RE: [wss] RE: X.509 - Issues for next meeting

[Jerry Schwarz <jerry.schwarz@oracle.com>]

At 12:01 PM 7/10/2003, Hallam-Baker, Phillip wrote:
>This is pretty much what I was thinking...
>
>The problem with having a profile namespace is that every single message is
>going to have to contain the profile namespace URI.
>
>Given that it should not be difficult for us to specify rules to prevent
>collisions I would prefer to avoid this overhead. One rule could be that
>each QName specified in a profile starts with a specific prefix. In our case
>X509.
>
>This would impact the other specs but not drastically.

But it also serves as a guide for specs developed by other committee's or 
proprietary documents.  Since they won't be able to take advantage of wsse 
it is the 800lb. gorilla approach to do so ourselves.


> > -----Original Message-----
> > From: Tim Moses [mailto:tim.moses@entrust.com]
> > Sent: Thursday, July 10, 2003 2:52 PM
> > To: 'DeMartini, Thomas'; Tim Moses; Hallam-Baker, Phillip;
> > wss@lists.oasis-open.org
> > Subject: RE: [wss] RE: X.509 - Issues for next meeting
> >
> >
> > Thomas - OK.  This sounds fine.  Profile versions are
> > indicated by different
> > names (wsseX509new versus wsseX509).  The initial version has
> > no indicator
> > (i.e. wsseX509 not wsseX509-v1.0); subsequent versions will.
> > Hopefully, we
> > won't literally use the string "new".  We'll use "v1.1",
> > perhaps.  Maybe the
> > first authors to face this issue will establish a convention.
> >  Do we need to
> > preface these names with "wsse"?  Simply "X509" would be
> > correct.  Perhaps,
> > it is helpful to the reader to be reminded that this is only wsse's
> > interpretation of X509.
> >
> > What about QNames defined in the profile?  Should it be
> > wsseX509:PKIPath or
> > wsse:PKIPath?  My feeling is that it is safer, whenever a
> > type is used only
> > by one profile, to name in the profile namespace.  However,
> > we should reuse
> > definitions from the core wherever possible.
> >
> > All the best.  Tim.
> >
> > -----Original Message-----
> > From: DeMartini, Thomas [mailto:Thomas.DeMartini@CONTENTGUARD.COM]
> > Sent: Thursday, July 10, 2003 2:17 PM
> > To: Tim Moses; Hallam-Baker, Phillip; wss@lists.oasis-open.org
> > Subject: RE: [wss] RE: X.509 - Issues for next meeting
> >
> >
> > So, to be clearer, maybe we should use example URIs.
> >
> > Something along these lines would be good:
> >
> > ... xmlns:wsseX509="http://schemas.xmlsoap.org/ws/2003/06/secext/x509"
> > ...
> > ... valueType="wsseX509:X509v3" ... // refers to X509v3 by X509
> > profilev1
> > ... valueType="wsseX509:X509v4" ... // refers to X509v4 by X509
> > profilev1
> >
> > Then if we need another version of the X509 Token Profile to support
> > some new stuff in X509v4 but we don't break compatibility
> > with v3, then
> > it'd be something like this:
> >
> > ... xmlns:wsseX509="http://schemas.xmlsoap.org/ws/2003/06/secext/x509"
> > ...
> > ...
> > xmlns:wsseX509new="http://schemas.xmlsoap.org/ws/2004/11/secext/x509"
> > ...
> > ... valueType="wsseX509:X509v3" ... // refers to X509v3 by X509
> > profilev1
> > ... valueType="wsseX509:X509v4" ... // refers to X509v4 by X509
> > profilev1
> > ... valueType="wsseX509new:X509v4" ... // refers to X509v4 by X509
> > profilev2
> >
> > &Thomas.
> >
> > -----Original Message-----
> > From: Tim Moses [mailto:tim.moses@entrust.com]
> > Sent: Thursday, July 10, 2003 10:52 AM
> > To: 'Hallam-Baker, Phillip'; Tim Moses; wss@lists.oasis-open.org
> > Subject: [wss] RE: X.509 - Issues for next meeting
> >
> > Colleagues - As I read Phill's suggestion, it does not seem
> > to allow for
> > profile versions to evolve independently of the core versions and the
> > versions of the token format.
> >
> > How would we handle a situation in which a profile (the X509v3 profile
> > for
> > instance) needed to be reved, because of a flaw, perhaps?  I
> > don't think
> > we
> > would want to force, or wait for, a revision of the core.  And we
> > certainly
> > don't want to wait until ITU comes out with X509v4.  So, we
> > seem to need
> > a
> > convention for indicating the version of the profile,
> > independent of the
> > version of the token format (X509v3, X509v4, etc.) and independent of
> > the
> > core version.
> >
> > Then what about names defined in the profile (e.g. X509v3PKIPath)?
> > Should
> > these be subordinate in the naming tree to the profile, or to wsse?  I
> > don't
> > think we should explicitly version these.  If they are found to be in
> > error,
> > we'll just have to come up with a new name for the corrected
> > definition.
> >
> > All the best.  Tim.
> >
> >
> >
> > -----Original Message-----
> > From: Hallam-Baker, Phillip [mailto:pbaker@verisign.com]
> > Sent: Thursday, July 10, 2003 11:48 AM
> > To: 'Tim Moses'; Hallam-Baker, Phillip; wss@lists.oasis-open.org
> > Subject: X.509 - Issues for next meeting
> >
> >
> > Tim has raised the following issues with the draft. Although I agree
> > with
> > him on one of them they are both issues that the group has discussed
> > before
> > and so there should be a decision of the group.
> >
> > 1. QName versioning
> >
> > 2. Remove either PKCS#7 or PKIPath
> >
> >
> > On 1. I think we are in agreement that there should be some form of
> > versioning mechanism. I believe that the discussion should
> > consider the
> > following issues separately.
> >
> > A - The version of the X.509 token - X509v3, X509v4 whatever
> > B - The version of the token profile wsse-v1 v2 - whatever
> >
> > The constraints to bear in mind here are when do we want to break
> > backwards
> > compatibility? For me the only reason for changing an identifier is to
> > explicitly break compatibility.
> >
> > I think that the case B is best delt with through the URI prefix
> > mechanism.
> >
> > I think A is best dealt with by the QName stem, so we could have
> > wsse:X509v3
> > as a QName.
> >
> >
> > On 2. the issue here is simplicity, it is better to avoid multiplicity
> > of
> > mechanisms. PKIPath is designed to do the specific task we
> > want. PKCS#7
> > is
> > simply a random bag of certs that promise no explicit relationship to
> > anything. Although we can reuse PKCS#7 for our purpose we are defining
> > new
> > semantics in the process, we also end up with an unnecessary signature
> > blob
> > on the path.
> >
> > You may leave a Technical Committee at any time by visiting
> > http://www.oasis-open.org/apps/org/workgroup/wss/members/leave
> > _workgroup
> > .php
> >
>
>You may leave a Technical Committee at any time by visiting 
>http://www.oasis-open.org/apps/org/workgroup/wss/members/leave_workgroup.php