- caops-wg - lists.ogf.org

Update: Links and information on recent OGSA work on Basic Security Profile and Express Authentication Profile documents
by Alan Sill 11 Dec '07

11 Dec '07

The referenced documents continue to be discussed in the context of OGF's OGSA work group. Links are in the following meeting announcement. Please contact Hiro Kishimoto, Andreas Savva, Duane Merrill, Andrew Grimshaw, or send comments on the process to David Groep and Blair Dillaway (Security Area directors) if you wish. Meanwhile, I think that the CAOps and IGTF groups should familiarize themselves with these documents. Alan OGSA-WG teleconference: Basic Security Profile (and related documents and efforts) When: 9-10pm EST, 8-9am CST, 6-7pm PST, 11-12pm JST, 2-3pm UK The dial-in number for Monday; US: +1 718 3541071 (New York) or +1 408 9616509 (San Jose) UK: +44 (0)207 3655269 (London) Japan: +81 (0)3 3570 8225 (Tokyo) Germany: +49 (0)69 50070802 (Frankfurt) Switzerland: +41 (0)1 8009574 (Zurich) PIN: 4371991 See more information: - https://forge.gridforum.org/sf/go/wiki1477 Screen share service: URL: http://ogsa.glance.net/?key=1206 Usage: https://forge.gridforum.org/sf/go/wiki1584 Note: ** OGF IPR POLICY APPLIES ** http://www.ogf.org/About/abt_policies.php 1) Early discussion Social study notification - https://forge.gridforum.org/sf/go/wiki1717 Note taker assignment - https://forge.gridforum.org/sf/go/wiki1848 Roll call Agenda bashing 2) Minutes approval and AI review (see the bottom of this agenda) Minutes approval Nov. 19: Waiting for minutes (Mark Morgan) Nov. 26: https://forge.gridforum.org/sf/go/doc14942?nav=1 Action Item review - http://forge.ogf.org/short/ogsa-wg/ailist 2) OGSA Express AuthN profiles (Duane) - Review comments received during final call of the two profiles Secure Addressing - https://forge.ogf.org/sf/go/doc14938 (doc) - http://forge.ogf.org/short/ogsa-wg/spsa (tracker) Secure Communication - https://forge.ogf.org/sf/go/doc14937 (doc) - http://forge.ogf.org/short/ogsa-wg/spsc (tracker) - Review updated version of the OGSA Basic Profile (to be uploaded before the call) https://forge.ogf.org/sf/go/doc14940 and comments posted to the list View your event at http://www.google.com/calendar/event? action=VIEW&eid=ZWYxbGJscGVzZWgwYXFodTJzaXRmMzF2NzQgb2dzYS13Z0BvZ2Yub3Jn &tok=MTcjb2dzYS53Z0BnbWFpbC5jb202ODEyZjgxZWU5OGE0Yjc0MzY1Nzg2YTFhODg2MjM 1OTI5MmM2ZTNm&ctz=America%2FChicago&hl=en. 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

New version of Audit Guidelines document
by Christos Kanellopoulos 03 Dec '07

03 Dec '07

Hi all, this morning Yoshio uploaded a new version (1.0b4) of the "Guidelines for auditing Grid CAs" document on GridForge [1]. This document is considered to be in it's final stages, so please do read the document and comment on it. For those in Seattle, see you in a few minutes at the CAOPS session [1]: https://forge.gridforum.org/sf/go/doc4858 -- 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

4 4

Grid Certificate Profile final version 0.25
by David Groep 08 Nov '07

08 Nov '07

Dear all, The latest version of the Grid Certificate Profile document, addressing the last open issue raised inthe public comments on IE7 -- based on Chrisots experimental result. The last version (0.25/8NOV) is now available on GridForge at: https://forge.gridforum.org/sf/go/doc13741 (PDF) https://forge.gridforum.org/sf/go/doc13742 (MS Word) Christos or Darcy can now start the WG last call process of one week and get it published. 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

Minutes from CAOPS Session at OGF 21 and next teleconference
by Christos Kanellopoulos 07 Nov '07

07 Nov '07

Dear all, the minutes from the CAOPS session that took place on 16.10.07 during OGF 21 have been uploaded on GridForge [1]. We are planning to have a CAOPS slot with [tele|video]conference at the next TAGPMA meeting that will take place in Santiago, Chile on 7th and 8th November. I will send more details when we finalize the arrangements. Regards, Christos [1]: https://forge.ogf.org/sf/go/doc14897?nav=1

2 2

Draft minutes from CAOPS Session on 16.10
by Christos Kanellopoulos 22 Oct '07

22 Oct '07

Dear all, Find below a draft version of the minutes from the CAOPS session on 16.10.2007. Please review them and send any comment to the list. On Wednesday 23.10.2007 I will upload it on GridForge. -C. CAOPS Session OGF 21 16.10.2007 ------------------------------------- Note Takers: Licia Florio, Christos Kanellopoulos ------------------------------------- David Groep: Grid Certificate Profile ..................................... x The document has finished the public comment period as of October 8. A1: David Groep to send email to the CAOPS mailing list with answers to the comments A2: Christos Kanellopoulos to test IE7 with CA certificate that has been reissued A3: By Nov 6 a new version of the document should be available that will address all the comments. There is going to be one week afterwards for group comments and then it will be pushed to the editor's queue. Yoshio Tanaka: Audit Document .............................. x New version of the document was uploaded to GridForge - Christos Kanellopoulos: 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 - Mike Helm: This look very much like the spreadsheet that is being used within TAGPMA for CA accreditation. A4: Mike Helm to send the spreadsheet template at the CAOPS mailing lists A5: By end of November a new version of the document should be ready. Christos Kanellopoulos to help with the editing. David Groep: Name Constraints .............................. x Still waiting for the replies from the people at OGF 20 CAOPS session x The implementation details will be stripped off from the document and it will be focused on the requirements for providing namespace constraints at the policy lave. - David Chadwick: What we want to achieve with this document can be found in the initial X.509 specs that got completely twisted around '97. This is expected to be changed in the new versions of the X.509 document - David Chadwick: Wild-card matching, as it is expressed in the document, did not exist in the X.500 specs. Subtree matching was part of the specs though - David Groep: We've added wild-card matching exactly to perform subtree matching A6: David Chadwick to send details at the CAOPS mailing list A7: David Groep to update the document with reference to the documents that David Chadwick will (if and where necessary) - Rachana Ananthakrishna: Globus will implement Namespace policies within 2008 Q1. Going to use the current policy language - David Groep: suggested that Globus eliminates the 1024 char limitation. A8: New version of the document by late December Mike Helm: OCSP Requirements for Grids ...................................... x The document was derailed from its initial scope during its development in the past two years. x We should revisit the document focusing on the Trusted Responder concept. x There is a lot of useful information within the document that could be used in future documents. x There is some work done in IETF that supersedes the document. However it is worth to look at Trusted Responder. Seems like the current trend is to use CRLs or short-lived certificates. - Mike Helm: Users seem to be happy with the current CRL solution. Even when they face problems, they prefer to (over) engineer around them. - Rachana Ananthakrishna: In order for Globus to start working on an implementation, they need to have specific requirements from the users A9: Mike Helm: New draft document by early January

2 3

New version GridCertProfile (0.23) with Public Comments addressed
by David Groep 17 Oct '07

17 Oct '07

Dear all, I've gone through the public comments and the results from our group discussion yesterday, and generated a new version of the GridCertProfile document (0.23) with virtually all of the changes incorporated. The list of changes is below, and the attached PDF document highlights the changes. The one open issue concerns re-testing Internet Explorer 7 with respect to the root-cert-import behaviour. In order to make a consistent document, I've now just stated "tested in versions up to and including v6". New versions are now on GridForge (doc and pdf), with a summary of all changes below. The slides used for the presentation are also on GridForge, in the CAOPS-WG document area -> Meeting Materials -> OGF21. One last question to Vivek Kaushik (or Yoshio): is there a public URL for the basicConstraints white paper? I've now put in a reference to the public comments ([Netrust2007]), but having a better URL would be nice (as we agreed to reference this excellent document in its entirety) Best, DavidG. Click Here Now: https://forge.gridforum.org/sf/go/projects.caops-wg/docman.root.working_dra… Comments addressed ------------------ Vladimir Dimitrov: we're sorry, but already changed the structure of the document twice (first converting all footnotes to in-line text, then realizing that it became unreadable, and converting everything to footnotes again :-) The group felt that leaving them out would devalue the document, but at the same time its not normative enough to warrant bing in the main text body. So, although there are a lot of them, we agreed to keep the footnotes. Yoshio Tanaka and Vivek Kaushik: The group realized the complexity of the issue and highly appreciates the white paper. We dropped the "MUST" to a "SHOULD" in 2.4.1, and added a summary of the white paper as a footnote. Since the white paper contains a lot of very valuable text, we agreed to just reference the entire paper. A better reference URL would be nice, though. Thanks for this in-depth analysis! Reimer: Updated the text in 3.3.2, making dataEncipherment a MUST, and adding a footnote with Reimer's analysis Paschalis: The new footnote text starts of with: "In case the country (C) is used as part of the varying part of the subject distinguished name (i.e., it is not part of the constant DN prefix that defines the issuing name space), the ..." ChristosT: In 3.3.8 added "It MUST return the CRL in DER encoded form". BobCowles: The testing of IE7 is not yet done, but I've qualified all mention of browsers with either a testing date ("Spring 2007"), or a version number ("up to and including version 6"). We can update than once IE7 has been tested. Blair: Section 2.2 now reads: "... The current most secure hash function that is supported by the entire target audience of the CA SHOULD be used, but at least SHA-1 or better MUST be used {footnote: Note that modern hashes, such as SHA-256, are not supported by the majority of OpenSSL versions in use, so SHA1 is the only available value as of time of writing.}" On non-repudation (3.3.2): "It SHOULD NOT be set in other end-entity certificates either, as the claims made by this keyUsage are ill-defined or non-verifiable, and its interpretation by clients unclear. If it is set regardless, its assertion in personal end-entity certificates SHOULD be limited to special purposes. " In 4.2 on ECC signatures: "... As other digital signature and key exchange algorithms are introduced, such as elliptic curve mechanisms, their use should be considered for new certificates provided the entire target audience is capable of dealing with such mechanisms {footnote: As of time of writing, only RSA algorithms are sufficiently supported in clients. It is thus NOT advisable to select non-RSA algorithms.}." -- 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

Subtree specifications
by David Chadwick 16 Oct '07

16 Oct '07

Here is the definition of X.500 subtrees from X.501 section 12.3. This is a general mechanism for specifying any sort of DN namespace which might be of use to you for specifying your signing policies. If you want a layman's explanation of this mechanism there is a section in my book (2.12.1 The Subtree Specification Attribute) which can be found at http://sec.cs.kent.ac.uk/x500book/Chapter.2/Chapter2.htm#2.9%20THE%20DIRECT… There are also a few examples at http://sec.cs.kent.ac.uk/x500book/Chapter.2/fig2-9.gif from which you can see how the c=ch, o=cern problem could easily be dealt with using subtree specification. As a footnote, subtree specifications were originally in X.509 name constraints, but were replaced in 1996 by GeneralSubtrees just before the standard was released, without people fully appreciating what had been done. 12.3 Subtrees 12.3.1 Overview A subtree is a collection of object and alias entries situated at the vertices of a tree. Subtrees do not contain subentries. The prefix "sub", in subtree, emphasizes that the base (or root) vertex of this tree is usually subordinate to the root of the DIT. A subtree begins at some vertex and extends to some identifiable lower boundary, possibly extending to leaves. A subtree is always defined within a context which implicitly bounds the subtree. For example, the vertex and lower boundaries of a subtree defining a replicated area are bounded by a naming context. Similarly, the scope of a subtree defining a specific administrative area is limited to the context of an enclosing autonomous administrative area. 12.3.2 Subtree specification Subtree specification is the definition of a subset of the entries below a specified vertex which forms the base of the subtree or subtree refinement. The vertex and/or the lower boundary of the subtree may be implicitly specified, in which case they are determined by the context within which the subtree is used. The vertex and/or the lower boundary may be explicitly specified using the mechanism specified in this clause. This mechanism may also be used to specify subtree refinements which are not true tree structures. NOTE – The topological concept of a (sub)tree is useful in considering such specifications, although a particular specification may determine a collection of entries that are not located at the vertices of a single (sub)tree. The term subtree refinement is preferred when the entries of the collection are not so located. Specification of a subtree consists of three optional elements of specification which identify the base of the subtree, and then reduce the collection of subordinate entries. These elements of specification are: a) Base – The root vertex of the subtree or subtree refinement produced by the evaluation of a subtree specification; b) Chop – A set of assertions concerning the names of the subordinate entries; and c) Specification filter – A proper subset of the assertive capability of a filter applied to the subordinates. The specification of a subtree or subtree refinement may be represented by the following ASN.1 type: SubtreeSpecification ::= SEQUENCE { base [0] LocalName DEFAULT { }, COMPONENTS OF ChopSpecification, specificationFilter [4] Refinement OPTIONAL } -- empty sequence specifies whole administrative area The three components of this sequence correspond to the three specification elements identified above. Where a value of SubtreeSpecification identifies a collection of entries that are located at the vertices of a single subtree, the collection is termed a subtree, otherwise the collection is termed a subtree refinement. The SubtreeSpecification type provides a general purpose mechanism for the specification of subtrees and subtree refinements. Any particular use of this mechanism defines the specific semantics of precisely what is specified and may impose limitations or constraints on the components of SubtreeSpecification. When each of the components of SubtreeSpecification is absent (i.e. a value of type SubtreeSpecification which is an empty sequence, {}), the subtree so specified is implicitly determined by the context within which the SubtreeSpecification is used. These terms are illustrated in Figure 9, for the case where subtrees are deployed within the context of administrative areas. 12.3.3 Base The base component of SubtreeSpecification represents the root vertex of the subtree or subtree refinement. This may be an entry which is subordinate to the root vertex of the identified scope or may be the root vertex of the identified scope itself (the default). Figure 9 – Specification of Subtrees and Subtree Refinements within the context of Administrative Areas The relative name of the root vertex of the subtree with respect to the root vertex of the identified scope is a value of typeLocalName: LocalName ::= RDNSequence Note that the root vertex of the identified scope and the root vertex of the subtree coincide when LocalName is omitted from SubtreeSpecification. RDNs used to name the root vertex of the subtree shall be primary RDNs. 12.3.4 Chop Specification The ChopSpecification component consists of a set of assertions concerning the names of the subordinates of a base. It consists of a value of type ChopSpecification: ChopSpecification ::= SEQUENCE { specificExclusions [1] SET SIZE (1..MAX) OF CHOICE { chopBefore [0] LocalName, chopAfter [1] LocalName } OPTIONAL, minimum [2] BaseDistance DEFAULT 0, maximum [3] BaseDistance OPTIONAL } This type is intended to permit the specification of a tree structure (or subset thereof) starting at the base by two methods, specific exclusions and base distance. Where any attribute in an RDN in chopBefore or chopAfter has multiple distinguished values differentiated by context, the primary distinguished value shall be used as the value in the RDN in LocalName. 12.3.4.1 Specific Exclusions The specificExclusions component has two forms, chopBefore and chopAfter, which may be used individually or in combination. The chopBefore component defines a list of exclusions, each in terms of some limit point which is to be excluded, along with its subordinates, from the subtree or subtree refinement. The limit points are the entries identified by a LocalName, relative to the base. The chopAfter component defines a list of exclusions, each in terms of some limit point whose subordinates are to be excluded from the subtree or subtree refinement. The limit points are the entries identified by a LocalName, relative to the base. 12.3.4.2 Minimum and Maximum These components allow exclusion of all entries that are superior to entries that are minimum RDN arcs below the base as well as entries which are subordinate to entries that are maximum RDN arcs below the base. These distances are expressed by values of the type BaseDistance: BaseDistance ::= INTEGER (0..MAX) For the purpose of chop specifications, a compound entry is counted as a single entry. In a compound entry, all family members are counted as having the same base distance as the ancestor, since they are all part of the same logical entry. A value of minimum equal to zero (the default), corresponds to the base. An absent maximum component indicates that no lower limit should be imposed on the subtree or subtree refinement. 12.3.5 Specification Filter The specificationFilter component consists of a proper subset of the assertive capability of a filter (see ITU-T Rec. X.511 | ISO/IEC 9594-3) applied to the subordinates of a base. Only entries for which the filter evaluates to true are included in the resulting subtree refinement. It consists of a value of type Refinement: Refinement ::= CHOICE { item [0] OBJECT-CLASS.&id, and [1] SET OF Refinement, or [2] SET OF Refinement, not [3] Refinement } A Refinement evaluates to TRUE as if it were a filter making an equality assertion regarding values of the attribute type objectClass only. If a family member is excluded from a subtree by this specification, all its subordinate family members are also excluded. -- ***************************************************************** David W. Chadwick, BSc PhD Professor of Information Systems Security The Computing Laboratory, University of Kent, Canterbury, CT2 7NF Skype Name: davidwchadwick Tel: +44 1227 82 3221 Fax +44 1227 762 811 Mobile: +44 77 96 44 7184 Email: D.W.Chadwick(a)kent.ac.uk Home Page: http://www.cs.kent.ac.uk/people/staff/dwc8/index.html Research Web site: http://www.cs.kent.ac.uk/research/groups/iss/index.html Entrust key validation string: MLJ9-DU5T-HV8J PGP Key ID is 0xBC238DE5 *****************************************************************

1 0

Reminder: Public comment period ending for Grid Certificate Profile Oct 8
by Alan Sill 03 Oct '07

03 Oct '07

The GCP document V0.22 is near the end of its public comment period at: http://www.ogf.org/Public_Comment_Docs/Documents/Aug-2007/draft-ogf- caops-grid-certificate-profile-v22.pdf or for convenience http://tinyurl.com/2f5x83 Make or view comments at http://www.ogf.org/gf/docs/?public_comment 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

Fwd: Protocol Action: 'Server-based Certificate Validation Protocol (SCVP)' to Proposed Standard
by Alan Sill 26 Sep '07

26 Sep '07

FYI. Given problems we have seen in path validation and certificate revocation enforcement policies and practical features in grid software implementations, it might prove worthwhile to investigate and study this document, which I believe is now up for the RFC process. I'm not sure where discussion of this topic should take place. OGF? Yours, Alan Begin forwarded message: > From: The IESG <iesg-secretary(a)ietf.org> > Date: September 25, 2007 2:06:25 PM CDT > To: IETF-Announce <ietf-announce(a)ietf.org> > Cc: Internet Architecture Board <iab(a)iab.org>, RFC Editor <rfc- > editor(a)rfc-editor.org>, pkix mailing list <ietf-pkix(a)imc.org>, pkix > chair <pkix-chairs(a)tools.ietf.org> > Subject: Protocol Action: 'Server-based Certificate Validation > Protocol (SCVP)' to Proposed Standard > > > The IESG has approved the following document: > > - 'Server-based Certificate Validation Protocol (SCVP) ' > <draft-ietf-pkix-scvp-33.txt> as a Proposed Standard > > This document is the product of the Public-Key Infrastructure (X.509) > Working Group. > > The IESG contact persons are Sam Hartman and Tim Polk. > > A URL of this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-pkix-scvp-33.txt > > Technical Summary > > SCVP allows a client to delegate certificate path construction and > certificate path validation to a server. The path construction or > validation (e.g., making sure that none of the certificates in the > path are revoked) is performed according to a validation policy, > which contains one or more trust anchors. It allows simplification > of client implementations and use of a set of predefined validation > policies. > > Working Group Summary > > The working group expressed consensus to advance the draft to > Proposed Standard. Two participants raised concerns that this > protocol did not meet all the requirements of RFC 3379 and > introduced > > significant new features. The working group investigated this > claim > and concluded that after minor revisions this document does meet > the > requirements and does not introduce significant new features. > > Protocol Quality > > This document has been reviewed by members of the ietf-pkix(a)imc.org > mailing list and by the working group chairs. The protocol seems > reasonable. This has been reviewed by Sam Hartman for the IESG. > 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

The Grid Certificate Profile document has entered the public comment period
by Christos Kanellopoulos 21 Aug '07

21 Aug '07

Dear All, The Grid Certificate Profile document is finally available for public comments [1]. The public comment period will last until October 8, 2007. This document describes the possibilities and limitations for attributes and extensions in X.509 certificates that are usable by grid infrastructures and defines the requirements for both CA and end- entity certificates. Please review the document and make your comments at [2]. Best regards, Christos Kanellopoulos OGF CAOPS Co-chair [1]: http://www.ogf.org/gf/docs/?public_comment [2]: https://forge.gridforum.org/sf/discussion/do/listTopics/ projects.ggf-editor/discussion.cp_grid_certificate_profile

1 0