Subject: [sidr] [Technical Errata Reported] RFC6487 (3174)

From: RFC Errata System <[email-masked]>
Date: Tue, 3 Apr 2012 11:26:31 -0700 (PDT)

The following errata report has been submitted for RFC6487,
"A Profile for X.509 PKIX Resource Certificates".

--------------------------------------
You may review the report below and at:
http://www.rfc-editor.org/errata_search.php?rfc=6487&eid=3174

--------------------------------------
Type: Technical
Reported by: David Mandelberg <[email-masked]>

Section: 5

Original Text
-------------
   An RPKI CA MUST include the two extensions, Authority Key Identifier
   and CRL Number, in every CRL that it issues.  RPs MUST be prepared to
   process CRLs with these extensions.  No other CRL extensions are
   allowed.

Corrected Text
--------------
   An RPKI CA MUST include the two extensions, Authority Key Identifier
   and CRL Number, in every CRL that it issues.  The Authority Key
   Identifier extension MUST follow the same restrictions as in
   Section 4.8.3 above.  RPs MUST be prepared to process CRLs with
   these extensions.  No other CRL extensions are allowed.

Notes
-----
RFC 6487 doesn't specify any restrictions on the format of the AKI extension in CRLs.

Instructions:
-------------
This errata is currently posted as "Reported". If necessary, please
use "Reply All" to discuss whether it should be verified or
rejected. When a decision is reached, the verifying party (IESG)
can log in to change the status and edit the report, if necessary. 

--------------------------------------
RFC6487 (draft-ietf-sidr-res-certs-22)
--------------------------------------
Title               : A Profile for X.509 PKIX Resource Certificates
Publication Date    : February 2012
Author(s)           : G. Huston, G. Michaelson, R. Loomans
Category            : PROPOSED STANDARD
Source              : Secure Inter-Domain Routing
Area                : Routing
Stream              : IETF
Verifying Party     : IESG

---

From: Geoff Huston <[email-masked]>
Date: Wed, 4 Apr 2012 09:27:25 +1000

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. 

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.

regards,

    Geoff

---

From: David Mandelberg <[email-masked]>
Date: Wed, 04 Apr 2012 13:21:04 -0400

> 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 furt…

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.

-- 
David Mandelberg
Wed Apr 4 13:07:37 EDT 2012