[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

Dan:

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

I care.  However, I do not see the certificate as the enforcement tool.  In the case of S/MIME, the SMIMECapabilities extension is used.  It tell the message originator the capabilities of the recipient.  If the recipient only offers "FIPS mode" algorithms, then those are the only ones that will be used by the message originator.  In the case of TLS and other protocols where real-time negotiation happens, either of the parties can ensure that "FIPS mode" algorithms are used, as long as both parties actually support them.

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.

RFC 4055 allows the parameters to be absent when used in the certificate subject public key information.  If they are present, then the MGF, for example, is carried there.

I would be happy with a similar arrangement for elliptic curve algorithms.  That is, we must have the same flexibility to omit the ECDH/ECMQV KDF.

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

The CA is the one that is signing the certificate.  A CA should not sign stuff that it does not understand, so it is involved in the ECDH/ECMQV KDF selection or the OAEP MGF selection if it is included in the certificate.

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

As said above, I'm okay with that as long as it is possible to omit the algorithm identifier parameters (as is allowed in RFC 4055) in a certificate subject public key.  Obviously, there are places where the same OID will be used where the parameters are required to be present (as is also the case in RFC 4055).

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

At the risk of repeating myself too much, I am not happy if the parameters to select the KDF are required.  I have no problem with one being present.

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?

Yes.

Russ