Dear all,
Following the discussion today at OGF19 on the Grid Certificate Profile
document, and with the valuable comments from Mike Jones addressed inasfar
we had not done that already during the meeting, a new version of
the GCP is now available on gridforge:
https://forge.gridforum.org/sf/go/doc13741 (PDF version)
https://forge.gridforum.org/sf/go/doc13742 (MS Word version)
The biggest change is probably in the abstract. The original abstract was
very unclear, so I've rewritten it quite a bit to hopefully better convey
the message. The new version reads:
"
Interoperability for X.509 identity certificates between issuers of those
certificates and the software that interprets the certificates has become
increasingly important with the growth of the global grid community. As the
number of participants in grids that rely on a X.509 certificates grows, it is
increasingly more difficult to predict which software will be used by the
parties relying on the certificate, and how this software will interpret
specific name forms, extensions and attributes. To ensure the certificate is
interpreted by the relying party in the way the issuer intended it, better
specifications and in some cases explicit restrictions on the use of name forms
and certificate extensions is needed in order to ensure continued
interoperability. This document provides guidance for the content of issuer and
end-entity X.509 certificates for use with grid software.
"
For the rest, it is mostly minor changes as we discussed live today.
Please have a final look at this document, so that the Chairs can push this
document to WG final call RealSoonNow(TM).
Thanks for all the comments!
DavidG.
Original comments from Mike:
-------------------------------------------------------
Globally:
1, Suggest changing URL to URI throughout (and using scheme=http/https if
necessary).
2, Suggest adding the OID as a subtitle to the relevant section
Abstract
--------
1a, The abstract confused me slightly (I had to read it a few times to try and
get the intended meaning).
Suggest a content change from "As the number of participants in the grid that
use certificates grows, the relationship between the issuers and relying parties
becomes weaker.", to "As the number of participants in a grid that use
certificates grow, the ability of a Certificate Authority to maintain an adequet
trust relation with its relying parties becomes more difficult." -- and perhaps
add -- "Therefore the assertions may need to become looser to reflect weaknesses
in larger scale environments."
1b, Otherwise can I suggest: "in the grid" -> "in a grid", "certificate grows,"
-> "certificates grow"
2, Of the relying parties refered to, are these the services who rely upon the
CA to identify EECs, the users and servers to whome certificates are issued or
both: do they both get weaker?
2, Typo: "come cases" -> "some cases"
1. Scope of this document
-------------------------
1, Suggest you delete ", unless explicitly stated otherwise in this document" --
I think it's unecessary.
2.2 Serial Number
-----------------
1, Suggest you qualify the statememt "The serial number of each CA certificate
SHOULD be unique" to explicitely say that a CA's S/N is to be unique for each
instance of a certificate created to represent the CA. e.g. "The serial number
of each CA certificate SHOULD be unique among all certificates representing that CA.
2, In the footnote: suggest you change "the import of" to "the process of
importing" -- the import of sounds like "the importance of".
3, In the footnote: change "certificate in Microsoft E" to certificate into
Microsoft E"
2.3 Issuer and Subject names
----------------------------
1, Typo: "supported by the all of the current software", delete the first "the".
2, "all known grid-middleware" is subjective. And I don't think UNICORE uses the
DN for identity purposes rather the whole X.509 certificate (I may be wrong).
3, Footnote2. Why is FreeRadius mentioned? It seems out of place to mention
one software and not list the others.
2.3.1 serialNumber
------------------
1, Do you want to explicitely forbid serialNumber rather that recommend not
using it?
2, Footnote3. discussion -> discussions
2.3.2 emailAddress
------------------
1, emailAddress has been deprecated not obsoleted.
2.2.3 userID of uid
-------------------
uid is also described in oid 2.5.4.45 (uniqueIdentifier) which openssl regards
as UID:
from crypto/objects/objects.h
#define SN_uniqueIdentifier "UID"
#define LN_uniqueIdentifier "uniqueIdentifier"
#define NID_uniqueIdentifier 102
#define OBJ_uniqueIdentifier OBJ_X509,45L
and from crypto/objects/obj_mac.h
0x55,0x04,0x2D, /* [544] OBJ_uniqueIdentifier */
2.4.5 cRLDistributionPoints
---------------------------
Need a CRL distribution point be included in an EEC whose CA falls within the
catagory of the SLCS profile?
footnote13, https downloads do not have to pass any verification. Therefore
bootstrap problems need not occur.
2.4.6 Authority and Subject Key Identifier
------------------------------------------
1, change "the authorityKeyIdentifier and subjectKeyIdentifier MUST be the same"
to "the subjectKeyIdentifier and authorityKeyIdentifier's subjectKeyIdentifier
MUST be the same".
3.2 Subject distinguished names
-------------------------------
1, change "Other RDN attribute types" to "RDN attribute types other"
3.2.2 PrintableString encoding recommendations
----------------------------------------------
footnote 17 kind of conrtadicet footnote 19.
3.2.6 userID or uid
-------------------
"i.e." should contian 2.5.4.45 as well
3.2.7 domainComponent...
---------------------
1, Why need DC ever be encoded as IA5string when DNS only allows [a-z0-9_.-]?
2, should the last word be RECOMENDED rather than encouraged?
3.3.13 authorityInformationAccess
---------------------------------
1, change authoirtyInfoAccess to authorityInformationAccess as per heading.
4.3 Maximum key lengths
-----------------------
Does the action for 2007 in this section need to be done now?
----------------------------------------------------------
--
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 **
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 **
