Re: [pkix] draft-turner-additional-methods-4kis to ISE

[Sean Turner <[e-mail]>]

James - thanks for the review.

On 6/21/12 3:22 AM, Manger, James H wrote:
> A few comments on "Additional methods for key identifiers":
>
>
> Truncation: are the "least significant bits" of a hash the right-most bits? I would have though keeping the leftmost bits was slightly more intuitive.

I'll add "(i.e., leftmost)" after "least significant bits".

> I think we better put an example in the draft: a SubjectPublicKeyValue; 2 (or 4) subjectKeyId extension values; and 2 (or 4) corresponding ext-skiSemantics values.

I'll add a new section:

****

This section provides some examples.  The keys and key identifiers are 
presented in hexadecimal (two hex digits per byte).

Given the following P-256 ECDSA key:

   047F7F35A79794C950060B8029FC8F363A28F11159692D9D34E6AC94819043
   4735F833B1A66652DC514337AFF7F5C9C75D670C019D95A5D639B72744C64A
   9128BB

The SHA-256 hash output of the key is as follows:

   E72EE6C9C63D2B7F960F0E0611B9800917B5F9494182403EF1BBA8927A57625E

Using method 1 in Section 2, the output is truncated as follows:

   E72EE6C9C63D2B7F960F0E0611B9800917B5F949

This value is then DER-encoded and placed in the SKI's OCTET STRING.

The SHA-512 hash output of the key is as follows:

   4EF48AB572113ADEC402CC415CF201D5C9969A8A41FE093C1C1D32D67DF66D58
   CD2A35607DC4452DF87750663668E2FE197E58A69059618CF0BA9D5C269106E9

Using method 2 in Section, the output is truncated as follows:

   4EF48AB572113ADEC402CC415CF201D5C9969A8A

This value is then DER-encoded and placed in the SKI's OCTET STRING.

******

> The ext-skiSemantics extension would be better if it held a single AlgorithmIdentifier -- identifying the algorithm used to generate the subject key id. Then the spec can define two such algorithms.
>
>    ext-skiSemantics EXTENSION ::= {
>      SYNTAX AlgorithmIdentifier
>      IDENTIFIED BY id-pe-skiSemantics }
>
>    alg-keyHash ALGORITHM ::= { AlgorithmIdentifier IDENTIFIER id-keyHash }
>
>    alg-keyInfoHash ALGORITHM ::= { AlgorithmIdentifier IDENTIFIER id-keyInfoHash }
>
>    alg-keyHash indicates that the key id is the, possibly truncated, hash of
>    the value of the BIT STRING subjectPublicKey (excluding the tag, length,
>    and number of unused bits). The amount of truncation can be determined from the
>    length of the actual key identifier. Truncation keeps the least significant bits
>    of the hash. The required parameter of this algorithm identifies the hash
>    algorithm that is used.
>
>    alg-keyInfoHash differs from alg-keyHash in that the hash covers the
>    key algorithm id in addition to the actual public key.  alg-keyInfoHash
>    indicates that the key id is the, possibly truncated, hash of the
>    subjectPublicKeyInfo field. The amount of truncation can be determined from the
>    actual key identifier value. Truncation keeps the least significant bits
>    of the hash. The required parameter of this algorithm identifies the hash
>    algorithm that is used.

If skiOutput was dumped (see the response below about my horrible c/p 
error), then this might be a possibility.

My objection to the proposed syntax is that the predominant use case I 
see is where a CA only wants to indicate that it used SHA-256/512 
instead of SHA-1 to make the SKI.  With the current syntax it collapses 
to one oid: id-sha256/512 in skiAlgorithm, skiInput and skiOutput are 
omitted.  With the proposed syntax we'd need to carry two oids.

> If the spec is going to define alg-keyInfoHash (which it currently does under
> the name id-subjectPublicKeyInfo) for the extension (section 3) it really needs
> to define it as additional methods for generating key ids (section 2).

There's only one there because only one was asked for.  I'm willing to 
add more - got any in mind?

> The current model of the extension consists of a hash algorithm, an input id, and an output id. This is confusing and too restrictive. The skiOutput field, in particular, is unclear. It talks about the *input*, and repeats a sentence from the skiInput definition.
>
>       o skiOutput indicates the key identifier's semantics.  If this
>         field is absent, then key identifier is the hash (algorithm
>         identified in kiAlgorithm) of the value of the BIT STRING
>         subjectPublicKey (excluding the tag, length, and number of unused
>         bits).  This document defines the OID id-subjectPublicKeyInfo to
>         be used when the input to the hash algorithm is the certificate's
>         SubjectPublicKeyInfo field [RFC5280].

Wow now wonder you're confused.  An amazingly bad c/p error on my part. 
Apologies.  That last two sentences should be replaced with:

  If this field is absent, then key identifier is *the output of*
  the hash (algorithm identified in skiAlgorithm) of the value of
  the BIT STRING subjectPublicKey (excluding the tag, length, and
  number of unused bits).  *That is, it is just like using the 1st
  key identifier example method in [RFC5280], but instead of
  using SHA-1 the truncated output of the algorithm in
  skiAlgorithm is used.  This document does not define any OIDs
  for this field.*

Some thought that it would be good to include a field to indicate the 
semantics of the output.  No real examples were given so I've left this 
one open (i.e., undefined).  If anybody's got any suggestions I'd be 
glad to add it/them.

> Typos:
>
> 1 "Introduction", 2nd paragraph, last sentence, "*" brackets changes.
>
>    In addition, some *security* protocols (e.g., SMIME [RFC5751])
>    *use key identifiers* as a shorthand way to refer to a cert.
>
> 3 "Subject Key identifier Semantics Extension", 1st and 2nd dot points.
>    WRONG "akiAlgorithm" and "akiInput"
>    RIGHT "skiAlgorithm" and "skiInput"

Fixed both of these thanks.  Steve also caught some other typos in the 
intro.

spt