On 04/04/2012 18:21, David Mandelberg wrote:
On Wed, 2012-04-04 at 09:27 +1000, Geoff Huston wrote:
I'm tending to a "reject". Section 4.8.3 does not precisely apply to CRLs, so
to accept this would then require a further errata notice to amend this errata to narrow
down the scope of the AIA further.
AKI, not AIA. I just meant that the CRL AKI should have the same format
and meaning as in 4.8.3, i.e. it should use the SHA-1 hash of the
issuer's public key with neither authorityCertIssuer nor
authorityCertSerialNumber fields present. Maybe the errata should be
rejected and resubmitted with text copied and edited from 4.8.3, instead
of referencing 4.8.3?
Given that the text already says: "The algorithm used in CRLs issued under this
profile is specified in [RFC6485]." then I'm not not what futerhe specification is
required here.
What part of RFC6485 says anything about CRL AKIs? The closest I can
find is in Section 2:
NOTE: The exception to the above hashing algorithm is the use
of SHA-1 [SHS] when Certification Authorities (CAs) generate
authority and subject key identifiers [RFC6487].
That maybe could be interpreted as saying that CRL AKIs should use
SHA-1, but it doesn't say that authorityCertIssuer and
authorityCertSerialNumber must be absent. It also doesn't explicitly say
what to take the SHA-1 of when generating a CRL AKI.
As far as I can see the thread died at this point.
I have rejected the errata.
I see two ways forward, either submit a new errata that describes the
correction in a way that has consensus, or roll the change into the
update required to address the issue raised in errata 3168.
- Stewart
_______________________________________________
sidr mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/sidr
