OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

ws-dd message

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


Subject: RE: Issue 126 - WS-Discovery - KeyId complexity in compactsignatures


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:Ram.Jeyaraman@microsoft.com]
Sent: Tuesday, December 16, 2008 8:12 AM
To: ws-dd@lists.oasis-open.org
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



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