Subject: Re: Non-Repudiation

From: "Aram Perez" <[email-masked]>
Date: Thu, 05 Aug 1999 17:40:35 -0700

Steve Kent wrote:

> Aram,
> 
>>This is not correct. In a previous job, we built a system using DES where
>>party A could only sign (using ANSI X9.9) and party B could only verify.
>>With party A, all the keys were kept on hardware tokens and required dual
>>control: a Security Administrator (SA) to start the system and the Signing
>>Offer (SO) to enable the signature process. The signing key was the
>>combination of the SA and SO keys. A similar setup existed at party B. With
>>this system, I could prove (in a court of law) that the signature was
>>generated by party A and not by party B.
>
> This is a misuse of the term "sign" and it not consistent with the language
> of X9.9.

Though you may consider it may be a misuse of the term "sign", the system
was designed to replace handwritten signatures. Instead of the SO signing a
paper document with his/her handwritten signature, he/she would "sign" (or
append a MAC) an electronic version of the document (on a system that could
only be started up by the SA).

>  X9.9 specifies a MAC, and a MAC is not a signature, period!

I'm don't understand why you state that "a MAC is not a signature, period!"
The following is not a legal definition or the most accurate, but according
to "http://www.dictionary.com/cgi-bin/dict.pl?term=signature" the definition
is: "signature \Sig"na*ture\, n. [F. (cf. It. signatura,
    segnatura, Sp. & LL. signatura), from L. signare, signatum, v. t.]
   1. A sign, stamp, or mark impressed, as by a seal.
   2. Especially, the name of any person, written with his own
      hand, employed to signify that the writing which precedes
      accords with his wishes or intentions; a sign manual; an
      autograph."

So why is an encrypted hash anymore a signature than a MAC?

> While
> the banking community has long treated MACs as though they provide
> technical support for NR, we all understand that a MAC is a poor technical
> basis for such a service.

I'm not sure if you are including me in the "we all understand ...", but the
"owners" of the system believed it was good enough. For non-disclosure
reasons I can't provide more more detail, but the system handled millions of
dollars.

>  In your example, collaboration by the SA and SO
> at the receiver could generate a MAC indistinguishable from that produced
> by the sender.

In that system, the SO was the sender. Given the that receiver/relying party
could not generate a MAC but only verify it.

Regards,
Aram Perez

---

From: Stephen Kent <[email-masked]>
Date: Fri, 6 Aug 1999 10:11:27 -0400

Aram,

The term "digital signature" has a well defined meaning in the technical
literature, and was specifically coined in the context of public key
cryptography, although one can achieve analogous features via symmetric
crypto.

[Also note that your characterization of signing a hash by "encrypting" it
is not correct, in general, e.g., DSA does not encrypt a hash to sign it.]

The term "signature" is more generally applied, and is more broadly defined
outside of the technical area in which we are working. Hence a definitoion
from a dictionary for the term signature does not address our debate.

The X9.9 standard was written at a time when the distinction was clear and
that's why that standard does not confuse matters by refering to a MAC as a
signature, much less a digital signature.  A critical aspect of a digital
signature is that the ability to verify it is cryptogra[hically distinct
from the ability to generate it.  That asymmetry is essential if signatures
are to be used to support NR.

I would argue that your example of a MAC does not fit this definition, as
the controls used to effect asymmetry are procedural, not cryptographic.
We have about 20 years of technical literature on this topic, most of which
is quite consistent in the use of this terminology.

Steve

---

From: "tog" <[email-masked]>
Date: Sat, 7 Aug 1999 06:10:57 -0700

Stephen, Aram,

----- Original Message -----
From: Stephen Kent <[email-masked]>
To: Aram Perez <[email-masked]>
Cc: <[email-masked]>
Sent: Friday, August 06, 1999 7:11 AM
Subject: Re: Non-Repudiation

> cryptography, although one can achieve analogous features via symmetric

It also has a pretty clear definition under US Law, I suggest if your
interested in looking at the state of the various legeislative processes at
MBC.COM, one of the premeir law firms that tracks US EC Legislation. The URL
is http://www.mbc.com/ds_sum.html, those of us that are aslo ISC members
(http://www.abanet.org/scitech/ec/isc) are familiar with this site, it and
several others including Perkins-Coie in Seattle have excellent "tracking EC
Legislation" websites.

Why I bring this up is that it seems to me is that we as technologies as we
progress farther and farther upwards in the food chain (the bottom being
Core Enablement, and the top being a Turnkey System) that the legislative
process and standards become some of the critical gating issues to deploying
our collective vision.

So I suggest that you might (or might not) enjoy looking at these sites.

Todd

---

From: Paul Hoffman / IMC <[email-masked]>
Date: Sat, 07 Aug 1999 11:01:10 -0700

>process and standards become some of the critical gating issues to deploying

Todd, I don't believe you understand the role that the IETF has actively 
chosen for itself. We stay out of local legislative issues wherever we can 
(and the US is local, as we have seen in this WG with the Europeans going 
many places the US has not). We're not lawyers here, and we strive mightily 
to not become them.

If you think you understand the law, great. (I do too, in some areas, but 
not this one.) I suggest you take that legal understanding to groups that 
are concerned with the law and help them understand what you understand of 
the technology. (I do that too.) They do law with only a bit of care for 
the technology; we do technology with only a bit (or zero) care for the 
law. But please stop trying to drag the WG towards "legal" solutions. I 
assure you, we'll do a bad job of it, given how little the vast majority of 
us understand about legal issues, and given how little coordination there 
is for the law in this area (or any technical area, for that matter).

BTW, I'm not at all against announcing interesting legal stuff that is 
related to the WG's work; that's fine. It's the trying to make our work 
align with the ever-changing legal stuff that is distracting and not 
helpful for us finishing our work.

--Paul Hoffman, Director
--Internet Mail Consortium

---

From: Stefan Santesson <[email-masked]>
Date: Sat, 07 Aug 1999 20:04:22 +0200

On August 6, we submitted the new draft for the Qualified Certificate profile 

We think this is ready now for WG last call and that all outstanding issues
has been resolved.
I will request WG last call as soon as the draft is officially published.

For those who don't want to wait untlil the draft hit the official pages,
the new draft can be obtained from: 

http://www.accurata.se/QC/documents/draft-ietf-pkix-qc-01.txt

In this draft we have also included an example cert. I would encourage
testing and evaluation of the example cert as well as all ASN.1 modules.

/Stefan

-------------------------------------------------------------------
Stefan Santesson                <[email-masked]>
Accurata AB                     http://www.accurata.se
Slagthuset                      Tel. +46-40 108588              
211 20  Malmö                   Fax. +46-40 150790              
Sweden                        Mobile +46-70 5247799

PGP fingerprint: 89BC 6C79 5B3D 591B 8547  1512 7D11 DBF4 528F 29A0
-------------------------------------------------------------------

---

From: Paul Hoffman / IMC <[email-masked]>
Date: Sat, 07 Aug 1999 11:29:12 -0700

>For those who don't want to wait untlil the draft hit the official pages,

They're faster than you think. It made it into the official directory 
Friday night. The new version is thus available at 
<http://www.ietf.org/internet-drafts/draft-ietf-pkix-qc-01.txt> 
and  <http://www.imc.org/draft-ietf-pkix-qc>.

--Paul Hoffman, Director

---

From: Ed Gerck <[email-masked]>
Date: Sat, 07 Aug 1999 12:45:11 -0700

> helpful for us finishing our work.

I agree with your msg. ICANN is perhaps a living proof how distracting
it can be to try to cope with all laws within one rule -- in fact, this is not
doable at all IMO.

And, I also strongly agree not to drag the WG towards "legal" solutions,
since they are always local to some extent.  However, the WG must not
either be dragged into "illegal" solutions -- which are dead on arrival. The
tension area between avoiding but not ignoring the legal issues is what
IMO needs to distinguish the results of this WG.

Also, one must be aware of over-legislative efforts that are just proposed
by "special interest groups" (an euphemism) and then mostly abandoned,
to which one must not swerve unless one wishes to go nowhere.

Cheers,

Ed Gerck