- caops-wg - lists.ogf.org

Updated Relying Party Defined Namespace Constraints Policies document with completely revamped text
by David Groep 04 Jun '08

04 Jun '08

Dear all, The latest version of the Relying Party Defined Namespace Constraints Policies document is now on gridforge: http://forge.gridforum.org/sf/go/doc4857?nav=1 Rewritten the rationale to better express we focus on authentication and CAs only. Jens will now take over editing and add a graphical figure to explain some use cases Cheers, 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

Trust anchor definition
by Milan Sova 04 Jun '08

04 Jun '08

Hi. This is the trust anchor definition form the Trust Anchor Management group strawman charter <http://www.vpnc.org/ietf-trust-anchor/mail-archive/msg00350.html> A trust anchor represents an authoritative entity represented via a public key and associated data. The public key is used to verify digital signatures and the associated data is used to constrain the types of information for which the trust anchor is authoritative. Relying parties use trust anchors to determine if digitally signed information objects are valid by verifying digital signatures using the trust anchor's public key and by enforcing the constraints expressed in the associated data. Regards -- Milan Sova sova(a)cesnet.cz

1 1

Debian key generation flaw
by Mike Jones 15 May '08

15 May '08

Hi folks, I've just been informed that openssl versions on Debian systems from Sep 2006 - May 2008 have had a substandard key generation algorithm. This is due to a predictable random number seed, resulting, I am led to believe, in a key space consisting of 32767 different keys for each key size, type and endianess. See e.g. http://lists.debian.org/debian-security-announce/2008/msg00152.html rgds Mike -- Dr. Mike Jones Research Computing Services at The University of Manchester http://www.rcs.manchester.ac.uk

1 0

Grid Certificate Profile is published as GFD.125
by Christos Kanellopoulos 01 Apr '08

01 Apr '08

Dear all, Finally, the Grid Certificate Profile is published [1] as GFD.125. Congratulations to all the authors and contributors of this document and especially to David Groep for responding very fast (even over the weekend!) to the last round of comments that were made by the reviewers. [1]: http://www.ogf.org/gf/docs/ -- Christos Kanellopoulos Grid Operations Center, Aristotle University of Thessaloniki University Campus, GR 541 24, Building 22D, Office 4'6B Tel. +302310998988 Fax. +302310994309 http://www.grid.auth.gr

1 0

Yet another final version of the CertProfile document
by David Groep 27 Mar '08

27 Mar '08

Dear all, The OGF e-Science function had yet another look at the grid certificate profile document and of course found a couple of minor textual issues, as listed in the gridForge tracker at https://forge.gridforum.org/sf/go/artf5963?nav=1 Based on these I updated the document to implement the requested textual changes and procuded revision 0.27, dated March 27, 2008 at: https://forge.gridforum.org/sf/go/doc13741 (PDF) https://forge.gridforum.org/sf/go/doc13742 (MS Word) (there called "version 19") I'll push this version back to the editor straight away, hoping that maybe, finally, at least, this documents makes it through the process without further a-do and gets its document number. 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 ** -- 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

Yet another final version of the CertProfile document
by David Groep 27 Mar '08

27 Mar '08

Dear all, The OGF e-Science function had yet another look at the grid certificate profile document and of course found a couple of minor textual issues, as listed in the gridForge tracker at https://forge.gridforum.org/sf/go/artf5963?nav=1 Based on these I updated the document to implement the requested textual changes and procuded revision 0.27, dated March 27, 2008 at: https://forge.gridforum.org/sf/go/doc13741 (PDF) https://forge.gridforum.org/sf/go/doc13742 (MS Word) (there called "version 19") I'll push this version back to the editor straight away, hoping that maybe, finally, at least, this documents makes it through the process without further a-do and gets its document number. 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

Requirements and rationale for Relying Party Defined Namespace Constraints (signing_policy file)
by David Groep 04 Mar '08

04 Mar '08

Dear all, The rationale for the signing policy file, expressing Relying Party Defined Namespace Constraints, has been documented in a CAOPS-WG draft document. This document is now nearing completion, but as its baseline is now more than two years old, we feel that the list of requirements on the signing policy language expressed in that document may no longer be up to date. As we discussed in the CAOPS WG, we have updated the document and now invite our major relying parties and middleware providers explicitly to comment on this document. Dave (JSPG), Christoph (MWSG) and Frank (Globus), can you forward this as appropriate? The latest document draft is at: https://forge.gridforum.org/sf/go/doc4857 (PDF version attached) and is really, really, small. We like to complete this document well before the Barcelona OGF in May, so your timely feedback is really, really welcome. And since the doc is small... Thanks, DavidG. PS: We will also ask to "end-user" relying parties via the IGTF and EUGridPMA announcement newsletter. -- 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 **

3 7

IGTF - CAOPS Agenda (Thursday 28th Feb, Starting at 08:30)
by Christos Kanellopoulos 25 Feb '08

25 Feb '08

WARNING: There is a change in the schedule and the workshop will start at 8:30 ! AGENDA: ---- HSM Vendor Sessions --- 08:30 - 09:00 nCipher 09:00 - 09:30 Kryptus 09:30 - 10:00 Aladdin 10:00 - 10:30 Safenet 10:30 - 10:45 Q & A 10:45 - 11:00 Coffee Break --- IGTF Session --- 11:00 - 11:30 Private Key Protection 11:30 - 11:45 Certificate Renewal 11:45 - 12:15 Higher Level CA Profile 12:15 - 13:15 Lunch --- CAOPS Session --- 13:15 - 13:30 Guidelines for Auditing CAs 13:30 - 14:00 Authentication Service Profile 14:00 - 14:30 Use Cases for Relying Party Enforced Namespace Constraints 14:30 - 14:45 CP/CPS model template 14:45 - 14:50 Election of new CAOPS co-chair 14:50 - 15:00 Coffee Break --- IGTF Session --- 15:00 - 15:20 BalticGrid CA 15:20 - 16:30 Robot Certificates 16:30 - 16:45 Coffee Break 16:45 - 17:00 OpenCA + PRQP (PKI Resource Query Protocol) 17:00 - 17:30 Identification in IGTF 17:30 - 18:00 Distribution process document 18:00 - 18:15 Discussion on SLCS (Revocation) -- Christos Kanellopoulos Grid Operations Center, Aristotle University of Thessaloniki University Campus, GR 541 24, Building 22D, Office 4'6B Tel. +302310998988 Fax. +302310994309 http://www.grid.auth.gr

1 0

Fwd: TAM is a deal done? Was: TAM as a new WG item?
by Alan Sill 15 Jan '08

15 Jan '08

TAM = Trust Anchor Management Do we want to weigh in as a related standards organization (or an opinionated party)? Thanks, Alan Begin forwarded message: > From: Russ Housley <housley(a)vigilsec.com> > Date: December 19, 2007 4:03:09 PM CST > To: "Denis Pinkas" <denis.pinkas(a)bull.net> > Cc: ietf-pkix(a)imc.org > Subject: Re: TAM is a deal done? Was: TAM as a new WG item? > > > Yes, and the IESG approval process includes a community review > similar to IETF Last Call as well as the proposed charter being > sent to several other SDOs to detect potential overlap. > > Russ > > At 06:34 AM 12/10/2007, Denis Pinkas wrote: > >> Russ, >> >> >There was a lot of support for adding this work item to PKIX, but >> the >> >proposed text for the rechartering of the WG has not been sent to >> the >> >IESG for approval yet. >> >> My understanding is the following: >> >> If TAM is supposed to become a PKIX work item, >> then a text for that new work item would need to be submitted to >> the PKIX WG. >> >> If TAM is supposed to become a WG, then a proposed text for the WG >> would need to be sent to the IESG for approval. >> >> Is this understanding correct ? >> >> Denis >> >> >Russ >> > >> > >> >At 01:57 AM 12/8/2007, Anders Rundgren wrote: >> > >> >>The following is dedicated to the folks who presumably will make >> TAM >> >>a PKIX WG item. >> >> >> >>Today "remote control" of devices like laptop computers and >> mobile phones >> >>is already a fact. For the latter there is a scheme known as >> OMA-DM which >> >>is used not only for distributing cryptographic keys, but >> software updates and >> >>"registry" settings. I don't really see that trust anchors differ >> >>from any other >> >>piece of information that an organization wants to securely >> maintain >> >>in their fleet >> >>of client computers. >> >> >> >>"Unmanaged" devices like consumer computers seems to be a white >> spot but >> >>IMO automatic software updates + various services that the >> browser vendors >> >>supply, essentially do what is technically feasible in assuring >> that >> >>the user is >> >>connecting to a credible site (the #1 problem on the Internet). >> >> >> >>thanks >> >>Anders Rundgren >> > >

1 0

Revised auditing documents
by Yoshio Tanaka 14 Dec '07

14 Dec '07

Dear all, Working with Matt, we have revised the auditing guidelines document. I also compared the TAGPMA spreadsheet and the auditing document. Here is the summary of the revision: - Added one auditing item (item# CA-(23)). - Moved item# CA-(30) to item# CA-(52). - Added Matt as a co-author. - Revised English. BTW, Christos gave us the following comment at the last OGF: The document should provide a generic framework for performing audits on Grid IdPs. We should remove any statements on the preferred answers for each question in the document. Actually, sections 1, 2, and 4 describe a generic framework. These sections are not profile-specific but common for all profiles. However, Section 3, "Auditing Checklist," is derived from and depend on the Classic AP. Section 3 should be different for the other profiles such as SLCS. Even so, should I modify profile-specific questions and descriptions to more generic descriptions? Any comments are appreciated. Regarding the comparison with the TAGPMA spreadsheet and the auditing document, here is the summary of the results: - One item in the spreadsheet was not in the auditing document. - new item #CA-(23) - Some items in the auditing document are not in the spreadsheet. - Most items are "SHOULD" statement. - Some of such items are newly added in Classic AP 4.1. - Item numbers which are not in the spreadsheet. - #CA-(14) - #CA-(21) - #CA-(31) - #CA-(39) - #CA-(43) - #CA-(44) - #CA-(45) - #CA-(49) - #CA-(59) - #RA-(4) - #RA-(8) Thanks, -- Yoshio Tanaka (yoshio.tanaka(a)aist.go.jp) http://ninf.apgrid.org/ http://www.apgridpma.org/

1 0