Rich,
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.
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: t(_dot_)dean(_at_)eris(_dot_)dera(_dot_)gov(_dot_)uk
Web: http://www.dera.gov.uk/
____________________________________
----------
From: BJUENEMAN(_at_)novell(_dot_)com[SMTP:BJUENEMAN(_at_)novell(_dot_)com]
Sent: 19 August 1999 17:58
To: "rankney(_at_)erols(_dot_)com"@mail.proper.com
Cc: ietf-pkix(_at_)imc(_dot_)org; ietf-smime(_at_)imc(_dot_)org
Subject: Re: NR -- what the real issues are, and a proposal
<<File: ATT00011.htm>>
"Rich Ankney" <rankney(_at_)erols(_dot_)com> 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 migbe 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 <BJUENEMAN(_at_)novell(_dot_)com>
To: ietf-pkix(_at_)imc(_dot_)org <ietf-pkix(_at_)imc(_dot_)org>
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]