OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

wss message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]

Subject: RE: [wss] Groups - WSS-X509-04.pdf uploaded


I just sent in the X509 profile, there is a problem with the specification
of cert chains however.

I think we should get rid of the PKCS#7 stuff entirely. It does not specify
a path, so the spec is having to make contorted statments to try to make
order matter in a spec where it does not. Nor does PKIPath work since it is
a dangling reference to yet more ASN.1 in an unratified spec. Neither scheme
supports use of OCSP tokens, let alone SAML, XrML etc.

We need to build chains of more than just certs, since the ASN.1 syntax is
not satisfactory why not use XML.

Instead what we should do is to have a sequence of binary security tokens,
each of which explains its reference to the next:

<BinarySecurityToken wsu:Id="EndEntity" parent="CACert"

<BinarySecurityToken wsu:Id="CACert" references="EndEntity"
relation="parent" ValueName="wsse:X509">

<BinarySecurityToken wsu:Id="RootCert" references="CACert" relation="parent"

This model could be used to add in other token types such as OCSP tokens,
there is a bit of a problem dancing arround the attribute syntax which is
why it is necessary to go in the direction from the parent to reference the

<BinarySecurityToken wsu:Id="RootCert" references="EndEntity"
relation="validates" ValueName="wsse:X509">

This extends very cleanly to concepts like SAML and XrML tokens.

The relation tag may not be needed, the ValueName may be enough.


[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]