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

[Daniel Brown <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.

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

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

> 
> But to answer the question, the design team slides stated:
> 
> * Define an optionally critical certificate extension
>    - Sequence of Algorithm Identifiers, as in X9.62 parameters

Yes, that does it.

>    - Reuse X9 algorithm Identifiers
>        . Deprecating "with recommended"?
>    - Add three "family" OIDs (ECDSA, ECDH, ECMQV)
> 
> 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.  They're
are some distinctions: the "family" OIDs are meant for a cert,
whereas the "with recommended" OIDs are being deprecated at both
the cert and application level; also, some people would construe the "family"
OIDs to mean "any" acceptable crypto parameters are okay, not
that some parameters are "recommended"; but neither point completely
resolves my confusion.  I will go back to the design team slides to
see if it clarifies things for me, but I thought I'd raise this now, just
in case it helps anybody else.

Best regards,

Dan Brown
(905) 501-3857
http://www.certicom.com


> 
> ________________________________________
> From: Daniel Brown [mailto:DBrown@xxxxxxxxxxxx] 
> Sent: Tuesday, January 16, 2007 4:03 PM
> To: Kemp, David P.
> Cc: ietf-pkix@xxxxxxx
> Subject: RE: Straw poll for Algorithm Identifiers in Subject Public
Key Info.
> 
> 
> David P. Kemp wrote on 01/16/2007 12:21:27 PM:
> 
> > 
> > > - The structured algorithm OID is maybe not the hardest
to define
> > > but the worse alternative in every other aspect.
> > 
> > Agree.
> > 
> 
> Suppose that a subject has an ECMQV-only cert, and wishes to allow
> either SHA-256 or SHA-384 based KDFs, but no other KDFs.  Also,
the 
> EKU field says that the cert can be used for SMIME, IPSec, SSH, or
> TLS (suppose the private key is on the user's smart card).  The
X9.
> 62 "structured" approach allows for this.  How would
the other 
> approaches allow for this? 
>