[OGSA-AUTHZ] Implementations

Sat Mar 22 11:49:51 CDT 2008

Hi Tom

thanks for taking the painful but necessary step of raising a defect.

Actually I dont think it is as bad as you say. The current draft is not 
erroneous, it is simply lacking in a non-essential though useful 
feature. The DN is not erroneous. It is perfectly OK and I would not 
suggest removing it. The reasons have already been given in my earlier 
discussions on Trust i.e. if the AA trusts the Grid SP then the DN of 
the Grid SP in the caller field (sorry may not have used the correct 
term here) and the DN of the user in the subject field (again may not be 
correct term) is sufficient to provide a perfectly good proxy service. 
It is also as scalable as Shibboleth is today (cf the metadata). So what 
you are proposing to add is a feature that will allow greater 
scalability and less configuring of trust meta data, since the user can 
dynamically delegate to a proxy to request attributes on his behalf. 
This is a nice additional feature to the current draft, but is not a 
show stopper in my opinion

Regards

David

Tom Scavo wrote:
> On Sat, Mar 22, 2008 at 11:32 AM, David Chadwick
> <d.w.chadwick at kent.ac.uk> wrote:
>>  we do a dis-service to people by specifying a standard which we know to
>>  be deficient beforehand. This will cause even more delays in trying to
>>  rectify it (consider for example the OGSA Authz SAML spec, GFD 66, which
>>   was only found to be deficient after practical trials, and how long it
>>  has taken to produce replacements).
> 
> I suppose that is why the OASIS process requires three attestations
> (i.e., claims of successful implementation) before OASIS Standard
> status can be put to the vote.
> 
>>  My suggestion would be to raise a ballot comment now on the current
>>  OASIS draft, along with a proposed solution, so that this can be taken
>>  into account in the revision.
> 
> I tend to agree (reluctantly).  What do others think?
> 
> Should the proposed solution require a <ds:KeyInfo> element and
> disallow an X509SubjectName identifier, or should it be more lax?
> That's really a tough call, I think.
> 
>>  If the process is anything like IETF or
>>  ISO it should not cause too much of a delay.
> 
> Such a change requires that we start from scratch, including another
> 60-day public review.  The delay will be substantial.
> 
>>  Tom Scavo wrote:
>>
>>
>>> On Sat, Mar 22, 2008 at 5:44 AM, David Chadwick <d.w.chadwick at kent.ac.uk> wrote:
>>  >>  ...the inclusion of a "certificate" needs more elaboration. The
>>  >>  inclusion for example of a user's public key certificate proves nothing
>>  >>  more than the presence of a DN does, since it is publicly available and
>>  >>  an untrustworth grid SP could send any PKC it wished, just as it can
>>  >>  send any DN it wished. Therefore one needs to specify the properties of
>>  >>  the certificate that are being transferred, which is, that the user is
>>  >>  delegating to the grid SP to act on its behalf. A proxy certificate
>>  >>  would do this, as would an attribute certificate.
>>  >
>>  > I totally agree.  Of course this requires a new attribute request
>>  > handler at the Shib AA but then a new handler is required for a bare
>>  > DN as well, so there's no additional penalty.  I don't know that much
>>  > about the VOMS AA, but I'd be surprised if handling a full certificate
>>  > turned out to be much of a problem for VOMS.
>>  >
>>  > We have a dilemma, however.  A formal ballot is currently underway to
>>  > promote the OASIS SAML V2.0 Deployment Profiles for X.509 Subjects to
>>  > Committee Specification status.  I fully expect this ballot to
>>  > succeed.  The next step after Committee Specification is OASIS
>>  > Standard (but this last step requires three attestations, which is
>>  > unlikely).
>>  >
>>  > If we introduce a normative change to the profile such as we've been
>>  > discussing, we essentially start over.  Presumably the profile could
>>  > travel faster through committee this time around since the bulk of it
>>  > has already been vetted, but a significant delay is inevitable.
>>  >
>>  > The other alternative is to specify this new extension of
>>  > saml2:BaseIDAbstractType in our Attribute Exchange profile and leave
>>  > the OASIS profile alone, flawed as it is.  A third alternative is to
>>  > do nothing.
>>  >
>>  > I'm not sure what to recommend.  I'll let others comment on the
>>  > appropriate course of action.
>>  >
>>  > Tom
>>  >
>>  >>  Tom Scavo wrote:
>>  >>  >
>>  >>  > Instead of *requiring* a DN, the name identifier in the query should
>>  >>  > be generalized to accommodate the entire certificate (without
>>  >>  > excluding the possibility of a naked DN in those situations where it
>>  >>  > is warranted).  This can be done using <ds:KeyInfo>, something like
>>  >>  > this:
>>  >>  >
>>  >>  > <saml:Subject>
>>  >>  >  <saml:BaseID xsi:type="KeyIdentifierType">
>>  >>  >    <ds:KeyInfo>...</ds:KeyInfo>
>>  >>  >  </saml:BaseID>
>>  >>  > </saml:Subject>
>>  >>  >
>>  >>  > where KeyIdentifierType is defined as follows:
>>  >>  >
>>  >>  > <complexType name="KeyIdentifierType">
>>  >>  >  <complexContent>
>>  >>  >   <extension base="saml:BaseIDAbstractType">
>>  >>  >     <sequence>
>>  >>  >       <element ref="ds:KeyInfo"/>
>>  >>  >     </sequence>
>>  >>  >   </extension>
>>  >>  >  </complexContent>
>>  >>  > </complexType>
>>  >
>>
>>
>>
>> --
>>
>>  *****************************************************************
>>  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 at 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
>>
>>  *****************************************************************
>>
> 

-- 

*****************************************************************
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 at 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

*****************************************************************