Hi,
I think the text is great.
However I'm not entirely convinced that AIA requires network connectivity at all times.
The AIA CA cert url is static and works fine as identifier for a locally cached cert
The fact that it is the correct cert is assured by the path validation process.
As such, the AIA works fine with a http cache implementation or similar or any other solution using locally stored data.
If used in a local corporate context, a cache mechanism could be provided with pre-loaded relevant certs.
But I don’t know how this may or may not interoperate with deployed base of EAP implementations.
Stefan Santesson
On 2020-10-30, 14:48, "Mohit Sethi M" <mohit.m.sethi@xxxxxxxxxxxx> wrote:
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@xxxxxxxx
> https://www.ietf.org/mailman/listinfo/emu
--
last-call mailing list
last-call@xxxxxxxx
https://www.ietf.org/mailman/listinfo/last-call
