Thanks for your replies, glad to see that I was not off track. Werner, I've attached a PNG-image with a screendump of what the "WseCertificate2.exe" tool gives me for the certificate I attached in the original mail. I use the "WseCertificate2.exe" tool that comes with WSE2.0 (think I have SP3). The RFC does say how to generate a SKI, but the purpose is to insert it into the certificate. I get even more confused when they (the MS WseCertificate2.exe) refer to the algorithm in the RFC since there seems to be two of them:
<quote>
Two common methods for generating key identifiers from the public key are:
(1) The keyIdentifier is composed of the 160-bit SHA-1 hash of the
value of the BIT STRING subjectPublicKey (excluding the tag,
length, and number of unused bits).
(2) The keyIdentifier is composed of a four bit type field with
the value 0100 followed by the least significant 60 bits of the
SHA-1 hash of the value of the BIT STRING subjectPublicKey
(excluding the tag, length, and number of unused bit string bits).
</quote>
I guess Hans's codesnippet is for the first algorithm.
I still think it's a bit fuzzy what the right thing is, since the RFC says
that the SKI should be included in the certificate, but to enable interop
with .NET/WSE2 it seems necessary to calculate it at runtime if not present
- classic Open Source dilemma. If it makes a diffenrence I would prefer to
see it calculated, since interop is my main concern.
/Brian
-----Original Message-----
From: Granqvist, Hans [mailto:[EMAIL PROTECTED]
Sent: 17. maj 2005 18:23
To: Brian Nielsen; [email protected]
Subject: RE: X509 Subject Key Identifer and interoperability
Either
1) Regen certs to contain SKI (OID 2.5.29.14)
Or
2) If SKI is not present, it can be hand-calculated as
follows for RSA keys:
PublicKey key = cert.getPublicKey();
if (!(key instanceof RSAPublicKey)) {
// this snippet handles only RSA keys
}
byte[] encoded = key.getEncoded();
// remove 22-byte algorithm ID and header
byte[] value = new byte[encoded.length - 22];
System.arraycopy(encoded, 22, value, 0, value.length);
MessageDigest md
= SecurityFactory.getMessageDigestInstance("SHA1");
return md.digest(value);
so this could be added to wss4j code
-Hans
> -----Original Message-----
> From: Brian Nielsen [mailto:[EMAIL PROTECTED]
> Sent: Monday, May 16, 2005 2:01 PM
> To: [email protected]
> Subject: X509 Subject Key Identifer and interoperability
>
>
> I have a service that I've created with axis/wss4j, and the
> certificates are created with openssl (I've attached the certificate
> to this mail). I've tested the service with an axis/wss4j without any
> problems, but when I tried calling from .NET/WSE2 I ran into problems.
> From .NET/WSE2 I can only generate a request that has a
> "SecurityTokenReference" with a "KeyIdentifier" childelement for the
> "Subject Key Identifier"
> (SKI), like in the spec [1]. But the server-side runs into problems
> with an exception, and then i tried to run an axis/wss4j client with
> SKI and didn't even get to send the request due to the same reason.
> I've looked around and found that my certificat doesn't contain a SKI,
> so in a way it's fair that wss4j gives an exception, but then I wonder
> how
> .NET/WSE2 does create a request with it. From the RFC [2] it does seem
> like I should go back and create a new set of
> certifcates:
>
> <quote section="4.2.1.2 Subject Key Identifier"> To assist
> applications in identifying the appropriate end entity certificate,
> this extension SHOULD be included in all end entity certificates.
> </quote>
>
> Has anyone dealt with the same problems, and do you think my
> certificates are to blame and last how can .NET/WSE2 do it.
>
> Thanks for any advice.
>
>
> Regards
> Brian
>
>
> [1]
> http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-x509-t
oken-profile-1
.0.pdf
[2] http://www.faqs.org/rfcs/rfc3280.html
<<attachment: WseCertificate2.PNG>>
