[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [wss] New Issue: Clarification on use of Key Identifier when SKI extension is not present
The problem with the certificate digesting approach is that a renewed certificate will not be matched by the original digest. --Maneesh -----Original Message----- From: Vijay Gajjala [mailto:vijayg@microsoft.com] Sent: Tuesday, August 24, 2004 5:35 AM To: wss@lists.oasis-open.org Subject: RE: [wss] New Issue: Clarification on use of Key Identifier when SKI extension is not present On the last TC call we discussed what to do when a X.509 certificate didn't have an SKI. The conclusion was to use the issuer-serial reference mechanism. However, after doing some investigation on this, we like to propose an alternate mechanism. The general idea of the SKI is to have a unique identifier that unambiguously identifies the certificate. The IETF has some work in this area, but as others have pointed out, it typically focuses on digests of the public key only and therefore could match multiple certificates. While issuer-serial is a fine mechanism if one explicitly chooses it, it could have issues relating to X.500 name matching. Specifically, there are concerns around false negatives when abbreviations are used as there are different standards in this space and interoperability events in the past have indicated that this can be problematic. 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. This is a simple algorithm that we can all implement without any ambiguity and can be guaranteed that it uniquely identifies a specific certificate. Thanks for your consideration, Vijay -----Original Message----- From: NISHIMURA Toshihiro [mailto:nishimura.toshi@jp.fujitsu.com] Sent: Monday, August 09, 2004 6:40 PM To: wss@lists.oasis-open.org Subject: Re: [wss] New Issue: Clarification on use of Key Identifier when SKI extension is not present Reading the current spec (and errata), I assume that #X509v3SubjectKeyIdentifier can be used only when the certificate contains X.509v3 SubjectKeyIdentifier extension. If the SKI extension is not present, it can not meet the following requirement (MUST). | its contents MUST be the value of the certificate's X.509v3 | SubjectKeyIdentifier extension That is choice #1. We must modify the current spec for #2 and #3. I think we may make an errata for #2 but #3 should be left for consideration for next version. --- NISHIMURA Toshihiro (FAMILY Given) nishimura.toshi@jp.fujitsu.com Planning Dept., STRATEGY AND TECHNOLOGY DIV., SOFTWARE GROUP, FUJITSU LIMITED At Mon, 09 Aug 2004 16:54:52 -0400, Hal Lockhart wrote: > > A new issue has arisen as a result of some interoperability testing we have been doing. > > Can a KeyIdentifier be used with an X.509 Token when the certificate in question does not contain a Subject Key Identifier extension, either because it is an V1 cert or because it is simply not present in a V3 cert? > > We discovered that another vendor calculates the value from the certificate if it is not present. Since there is no standardized means of calculating the SKI, this only works if there is agreement on what method to use. > > We would like to see the TC do one of the following (in order of our preference): > > 1. Declare that the Key Identifier may not be used with an X.509 binary token unless the certificate contains an SKI extension. > > 2. Select a particular method of calculating the SKI and say that is must be used if the Key Identifier is used when the SKI is not present. > > 3. Define a scheme (valuetype) for declaring how the key identifier was calculated. One value could mean "taken from the cert" other values could define algorithms from RFC 3280, etc. > > Hal > > To unsubscribe from this mailing list (and be removed from the roster of the OASIS TC), go to http://www.oasis-open.org/apps/org/workgroup/wss/members/leave_workgroup .php. > > To unsubscribe from this mailing list (and be removed from the roster of the OASIS TC), go to http://www.oasis-open.org/apps/org/workgroup/wss/members/leave_workgroup .php. To unsubscribe from this mailing list (and be removed from the roster of the OASIS TC), go to 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]