Shibboleth Developers

[Peter Williams <>]

ok. Well I broke a personal rule and actually read the cited PKIX RFC. This 
must be the first time in 2 years.

4.2.1.2 is clear that SKI aims to id a cert (which is what folks intended it 
to do, in the original proposed amendment to the X.509 standard). Good so 
far. Any use of SKI for other purpose (e.g. id keying material, id a party, 
id some arbitrary datum) is "improper" security engineering.

It's pretty obvious that the means of generating the unique value is 
essentially irrelevant - as all the core technical control is intended to do 
is allow one to make matches, between certificate layers, for use in path 
building or discriminating between leaf path nodes with the same  public key 
component value(s) yet different control parameters. No other purpose is 
intended, and none should be assigned, I might counsel.

The 2 suggested practices for calculating the value in CA certs are pretty 
clearly written up: DER encoding of the subjectPublicKey **ASN.1 typed 
value*, as then encoded into an X.410 BIT STRING, with various leading bits 
and bytes removed or added to/from the DER-marshaled bit-string primitive 
type.

The type of the SubjectPublicKey Type is dependent on the algorithm of the 
keying material(s), of course, and contains various values as a consequence. 
(One deprecated NSA type defined for the DSS/KEA world used to contain 2 
public keys, various privilege bits, and control values for ensuring key 
wrapping IKs derived from one of the public keys by KEA would be guaranteed 
to change by month and sensitivity class assigned to the particular TEK). 
Hopefully, it's now obvious why the suggested calculation is a function of 
the bit-string, whose value is an encoding of the marshaled subjectPublicKey 
type - which by the magic of ASN.1 macros is essentially an opaque type

The spec does then call out how CA certs are to be distinguished from EE 
certs, in the area of including the SKI extension: it's MUST generation and 
it's SHOULD handling.

"For end entity certificates, subject key identifiers SHOULD be
   derived from the public key.  Two common methods for generating key
   identifiers from the public key are identified above."

However, this quote pretty clearly references the very methods defined 
earlier, for CA certs.

My conclusion is that the X.509 profile does not require its described 
methods be used (in fact, it clearly states one can roll one's own.) The 
methods it describes do support (to my eye) the main purpose of the 
identifier - identify certs - and thus the asymmetric key management controls 
that the particular cert represents. This all seems to nicely support the 
guts of Rick's message (from way back in 2003).

-----Original Message-----
From: Tom Scavo 
[mailto:]
Sent: Saturday, August 09, 2008 12:41 PM
To: Peter Williams
Cc: 

Subject: Re: [Shib-Dev] how to deliver personal infocard keyinfo to app?

On Sat, Aug 9, 2008 at 1:32 PM, Peter Williams 
<>
 wrote:
> See 2003: http://lists.oasis-open.org/archives/wss/200306/msg00096.html

The writer of this message claims the SKI is the "SHA1 hash of the DER
of the key."  I don't think that's correct.  According to RFC5280, at
least, the SKI is the SHA-1 hash of the plain (not DER-encoded) public
key.  The tools I've looked at compute it this way, too.

Tom