January 2007 - caops-wg - lists.ogf.org

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