issue 310 - comments on nov 8 draft of the x509 profile

[Ron Monzillo <Ronald.Monzillo@Sun.COM>]

http://www.oasis-open.org/apps/org/workgroup/wss/download.php/10115/oasis-2004xx-wss-x509-token-profile-1.1-changes.pdf 

draft dated 8 Nov 2004

> 3.2.4 Thumbprint References 174
> The <wsse:KeyIdentifier> element is used to specify a reference to an 
> X.509 certificate by 175
> means of a reference to its X.509 Thumbprint attribute. This profile 
> defines the syntax of, and the 176
> processing rules for referencing a Thumbprint using the URI values 
> specified below (note that the 177
> URI fragments are relative to the URI for this specification): 178
> 179
> Subject Key Identifier ValueType URI Description
> Thumbprint #X509ThumbprintSHA1 The thumbprint of the X.509 certificate
> 180
> The <wsse:SecurityTokenReference> element from which the reference is 
> made contains a 181
> <wsse:KeyIdentifier> element. The <wsse:KeyIdentifier> element MUST 
> have a 182
> ValueType attribute with the value or #X509ThumbprintSHA1 and its 
> contents MUST be the 183
> thumbprint for the desired certificate . If the certificate does not 
> contain a X.509 Thumbprint 184
> extension, then one is computed as the SHA1 of the raw octets which 
> would be encoded within 185
> the <wsse:BinarySecurityToken> element were it to be included. The 
> thumbprint is 186
> encoded as per the <wsse:KeyIdentifier> element's EncodingType 
> attribute. The default 187
> encoding is Base64. Implementations compliant with this specification 
> MAY support such a 188
> certificate reference mechanism. 

The latest sentcnce should more closely reflect the treatment of 
thumbprint references that we agreed
to in the teleconf of 10/19

>310: Pending. Make it clear that you can include multiple key reference
>methods in a single KeyInfo. This allows you to include a potentially more
>efficient (SKI) mechanism along with a potentially more interoperable
>mechanism (IssuerSerialNumber) for example.
>
Support for thumbprint based keyIdenfier references is optional. 
Implementations
compliant with this specification MAY include a thumbprint based 
KeyIdentifier
if the containing SecurityTokenReference contains another mandatory to 
be supported
by the profile reference (e.g. a <ds:X509IssuerSerial> reference) that 
resolves to the
same token.

The minutes from 10/19 discuss multiple reference forms in keyInfo, 
without clarifying
whether the thumprint would actually occur within an encapsualted STR, 
and without
clarifying whether the "potentially more interopeable mechanism 
(IssuerSerialNumber)"
would be booted up to the enclosing KeyInfo, to make room for the 
thumbprint.

IMV, we should avoid mentioning KeyInfo, and focus on the potential use of
thrumbprint based KIDs in STR's.

An alternative would be to allow the optional inclusion of a thumbprint 
in keyInfo,
above and outside the STR, while requiring that the contained STR 
includes a mandatory
to support reference form.

Ron