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

[Rene Struik <[e-mail]>]

Hi Sean:

On 24/04/2012 12:22 PM, Sean Turner wrote:
> 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.
>
RS>>
Hence, my suggestion, which would avoid having to check more than one
option.
<<RS
>> 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.
>
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
> 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
>>>>
>>>>
>>
>>


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