Hi Kaspar, all, Kaspar Brand wrote:
Please have a final look at this document, so that the Chairs can push this document to WG final call RealSoonNow(TM).
Thanks for these new references. I think it's essential to capture this in the document and not rely on old versions (especially RFC4630 clears things up very well). I've merged these changes into version 0.21 of the Grid Certificate Profile document that is now on gridforge: https://forge.gridforum.org/sf/go/doc13741 (PDF version) https://forge.gridforum.org/sf/go/doc13742 (MS Word version) I think the document is now in quite a good shape. Changes: * in section 2.3 and 3.2.1, rewritten to incorporate RFC4630: "All Relative Distinguished Name (RDN) components in distinguished names MUST be compliant with [RFC4630] and in addition SHOULD be encoded as PrintableString. If an UTF8String is used for encoding, the RDN MUST NOT contain characters that cannot be expressed in printable 7-bit ASCII, as these characters have inconsistent representations." * replaced references to RFC2253 with RFC4514, and added correct reference * cleaned up references and added formal ref to RFC2119 * added explanation of why ordering is important (tailing end wildcard matching) to section 4.1 [being triggered by refs to 4514] * cleared up the top-level abstract a bit, defining scope and intended audience "This document provides guidance for the use of directory names, attributes, and extensions in X.509 certificates, such that they are usable by the majority of the grid infrastructures today. The intended audience for this document includes issuers of X.509 certificates for use in grid infrastructures, and implementers of X.509 validation software for grid purposes. Interoperability for X.509 identity certificates between the issuers of certificates and the software that interprets them is increasingly more important as the number of participants in grids that rely on a X.509 certificates grows. It is difficult to predict which particular software will be used by the parties relying on the certificate, and how this software interprets specific name forms, attributes, and extensions. This document gives guidance and defines explicit restrictions on the certificate profile to ensure the certificate is interpreted by the relying party in the way the issuer intended. It specifies and further restricts the certificate format as defined in RFC3280 and the X.509 standard." * I would propose this document be classified as "Community Practice" (GWD-C). Do the WG and chairs agree? Best, DavidG.
Not sure if I'm too late with this, but I recently came across
RFC 4630, Update to DirectoryString Processing in the Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile http://www.ietf.org/rfc/rfc4630.txt
which is probably worth to be referenced in 3.2.1 ff. (String encoding of the RDN components). It no longer makes UTF8String mandatory for certs issued after December 31, 2003 - instead it now reads:
The DirectoryString type is defined as a choice of PrintableString, TeletexString, BMPString, UTF8String, and UniversalString. CAs conforming to this profile MUST use either the PrintableString or UTF8String encoding of DirectoryString, with one exception. When CAs have previously issued certificates with issuer fields with attributes encoded using the TeletexString, BMPString, or UniversalString, the CA MAY continue to use these encodings of the DirectoryString to preserve the backward compatibility.
Similarly, the references to RFC 2253 could be adapted to point to
RFC 4514, Lightweight Directory Access Protocol (LDAP): String Representation of Distinguished Names http://www.ietf.org/rfc/rfc4514.txt
instead (appendix B has a list of "substantive changes" compared to 2253, I haven't looked at it in detail).
Regards, Kaspar
-- David Groep ** National Institute for Nuclear and High Energy Physics, PDP/Grid group ** ** Room: H1.56 Phone: +31 20 5922179, PObox 41882, NL-1009DB Amsterdam NL **