RE: AuthN CA middleware support [Fwd: [caops-wg] Draft Agenda]
David, one more comment. If you're referring to the NIST document, it may be helpful to provide a link to this overview presentation: http://www.csrc.nist.gov/pki/BioandEAuth/Presentations/Wednesday,%20March%20... We would roughly be on Level 2 with the Grid; worth thinking whether we ever need Level 3 (eg for biomed), and if so, how to get there on the Grid. Regardless of whether "we" build a validation authority or add to the middleware validation, someone still needs to build the validation code, and the language to specify what you want. The language should allow for checking not just policy oid but also key size and individual extensions, etc, IMHO. And be simple enough that anyone can implement an acceptance policy - no XML, no binary encodings. And as I mentioned earlier, if we add it to the middleware, it is best to go as far upstream as possible - OpenSSL ideally, or Globus. Document may need tweaking depending on where we go. Cheers, --jens -----Original Message----- From: owner-caops-wg@ggf.org [mailto:owner-caops-wg@ggf.org]On Behalf Of David Groep Sent: 10 May 2006 05:23 To: CAOPS-WG; 'igtf-general' Subject: AuthN CA middleware support [Fwd: [caops-wg] Draft Agenda] Dear all, For the discussion on Friday's IGTF session, following up from the discussion we had at the last TAGPMA F2F meeting, the following document is the /very first and preliminary draft/ of the 'Request to MW Providers' Your comments are more then welcome (also if you're not physically at GGF). Regards, DavidG.
Would you like to discuss this in the IGTF session at GGF for a few minutes? I think it would make a great topic of discussion. And anyways I've pencilled you in.
Darcy
David Groep wrote:
Hi Tony, Jens, Scott, others,
On my to-do list for GGF CAOPS/IGTF session was still this request from the last TAGPMA F2F:
"e-Authentication
Mike: can we reflect the different LOAs in the middleware? Influence the way middleware is developed. Tony suggests IGTF writes a formal letter of requirements to the middleware developers. Policies is a good start. Scott mentions that MS Vista will support policies (as a RP). David will set up a group to summarise issues to be discussed in PMAs. Tony, Scott, Jens volunteer. TBD before GGF."
Essentially asking the M/W providers to support decision making based on Policy OIDs (and still to respect the RP-defined namespace constraints). To start of the discussion I put together a quick draft letter. When complete and approved, it should go out as an IGTF recommendation, so with the support from all three PMAs. The CAOPS-WG #2 session on the IGTF next week would be the obvious place to discuss this.
Can you give comments, so that we can distribute a draft version to the igtf-general list for wider comments shortly? In-line editing welcomed!
-------- Original Message -------- Subject: [caops-wg] Draft Agenda Date: Sun, 07 May 2006 21:48:04 -0400 From: Darcy Quesnel <darcy.quesnel@canarie.ca> To: caops-wg@ggf.org CAOPS Session, Friday May 12, 09:00 - 10:30, G407 - Introduction, 5 minutes - Draft Auditing Document, Yoshio, 10 minutes - Authentication Profile Document Review, Tony, 20 minutes - OCSP Document Finalization, Olle &c, 30 minutes - AOB IGTF Session, Friday May 12, 15:45 - 17:15, G404 - Introduction, 5 minutes - EUGridPMA update, 5-10 minutes - APGridPMA update, 5-10 minutes - TAGPMA update, 5-10 minutes - Auth'n Profiles discussion (does anyone have anything to discuss about particular auth'n profiles) - Middleware Authentication support, David Groep, 20 minutes ? - AOB -- 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 **
Hi Jens et al., On 11.05.06 12:53, Jensen, J (Jens) wrote:
Regardless of whether "we" build a validation authority or add to the middleware validation, someone still needs to build the validation code, and the language to specify what you want. The language should allow for checking not just policy oid but also key size and individual extensions, etc, IMHO. And be simple enough that anyone can implement an acceptance policy - no XML, no binary encodings.
I've been working on something like this and I hope to have the opportunity to describe it at the next EU Grid PMA meeting. The acceptance policy uses a Scheme-style S-Expression format, which admittedly has a lot in common with XML.
And as I mentioned earlier, if we add it to the middleware, it is best to go as far upstream as possible - OpenSSL ideally, or Globus. Document may need tweaking depending on where we go.
It will also need to work with other libraries, such as Bouncy Castle which is used for Java-based software (e.g. in gLite). Kind regards, David O'C
participants (2)
-
David O'Callaghan -
Jensen, J (Jens)