Re: [wss] X.509v1 Certificate Support in 1.0 Errata

[Michael McIntosh <mikemci@us.ibm.com>]

Ron Monzillo <Ronald.Monzillo@Sun.COM> wrote
on 03/07/2005 07:44:26 AM:

> Michael,
> 
> I'd like to add the following 3rd alternative to the 2 you have proposed.
> 
> In Web Services Security: X.509 Token Profile 1.0 Errata 1.0 Committee
> Draft 200401, October 2004
> http://www.oasis-open.org/committees/download.
> php/11145/oasis-200401-x509-token-profile-1.0-errata- 
> errata-004.pdf
> 
> 1. delete sections 3.1, 3.3, 3.4, 3.6, 3.7, and 3.10
> 
> In Web Services Security: SOAP Message Security 1.0 (WS-Security 2004)
> Errata 1.0 Committee Draft 200401, October 2004
> http://www.oasis-open.org/committees/download.
> php/11146/oasis-200401-wss-soap-message-security-1.0-errata-004.pdf

Ok.

> 2. revert the URI in the 3rd row of the table on line 211 to contain:
>         #X509v3          
      
> http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-x509-
> tokenprofile-1.0#X509v3
> 
> BTW, the purpose the table plays in the clarification is unclear to
me. 
> Perhaps the table should be
> removed from the clarification.

Ok, but I'd like to add a URL for v1 since the BSP
requires the ValueType.

> 3. Add the following sentence to the description of the 
> /wsse:BinarySecurityToken/@ValueType attribute
> beginning on line 587.
> 
> When the ValueType attribute is not specified, the encoded binary
data 
> MUST be an X509 certificate.

Currently, the Core and X.509 Profile are silent on
what it means when the recommended ValueType is absent.
To me that means any BST could be held within, X.509v3,
PKIPath, PKCS7, Kerberos, and any other.
I guess the assumption is that a processor could discover
the content while parsing.
I don't seem a reason to further constrain this here.

> ------
> The effect of change 3 would be to allow the use of x509 certificates
of 
> unspecified version
> within BSTs (while maintaining backward comapatibility) with existing
> implementations, which are
> not required to provide a ValueType, and which would not be prepared
to 
> recognize a newly defined
> x509v1 valuetype.
> 
> Ron
> 
> >
> > The current errata [1] line 211 and [2] sections 3.3 thru 3.7
> > implement changes intended to allow X.509v1 certificates to be
used 
> > with WSS 1.0. The changes as described in the errata are not
backward 
> > compatible with the WSS 1.0 standard. This has resulted in confusion
> > and interoperability problems since some vendors are implementing
> > according to the errata and others are implementing according
to the 
> > WSS 1.0 standard.
> >
> > I suggest we revisit the errata to allow use of X.509v1 certificates
> > while retaining backwards compatibility with the WSS 1.0 standard.
My 
> > preferred alternative would be to rollback the change of the
URI from 
> > "...#X509v3" to "...#X509", rollback the
change of the URI from 
> > "...#X509SubjectKeyIdentifier" to "...#X509v3SubjectKeyIdentifier",
> > and add a URI for "...#X509v1". Specific changes would
be:
> >
> > Revise [1] as follows:
> >
> > 1) replace the 3rd row of the table on line 211 containing:
> >         #X509 
> > http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-x509-
> tokenprofile-1.0#X509 
> >
> > with two rows containing:
> >         #X509v1 
> > http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-x509-
> tokenprofile-1.0#X509v1 
> >
> >         #X509v3 
> > http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-x509-
> tokenprofile-1.0#X509v3 
> >
> >
> > Revise [2] as follows:
> >
> > 2) change section 3.3 deleting line 82 and changing line 83 to:
> >         Insert a new first cell at line 172
containing:
> >         Single certificate #X509v1 An X.509
v1 signature-verification 
> > certificate.
> >
> > 3) remove section 3.6
> >
> > 4) remove section 3.7
> >
> > A less attractive (to me) alternative to the "...#X509v1"
URI 
> > described in #1 would be to add a statement to the errata that
makes 
> > it clear that you may include an X.509v1 certificate when the
URI 
> > states "...#X509v3". The reason I find this less attractive
is that it 
> > changes the expected behavior of the existing URI. By adding
a new URI 
> > we allow implementations to support X.509v1 while allowing those
that 
> > chose not to to correctly function without change.
> >
> > Thanks,
> > Mike
> >
> > [1] Web Services Security: SOAP Message Security 1.0 (WS-Security
> > 2004) Errata 1.0 Committee Draft 200401, October 2004
> > http://www.oasis-open.org/committees/download.
> php/11146/oasis-200401-wss-soap-message-security-1.0-errata-004.pdf
> >
> >
> > [2] Web Services Security: X.509 Token Profile 1.0 Errata 1.0
> > Committee Draft 200401, October 2004
> > http://www.oasis-open.org/committees/download.
> php/11145/oasis-200401-x509-token-profile-1.0-errata-004.pdf 
> 
> 
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: wss-unsubscribe@lists.oasis-open.org
> For additional commands, e-mail: wss-help@lists.oasis-open.org
>