RE: [wss] New Issue: Clarification on use of Key Identifier when SKI extension is not present

["Vijay Gajjala" <vijayg@microsoft.com>]

Based on the feedback so far, here is an alternative:

SOAP Message security defines KeyIdentifier as a value that can be used
to uniquely <b>identify a security token</b> (not just the key). Lines
752-756 in the core specification also talk about the use of ValueType
attribute to specify the critical semantics of the identifier, such as
whether the KeyIdentifier is unique to the key or the token. 

Given this guidance, it appears that we can add a section 3.2.4 to the
x509 token profile along the lines of:

3.2.4 Thumbprint References
The <wsse:KeyIdentifier> element is used to specify a reference to an
X.509 certificate by means of a reference to its X.509 Thumbprint
attribute. This profile defines the syntax of, and the processing rules
for referencing a Thumbprint using the URI values specified below (note
that the URI fragments are relative to the URI for this specification):

ValueType         : #X509ThumbprintSHA1 [1]
Description       : The thumbprint of the X.509 certificate
 

The <wsse:SecurityTokenReference> element from which the reference is
made contains a <wsse:KeyIdentifier> element. The <wsse:KeyIdentifier>
element MUST have a ValueType attribute with the value or
#X509ThumbprintSHA1 and its contents MUST be the  thumbprint for the
desired certificate .  If the certificate does not contain a X.509
Thumbprint extension, then one is computed as the SHA1 of the raw octets
which would be encoded within the <wsse:BinarySecurityToken> element
were it to be included.  The thumbprint is encoded as per the
<wsse:KeyIdentifier> element's EncodingType attribute.   The default
encoding is Base64. Implementations compliant with this specification
MAY support such a certificate reference mechanism.

Thoughts?
- Vijay

-----Original Message-----
From: Rich Salz [mailto:rsalz@datapower.com] 
Sent: Monday, August 30, 2004 9:59 AM
To: Vijay Gajjala
Cc: wss@lists.oasis-open.org
Subject: Re: [wss] New Issue: Clarification on use of Key Identifier
when SKI extension is not present

> What we'd like to propose is a simple alternative whereby if a SKI
isn't
> present, the token profile defines the default SKI as the SHA1 digest
of
> the certificate octets prior to base64 encodining and insertion into a
> <wsse:BinarySecurityToken> element.

I object to this proposal because it changes the semantics of the SKI, 
which is explicitly called out as a *key* identifier, to something like 
a CUI (cert unique identifier).  X509SKI has particular semantics, and 
this proposal changes them.  I don't think we should do that.  In 
addition to just being wrong :), it adds to the confusion around SKI: 
"using the SKI can lead to incorrect trust decisions unless the cert has

no SKI."

I think we must either define a new cert identifier, wss:X509CUI, which 
has its own deployment and propagation issues, or leave things as they
are.
	/r$

-- 
Rich Salz, Chief Security Architect
DataPower Technology                           http://www.datapower.com
XS40 XML Security Gateway   http://www.datapower.com/products/xs40.html
XML Security Overview  http://www.datapower.com/xmldev/xmlsecurity.html