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

 


Help: OASIS Mailing Lists Help | MarkMail Help

wss message

[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


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.



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