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

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

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


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

Yes. You need 2 OIDs. It adds, say, 5 bytes to the cert for a less hacky design. That is worth it.

The current syntax assumes the only way to generate a key id is to munge the hash of something. Three OIDs identify the munging (skiOutput), the hash (skiAlgorithm), and the something (skiInput). Defaults are given for the munging (optionally truncate) and the something (public key value) so only 1 OID is needed in the "common" case (which isn't actually common since SKISemantics seems likely to be a niche extension).

If, for instance, the CA randomly generates the key id it cannot indicate that -- it doesn't fit the munged-hash-of-something model. The CA would need to lie, making up fake hash and input OIDs and including 3 OIDs in the extension.


>> 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 methods for generating key ids (section 2 and RFC5280), and the ways to identify those methods in an extension (section 3), need to be consistent. At the moment they are not consistent since id-subjectPublicKeyInfo is defined in section 3 with nothing corresponding to it anywhere else.


P.S. In the current ASN.1 for SKISemantics the skiInput and skiOutput fields are both OIDs and both OPTIONAL so they need tags to distinguish them (eg [0] and [1]).

--
James Manger