errata logo graphic

Found 5 records.

Status: Verified (2)

RFC6487, "A Profile for X.509 PKIX Resource Certificates", February 2012

Source of RFC: sidr (rtg)

Errata ID: 3205

Status: Verified
Type: Technical

Reported By: David Mandelberg
Date Reported: 2012-04-27
Verifier Name: Stewart Bryant
Date Verified: 2013-09-19

Section 5 says:

   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.

It should say:

   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. The extensions mentioned above MUST NOT appear more than 
   once each.

Notes:

The clarification:

"The extensions mentioned above MUST NOT appear more than once each."

is added.


Errata ID: 3238

Status: Verified
Type: Technical

Reported By: Stephen Kent
Date Reported: 2012-05-31
Verifier Name: Stewart Bryant
Date Verified: 2013-01-11

Section 6.3 says:

 ExtendedKeyUsage
         The CA MAY honor ExtendedKeyUsage extensions of keyCertSign and
         cRLSign if present, as long as this is consistent with the
         BasicConstraints SubjectType sub-field, when specified.

It should say:

 ExtendedKeyUsage
         The CA MAY honor ExtendedKeyUsage extensions in requests for EE
         certificates that are issued to routers or other devices, consistent with values
         specified in Standards Track RFCs that adopt this profile and that identify
         application-specific requirements that motivate the use of such EKUs.

Notes:

The current text appears to be the result of a "cut and paste" error. It is essentially identical to the text
for the Key Usage extension, and names two fields that appear in that extension, not in an EKU extension. The text I propose above parallels what appears in Section 4.8.5, which describes how an
EKU MAY be used in RPKI certificates.


Status: Reported (1)

RFC6487, "A Profile for X.509 PKIX Resource Certificates", February 2012

Source of RFC: sidr (rtg)

Errata ID: 4080

Status: Reported
Type: Technical

Reported By: Sean Turner
Date Reported: 2014-08-12

Section 6.1.1 says:

This field MAY be omitted.  If present, the value of this field
SHOULD be empty (i.e., NULL), in which case the CA MUST
generate a subject name that is unique in the context of
certificates issued by this CA.  This field is allowed to be
non-empty only for a re-key/reissuance request, and only if the
CA has adopted a policy (in its Certificate Practice Statement
(CPS)) that permits reuse of names in these circumstances.

It should say:

This field
SHOULD be empty (i.e., NULL), in which case the CA MUST
generate a subject name that is unique in the context of
certificates issued by this CA.  This field is allowed to be
non-empty only for a re-key/reissuance request, and only if the
CA has adopted a policy (in its Certificate Practice Statement
(CPS)) that permits reuse of names in these circumstances.


Notes:

Submitted after consultation with the responsible AD and WG chairs.

The subject field included in the PKCS#10 request can't be omitted because the ASN.1 in RFC 2986 doesn’t allow subject to be omitted - there’s no “OPTIONAL” in the ASN.1:

CertificationRequestInfo ::= SEQUENCE {
version INTEGER { v1(0) } (v1,...),
subject Name,
subjectPKInfo SubjectPublicKeyInfo{{ PKInfoAlgorithms }},
attributes [0] Attributes{{ CRIAttributes }}
}

In other words, four fields are included in every certificate request. If there’s no subject field it’s a NULL (see RFC5280 for omitting subjects) and if there’s no attributes it’s an empty sequence. version and subjectPKInfo (subject public key information) are always present.


Status: Rejected (2)

RFC6487, "A Profile for X.509 PKIX Resource Certificates", February 2012

Source of RFC: sidr (rtg)

Errata ID: 3168

Status: Rejected
Type: Technical

Reported By: David Mandelberg
Date Reported: 2012-03-26
Rejected by: Stewart Bryant
Date Rejected: 2013-05-06

Section 4.8 says:

   or non-critical.  A certificate-using system MUST reject the
   certificate if it encounters a critical extension it does not
   recognize; however, a non-critical extension MAY be ignored if it is
   not recognized [RFC5280].

It should say:

   or non-critical.  A certificate-using system MUST reject the
   certificate if it encounters an extension not explicitly mentioned
   in this document.  This is in contrast to RFC 5280 which allows
   non-critical extensions to be ignored.

Notes:

Other sections of the same document contradict the original section 4.8:

Section 1:

Any extensions not explicitly mentioned MUST be absent. The same
applies to the CRLs used in the RPKI, that are also profiled in this
document.

Section 8:

Certificate Extensions:
This profile does not permit the use of any other critical or
non-critical extensions.
--VERIFIER NOTES--
This is a technical change to the RFC and needs to be addressed though the IETF consensus process and rather than via the errata process.


Errata ID: 3174

Status: Rejected
Type: Technical

Reported By: David Mandelberg
Date Reported: 2012-04-03
Rejected by: Stewart Bryant
Date Rejected: 2013-05-06

Section 5 says:

   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.

It should say:

   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.
--VERIFIER NOTES--
The discussion on the SIDR list concluded that this errata should be rejected, although there appears an issue that may need addressing through a new errata or a revision to the RFC text.


Report New Errata