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

From: Russ Housley <[email-masked]>
Date: Wed, 01 Dec 1999 12:48:41 -0500

Denis Pinkas proposed the following:

    The protection afforded private keys is a critical factor in main-
    taining security.  On a small scale, failure of users to protect
    their private keys will permit an attacker to masquerade as them, or
    decrypt their personal information. [stuff about CA keys deleted]

Tim Polk countered with the following:

       A CA may include the key usage extension and assert the 
nonRepudiation bit
       when issuing a certificate.  This implies that a reliable third 
party will
       be able to determine the authenticity of signed data in the event of 
a dispute.
       If the certificate subject uses the private key in an insecure 
environment,
       it may be difficult to detect or prevent key compromise.  This could 
prevent a
       reliable third party from determining the authenticity of signed 
data.  A CA
       should consider the environment of the private key before asserting the
       nonRepudiation bit.

I have a problem with either paragraph being added to this 
section.  Consequences of detected and undetected compromise belong in the 
Security Considerations section, not here.

Russ

---

From: Paul Hoffman / IMC <[email-masked]>
Date: Wed, 01 Dec 1999 11:56:46 -0800

>Security Considerations section, not here.

I agree fully with Russ. There are dozens of places in this document where 
we could also talk about the problem of the signing party's key being 
compromised, and this one isn't all that important relative to the others.

--Paul Hoffman, Director
--Internet Mail Consortium

---

From: Tim Polk <[email-masked]>
Date: Thu, 02 Dec 1999 10:15:37 -0500

Russ & Paul,

I agree, the security considerations section is the right place to
address this.  Do you have a problem with the paragraph if it goes
there?

Thanks,

Tim

<excerpt>>Denis Pinkas proposed the following:

>Russ

</excerpt><<<<<<<<

---

From: Denis Pinkas <[email-masked]>
Date: Tue, 07 Dec 1999 18:47:55 +0100

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

=======================================
 
> Denis,
> 
> At 11:52 AM 11/25/1999 +0100, Denis Pinkas wrote:
> >Tim and Russ,
> >
> >> To people who still care about NR:
> >
> >I care.
> >
> 
> We thought you might. :-)
> 
> I've cut and pasted a bit to asssist those reading along at home... I trust I haven't altered your intent.
> 
> Our proposed text:
> > 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, excluding certificate or CRL
> > signing. In the case of later conflict, a reliable third party may
> > determine the authenticity of the signed data.
> 
> Your proposed text:
> 
> >" The nonRepudiation bit is asserted when the subject public key is
> >used to verify digital signatures used to provide a non-repudiation
> >service. When present, the nonRepudiation bit indicates that the
> >private key corresponding to the subject public key present in that
> >certificate may be used to indicate the user's conscious and willing
> >intent to endorse what is being signed."
> >
> 
> I prefer our text, since it sticks to the definition of the service. The certificate subject can use their private key for anything they'd like. The question for the key usage extension is, "Should I use this public key to implement this service?". I believe our text describes the general case, yours an important specific case.
> 
> Russ and I worked very hard to remove the word "intent" in our latest proposal. Intent can only be indicated through context, such as the signing policy that ETSI has proposed. This specification cannot do a thing to ensure that any particular signature was generated conciously and willingly.
> 
> Since our text includes your case, and ETSI is already working on the mechanisms to describe the signing context, I think our text is a good middle ground.
> 
> You also wrote:
> >I would also propose to add a note that explains the case of a
> >certificate having both the DS and the NR bits set and to place this
> >addition at the end of the whole section 4.2.1.3:
> >
> >" Note: A certificate with the nonRepudiation bit set should only be
> >used when it is possible to get full confidence of the environments
> >where the private key will be used. If a certificate has both the
> >digitalSignature and the nonRepudiation bit set, the entity owning
> >the private key should have full confidence of all the various
> >environments and applications where the private key will being used.
> >For the cases where that condidence cannot be obtained, 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."
> >
> >
> 
> I substituted "issued" for "used" in this paragraph. I'm assuming you are talking about how a CA determines *which* bits should be asserted. Is that right? On that assumption, I think it is a policy issue or a security consideration. [Side note: What do you mean by "full confidence"?] The next paragraph points to the policy for additional information.
> 
> The other possibility would be the security considerations section. It could build on the current text, which includes the folowing:
> 
> Adding the following paragraph might address your concern:
> 
> A CA may include the key usage extension and assert the nonRepudiation bit
> when issuing a certificate. This implies that a reliable third party will
> be able to determine the authenticity of signed data in the event of a dispute.
> If the certificate subject uses the private key in an insecure environment,
> it may be difficult to detect or prevent key compromise. This could prevent a
> reliable third party from determining the authenticity of signed data. A CA
> I know this text is very rough, but would this serve your purpose?
> 
> Thanks,
> 
> Tim

---

From: Ed Gerck <[email-masked]>
Date: Tue, 07 Dec 1999 10:50:26 -0800

> below, for values that are considered when validating such

Should I understand this suggestion as a substituion for the first
sentence or for the entire paragraph?  Either way, the suggestion
seems to cut the part where the *meaning* of the NR bit is
given.  The original text was:

So, I fail to see how the suggested text is better. In fact, I think it
turns back the clock some six months and we are again back
to nothing.

If you want to deprecate the NR bit, please say so.

> dispute, he may be held responsible of the data signed with this

"The owner of the private key should be warned" -- we are again back
some six months ago.  Non-repudiation cannot be imposed,
it has to be voluntary.  Why should the CA tell me that I may be
held responsible when the CA themselves says that they are never
responsible, provide no warranty, no assurances, yada yada?

> that private key.

*All the enviroments and the applications" -- can we be more less
assuming?  If even the CA refuses to accept responsibility for their
environment, I presume that the above text is fictional to the extreme
and unfair.  Besides, it is outdated by six months.

Again, the lack of a real-world model is apparent in the previous
work and percolates here.

> If that condidence can only be obtained in some

Dennis:

I see that we are back to nothing if we follow your suggestions.

Again, if you want to deprecate the NR bit, please say so.  This is
what the market, if not this list, will do if your suggestion is accepted
*over all the discussions here*.  Those issues that you want to
"introduce" now at the final round were already discussed and
rejected. Why discuss them to death over and over and over?

Cheers,

Ed Gerck

---

From: Stephen Farrell <[email-masked]>
Date: Tue, 07 Dec 1999 20:20:54 +0000

...some 100s of messages later...

> If you want to deprecate the NR bit, please say so.

YES!!! More and more everytime I see this discussion.

Actually, I did have the idea that we mandate that CAs
MUST set this bit randomly whenever a keyUsage extension
is present, just to stop people who argue that its absence 
has a meaning.

Stpehen.

-- 
____________________________________________________________
Stephen Farrell         				   
Baltimore Technologies,   tel: (direct line) +353 1 647 7406
61 Fitzwilliam Lane,                    fax: +353 1 647 7499
Dublin 2.                mailto:[email-masked]
Ireland                             http://www.baltimore.com