Hi Stefan, Thank you for the review. I have updated the draft in github (https://github.com/emu-wg/eaptls-longcert). Here is the diff for your convenience: https://tools.ietf.org/rfcdiff?url1=https://tools.ietf.org/id/draft-ietf-emu-eaptlscert.txt&url2=https://emu-wg.github.io/eaptls-longcert/draft-ietf-emu-eaptlscert.txt.
The following text was added: > The size of certificates (and certificate chains) may also increase > manifold in the future with the introduction of quantum-safe > cryptography. For example, lattice-based cryptography would have > public keys of approximately 1000 bytes and signatures of > approximately 2000 bytes. and in Section 4.2.5 > The Authority Information Access (AIA) extension specified in > [RFC5280] can be used with end-entity and CA certificates to access > information about the issuer of the certificate in which the > extension appears. For example, it can be used to provide the > address of the OCSP responder from where revocation status of the > certificate (in which the extension appears) can be checked. It can > also be used to obtain the issuer certificate. Thus, the AIA > extension can reduce the size of the certificate chain by only > including a pointer to the issuer certificate instead of including > the entire issuer certificate. However, it requires the side > receiving the certificate containing the extension to have network > connectivity. Naturally, such indirection cannot be used for the > server certificate (since the EAP peer in most deployments does not > have network connectivity before authen Let me know what you think. I am not an expert on quantum cryptography or on the AIA extension. I will wait for all the comments to come in before submitting a new version. --Mohit On 10/30/20 5:04 AM, Benjamin Kaduk wrote: > Hi Stefan, > > Thanks for the review; it raises some good topics. > Replying on a couple points... > > On Thu, Oct 29, 2020 at 04:13:02PM -0700, Stefan Santesson via Datatracker > wrote: >> Reviewer: Stefan Santesson >> Review result: Has Nits >> >> The document in general is good and well written. >> >> Some nits needs attention before publication as the general review also >> points >> out. Ex in the abstract "This document looks at the this problem" >> >> Some abbreviations needs to be spelled out at first usage, such as MTU >> (Maximum >> Transmission Unit) > MTU may actually be okay; per > https://www.rfc-editor.org/materials/abbrev.expansion.txt it is marked as > "well-known" and does not always need to be expanded. > >> On the content itself I have two questions: >> >> - Wouldn't it be relevant to also discuss the risks with regard to >> introduction >> of quantum safe crypto, if that leads to significantly increased key sizes? >> It >> could be troublesome if transition to a safer crypto is made impossible due >> to >> size limitations. - Would it be relevant to discuss usage of AIA extension as >> means of possibly excluding intermediary certs from the path as they could be >> located using AIA? >> >> Finally, I agree with the general review that this document reference quite >> some work in progress. If this document is to be published before these >> referenced works are concluded, are there alternatives to make the same >> point? > They seem to mostly be informative references, and so would not require us > to hold publication of this document. It is probably still worth > considering if there are alternatives anyway, though. > > -Ben > > _______________________________________________ > Emu mailing list > Emu@ietf.org > https://www.ietf.org/mailman/listinfo/emu _______________________________________________ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
