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

From: Sean Turner <[email-masked]>
Date: Tue, 19 Jun 2012 11:49:52 -0400

I'm planning on asking the ISE to publish this draft in the next couple 
of days.  Comments are welcome.

spt

On 5/30/12 3:39 PM, Sean Turner wrote:
> I've updated this draft to remove the 224 and 384 options, added some
> rationale for the extension, removed the length field (we'll rely on the
> OID), and added a field to indicate the format of the output.
>
> spt
>
> On 5/30/12 3:35 PM, [email-masked] wrote:
>>
>> A New Internet-Draft is available from the on-line Internet-Drafts
>> directories.
>>
>>     Title           : Additional Methods for Generating Key
>> Identifiers and Key Identifier Semantic Extension
>>     Author(s)       : Sean Turner
>>                            Stephen Kent
>>     Filename        : draft-turner-additional-methods-4kis-05.txt
>>     Pages           : 8
>>     Date            : 2012-05-30
>>
>>     This document specifies additional methods for generating key
>>     identifiers from a public key.  This document also specifies an
>>     extension to identify the algorithms used to generate the key
>>     identifiers.
>>
>>
>> A URL for this Internet-Draft is:
>> http://www.ietf.org/internet-drafts/draft-turner-additional-methods-4kis-05.txt
>>
>>
>> Internet-Drafts are also available by anonymous FTP at:
>> ftp://ftp.ietf.org/internet-drafts/
>>
>> This Internet-Draft can be retrieved at:
>> ftp://ftp.ietf.org/internet-drafts/draft-turner-additional-methods-4kis-05.txt
>>
>>
>> The IETF datatracker page for this Internet-Draft is:
>> https://datatracker.ietf.org/doc/draft-turner-additional-methods-4kis/
>>
>> _______________________________________________
>> I-D-Announce mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/listinfo/i-d-announce
>> Internet-Draft directories: http://www.ietf.org/shadow.html
>> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt
>>
> _______________________________________________
> pkix mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/pkix
>

---

From: "Manger, James H" <[email-masked]>
Date: Thu, 21 Jun 2012 17:22:46 +1000

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

---

From: Sean Turner <[email-masked]>
Date: Thu, 21 Jun 2012 12:34:36 -0400

James - thanks for the review.

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

******

>    of the hash. The required parameter of this algorithm identifies the hash

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.

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

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

>    RIGHT "skiAlgorithm" and "skiInput"

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

spt

---

From: [email-masked] (Martin Rex)
Date: Thu, 21 Jun 2012 23:41:00 +0200 (CEST)

Sean Turner wrote:
> Manger, James H wrote:
>> 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.
> 

"leftmost bits" is also what NIST FIPS 186-3 (Digital Signature Standard)
uses for hash output truncation (Section 4.2, page 16):

                                                   When the length of the
   output of the hash function is greater than N (i.e., the bit length of q),
   then the leftmost N bits of the hash function output block shall be used
   in any calculation using the hash function output during the generation
   or verification of a digital signature.

>   [...]

Yup, an example helps showing truncation to "leftmost bits".

-Martin

---

From: "Manger, James H" <[email-masked]>
Date: Fri, 22 Jun 2012 11:50:45 +1000

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

Please keep "leftmost", but completely drop "least significant".
In a DER-encoded integer, for example, the least significant bits are the rightmost bits.

--
James Manger

---

From: "Manger, James H" <[email-masked]>
Date: Fri, 22 Jun 2012 13:31:41 +1000

>> 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:
> 
> ****
> 

Better to start with a SPKI value.

  Given the following DER-encoded SubjectPublicKeyInfo value holding an P-256 ECDSA key:
 
    30 59
       30 13
          06 07 2A8648CE3D0201    -- id-ecPublicKey
          06 08 2A8648CE3D030107  -- secp256r1
       03 42 00
             04 7F7F35A79794C950060B8029FC8F363A
                28F11159692D9D34E6AC948190434735
                F833B1A66652DC514337AFF7F5C9C75D
                670C019D95A5D639B72744C64A9128BB

  The SHA-256 hash of the 65 bytes 047F7F...BB is
    BF37B3E5808FD46D54B28E846311BCCE1CAD2E1A62AA9092EF3EFB3F11451F44

  The SHA-1 hash of these 65 bytes is
    6FEF9162C0A3F2E7608956D41C37DA0C8E87F0AE

  The SHA-256 hash of the 91 bytes 305930...BB is
    6D20896AB8BD833B6B66554BD59B20225D8A75A296088148399D7BF763D57405

  Using method 1 from section 2, the subject key id
  extension and the key id semantics extension would be:

    30 1D
       06 03 551D0E  -- id-ce-subjectKeyIdentifier
       04 16
          04 14 BF37B3E5808FD46D54B28E846311BCCE1CAD2E1A
   
    30 xx
       06 xx xxxxxx  -- id-pe-skiSemantics
       04 xx
          30 xx
             06 xx xxxxxx  -- id-keyHash
             06 09 608648016503040201  -- id-sha256

  Using method 1 from RFC5280 the two extensions would be:

    30 1D
       06 03 551D0E  -- id-ce-subjectKeyIdentifier
       04 16
          04 14 6FEF9162C0A3F2E7608956D41C37DA0C8E87F0AE
   
    30 xx
       06 xx xxxxxx  -- id-pe-skiSemantics
       04 xx
          30 xx
             06 xx xxxxxx  -- id-keyHash
             06 05 2B0E03021A  -- id-sha1

  Using method 3 from section 2 the two extensions would be:

    30 1D
       06 03 551D0E  -- id-ce-subjectKeyIdentifier
       04 16
          04 14 6D20896AB8BD833B6B66554BD59B20225D8A75A2
   
    30 xx
       06 xx xxxxxx  -- id-pe-skiSemantics
       04 xx
          30 xx
             06 xx xxxxxx  -- id-keyInfoHash
             06 09 608648016503040201  -- id-sha256 

>    E72EE6C9C63D2B7F960F0E0611B9800917B5F9494182403EF1BBA8927A57625E

Not quite.
This is the SHA-256 hash of the 130 ASCII hex digits, not the 65 bytes.

--
James Manger

---

From: "Manger, James H" <[email-masked]>
Date: Fri, 22 Jun 2012 15:46:30 +1000

>> 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.
>>
>>    alg-keyHash ALGORITHM ::=
>>      { AlgorithmIdentifier IDENTIFIER id-keyHash }
>>
>>    alg-keyInfoHash ALGORITHM ::=
>>      { AlgorithmIdentifier IDENTIFIER id-keyInfoHash }

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

> 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