[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [wss] Groups - WSS-X509-04.pdf uploaded
> 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. Actually the VeriSign engineers were complaining that they were having to use Java 1.4 precisely because earlier versions did not support PKIPath. Base64 encoding 3 or a hundred times is not an issue. I have never had an engineer complain about base64 encoding. > The problem with the PKCS #7 definition as a path stems > from English prose, not the ASN.1 definition. No, the English prose is the definition of the semantics of PKCS#7. The syntax has to specify an ordering, but there is no requirement on exisiting PKCS#7 tools to observe it. There is no guarantee that a particular PKCS#7 interface will encode certs in the order specified in the list, in fact a library could be updated to reverse the order of the list without breaking the contract. >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. You are then not referencing PKCS#7, you are referencing a data structure that shares the syntax but has different semantics. That is a very bad thing to do. Phill
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]