Subject: Re: [pkix] Possible new work item: additional methods for generating key identifiers

From: Sean Turner <[email-masked]>
Date: Mon, 23 Apr 2012 16:29:06 -0400

<no hat>

I've resurrected this draft after making some changes/additions to it 
based on mailing list comments.  The latest version can be found at:

http://datatracker.ietf.org/doc/draft-turner-additional-methods-4kis/

I'd like to ask the WG (again) to consider adopting this a WG item.

spt

</no hat>

On 6/16/10 10:17 AM, Sean Turner wrote:
> Greetings. Steve and I have whipped up a short I-D that specifies
> additional methods for generating key identifiers from a public key. The
> draft can be found at:
>
> http://datatracker.ietf.org/doc/draft-turner-additional-methods-4kis/
>
> I'd like to ask the WG to consider adopting this as a WG item.
>
> Cheers,
>
> spt*
>
> * (with no hat on)
> _______________________________________________
> pkix mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/pkix
>

---

From: Rene Struik <[email-masked]>
Date: Mon, 23 Apr 2012 17:46:54 -0400

Hi Sean:

You defined the key identifier to be the hash of the public key,
truncated to 160 bits. Shouldn't one have different key identifiers if
the policy fields assoicated with the public key are different (e.g., if
the same public key Qa associated with some entity A gets rolled over
and assigned a new validity period)? Similarly, shouldn't one include
the unique id of the presumed key holder (e.g.,so as to preclude people
cloning a public/private key pair to another device [I am sure
implementers contemplating this exist] without notice)?

Best regards, Rene

-- 
email: [email-masked]
Skype: rstruik
cell: +1 (647) 867-5658
USA Google voice: +1 (415) 690-7363

---

From: Sean Turner <[email-masked]>
Date: Tue, 24 Apr 2012 07:07:38 -0400

Rene,

Thanks for reviewing.  Comments inline.

spt

On 4/23/12 5:46 PM, Rene Struik wrote:
> truncated to 160 bits.

There's two parts of this draft:

- Describing methods for generating a key identifier that are the same 
as one of the example methods in 5280 except they ones in the draft use 
the SHA2 algs.

- Defining an extension to allow CAs to indicate the alg used to compute 
they key identifier, the input to the hash alg, and the output length.

> Shouldn't one have different key identifiers if
> and assigned a new validity period)?

If I'm reading RFC 5280 correctly, then I think it might go against it:

  Where a key identifier has been previously established,
  the CA SHOULD use the previously established identifier.

> Similarly, shouldn't one include

I'm certainly not precluding anybody from using whatever they want as an 
input to hash alg used to generate the key identifiers.  I'm just 
listing some additional methods.

To play devil's advocate here, I can already see the questions on this 
one: how do you know the identifier for the key holder is unique.

---

From: Rene Struik <[email-masked]>
Date: Tue, 24 Apr 2012 09:31:37 -0400

Hi Sean:

Thanks for the feedback. Your feedback seems more procedural (since you
refer to SHOULD language in RFC 5280. My comment was more technical
(granted - it did  not look at your write-up in the context of RFC5280).

draft-turner-additional-methods-4kis-03, Section 1, first para suggests
the following:

    These key identifiers are used by PKI-enabled security protocols,
such as CMP (Certificate Management Protocol) [RFC4210] and CMS
(Cryptographic Message Syntax) [RFC5652],
    to identify the certificate used to protect a message, a session, etc.

If so, referring to the same public key in different policy context via
the same identifier does not seem to serve the purpose. After all, if
one has CertCA(IdA, Qa, Valid0) and CertCA(IdA,Qa,Valid1), how can one
identify which of these two certificates to use if the key identifier
only depends on the common part of both certs?

To me, a key identifier identifies a key and associated keying
information that is bound to it.

I do agree it is hard to enforce uniqueness of identifiers (but that is
true for any requirement in a specification, even if one would use SHALL
language).

Best regards, Rene

On 24/04/2012 7:07 AM, Sean Turner wrote:
> as one of the example methods in 5280 except they ones in the draft
> use the SHA2 algs.
>
> - Defining an extension to allow CAs to indicate the alg used to
> compute they key identifier, the input to the hash alg, and the output
> length.
>
> I'm certainly not precluding anybody from using whatever they want as
> an input to hash alg used to generate the key identifiers.  I'm just

---

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

> only depends on the common part of both certs?

Ah so if the entity that holds both of CertCA's certs is doing the 
signing/encrypting - it usually includes the certificate in the 
protocol.  So, it's really just helping the recipient figure out which 
one of the certs in the certs bag to start with.

In the general case, if an EE only has one key and the CA has two valid 
certificates, then the RP is going to use which ever path works and it 
might have to check both.

> information that is bound to it.

Isn't that a certificate? ;)  But, I'm not trying to redefine what a key 
identifier is.  I'm just going with what RFC 5280 says in s4.2.1.1 and 
s4.2.1.2.

spt

---

From: Rene Struik <[email-masked]>
Date: Tue, 24 Apr 2012 12:45:29 -0400

Hi Sean:

On 24/04/2012 12:22 PM, Sean Turner wrote:
> In the general case, if an EE only has one key and the CA has two
> valid certificates, then the RP is going to use which ever path works
> and it might have to check both.
>
RS>>
Hence, my suggestion, which would avoid having to check more than one
option.
<<RS
> Isn't that a certificate? ;)  But, I'm not trying to redefine what a
> key identifier is.  I'm just going with what RFC 5280 says in s4.2.1.1
> and s4.2.1.2.
>
RS>>
Usually, keying material takes the form (key, associated keying info),
where the associated keying info was  not created in a vacuum: it
supposedly stipulates something about the key itself: key validity
period, key usage, key originator, key owner, etc. Thus, my reference to
"bound to it" (maybe, I should have written "[supposedly] bound to it").
With certs, one has the CA vouching for the binding of the key to other
attributes via a signature, but there could be other mechanisms to
attest to a binding (including attesting to this via symmetric key
techniques or by just imprinting the keying material onto a device).
<<RS