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

From: RFC Errata System <[email-masked]>
Date: Tue, 12 Aug 2014 17:25:01 -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=4080

--------------------------------------
Type: Technical
Reported by: Sean Turner <[email-masked]>

Section: 6.1.1

Original Text
-------------
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.

Corrected Text
--------------
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.

Instructions:
-------------
This erratum 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, 13 Aug 2014 12:06:53 +1000

I support verification of this Errata Report.

  Geoff