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

From: "Aram Perez" <[email-masked]>
Date: Tue, 07 Dec 1999 10:38:54 -0800

Denis Pinkas wrote:

> Tim,
> 
> I did not realized that the ball was rolling in my camp and thus I
> needed to send you a response.
> I would like first to summarize where we are. Keeping the first
> sentence unchanged and adding the text you proposed to solve both my
> issue and John Linn issue we come to the following normative text:
>
> The nonRepudiation bit is asserted when the subject public key is
> used to verify digital signatures used to provide a non-repudiation
> service. The values of the digitalSignature and nonRepudiation bits
> are not considered when validating the signature on certificates or
> certificate status information (see keyCertSign and cRLSigning,
> below, for values that are considered when validating such
> signatures.)
>
> Thenafter I agree that warnings should be moved in the security
> consideration section. So the only remaining point should be to
> agree on that text. You proposal was missing the case of the two
> bits set. Here is a new attempt:
>
> "A CA may include the key usage extension and assert the
> nonRepudiation bit when issuing a certificate. When such a
> certificate is delivered, it implies that the owner of the
> corresponding private key should be warned that, in the event of a
> dispute, he may be held responsible of the data signed with this
> key.
>
> If a certificate has both the digitalSignature and the
> nonRepudiation bit set, the owner of the private key should make
> sure that all the environments and applications where the
> corresponding private key is being used do not allow a misuse of
> that private key. If that condidence can only be obtained in some
> environments, two different certificates, one with one public public
> key and the digitalSignature bit set and another one with a
> different public key and the nonRepudiation bit set, should be used,
> so that the private key corresponding to the certificate with the
> nonRepudiation bit set is only used in secure environments."
>
> Regards,
>
> Denis

I like Denis' suggestions and I agree that "warnings should be moved in the
security consideration section".

Regards,
Aram Perez

[snip]

---

From: Tim Polk <[email-masked]>
Date: Tue, 07 Dec 1999 15:30:50 -0500

Folks,

With Aram and Denis back in the fray, I think we can finish this one off.
I have incorporated all the changes, and think we may be nearing consensus!
 There are two pieces of proposed text; text for the key usage extension
and text for the security considerations section.

Please read it carefully.  In general, the changes were all introduced on
the list in the "porposed" thread, but I have tweaked a couple of other
paragraphs.  The only real suprise is that I capitulated and deleted the
word "user" under dataEncipherment.  I thought keeping it would be less
controversial, but that wasn't true!  I don't think it added anything, so
let's delete it.

Thanks,

Tim Polk

 parties.---- Proposed text for 4.2.1.3 Key Usage

4.2.1.3  Key Usage

    The key usage extension defines the purpose (e.g., encipherment, sig-
    nature, certificate signing) of the key contained in the certificate.
    The usage restriction might be employed when a key that could be used
    for more than one operation is to be restricted.  For example, when
    an RSA key should be used only for signing, the digitalSignature
    and/or nonRepudiation bits would be asserted. Likewise, when an RSA
    key should be used only for key management, the keyEncipherment bit
    would be asserted. When used, this extension SHOULD be marked criti-
    cal.

       id-ce-keyUsage OBJECT IDENTIFIER ::=  { id-ce 15 }

       KeyUsage ::= BIT STRING {
            digitalSignature        (0),
            nonRepudiation          (1),
            keyEncipherment         (2),
            dataEncipherment        (3),
            keyAgreement            (4),
            keyCertSign             (5),
            cRLSign                 (6),
            encipherOnly            (7),
            decipherOnly            (8) }

    Bits in the KeyUsage type are used as follows:

       The digitalSignature bit is asserted when the subject public key
       is used with a digital signature mechanism to support security
       services other than non-repudiation (bit 1), certificate signing
       (bit 5), or revocation information signing (bit 6). Digital signa-
       ture mechanisms are often used for entity authentication and data
       origin authentication with integrity.

       The nonRepudiation bit is asserted when the subject public key is
       used to verify digital signatures used to provide a non-repudiation
       service.  This service protects against the certificate subject falsely
       denying signing the data.  In the case of later conflict, a reliable
       third party may determine the authenticity of the signed data.

       The values of the digitalSignature and nonRepudiation bits are not
       considered when validating the signature on certificates or certificate
       status information.  Further distinctions between the digitalSignature
       and nonRepudiation bits may be provided in specific certificate
       policies.  The values of the digitalSignature and nonRepudiation bits
       is insufficient to determine the intentions of the certificate subject.
       The context in which the data was signed MUST also be considered.  A
       signature policy identifier embedded in the signed data MAY be used to
       explicitly provide context.

       The keyEncipherment bit is asserted when the subject public key is
       used for key transport.  For example, when an RSA key is to be
       used for key management, then this bit shall be asserted.

       The dataEncipherment bit is asserted when the subject public key
       is used for enciphering data other than cryptographic keys.

       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 be 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).
       Note: Unlike the keyCertSign bit, there is no relationship
       between the value of cRLSign and the basic constraints extension.

       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,
    valid combinations of bits are specified for particular algorithms
    in section 7.3.

--- proposed new paragraphs for Security Considerations section

    A CA may include the key usage extension and assert the
    
    If a certificate has both the digitalSignature and the
    nonRepudiation bit set, the owner of the private key should make
    sure that all the environments and applications where the
    corresponding private key is being used do not allow a misuse of
    that private key. If that confidence can only be obtained in some
    environments, two different certificates, one with one public
    key and the digitalSignature bit set and another one with a
    different public key and the nonRepudiation bit set, should be used,
    so that the private key corresponding to the certificate with the
    nonRepudiation bit set is only used in secure environments.

---

From: Ed Gerck <[email-masked]>
Date: Tue, 07 Dec 1999 13:46:04 -0800

> and text for the security considerations section.

No comments.  The key usage text looks fine.

> --- proposed new paragraphs for Security Considerations section

Here, I have some comments.

>     nonRepudiation bit when issuing a certificate.

This part is fine.

> When such a

I am not in favor of this entire sentence.  It fixes a context for the
NR bit which *contradicts* the key usage section (for example: "A
signature policy identifier embedded in the signed data MAY be used to
explicitly provide context.") and it unduly imposes upon the owner
of the private key a duty which the signer herself (the CA, that elusive lady)
refrains from, for example: in the case of virus, fraud, etc,. These are valid
cases and if they would be reflected in the text, we would have a repeat of a
CA's CPS, I am afraid.

So, "when such a certificate is delivered, it implies that" is not a matter to
be solved here. Rather it MAY be solved in a signature policy identifier
embedded in the signed data, it MAY be solved in the CA's CPS, etc., all
as already predicated in PKIX.

Suggestion: delete the sentence.

>     that private key.

I am not in favor of this entire sequence.  It is not realistic that the
owner of the private key "should make sure that all the
environments and applications where the corresponding private key is
being used" is anything.  The most we can ask is a reasonable effort,
which may not be much in the case of virus, fraud, theft, etc.  To say
otherwise is to put on the certificate subject's a burden which not even
highly-qualified CAs want to shoulder.

Suggestion: A toned-down statement might be useful, such as:

    If a certificate has both the digitalSignature and the
    nonRepudiation bit set, the private key owner should take
    justified measures to prevent a misuse of that private key.

Of course, "justified measures" are commensurate to cost and risk,
which means that the above statement is even more effective than
the original to define what the keyholder's responsibilities are (for
example, a private key used to sign money transfer justifies a
need for more precautions than a private key used to sign email messages
in a mailing list) -- and avoids the trap of requiring the whole world
to be secure. An untainable goal, which could easily make the original
clause moot by excessive requirements (not even CAs can do this).

Note: I have, on purpose, avoided the terms "reasonable measures"
because reasonableness may be difficult to define in the technical
sense, while a justification can be a letter from the ISP on which
one relies upon without (usually) further checking.

>  If that confidence can only be obtained in some

I am not in favor of this addition, which seems obvious (do not set the
NR bit unless you want to set the NR bit), costly (two certificates) and
unnecessary -- since I can use only one certificate with the NR bit set
and deny NR directly in the signed data, case by case (NR opt out mode).
Or, I can use only one certificate with the NR bit off and grant NR directly
in the signed data, case by case (NR opt in mode).

If one thinks though that saying something is necessary, I suggest, in
agreement with the change proposed above:

 If the private key owner can only prevent misuse in some environments, 
 then it is possible to use a certificate with the nonRepudiation bit 
 set and deny non-repudiation in the signed data, case by case (NR opt
 out mode); or use a certificate with the nonRepudiation bit off and
 grant non-repudiation in the signed data, case by case (NR opt in
 mode); or use two different certificates, one with one public key and
 the digitalSignature bit set and another one with a different public
 key and the nonRepudiation bit set; or use another method that could
 be justified, so that the private key corresponding to the certificate
 with the nonRepudiation bit set is not used in environments that may 
 either not conform to a non-repudiation signature policy, or be unknown.

Cheers,

Ed Gerck

---

From: Denis Pinkas <[email-masked]>
Date: Thu, 09 Dec 1999 16:51:47 +0100

Ed,

> No comments.  The key usage text looks fine.

Good ! (pending a small change requested by Aram which seems quite
reasonable).

 
 
> Suggestion: delete the sentence.

This is the implication of that bit, as far as the user is
concerned. Your argumentation saying that "it MAY be solved in a
signature policy identifier embedded in the signed data, it MAY be
solved in the CA's CPS, etc" is not valid. If I re-use the example I
used during my presenation at the last PKIX session in Washington,
the user should really be warned, e.g. not to insert his key in an
unknown door lock so that instead of getting the door opened he
unknowingly signs a check of 5.000 $. There may be alternatives to
the proposed wording, but the warning should be kept. Do not forget
that this belongs to the security considerations section, where
warnings are fully appropriate. 

>     justified measures to prevent a misuse of that private key.

I think your sentence creates more problems than the original one.
Some people might argument: what means a "justified measure" ? The
original sentence should be kept.

>  either not conform to a non-repudiation signature policy, or be unknown.

Your proposed text is much more complicated to follow (and longer)
than the original one. It introduces notions which are not explained
in that document e.g. "NR opt out mode" ?!?" and "NR opt in mode"
?!? is also incorrect on several aspects; e.g. you said: " If the
private key owner can only prevent misuse in some environments, then
it is possible to use a certificate with the nonRepudiation bit set
[...] case by case". I do not think that the user, in *any* case,
should use (the corresponding private key of) a certificate with the
nonRepudiation bit set, if he cannot prevent the misuse of his
private key.

Tim, the editor, could apparently live with the original proposal.
Let us keep the original text, if you can also "live with it". :-)

Regards,

Denis

---

From: Ed Gerck <[email-masked]>
Date: Fri, 10 Dec 1999 00:43:50 -0800

Denis Pinkas wrote:

> Ed Gerck wrote:

Yes.

> > I am not in favor of this entire sentence.
> ....
>  If I re-use the example I
> unknowingly signs a check of 5.000 $.

Or not. It depends on the CA's CPS, on what is disclaimed by the user
in the signed data, etc.  My objection to that text segment is that PKIX
is not the party that should "warn" the user of anything, or mandate that
the user "should be warned" -- such "warning" is outside the scope of
PKIX in the same way that the CPS is outside the scope of PKIX.

> There may be alternatives to

But not for warnings that lie outside the scope of PKIX. For example, the
user  is not warned to set the date correctly in his computer -- and yet,
setting a wrong date may make an expired certificate, valid.  The
justification/negation of user actions, or lack of actions,  lie outside the
scope of PKIX in the same way that justification of CA's actions are not
the concern of PKIX.

> > I am not in favor of this entire sequence.
> >....

Your point is well taken. Perhaps an even more toned-down note would
be useful, for example:

     If a certificate has both the digitalSignature and the
     nonRepudiation bit set, the private key owner should take
     measures to prevent a misuse of that private key.

where not even justification is predicated -- leaving the user
responsible for deciding "how", while PKIX clearly warns
about "what" should be protected when the NR and DS bits
are set.

> > I am not in favor of this addition, which seems obvious
> ....
> >...
> than the original one.

Your point is well taken. I go back to my first suggestion to simply delete
the addition. Seems less confusing at this time.

Cheers,

Ed Gerck

---

From: Denis Pinkas <[email-masked]>
Date: Fri, 10 Dec 1999 10:46:50 +0100

Ed,

I would like to leave the bandwith of the PKIX mailing list for
other topics and thus I am not going to argument for ever on that
topic. So, (I do hope that) this is my last reply to you on that
topic and I let Tim, the editor, take the final decision. 

> PKIX in the same way that the CPS is outside the scope of PKIX.

Your two arguments can be refuted:

1) CA's CPS will say that key that has the NR bit set has NR
properties for everything signed with that key.
So if someting is maliciously signed, it becomes rather hard for the
user to say that it was maliciously obtained. He has to make sure
that nothing can be maliciously signed using that key. The
environment where the key is being used should have a "What You See
Is What You Sign" (WYSIWYS) property.

2) In the example no disclaimer can be placed by the user because he
does not know what he signs while opening the door.

So we currently end up with a simple conclusion: we simply disagree.

> scope of PKIX in the same way that justification of CA's actions are not

I would have no problem to extend warnings to the case you describe.
So I do not take this as an argument.

>      measures to prevent a misuse of that private key.

Your proposal is missing the fact that the measures are related to
the environments where the key is being used. It may be sufficiently
explicit for you, but it would become hard to understand for the
novice. 

> the addition. Seems less confusing at this time.

You cannot say above " this addition [...] seems obvious " and a few
lines later "delete the addition. Seems less confusing at this
time". It cannot be both obvious and confusing.

Ed, I have done my best to answer your E-mails. We cannot argument
for ever. 

Tim, the final decision is yours.

Regards,

Denis

---

From: Ed Gerck <[email-masked]>
Date: Fri, 10 Dec 1999 08:57:38 -0800

Denis:

My disagreement with you is not a matter of
opinion, but in basics. What you propose is
outside the scope of X.509.  Section 1 states
(my inserted *):

 Authentication (and other security services [including
 thus non-repudiation]) can only be provided within
 the context of a defined security policy. It is a matter for
 users of an application to define *their own* security
 policy which may be *constrained* by the services
 provided by a standard.

Further, the general scope of X.509 is *authentication*,
the verification of user credentials. What the user signs
with those credentials is outside the scope of X.509  --
the user is in no way constrained on the content, meaning
or legal implications of what is signed.

So, PKIX MAY constrain the security policies that users
can define but PKIX MUST NOT define that security
policy, NOR what it must include, NOR the legal or otherwise
any implication of what is signed.  PKIX  MAY only say
what a user's security policy MUST NOT allow -- and even
so, ONLY in regard to the scope of PKIX (authentication of
user credentials).

And, this makes pretty good sense. Why should it be
desirable, as you wish, for PKIX to impose upon
users the non-technical burden of risk for the *data*
signed with  a key when X.509 is moot on what is signed
and even on how users should verify what is signed prior
to signing?  And, what does this have to do with security
considerations on *private-keys* in PKIX -- are you really
still constraining user security policies for keys when you
set a mock criminal code  for data that is signed by keys?
After all, PKIX *refuses* to warn CAs on *any* security
risks in that very same NR security discussion you propose --
and thus CAs can become the back-door of user security
if one follows what you suggest and shift the burden of risk
100% to the user.

So, following your suggested additions and forceful defense
of them, I am forced to conclude that even though PKIX is not
willing to trust users to take the necessary precautions, it
does expect them to take the risk of failing to take the
precautions. Is this a fair conclusion?

Your suggestion is therefore: (i) not in accord with X.509
design framework (Section 1) and, (ii) does not allow
risk to be well balanced between user and CA.  In
effect, your suggestion *interferes* with the CA-user
relationship -- which is hands-off by design in X.509,
and intends to *impose* rules on the consequences
of content signed by users -- which is clearly outside
the scope of X.509.

Further, what you propose would amount to an
overreaching security policy set by PKIX over *all*
users, while any  CA is free to do whatever they
want and even to treat different users differently.

Note also that X.509 refrains from setting security
policies even for user identification (this is also
in accord with X.509 Section 1 cited above).  For
example, X.509 Section 11.2.a states that: "a
certification authority shall be satisfied of the
identity of a user before creating a certificate for
it",  which means that identity validation procedures
are to be satisfied in the CA's frame of reference by
following the CA's own rules (CPS), which are
declared outside the scope of X.509 and can be
entirely different for different CAs and even for
different users in the same CA.

So, what is this all about? It is about NOT including the
following text segments in PKIX security discussions,
for the reasons inlined:

1. NOT include:
 When such a  certificate [with NR bit set] is delivered, it
 implies that the owner of the corresponding private key
 should be warned that, in the event of a dispute, he may
 be held responsible of the data signed with this  key.

REASON:  Setting user's security policy on the data
*signed* by the user is outside the scope of PKIX.
The text seems to intend to allow CAs to hide behind
PKIX in order to impose upon users a burden which
not even CAs accept for the data they sign with their
own key.  Obviously, this would be unfair and is not
what this WG should recommend.

2. NOT include:
 If a certificate has both the digitalSignature and the
 nonRepudiation bit set, the owner of the private key
 should make sure that all the environments and
 applications where the corresponding private key is
 being used do not allow a misuse of that private key.

REASON: Obviously impossible -- the user has no way of
knowing that *all* the environments and applications where the
corresponding private key is being used do not allow a misuse of
that private key.  Further, setting user's security policy is outside
the scope of PKIX -- especially so in *applications*.

3. NOT include:
 If that confidence can only be obtained in some
 environments, two different certificates, one with one public
 key and the digitalSignature bit set and another one with a
 different public key and the nonRepudiation bit set, should be
 used, so that the private key corresponding to the certificate
 with the nonRepudiation bit set is only used in secure
 environments.

REASON: Obviously, the private key corresponding to any
certificate [not only NR] should only used in secure
environments, where "secure" is a concept relative to risk
and cost.  Besides, X.509 *already* says this in "One of the
basic principles of strong authentication is that the user’s
private key remain secure. A number of practical methods
are available for the user to hold his private key in a
manner that provides adequate security".

Cheers,

Ed Gerck

PS: My early attempt to "save" some of your suggestions by
editing them to be in accord with X.509's factual text has
been unfruitful. Therefore, it seems better to me to just
delete them. This is however a matter of opinion and I would
welcome (as a second option) that number (2) and (3) be
edited. However, I see nothing of substance that would be
left if (1) is edited to reflect X.509 as an authentication spec,
not a one-sided surreptitious criminal code on content
signed -- as currently implied by it.