Subject: [pkix] Fwd: I-D Action: draft-turner-additional-methods-4kis-02.txt

From: Sean Turner <[email-masked]>
Date: Mon, 23 Apr 2012 14:38:28 -0400

The previous version assumed that the input to the hash was always the 
private key.  Somebody pointed out that this might not always be the 
case so I added a field (an OID) to indicate the semantics of the hash 
input.  I also defined one value to indicate for SubjectpublicKeyInfo to 
be the input to the hash alg.

spt

-------- Original Message --------
Subject: I-D Action: draft-turner-additional-methods-4kis-02.txt
Date: Mon, 23 Apr 2012 11:31:51 -0700
From: [email-masked]
Reply-To: [email-masked]
To: [email-masked]

A New Internet-Draft is available from the on-line Internet-Drafts 
directories.

	Title           : Additional Methods for Generating Key Identifiers
	Author(s)       : Sean Turner
                           Stephen Kent
	Filename        : draft-turner-additional-methods-4kis-02.txt
	Pages           : 8
	Date            : 2012-04-23

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

_______________________________________________
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

---

From: "Manger, James H" <[email-masked]>
Date: Tue, 24 Apr 2012 13:15:37 +1000

>	Filename        : draft-turner-additional-methods-4kis-04.txt

Using a more recent hash alg than SHA-1 to generate key ids sounds fine.

Keeping the 160-bit size "to avoid adversely affecting relying party code" sounds strange. RFC5280 already recommends 2 methods with different lengths (160-bit and 64-bit) so relying party code better handle that. Perhaps using a size no longer than 160-bit is nice (so it takes no more space in a database field, for instance). Since we are truncating the hashes in all the new algs, why not truncate to something shorter? 64-bits would be a good choice (matching the shorter existing recommended method). We could even set the first 4 bits to 0101, 0110, 0111, 1000 for the 4 new methods so it matches the existing recommendation even more closely.

What is the reason for having a certificate extension to describe how a key id is generated?
I don't think the draft gives any reason.

The kiLength field seems pointless. You can look at the actual key id (also in the cert) to get its length.

A kiHashInput value of id-subjectPublicKey seems to mean the same thing as the kiHashInput field being absent. Two ways to say the same thing is bad.

--
James Manger

---

From: Sean Turner <[email-masked]>
Date: Tue, 24 Apr 2012 08:28:00 -0400

James,

Thanks for the review.  Comments inline.

spt

> Keeping the 160-bit size "to avoid adversely affecting relying party code" sounds strange. RFC5280 already recommends 2 methods with different lengths (160-bit and 64-bit) so relying party code bet…

Okay I struck "to avoid ...".

My primary reason for picking the 160-bit truncated length was that in 
sidr there was some discussion about what the output lengths would be if 
the alg to generate the key identifier was from the SHA2 family.  Some 
of the implementers seemed to like the idea of having it documented and 
fixed to the same length as the 160-bit truncated SHA-1 example in 5280 
(which is what they use now).  I realize that they could define any old 
method they wanted in their drafts, but this has come up a couple of 
times for me and I just wanted to document something so that it could be 
referenced.

Given the above, I don't want to remove the 160-bit truncated versions, 
but I don't have any problem adding the 64-bit methods you describe. 
Remember these are just listing some example methods - implementers are 
free to do these or not.

Sound like a plan?

> I don't think the draft gives any reason.

I added it because there was some discussion on the list about it - 
granted it was like 2 years ago.  Some folks were on about it here:
https://www.ietf.org/mail-archive/web/pkix/current/msg27849.html

I'll add some wording after I've run it by my co-author.

> The kiLength field seems pointless. You can look at the actual key id (also in the cert) to get its length.

I think you're right here and I'll remove kiLength.

> A kiHashInput value of id-subjectPublicKey seems to mean the same thing as the kiHashInput field being absent. Two ways to say the same thing is bad.

Ah that should have been id-subjectPublicKeyInfo which is different than 
just the key because it includes alg id/parameters.

---

From: Tom Gindin <[email-masked]>
Date: Tue, 24 Apr 2012 20:09:04 -0400

RFC 5280 section 4.2.1.2 suggests using the public key, not the 
private, as does the same section in 3280 and 2459.  I'm not sure why the 
private key would be better, and I can think of several reasons why the 
public key should be used as the basis for a certificate field rather than 
the private key.  We should probably stick with the earlier approach.

Tom Gindin

From:   Sean Turner <[email-masked]>
To:     [email-masked], 
Date:   04/23/2012 02:40 PM
Subject:        [pkix] Fwd: I-D Action: 
draft-turner-additional-methods-4kis-02.txt
Sent by:        [email-masked]

spt

-------- Original Message --------
Subject: I-D Action: draft-turner-additional-methods-4kis-02.txt
Date: Mon, 23 Apr 2012 11:31:51 -0700
From: [email-masked]
Reply-To: [email-masked]
To: [email-masked]

                 Title           : Additional Methods for Generating Key 
Identifiers
                 Author(s)       : Sean Turner
                           Stephen Kent
                 Filename        : 
draft-turner-additional-methods-4kis-02.txt
                 Pages           : 8
                 Date            : 2012-04-23

_______________________________________________
pkix mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/pkix

---

From: Sean Turner <[email-masked]>
Date: Tue, 24 Apr 2012 22:19:51 -0400

An amazingly bad typo on my part - should have been:

public key.

spt

On 4/24/12 8:09 PM, Tom Gindin wrote:
> From:   Sean Turner<[email-masked]>
> To:     [email-masked],

---

From: "Manger, James H" <[email-masked]>
Date: Thu, 26 Apr 2012 15:38:22 +1000

>> ...Since we are truncating the hashes in all the new algs, why not truncate to something shorter? 64-bits would be a good choice...

> ...I don't want to remove the 160-bit truncated versions, 
but I don't have any problem adding the 64-bit methods you describe...
> Sound like a plan?

No. One variety per hash is enough.
I feel that 160-bits is so far beyond what you need to be unique with high probability, that it is almost suggesting (erroneously) to the reader that the key-id needs to have "crypto" strength.
But if you want 160-bits, don't complicate it with shorter options as well.

You could ditch the SHA-224 and SHA-384 methods. Those 2 algs are just truncations of SHA-256 and SHA-512 (with different initial constants) so it is inconceivable that an implementation supports, say, SHA-224 but not SHA-256.

> I'll add some wording after I've run it by my co-author.

I look forward to seeing the reason. I read that thread, saw people asking for the extension, but still failed to discern a reason. 

How can you indicate that you used the 2nd recommended mechanism to generate a key-id (ie 0100 + truncate_to_60bits(sha1(public_key))) in the ext-kiAlgAndLen extension? I don't think you can given the extensions assumption of a purely truncated hash. Perhaps a special rule for 64-bit key ids is needed.

--
James Manger