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

["Hallam-Baker, Phillip" <pbaker@verisign.com>]

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.


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