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

[Sean Turner <[e-mail]>]

On 4/24/12 9:31 AM, Rene Struik wrote:
> 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?

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.

> To me, a key identifier identifies a key and associated keying
> 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

> 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:
>> Rene,
>>
>> Thanks for reviewing.  Comments inline.
>>
>> spt
>>
>> On 4/23/12 5:46 PM, Rene Struik wrote:
>>> Hi Sean:
>>>
>>> You defined the key identifier to be the hash of the public key,
>>> 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
>>> 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)?
>>
>> 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
>>> 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)?
>>
>> 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.
>>
>>> Best regards, Rene
>>>
>>> On 23/04/2012 4:29 PM, Sean Turner wrote:
>>>> <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
>>>>> [e-mail]
>>>>> https://www.ietf.org/mailman/listinfo/pkix
>>>>>
>>>> _______________________________________________
>>>> pkix mailing list
>>>> [e-mail]
>>>> https://www.ietf.org/mailman/listinfo/pkix
>>>
>>>
>
>