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

[Geoff Huston <[e-mail]>]

I support verification of this Errata Report.

  Geoff

On 13 Aug 2014, at 10:25 am, RFC Errata System <[e-mail]> wrote:

> 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 <[e-mail]>
> 
> 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
>