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

["Phillip H. Griffin" <phil.griffin@asn-1.com>]

If I read your example correctly, a recipient would need to
use Base64 code three times to retrieve the elements of this
chain of certificates - a one step operation using the PKCS
#7 format. Then to use existing software you would still need
to encode them into an ASN.1 set.

The problem with the PKCS #7 definition as a path stems
from English prose, not the ASN.1 definition. The prose
states that the certificates in a series may not be a path, may
contain the elements of a path that are not in path order, may
not contain all of the certificates needed to form a path, and
may contain more certificates than needed to form a path.

This is trivial to fix if all you want in WSS is a path - simply
make this a requirement of the contents of this commonly
used ASN.1 type.

If you need more than just a path, all flavors of this PKCS #7
type, then define a <Path> version of PKCS #7 that is required
to contain a path, and a generic certificate <Bucket> to handle
the other cases if they are important.

Phil Griffin


Hallam-Baker, Phillip wrote:

>All,
>
>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"
>ValueName="wsse:X509">
>	sersesrdtlaoewrhtlqkajhewrtlkqhw==
></BinarySecurityToken>
>
><BinarySecurityToken wsu:Id="CACert" references="EndEntity"
>relation="parent" ValueName="wsse:X509">
>	zs58aow975tlozw4t7o8yuwst9o87==
></BinarySecurityToken>
>
><BinarySecurityToken wsu:Id="RootCert" references="CACert" relation="parent"
>ValueName="wsse:X509">
>	izs745t8ayuw4t;oapt987apw8y435==
></BinarySecurityToken>
>
>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
>child.
>
><BinarySecurityToken wsu:Id="RootCert" references="EndEntity"
>relation="validates" ValueName="wsse:X509">
>	sawruygq47yhb43287yt==
></BinarySecurityToken>
>
>This extends very cleanly to concepts like SAML and XrML tokens.
>
>
>The relation tag may not be needed, the ValueName may be enough.
>
>
>		Phill
>
>You may leave a Technical Committee at any time by visiting http://www.oasis-open.org/apps/org/workgroup/wss/members/leave_workgroup.php
>
>
>  
>