Subject: Re: proposed key usaged text -- the final round

From: "Aram Perez" <[email-masked]>
Date: Wed, 24 Nov 1999 13:35:39 -0800

Hi Tim and Russ,

Thanks for taking the effort to clarify and settling the key usage debate.
Below are a few comments...

> To people who still care about NR:
>
> In a last ditch hope of settling the key usage debate Tim Polk and I have
> made minor adjustments to the key usage text.  We hope that this is text
> that everyone can live with (but we know that there are some people who
> will feel compelled to argue on and on and on and on and on and on ...).
>
> We believe that the PKIX Working Group Chairmen will have to determine
> whether or not we have reached rough consensus or not.
>
> Thanks,
>    Tim Polk and Russ Housley
>
[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".

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

>
>        The meaning of the encipherOnly bit is undefined in the absence of
>        the keyAgreement bit.  When the encipherOnly bit is asserted and
>        the keyAgreement bit is also set, the subject public key may be
>        used only for enciphering data while performing key agreement.
>
>        The meaning of the decipherOnly bit is undefined in the absence of
>        the keyAgreement bit.  When the decipherOnly bit is asserted and
>        the keyAgreement bit is also set, the subject public key may be
>        used only for deciphering data while performing key agreement.
>
>     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.

Regards,
Aram Perez

P.S. I'm leaving shortly on vacation and will not be back until December 6,
so I won't read any responses until then. Have a great Thanksgiving!

---

From: Tim Polk <[email-masked]>
Date: Fri, 26 Nov 1999 14:27:04 -0500

Hi Aram,

[snip]
>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.

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

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.

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.  Others have rational arguments with 1) and 2).

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.

Thanks,

Tim Polk

>so I won't read any responses until then. Have a great Thanksgiving!

P.S. Hope you had a great vacation!

---

From: Stefan Santesson <[email-masked]>
Date: Mon, 29 Nov 1999 21:24:30 +0100

All,

My last trial to settle the dnQualifier topic drowned in the NR-bit struggle.

So I take the chance, during this apparent rest in the traffic, to bring
this up again for settlement.

What we need:
-------------
We need an attribute that we can use to store an identifier of a
certificate subject. This may be a unique identifier (sufficient to
identify the subject) or may act as a name distinguisher (sufficient to
identify the subject if combined with other names of the subject)

What do we have:
----------------
We have five candidate solutions, all with troubles. they are -

1) X.520 dnQualifier - the only attribute from rfc2459 with an intention
close to what we need. The problem is that using this attribute will break
the INTENT of this attribute according to X.520. This is also a solution
implemented by some vendors today.

2) X.520 serialNumber - Having the problem that it is defined for a device.
It is also only used with the object class device in X.501. It has however
been considered by X.500 standardization to change this to include support
for use with any type of "object". This is however not done yet and not
formally approved. It should also be noted that this is the current
solution of Finland, Sweden, Germany and probably more national electronic
ID-projects.

3) X.520 uniqueIdentifier - Having the problem that it is defined as a bit
string. This makes it impossible to display in any standardized way except
as a hex dump. Not a very useful format.

4) RFC 1274 uniqueIdentifier - Having the problem that is has an illegal
OID, together with all attributes defined under the PilotAttributeType
branch. This is in fact the same problem with the attribute domainComponent
also used in RFC2459 and the QC-profile, so using this attribute does not
introduce a new problem, but it makes the existing problem worse and more
critical.

5) To define a completely new attribute - Having the problem that we may
have a longer road to travel before this gets recognized and implemented in
proucts.

We need a solution that can be used consistently in the subject field in
son of RFC 2459 as well as in the QC profile.

So Please fellows.

This must be an important problem to solve for many of you out there,
affecting your products and implementations. So be active and propose
actions. Don't wait for others to solve this for you. Make your voice heard.

I hope we can solve this within a couple of weeks and perhaps make a straw
poll if consensus is hard to reach.

/Stefan 

-------------------------------------------------------------------
Stefan Santesson                <[email-masked]>
Accurata AB                     http://www.accurata.se
Slagthuset                      Tel. +46-40 108588              
211 20  Malmö                   Fax. +46-40 150790              
Sweden                        Mobile +46-70 5247799

PGP fingerprint: 89BC 6C79 5B3D 591B 8547  1512 7D11 DBF4 528F 29A0
-------------------------------------------------------------------

---

From: "Charles Moore" <[email-masked]>
Date: Tue, 30 Nov 1999 07:21:39 +1000

My suggestion is to take the same approach as the UTC/Generalised time and
several others todate..

a) Document the use of options 1 and 2 as they have already been implemented
and are in use...
b) Define a new attribute within the RFC something like 'distiguising
qualifier' with a discription something like "The Distinguishing Qualifier
attribute type specifies disambiguating information used to uniquely
identify a subject".

A value of the 'distiguising qualifier'  attribute identifies and conveys
qualifier information for the subject,and is only used if disambiguation is
required ( needed to meet privacy concerns, i.e to prevent national ID type
usage).

An attribute value for Distinguishing Qualifier is a string
distinguishingQualifier ATTRIBUTE ::= {
 SUBTYPE OF  name
 WITH SYNTAX  DirectoryString {ub-name}
 ID  id-at-distinguishingQualifier }

Text should state that the use of options 1&2 should be deprecated after say
2002....

My two cents worth...

Charles...

----- Original Message -----
From: Stefan Santesson <[email-masked]>
To: <[email-masked]>
Sent: Tuesday, November 30, 1999 6:24 AM
Subject: dnQualifier topic - not solved yet.

All,

My last trial to settle the dnQualifier topic drowned in the NR-bit
struggle.

What we need:
-------------

What do we have:
----------------

So Please fellows.

/Stefan