[legalxml-enotary] FWD: Re: FW: URGENT ** Non-repudiation key usage **

[John Messing <jmessing@law-on-line.com>]

For those who are members of the ISC-ABA, please excuse the cross-posting

---------- Original Message ----------------------------------
From:         John Messing <jmessing@LAW-ON-LINE.COM>
Reply-To:     John Messing <jmessing@LAW-ON-LINE.COM>
Date:          Sat, 16 Nov 2002 11:27:03 -0500

Steve:

I would be against taking either position (urging renaming or deletion) as a lawyer talking to technologists. That is their call. I think we have pointed out the difficulties from a legal standpoint and made our position clear. Some of the technologists on the ISC have pointed out technical difficulties. The rest is common sense or the lack of it on the part of the publishers of the X-509 standard.

Without having the thread degenerate into yet another post-mortem on PKI and where its advocates went wrong (MS operating systems seemingly have plenty wrong with them but are not considered dead yet), I think the reality is that technical attempts to devise a method for a conclusive presumption of authentication, as the non-repudiation bit seemingly attempted to do initially, are probably inevitably doomed to failure. The sooner technologists realize the probable futility of such efforts, the better. (I say probable because it is possible that such a machine could be devised, but I sincerely doubt it.) Signatures involve complex human behavior by decision makers about determining objective manifestations of intent. It is not simply boolean logic at play.

I would like to encourage discussions both in the ISC and the eNotary TC of LegalXML-Oasis about when machine authentications of both machine agents and human beings should be considered legally self-authenticating for evidentiary purposes, and what weight should be accorded to such authentications (rebuttable, presumptive, conclusive, etc.)? I believe that is a broader issue that is intrinsically involved with a discussion of the non-repudiation bit.

Best regards.

John Messing
3900 E. Broadway Blvd., Suite 201
Tucson, AZ 85711
(520)547-7933 (v)
(520)547-7920 (f)
jmessing@law-on-line.com
----- Original Message -----
From: Stephen Wu
To: ST-ISC@MAIL.ABANET.ORG
Sent: Friday, November 15, 2002 2:33 PM
Subject: Re: FW: URGENT ** Non-repudiation key usage **


Bob:  I think it's clear the ISC can take a position of one kind.  It can provide legal input under the assumption that people will not want to kill off or rename the bit.  The question that I leave open, and I'd like to hear from others, is whether the ISC should go the second step and urge its renaming or deletion.

Steve
-----Original Message-----
From: Robert Jueneman [mailto:bob@jueneman.com]
Sent: Friday, November 15, 2002 12:12 PM
To: Stephen Wu; ST-ISC@MAIL.ABANET.ORG
Subject: Re: FW: URGENT ** Non-repudiation key usage **


Stephen:  I'll get all of the technologists to agree, if you'll commit to get all of the attorneys in the world to agree at the same time! :-)

The problem is that some of these definitions and concepts go back a long, long way, and although they demonstrably don't carry the water, some of the original people involved (Dennis Pinckas in particular) are hanging on and saying that it is the rest of the world that is out of step.

But I'm heartened to hear that Santosh seems to agree.

I'm suggesting a potential means of moving the ball forward by allowing the CA and the end-user to agree on one thing that is obviously necessary, if certainly not sufficient, for nonrepudiation, i.e., that the key isn't shared or recoverable.  Such a definition could fairly easily be enforced in hardware, and the CA could require that compliant systems be used prior to signing the certificate.

It obviously doesn't do what I would really like it to do, and that is to tie the use of such a certificate and key to a rebuttable presumption of validity (which sidesteps the issue of intent), but I suppose it could be argued that the people who really care about such things could encode them in certificate policies and policy OIDs.  And if the transaction is important enough, I suppose there is even a chance that someone will actually read the CP!

Given the muddiness of the water at this point, and the fact that some laws may have been written which refer to the NR bit, I'm not sure if this is really the best way forward, in particular because it causes some uncertainty with respect to the old vs. the new definitions.

The preferred way to handle the situation would be to deprecate the bit entirely and define some new ones.  But that would require another five years or more before software would be in place to deal with the new bits, and that might be the kiss of death to the whole notion.

So perhaps this is the best compromise available -- change the technical definition in a way that is at least unambiguous and a compatible subset of the more grandiose (and unworkable) concept, and then leave the rest of the legal details to contracts and/or CPs.  At least the existing CA software has the means to set the bit, and applications can easily parse the certificate and decide what to do with the information with respect to a particular transaction.

And it also provides a mechanism for dealing with the issue of disclosure of key escrow to the originator or an encrypted message.  Without this minimal capability, it is possible that even the recipient may not be aware that someone else may be reading his mail, much less the originator.

I would suggest that the name be changed to "Non-Recoverable" rather than Nonrepudiation, so that we don't have to keep arguing the same points for decades to come.  The purists won't like using the same bit with a new and different definition, and I don't like it either, but this may be the best compromise available.

Would it be helpful to have the ISC take a formal position on this issue?

Bob



Jueneman Consulting , LLC -- "Security Solutions for an Insecure World"
Robert R. Jueneman, President
1154 E. Dover Dr.
Provo, UT 84604
1-801-765-4829 (Office)
1-866-430-4685 (Toll Free)
1-801-765-4378 (Fax)
1-801-372-5501 (Cellular)
consulting@jueneman.com
www.jueneman.com

This message and any attached documents may contain Jueneman Consulting, LLC confidential or proprietary information and may be subject to privilege or exempt from disclosure under applicable law.  These materials are intended only for the use of the intended recipient.  If you are not the intended recipient of this electronic message, you are hereby notified that any use of this message is strictly prohibited.  Delivery of this message to any person other than the intended recipient shall not constitute any waiver of any privilege.  If you have received this message in error, please delete this message from your system and notify the sender immediately.    Thank you.

>>> Stephen Wu<swu@INFOSECLAW.COM> 11/15/02 12:20PM >>>

Bob:  This is certainly a bright line position, and is very close if not identical to Santosh's position.  It bypasses all the vaguaries of the legal system.  But will technologists go for it?  Some still seem to hold onto the dream of dictating a legal result via technology.

Steve
-----Original Message-----
From: Information Security Committee [mailto:ST-ISC@MAIL.ABANET.ORG] On Behalf Of Robert Jueneman
Sent: Friday, November 15, 2002 9:59 AM
To: ST-ISC@MAIL.ABANET.ORG
Subject: Re: FW: URGENT ** Non-repudiation key usage **


Russ,

That's why, in my reply to Katarina, I suggested the minimal, place-saving, face-saving definition:

If the NR bit is asserted in the keyUsage field, then the private key in question must NOT be known to, controlled by, or subject to key escrow or key recovery by anyone other than the individual subscriber.  In particular, this means that neither the CA, nor the subscriber's employer, nor even the national government, should be able to reconstruct or gain access to or control over the key.

"NR" could then be interpreted to mean "Not Recoverable", and I think most people would agree that not sharing or being able to recover the key is perhaps the irreducible minimum requirement for nonrepudiation. If someone other than the entity identified in the certificate could potentially have access to or effective control over the usage of the key, then it is very difficult to prove that only that entity could have possibly signed the transaction in question.

Although most of the discussion about the NR bit has centered around its use in the digital signature context, I would also argue that the above definition makes excellent sense in combination with the Key Exchange key usage -- it informs the recipient of the certificate, in this case the person who is about to send an encrypted document, whether or not someone else could potentially decrypt the information.  (Obviously this doesn't say anything at all about what happens to the information once it is received and decrypted -- if the recipient chooses to leak the information to the press, then that is a different issue.  But even in that case, the originator would clearly know who was ultimately responsible for the loss of confidentiality, so in that sense it is similar to and compatible with the notion of "responsibility" that nonrepudiation implies.

There are a number of reasons why organizations may wish to have key generated centrally. Certainly while I was at Novell, we believed that keys generated on one of our servers using our crypto software were likely to of much higher quality than those generated on say a Windows 95 browser.

So for keys used to encrypt and decrypt company e-mail and other company documents, server-generated keys work just fine.

There are also cases where the single key model works just fine, notably for SSL mutual authentication, where nonrepudiation is not involved. I'm not even sure that it is necessary to turn on the Digital Signature bit for such keys, much less the NR bit. IPSEC and VPN usage is similar, as is PC smart-card logon.

Even in those cases where digital signatures are being used, e.g., for code signing, it still isn't obvious that the rigid exclusion of any other person is vitally important -- those keys are primarily used on behalf of and within an enterprise, and not for an individual per se.

But of course if you do want to have something approximating classic nonrepudiable digital signatures, OR if you want to be certain that your whistle-blower e-mail can't be read by the system administrator or anyone else, then you need to ensure that key recovery is not possible.

Bob



Jueneman Consulting , LLC -- "Security Solutions for an Insecure World"
Robert R. Jueneman, President
1154 E. Dover Dr.
Provo, UT 84604
1-801-765-4829 (Office)
1-866-430-4685 (Toll Free)
1-801-765-4378 (Fax)
1-801-372-5501 (Cellular)
consulting@jueneman.com
www.jueneman.com

This message and any attached documents may contain Jueneman Consulting, LLC confidential or proprietary information and may be subject to privilege or exempt from disclosure under applicable law.  These materials are intended only for the use of the intended recipient.  If you are not the intended recipient of this electronic message, you are hereby notified that any use of this message is strictly prohibited.  Delivery of this message to any person other than the intended recipient shall not constitute any waiver of any privilege.  If you have received this message in error, please delete this message from your system and notify the sender immediately.    Thank you.

>>> Russ Savage<rsavage@SOS.STATE.AZ.US> 11/15/02 11:10AM >>>
so is the so called NR bit the bridge between dual key pair use and
single key pair use?
if not, what is?
and, again out of curiosity, how would one distinguish between a single
key pair with key recovery and a single key pair without key recovery?

On Friday, November 15, 2002, at 10:39 AM, Joel S. Kazin wrote:

> Good question counselor.
>
> There are two different needs: encrypting documents and digitally
> signing
> documents.
>
> An organization needs to be able to decrypt documents that have been
> encrypted with an individual's private key.  Just try to tell a judge
> that
> you have delivered the subpoenaed document but don't have the
> decryption
> key.  Your first case also is in this class.  Or , just suppose  Joe
> hadn't
> retired but just lost his token while fishing and needs to get an
> important
> document, that he encrypted, back so that he can use it. Some sort of
> key
> escrow system is needed.
>
> Digitally signing documents, your second case,  requires that there is
> only
> one copy of the key.
>
> Single key pair PKI systems, where a single pair of keys is used for
> both
> signature and encryption functions can not satisfy both requirements
> concurrently. Early versions of PGP are single key pair systems.
>
> Two key pair PKI systems, such as Entrust, do satisfy both requirements
> concurrently. One key pair is used for encryption the other key pair
> for
> signature. The decryption key is escrowed, but the private signature
> key
> is
> not.
>
> Furthermore, the private signature key is created on and never leaves
> the
> smart card. If the card is lost a new card is issued and a new signing
> key
> pair created. The private encryption key may be recovered from the
> escrow
> agent or a new encryption key pair created.  Remember that subsequent
> signature verification requires the corresponding public key contained
> in
> the certificate.
>
> The respective certificates have either the signing or encryption bit
> set,
> but never both. Regrettably, to support single key pair systems, RFC
> 3280
> does not restrict setting both bits on concurrently. "This profile does
> not
> restrict the combinations of bits that may be
> set in an instantiation of the keyUsage extension."
>
> Of course, a well designed application will inspect the appropriate
> bits
> and reject any certificate that doesn't meet its basic
> requirements.
>
>
>
> At 09:38 AM 11/15/2002 -0700, Russ Savage wrote:
>> Joel,
>>
>> just out of curiosity,
>> what, if any, distinction do you make between key pairs used so you
>> can
>> distinguish between & handle
>> 1. "yeah, Joe retired and lost his token in the lake while fishing but
>> don't worry we have a mechanism to recover his key off our secure
>> system and decrypt his files." and
>> 2. "your honor, our key generation process places the one and only
>> private key in the possession of that person over there (Joe) who is
>> saying somebody else must have used his key."
>>
>> and
>> if you make that distinction, how do you indicate it in the cert? How
>> does an application know what type of key its being presented by Joe
>> to
>> do whatever it is to do (encrypt or sign or....)?
>> if you don't make that distinction, why not?
>>
>> Russ-the-curious
>>
>> On Friday, November 15, 2002, at 08:21 AM, Joel S. Kazin wrote:
>>
>>> Now for some more fuel to this fire; this is just a different view.
>>>
>>> As consultant who helps organizations to build their PKI
>>> infrastructures
>>> I have never seen any of my employer's clients use the dam bit or
>>> include it in their CP, CPS, or certificate specification.  Yes, I
>>> write
>>> the things.  I Perhaps my colleagues who are cc'd on this message
>>> have
>>> had different experiences?  Who is actually setting or using the bit
>>> and
>>> for what?  If no one is using it then get rid of it; if a few people
>>> are
>>> using it, perhaps it should be deprecated.
>>>
>>>
>>> At 10:55 PM 11/14/2002 -0600, you wrote:
>>>
>>>
>>> To paraphrase Shakespeare, "Will no one rid me of this troublesome
>>> bit?"
>>>
>>> I submit that if there is a single reason why PKI has so far failed
>>> to
>>> flourish to the extent that the benefits of the technology so clearly
>>> deserves, it is because of this ill-defined bit and the problems and
>>> false expectations it raises.  A stake should have been driven
>>> through
>>> its heart at least 10 years ago, and I've been trying without success
>>> ever since then.
>>>
>>> I am in general agreement with Jane Hill's position, and with the
>>> comments from the ISC, and by Dan Greenwood and others -- I only wish
> I
>>> could have attended the meeting.
>>>
>>> The fact of the matter, both from a technical and a legal
>>> perspective,
>>> is that the NR bit is neither necessary (there are lots of ways that
> an
>>> agreement can be interpreted as valid without the bit being set), nor
>>> is
>>> it sufficient (there are way too many loopholes, both technical and
>>> legal, to have it be conclusive or dispositive).
>>>
>>> Something that is neither necessary nor sufficient may at least be
>>> corroborative of intent, but for all the reason that both Jane and
>>> the
>>> ISC paper cite, even that isn't very convincing. Something that is
>>> neither necessary nor sufficient, nor even very corroborative, is not
>>> merely nearly useless, in my opinion, but positively harmful.
>>>
>>> The ISO, X.509, and PKIX technical groups, despite the valiant
>>> efforts
>>> of some good and well-intentioned people, is demonstrably not capable
>>> of
>>> adequately addressing what are essentially legal issues, and to the
>>> extent that the term "repudiation", or worse yet "nonrepudiation" are
>>> essentially legal constructs, what those technical bodies are likely
> to
>>> say about the subject is again neither necessary nor sufficient, but
>>> quite likely to be harmful.
>>>
>>> I have said it before, and I will say it again -- we are WAY past the
>>> point of being able to salvage this concept by minor changes or
>>> wordsmithing of the definition -- the patient is hemorrhaging from a
>>> ruptured aorta, and applying a band-aid to his toe is simply not
>>> going
>>> to help.
>>>
>>> The ONLY viable approach, in my judgement is to admit that we
>>> (collectively) botched it beyond repair. As a result, we should
>>> formally
>>> deprecate the NR bit entirely, and admit to the fact that it is
>>> completely meaningless.  Then, with a clean sheet of paper, we can
>>> perhaps start over and try to do something constructive.
>>>
>>> I believe that it is obvious to this audience that a bit in a
>>> certificate which may have a validity period of three years or more
>>> is
>>> simply not going to be indicative of the end-user's intent at a
>>> particular point in time.  And suing the CA because the CA didn't
>>> enforce the proper terms upon the end-user is a complete nonstarter
>>> --
>>> it would simply drive potential CAs further and further away from
>>> this
>>> (so far rather unprofitable) business, even if it were a sustainable
>>> legal concept.  It therefore ought to be obvious that the place for
> any
>>> such construct is with the digital signature itself, where it can
>>> correctly indicate the individual user's intent at the moment.
>>>
>>> In summary, I don't believe that the NR bit can, or even should be
>>> viewed as being indicative of the user's INTENT to be bound in some
> way
>>> or other, and for that reason, along with all of the historical
>>> baggage,
>>> it ought to be deprecated and abandoned, once and for all.  No life
>>> sentence -- the death penalty!
>>>
>>> Once we've finally killed the beast, we can start to rethink many of
>>> the
>>> more nuanced concepts that have been proposed in the past, but
> rejected
>>> or deferred because it was not possible to fit those finer nuances
> into
>>> the Procrustean bed of a single bit.
>>>
>>> I've got a fairly long list of things I'd like to see worked on this
>>> area once we get past this hurdle, beginning with something I call
>>> key
>>> quality:
>>>
>>> 1. Where was the key generated, and how is it being protected and
>>> stored?  If the key is generated in software, or worse yet, is
>>> currently
>>> being "protected" by the run of the mill commercial operating systems
>>> as
>>> opposed to being stored in dedicated hardware, then as a relying
>>> party
>>> I
>>> don't want to give a transaction signed with such a key very much
>>> credence -- it's only marginally better than a FAXed signature.
>>>
>>> 2.  No matter how tamper-proof the storage device might be, how is
>>> access to that key granted or unlocked?  If the PIN or password that
> is
>>> used to unlock access to the key is processed through a relatively
>>> untrustworthy operating system, then the hardware will do what it is
>>> told, and I still don't have any significant amount of faith in the
>>> results.  It is all too easy, these days, to surreptitiously install
>>> and
>>> run a keyboard sniffing program that would capture every keystroke
>>> necessary to activate even a very secure token.  As a result, I don't
>>> have to steal the key -- I can simply use it whenever I wish to.
>>>
>>> 3.  Even if the key storage device were controlled by a separate
>>> token
>>> or smart card reader with a separate keypad that is independent of
>>> the
>>> potentially malicious host processor, once the key is unlocked, can
>>> it
>>> be used for multiple purposes after that point in time?  And how do I
>>> know that keypad is really trusted -- most of them are programmable,
>>> right?  So I do I know that someone can't install some bogus software
>>> on
>>> my keypad that can do something evil, such as returning the PIN to
>>> the
>>> host, or stealthily allowing two different signing operations to take
>>> place?
>>>
>>> 4.  Although some hardware crypto processors do include the popular
>>> hash
>>> algorithms, I don't know of any cryptographic service providers
>>> (CSPs)
>>> or their equivalent in non-Microsoft environments that actually
> compute
>>> the hash of a transaction on the smart card, token or cryptographic
>>> processor itself -- that is inevitably done by the CSP driver itself,
>>> which of course is under the control of the potentially compromised
>>> host
>>> processor.  As a result, I really have no way of knowing if what was
>>> present to me on the screen for my approval is really what was
>>> signed.
>>> So if someone really wants to insist on "technical nonrepudiation",
>>> my
>>> answer would be to require something like a Palm or Windows CE PDA
>>> device that would be capable of independently displaying the text
>>> that
>>> is to be signed prior to having the smart card or token actually do
> the
>>> signing function.  The programming on the PDA would presumably be
>>> resident in or on a ROM memory card that could not be altered.
>>>
>>> Now, someone reading all of the above would probably say that I am
>>> raising an impossibly high hurdle, and that in fact commercial
>>> transactions seldom require all that much perfection.  I completely
>>> understand that one man's prudence is another man's paranoia, and
> there
>>> comes a point where the endless pursuit of perfection becomes
>>> counter-productive.
>>>
>>> But in the meantime, my bank continues to use my username and
>>> password
>>> to authenticate access to my electronic banking account, and
>>> knowledge
>>> of someone's SSN and mother's maiden name is sufficient for someone
>>> to
>>> request a password reset on my account. (Actually, anyone who can
>>> gain
>>> access to any one of the customer service personnel can use their
>>> master
>>> password tor reset the passwords of every customer of the bank!) And
> it
>>> bugs me that that isn't a violation of GLBA and other applicable
>>> banking
>>> regulations, given how easy it would be to solve that problem with
>>> SSL
>>> mutual authentication.
>>>
>>> Bob
>>>
>>>
>>>
>>> Jueneman Consulting , LLC -- "Security Solutions for an Insecure
> World"
>>> Robert R. Jueneman, President
>>> 1154 E. Dover Dr.
>>> Provo, UT 84604
>>> 1-801-765-4829 (Office)
>>> 1-866-430-4685 (Toll Free)
>>> 1-801-765-4378 (Fax)
>>> 1-801-372-5501 (Cellular)
>>> consulting@jueneman.com <mailto:consulting@jueneman.com>
>>> www.jueneman.com <http://www.jueneman.com/>
>>>
>>> This message and any attached documents may contain Jueneman
>>> Consulting,
>>> LLC confidential or proprietary information and may be subject to
>>> privilege or exempt from disclosure under applicable law.  These
>>> materials are intended only for the use of the intended recipient.
>>> If
>>> you are not the intended recipient of this electronic message, you
>>> are
>>> hereby notified that any use of this message is strictly prohibited.
>>> Delivery of this message to any person other than the intended
>>> recipient
>>> shall not constitute any waiver of any privilege.  If you have
> received
>>> this message in error, please delete this message from your system
>>> and
>>> notify the sender immediately.    Thank you.
>>>
>>>>>> Steven W. Teppler steppler@TIMECERTAIN.COM
>>> <mailto:steppler@TIMECERTAIN.COM> 11/14/02 10:57AM >> > 11/14/02
>>> 10:57AM
>>> Hot off the presses.
>>>
>>> The technical people, in follow ups, still try to subordinate process
>>> to
>>> policy.  Come to think of it, the term "deprecate policy to process"
>>> may
>>> be
>>> even more apt, and more easily understood by the more technical
>>> oriented...
>>>
>>> Steven
>>>
>>> "If the probability be called P; the injury, L; and the burden, B;
>>> liability
>>> depends upon whether B is less than L multiplied by P: i.e., whether
>>> B
>>> is
>>> less than PL." United States v. Carroll Towing (159 F.2d 169 [2d Cir.
>>> 1947]
>>>
>>>
>>>
>>> -----Original Message-----
>>> From: EL-Sign: Electronic Signatures - Open Discussion
>>> [ mailto:EL-SIGN@list.etsi.fr]On <mailto:EL-SIGN@list.etsi.fr]On>
>>> Behalf Of Richard G. WILSHER
>>> Sent: Thursday, November 14, 2002 10:55 AM
>>> To: EL-SIGN@list.etsi.fr
>>> Subject: URGENT ** Non-repudiation key usage **
>>>
>>>
>>> Colleagues,
>>>
>>> I am sending this mail on behalf of Jane Hill (she being unable to
>>> access
>>> her mail service at the present)  -  see attachment.
>>>
>>> ***  PLS respond to her directly at:   JH@JaneHill.com  (she asks me
> to
>>> write)  ***
>>>
>>> Kind regards,
>>>
>>> Jane Hill's personal assistant, tea maker, etc. ....    :-|
>>>
>>>
>>> This text has to be with IETF by close of 'business' Saturday, so
>>> Jane
>>> would like your comments with her by tea-time Friday, i.e. 17h00 ETT
>>> (English Tea Time :-)
>>>
>>> Thank you for your swift responses.
>>>
>>> Senior Consultant
>>> Technical Consulting Practice, Northeast Region
>>> Schlumberger Network Solutions
>>>
>>> jkazin@parsippany.sns.slb.com
>>> www.slb.com/nws <http://www.slb.com/nws>
>>>
>>> 35 Waterview Blvd.
>>> Suite 210
>>> Parsippany, NJ 07054-1200
>>> USA
>>>
>>> Phone  +1 914-769-8780
>>> Mobile  +1 914-645-5598
>>>
>>> <mime-attachment>
>>
>> To unsubscribe send the following in the body of a message to
>> listserv@abanet.org  - unsubscribe st-isc
>
> Senior Consultant
> Technical Consulting Practice, Northeast Region
> Schlumberger Network Solutions
>
> jkazin@parsippany.sns.slb.com
> www.slb.com/nws
>
> 35 Waterview Blvd.
> Suite 210
> Parsippany, NJ 07054-1200
> USA
>
> Phone  +1 914-769-8780
> Mobile  +1 914-645-5598
>
> To unsubscribe send the following in the body of a message to
> listserv@abanet.org  - unsubscribe st-isc
> <mime-attachment>

To unsubscribe send the following in the body of a message to
listserv@abanet.org  - unsubscribe st-isc

To unsubscribe send the following in the body of a message to
listserv@abanet.org  - unsubscribe st-isc