Re: proposed key usaged text -- the final round

["Aram Perez" <aram@xxxxxxxxx>]

Tim Polk wrote:

> Hi Aram,
> 
> I At 01:35 PM 11/24/1999 -0800, Aram Perez wrote:
>>Hi Tim and Russ,
>>
>>Thanks for taking the effort to clarify and settling the key usage debate.
>>Below are a few comments...
>>
> [snip]
>>>
>>>        The dataEncipherment bit is asserted when the subject public key
>>>        is used for enciphering user data, other than cryptographic keys.
>>
>>I'd would change "enciphering user data" to "enciphering data".
>>
>
> At the moment, I can't think of a technical reason to retain "user" in that
> phrase.  However, that bit of text has been stable since at least draft 5
> (July '97).  The word user doesn't add much, but is it *really* a problem?
>
> My inclination is to leave it alone unless it is really broken.

I believe a few other folks agree that it should be dropped. It does not add
anything and it raises the question "What's the difference between 'user
data' and just plain 'data'?"

>
>>>
>>>        The keyAgreement bit is asserted when the subject public key is
>>>        used for key agreement.  For example, when a Diffie-Hellman key is
>>>        to be used for key management, then this bit shall asserted.
>>>
>>>        The keyCertSign bit is asserted when the subject public key is
>>>        used for verifying a signature on certificates.  This bit may only
>>>        be asserted in CA certificates.  If the keyCertSign bit is
>>>        asserted, then the cA bit in the basic constraints extension (see
>>>        4.2.1.10) MUST also be asserted. If the keyCertSign bit is not
>>>        asserted, then the cA bit in the basic constraints extension MUST
>>>        NOT be asserted.
>>>
>>>        The cRLSign bit is asserted when the subject public key is used
>>>        for verifying a signature on revocation information (e.g., a CRL).
>>
>>Neither of you responded to my previous comment on this bit. If cRLSign bit
>>is asserted, must the cA bit in the basic constraints extension also be
>>asserted? And vice-versa?
>>
>
> My apologies for the lack of a response.  I have been swamped since we
> posted the text.
>
> There is no direct relationship between the cA bit in basic constraints and
> the cRLSign bit in key usage.  Consider a subject that issues indirect CRLs
> but does not generate certificates.  In this case, the cRLSign bit would be
> set, but the cA bit in basic constraints and the keyCertSign bit in key
> usage would not be set.
>
> Alternatively, CAs may not issue CRLs; they may rely on indirect CRLs or
> OCSP for example.  In that case, the cA bit in basic constraints and the
> keyCertSign bit in key usage would be set; the cRLSign bit would not.
>
> Would a brief note stating that no relationship exists clarify matters?
> Perhaps the following would do?
>
>         The cRLSign bit is asserted when the subject public key is used
>         for verifying a signature on revocation information (e.g., a CRL).
>         [Note: Unlike the keyCertSign bit, there is no relationship
>         between the value of cRLSign and the basic constraints extension.]

Yes, I think this would clarify the description.

>
>
>>>     This profile does not restrict the combinations of bits that may be
>>>     set in an instantiation of the keyUsage extension.  However,
>>>     appropriate values for keyUsage extensions for particular algorithms
>>>     are specified in section 7.3.
>>
>>Again, neither of you responded to my previous comment on at least
>>recommending against certain combinations.
>>
>
> See apology above.  From your email on 11/17:
>>I think this is a mistake and causes confusion. In an extreme example, since
>>there is no restrictions, I could have a certificate that has all the bits
>>set. This means that I can do the following with my asymmetric key pair:
>>
>>1) sign for entity authentication and data origin authentication with
>>integrity,
>>2) sign with a non-repudiation service,
>>3) encrypt keys for transport using RSA like algorithms,
>>4) encrypt data,
>>5) exchange keys using D-H like algorithms,
>>6) sign certificates,
>>7) sign CRLs,
>>8) encrypt data using D-H like algorithms, and
>>9) decrypt data using D-H like algorithms.
>>
>>
> That's true.  That is also the case if the key usage extension isn't
> included in the certificate.
>
> We rely on the algorithm text (section 7.3) to recommend against
> combinations that don't make sense cryptographically.  (That is, if the
> public key is a DSA key, don't asssert keyEncipherment or
> dataEncipherment.) I expect that is all this group can do.

I still believe that stating the profile "does not restrict the combinations
of bits" is a mistake. This means that there will be compliant software that
has invalid keyUsage bit combinations.

>
> More from 11/17:
>>At a minimum, the profile should list the combination of bits which are not
>>allowed. A few examples:
>>
>>1) If keyCertSign is asserted, then the only other bit that can be asserted
>>is the cRLSign bit.
>>2) If cRLSign is asserted, then the only other bit that can be asserted is
>>the keyCertSign bit.
>>3) If keyEncipherment is asserted, then keyAgreement MUST NOT be asserted.
>>
>>
> There has been a lot of debate here, and in other groups, about which
> combinations should be permitted or forbidden.  There are lots of different
> opinions.  For example, I personally could accept 1) and 2) but not 3).
> There are algorithms that would let me use my RSA key for key agreement or
> my elliptic curve key for key transport. I don't think I should need two
> certificates to support that.

You lost me here Tim. I've never seen an X.509 certificate for both an RSA
key and an elliptic curve key. Unless I've completed missed something, you
MUST have certificate for your RSA key and another certificate for your
elliptic curve key.

>  Others have rational arguments with 1) and 2).

Just because there are rational arguments does not mean that they are
"secure arguments". I've asked the question and I will ask it again: "If we,
who claim to be the security experts, can't agree on these issues, how is
the general population going to know what to do?

>
> IMHO, there is absolutely no chance that this group would ever reach
> consensus on which combinations should be restricted.  It is rathole as
> dark and deep as the NR bit!
>
> Besides, PKIX client systems need to handle any combinations of key usage
> bits for the sake of interoperability.  As long as path building is "hard",
> people will try to limit the number of certificates they generate by
> asserting all (cryptographically) reasonable bits.

But they should be asserting all (cryptographically and security-wise)
reasonable bits.

Regards,
Aram Perez