AuthN CA middleware support [Fwd: [caops-wg] Draft Agenda]

[Olle Mulmo]

David,

I'm sure David will respond with a longer reply, but the short answer  
is "no". This is to indicate that the RP only honors subsets of the  
CA's namespace.

/Olle


On May 10, 2006, at 07:18, David Chadwick wrote:

> Hi David
>
> the nameConstraints extension can almost provide the namespace  
> constraints that you require, but it has some weaknesses due to its  
> "trust all except" semantics. It is necessary that each application  
> check that the authenticated name that is returned is a DN and not  
> a name in some other name format, and that no other name forms  
> exist in the subjectAltName extension. With those provisos,  
> nameConstraints should work when cross certifying CAs or  
> subordinate CAs
>
> regards
>
> David
>
>
>
>
> David Groep wrote:
>> 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 at canarie.ca>
>> To: caops-wg at 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 W. Chadwick, BSc PhD
> Professor of Information Systems Security
> The Computing Laboratory, University of Kent, Canterbury, CT2 7NF
> Tel: +44 1227 82 3221
> Fax +44 1227 762 811
> Mobile: +44 77 96 44 7184
> Email: D.W.Chadwick at kent.ac.uk
> Home Page: http://www.cs.kent.ac.uk/people/staff/dwc8/index.html
> Research Web site: http://sec.cs.kent.ac.uk
> Entrust key validation string: MLJ9-DU5T-HV8J
> PGP Key ID is 0xBC238DE5
>
> *****************************************************************
>