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

[Daniel Brown <DBrown@xxxxxxxxxxxx>]

Russ Housley <housley@xxxxxxxxxxxx> wrote on
01/17/2007 02:57:40 PM:

[> Dan Brown wrote on 01/17/2007 11:30 AM:] 
[>> 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.

> 
> I do not think that it is the role of the certificate to "enforce"
> compliance.  Rather, the application needs to be run in "FIPS
mode" 
> so that all of the choices necessary to conform to NIST guidance are
made.

Yes, Alice can run in FIPS mode, but she may also
like to tell Bob to please only secure email to her using FIPS mode.  Well,
perhaps, nobody else but me really cares?

Back to the original question: 4055 optionally allows
the cert to specify the MGF in OAEP.  So why not be able to specify
the KDF for ECMQV/ECDH in a cert?  I see these as analogous.

>> > 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.
> 
> So?  What does this have to do with the best way to represent
the 
> algorithm constraints in the certificate?

Nothing: I was only addressing David's specific question
of whether it's "cryptographically appropriate" to used mixed
sizes.

>> > 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. 
> 
> The closest thing that we have for something like this is 
> SMIMECapabilities.  In this case, the store-and-forward nature
of 
> email makes this a reasonable thing to do.  If real-time 
> negotiations are possible in the protocol, then keeping the CA out
> of the picture is desirable.

What extra involvement of the CA is there, when the
KDF (or MGF for OAEP) is specified in the cert?

>> > 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.
> 
> I interpreted the design team output to say that the family OIDs 
> would specify ECDSA, ECDH, and ECMQV without saying anything about
> the KDF at all.

So, with family OIDs, the protocol would determine/negotiate
the KDF.  That should be fine with David's preference of implied acceptable
KDF size, provided the protocol specifiers adhere to it.

I like this open functionality of family OIDs.  But
I think there should be an option to make them specific, less open-ended,
as is available in 4055, the design team proposal, and the X9.62 syntax.
 In retrospect, family-like OIDs could have easily been added to the
X9.62 syntax, simply by making the parameters field optional, then defining
their absence to mean that any (legal) parameter is allowed.  (E.g.
ecdsa-with-Specified, omitting the hash parameter.)

If we don't like lists, then PKIX can limit the list
length to 1, and still comply the X9.62 syntax.  If we need family
OIDs, then only a small tweak of X9.62 syntax is needed (as described above).

On the other hand, I like the gradual migration possibilities
of a critical/noncritical extensions.  Critical extensions are functionally
like 4055/X9.62, so the noncritical is the added value.  If the relying
party is understands the noncritical extensions, is he/she required to
comply with them?

Regards,

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