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

["Manger, James H" <[e-mail]>]

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 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.


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 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).


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].





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"


--
James Manger