RE: Straw poll for Algorithm Identifiers in Subject Public Key Info.

["Kemp, David P." <DPKemp@xxxxxxxxxxxxxx>]

________________________________________
From: Daniel Brown [mailto:DBrown@xxxxxxxxxxxx] 
> David Kemp wrote on 01/16/2007 06:07:48 PM:
>> 
>>  Is KDF an appropriate level of granularity for certificate-based
>>  constraints on the usage of public keys?   
>
> Well, only to those who strive for strict compliance to SP 800-56A, in the > face of application protocols allowing noncompliant KDFs. 

An application can comply with SP 800-56A recommendations, protocol
specifications, both, or neither.  This is independent of certificate
contents.  In fact, an SP 800-56 compliant application must refuse
to honor a non-compliant KDF specification contained in a certificate
either by refusing to derive a key using that cert or by substituting
a compliant KDF to use with the cert's public key.  (The latter
is admittedly shady behavior, but it is possible.)


>>  And if so, is it
>>  cryptographically appropriate to use a single public key size
>>  with both SHA-256 and SHA-384 KDFs?  
>
> Many in IETF have argued that a SHA-1 based KDF (such as the TLS's or
> IPSec's) provides 160 bits of security, so it is acceptable for use with
> 128-bit security, i.e. 256 bit ECC keys.  By the same argument, a SHA-256
> based KDF ought to be acceptable for an 384-bit ECC key.

Strict compliance with SP 800-56A says not.  The minimum bit length of the hash function for 384-511 bit ECC key is 384.  A SHA-256 based KDF is, however, acceptable for a 383 bit ECC key :-).

I'm not sure why SP 800-56A doesn't specify a maximum hash size.  Using
SHA-384 with a 160 bit ECC key would seem to provide less than the
implied amount of entropy for the derived key.

 
>>  Specifying a list of allowed features does not satisfy the design
>>  team's goal of using certificates to reduce protocol negotiation -
>>  if more than one KDF is possible with a pair of peer certificates,
>>  it is still necessary to negotiate which KDF to use.
>
> Doesn't it reduce negotiation?  Alice and Bob can state their crypto
> abilities using certs.  Then one of them chooses an algorithm in the
> intersection of the abilities, and tells the other that he/she's used it.
> The certs have saved the protocol from sending at least some "crypto
> capabilities" message flows.

That assumes that cert exchange occurs before algorithm negotiation,
which is not the case for RFC 4306 - the first cert request is
contained in the same message as algorithm acceptance.  Even if certs
were sent in the first two messages, they wouldn't reduce the
number of messages, and if multiple certs (e.g. RSA and ECC)
were sent before algorithm negotiation was done, the size of
the messages would go way up, not slightly down.


>>  So the extension approach allows a list of KDFs, but the RFC 4055
>>  approach does not.  I believe that a list is unnecessary because
>>  an ECMQV public key of a given size should imply the acceptable
>>  KDF size (or conversely, a key derive function should imply the
>>  acceptable public key size).
>
> I'm a little confused now.  While we're deprecating "with recommended"
> syntax, we're introducing a "family" syntax, where the crypto parameters
> (KDFs, etc.) are implicitly "recommended" by association with key size.
> This seems a paradoxical to me.

Good question.  I'd guess that the family OID means to use configured
or negotiated parameters if available, with recommended parameters as
a default if the application has no other guidance.  A
KDF-specific OID (including "with recommended" if it weren't
deprecated) means mandatory use of the specified parameters.  An
RFC would need to unambiguously specify the semantics of family OIDs.

Regards,
Dave