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 **
One question that I've just been asked is: "Does the hyphen in a in a CN (ss 3.2.3) affect user certificates in Globus installations?" e.g. If I have "...CN=robert kilroy-silk" in my grid-mapfile and a I process an GSI connection with "CN=robert kilroy", will they get Mr kilroy-silk's account mapping? Mike
Hi Mike, Mike 'Mike' Jones wrote:
One question that I've just been asked is: "Does the hyphen in a in a CN (ss 3.2.3) affect user certificates in Globus installations?"
e.g. If I have "...CN=robert kilroy-silk" in my grid-mapfile and a I process an GSI connection with "CN=robert kilroy", will they get Mr kilroy-silk's account mapping?
No, this particular behaviour is only used when authenticating hosts and services, and not in any subsequent authZ decisions. DavidG.
Mike
-- 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 **
Has anyone replied to you about this? My experience is that the globus patched version of openssl will interpret the "robert kilroy-" part as a wildcard and only treat silk as significant. I'm trying to remember if the space makes a difference - I don't think it does. Darcy Mike 'Mike' Jones wrote:
One question that I've just been asked is: "Does the hyphen in a in a CN (ss 3.2.3) affect user certificates in Globus installations?"
e.g. If I have "...CN=robert kilroy-silk" in my grid-mapfile and a I process an GSI connection with "CN=robert kilroy", will they get Mr kilroy-silk's account mapping?
Mike
-- caops-wg mailing list caops-wg@ogf.org http://www.ogf.org/mailman/listinfo/caops-wg
Hi all, Darcy Quesnel wrote:
Has anyone replied to you about this?
My experience is that the globus patched version of openssl will interpret the "robert kilroy-" part as a wildcard and only treat silk as significant. I'm trying to remember if the space makes a difference - I don't think it does.
No, this implicit wildcard matching is only used when comparing host names, and is not in the code matching usernames in the gridmapfile (I just lloked at that piece of the code and there is nothing special in the gss_assist_gridmap call regarding dashes). So, the mapping will be unique and Mr. Kilroy-silk will be safe :-) Cheers, DavidG.
Darcy
Mike 'Mike' Jones wrote:
One question that I've just been asked is: "Does the hyphen in a in a CN (ss 3.2.3) affect user certificates in Globus installations?"
e.g. If I have "...CN=robert kilroy-silk" in my grid-mapfile and a I process an GSI connection with "CN=robert kilroy", will they get Mr kilroy-silk's account mapping?
Mike
-- caops-wg mailing list caops-wg@ogf.org http://www.ogf.org/mailman/listinfo/caops-wg
-- 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 **
Darcy, Yes, there was a discussion about this at OGF19. It seems that it's only the hostname to certificate authentication cross check that uses this process, I was just worried that the same routines might be used in the grid-mapping of user certificates but this seems not to be the case. On the subject of wild cards, a number of browsers support the use of the asterisks as wild cards in the CN field of a DNS style CN. e.g. *.google.com; does this document need a comment to this effect? Thanks, Mike On Thu, 15 Mar 2007, David Groep wrote:
Hi all,
Darcy Quesnel wrote:
Has anyone replied to you about this?
My experience is that the globus patched version of openssl will interpret the "robert kilroy-" part as a wildcard and only treat silk as significant. I'm trying to remember if the space makes a difference - I don't think it does.
No, this implicit wildcard matching is only used when comparing host names, and is not in the code matching usernames in the gridmapfile (I just lloked at that piece of the code and there is nothing special in the gss_assist_gridmap call regarding dashes). So, the mapping will be unique and Mr. Kilroy-silk will be safe :-)
Cheers, DavidG.
Darcy
Mike 'Mike' Jones wrote:
One question that I've just been asked is: "Does the hyphen in a in a CN (ss 3.2.3) affect user certificates in Globus installations?"
e.g. If I have "...CN=robert kilroy-silk" in my grid-mapfile and a I process an GSI connection with "CN=robert kilroy", will they get Mr kilroy-silk's account mapping?
Mike
-- caops-wg mailing list caops-wg@ogf.org http://www.ogf.org/mailman/listinfo/caops-wg
Mike 'Mike' Jones <mike.jones@manchester.ac.uk> wrote:
On the subject of wild cards, a number of browsers support the use of the asterisks as wild cards in the CN field of a DNS style CN. e.g. *.google.com; does this document need a comment to this effect?
One reference for this behavior is Section 3.1 (Server Identity) of RFC 2818 (HTTP Over TLS). If a subjectAltName extension of type dNSName is present, that MUST be used as the identity. Otherwise, the (most specific) Common Name field in the Subject field of the certificate MUST be used. Although the use of the Common Name is existing practice, it is deprecated and Certification Authorities are encouraged to use the dNSName instead. Matching is performed using the matching rules specified by [RFC2459]. If more than one identity of a given type is present in the certificate (e.g., more than one dNSName name, a match in any one of the set is considered acceptable.) Names may contain the wildcard character * which is considered to match any single domain name component or component fragment. E.g., *.a.com matches foo.a.com but not bar.foo.a.com. f*.com matches foo.com but not bar.com. -Jim
Hi folks, I've just been asked to add an LSU grid certificate to one of our servers. We sometimes do things like this as a special case reading the CP/CPS where available. However, that's not the point of this email! Poking around the web for details of the "/O=Louisiana State University/OU=CCT/OU=ca.cct.lsu.edu/CN=CCT CA" Certificate Authority I came across the SURAgrid bridge CA. In their documentation they advise _against_ using the Authority Key Identifier (for obvious reasons). The Grid Certificate Profile draft currently recommends that AKID be used (table in section 2.4). Might it be appropriate for us to add a note that by doing this one essentially removes the possibility for joining a bridging scheme such as https://www.pki.virginia.edu/nmi-bridge/ ? Cheers, Mike
Mike, Using AKI is definitely recommended for Bridging - it makes it easier to discover appropriate paths. The SURA documentation is not advising against this, they are in fact recommending that you do use it - but use the keyid version rather than the dirname version. AKI can be populated with multiple values, SURA recommends that you simply use the keyid value only as this works with the bridge and the globus software as they have configured it. Regards, -Scott Mike 'Mike' Jones wrote:
Hi folks,
I've just been asked to add an LSU grid certificate to one of our servers. We sometimes do things like this as a special case reading the CP/CPS where available. However, that's not the point of this email!
Poking around the web for details of the "/O=Louisiana State University/OU=CCT/OU=ca.cct.lsu.edu/CN=CCT CA" Certificate Authority I came across the SURAgrid bridge CA. In their documentation they advise _against_ using the Authority Key Identifier (for obvious reasons). The Grid Certificate Profile draft currently recommends that AKID be used (table in section 2.4). Might it be appropriate for us to add a note that by doing this one essentially removes the possibility for joining a bridging scheme such as https://www.pki.virginia.edu/nmi-bridge/ ?
Cheers, Mike ------------------------------------------------------------------------
-- caops-wg mailing list caops-wg@ogf.org http://www.ogf.org/mailman/listinfo/caops-wg
-- Scott Rea Director, HEBCA|USHER Operating Authority Dartmouth Senior PKI Architect Peter Kiewit Computing Services Dartmouth College 058 Sudikoff, HB 6238 Hanover, NH 03755 Em: Scott.Rea@Dartmouth.edu Ph#(603) 646-0968 Ot#(603) 646-9181 Fx#(603) 646-9019 Ce#(603) 252-7339
Scott Rea writes:
Using AKI is definitely recommended for Bridging - it makes it easier to discover appropriate paths. The SURA documentation is not advising against this, they are in fact recommending that you do use it - but use the keyid version rather than the dirname version.
I believe we are (or should be) recommending the same thing in the profile; the directory name version usage has led to problems with CA key rollover.
AKI can be populated with multiple values, SURA recommends that you simply use the keyid value only as this works with the bridge and the globus software as they have configured it.
Regards, -Scott
Mike 'Mike' Jones wrote:
Hi folks,
I've just been asked to add an LSU grid certificate to one of our servers. We sometimes do things like this as a special case reading the CP/CPS where available. However, that's not the point of this email!
Poking around the web for details of the "/O=Louisiana State University/OU=CCT/OU=ca.cct.lsu.edu/CN=CCT CA" Certificate Authority I came across the SURAgrid bridge CA. In their documentation they advise _against_ using the Authority Key Identifier (for obvious reasons). The Grid Certificate Profile draft currently recommends that AKID be used (table in section 2.4). Might it be appropriate for us to add a note that by doing this one essentially removes the possibility for joining a bridging scheme such as https://www.pki.virginia.edu/nmi-bridge/ ?
Cheers, Mike ------------------------------------------------------------------------
-- caops-wg mailing list caops-wg@ogf.org http://www.ogf.org/mailman/listinfo/caops-wg
-- Scott Rea Director, HEBCA|USHER Operating Authority Dartmouth Senior PKI Architect Peter Kiewit Computing Services Dartmouth College 058 Sudikoff, HB 6238 Hanover, NH 03755
Em: Scott.Rea@Dartmouth.edu Ph#(603) 646-0968 Ot#(603) 646-9181 Fx#(603) 646-9019 Ce#(603) 252-7339
-- caops-wg mailing list caops-wg@ogf.org http://www.ogf.org/mailman/listinfo/caops-wg
I would be in favor of this - I have never used the DirName value in AuthorityKeyIdentifier, I have always used KeyId -Scott Mike Helm wrote:
Scott Rea writes:
Using AKI is definitely recommended for Bridging - it makes it easier to discover appropriate paths. The SURA documentation is not advising against this, they are in fact recommending that you do use it - but use the keyid version rather than the dirname version.
I believe we are (or should be) recommending the same thing in the profile; the directory name version usage has led to problems with CA key rollover.
AKI can be populated with multiple values, SURA recommends that you simply use the keyid value only as this works with the bridge and the globus software as they have configured it.
Regards, -Scott
Mike 'Mike' Jones wrote:
Hi folks,
I've just been asked to add an LSU grid certificate to one of our servers. We sometimes do things like this as a special case reading the CP/CPS where available. However, that's not the point of this email!
Poking around the web for details of the "/O=Louisiana State University/OU=CCT/OU=ca.cct.lsu.edu/CN=CCT CA" Certificate Authority I came across the SURAgrid bridge CA. In their documentation they advise _against_ using the Authority Key Identifier (for obvious reasons). The Grid Certificate Profile draft currently recommends that AKID be used (table in section 2.4). Might it be appropriate for us to add a note that by doing this one essentially removes the possibility for joining a bridging scheme such as https://www.pki.virginia.edu/nmi-bridge/ ?
Cheers, Mike ------------------------------------------------------------------------
-- caops-wg mailing list caops-wg@ogf.org http://www.ogf.org/mailman/listinfo/caops-wg
-- Scott Rea Director, HEBCA|USHER Operating Authority Dartmouth Senior PKI Architect Peter Kiewit Computing Services Dartmouth College 058 Sudikoff, HB 6238 Hanover, NH 03755
Em: Scott.Rea@Dartmouth.edu Ph#(603) 646-0968 Ot#(603) 646-9181 Fx#(603) 646-9019 Ce#(603) 252-7339
-- caops-wg mailing list caops-wg@ogf.org http://www.ogf.org/mailman/listinfo/caops-wg
-- Scott Rea Director, HEBCA|USHER Operating Authority Dartmouth Senior PKI Architect Peter Kiewit Computing Services Dartmouth College 058 Sudikoff, HB 6238 Hanover, NH 03755 Em: Scott.Rea@Dartmouth.edu Ph#(603) 646-0968 Ot#(603) 646-9181 Fx#(603) 646-9019 Ce#(603) 252-7339
Hi, Mike Helm wrote:
Scott Rea writes:
Using AKI is definitely recommended for Bridging - it makes it easier to discover appropriate paths. The SURA documentation is not advising against this, they are in fact recommending that you do use it - but use the keyid version rather than the dirname version.
I believe we are (or should be) recommending the same thing in the profile;
ACK
the directory name version usage has led to problems with CA key rollover.
Well if the key of the authority changes the hash variant of the AKI is changing too. IMO it was not the key rollover, it was the reissuing of a CA cert with e.g. an extended lifetime or a different signing hash (md5 towards sha1) which was easier with the hash AKI. In this case the serial number could be changed without effect to the evaluation of preexisting certification paths. The changed CA cert could just be replaced. -- Beste Gruesse / Kind Regards Reimer Karlsen-Masur DFN-PKI FAQ: https://www.pki.dfn.de/faqpki -- Dipl.-Inform. Reimer Karlsen-Masur (PKI Team), Phone +49 40 808077-615 DFN-CERT Services GmbH, https://www.dfn-cert.de, Phone +49 40 808077-555 Sitz / Register: Hamburg, AG Hamburg, HRB 88805, Ust-IdNr.: DE 232129737
"Reimer Karlsen-Masur, DFN-CERT" writes:
IMO it was not the key rollover, it was the reissuing of a CA cert with e.g. an extended lifetime or a different signing hash (md5 towards sha1) which
Yes that's much better. The CA's in question came to the end of the lifetime of the signing cert & needed to do something, and how they had previously set up the Authority KeyId had a large role in what they did next. We should actually write another document about how to manage this transistion (or how not to :^).
participants (7)
-
Darcy Quesnel -
David Groep -
Jim Basney -
Mike 'Mike' Jones -
Mike Helm -
Reimer Karlsen-Masur, DFN-CERT -
Scott Rea