Re: [ws-dd] RE: Issue 126 - WS-Discovery - KeyId complexity in compactsignatures

I think that this has to be clarified as to what teh thumbprint actually is, like "a sha1 hash over the raw octet sting"

Anthony Nadalin | Work 512.838.0085 | Cell 512.289.4122

Dan Driscoll ---01/13/2009 11:12:48 AM---Proposed change: replace SKI and SHA-1 hash of the public key of the signing token with ‘Thumbprint.’ This will make impleme

From:

Dan Driscoll <>

To:

Ram Jeyaraman <>, "" <>

Date:

01/13/2009 11:12 AM

Subject:

[ws-dd] RE: Issue 126 - WS-Discovery - KeyId complexity in compact signatures

Proposed change: replace SKI and SHA-1 hash of the public key of the signing token with ‘Thumbprint.’  This will make implementations simpler, and will make it easier to debug compact signature issues.

 

d:Security/d:Sig/@KeyId 

The key identifier of the signing token. MUST be specified if a public key token is used. If included, MUST be Subject Key Identifier (see [RFC 5380] Section 4.2.1.2) Thumbprint extension of the signing token, encoded in Base64. If the signing token does not have a Subject Key Identifier, it MUST be the SHA-1 hash of the public key of the signing token. If omitted, the semantics are undefined. 

 

 

From: Ram Jeyaraman [mailto:] 

Sent: Tuesday, December 16, 2008 8:12 AM

To: 

Subject: [ws-dd] Issue 126 - WS-Discovery - KeyId complexity in compact signatures

 

This issue is assigned the number 126. For further discussions on this issue, please refer to this issue number or use this thread.

 

From: Dan Driscoll 

Sent: Monday, December 15, 2008 10:05 PM

To: Ram Jeyaraman

Cc: Vipul Modi

Subject: NEW Issue: KeyId complexity in WS-D compact signatures

 

The WS-Discovery compact signature KeyId is complex to generate.

 

d:Security/d:Sig/@KeyId 

The key identifier of the signing token. MUST be specified if a public key token is used. If included, MUST be Subject Key Identifier (see [RFC 5380] Section 4.2.1.2) of the signing token. If the signing token does not have a Subject Key Identifier, it MUST be the SHA-1 hash of the public key of the signing token. If omitted, the semantics are undefined. 

 

Implementers must build fallback logic (SKI, then public key hash) and must also implement their own search comparison logic, since the hash of the public key is not stored with the rest of the certificate.  When using the hash of the public key, it is also difficult to debug since the SHA-1 hash of the key is often not computed when the certificate is displayed on its own.

 

Proposed change: TBD