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


Hallam-Baker, Phillip wrote:
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.
Your design is more complex than PKCS #7, though potentially it
provides more functionality. But to pipe a path of N certificates it
requires N Base64 processes. The PKCS #7 design require only
one, regardless of the number of certificates in the path.
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.
This is why I suggest a profile, a restriction for WSS use
on the generality that is currently allowed.
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.
I do not refer to different semantics, but to a proper subset
of what PKCS #7 currently allows - a profile.


You may leave a Technical Committee at any time by visiting http://www.oasis-open.org/apps/org/workgroup/wss/members/leave_workgroup.php


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