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 <turn...@ieca.com> 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
_______________________________________________ sidr mailing list sidr@ietf.org https://www.ietf.org/mailman/listinfo/sidr