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

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

> I'm assuming in your example that the middle cert, CACert, 
> should have also had a 'parent' reference to RootCert, correct?
> --
> Steve

No, the references point in a single direction. The reason for doing it from
the root to the CA and from the CA to the end entity is that they are in
essence annotations. You might have an OCSP token AND a CA Cert both
annotating the same end entity cert.

OOps - I see the mistake now. parent is a holdover from the first time we
did this and discovered the problem cited.

 <BinarySecurityToken wsu:Id="EndEntity" ValueName="wsse:X509">
 	sersesrdtlaoewrhtlqkajhewrtlkqhw==
 </BinarySecurityToken>

It is possible you might have a CA cert that authenticates two separate end
entity certs in the same message, this seems less likely though.


		Phill


> 
> -----Original Message-----
> From: Hallam-Baker, Phillip [mailto:pbaker@verisign.com]
> Sent: Monday, May 19, 2003 3:35 PM
> To: Hallam-Baker, Phillip; wss@lists.oasis-open.org
> Subject: RE: [wss] Groups - WSS-X509-04.pdf uploaded
> 
> 
> 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