[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: 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.
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]