[OGSA-AUTHZ] Implementations

[Tom Scavo]

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