Re: [secdir] [Emu] Secdir last call review of draft-ietf-emu-eaptlscert-06

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