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

[Rene Struik <[e-mail]>]

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


-- 
email: [e-mail]
Skype: rstruik
cell: [phone]
USA Google voice: [phone]