Subject: Re: NR -- what the real issues are, and a proposal

From: [email-masked]
Date: Thu, 19 Aug 1999 10:58:00 -0600

>>> "Rich Ankney" <[email-masked]> 08/17/99 05:07PM >>>
Bob,

Thanks for finally posting all of the relevant stuff in one
message.  My first thought would be to minimize reliance
on the NR bit, i.e. follow Steve's suggestion that if it's
FALSE, you can't use the cert for NR, else you might
be able to.

Of course, ANSI X9.45 defines a useful (CMS signed) attribute
to indicate the purpose of a signature.  Could we overload this (or
define something new but similar) to indicate intent?  The
syntax was an OID, so doing this is pretty simple.  I'd be
glad to force this thru X9 if the IETF crowd is not interested.

Best regards,
Rich

PS: I sent this to you personally rather than to the list in case
you'd like to discuss the details.  If not, of course, feel free
to post your response to the list.

Hi, Rich,

I'll take you upon your offer to post your note to the list, and
I'll also comment in passing on some other contributions from
Ed, Tony, and Steve, recognizing that some other suggestions have 
partially overtaken some of these ideas while I was preparing
this note and attending meetings. :-)

I agree with you regarding the case when the NR bit is off -- you
can't use the certificate for any nonrepudiation purpose in that case.
Perhaps I wasn't sufficiently clear in the proposal summary, 
although I think I was in the more detailed text, where I said that the NR
bit has to be used to ENABLE the NR bit in the message itself.

If NR bit is off, any message signed with the key in that certificate 
CANNOT intentionally or unintentionally be used for any legally 
binding purpose -- you are denying, in advance, that that was 
your intent, and signaling a prospective relying party that relying 
on your signature and certificate would be repudiated in court, if 
necessary, and hence such reliance would be quite unwise,
to say the least.
 
Why should you try to deny in advance something that might be 
legally binding (to answer someone else's question)?  Because 
you might be concerned about the possibility that your key might 
be stolen, and that it might not be YOU that is signing in that fashion!

Obviously you know (or at least ought to know) the strengths and 
weakness of your own key management system, and you might
very well decide that a given key/certificate was not sufficiently 
well protected to be used for any legally binding purposes -- it would 
just be too risky. Maybe your ordinary digital-signature-key-used-for-
network-logon-authentication-via-SSL is kept on your hard 
drive with relatively weak password encryption, and your 
nonrepudiation key/certificate is kept on a removable smart card.  
(I think this is Ed's point -- that if I don't have the power to deny 
a given capability in advance, it really isn't nonrepudiation -- it's 
just an option that I can't control and hence can't be binding, since 
it isn't voluntary.)

As I read Steve's note, I think he is in agreement with at least this point.

However, Steve, Tony, and even Ed then go down a path that I think is 
highly questionable, and that is the CA-centric view of enabling 
or disabling nonrepudiation within the CPS. Granted, if there is even 
the faintest suggestion that the CA might be liable for the user's 
actions with respect to his key and how they are used, then the 
CA ought to be able to deny the user the ability to set the NR bit. 
But it should do, obviously, by simply refusing to issue a certificate 
containing that bit.  But whether the CA can impose other conditions 
on the subscriber, or on the RP, in this particular area seems highly 
doubtful, as I will explain. (And as I expect that you, Rich, 
already know because of your banking involvement.)

There are three reasons why something like a NR bit should be in the 
certificate, and not just rely on a certificate policy OID (or worse yet, 
just a statement in the CPS itself.)

The first is a practical one -- very little RP software to date (none that I know of) 
implements the policy OID constraint, and without that constraint there is no 
enforcement.  In fact, I would bet that a lot of software would ignore the
constraint even if it were marked critical -- they certainly ignore a lot of other
critical attributes.

The second reason is more important.  Although I can, if I am the relying
party, choose a superior CA whose certificate specifies a policy OID constraint,
I am not required to do so. In fact, I can import and "trust" (accept as valid) 
a user's certificate directly, without relying on any intervening CA's certificate 
at all.  I'm not quite certain whether a policyOID constraint can be placed on 
the end-user's certificate -- can it? -- but even if it is it is far from obvious that
such a constraint is binding upon the application. What mechanisms are 
postulated to tell the RP what particular policy OID the user feels like accepting 
today?

So the relying party, or the relying party's IS department, may specify such a policy
constraint, BUT THEY ARE NOT REQUIRED TO DO SO.  

Finally, as I believe I explained in a previous message, to the best of my
knowledge there is no legal way that I know of whereby the relying party
can be required to even read the CA's CPS prior to accepting a digital signature,
or more importantly why a CPS that reflects an agreement between the CA 
and the subscriber would be binding upon the RP.  

This is a contractual privity issue, and there simply isn't any way around it that 
I know of -- a contract between A and B is not binding on C, even if there were 
also a contract between B and C.

So the only way that I know of to specify something of this type is in the defined 
semantics of the attribute itself.  If the NR bit is now so hopeless confused that
someone could wriggle out of this definition, then we ought to define a new one,
perhaps intentToBeLegallyBound, and deprecate the old one. But I don't think we 
are there yet -- I think we can use the existing bit for this purpose, so long as we 
recognize that it is the turning off of the bit that is really the most important thing.

With respect to the suggestion to define a new signedAttribute to be applied 
to the message, Russ Housely indicates that would be outside of the current
SMIME WG's charter, but that the charter could be amended if there was 
sufficient interest.

If we can get some reasonable consensus on the overall approach, I would 
be happy to work with you, Rich, to perhaps define a joint IETF-SMIME and
 X9 contribution in this area.

Bob

-----Original Message-----
From: Bob Jueneman <[email-masked]>
To: [email-masked] <[email-masked]>
Date: Tuesday, August 17, 1999 5:39 PM
Subject: NR -- what the real issues are, and a proposal

>The message which follows is a rather lengthy attempt to recap of
>the last five years or so of technical/legal discussion regarding
>digital signatures, followed by a proposal for what to do to fix these
>problems.
>
>However, since many may want to skip the justification and cut t
>o the bottom line, I'll put the proposal up front, and then justify it:
>
>My proposal is that the text of the nonrepudiation key usage bit I
>n the PKIX RFC (and hopefully in X.509) be revised to unambiguously
>state that the defined semantics of this bit is to indicate the willingness
>of the subscriber to be legally bound by a digital signature which can be
>verified by a certificate that can be established to have been valid at the
>time of signature, where "valid" has the normal meaning of not expired, not
>revoked, etc., etc.
>
>In addition, I propose that we create an additional indicator of a
>human being's conscious and willful intent to be legally bound by
>a digital signature that would be applied on a message by message
>basis. This additional indicator would require, as an integral part of
>its semantic definition, that an explicit computer-to-human interaction
>be required to provide some reasonable level of ceremonial and due
>caution warning be provided to the user.  In addition, the semantics
>of this indicator should specify that its use must be ENABLED by the
>NR bit ( as redefined) in the certificate which includes the corresponding
>public key.  If the certificate does not have the bit turned on, the
>application is not obligated to request the ceremonial, due caution
>approval; and relying party software should ignore a per-message
>indicator even if present in that case.
>
>The obvious, but not necessarily the only, place to put such a message
>by message indicator would be in the Cryptographic Message Syntax
>used by S/MIME V3, in particular as a new signedAttribute.  Since
>signedAttributes is a SET of self-describing attributes, adding
>an additional one would be very simple.
>
>Now for the history lesson.
[snip]

---

From: Tim Dean <[email-masked]>
Date: Tue, 24 Aug 1999 11:57:19 +0100

Rich,

>glad to force this thru X9 if the IETF crowd is not interested.

Speaking as one very small part of the "IETF crowd" we are very interested in 
this. We have long believed that the ability to specify signature semantics 
when signing messages would be a "Very Useful Thing". But we come at it from a 
negative perspective - viz, there are many situations where signing messages 
protects against real threats in the network but where the signing entity does 
not wish to be encumbered by legal liabilities. Two examples are (1) a human 
user who wants to protect herself against a law-suit (2) a machine which has no 
understanding of its legal liabilities and can't easily be taken to court ;-). 
In the absence of anything better we created the "signature type" attribute and 
put it in our Domsec draft in the S/MIME working group - which we hope to 
re-issue later on this year .  Would that be a suitable container for your 
OID(s)?

Tim

____________________________________
Tim Dean
DERA
E-mail: [email-masked]
Web: http://www.dera.gov.uk/
____________________________________

----------
From: 	[email-masked][SMTP:[email-masked]]
Sent: 	19 August 1999 17:58
To: 	"[email-masked]"@mail.proper.com
Cc: 	[email-masked]; [email-masked]
Subject: 	Re: NR -- what the real issues are, and  a proposal

<<File: ATT00011.htm>>
Bob,

Thanks for finally posting all of the relevant stuff in one
message.  My first thought would be to minimize reliance
on the NR bit, i.e. follow Steve's suggestion that if it's
FALSE, you can't use the cert for NR, else you migbe able to.

Best regards,
Rich

Hi, Rich,

The first is a practical one -- very little RP software to date (none that I 
know of)
implements the policy OID constraint, and without that constraint there is no
enforcement.  In fact, I would bet that a lot of software would ignore the
constraint even if it were marked critical -- they certainly ignore a lot of 
other
critical attributes.

The second reason is more important.  Although I can, if I am the relying
party, choose a superior CA whose certificate specifies a policy OID 
constraint,
I am not required to do so. In fact, I can import and "trust" (accept as valid) 
a user's certificate directly, without relying on any intervening CA's 
certificate
at all.  I'm not quite certain whether a policyOID constraint can be placed on
the end-user's certificate -- can it? -- but even if it is it is far from 
obvious that
such a constraint is binding upon the application. What mechanisms are
postulated to tell the RP what particular policy OID the user feels like 
accepting
today?

So the relying party, or the relying party's IS department, may specify such a 
policy
constraint, BUT THEY ARE NOT REQUIRED TO DO SO.

can be required to even read the CA's CPS prior to accepting a digital 
signature,

This is a contractual privity issue, and there simply isn't any way around it 
that
I know of -- a contract between A and B is not binding on C, even if there were 
also a contract between B and C.

So the only way that I know of to specify something of this type is in the 
defined
semantics of the attribute itself.  If the NR bit is now so hopeless confused 
that
someone could wriggle out of this definition, then we ought to define a new 
one,
perhaps intentToBeLegallyBound, and deprecate the old one. But I don't think we 
are there yet -- I think we can use the existing bit for this purpose, so long 
as we
recognize that it is the turning off of the bit that is really the most 
important thing.

Bob

-----Original Message-----
From: Bob Jueneman <[email-masked]>
To: [email-masked] <[email-masked]>
Date: Tuesday, August 17, 1999 5:39 PM
Subject: NR -- what the real issues are, and a proposal

[snip]