November 2006 - caops-wg

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

Grid Certificate Profile document update
by David Groep 30 Nov '06

30 Nov '06

Dear all, I've uploaded an updated version of the Grid Certificate Profile document, clearing up confusion on the use of the Country (C) attribute in issuer and subject distinguished names. It's interpretation for the issuer and subject should be considered differently. The new text in v0.17 The new version reads (in the explanatory footnotes), for issuer (CA) DNs: "If a Country (C) component is included in the issuer DN, it SHOULD reflect the country in which the issuer is based." and for subject end-entity DNs: "The country (C) asserted in the subject DN of an end-entity certificate SHOULD correspond the home country of the end-entity, and thus does not necessarily reflect and is not necessarily the same as the country in which the CA is operating, or the country code in the issuer DN. Therefore, in such cases the Country attribute should not be part of a unique subject DN naming prefix." The new version is on GridForge: https://forge.gridforum.org/sf/go/doc13741 (PDF) https://forge.gridforum.org/sf/go/doc13742 (MS Word) with the comment: new version 0.17: Clarified use of Country(C) attribute in subject and issuer names 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

CAOPS-WG Teleconference
by Darcy Quesnel 30 Nov '06

30 Nov '06

I know that this is very late notice, and I apologize. I thought that I'd telepathically communicated this already out to everyone. We've reserved an hour slot out of the TAGPMA meeting for discussion of CAOPS business. We'll piggyback on ESnet conferencing facilities as usual. Details below. DATE Thursday, 30 November, 13:30 CT (Austin, TX Time) http://indico.na-df.rnp.br/indico/contributionDisplay.py?contribId=19&sessi… AGENDA Documents that should be in the editor queue Documents still in writers hands New Documents? (I'll fill in the agenda with specifics...) CONTACT GDS 0011349884483 or ESNet 884483 or phone 1-510-883-7860 884483# Please join us if you can Darcy

1 1

on-hold cert revocation ("suspend") to disappear?
by Mike Helm 27 Nov '06

27 Nov '06

------- Forwarded Message >From SRS0=c649ea436bb7f94904d7eb80db940951b33abd3e=167=mail.imc.org=owner-ietf-pkix(a)es.net Mon Nov 27 12:55:57 2006 Message-ID: <456B47D1.2050405(a)cs.tcd.ie> Date: Mon, 27 Nov 2006 20:17:21 +0000 From: Stephen Farrell <stephen.farrell(a)cs.tcd.ie> User-Agent: Thunderbird 1.5.0.8 (Windows/20061025) MIME-Version: 1.0 To: Russ Housley <housley(a)vigilsec.com> CC: ietf-pkix(a)imc.org Subject: Re: on-hold certificates in CRLs References: <a7d7da420611270753s70be3596qebe24ea9f3aff6b(a)mail.gmail.com> <7.0.0.16.2.20061127140855.07404318(a)vigilsec.com> In-Reply-To: <7.0.0.16.2.20061127140855.07404318(a)vigilsec.com> List-ID: <ietf-pkix.imc.org> Bit of a late change, but a good one, S. Russ Housley wrote: > > I would like to take this opportunity to advocate the deprecation of "on > hold" altogether. No good can come from it, as been discussed so many > times on this list. > > I can live with the current text, but I think it would be far better to > say that the "on hold" status MUST NOT be used by CAs conforming to > 3280bis. > > Russ > > At 10:53 AM 11/27/2006, Carlos González-Cadenas wrote: >> Hi, >> >> Suppose we have the following ordered temporal sequence >> >> t1 - a certificate with serial "S1" is issued by a CA >> t2 - the certificate is put on-hold by the CA (i.e. in order to >> investigate a possible compromise) >> t3 - a full CRL is issued by the CA >> t4 - the investigation carried by the CA ends up in no compromise, and >> the CA makes the certificate valid again >> t5 - a delta CRL is issued by the CA >> t6 - a full CRL is issued by the CA >> >> Does the CRL logs all the revocation-related events for the >> certificate with serial S1?. >> >> If we assume that all the events are logged, then the CRLs contents >> (for certificate with serial S1) should be: >> >> full CRL issued at t3: contains an entry for S1 at t3 with reason code >> on-hold >> delta CRL issued at t5: contains the previous full CRL entry plus an >> entry for S1 at t5 with reason code removeFromCRL >> full CRL issued at t6: contains both previous entries (so you know >> the on-hold period for the certificate) (maybe this is violating >> RFC3280 as removeFromCRL is only applicable for deltaCRLs??) >> >> If we assume that NOT all events are logged, CRLs issued >=T6 don't >> include revocation entries for certificate S1, that is >> >> full CRL issued at t3: contains an entry for S1 at t3 with reason code >> on-hold >> delta CRL issued at t5: contains the previous full CRL entry plus an >> entry for S1 at t5 with reason code removeFromCRL >> full CRL issued at t6: contains NO entry for S1 >> >> Which is the normative (RFC3280) behaviour for that case?. Is there >> any change between RFC3280 and RFC3280bis about these issues? >> >> Note that if the second case is the normative behaviour IMHO there's >> no way (except storing the CRLs between t2 and the next CRL appeared >> after t4) for a relying party (verifying the certificate in or after >> t6) to know the certificate status between t2 and t4. >> >> Many thanks in advance, >> >> Carlos >> > > ------- End of Forwarded Message

1 0

Extended Validation certificates
by Mike Helm 15 Nov '06

15 Nov '06

>From the CA/Browser forum, which apparently put up a website recently. Objectives: http://cabforum.org/objectives.html "EV SSL Certificates establish online businesses identity by confirming the certificate holder's legal and physical existence." (See link - emphasis on phishing/id fraud prevention, somehow) Vetting process: http://cabforum.org/vetting.html "The Extended Validation (EV) SSL vetting process will validate the requestor's domain control and verify the requesting entity's legal existence and identity:" (see link)

1 1

Topical OGF Levels of Assurance (LoAs) BoF and activity initiative
by David Groep 15 Nov '06

15 Nov '06

Dear all, The OGF Security Area would like to draw your attention to an initiative addressing topics around the concept of Levels of Assurance. We know or expect that at least quite a few of you are interested in this topic, and thus are likely to either participate and have an opinion on this... An initial description of the activity and possible directions are described below. Please note that this will be a topical activity BoF, and is not aimed to be a charter BoF or to necessarily create a new group. If there is sufficient momentum to address this topic (also) in the OGF context, we can subsequently discuss the organisational embedding in an existing or new group. So, if you are interested, please participate via the security area mailing list or the gforge Wiki and forum, whose URLs are listed below. A BoF session to discuss this activity will be organised during OGF19 (to be held in North Carolina on January 29 - February 2, 2007). You are very warmly invited to attend this event, which will be full of new activities in the security area. Best regards, Blair Dillaway and David Groep, (OGF Security ADs) Topical BoF on Levels of Assurance (LoAs) ----------------------------------------- Ideas around "Levels of Assurance" have been receiving more and more attention, with the advance of federations and Authentication and Authorization infrastructures. "LoA is defined as the strength of authentication required for a service provider to be assured that a resource access is only granted to users whose identities have been verified. It reflects the degree of confidence in an authentication process used to establish the identity of an entity (an individual or a software component) to whom the credential was issued, and the degree of confidence that the entity using the credential is indeed the entity that the credential was issued to." Ning Zhang of Manchester University has taken the initiative to bring up the discussion on this activity in the OGF context. Examples of questions that this activity could address are: - What are the existing definitions of LoA suited to Grid or VO environment? - How to apply LoA to safeguard Grid services/resources? - Are some onerous registration requirements or special condition stipulations due to perceived inadequacies in the strength of authentication? - Are there any limitations in terms of user accessibility, scalability and interoperability? The activity can include discussion on how operational procedures affect LoA, how the various parameters and factors influence the overall LoA value in grid/VO environments, and come up with recommendations on how these factors can be taken into account. The purpose here is to consult, and to seek comments and feedbacks from, the communities concerned (including service providers, from e-Science, e-Business and e-Gov) on their views on the definition and applications of LoA in achieving fine-grained access control. Everyone interested in such an activity is extremely welcome to attend this activity BoF session. If there is sufficient interest within OGF, the BoF can also discuss how the activity is best embedded in the OGF organisation; it is not necessarily the aim of this BoF to result in a new research or working group. More information: Security Area Wiki: https://forge.gridforum.org/sf/wiki/do/viewPage/projects.sec/wiki/LoAInitia… Document "e-Infrastructure Security: Levels of Assurance" https://forge.gridforum.org/sf/sfmain/do/downloadAttachment/projects.sec/wi… Discussion forum: https://forge.gridforum.org/sf/discussion/do/listTopics/projects.sec/discus… -- 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

List invitation: OGSA-AuthN-BoF for grid services authentication issues
by Alan Sill 08 Nov '06

08 Nov '06

This is the last in a series of messages intended to announce a requested Birds-of-a-Feather session (BoF) at the Open Grid Forum OGF-19 meeting for discussion of Open Grid Services Architecture Authentication topics and activities. The list and its associated BoF are intended to carry out the steps for formation of an OGSA- AuthN work group. This message is being sent out widely to call your attention to the existence of a mailing list specific to this purpose. You may subscribe to the ogsa-authn-bof(a)ogf.org mailing list by sending a message to me or to David Groep <davidg(a)nikhef.nl> , or by visiting the following page: http://www.ogf.org/mailman/listinfo/ogsa-authn-bof Your participation is appreciated. This announcement will be sent to several relevant lists and people to extend the invitation as broadly as possible, but subsequent communication about the BoF will proceed through the above list. Subscription to the above list will be your method to ensure involvement in this process. Best, Alan Sill, Ph.D TIGRE Senior Scientist High Performance Computing Center 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

OGSA-AuthN-WG charter effort: the Seven Questions
by Alan Sill 06 Nov '06

06 Nov '06

Dear colleagues, Apologies if you are getting these messages more than once due to cross-posting. Once the OGSA-AuthN work group is set up, it will have its own mailing list to which you will be able to subscribe if it is of interest, so that symptom will disappear soon. As a reminder, here are the answers that were presented to the OGSA- WG in response to the standard "seven questions" asked as part of the process of setting up a new group. Comments with respect to the authentication direction to be pursued by this group are welcome and recruited. Anything specific to the Birds-of-a-Feather session we are organizing on this topic for OGF-19 in North Carolina at the end of January is also welcome; we hope this will be a productive work group and BoF session. Alan Begin forwarded message: > From: Alan Sill <Alan.Sill(a)ttu.edu> > Date: October 26, 2006 9:24:27 AM CDT > To: Hiro Kishimoto <hiro.kishimoto(a)jp.fujitsu.com> > Cc: Alan Sill <Alan.Sill(a)ttu.edu>, ogsa-wg WG <ogsa-wg(a)ggf.org>, > David Groep <davidg(a)nikhef.nl>, Blair Dillaway <blaird(a)microsoft.com> > Subject: OGSA-AuthN-WG charter effort: the Seven Questions > > > On Oct 23, 2006, at 9:29 PM, Hiro Kishimoto wrote: > >> The Seven Questions >> >> 1. Is the scope of the proposed group sufficiently focused? > > The scope of the proposed group is strictly limited to > authentication technologies for use within grid services > architectures. As such, I believe it is sufficiently focused, > although the relation to corresponding activities in authorization > and in the activities of other work groups is important and clear. > >> 2. Are the topics that the group plans to address clear and >> relevant for >> the Grid research, development, industrial, implementation, and/or >> application user community? > > Authentication is a key security step in any chain of grid services > usage. Up to now, most grid applications have either used no > security (for testing purposes), a limited and often self-signed > configuration again mostly for testing purposes, or have had to > rely on pure deployment of X.509 technology infrastructures. Some > extensive community practice has grown up in the academic > community, especially with regard to deployment at and between the > large-scale national laboratories and universities on an > international basis, and siloed implementations exist within > industry, as well as some federal non-laboratory organizations. It > is a goal of this work group to document current practice and to > extend the standards basis for development of AuthN technologies > within all of the above communities. Another significant output > will be recommendations for future work in this area, taking into > account all relevant technological development in this area. > Interoperability will also be an important factor, of course. > >> 3. Will the formation of the group foster (consensus–based) work that >> would not be done otherwise? > > Yes. Several conversations on related technologies have sprung up > naturally within segments of the affected communities, as described > above. The existence of an OGSA AuthN work group would allow > concentration and coordination of these conversations and > recommendations in a context that is explicitly connected to the > overall OGSA standards effort. > >> 4. Do the group’s activities overlap inappropriately with those of >> another OGF group or to a group active in another organization >> such as >> IETF or W3C? Has the relationship, if any, to the Open Grid Services >> Architecture (OGSA) been determined? > > There is no other effort exclusively devoted to this task within > OGSA. Polling of the membership of other groups active in the > authentication and authorization areas has resulted in strong > support for the idea of a specific OGSA effort. Groups that have > been polled include the following: > > CA-Ops: Within the current OGF structure, this group is defined as > an operations group responsible for Certificate Authority standards > and participation. It is the parent body (in a historical sense) > of the IGTF described below. > > International Grid Trust Federation (IGTF): an independent body > comprised of three regional policy management authorities (PMAs) > with membership consisting of grid certificate authority providers > and (in some cases) relying parties with an interest in the > operational policies and procedures of the CA providers. The > primary mechanism of operation of the IGTF is through the > development and common accreditation of CAs against specific, > detailed CP/CPS statements within the context of Authentication > Profiles (APs); APs exist for "classic PKI" deployments as well as > short-lived credential and experimental services. Within the > context of the IGTF PMA charters, interest has been growing in > improving the variety and accessibility of grid authentication > methods while retaining the ability to work with existing grid > deployments with high security. > > OGSA-AuthZ: This group is focused on authorization technologies. A > variety of useful documents has been successfully produced through > various incarnations of this group to date. Its membership is > supportive of a corresponding OGSA-AuthN effort. > > Shibboleth for Grids BoF: This BoF was held at GGF-18 and its > activities are documented at the URL http://grid.ncsa.uiuc.edu/ > events/ggf18-shib-bof/ for reference. Although focused primarily > on authorization, Shibboleth technologies are consumers of > authentication information and a great deal of activity is being > devoted to understanding the interaction between Shibboleth and the > needs of grids. The participants in the BoF mailing list are > strongly supportive of an OGSA-AuthN effort. > >> 5. Are there sufficient interest and expertise in the group’s topic, >> with at least several people willing to expend the effort that is >> likely >> to produce significant results over time? > > Yes. A significant short-term effort should be exerted to identify > authors of the proposed documents and a co-chair in the near future. > >> 6. Does a base of interested consumers (e.g., application developers, >> Grid system implementers, industry partners, end-users) appear to >> exist >> for the planned work? > > Yes. The BoF planned for the next OGF meeting should provide > opportunities for organization of work in this area. > >> 7. Does the OGF have a reasonable role to play in the >> determination of >> the technology? > > Yes, as described above. One specific output of the group that > would be made possible by the OGF will be production of an OGF > document with recommended standards for OGSA-AUthN. > > Respectfully submitted, 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

Planning attendance for OGF-19 BoF: OGSA-AuthN WG
by Alan Sill 06 Nov '06

06 Nov '06

I am working on the session form for OGF-19 for the BoF we would like to have on the OGSA-AuthN charter to set its initial direction and specific deliverables. Anyone who would like to give a talk, keeping in mind that the session is short, is welcome. A draft charter in short form for this group is at: http://www.ggf.org/gf/group_info/charter.php?review&group=OGSA-AuthN-WG and other related documents will be published shortly. If you are interested in working on the topic of authentication for OGSA grid services, please do contact me. All interested parties are welcome to this effort so we can keep grid services architecture authentication on a good design basis and in touch with the best current and future practices in the field. I am also specifically recruiting help in the form of co-conveners to help with the leadership of this work group. Please also welcome our new OGF Security Area Directors Blair Dillaway and David Groep, and give them the benefit of your communication on various related topics, and every possible cooperation, suggestions, work on documents and standards, etc. If you are going to be in North Carolina for the OGF-19 conference and are interested in these topics, I would like to hear from you. Best, 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

Certificate Profile document updated (to v0.14)
by David Groep 01 Nov '06

01 Nov '06

Dear all, With the comments I received on the Grid Certificate Profile document from all of you during OGF18, the remote conf session earlier this month, and via mail, I've updated the Grid Cert Profile document to version 0.14. I've uploaded it to the CAOPS GridForge in both .doc and PDF format: http://forge.ggf.org/sf/docman/do/downloadDocument/projects.caops-wg/docman… This version is a major overhaul, where all the meta-comments and general pondering have been put in foot notes, and only the actual guideline text and the SHOULDs and MUSTs are in-line. The actual recommendations have not changed, but it should be clearer to read. Please have a look and comment (and propose text for the few missing elements marked in yellow). Thanks a lot for all your contributions! 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 **

2 4