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

From: "Linn, John" <[email-masked]>
Date: Mon, 29 Nov 1999 16:49:23 -0500

The content looks good.  I've just one question and one editorial point.  In
the sentence re the NR bit, "This service protects against the certificate
subject falsely denying signing the data, excluding certificate or CRL
signing", I'm not sure how to interpret the scope and intent of the
"excluding" clause.  If a CA certificate has NR set, is the intent to say:
(a) that the certified CA is free to deny issuance of any certificate or CRL
it signs, (b) to state that the value of the NR bit is definitionally
irrelevant to the repudiability of issued certificates or CRLs as the scope
of the NR service is confined to usage on data other than certificates and
CRLs, or (c) to state that the question of semantics (if any) of NR for
certificate and CRL issuance is undefined in this specification, potentially
to be considered in policy documents?  I'll assume not (a), but it might be
useful to clarify towards (b) or (c). 

Editorially, under the paragraphs for keyAgreement and keyEncipherment,
"shall asserted" -> "shall be asserted". 

--jl

---

From: Peter Williams <[email-masked]>
Date: Tue, 30 Nov 1999 02:32:05 -0800

> -----Original Message-----
> From: Ed Gerck [mailto:[email-masked]]
> Sent: Thursday, November 25, 1999 10:01 AM
> Cc: Russ Housley; [email-masked]; [email-masked]
> Subject: Re: proposed key usaged text -- the final round
> 
> 
> 
> 
> Denis Pinkas wrote:
> 
> > I am not going to die with the proposed text :-) ...
> 
> But, perhaps we could all live with it ;-) and move on ....
> 
> > However, there are two sentences that are rather obscure or
> > not helpul and I would like to take advantage of some earlier
> > E-mail exchanges to canibalize these exchanges in order to
> > improve the text. The two last sentences of the section
> > explaining the NR bit could be deleted without loosing
> > much:
> >
> >   [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.
> 

What happens when two pieces of definitive NR evidence do
not agree?

http://www.imc.org/ietf-ediint/archive1/0003.html suggests that
digital signatures are not the only mechanism to achieve
NR (of receipt).

> I disagree -- the first sentence explains what the NR bit is used
> for (to verify digital signatures) in a specific context ( to provide
> a non-repudiation service), in contrast to explaining what the service
> is and why it would be useful to use it (protects against the
> certificate subejct falsely denying signing).
> 
> If you believe that it could be deleted without loosing much, and
> in fact something *is* lost, then it is IMO better to keep it 
> and be clear
> in a subject which has been unclear for far too long.  I 
> would rather we
> would not need to beat this horse dead an umpth-time.
> 
> > I propose to keep the first sentence unchanged and have the 
> following
> > global replacement for the three sentences:
> >
> > " 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 disagree -- is there anything more "rather obscure or not helpul"
> than "the user's conscious and willing intent"?  So, the change IMO
> is in contradiction with the purpose. Further, "to endorse" may have
> different legal meanings in different jurisdictions ("endorsement
> sans recourse" in the UK is one of the few that does not have legal
> consequences, but it needs to have the "sans recourse" appended
> to it and it is not valid in civil law regimes where almost 
> anything that
> you do flows back to the original agent -- you).
> 
> Finally, I would lint anything that predicates measuring, assessing,
> controlling or even estimating "the user's conscious and willing
> intent" in PKIX because if there is anything that no law, policy or
> dictatorship has ever managed to do is to control people's "conscious
> and willing intent" -- so, this is a slippery slope which was already
> debated, spotted and marked as leading nowhere in an Internet
> protocol; and debating this on and on and on and on will not change
> it or make it valid by repetition.
> 
> Gosh, if we can't even say *who* the sender is, *what* path did that
> message take, *if* the full communication of the sender with 
> all its follow
> up certified partial messages arrived or if there was a 
> partial or total denial
> en route which was blocked by an attacker, then how can we say what
> that unknown person in an unknown place with an unknown communication
> *intented* to say???
> 
> 
> > 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 do not want to sound in opposition to your entire email, but I also
> disagree. This is an "explanation mode" definition which is repetitive
> ("possible to get full confidence of the environments where 
> the private
> key will be used" and "should have full confidence of all the various
> environments and applications where the private key will being used");
> predicates an impossible condition (full confidence) in an overbroad
> context (all  the various environments where the private key will be
> used); indeterminate ("For the cases where that condidence cannot
> be obtained"); ineffective ("two different certificates ..."); and
> contradictory (why would two wrong certificates make a right one?)
> 
> Cheers,
> 
> Ed Gerck
> 
>

---

From: Tim Polk <[email-masked]>
Date: Tue, 30 Nov 1999 09:36:33 -0500

John,

Is see the confusion.  The answer is (b), the nonRepudiation bit is
irrelevant when validating the signature on a certificate or certifcate
status information (e.g., CRL or OCSP message).

Perhaps it would be clearer to simply say:

<paraindent><param>left</param>This service protects against the
certificate subject falsely denying signing the data.

</paraindent>

and add the following sentences to the next paragraph:

<paraindent><param>left</param>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.)

</paraindent>

Would this clear things up?

Gee, my quality control must be slipping!  Thanks for catching this 
one.

Thanks,

Tim Polk

---

From: "Linn, John" <[email-masked]>
Date: Tue, 30 Nov 1999 11:42:39 -0500

Tim,
 
Yes; that works for me.  Thanks.
 
--jl

-----Original Message-----
From: Tim Polk [mailto:[email-masked]]
Sent: Tuesday, November 30, 1999 9:37 AM
To: Linn, John; 'Russ Housley'; [email-masked]
Subject: RE: proposed key usaged text -- the final round

John, 

This service protects against the certificate subject falsely denying
signing the data. 

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

Gee, my quality control must be slipping! Thanks for catching this one. 

Thanks, 

Tim Polk