|
>>> "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 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 <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]
|