- caops-wg - lists.ogf.org

Draft Agenda
by Darcy Quesnel 08 May '07

08 May '07

- Vote on Grid Certificate Profile Document? - David, 2 min, Darcy 3 min - Plans on Finalizing the #%&! OCSP Document! - Milan Sova, 15 min - Development of Audit Guidlines Document? - Yoshio, 15 min - Development of the Authentication Service Profile Document - David, 15 min - Development of the Relying Party Defined Namespace Policies Document - David, 15 min Any suggestions are welcome. The agenda is on the wiki associated with the CAOPS site http://forge.gridforum.org/sf/wiki/do/viewPage/projects.caops-wg/wiki/HomeP… Feel free to add material, amend, and generally edit this agenda. Darcy

5 8

Grid Certificate Profile version 0.20
by David Groep 28 Mar '07

28 Mar '07

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 **

7 12

Meeting Materials for OGF19 now online
by Darcy Quesnel 14 Mar '07

14 Mar '07

Some of the meeting materials are now finally online: http://forge.gridforum.org/sf/docman/do/listDocuments/projects.caops-wg/doc… If anyone has any more material to add, please tell me. BTW, we are now planning for OGF20 in Manchester. Darcy

1 0

Re: [caops-wg] Grid Certificate Profile version 0.20
by David Groep 06 Mar '07

06 Mar '07

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 **

1 0

GNU TLS now supports RFC 3820 proxy certificates in experimental branch
by Alan Sill 05 Feb '07

05 Feb '07

In developing standards it is sometimes useful to keep track of progress in implementation. In this light it may be interesting to note that the most recent experimental branch of the GNU TLS library, which runs on most Unix platforms as well as on Windows and provides support for TLS 1.0, TLS 1.1 and SSL 3.0 and authentication using both X.509 certificates and OpenPGP keys and certificates, now also includes support for RFC 3820 proxy certificates (as well as TLS 1.2): http://www.gnu.org/software/gnutls/ Alan Alan Sill, Ph.D TIGRE Senior Scientist, High Performance Computing Center Adjunct Professor of Physics TTU ==================================================================== : Alan Sill, Texas Tech University Office: Admin 233, MS 4-1167 : : e-mail: Alan.Sill(a)ttu.edu ph. 806-742-4350 fax 806-742-4358 : ====================================================================

1 0

Draft Agenda for the Document Session
by Darcy Quesnel 01 Feb '07

01 Feb '07

It's already the night before the week of, and we haven't formed an actual draft agenda yet! Well. Let's try something a bit different this time. The following is up on the CAOPS-WG wiki, feel free to add ideas, your name next to things to do :-), etc. http://forge.gridforum.org/sf/wiki/do/viewPage/projects.caops-wg/wiki/HomeP… CAOPS-WG (Document Session) Thursday 11:00 am - 12:30 pm (Windflower Room) * Status of existing documents (5' Darcy) * OCSP document ?? * CA Auditing ?? * RA Aditing (15' Matthew Viljoen) * Certificate Contents ?? * Any other bright ideas ?? Let's form the agenda on the wiki and through discussion on the mailing list, otherwise this is going to be a short session. I think it's set up so that any one who's a member of the CAOPS-WG group can edit the wiki. Let's see. Darcy

7 9

Dial-In details for the CAOPS session
by Christos Kanellopoulos 31 Jan '07

31 Jan '07

Hi all, The Dial-In number is +1 (866) 599-4740. When prompted enter the conference code, which is 9621599, followed by # The CAOPS Session starts 11:00 am EST (-5 GMT) -C.

1 0

Draft Agenda
by Yoshio Tanaka 29 Jan '07

29 Jan '07

Dear all, The OGF19 will start tomorrow. As in the recent GGF/OGFs, we will have one regular CAOPs session and one IGTF session, both sessions are scheduled on Thursday (Feb. 1) morning. Here is a draft agenda of the IGTF session: ------------------------------------------------------------ - Short updates from regional PMAs - APGrid PMA (Yoshio) - EUGrid PMA (David) - TAGPMA (Darcy) - IGTF Key Registry and TACAR (Yoshio, Mike, Licia) - Authentication Profiles - Member Integrated Credential Services (TBD) - Portal-based credential services (Yoshio) - AOB ------------------------------------------------------------ Suggestions for the agenda are welcome. I would like to note that the schedule on the OGF web site (as of 28th, Sun 11pm UTC) has been changed as below: IGTF session: 9:00am - 10:30am Feb. 1 (Thu) CAOPs session: 11:00am - 12:30am Feb. 1 (Thu) This change has been confirmed by the Security AD and the OGF web site is expected to be updated shortly. -- Yoshio Tanaka (yoshio.tanaka(a)aist.go.jp) http://ninf.apgrid.org/ http://www.apgridpma.org/

3 2

Latest version (0.19) of the Grid Certificate Profile doc
by David Groep 25 Jan '07

25 Jan '07

Dear all, For reference and use during the upcoming CAOPS document session Thursday next week, the latest version of the Grid Certificate Profile document is (as always) available from GridForge at: https://forge.gridforum.org/sf/go/doc13741 (PDF version) https://forge.gridforum.org/sf/go/doc13742 (MS Word version) The content has been quite stable over the past few months, so hopefully our session next week will be good time to decide on the way forward. Please have a look at the document so that we can make a hopefully well-informed decision about it. Best regards, DavidG. -- 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 **

1 0

Re: [caops-wg] [igtf-general] Re: Certificate Profile document updated (to v0.14)
by Mike Helm 04 Jan '07

04 Jan '07

I haven't had time to read the new draft but a couple comments at 2nd hand ... Kaspar Brand writes: > > recommendation. It used to be necessary to set pathlen=0 in the I said the wrong thing here - pathlen has to be undefined, or whatever "unlimited" is in asn.1. "0" probably has to be forbidden for Grid CAs; it disables old-style Grid proxy certs (we did this ca 2002). > > that pathLenConstraint MUST be absent or set to 0. I did the same for > > end-entity certs, comments welcome on that! > > Setting pathlen to 0 in end-entity certs actually goes explicitly > against both RFC 3280 and the latest 3280bis I-D: > > > CAs MUST NOT include the pathLenConstraint field unless the cA > > boolean is asserted and the key usage extension asserts the > > keyCertSign bit. > > In its current wording, 3.3.1 still gives the option of not including > pathlen at all (which is fine), but if we really want to allow the other > option (setting it to 0 for EE certs), then we should state that this > contradicts a mandatory requirement of RFC 3280 (similar to 3.2.1). Why would we want to set it for EE certs? The IETF PKIX profile for how path length is evaluated is in 4.2.1.10 (about p 36) > Second, two comments about authority and subject key identifiers - > section 2.4.6 currently states: > > > 2.4.6 Authority and Subject Key Identifier: > > A subjectKeyIdentifier extension MAY be included in CA certificates > > to aid in validation path construction. An authorityKeyIdentifier > > MAY be included in all CA certificates, except for selfsigned > > root certificates. > > The statement about the authorityKeyIdentifier is basically fine, but > the "except for selfsigned root certificate" poses a problem for a large > number of existing CA certs - when looking at the IGTF distribution Sure, ours does too. I don't understand this restriction - see the discussion in RFC 3280 4.2.1.1 - it's simply useless in the case of most self-signed CAs. RFC 3280 says "where ... [the CA has a] "self-signed" certificate, the authority key identifier MAY be omitted .... It's useless (I think) because disambiguation is not defined at the point in the chain of certs where you have a self-signed cert. The subject key & authority key ids should be identical in this case. (It might be useful to say, that if a self-signed CA cert presents an authority key id, it must be identical to the subject key id.)

3 3