Subject: RE: 3280bis: key usage (13)

From: "Kazin, Joel" <[email-masked]>
Date: Fri, 27 May 2005 08:19:49 -0500

The core problem is labeling the bit non-repudiation.  It goes against the
legal idea that you can attempt to repudiate your alleged actions even when
your defense is weaker than "the cat ate my homework".  To me,
non-repudiation is more of a marketing description than a technical,
contractual, or legal description of what the signer intended to do.  

A secondary problem is that the non-repudiation bit doesn't tell a relying
party or third party enough.  The logical place to look for such information
is in the id-ce-certificatePolicies extension.  Was the
id-ce-certificatePolicies extension part of the original x.509 v1
specification?  If that is true, then perhaps the non-repudiation bit is
just a holdover from the original x.509 v1 certificate definition?  If my
arguments are true then we can: 1) keep calling it non-repudiation and
strongly deprecate its use, 2) change the name and deprecate its use, 3)
change the name and allow its use. I favor 1 over 2 over 3.  

At 07:06 AM 5/27/2005 -0500, Stefan Santesson wrote:

Speaking as implementer and not design team member, I can live with both 
texts since they allow me to do the same thing. 

It allows my low level application to add a digital signature supported 
by the digital signature bit, where the intention of that application is 
to add integrity and origin authentication, while the use of the 
signature in practice (higher layers) ends up being used as evidence of 
some kind of commitment. 

Example. An e-mail application adds an arbitrary signature supported by 
the DS bit, while the body of the text reads "Through the digital 
signature on this e-mail I commit to....). This is now a perfectly valid 
scenario according to both texts. 

The real defect that was fixed was that the digital signature bit said 
that it was for purposes "other" than NR. That is now gone in both 
standards. 

I agree to Stephen's rationale to keep the name nonRepudiation. It is 
not worth the cost to change the name. Stephen's point here was missing 
in the X.509 discussions of a name change. 

Stefan Santesson 
Program Manager, Standards Liaison 
Windows Security 

> -----Original Message----- 
> From: [email-masked] 
[mailto:[email-masked] <mailto:[email-masked]> ]

> On Behalf Of Denis Pinkas 
> Sent: den 27 maj 2005 12:29 
> To: Stephen Farrell 
> Cc: Hoyt L Kesterson II; pkix 
> Subject: Re: 3280bis: key usage (13) 
> 
> 
> Stephen, 
> 
> I agree with everything Hoyt said on bit 1. 
> 
> However, there are two sides for this coin : bit 0 and bit 1. 
> 
> Both are again copied below: 
> 
> ISO Corrigendum: 
> 
>      a) digitalSignature: for verifying digital signatures that are 
used 
>         with an entity authentication service, a data origin 
> authentication 
>         service or/and an integrity service; 
> 
> 3280bis: 
> 
>      The digitalSignature bit is asserted when the subject public key 
>      is used with a digital signature mechanism to support security 
>      services other than certificate signing (bit 5), or CRL signing 
>      (bit 6).  Digital signature mechanisms are often used for entity 
>      authentication and data origin authentication with integrity. 
> 
> The current text of 3280bis for bit 0 (ds) is incompatible with the 
ISO 
> Corrigendum. 
> 
> As Hoyt already said, any new text should align with the definition in 
the 
> approved technical corrigenda against the 4th edition and in the 
upcoming 
> 5th edition. 
> 
> Denis 
> 
> > Hi Hoyt, 
> > 
> > Hoyt L Kesterson II wrote: 
> > 
> >> Stephen 
> >> 
> >> I am somewhat dismayed at your reaction to the new text in X.509. 
> > 
> > 
> > I'm sorry about that, but I guess I'm just fed up with the 
> > NR bit, though I can understand how people who've worked 
> > hard to try fix it might be dismayed. 
> > 
> > (BTW: I once suggested that CAs MUST set this bit randomly 
> > since that was the only way I could see to kill it off 
> > properly. If you can get that into X.509 then I'd be happy 
> > for 3280bis to align:-) 
> > 
> >  > I am not going to argue with you here (maybe in a bar the next 
time 
> >  > we run into each other). 
> > 
> > Good idea! 
> > 
> >> However, I do want to mention several points. 
> >> 
> >> 1) I initiated the change in text because of the various 
> interpretations 
> > 
> >  > by implementors that were resulting in non-interoperable 
> >  > implementations. It was a conversation with a PKIXer at a RSA 
> >  > conference a few years ago that caused me to articulate a private 
> >  > concern. 
> > 
> > I agree that everything connected with this bit has been 
> > confused and remains so. 
> > 
> >> 2) The legal community was very confused. There was even a 
> > 
> >  > paper castigating the standard developers for mandating that 
> >  > one could not repudiate an action. 
> > 
> > Maybe the mistake was defining a bit that laywers care about? 
> > 
> >> 3) There were several meetings held where there was significant 
> > 
> >  > participation by people in the IETF PKIX group (as well as 
> >  > lawyers). All agreed there was a problem with the published text. 
> >  > Denis and I argued long and hard over wording but we didn't 
> >  > disagree on the need for new text and its general intent. 
> > 
> > Fair enough. 
> > 
> >> 4) Russ was concerned that change would cause a problem 
> > 
> >  > with existing IETF standards and was not too happy with a 
> >  > change to the name of the bit. That's why I put the line 
> >  > in that you referenced. However, that was to grandfather 
> >  > existing text, not to allow new text to continue using 
> >  > the old term and definitions. 
> > 
> > Ok. Here's the real reason not to change: Many people use 
> > ASN.1 compilers which means that names from the ASN.1 
> > module end up being directly used in higher layer code. 
> > Changing the name causes that code not to compile. I'd 
> > say that there's quite a lot of 3280 code in the world 
> > at this stage. So, if the semantics isn't supposed to 
> > have changed (and I assume that is meant to be the 
> > case) then this cost just doesn't seem worthwhile. 
> > 
> >> 5) It is the definition that is important. I recommend 
> > 
> >  > that any new text align with the definition in the approved 
> >  > technical corrigenda against the 4th edition and in 
> >  > the upcoming 5th edition. 
> > 
> > While I'd rather not see any more text added on this, 
> > (there's been way too much already) I wouldn't have a big 
> > issue with trying to help a reader make sense of the 
> > fact that 3280bis and x.509 name this bit differently. 
> > 
> > However text like the sentence below is IMO almost 
> > certain to cause even more confusion: 
> > 
> >   The precise type of commitment of the signer e.g. "reviewed 
> >   and approved" or "with the intent to be bound", may be 
> >   signalled by the content being signed, e.g. the signed 
> >   document itself or some additional signed information. 
> > 
> > That sounds like the sole purpose of the CC-bit is as 
> > a flag to indicate when some other bits somewhere else 
> > tell you what the CC-bit means. 
> > 
> > So in the absence of some better text I think that 3280bis 
> > is better off just saying "NR a.k.a. CC" as it currently 
> > does. 
> > 
> > Regards, 
> > Stephen. 
> > 
> >> 
> >> At 14:49 +0100 5/26/05, Stephen Farrell wrote: 
> >> 
> >>> Denis, 
> >>> 
> >>> 
> >>>> Please align with the the ISO-ITU text. 
> >>> 
> >>> 
> >>> Do you mean we should rename the bits and include the 
> >>> other new x.509 text? The design team were against 
> >>> doing that. 
> >>> 
> >>> Is there any (good) reason other than alignment to 
> >>> make such a change? 
> >>> 
> >>> Personally, I find the new x.509 text worse, although 
> >>> it does say: "Note that it is not incorrect to refer to 
> >>> this keyUsage bit using the identifier nonRepudiation." 
> >>> So I can argue that we are aligned, just not identical. 
> >>> 
> >>> But of course, I'm from the non-repudiation is non-sense 
> >>> camp so I may not be the best judge. 
> >>> 
> >>> Stephen. 
> >>> 
> >>> PS: A quibble: 
> >>> 
> >>> 
> >>>>  The new text in X.509 aligns with the text in RFC 3280.  No 
changes 
> >>>>  are required to 3280bis.  A comment has been added to the ASN.1 
for 
> >>>>  KeyUsage stating that "recent editions of X.509 have renamed 
> >>>>  [the nonRepudiation] bit to contentCommitment" 
> >>>> 
> >>>> This statement is untrue. 
> >>> 
> >>> 
> >>> The paragraph to which I assume you refer contains 3 
> >>> statements - it'd be easier to close these threads if 
> >>> you were more precise. (I think I got what you want 
> >>> by the end of the mail though...) 
> >>> 
> >>> PPS: "This statement is untrue." 
> >>>    Are you from Crete after all? :-) 
> >>> 
> >>> 
> >>> 
> >>> 
> >>> Denis Pinkas wrote: 
> >>> 
> >>> 
> >>>> To the list, 
> >>>> 
> >>>> The disposition of comments states: 
> >>>> 
> >>>> 13) The descriptions of the meanings of the digitalSignature and 
> >>>>    nonRepudiation bits of keyUsage may need to be adjusted based 
> >>>>    on the work in X.509 
> >>>> 
> >>>> The new text in X.509 aligns with the text in RFC 3280.  No 
changes 
> >>>> are required to 3280bis.  A comment has been added to the ASN.1 
for 
> >>>> KeyUsage stating that "recent editions of X.509 have renamed 
> >>>> [the nonRepudiation] bit to contentCommitment" 
> >>>> 
> >>>> This statement is untrue. 
> >>>> 
> >>>> The text from X.509 has been published in Corrigendum 3 (04/2004) 
> >>>> on pages 4 and 5 (see ISO/IEC 9594-8:2000/Cor.3:2004 also called 
> >>>> 
> >>>> ITU-T Rec. X.509 (2000)/Cor.3 (04/2004)). 
> >>>> 
> >>>> An extract from this text is copied below: 
> >>>> 
> >>>> a) digitalSignature: for verifying digital signatures that are 
used 
> >>>>  with an entity authentication service, a data origin 
authentication 
> >>>>  service or/and an integrity service; 
> >>>> 
> >>>> b) contentCommitment: for verifying digital signatures which are 
> >>>> intended 
> >>>>  to signal that the signer is committing to the content being 
signed. 
> >>>>  The type of commitment the certificate can be used to support 
may be 
> >>>>  further constrained by the CA, e.g. through a certificate 
policy. 
> >>>>  The precise type of commitment of the signer e.g. "reviewed and 
> >>>>  approved" or "with the intent to be bound", may be signalled by 
the 
> >>>>  content being signed, e.g. the signed document itself or some 
> >>>> additional 
> >>>>  signed information. 
> >>>> 
> >>>>  Since a content commitment signing is considered to be a 
digitally 
> >>>> signed 
> >>>>  transaction, the digitalSignature bit need not be set in the 
> >>>> certificate. 
> >>>>  If it is set, it does not affect the level of commitment the 
signer 
> >>>> has 
> >>>>  endowed in the signed content. 
> >>>> 
> >>>>  Note that it is not incorrect to refer to this keyUsage bit 
using 
> the 
> >>>>  identifier nonRepudiation. However, the use of this identifier 
has 
> >>>> been 
> >>>>  deprecated. Regardless of the identifier used, the semantics of 
> >>>> this bit 
> >>>>  are as specified in this Directory Specification. 
> >>>> 
> >>>> The text from 3280 is copied below: 
> >>>> 
> >>>>     The digitalSignature bit is asserted when the subject public 
key 
> >>>>     is used with a digital signature mechanism to support 
security 
> >>>>     services other than certificate signing (bit 5), or CRL 
signing 
> >>>>     (bit 6).  Digital signature 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 which protects against the signing entity 
> >>>>     falsely denying some action, excluding certificate or CRL 
> signing. 
> >>>>     In the case of later conflict, a reliable third party may 
> >>>>     determine the authenticity of the signed data. 
> >>>> 
> >>>>     Further distinctions between the digitalSignature and 
> >>>>     nonRepudiation bits may be provided in specific certificate 
> >>>>     policies. 
> >>>> 
> >>>> The text from 3280bis does not align with the ISO-ITU text. 
> >>>> Please align with the the ISO-ITU text. 
> >>>> 
> >>>> Denis 
> >>> 
> >> 
> >> 
> >> 
> > 
> > 
> 

Joel S. Kazin CPA, CISA, CISSP, CISM
Senior Consultant
Atos Origin
40 Old Sleepy Hollow Road
Pleasantville, New York 10570-3802
USA
Phone  +1 914-769-8780
Mobile  +1 914-564-1484
email    [email-masked]
www.atosorigin.com <http://www.atosorigin.com/>

---

From: "Santosh Chokhani" <[email-masked]>
Date: Fri, 27 May 2005 10:43:47 -0400

X.509 V1 or V2 did not have any extensions.  Thus, neither key usage nor
certificate policies were part of v1 or v2.  These extensions came about in
v3.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of Kazin, Joel
Sent: Friday, May 27, 2005 9:20 AM
To: Stefan Santesson; Denis Pinkas; Stephen Farrell
Cc: Hoyt L Kesterson II; pkix
Subject: RE: 3280bis: key usage (13)

Stefan Santesson 

> From: [email-masked] 
[mailto:[email-masked]] 
used 
ISO 
the 
upcoming 
time 
changes 
for 
changes 
for 
used 
authentication 
signed. 
may be 
policy. 
the 
digitally 
signer 
using 
has 
key 
security 
signing 
entity 
key is