RE: Dual-signed certificates

["Hiroyuki Sakakibara" <[e-mail]>]

I have two questions related to this topic.

[Question 1]

May "issuance agreement or receipt of certificate
included in or attached to a public key certificate"
be used for protecting against following attack ?

Because a CA publishes his certificate, someone can know the
profile of it, and create the CA's certificates including the
same public key, same issuer/serialnumber, subject and
same or different extension values, "fake certs", and publishes 
them to a public repository or attaches to protocol messages etc...
Also he can create not only CA's fake certs but also fake long pathes.
If an attacker sends these fake pathes with many messages to a server
( i.e a shopping server, a validation server etc ... ),
this strengthens a Denial Of Service attack against the server, 
because the server will validate the fake pathes.

Of course, the server would notice that those fake certs, and fake pathes
are invalid, because verification of the signatures are failed at his
trust anchor.

If a top down path construction is applied, with checking
signatures, the attack will be defeated immediately, but, bottom up path
construction ... RP will not notice it fake until the path
reaches to his trust anchor.

[Question 2]

In a cross-certificate environment, a certificate
path may contain several CA certificates in different domains.

For example,

CA_a cert(trust anchor) -->
CA_b cert --> CA_c cert --> CA_d cert --> EE cert

if CA_a, CA_b, CA_c, CA_d are in differnt PKI domains,

Supposing that CA_c issues a new certificate "CA_d cert ' "
( after issuing CA_d cert )
 to CA_d which includes the same public key as in "CA_d cert"
WITHOUT AGREEMENT of CA_d.

Even if CA_d cert ' includes the same extensions as the original one,
is this a valid path ?

CA_a cert(trust anchor) -->
CA_b cert --> CA_c cert --> "CA_d cert ' "--> EE cert

If "CA_d cert ' " includes additional extensions, i.e, additional policies,
CRL Distribution Points etc, which the original one does not include,
a path validation function based on RFC2459 or X.509 ver3
will succeed ?

for example
CA_d cert    includes policy1, policy2, CDP1, CDP2
CA_d cert'   includes policy1, policy2, policy3, CDP1, CDP2, CDP3
other certificate elements are the same.

In this case, CA_c may be a rough CA, but, 
I think that path validation will succeed, because there is no proof of
agreement or receipt of certificate issuance.

This CA_c' odd issuance of certificate seems no-benefical to CA_c, 
however,
I think that RP needs to notice this odd path
during path validation processing. 

---------------------------------------
Hiroyuki Sakakibara
MITSUBISHI ELECTRIC CORPORATION
Information Technology R&D Center
5-1-1 Ofuna, Kamakura, Kanagawa, Japan
PHONE: [phone]
FAX:   [phone]
E-mail : [e-mail]




Received: from florida.melco.co.jp (florida.melco.co.jp [192.218.140.46]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id UAA08343 for <[e-mail]>; Mon, 31 Jul 2000 20:13:26 -0700 (PDT)
Received: by florida.melco.co.jp (3.7W-florida) id MAA27638; Tue, 1 Aug 2000 12:17:00 +0900 (JST)
Received: by mailgw.melco.co.jp (3.7W-mailgw) id MAA02508; Tue, 1 Aug 2000 12:16:59 +0900 (JST)
Received: by inetgw.melco.co.jp (8.8.8+2.7Wbeta7/3.7W-inetgw) id MAA07512; Tue, 1 Aug 2000 12:16:59 +0900 (JST)
Received: from islgw.isl.melco.co.jp by elgw.isl.melco.co.jp (8.8.8/3.6W) id MAA08346; Tue, 1 Aug 2000 12:16:58 +0900 (JST)
Received: from iss.isl.melco.co.jp by islgw.isl.melco.co.jp (8.8.8/3.6W) id MAA19874; Tue, 1 Aug 2000 12:16:57 +0900 (JST)
Received: from belize by iss.isl.melco.co.jp (8.8.8/3.6W) id MAA04733; Tue, 1 Aug 2000 12:16:55 +0900 (JST)
Message-ID: <003101bffb67$2f2f8570$[e-mail]>
From: "Hiroyuki Sakakibara" <[e-mail]>
To: <[e-mail]>
Subject: RE: Dual-signed certificates
Date: Tue, 1 Aug 2000 12:18:37 +0900
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-2022-jp"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.00.2314.1300
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300

I have two questions related to this topic.

[Question 1]

May "issuance agreement or receipt of certificate
included in or attached to a public key certificate"
be used for protecting against following attack ?

Because a CA publishes his certificate, someone can know the
profile of it, and create the CA's certificates including the
same public key, same issuer/serialnumber, subject and
same or different extension values, "fake certs", and publishes 
them to a public repository or attaches to protocol messages etc...
Also he can create not only CA's fake certs but also fake long pathes.
If an attacker sends these fake pathes with many messages to a server
( i.e a shopping server, a validation server etc ... ),
this strengthens a Denial Of Service attack against the server, 
because the server will validate the fake pathes.

Of course, the server would notice that those fake certs, and fake pathes
are invalid, because verification of the signatures are failed at his
trust anchor.

If a top down path construction is applied, with checking
signatures, the attack will be defeated immediately, but, bottom up path
construction ... RP will not notice it fake until the path
reaches to his trust anchor.

[Question 2]

In a cross-certificate environment, a certificate
path may contain several CA certificates in different domains.

For example,

CA_a cert(trust anchor) -->
CA_b cert --> CA_c cert --> CA_d cert --> EE cert

if CA_a, CA_b, CA_c, CA_d are in differnt PKI domains,

Supposing that CA_c issues a new certificate "CA_d cert ' "
( after issuing CA_d cert )
 to CA_d which includes the same public key as in "CA_d cert"
WITHOUT AGREEMENT of CA_d.

Even if CA_d cert ' includes the same extensions as the original one,
is this a valid path ?

CA_a cert(trust anchor) -->
CA_b cert --> CA_c cert --> "CA_d cert ' "--> EE cert

If "CA_d cert ' " includes additional extensions, i.e, additional policies,
CRL Distribution Points etc, which the original one does not include,
a path validation function based on RFC2459 or X.509 ver3
will succeed ?

for example
CA_d cert    includes policy1, policy2, CDP1, CDP2
CA_d cert'   includes policy1, policy2, policy3, CDP1, CDP2, CDP3
other certificate elements are the same.

In this case, CA_c may be a rough CA, but, 
I think that path validation will succeed, because there is no proof of
agreement or receipt of certificate issuance.

This CA_c' odd issuance of certificate seems no-benefical to CA_c, 
however,
I think that RP needs to notice this odd path
during path validation processing. 

---------------------------------------
Hiroyuki Sakakibara
MITSUBISHI ELECTRIC CORPORATION
Information Technology R&D Center
5-1-1 Ofuna, Kamakura, Kanagawa, Japan
PHONE: [phone]
FAX:   [phone]
E-mail : [e-mail]



Received: from florida.melco.co.jp (florida.melco.co.jp [192.218.140.46]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id UAA07542 for <[e-mail]>; Mon, 31 Jul 2000 20:05:54 -0700 (PDT)
Received: by florida.melco.co.jp (3.7W-florida) id MAA25563; Tue, 1 Aug 2000 12:09:19 +0900 (JST)
Received: by mailgw.melco.co.jp (3.7W-mailgw) id MAA00394; Tue, 1 Aug 2000 12:09:19 +0900 (JST)
Received: by inetgw.melco.co.jp (8.8.8+2.7Wbeta7/3.7W-inetgw) id MAA05315; Tue, 1 Aug 2000 12:09:18 +0900 (JST)
Received: from islgw.isl.melco.co.jp by elgw.isl.melco.co.jp (8.8.8/3.6W) id MAA07851; Tue, 1 Aug 2000 12:09:17 +0900 (JST)
Received: from iss.isl.melco.co.jp by islgw.isl.melco.co.jp (8.8.8/3.6W) id MAA19407; Tue, 1 Aug 2000 12:09:17 +0900 (JST)
Received: from belize by iss.isl.melco.co.jp (8.8.8/3.6W) id MAA04615; Tue, 1 Aug 2000 12:09:15 +0900 (JST)
Message-ID: <002a01bffb66$1c9c1410$[e-mail]>
From: "Hiroyuki Sakakibara" <[e-mail]>
To: <[e-mail]>
Subject: RE: Dual-signed certificates
Date: Tue, 1 Aug 2000 12:10:56 +0900
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-2022-jp"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.00.2314.1300
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300

Mr. Tony Bartoletti
Thank you for your comments.

Date: Fri, 28 Jul 2000 14:57:39 -0700 Mr. Tony Bartoletti wrote

<snip>
>However, this method involves a near-duplication of information that
>"must be preserved", and would seem to require the relying party
>retrieve/check the "Issuance Agreement" against the actual elements
>of the certificate, in order to preclude some claim by the subject
>that they (plausibly) never agreed to the certificate terms.

Yes, RP needs to check that "signed Issuance Agreement" extension 
which includes public key value, issuer name, subject name, and other
extensions 
indicate the actual elements of certificates.
Therefore, as Mr. Bartoletti commented, it is near-duplication of
certificate,
but it could be in X.509 ver3 certifcate as an extension.
Or applying a hash function, it might be reduced ?

<snip>
>A protocol that provided the subject "sign first" seems very elegant,
>in that you get POP on the key, and POA (proof of acceptance) on the
>(pre)certificate, all in one shot.  And no duplication of the data.

"sign first", a certificate can include the "subject sign" as an extension,
however, a new protocol may be needed ... 

Hiroyuki Sakakibara
MITSUBISHI ELECTRIC



Received: from d1o69.telia.com ([e-mail] [62.20.144.241]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id OAA22464 for <[e-mail]>; Mon, 31 Jul 2000 14:42:06 -0700 (PDT)
Received: from mega (t5o69p50.telia.com [213.64.110.50]) by d1o69.telia.com (8.8.8/8.8.8) with SMTP id XAA29234; Mon, 31 Jul 2000 23:44:23 +0200 (CEST)
Message-ID: <000a01bffb40$be0af0d0$[e-mail]>
From: "Anders Rundgren" <[e-mail]>
To: "David P. Kemp" <[e-mail]>, <[e-mail]>
Subject: Re: QC DN "qualities". Was: I-DACTION:draft-ietf-pkix-qc-04.txt
Date: Tue, 1 Aug 2000 00:43:25 +0200
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 4.72.3110.5
X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by ns.secondary.com id OAA22465

David,
I don't expect too many persons in this list to agree on this and my previous posting
as they invalidate most organizational PKI-schemes in development!

<snip>
>> I.e. regardless if you are doing manual selections based om various attributes
>> or doing automated access control, a cert with just CN and a (within the
>> naming domain unique) Serial Number is the way to go for 99.999% of all
>> closed PKI-systems.
>
>The key to the last sentence is "within the naming domain unique". If
>the certificate subject name is <naming domain><serial number><common name>,
>the naming domain for organizational persons certainly contains an
>Organization, and may well contain a department/division if individual
>divisions autonomously maintain their own administrative systems and
>directories.

That is a popular way of creating an organizational identity.  Unfortunately, it dies
immediately when you reorganize!  See "Conclusions".

<snip>

>Not all people doing manual selection will find CN and SN sufficient.

Probably no one.  But assisted by directories or other databases they
can get what they want.


>For those people, the cost (possibly reduced lifetime) of including
>additional information in the cert is weighed against the cost
>(bandwidth, latency, lesser assurance if unsigned) of obtaining the
>additional information from other sources.

What you are saying is that the current  directory-trend could be on the road to nowhere.
Bob J/Novell may want to comment on that?

> For additional attributes
>to be useful, applications must be able to display them - it is
>inconsistent for an application to be designed to retrieve and display an
>attribute from a directory but not to be able to display the identical
>information from a certificate SDA.


Apparently we must add new stuff to X509.3?  It lacks a lot of useful attributes like
salary, vaction-period, hired-date etc.


>Conclusions:
>
>1) Some attributes may be necessary to uniquely identify the naming
>domain.  These must be included in the subject name.

I do not agree.
Multiple naming domains are essentially equivalent to multiple RAs if you have a single CA.
For a single CA it is preferable to let the CA maintain an organization-independent
name space and only keep RA-information within the CA registry (which it must keep anyway using
a multiple RA arrangement).

At least if you plan to reorganize every now and then, which sometimes causes a
local naming domain/RA to completely dissapear because it was "downsized"
or merged with another unit.  The naming domain/RA may BTW not have anything
with the actual organizational unit you are hired by, so putting such information in the subject
of a cert is not particularly useful.

Smells like a genuine TTP, don't it?  :-)



<snip>

Anders




Received: from roadblock.missi.ncsc.mil (roadblock.missi.ncsc.mil [144.51.50.70]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id LAA18511 for <[e-mail]>; Mon, 31 Jul 2000 11:25:00 -0700 (PDT)
Received: from roadblock.missi.ncsc.mil (root@localhost) by roadblock.missi.ncsc.mil with ESMTP id OAA21639 for <[e-mail]>; Mon, 31 Jul 2000 14:15:45 -0400 (EDT)
Message-Id: <[e-mail]>
Date: Mon, 31 Jul 2000 14:24:10 -0400 (EDT)
From: "David P. Kemp" <[e-mail]>
Reply-To: "David P. Kemp" <[e-mail]>
Subject: Re: QC DN "qualities". Was: I-DACTION:draft-ietf-pkix-qc-04.txt
To: [e-mail]
MIME-Version: 1.0
Content-Type: TEXT/plain; charset=us-ascii
Content-MD5: Qy0JZJfvVhwhDAWM8QczkQ==
X-Mailer: dtmail 1.3.0 CDE Version 1.3 SunOS 5.7 sun4u sparc

> From: "Anders Rundgren" <[e-mail]>
>
> If you looked closely to what Steve wrote,  he promoted the idea to inser
> additional information about subjects in certificates due his opinion that
> you can't trust directories. Right or wrong, the market is clearly going
> to use directories as a general cross-platform solution for storing
> employee information, account information etc.
> PKI will not change this powerful paradigm,  just provide a better "key".
> 
> I.e. regardless if you are doing manual selections based om various attributes
> or doing automated access control, a cert with just CN and a (within the
> naming domain unique) Serial Number is the way to go for 99.999% of all
> closed PKI-systems.

The key to the last sentence is "within the naming domain unique". If
the certificate subject name is <naming domain><serial number><common name>,
the naming domain for organizational persons certainly contains an
Organization, and may well contain a department/division if individual
divisions autonomously maintain their own administrative systems and
directories.

Even if the naming authority is at the enterprise-wide level, there may be
benefit to including additional identifying information in certificates.
If an attribute is stable, it is both less disruptive to the lifetime
of the certificate and more useful as a name. "Dave in accounting"
might have been a good identifying name for a person in an era when
accounting was not just a department but a career choice.  Rfc822
names, if assigned by a naming authority at a high level, can be
useful as static identifying information in certificates as long as
applications don't make the mistake of trying to enforce rfc822names as
email addresses.

Not all people doing manual selection will find CN and SN sufficient.
For those people, the cost (possibly reduced lifetime) of including
additional information in the cert is weighed against the cost
(bandwidth, latency, lesser assurance if unsigned) of obtaining the
additional information from other sources.  For additional attributes
to be useful, applications must be able to display them - it is
inconsistent for an application to be designed to retrieve and display an
attribute from a directory but not to be able to display the identical
information from a certificate SDA.


Conclusions:

1) Some attributes may be necessary to uniquely identify the naming
domain.  These must be included in the subject name.

2) Some subject attributes may be useful to human RPs selecting an
individual or to automated RPs doing group-based access control.  If
these attributes have minimal impact on certificate lifetime, they are
suitable for inclusion in the certificate. They should not be included
in the subject name except if necessary to accommodate lame applications.

3) It is not possible to make a general statement that any given
attribute is justified under 1) or 2).



Received: from popmail.inbox.se (popmail.inbox.se [193.12.72.102]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id TAA19805 for <[e-mail]>; Sun, 30 Jul 2000 19:34:23 -0700 (PDT)
Received: from santesson.accurata.se (atl-tgn-yfw-vty19.as.wcom.net [216.192.207.19]) by popmail.inbox.se (8.9.3/8.9.3) with ESMTP id EAA01920; Mon, 31 Jul 2000 04:37:40 +0200
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Version 4.3.2
Date: Sun, 30 Jul 2000 20:39:23 -0600
To: Denis Pinkas <[e-mail]>
From: Stefan Santesson <[e-mail]>
Subject: Denis remaining QC comments
Cc: [e-mail]
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed

Denis,

I'm working on my "Make Denis Happy" list, to which I dedicate all my best 
efforts right know.
In this mail I will try to clean up in the somewhat messy debate.

Generally we disagree about everything we debate here, but since we only 
debate less than 1% of the document, it must mean that we agree on more 
than 99% of the stuff :-).
Lets see if we can increase that positive factor and get over the finish line.

My summary is:

COMMENT 1
Issue: Uniqueness of DN over the lifetime of the CA

Fixed in qc-05

COMMENT 2
Issue: Use of the term "registered name" for Issuer DN

You want the term removed and I think it serves a purpose to keep it.
Basically I don't understand the SERIOUS problem with this..

I think that the current text is OK but I could live with having this removed.

COMMENT 3
Issue: Legal Jurisdiction

We basically agree that the legal jurisdiction of the CA should be 
consistent with the issuer DN. We argue however about wordings. Right?

COMMENT 4
Issue: Use of policy OID to state that a QC is a QC

Here we agree on the principle that the Issuer should be allowed to 
communicate the fact that a QC is a QC by just including a policy OID, 
defining this property. We consequently agree that use of the QCstatements 
extension for this purpose is optional. There is still some argue about 
wordings.Right?

For your information you fully misunderstood my comment about ETSI's policy 
OID:s. I'm fully aware that ETSI is producing 2 policy OID:s. What I mean 
is that I doubt that ETSI will define a 3:rd policy OID that JUST declare 
conformance with the EU directive Annex I and II and nothing else.


COMMENT 5
Issue: definition of a new extension for reliance limit.

Here is the first disagreement of concept. Even though I would not oppose a 
WG consensus on a new extension according to your proposal, I would argue 
against it. There is NO way that such change will just sneak in without 
going through a thorough WG debate, followed by a new WG last call and then 
proceed. This will cost considerable time and I truly doubt that 1) the 
solution will be better and 2) that it is worth a delay that will 
permanently kill the ETSI timetable.

There is no technical argument either against your solution or the current 
one, since both will work technically if supported by the market.

We will have to remind us though that we standardize the solutions of 
tomorrow. It will always take some time before a standard gets deployed. 
Until then CA's will find other quick and dirty ways to display this type 
of information (such as CA's today commonly use OU attributes in the 
subject and Issuer field to display disclaimer information)

Nor your solution nor the current one can change that. I hope to convince 
you that changing direction now will only make things worse, due to time 
delay, not better.

COMMENTS 6&7
Issue: Wordings in the security considerations section.

Except for the fact that I don't have a clue what you mean when you say 
that POP is not needed when the NR-bit is set, I see only disagreement of 
wordings.
Since this is just a security section, I hope that this won't be a major 
problem.

---------------------

Finally I would hope that we could agree to advance the document as it is, 
and then debate the minor wordings disagreements after having an RFC. I 
mean, even if we fix these comments to your 100% satisfaction, I promise 
that we will find more to argue about anyway :-)

Since the QC document has passed WG-last call I guess we will have to 
discuss this with Stephen and Warwick and see if we can reach some kind of 
resolution.

Hope to see you here in Pittsburgh

/Stefan





Received: from smtprch1.nortel.com (smtprch1.nortelnetworks.com [192.135.215.14]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id IAA04350 for <[e-mail]>; Sun, 30 Jul 2000 08:50:33 -0700 (PDT)
Received: from zsc4c002.corpwest.baynetworks.com by smtprch1.nortel.com; Sun, 30 Jul 2000 10:53:18 -0500
Received: by zsc4c002.corpwest.baynetworks.com  with Internet Mail Service (5.5.2652.35) id <P4TCWS64>; Sun, 30 Jul 2000 08:51:18 -0700
Message-ID: <[e-mail]>
From: "David Kurtz" <[e-mail]>
To: [e-mail]
Subject: Federal Government rulings?
Date: Sun, 30 Jul 2000 08:51:12 -0700
Importance: high
X-Priority: 1
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2652.35)
Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01BFFA3D.FC8D2200"

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01BFFA3D.FC8D2200
Content-Type: text/plain

Hello,

My name is Dr. David G. Kurtz and I work for Nortel Networks. I have a
question for you. Currently Nortel is providing a banking solution for a
major bank in the US using PKI. Is there any restriction from either the UCC
or Federal Government on the number of networks that can traverse or be
certified on one network?


Regards,

David G. Kurtz Ph.D.
Security Segment & Practice Technology
Home Office 		303-494-0297
Voice Mail			303-605-2186
Global Cell Telephone	[phone] 
Global Pager/Text Message	[e-mail]


------_=_NextPart_001_01BFFA3D.FC8D2200
Content-Type: text/html
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Dus-ascii">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
5.5.2652.35">
<TITLE>Federal Government rulings?</TITLE>
</HEAD>
<BODY>

<P><FONT FACE=3D"Univers (W1)">Hello,</FONT>
</P>

<P><FONT FACE=3D"Univers (W1)">My name is Dr. David G. Kurtz and I work =
for Nortel Networks. I have a question for you. Currently Nortel is =
providing a banking solution for a major bank in the US using PKI. Is =
there any restriction from either the UCC or Federal Government on the =
number of networks that can traverse or be certified on one =
network?</FONT></P>
<BR>

<P><FONT SIZE=3D2 FACE=3D"Arial">Regards,</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Tahoma">David G. Kurtz Ph.D.</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Tahoma">Security Segment &amp; Practice =
Technology</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Tahoma">Home Office &nbsp;&nbsp;&nbsp; =
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 303-494-0297</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Tahoma">Voice =
Mail&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 303-605-2186</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Tahoma">Global Cell Telephone&nbsp;&nbsp; =
303-961-5354 </FONT>
<BR><FONT SIZE=3D2 FACE=3D"Tahoma">Global Pager/Text =
Message&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
[e-mail]</FONT>
</P>

</BODY>
</HTML>
------_=_NextPart_001_01BFFA3D.FC8D2200--


Received: from d1o69.telia.com ([e-mail] [62.20.144.241]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id IAA19891 for <[e-mail]>; Sat, 29 Jul 2000 08:45:06 -0700 (PDT)
Received: from mega (t6o69p46.telia.com [213.64.110.166]) by d1o69.telia.com (8.8.8/8.8.8) with SMTP id RAA21980; Sat, 29 Jul 2000 17:48:22 +0200 (CEST)
Message-ID: <002e01bff97c$ae2b08a0$[e-mail]>
From: "Anders Rundgren" <[e-mail]>
To: <[e-mail]>, "Stephen Kent" <[e-mail]>
Cc: "PKIX-List" <[e-mail]>
Subject: Re: QC DN "qualities". Was: I-DACTION:draft-ietf-pkix-qc-04.txt
Date: Sat, 29 Jul 2000 18:47:26 +0200
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 4.72.3110.5
X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by ns.secondary.com id IAA19892

Tom & Steve

> My point is that in very many cases, an employee serial number or
>something like that is just as good for the RP's as a department.  Its
>greater stability compensates for its lack of user-friendliness.

This is of course right but actually serial numbers do not have to be user-friendly
as they are almost only digested by computers.

>  As you rightly pointed out to Anders, if manual selection of one user from a list
>of choices is the primary scenario in which an extra attribute is used,
>serial numbers aren't the best way to make such a selection.

If you looked closely to what Steve wrote,  he promoted the idea to insert additional information
about subjects in certificates due his opinion that you can't trust directories.
Right or wrong, the market is clearly going to use directories as a general
cross-platform solution for storing employee information, account information etc.
PKI will not change this powerful paradigm,  just provide a better "key".

I.e. regardless if you are doing manual selections based om various attributes
or doing automated access control, a cert with just CN and a (within the naming domain
unique) Serial Number is the way to go for 99.999% of all closed PKI-systems.

For open PKIs and TTPs we can just speculate as there is so little substance in
that market currently.  But you already know my position here :-)

Anders



Received: from mail.arabtrust.com (mail.arabtrust.com [216.247.149.19]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id WAA10285 for <[e-mail]>; Fri, 28 Jul 2000 22:26:37 -0700 (PDT)
Received: from jean [195.39.160.81] by mail.arabtrust.com (SMTPD32-6.00) id AC2D65F011C; Sat, 29 Jul 2000 01:31:25 -0400
From: "Jean Abraham" <[e-mail]>
To: <[e-mail]>
Subject: unsubscribe
Date: Sat, 29 Jul 2000 08:27:23 +0300
Message-ID: <[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset="Windows-1252"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0)
In-Reply-To: <[e-mail]>
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6600
Importance: Normal

unsubscribe [e-mail]


Received: from e1.ny.us.ibm.com (e1.ny.us.ibm.com [32.97.182.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id QAA23270 for <[e-mail]>; Fri, 28 Jul 2000 16:23:25 -0700 (PDT)
From: [e-mail]
Received: from northrelay02.pok.ibm.com (northrelay02.pok.ibm.com [9.117.200.22]) by e1.ny.us.ibm.com (8.9.3/8.9.3) with ESMTP id TAA59172; Fri, 28 Jul 2000 19:26:41 -0400
Received: from D51MTA04.pok.ibm.com (d51mta04.pok.ibm.com [9.117.200.32]) by northrelay02.pok.ibm.com (8.8.8m3/NCO v4.92) with SMTP id TAA25398; Fri, 28 Jul 2000 19:26:37 -0400
Received: by D51MTA04.pok.ibm.com(Lotus SMTP MTA v4.6.5  (863.2 5-20-1999))  id 8525692A.0080C5B9 ; Fri, 28 Jul 2000 19:26:32 -0400
X-Lotus-FromDomain: IBMUS
To: Stephen Kent <[e-mail]>
cc: "PKIX-List" <[e-mail]>
Message-ID: <[e-mail]>
Date: Fri, 28 Jul 2000 19:26:30 -0400
Subject: Re: QC DN "qualities". Was: I-DACTION:draft-ietf-pkix-qc-04.txt
Mime-Version: 1.0
Content-type: text/plain; charset=us-ascii
Content-Disposition: inline

     My point is that in very many cases, an employee serial number or
something like that is just as good for the RP's as a department.  Its
greater stability compensates for its lack of user-friendliness.  As you
rightly pointed out to Anders, if manual selection of one user from a list
of choices is the primary scenario in which an extra attribute is used,
serial numbers aren't the best way to make such a selection.  However, they
may well be more useful for access control lists or for non-repudiation.

          Tom Gindin


Stephen Kent <[e-mail]> on 07/28/2000 06:47:32 PM

To:   Tom Gindin/Watson/IBM@IBMUS
cc:   "PKIX-List" <[e-mail]>
Subject:  Re: QC DN "qualities". Was: I-DACTION:draft-ietf-pkix-qc-04.txt



Tom,

>      Without getting into the question of whether bureaucratic
organization
>is obsolete (personally, I doubt that it is all that obsolete), you can
>just cite the non-quantitative and almost undisputed version of the Rule
of
>Revocation:  "Every additional attribute or extension added to a
>certificate shortens its life expectancy".  Leaving out which department a
>given subject belongs to has to increase the life expectancy of the
>certificate.  If an ID is assigned by an organization for as long as the
>subject is associated with the organization, then it doesn't really
>decrease the life expectancy of a certificate that already contains that
>organization's name, while organizational details or place of residence
do.
>

While it's heartening to hear variants of "Steve's Rule of
revocation" cited, there is still an issue of whether the name assert
in the subject address the fundamental needs of the RPs. If not, then
the reduced revocation frequency is irrelevant.

Steve






Received: from po1.bbn.com (PO1.BBN.COM [192.1.50.38]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id PAA22172 for <[e-mail]>; Fri, 28 Jul 2000 15:48:45 -0700 (PDT)
Received: from [171.78.30.107] (fixed030-107.bbn.com [171.78.30.107] (may be forged)) by po1.bbn.com (8.9.1/8.9.1) with ESMTP id SAA13984; Fri, 28 Jul 2000 18:52:02 -0400 (EDT)
Mime-Version: 1.0
X-Sender: [e-mail]
Message-Id: <v0422081eb5a7bd8f11fb@[171.78.30.107]>
In-Reply-To: <[e-mail]>
References: <[e-mail]>
Date: Fri, 28 Jul 2000 18:47:32 -0400
To: [e-mail]
From: Stephen Kent <[e-mail]>
Subject: Re: QC DN "qualities". Was: I-DACTION:draft-ietf-pkix-qc-04.txt
Cc: "PKIX-List" <[e-mail]>
Content-Type: text/plain; charset="us-ascii" ; format="flowed"

Tom,

>      Without getting into the question of whether bureaucratic organization
>is obsolete (personally, I doubt that it is all that obsolete), you can
>just cite the non-quantitative and almost undisputed version of the Rule of
>Revocation:  "Every additional attribute or extension added to a
>certificate shortens its life expectancy".  Leaving out which department a
>given subject belongs to has to increase the life expectancy of the
>certificate.  If an ID is assigned by an organization for as long as the
>subject is associated with the organization, then it doesn't really
>decrease the life expectancy of a certificate that already contains that
>organization's name, while organizational details or place of residence do.
>

While it's heartening to hear variants of "Steve's Rule of 
revocation" cited, there is still an issue of whether the name assert 
in the subject address the fundamental needs of the RPs. If not, then 
the reduced revocation frequency is irrelevant.

Steve



Received: from po1.bbn.com (PO1.BBN.COM [192.1.50.38]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id PAA22171 for <[e-mail]>; Fri, 28 Jul 2000 15:48:45 -0700 (PDT)
Received: from [171.78.30.107] (fixed030-107.bbn.com [171.78.30.107] (may be forged)) by po1.bbn.com (8.9.1/8.9.1) with ESMTP id SAA13980; Fri, 28 Jul 2000 18:52:01 -0400 (EDT)
Mime-Version: 1.0
X-Sender: [e-mail]
Message-Id: <v0422081db5a7bb9d9cc4@[171.78.30.107]>
In-Reply-To: <001d01bff8e9$c05e57e0$[e-mail]>
References: <001d01bff8e9$c05e57e0$[e-mail]>
Date: Fri, 28 Jul 2000 18:44:41 -0400
To: "Anders Rundgren" <[e-mail]>
From: Stephen Kent <[e-mail]>
Subject: Re: QC DN "qualities". Was: I-DACTION:draft-ietf-pkix-qc-04.txt
Cc: "PKIX-List" <[e-mail]>
Content-Type: text/plain; charset="us-ascii" ; format="flowed"

Anders,

>Steve,
>
>  >Anders,
>  >
>  >There are no ID forms that are both globally unique and globally
>  >meaningful. We use names in contexts, and relate to people by names
>  >in context. That's why a name structured along org and dept lines is
>  >attractive, despite the fact that it requires more frequent
>  >revocation and re-issuance of certs.
>
>I never said I don't understand why people make such certs but I believe
>they are applying PKI in a less than optimal way. To *have to* 
>revoke a certificate
>due to a changed department seems like a bad solution.

I usually get new business cards when my job changes (internally), so 
why not just consider this to be another item I have to change?

>Directories (and other external databases) ought to be a much better 
>way to look
>for additional information  concerning a subject within a certain 
>domain than trying to
>squeeze in unstable data such as department in a certificate.

But directories are not viewed as secure, and hence they are not 
reliable sources of such data, unless the data is signed. If one uses 
attribute certs this is manageable for access control purposes, but 
it still does not address the fundamental issue of mapping certs to 
entities in the real world, which requires context.

>
>And outside the organization domain, departments does not mean that much.
>
>There is also a great risk that you during the transitional phase between two
>departments can find yourself be stuck with a useless or revoked certificate.
>
>By leaving out department you can even be a valid member of more than
>one department!
>
>My conclusion: Departments and such stuff are just relics from the 
>*almost* extinct, static, off-line world.

We disagree, as usual. Maybe too much emphasis on departments. Still, 
an example may help. In our company we have a voice recognition 
system that listens to a name and dials the phone number of the 
person we want to call. How do we differentiate between two people 
with the same first and last names?  We don't add in the middle name, 
because most people would not know it and so, even though it would 
serve to make more names unique, it would fail to be meaningful to 
the caller.  Instead we add in a qualifier such as office locale 
(city) or department, etc.  This is not a PKI problem, its a general 
"how do you name the individual meaningfully and uniquely" problem.

Steve



Received: from e1.ny.us.ibm.com (e1.ny.us.ibm.com [32.97.182.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id PAA21806 for <[e-mail]>; Fri, 28 Jul 2000 15:36:39 -0700 (PDT)
From: [e-mail]
Received: from northrelay02.pok.ibm.com (northrelay02.pok.ibm.com [9.117.200.22]) by e1.ny.us.ibm.com (8.9.3/8.9.3) with ESMTP id SAA49526; Fri, 28 Jul 2000 18:39:55 -0400
Received: from D51MTA04.pok.ibm.com (d51mta04.pok.ibm.com [9.117.200.32]) by northrelay02.pok.ibm.com (8.8.8m3/NCO v4.92) with SMTP id SAA41028; Fri, 28 Jul 2000 18:39:55 -0400
Received: by D51MTA04.pok.ibm.com(Lotus SMTP MTA v4.6.5  (863.2 5-20-1999))  id 8525692A.007C7F06 ; Fri, 28 Jul 2000 18:39:49 -0400
X-Lotus-FromDomain: IBMUS
To: "Anders Rundgren" <[e-mail]>
cc: "Stephen Kent" <[e-mail]>, "PKIX-List" <[e-mail]>
Message-ID: <[e-mail]>
Date: Fri, 28 Jul 2000 18:39:45 -0400
Subject: Re: QC DN "qualities". Was: I-DACTION:draft-ietf-pkix-qc-04.txt
Mime-Version: 1.0
Content-type: text/plain; charset=us-ascii
Content-Disposition: inline

     Without getting into the question of whether bureaucratic organization
is obsolete (personally, I doubt that it is all that obsolete), you can
just cite the non-quantitative and almost undisputed version of the Rule of
Revocation:  "Every additional attribute or extension added to a
certificate shortens its life expectancy".  Leaving out which department a
given subject belongs to has to increase the life expectancy of the
certificate.  If an ID is assigned by an organization for as long as the
subject is associated with the organization, then it doesn't really
decrease the life expectancy of a certificate that already contains that
organization's name, while organizational details or place of residence do.

          Tom Gindin


"Anders Rundgren" <[e-mail]> on 07/28/2000 07:15:40 PM

To:   "Stephen Kent" <[e-mail]>
cc:   "PKIX-List" <[e-mail]>
Subject:  Re: QC DN "qualities". Was: I-DACTION:draft-ietf-pkix-qc-04.txt



Steve,

>Anders,
>
>There are no ID forms that are both globally unique and globally
>meaningful. We use names in contexts, and relate to people by names
>in context. That's why a name structured along org and dept lines is
>attractive, despite the fact that it requires more frequent
>revocation and re-issuance of certs.

I never said I don't understand why people make such certs but I believe
they are applying PKI in a less than optimal way. To *have to* revoke a
certificate
due to a changed department seems like a bad solution.

Directories (and other external databases) ought to be a much better way to
look
for additional information  concerning a subject within a certain domain
than trying to
squeeze in unstable data such as department in a certificate.

And outside the organization domain, departments does not mean that much.

There is also a great risk that you during the transitional phase between
two
departments can find yourself be stuck with a useless or revoked
certificate.

By leaving out department you can even be a valid member of more than
one department!

My conclusion: Departments and such stuff are just relics from the *almost*
extinct, static, off-line world.

<snip>

Anders




Received: from prv-mail20.provo.novell.com (prv-mail20.provo.novell.com [137.65.81.122]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id PAA21360 for <[e-mail]>; Fri, 28 Jul 2000 15:22:00 -0700 (PDT)
Received: from INET-PRV-Message_Server by prv-mail20.provo.novell.com with Novell_GroupWise; Fri, 28 Jul 2000 16:24:43 -0600
Message-Id: <[e-mail]>
X-Mailer: Novell GroupWise Internet Agent 5.5.3.1
Date: Fri, 28 Jul 2000 16:24:43 -0600
From: "Bob Jueneman" <[e-mail]>
To: <[e-mail]>, <[e-mail]>, <[e-mail]>
Cc: <[e-mail]>
Subject: RE: Dual-signed certificates
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by ns.secondary.com id PAA21363

Exactly.  Nicely summarized, Tony.

Bob

>>> Tony Bartoletti <[e-mail]> 07/28/00 03:57PM >>>
At 04:11 PM 7/27/00 +0900, Hiroyuki Sakakibara wrote:
>A self-signed certificate that contains the original
>certificate as an extension within it, or, a dual-signed
>certificate using CMS SignedData are recommended in this-list.
>
>On Mon, 24 Jul 2000 Mr. Russ Housley wrote:
> >Bob:
>
> >There are some significant technical issues here.  The subject cannot sign
> >first because it does not know the values that will be assigned for several
> >fields, like the serial number.  The subject cannot sign second
> >either.  The insertion of an additional extension will break the issuer
> >signature.
>
> >Thus, to proceed in this vain, complex processing must be defined that says
> >which parts of the certificate are covered by the subject signature in the
> >extension.  I think that the processing is complex enough....
>
> >Russ
>
>Is a X.509 ver3 certificate,
>including such as "Issuance Agreement"extension signed by a subject
>not feasible ?
>
>Extension : Issuance Agreement
>means that "Subject agrees with issuance of his certificate
>which includes fields and values described in this agreement."
>Fields and values include public key, issuer name, subject name,
>extensions etc..., but DO NOT include CA's signature.

A subject-signed "Issuance Agreement" extension would seem to work
from the CA's point of view.  The subject data could be signed by
the subject (prior to encryption by the root-public-key) as part of
a certificate request.  Then, as I understand Hiroyuki's suggestion,
this "submission" would become a certificate extension.

However, this method involves a near-duplication of information that
"must be preserved", and would seem to require the relying party
retrieve/check the "Issuance Agreement" against the actual elements
of the certificate, in order to preclude some claim by the subject
that they (plausibly) never agreed to the certificate terms.

Why (really) cannot the CA supply the "pre" (unsigned) certificate
for the subject review and signature, prior to the final CA signature?

I do not understand the argument "subject cannot sign first" because
some values (e.g., serial number) cannot be pre-assigned.  Absent the
CA-signature, the certificate is merely a string of bytes that anyone
can generate.  It cannot have value prior to this CA-signature.  And
I can't believe the market is suffering a shortage of serial numbers.

A protocol that provided the subject "sign first" seems very elegant,
in that you get POP on the key, and POA (proof of acceptance) on the
(pre)certificate, all in one shot.  And no duplication of the data.

Is there a really compelling reason why "subject-sign-first" is
a bad idea?


Tony Bartoletti 925-422-3881 <[e-mail]>
Information Operations, Warfare and Assurance Center
Lawrence Livermore National Laboratory
Livermore, CA 94551-9900




Received: from prv-mail20.provo.novell.com (prv-mail20.provo.novell.com [137.65.81.122]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id PAA21187 for <[e-mail]>; Fri, 28 Jul 2000 15:20:25 -0700 (PDT)
Received: from INET-PRV-Message_Server by prv-mail20.provo.novell.com with Novell_GroupWise; Fri, 28 Jul 2000 16:22:54 -0600
Message-Id: <[e-mail]>
X-Mailer: Novell GroupWise Internet Agent 5.5.3.1
Date: Fri, 28 Jul 2000 16:22:45 -0600
From: "Bob Jueneman" <[e-mail]>
To: <[e-mail]>, <[e-mail]>
Subject: RE: Dual-signed certificates
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by ns.secondary.com id PAA21188

David,

> The point is that in many respects we tend to grant an excessive
> amount of authority to the CA in terms of establishing policy, etc.,
> and yet in most cases (other than some closed user groups) the CA is
> not in a position to be able to enforce those policies against a
> particular user.  So the real issue is what terms and conditions the
> subscriber has agreed to, and how that acceptance can be reliably made
> known.
> 
> (This point of view may of course be anathema to those who espouse a
> top-down, authoritarian control structure, including many European
> countries and perhaps the US DOD.  Chacun a son gout.:-)

>Bob, you're starting to sound like Peter Williams.  Take that as a
compliment if you wish. :-).

But what will Peter say! :-)

>Any non-commercial PKI exists solely to serve Relying Parties - the
benefit to the RPs must exceed the cost of operating the CAs and
outfitting (and inconveniencing) the Subscribers.  Any obligations a
DoD CA imposes on its Subscribers exist to provide evidence to RPs that
the contents of a certificate are accurate (to the level of assurance
advertised within the certificate).

>The DoD Certificate Policy is maintained by, surprisingly, the DoD
Certificate Policy Management Working Group, which has representatives
from all the Services and Agencies which make up the Subscriber and RP
population.  DoD CAs have no independent authority; they only do what
the customers have agreed should be done.

>Can you cite from the DoD Certificate Policy or elsewhere a Subscriber
Obligation which you feel is unnecessary, excessive, or gratuitously
authoritarian?  If not, perhaps you should eschew the gratuitous
flame bait. 

Seriously, the above was not intended as flame bait, nor intended to 
derogate the role of DoD, or even other countries with more top-down and/or
authoritarian cultures and legal traditions, e.g., Sweden or Germany,
and the civil law countries in general.

Top-down policy controls may be perfectly suitable for hierarchical organizations,
which certainly includes the Executive branch of the US Government.
And in that kind of structure it is perfectly appropriate that the services
and agencies decide what the policy should be, and how they are going to 
interoperate, and especially so for servers and other functions under the 
direct control of those agencies and services.  And as for the individual
employees or servicemen within those organizations, they will do 
what they are told, or face a court martial, presumably.

And by the way, it is also perfectly appropriate for intra-organization PKI,
and for closed, limited-purpose organizations such as stock brokers,
and maybe (not clear) for credit card applications.  such
organizations can establish rules, and fully expect people within 
that organization to play by them

All that I was trying to suggest was that for less structured organizations,
such as the organized anarchy that constitutes the Internet community
and the consumer marketplace, or even the business-to-business
market, relying on the CA to enforce policy conditions upon the 
subscribers is probably not realistic in terms of expectations, and in addition is on
very shaky legal ground.

If A and B both have a contract with C, then B cannot sue C just because
A fails to carry out its obligations to C.  And if B (the relying party) does not 
have a contract with C (the CA), as is typically the case in the broad PKI
industry, then B's reliance on C to hold A to a certain code of conduct is 
even more shaky.

So in that less-well structured environment, I am much less interested in
what the CA knows or thinks about the subscriber's conduct -- I want to know
directly from the subscriber, with whom I do have a direct legal relationship,
and I can sue if necessary.

So I don't think we are disagreeing -- we are just talking about
two radically different environments.

Bob




Received: from d1o69.telia.com ([e-mail] [62.20.144.241]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id PAA20879 for <[e-mail]>; Fri, 28 Jul 2000 15:13:23 -0700 (PDT)
Received: from mega (t5o69p21.telia.com [213.64.110.21]) by d1o69.telia.com (8.8.8/8.8.8) with SMTP id AAA24583; Sat, 29 Jul 2000 00:16:37 +0200 (CEST)
Message-ID: <001d01bff8e9$c05e57e0$[e-mail]>
From: "Anders Rundgren" <[e-mail]>
To: "Stephen Kent" <[e-mail]>
Cc: "PKIX-List" <[e-mail]>
Subject: Re: QC DN "qualities". Was: I-DACTION:draft-ietf-pkix-qc-04.txt
Date: Sat, 29 Jul 2000 01:15:40 +0200
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 4.72.3110.5
X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by ns.secondary.com id PAA20880

Steve,

>Anders,
>
>There are no ID forms that are both globally unique and globally 
>meaningful. We use names in contexts, and relate to people by names 
>in context. That's why a name structured along org and dept lines is 
>attractive, despite the fact that it requires more frequent 
>revocation and re-issuance of certs. 

I never said I don't understand why people make such certs but I believe
they are applying PKI in a less than optimal way. To *have to* revoke a certificate 
due to a changed department seems like a bad solution.  

Directories (and other external databases) ought to be a much better way to look
for additional information  concerning a subject within a certain domain than trying to
squeeze in unstable data such as department in a certificate. 

And outside the organization domain, departments does not mean that much. 

There is also a great risk that you during the transitional phase between two
departments can find yourself be stuck with a useless or revoked certificate.

By leaving out department you can even be a valid member of more than
one department!

My conclusion: Departments and such stuff are just relics from the *almost* extinct, static, off-line world.

<snip>

Anders




Received: from poptop.llnl.gov (poptop.llnl.gov [128.115.41.70]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id OAA19861 for <[e-mail]>; Fri, 28 Jul 2000 14:47:09 -0700 (PDT)
Received: from catalyst (catalyst.llnl.gov [128.115.222.68]) by poptop.llnl.gov (8.8.8/LLNL-3.0.2/pop.llnl.gov-5.1) with ESMTP id OAA11489; Fri, 28 Jul 2000 14:49:54 -0700 (PDT)
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.2 
Date: Fri, 28 Jul 2000 14:57:39 -0700
To: "Hiroyuki Sakakibara" <[e-mail]>, <[e-mail]>
From: Tony Bartoletti <[e-mail]>
Subject: RE: Dual-signed certificates
Cc: Russ Housley <[e-mail]>, "Bob Jueneman" <[e-mail]>
In-Reply-To: <00d401bff799$e85191a0$[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed

At 04:11 PM 7/27/00 +0900, Hiroyuki Sakakibara wrote:
>A self-signed certificate that contains the original
>certificate as an extension within it, or, a dual-signed
>certificate using CMS SignedData are recommended in this-list.
>
>On Mon, 24 Jul 2000 Mr. Russ Housley wrote:
> >Bob:
>
> >There are some significant technical issues here.  The subject cannot sign
> >first because it does not know the values that will be assigned for several
> >fields, like the serial number.  The subject cannot sign second
> >either.  The insertion of an additional extension will break the issuer
> >signature.
>
> >Thus, to proceed in this vain, complex processing must be defined that says
> >which parts of the certificate are covered by the subject signature in the
> >extension.  I think that the processing is complex enough....
>
> >Russ
>
>Is a X.509 ver3 certificate,
>including such as "Issuance Agreement"extension signed by a subject
>not feasible ?
>
>Extension : Issuance Agreement
>means that "Subject agrees with issuance of his certificate
>which includes fields and values described in this agreement."
>Fields and values include public key, issuer name, subject name,
>extensions etc..., but DO NOT include CA's signature.

A subject-signed "Issuance Agreement" extension would seem to work
from the CA's point of view.  The subject data could be signed by
the subject (prior to encryption by the root-public-key) as part of
a certificate request.  Then, as I understand Hiroyuki's suggestion,
this "submission" would become a certificate extension.

However, this method involves a near-duplication of information that
"must be preserved", and would seem to require the relying party
retrieve/check the "Issuance Agreement" against the actual elements
of the certificate, in order to preclude some claim by the subject
that they (plausibly) never agreed to the certificate terms.

Why (really) cannot the CA supply the "pre" (unsigned) certificate
for the subject review and signature, prior to the final CA signature?

I do not understand the argument "subject cannot sign first" because
some values (e.g., serial number) cannot be pre-assigned.  Absent the
CA-signature, the certificate is merely a string of bytes that anyone
can generate.  It cannot have value prior to this CA-signature.  And
I can't believe the market is suffering a shortage of serial numbers.

A protocol that provided the subject "sign first" seems very elegant,
in that you get POP on the key, and POA (proof of acceptance) on the
(pre)certificate, all in one shot.  And no duplication of the data.

Is there a really compelling reason why "subject-sign-first" is
a bad idea?


Tony Bartoletti 925-422-3881 <[e-mail]>
Information Operations, Warfare and Assurance Center
Lawrence Livermore National Laboratory
Livermore, CA 94551-9900



Received: from roadblock.missi.ncsc.mil (roadblock.missi.ncsc.mil [144.51.50.70]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id NAA17797 for <[e-mail]>; Fri, 28 Jul 2000 13:24:44 -0700 (PDT)
Received: from roadblock.missi.ncsc.mil (root@localhost) by roadblock.missi.ncsc.mil with ESMTP id QAA06850 for <[e-mail]>; Fri, 28 Jul 2000 16:15:35 -0400 (EDT)
Message-Id: <[e-mail]>
Date: Fri, 28 Jul 2000 16:23:56 -0400 (EDT)
From: "David P. Kemp" <[e-mail]>
Reply-To: "David P. Kemp" <[e-mail]>
Subject: RE: Dual-signed certificates
To: [e-mail]
MIME-Version: 1.0
Content-Type: TEXT/plain; charset=us-ascii
Content-MD5: kVlmSJqGaGRO9wVTtuaIWQ==
X-Mailer: dtmail 1.3.0 CDE Version 1.3 SunOS 5.7 sun4u sparc

> From: "Bob Jueneman" <[e-mail]>
> 
> Denis proposed:
> 
> ><There exists a way, including by a procedure that is verifiable for
> > every received signature by any relying party. In the stuff that got
> > signed, you include the identifier of the certificate. This may be
> > done by using CMS (or is mandated in ES 201733). There is no need to
> > invent a double-signed certificate.
> 
> The point is that this procedure works for every legitimate document
> that I signed, but is not enforceable AS AN EXPECTATION against some
> illegitimate use of my certificate/key.
> 
> Now I grant that a CA can easily create a key pair and a certificate
> that would impersonate me for some small number of documents.  But I
> would attempt to repudiate that so-called signature by saying, "That
> signature and key is not mine, and I have never sees or made beneficial
> use of that key.  My key is xxxxxxx, and in fact I _have_ made
> extensive use of that key, and I have signalled my acceptance of that
> key, the certificate, and the terms and conditions of that certificate
> by counter-signing it and distributing widely in that counter-signed
> format."
> 
> The rogue CA could claim the same thing, of coruse, but then I would
> ask to see demonstrated beneficial use on my behalf, for example
> goods that were ordered and delivered (and accepted) to my address,
> based on that key.
> 
> A dual-signed certificate would also be beneficial to the good CAs,
> because it would provide a degree of proof that I had in fact accepted
> the certificate.


If you use a CMS-signed transactions with the signingCertificate
attribute as proposed by Denis, you have a degree of proof that the
user has accepted the cert by virtue of his use of the private key to
sign the transaction.  This is no weaker than accepting the certificate
by using the same private key to dual-sign the certificate, and it has
the additional benefit of binding the cert to the transaction.

A simple signed message of acceptance (the message body could be empty)
signed by the client would be just as beneficial to the CA as a
dual-signature on the cert, and as Denis points out, it requires no new
data formats to be defined.  In fact, you could define the dual-signature
format to be a CMS message with a null message body if you insist
on having an object you could call a "dual-signed certificate".



> The point is that in many respects we tend to grant an excessive
> amount of authority to the CA in terms of establishing policy, etc.,
> and yet in most cases (other than some closed user groups) the CA is
> not in a position to be able to enforce those policies against a
> particular user.  So the real issue is what terms and conditions the
> subscriber has agreed to, and how that acceptance can be reliably made
> known.
> 
> (This point of view may of course be anathema to those who espouse a
> top-down, authoritarian control structure, including many European
> countries and perhaps the US DOD.  Chacun a son gout.:-)


Bob, you're starting to sound like Peter Williams.  Take that as a
compliment if you wish. :-).

Any non-commercial PKI exists solely to serve Relying Parties - the
benefit to the RPs must exceed the cost of operating the CAs and
outfitting (and inconveniencing) the Subscribers.  Any obligations a
DoD CA imposes on its Subscribers exist to provide evidence to RPs that
the contents of a certificate are accurate (to the level of assurance
advertised within the certificate).

The DoD Certificate Policy is maintained by, surprisingly, the DoD
Certificate Policy Management Working Group, which has representatives
from all the Services and Agencies which make up the Subscriber and RP
population.  DoD CAs have no independent authority; they only do what
the customers have agreed should be done.

Can you cite from the DoD Certificate Policy or elsewhere a Subscriber
Obligation which you feel is unnecessary, excessive, or gratuitously
authoritarian?  If not, perhaps you should eschew the gratuitous
flame bait. 



Received: from prv-mail20.provo.novell.com (prv-mail20.provo.novell.com [137.65.81.122]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id MAA16793 for <[e-mail]>; Fri, 28 Jul 2000 12:58:13 -0700 (PDT)
Received: from INET-PRV-Message_Server by prv-mail20.provo.novell.com with Novell_GroupWise; Fri, 28 Jul 2000 14:00:56 -0600
Message-Id: <[e-mail]>
X-Mailer: Novell GroupWise Internet Agent 5.5.3.1
Date: Fri, 28 Jul 2000 14:00:53 -0600
From: "Bob Jueneman" <[e-mail]>
To: <[e-mail]>, <[e-mail]>
Subject: Re: Dual-signed certificates
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by ns.secondary.com id MAA16794

Simon,

Both of your points are valid, and I'm not going to fall on my sword if this notion 
doesn't take off.

I guess my fundamental points were that it would be nice to have some way to
indicate to the relying party directly that the subscriber had agreed to 
the terms of the certificate and the policy requirements behind it; and that
I am increasingly uncomfortable with the continuing and eternal reliance on the
CA to drive policy, hang on to all of the evidence, etc.  CAs to date have just not
established the fact that then can successfully handle those on-going
responsibilities.

As a legal matter, I'm not at all sure that I can sue the CA for some failing of the
subscriber, and so I would like to minibike my reliance on the CA for an on-going
relationship.

I'm willing to trust the CA for the initial identity/binding confirmation, but for any
on-going issues of trust (with the except of a certificate revocation) I would prefer 
deal on a two-party relationship rather than a triangular deal.  Maybe that's just me.

Bob

>>> "Simon McMahon" <[e-mail]> 07/28/00 02:42AM >>>
Hi Bob,

> The present, more or less-well-accepted CA model is that the subscriber
goes to a local RA and requests a certificate be issued in his name.  That
RA is then free to add or modify whatever it likes to the certificate
request, and sends it on to the CA to be certified.
>
> But the CA, depending on its CP and CPS, may add, modify, or delete
information in the certificate request to suit its own purposes.  It could
add DN qualification to make the DN unique, it could add various policy OIDs
and policy constraints -- whatever it wishes to do.
>
> It then sends the certificate back to the user, or posts it in a
repository, but with no nonrepudiable evidence that either the RA or the
subscriber had in fact agreed to those changes or additions!
>
How well accepted is that model ? You are suggesting that a certificate may
bare little resemblance to what the subscriber asked for. Of course that
will require the subject to acknowledge / accept the certificate. An
alternative model is where all the conditions are decided upon at
registration time and the RA and CA do not mess about with any policy OIDs
so that the cert is accepted by virtue of the fact that it (at least the
policy relevant parts) are derived solely from request.

> Moreover, a rogue CA could create two such certificates, one containing
terms favorable to it, and another closer to what the subscriber had
originally requested.  Now, because the inclusion of the certificate in a
transaction to be signed is (1) optional, and (2) only applies to
transactions per se and not to session authentication or encryption, the
relying party has no way of knowing whether the user in fact agreed to those
terms..
>
> This is why relying on a signed CMS object won't work -- the RP has no
good way of knowing whether that format was expected or not.
>
RPs that trust rogue CAs shouldn't be considered a valid argument for PKI
architecture discussions. If you build complexity into the protocols to try
and accomidate every such thing then it will not get deployed widely and
people will consider alternatives. Look what happened to SET.

Regards,

Simon McMahon
ERACOM Pty. Ltd.





Received: from po1.bbn.com (PO1.BBN.COM [192.1.50.38]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id IAA28538 for <[e-mail]>; Fri, 28 Jul 2000 08:01:30 -0700 (PDT)
Received: from [171.78.30.107] (fixed030-107.bbn.com [171.78.30.107] (may be forged)) by po1.bbn.com (8.9.1/8.9.1) with ESMTP id LAA11912; Fri, 28 Jul 2000 11:04:44 -0400 (EDT)
Mime-Version: 1.0
X-Sender: [e-mail]
Message-Id: <v04220807b5a74f342460@[171.78.30.107]>
In-Reply-To: <002501bff8a3$6f0eecb0$[e-mail]>
References: <002501bff8a3$6f0eecb0$[e-mail]>
Date: Fri, 28 Jul 2000 10:58:04 -0400
To: "Anders Rundgren" <[e-mail]>
From: Stephen Kent <[e-mail]>
Subject: Re: QC DN "qualities". Was: I-DACTION:draft-ietf-pkix-qc-04.txt
Cc: <[e-mail]>
Content-Type: text/plain; charset="us-ascii" ; format="flowed"

Anders,

There are no ID forms that are both globally unique and globally 
meaningful. We use names in contexts, and relate to people by names 
in context.  That's why a name structured along org and dept lines is 
attractive, despite the fact that it requires more frequent 
revocation and re-issuance of certs. It is also why no single cert is 
likely to be appropriate for identifying individuals in all contexts. 
Moreover, we often use name in certs as inputs for access control 
decisions.  because many such decisions are made based on 
organizational structure, it is convenient to embed that structure in 
subject names, e.g, it allows for structured ACL entries.

Steve


Received: from d1o69.telia.com ([e-mail] [62.20.144.241]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id GAA22325 for <[e-mail]>; Fri, 28 Jul 2000 06:50:04 -0700 (PDT)
Received: from mega (t4o69p32.telia.com [62.20.145.152]) by d1o69.telia.com (8.8.8/8.8.8) with SMTP id PAA24599; Fri, 28 Jul 2000 15:53:16 +0200 (CEST)
Message-ID: <002501bff8a3$6f0eecb0$[e-mail]>
From: "Anders Rundgren" <[e-mail]>
To: "Denis Pinkas" <[e-mail]>
Cc: "Stefan Santesson" <[e-mail]>, <[e-mail]>
Subject: Re: QC DN "qualities". Was: I-DACTION:draft-ietf-pkix-qc-04.txt
Date: Fri, 28 Jul 2000 16:52:20 +0200
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 4.72.3110.5
X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by ns.secondary.com id GAA22329

Denis,

>> >There is no specific rule that you can apply to a Swedish
>> >certificate to bear a different semantics of *one* component of the
>> >DN (ie. the Swedish civic registration number, which is the last
>> >component of the name). The same rules apply to all certificates,
>> >hence there is no notion of "context".
>
>> Stefan is right.  Unfortunately you must know a lot of things before you
>> can treat certs in such a way.  This usage is wrong according to some notable people
>> on this list but this is also the reality.
>
>You cannot say "Stefan is right" while you say just after "this
>usage is wrong". :-)
>Neither RFC2459, nor son-of-RFC2459, nor QC-05 makes such an
>interpretation of the serial number component of the DN.

In my opinion it does not matter what the spec. says as an interpretation
of this kind is needed to re-create the *functionality* of the Swedish ID-system in PKI. 
In Sweden, names are in principle variable attributes, civic registration number is identity.
Of course they could have put the names in SubjectAltNames but that would look awful
when you see the cert in Internet Explorer or Navigator.  Admittely the Swedish solution
is not rocket-science or very clean, but the culprit is really X509/PKIX that lacks proper
support for schemes like that.

I am also 100% sure that this is also performed in many organization-oriented PKIs as
it is just plain stupid to lose or have to renew a link to a "numbered person" beacuse
they changed name or department.  Why then bother with names and departments in the first
place one could argue?  Well, it is the old way of doing things (hard to change) and when
you got that first contact with a new RP it helps a bit to know that you are not only "6575765" but also 
"Marion Anderson"


>> Is not this almost the sole reason you and Tim work with the PI-specification?

>This is one of the reasons, but not the single one.

Enlighten me! What are the other *major* reasons (i.e. beyond limiting the need for "smart", non-standard DN iterpretation)?

Anders



Received: from popmail.inbox.se (popmail.inbox.se [193.12.72.102]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id GAA21193 for <[e-mail]>; Fri, 28 Jul 2000 06:45:16 -0700 (PDT)
Received: from santesson.accurata.se (sfr-qbu-pqn-vty7.as.wcom.net [216.192.22.7]) by popmail.inbox.se (8.9.3/8.9.3) with ESMTP id PAA28017; Fri, 28 Jul 2000 15:48:18 +0200
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Version 4.3.2
Date: Fri, 28 Jul 2000 07:50:02 -0600
To: "Anders Rundgren" <[e-mail]>, "Denis Pinkas" <[e-mail]>
From: Stefan Santesson <[e-mail]>
Subject: Re: QC DN "qualities". Was: I-DACTION:draft-ietf-pkix-qc-04.txt
Cc: <[e-mail]>
In-Reply-To: <000c01bff87f$dd26b620$[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed

At 12:37 2000-07-28 +0200, Anders Rundgren wrote:
><snip>
>
> >> I.e. If you have a Swedish certificate with Swedish civic registration
> >> number. Then you can know that the DN represent the same person even if
> >> some other data is differing.
> >
> >There is no specific rule that you can apply to a Swedish
> >certificate to bear a different semantics of *one* component of the
> >DN (ie. the Swedish civic registration number, which is the last
> >component of the name). The same rules apply to all certificates,
> >hence there is no notion of "context".

This last comment is not correct.

Yes it is right that there is no definition of context in the subject field 
but there are several other ways by which the relying party can determine 
context.

1) By recognizing an implicit policy for all certificates issued under a 
certain root CA
2) By implicit knowledge of certificates issued by a certain CA
3) By information defined by a contained policy OID
4) By explicit definition in the QCStatements extension

There might be others but these are enough to demonstrate my point.

/Stefan



Received: from odin2.bull.net (odin2.bull.net [192.90.70.84]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id FAA13305 for <[e-mail]>; Fri, 28 Jul 2000 05:16:06 -0700 (PDT)
Received: from lvt-mail.frlv.bull.fr (lvt-mail.frlv.bull.fr [129.184.62.223]) by odin2.bull.net (8.9.3/8.9.3) with ESMTP id OAA42236; Fri, 28 Jul 2000 14:23:13 +0200
Received: from bull.net (frpq6118.frpq.bull.fr [129.184.8.64]) by lvt-mail.frlv.bull.fr (8.9.2/8.9.1) with ESMTP id OAA20454; Fri, 28 Jul 2000 14:18:41 +0200
Message-ID: <[e-mail]>
Date: Fri, 28 Jul 2000 14:18:44 +0200
From: Denis Pinkas <[e-mail]>
Organization: Bull
X-Mailer: Mozilla 4.7 [fr] (Win98; I)
X-Accept-Language: fr
MIME-Version: 1.0
To: Frank Balluffi <[e-mail]>
CC: [e-mail]
Subject: Re: OCSP request
References: <[e-mail]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Frank,

> > This is wrong. A chain of time stamps protects against key
> > compromise, as well as weak algorithms, as long as the
> > timestamps have been
> > applied before the key has been compromised or the algorithm
> > has been found
> > weak. So there is no need to ask the CA.
> 
> I agree. It may be desirable to include OCSP responses in the data to be
> timestamped. For example, a construct like a CMS/PKCS #7 SignedData that
> includes OCSP responses might be very useful.

Your example is perfectly right. This is exactly one of the options
currently defined in:

http://www.ietf.org/internet-drafts/draft-ietf-smime-esformats-01.txt

Denis

> Frank


Received: from odin2.bull.net (odin2.bull.net [192.90.70.84]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id CAA01635 for <[e-mail]>; Fri, 28 Jul 2000 02:57:29 -0700 (PDT)
Received: from lvt-mail.frlv.bull.fr (lvt-mail.frlv.bull.fr [129.184.62.223]) by odin2.bull.net (8.9.3/8.9.3) with ESMTP id MAA41404; Fri, 28 Jul 2000 12:04:41 +0200
Received: from bull.net (frpq6118.frpq.bull.fr [129.184.8.64]) by lvt-mail.frlv.bull.fr (8.9.2/8.9.1) with ESMTP id MAA38966; Fri, 28 Jul 2000 12:00:08 +0200
Message-ID: <[e-mail]>
Date: Fri, 28 Jul 2000 12:00:11 +0200
From: Denis Pinkas <[e-mail]>
Organization: Bull
X-Mailer: Mozilla 4.7 [fr] (Win98; I)
X-Accept-Language: fr
MIME-Version: 1.0
To: Anders Rundgren <[e-mail]>
CC: Stefan Santesson <[e-mail]>, [e-mail]
Subject: Re: QC DN "qualities". Was: I-DACTION:draft-ietf-pkix-qc-04.txt
References: <000c01bff87f$dd26b620$[e-mail]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Anders,

> <snip>
 
> >> I.e. If you have a Swedish certificate with Swedish civic registration
> >> number. Then you can know that the DN represent the same person even if
> >> some other data is differing.

> >There is no specific rule that you can apply to a Swedish
> >certificate to bear a different semantics of *one* component of the
> >DN (ie. the Swedish civic registration number, which is the last
> >component of the name). The same rules apply to all certificates,
> >hence there is no notion of "context".

> Denis,

> Stefan is right.  Unfortunately you must know a lot of things before you
> can treat certs in such a way.  This usage is wrong according to some notable people
> on this list but this is also the reality.

You cannot say "Stefan is right" while you say just after "this
usage is wrong". :-)
Neither RFC2459, nor son-of-RFC2459, nor QC-05 makes such an
interpretation of the serial number component of the DN.

> Is not this almost the sole reason you and Tim work with the PI-specification?

This is one of the reasons, but not the single one.

Denis

> Anders


Received: from d1o69.telia.com ([e-mail] [62.20.144.241]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id CAA29826 for <[e-mail]>; Fri, 28 Jul 2000 02:35:26 -0700 (PDT)
Received: from mega (t6o69p82.telia.com [213.64.110.202]) by d1o69.telia.com (8.8.8/8.8.8) with SMTP id LAA11813; Fri, 28 Jul 2000 11:38:38 +0200 (CEST)
Message-ID: <000c01bff87f$dd26b620$[e-mail]>
From: "Anders Rundgren" <[e-mail]>
To: "Denis Pinkas" <[e-mail]>, "Stefan Santesson" <[e-mail]>
Cc: <[e-mail]>
Subject: Re: QC DN "qualities". Was: I-DACTION:draft-ietf-pkix-qc-04.txt
Date: Fri, 28 Jul 2000 12:37:42 +0200
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 4.72.3110.5
X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by ns.secondary.com id CAA29827

<snip>

>> I.e. If you have a Swedish certificate with Swedish civic registration
>> number. Then you can know that the DN represent the same person even if
>> some other data is differing.
>
>There is no specific rule that you can apply to a Swedish
>certificate to bear a different semantics of *one* component of the
>DN (ie. the Swedish civic registration number, which is the last
>component of the name). The same rules apply to all certificates,
>hence there is no notion of "context".


Denis,
Stefan is right.  Unfortunately you must know a lot of things before you
can treat certs in such a way.  This usage is wrong according to some notable people
on this list but this is also the reality.

Is not this almost the sole reason you and Tim work with the PI-specification?


Anders




Received: from diablo.OntheNet.com.au (diablo.OntheNet.com.au [203.10.89.2]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id BAA26129 for <[e-mail]>; Fri, 28 Jul 2000 01:31:16 -0700 (PDT)
Received: from msimon (pc3.eracom.com.au [203.144.16.147]) by diablo.OntheNet.com.au (8.9.3/8.9.3) with SMTP id SAA70376; Fri, 28 Jul 2000 18:34:18 +1000 (EST)
Message-ID: <04a601bff86f$dcb522e0$[e-mail]>
From: "Simon McMahon" <[e-mail]>
To: "Bob Jueneman" <[e-mail]>, <[e-mail]>
References: <[e-mail]>
Subject: Re: Dual-signed certificates
Date: Fri, 28 Jul 2000 18:42:40 +1000
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.00.2314.1300
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300

Hi Bob,

> The present, more or less-well-accepted CA model is that the subscriber
goes to a local RA and requests a certificate be issued in his name.  That
RA is then free to add or modify whatever it likes to the certificate
request, and sends it on to the CA to be certified.
>
> But the CA, depending on its CP and CPS, may add, modify, or delete
information in the certificate request to suit its own purposes.  It could
add DN qualification to make the DN unique, it could add various policy OIDs
and policy constraints -- whatever it wishes to do.
>
> It then sends the certificate back to the user, or posts it in a
repository, but with no nonrepudiable evidence that either the RA or the
subscriber had in fact agreed to those changes or additions!
>
How well accepted is that model ? You are suggesting that a certificate may
bare little resemblance to what the subscriber asked for. Of course that
will require the subject to acknowledge / accept the certificate. An
alternative model is where all the conditions are decided upon at
registration time and the RA and CA do not mess about with any policy OIDs
so that the cert is accepted by virtue of the fact that it (at least the
policy relevant parts) are derived solely from request.

> Moreover, a rogue CA could create two such certificates, one containing
terms favorable to it, and another closer to what the subscriber had
originally requested.  Now, because the inclusion of the certificate in a
transaction to be signed is (1) optional, and (2) only applies to
transactions per se and not to session authentication or encryption, the
relying party has no way of knowing whether the user in fact agreed to those
terms..
>
> This is why relying on a signed CMS object won't work -- the RP has no
good way of knowing whether that format was expected or not.
>
RPs that trust rogue CAs shouldn't be considered a valid argument for PKI
architecture discussions. If you build complexity into the protocols to try
and accomidate every such thing then it will not get deployed widely and
people will consider alternatives. Look what happened to SET.

Regards,

Simon McMahon
ERACOM Pty. Ltd.




Received: from odin2.bull.net (odin2.bull.net [192.90.70.84]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id BAA25040 for <[e-mail]>; Fri, 28 Jul 2000 01:15:24 -0700 (PDT)
Received: from lvt-mail.frlv.bull.fr (lvt-mail.frlv.bull.fr [129.184.62.223]) by odin2.bull.net (8.9.3/8.9.3) with ESMTP id KAA38398; Fri, 28 Jul 2000 10:22:35 +0200
Received: from bull.net (frpq6118.frpq.bull.fr [129.184.8.64]) by lvt-mail.frlv.bull.fr (8.9.2/8.9.1) with ESMTP id KAA39064; Fri, 28 Jul 2000 10:18:03 +0200
Message-ID: <[e-mail]>
Date: Fri, 28 Jul 2000 10:18:06 +0200
From: Denis Pinkas <[e-mail]>
Organization: Bull
X-Mailer: Mozilla 4.7 [fr] (Win98; I)
X-Accept-Language: fr
MIME-Version: 1.0
To: Stefan Santesson <[e-mail]>
CC: [e-mail]
Subject: Re: QC DN "qualities". Was: I-DACTION:draft-ietf-pkix-qc-04.txt
References: <[e-mail]> <001201bff55f$457cac80$[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Stefan,

> Denis,
> 
> Let me first say that I'm glad that you liked the change in QC-05 regarding DN.

:-)

> Many of the other issues you raise though are things that has been
> discussed in detail and where consensus has been reached in accordance with
> the current wording.
> 
> I hope you agree that it is generally would to change a reached consensus
> decision just based on a single "late" comment from someone that didn't
> participate in the discussion when it took place. At least not unless the
> suggested change fix a serious problem that was not known at time of
> original discussion.
> 
> That is why I make much resistance here if I don't see that your requests
> means MAJOR improvements or fix SERIOUS and REAL problems.

I did observed your resistance. :-) However the issues raised are
SERIOUS and REAL.

> Generally I think that all your issues, except for the discussion of new
> extensions, could be discussed on the road between proposed to draft
> standard. There is no reason to uphold the RFC process over wordings that
> does not change the syntax of the standard.
> 
> I give more specific comments in line;
> 
> At 08:36 2000-07-26 +0200, you wrote:
> >Stefan,
> >
> > > May I draw your attention to the updated QC 05 where the uniqueness
> > > requirement stated in RFC 2459 (and son of) has been clarified to count for
> > > the whole lifetime of the CA.
> > >
> > > section 2.4 now states:
> > >     "The distinguished name MUST be unique for each subject
> > >     entity certified by the one CA as defined by the issuer name field,
> > >     during the whole life time of the CA."
> > >
> > > This is actually nothing new, rather a clarification of the existing
> > > technical concept of DNs.
> > > An compliant implementation can simply not be based on CA's using the same
> > > DN for several different entities. It is reasonable to assume that this is
> > > the intent behind the original X.501 definition of DNs.
> > >     "Distinguished name is originally defined in X.501 [X.501] as a
> > >      representation of a directory name, defined as a construct that
> > >      identifies a particular object from among the set of all objects."
> >
> >
> >This is fine with me and solves one of the seven issues I have
> >posted on July 13 th. So COMMENT 1 is now solved. I re-post the six
> >other comments, which up to now have not yet been answered:
> >
> >COMMENT 2
> >
> >Section 3.1.1. Issuer states:  "The issuer field SHALL identify the
> >organization responsible for issuing the certificate, and SHALL
> >include a registered name of the organization".
> >
> >The basic question is what is the meaning of a "registered" name.
> >Who should be the registration authority ? Do we have such an
> >authority for registered names in the IETF ? Is this authority
> >adequate for such a usage ? Instead of trying to answer the
> >question, it makes more sense to omit the second part of the
> >sentence which leads to the following sentence: "The issuer field
> >SHALL identify the organization responsible for issuing the
> >certificate".
> 
> I disagree.
> 
> The meaning is to avoid organizations from specifying other names than they
> have registered for the organization. I have practical experiences with
> this when name collisions occur caused by organizations using common
> abbreviations or shorter versions of their name.
> 
> Typically we would like to avoid names as e.g. "RSV"  and "DSP" unless
> these organizations have registered these names.
> What "registered" actually means is not important from a tecnical point of
> view. It is asumed that all organization names are "registered" according
> to local law.
> 
> We had a major discussion around this concluding in the current wording. I
> would like to keep it as it is.

I disagree as well. Should the organization be registered at the ICC
? At an ISO body like ANSI, AFNOR, DIN, BIS ? At a country specific
registration authority ? Anyway, this will NOT prevent name
collisions as you might think, since anyway the name is only
meaningful for the CA that issues the certificate.


> >COMMENT 3
> >
> >Section 3.1.1. Issuer states:  "The legal jurisdiction for the
> >issuing CA SHOULD be consistent with the issuer name.". However the
> >abstract says: "   The goal of this document is to define a general
> >syntax independent of local legal requirements." and also "It is
> >important to note that the profile does not define any legal
> >requirements for Qualified Certificates.". This is contradictory.
> 
> No I don't think that this is contradictory. The text above is putting
> requirements on the contet of the listed attributes which include the
> geographical attributes
> 
>          countryName;
>           stateOrProvinceName; and
>          localityName;
> 
> What we say is that the content of these attributes SHOULD be consistent
> with the legal jurisdiction. This means that it is not in line with this
> requirement to state Sweden as country if the CA is operating under French law.

The legal jurisdiction of what ? I think you mean the legal
jurisdiction where the CA is established. If this is the case, then
this depends from the country where the CA is established, hence the
reason to speak of the country where the CA is established and avoid
in a technical specification legal aspects, as indicated above.


> I think that this is a legitimate requirement of content and fullfilles the
> need you express below.
> 
> > >From the discussions that recently took place in Stockholm, the
> >agreement was to mandate the inclusion of the country where from the
> >CA is operating. In this way, by indirection, the country where the
> >CA is established may implement a supervision scheme, if required.
> >
> >The text should be modified to reflect this.
> 
> See above.
> 
> The text DOES reflect this by saying that the name should be consistent
> with the legal jurisdiction.
> 
> >It should be noticed
> >that taking this into consideration, the first element of a DN for
> >an issuer must then be a country name. This should be reflected in
> >the text.
> 
> No. There are organizations that does not sort under a country. This
> standard is not only there for European CA operators.
> 
> This has been discussed, consensus has been reached and the issue closed.
> 
> >Full text proposal replacement for 3.1.1:
> >
> >3.1.1  Issuer
> >
> >The issuer field SHALL identify the organization responsible for
> >issuing the certificate.
> >
> >The identity of the issuer SHALL be specified using an appropriate
> >subset of the following attributes:
> >
> >          domainComponent;
> >          countryName;
> >          stateOrProvinceName;
> >          organizationName;
> >          localityName; and
> >          serialNumber.
> >
> >Additional attributes MAY be present but they SHOULD NOT be
> >necessary to identify the issuing organization. The first element of
> >the DN shall be the country where the CA is operating from.
> 
> Disagree according to reasons above.

The same for me.

> >COMMENT 4
> >
> >The text is not consistent when talking about certificate policies
> >and public statements.
> >
> >In section 2.2. Statement of Purpose, the text says:
> >
> >"For a certificate to serve the purpose of being a Qualified
> >Certificate, this profile assumes that the CA will have to include
> >in the certificate a public statement that explicitly defines this
> >intent."
> 
> Clarification: This says nothing about what method to use and this is
> further just part of the "scope section"
> 
> This is a EU directive requirement. So I see nothing wrong with it.
> 
> >In section 3.2.2.Certificate Policies, the text says:
> >
> >" A statement by the issuer stating the purpose of the certificate
> >as discussed in Section 2.2 SHOULD be evident through indicated
> >policies."
> 
> This means that the policy should indicate that the certificate is a QC.
> I.e. regardless of any QCStatamenet extension information.
> 
> >The later statement is not that "evident" at all, in particular
> >since from section 2.2. any certificate policy may be used, provided
> >that it is consistent with the policy for a QC.
> >
> >The basic question is the following: How is it possible to know that
> >a certificate is a QC ?
> 
> By
> 
> 1) Recognizing the policy OID and understanding that this is a QC; and/or
> 2) Recognizing a statement included in the QCStatement extension (if present).
> 
> >There are two possible answers:
> >
> >a) use a QC statement to tell it (and this "costs" a new extension),
> >
> >b) use some pre-defined Certificate Policy OID to tell it (and this
> >costs no new extension).
> >
> >The text from section 2.2. mandates the inclusion of a QC statement.
> 
> Absolutely not:
> 1) Section 2.2 is just a scope section. It does not mandate anything
> 2) The wording in 2.2. says "assumes"
> 3) Section 3.2.2 makes it clear that such statement can be evident from a
> policy OID
> 
> >However, all current software is able to test for the presence of
> >any Certificate Policy OID in a certificate and thus the current
> >software could easily check for the presence of pre-defined
> >Certificate Policy OIDs for QCs. The QC statement mandates the use
> >of a new extension, that
> >no one has yet implemented, both for the construction of the
> >certificate and the checking of a certification path.
> >
> >Should we really mandate the presence of the QC statement (as being
> >the only way to indicate that a certificate is a QC) or should we
> >also allow the use of pre-defined Certificate Policy OID (making the
> >QC statement non mandatory) ?
> >
> >I think both options should be mentioned as possible
> 
> They are.

Fine. In that case we both agree in principle. :-)
 
However, what can be proven from that discussion is that the text is
ambiguous and thus needs to be clarified.

> Still there is a flaw in your logic with policy OID:s.
> IETF will never issue such a policy, and I doubt that ETSI will.

You should take a look at a draft document from ETSI called : Policy
Requirements for Certification Service Providers Issuing Qualified
Certificates ETSI STF 155 T1 Draft H 15th July 2000.

In that document on page 8, section 5.2 the text says:

" 5.2 Identification

The identifiers for the Qualified Certificate Policies specified in
the current document are:

a) QCP Public: A Certificate Policy for Qualified Certificates
issued to the public, Editorial note: Object identifier to be added.

c) QCP Public + SSCD: A Certificate Policy for Qualified
Certificates issued to the public, requiring use of secure
signature creation devices. Editorial note: Object identifier to be
added."

So it is apparent that two OIDs from the ETSI arc will be defined,
since this is an ETSI document.

> Still, there is nothing that prevents it from being defined but it's use
> may not be as efficient and general as you think.
> 
> >Note: I must recognise that the following text belonging to section
> >3.2.2 is not understandable to me:
> >
> >" In order to enhance path validation based on policy object
> >identifiers any statement related to  Qualified Certificates, as
> >defined in 3.2.5, SHOULD also be defined by included certificate
> >policies."
> 
> This means that you should not include policy statement in the QCStatements
> ext. that are not also defined by present policies.

I still do not understand. Are you thinking of a possible coliision
with PolicyQualifier (that are not used, but would have been the
"natural place" for making extension to policies). This sentence
either needs clarification or should be deleted. 

> Also note that this is a SHOULD requirement.
> 
> The reason is that any relying party that doesn't care about QCStatement
> extensions should be fully informed by the policy. 

You cannot say that anymore. In version QC-05, the text now says
that the Qualified Certificate Statements extension may be critical
or non-critical. When it is, then the application MUST understand
it.

> This is the fundamentals
> of handling policies in path validation, i.e. that each policy OID
> identifies a complete set of policy requirements.
> 
> >COMMENT 5
> >
> >Section 3.2.5. Qualified Certificate Statements, defines an
> >extension for inclusion of defined statements related to Qualified
> >Certificates. However, there is a major problem with the way the
> >extension is built. It is constructed as:
> >
> >  QCStatements ::= SEQUENCE OF QCStatement
> >
> >Since nothing is said in the text about the criticality this
> >extension is, by implication, non critical. This means that any
> >individual  QCStatement is not mandatory to understand. So unless an
> >application specifically looks for some pre-defined statement, it
> >will miss the others and is not required to "understand them. Also
> >remember that only ONE such extension may be present.
> >
> >In a profile of this document (not a PKIX document) this extension
> >is being used to specify the maximum amount of money which is
> >permissible for one transaction, this is what is referred in QC-04
> >as "a maximum reliance limit for the certificate indicating
> >restrictions on CA's liability".
> >
> >The basic question is whether we should have a separate extension
> >for a maximum reliance from a CA.
> >
> >If the maximum reliance limit statement is part of the new
> >extension, there is no guarantee that it will ever be seen or
> >recognized. In principle any QCStatement in a non critical extension
> >may be ignored by the application.
> >
> >If the maximum reliance limit statement is in a separate extension
> >marked critical, no application could miss it, if it is present.
> >
> >The requirement comes from an annex of the European Directive. The
> >definition of a maximum reliance limit is optional and it makes
> >sense to have a dedicated extension to support it.
> >
> >I would thus propose to suppress the following sentence from 3.2.5:
> >"As an example this MAY include a maximum reliance limit for the
> >certificate indicating restrictions on CA's liability."
> >
> >Instead I would propose to define a separate extension to support a
> >maximum reliance limit.
> 
> I completely disagree.
> 
> The QCStatement extension works just like the policy extension.

Why didn't you use PolicyQualifier ?

> It includes
> OID:s defining the statement (compare with an OID that define a policy).
> This OID can further be combined with some qualifying data.
> 
> The criticality bit does not give what you want anyway. It does only make
> sure that the relying party RECOGNIZE the extension. It doesn't even
> guarantee that the relying party recognize any of the information stored in
> the extension.

I do not share your interpretation of the sentence which is in RFC
2459, i.e. "A certificate using system MUST reject the certificate
if it encounters a critical extension it does not recognize; "

For me it clearly means that the RP must understand the semantics of
the extension.

> The criticality bit, when set, makes sure that the relying party knows what
> type of information he ignores, if he choose to ignore it.
> If we would follow your logic then there would also be a "problem" with
> many other extensions, e.g. key usage. What if some key usage information
> is regarded as critical and other as informational? 

This is not the case. The key usage extension, when present is
critical.

> Should we then have
> different extensions for different key usages? I doubt it.
> 
> I don't think that we should litter the standard with yet another
> extension. The QC Statements ext works just fine.
> 
> There was also a big discussion in ETSI on this. Everybody in the ETSI
> discussion (except you) agreed to go forward with the current solution.
> 
> >COMMENT 6
> >
> >Section 4, Security considerations. This section has major problems.
> >It uses some arguments to provide wrong conclusions. The current
> >text is as follows:
> >
> >" Since the public keys are for public use with legal implications
> >for involved parties, certain conditions should exist before CAs
> >issues certificates as Qualified Certificates. The associated
> >private keys must be unique for the subject, and must be maintained
> >under the subject's sole control.  That is, a CA should not issue a
> >qualified certificate if the private key is shared among entities,
> >or the means to use the private key is not protected against
> >unintended usage. This implies that the CA must perform
> >proof-of-possession of the private key. In addition, it implies that
> >the CA have some knowledge about the subject's cryptographic
> >module."
> >
> >The text says that a "CA should not issue a qualified certificate if
> >the private key is shared among entities". This is fine, but the CA
> >has no way to know whether the private key has been given to someone
> >else. Proof-of-possession of the private key does not solve the
> >issue as well, since everyone who has been given the private key
> >could provide proof-of-possession.
> >
> >What is transparent from the text, but not said correctly, is that
> >if a physical device is used, then it becomes "more difficult" to
> >share the private key. Proposed text full replacement for the text
> >above:
> >
> >"The private keys must be maintained under the subject's sole
> >control.  That is, a CA should not issue a qualified certificate if
> >the means to use the private key is not protected against unintended
> >usage. It implies that the CA should have some knowledge about the
> >subject's cryptographic module."

You forgot to answer to that text replacement proposal.

> >It should be realized also that proof-of-possession is NOT needed at
> >all what using good cryptography practice. As soon as the identifier
> >of the certificate being used is protected by the digital signature,
> >then proof-of-possession becomes unnecessary. Why not say it ?
> 
> Well. POP must be performed and what I read in your wordings, you agree to
> that. It seams that you are locked on the idea that POP requires a separate
> protocol and to me that's NOT the case. A signed request, signed with the
> subject private key, also provides POP.

I think you missed the point. I am not arguing whether a separate
protocol is necessary or not, I say that POP *towards a CA* is
unecessary for keys that have the NR bit set, as soon as "a good
usage of cryptography" is being used at the time the private key is
being used.
 
> >COMMENT 7
> >
> >Section 4, Security considerations. The current text is as follows:
> >
> >"Comparing two qualified certificates to determine if they represent
> >the same physical entity may provide misleading results and should
> >be performed with care."
> >
> >This sentence does not help. Replace by:
> >
> >"Comparing two qualified certificates, that contain different DNs,
> >to determine if they represent the same physical entity cannot be
> >made."
> 
> No you can't say that.
> 
> It may be very possible, in cases where the certificate context allows it.

How do you know the "context" ? 

> I.e. If you have a Swedish certificate with Swedish civic registration
> number. Then you can know that the DN represent the same person even if
> some other data is differing.

There is no specific rule that you can apply to a Swedish
certificate to bear a different semantics of *one* component of the
DN (ie. the Swedish civic registration number, which is the last
component of the name). The same rules apply to all certificates,
hence there is no notion of "context".

Denis


> It's simply dependent on context. This is a security consideration section
> with the purpose of informing implementers of possible security problems
> that they should be aware of in order to avoid them.
> 
> I think that in that context the current existing wording is better.
> 
> /Stefan
> 
> >Denis
> >
> > > We are not talking about unintentional mistakes here (which always can
> > > happen) but the concept of operation.
> > >
> > > /Stefan


Received: from unimur.um.es (unimur.um.es [155.54.1.1]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id AAA22082 for <[e-mail]>; Fri, 28 Jul 2000 00:37:03 -0700 (PDT)
Received: from aries.dif.um.es (aries.dif.um.es [155.54.210.253]) by unimur.um.es (8.9.1b+Sun/8.9.1) with ESMTP id JAA22786 for <[e-mail]>; Fri, 28 Jul 2000 09:40:17 +0200 (MET DST)
Received: from dif.um.es (pirania.dif.um.es [155.54.210.33]) by aries.dif.um.es (Postfix) with ESMTP id F1EC6EC1A for <[e-mail]>; Fri, 28 Jul 2000 09:39:48 +0200 (MET DST)
Sender: [e-mail]
Message-ID: <[e-mail]>
Date: Fri, 28 Jul 2000 09:41:04 +0200
From: Gabriel Lopez Millan <[e-mail]>
X-Mailer: Mozilla 4.72 [es] (X11; U; Linux 2.2.14-5.0 i686)
X-Accept-Language: en
MIME-Version: 1.0
To: [e-mail]
Subject: policy representation
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

    Hi all. Where can I get information about policy representation?
    There is any RFC?

    Thanks, Gabi.




Received: from popmail.inbox.se (popmail.inbox.se [193.12.72.102]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id UAA08786 for <[e-mail]>; Thu, 27 Jul 2000 20:58:17 -0700 (PDT)
Received: from santesson.accurata.se (sfr-qbu-pqm-vty8.as.wcom.net [216.192.55.8]) by popmail.inbox.se (8.9.3/8.9.3) with ESMTP id GAA25830; Fri, 28 Jul 2000 06:01:27 +0200
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Version 4.3.2
Date: Thu, 27 Jul 2000 22:03:10 -0600
To: "Stefan Kelm" <[e-mail]>
From: Stefan Santesson <[e-mail]>
Subject: Re: QC DN "qualities". Was: I-DACTION:draft-ietf-pkix-qc-04.txt
Cc: [e-mail]
In-Reply-To: <[e-mail]>
References: <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed

At 17:34 2000-07-26 +0200, you wrote:
>Denis,
>
> > Should we really mandate the presence of the QC statement (as being
> > the only way to indicate that a certificate is a QC) or should we
> > also allow the use of pre-defined Certificate Policy OID (making the
> > QC statement non mandatory) ?
> >
> > I think both options should be mentioned as possible
>
>I wholeheartedly agree with you. The QCStatement, as useful as
>it might be, should not be mandatory.
>

So do I

But this is no issue since this already is optional in the current profile.

/Stefan


>Cheers,
>
>         Stefan.
>
>
>--------------------------------------------------------
>PKI-Symposium, 10.-11.Oktober 2000, www.pki-symposium.de
>--------------------------------------------------------
>Dipl.-Inform. Stefan Kelm
>Security Consultant
>
>Secorvo Security Consulting GmbH
>Albert-Nestler-Strasse 9, D-76131 Karlsruhe
>
>Tel. [phone], Fax [phone]
>E-Mail [e-mail], http://www.secorvo.de
>-------------------------------------------------------
>PGP Fingerprint 87AE E858 CCBC C3A2 E633 D139 B0D9 212B



Received: from po1.bbn.com (PO1.BBN.COM [192.1.50.38]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id NAA11561 for <[e-mail]>; Thu, 27 Jul 2000 13:11:08 -0700 (PDT)
Received: from [171.78.30.107] (fixed030-107.bbn.com [171.78.30.107] (may be forged)) by po1.bbn.com (8.9.1/8.9.1) with ESMTP id QAA27392; Thu, 27 Jul 2000 16:14:17 -0400 (EDT)
Mime-Version: 1.0
X-Sender: [e-mail]
Message-Id: <v0422080cb5a646102b19@[171.78.30.107]>
In-Reply-To: <3.0.5.32.20000727114042.00a8b8a0@localhost>
References: <3.0.5.32.20000726164011.04531100@localhost> <3.0.5.32.20000726164011.04531100@localhost> <3.0.5.32.20000727114042.00a8b8a0@localhost>
Date: Thu, 27 Jul 2000 16:12:34 -0400
To: Juergen Brauckmann <[e-mail]>
From: Stephen Kent <[e-mail]>
Subject: RE: OCSP request
Cc: [e-mail]
Content-Type: text/plain; charset="us-ascii" ; format="flowed"

At 11:40 AM +0200 7/27/00, Juergen Brauckmann wrote:
>At 16:52 26.07.00 +0200, Michael Fritscher wrote:
>  >The problem in this context is not so much to be able to rely upon the
>  >OCSP response, but rather that you may have a relyable OCSP response on a
>  >certificate that can have been "easily faked" in the meantime...
>
>And therefore you need trusted, reliable directory services that can
>confirm the existence of a certificate, e.g., OCSP with extensions, and
>that can give the user a chance to validate that the certificate the
>directory service is talking about is the certificate he has (this can be
>done by letting the OCSP responder send a hash of the cert in the response).

Whenever I hear someone talk about needing to trust directory 
services, I worry. We generally do not want to rely strongly on 
directories, because on can imagine many ways in which directory 
security could be compromised.  The distributed, replicated nature of 
directories increases the potential for compromise of (unsigned) data 
stored there.

Even the model that calls for a certificate to be time stamped as 
part of being stored in a directory entry is questionable, in my 
mind.  The fundamental notion is that a second, presumably 
independent signature has been applied to a cert when stored in this 
fashion.  The independence part of this is a good notion, but it 
might also be achieved by a CA that uses dual, independent crypto 
devices to sign certs in the first place.  Thus the insistence on 
this specific means of ensuring dual signature controls seems unduly 
implementation-specific and seems to ignore other, equivalently good 
means of effecting the same sort of security.

Steve



Received: from ext-mail.valicert.com (ns1.valicert.com [63.65.221.10]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id MAA09517 for <[e-mail]>; Thu, 27 Jul 2000 12:23:23 -0700 (PDT)
Received: from CONVERSION-DAEMON.ext-mail.valicert.com by ext-mail.valicert.com (PMDF V6.0-24 #46243) id <[e-mail]> for [e-mail]; Thu, 27 Jul 2000 12:23:31 -0700 (PDT)
Received: from seine.valicert.com ([192.168.2.23]) by ext-mail.valicert.com (PMDF V6.0-24 #46243) with ESMTP id <[e-mail]>; Thu, 27 Jul 2000 12:22:08 -0700 (PDT)
Received: by seine.valicert.com with Internet Mail Service (5.5.2650.21) id <36007H5W>; Thu, 27 Jul 2000 07:44:28 -0700
Content-return: allowed
Date: Thu, 27 Jul 2000 07:44:26 -0700
From: Ambarish Malpani <[e-mail]>
Subject: RE: OCSP request
To: "'Juergen Brauckmann'" <[e-mail]>
Cc: [e-mail]
Message-id: <[e-mail]>
MIME-version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-type: text/plain; charset=iso-8859-1
Content-transfer-encoding: 8BIT

Hi Juergen,
    Originally, OCSP had the following states (I do this from
memory, so I might be a little off):

- good
- revoked
- expired
- notIssued
- unknown (maybe)

The problem with having this set of return states, is you then
need to ask: does "revoked" also mean not-expired, but issued?
What does "issued" say about the revocation status? Does "good" imply
that is was issued? What if the responder doesn't know about that?

This topic was discussed in gory detail, and I had suggested one
of two approaches:
1. The current way of doing things
2. Have 3 orthogonal statuses in the response, referring to
the revocation, expiration and issuance status of the cert.

While proposing the second question, I had also asked why it was
important to figure out the expiration/issuance status in OCSP -
couldn't the client figure this out on their own. Pretty much all
the people agreed that they could and that is why we went with
solution #1.

Yes, as far as I can see, your certHash mechanism will work.
However, I still don't see exactly what problem you are solving
with it. Are you trying to take care of the issue of CA key
compromise/misuse? That was not the problem we were trying to
solve with OCSP. If the CA key is compromised, I could also issue
a OCSP-signing certificate to a fake OCSP responder controlled by
me and then issue incorrect responses to my heart's content.
Couldn't I?

It is really important that you specify very, very clearly what
problem you are trying to solve and the kind of scenario you
are operating in (direct trust of the responder, CA delegated trust,
...). Then, a better analysis of your proposed solution is
possible.

Hope this helps,
Regards,
Ambarish

P.S. What is the status of the ISIS solution? Is it already a
"rule/law"? Is it open to review/comments/suggestions?

A

---------------------------------------------------------------------
Ambarish Malpani
Architect                                                650.567.5457
ValiCert, Inc.                                  [e-mail]
339 N. Bernardo Ave.                          http://www.valicert.com
Mountain View, CA 94043


> -----Original Message-----
> From: Juergen Brauckmann [mailto:[e-mail]]
> Sent: Thursday, July 27, 2000 2:34 AM
> To: Ambarish Malpani
> Cc: [e-mail]
> Subject: RE: OCSP request
> 
> 
> Hello Ambarish.
> 
> At 07:10 26.07.00 -0700, Ambarish Malpani wrote:
> >1. OCSP responses are not meant to be weak at all. The meaning of
> >good is "not revoked" or "still good" (as long as the certificate
> >was correctly issued and hadn't expired before the ArchiveCutoff
> >date).
> 
> From RFC 2560:
>    The "good" state indicates a positive response to the 
> status inquiry.
>    At a minimum, this positive response indicates that the certificate
>    is not revoked, but does not necessarily mean that the certificate
>    was ever issued
> 
> By saying that OCSP responses are "weak" I had the last 
> sentence in mind.
> An OCSP responder can give me a "good" even if the CA did not 
> issue the
> certificate. Minimum-RFC2560-OCSP-responses with "Good" don't tell me
> whether the certificate ever existed.
> 
> "Weak" is probably a bad word for it. 
> 
> >The problem you might run into,
> >is say, somebody builds an ISIS OCSP server and somebody else
> >tries to use it with say a Netscape Communicator OCSP client. The
> >two products will claim to talk OCSP, but will actually be saying
> >different things in their requests and responses and nobody else
> >will ever know.
> 
> Yes, I see. 
> 
> One question (mainly an attempt to try to understand rfc 
> 2560): Why didn't
> you include specifications for the issuance questions into rfc 2560?
> Obviously you were aware of the problem because the 
> description of "good"
> says that such information may be delivered by extensions. 
> And why isn't
> there a fourth state "noSuchCert" besides good,revoked,unknown? I
> understand that it was the intention to be able to build 
> CRL-based OCSP
> Responders, but I don't see why it should have been 
> impossible to combine
> the two things.
> 
> >b. The reason why the change ISIS has proposed is "wrong" is:
> >In an OCSP request, you identify a cert by the hash of the CA's
> >public key [and the hash of the CA's name] and the certificate
> >serial number. If somebody had compromised the CA's public key,
> >all they would need to do, is create a new certificate with a
> >serial number that corresponds to a legitimate serial number, but
> >a different subject public key and there goes the ability of the
> >OCSP responder to tell you anything useful.
> 
> Yes. Therefore the OCSP Response should contain a hash of the 
> certificate
> in an extension, see my mail
> from yesterday "good in OCSP Responses. Was: Re: OCSP 
> request". This is the
> ISIS certHash extensions Simon is refering to in his mail 
> from 10:28 today.
> 
> >Part of why it is valuable to at least pose desires to change the
> >interpretations of RFCs on this kind of a list, is you might
> >actually get some useful input from others, who might think about
> >a problem in different ways.
> >
> >Does that make sense?
> 
> Well one problem is that it's difficult to see what the 
> interpretation of
> RFC2560 is that the authors had in mind... .
> 
> >P.S. Again, if you do pose the problems you want to solve, there
> >might be other reasonable ways of extending OCSP [within the
> >framework of the protocol], that might better fit in with the RFC
> >itself.
> 
> We try that, see the certHash extension... .
> 
> Regards,
>   Juergen
> -- 
> Juergen Brauckmann             Tel.:  +49 (0)40 / 80 80 26-3 11
> TC TrustCenter GmbH            Fax.:  +49 (0)40 / 80 80 26-1 26
> Sonninstraße 24-28   	    mailto:[e-mail]
> D-20097 Hamburg 		    http://www.trustcenter.de	
> 


Received: from ext-mail.valicert.com (ns1.valicert.com [63.65.221.10]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id MAA09519 for <[e-mail]>; Thu, 27 Jul 2000 12:23:23 -0700 (PDT)
Received: from CONVERSION-DAEMON.ext-mail.valicert.com by ext-mail.valicert.com (PMDF V6.0-24 #46243) id <[e-mail]> for [e-mail]; Thu, 27 Jul 2000 12:24:11 -0700 (PDT)
Received: from seine.valicert.com ([192.168.2.23]) by ext-mail.valicert.com (PMDF V6.0-24 #46243) with ESMTP id <[e-mail]>; Thu, 27 Jul 2000 12:22:47 -0700 (PDT)
Received: by seine.valicert.com with Internet Mail Service (5.5.2650.21) id <PY1WTWMD>; Thu, 27 Jul 2000 11:09:18 -0700
Content-return: allowed
Date: Thu, 27 Jul 2000 11:09:16 -0700
From: Frank Balluffi <[e-mail]>
Subject: RE: OCSP request
To: "'[e-mail]'" <[e-mail]>, Denis Pinkas <[e-mail]>
Cc: Juergen Brauckmann <[e-mail]>, [e-mail]
Message-id: <[e-mail]>
MIME-version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-type: text/plain; charset=iso-8859-1

Tom Ginden wrote:

> This is wrong. A chain of time stamps protects against key
> compromise, as well as weak algorithms, as long as the 
> timestamps have been
> applied before the key has been compromised or the algorithm 
> has been found
> weak. So there is no need to ask the CA.

I agree. It may be desirable to include OCSP responses in the data to be
timestamped. For example, a construct like a CMS/PKCS #7 SignedData that
includes OCSP responses might be very useful.

Frank


Received: from e1.ny.us.ibm.com (e1.ny.us.ibm.com [32.97.182.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id KAA06067 for <[e-mail]>; Thu, 27 Jul 2000 10:04:25 -0700 (PDT)
From: [e-mail]
Received: from northrelay02.pok.ibm.com (northrelay02.pok.ibm.com [9.117.200.22]) by e1.ny.us.ibm.com (8.9.3/8.9.3) with ESMTP id NAA135274; Thu, 27 Jul 2000 13:07:34 -0400
Received: from D51MTA04.pok.ibm.com (d51mta04.pok.ibm.com [9.117.200.32]) by northrelay02.pok.ibm.com (8.8.8m3/NCO v4.92) with SMTP id NAA39618; Thu, 27 Jul 2000 13:07:34 -0400
Received: by D51MTA04.pok.ibm.com(Lotus SMTP MTA v4.6.5  (863.2 5-20-1999))  id 85256929.005E115A ; Thu, 27 Jul 2000 13:07:27 -0400
X-Lotus-FromDomain: IBMUS
To: Denis Pinkas <[e-mail]>
cc: Juergen Brauckmann <[e-mail]>, [e-mail]
Message-ID: <[e-mail]>
Date: Thu, 27 Jul 2000 13:07:18 -0400
Subject: Re: OCSP request
Mime-Version: 1.0
Content-type: text/plain; charset=us-ascii
Content-Disposition: inline

     One slight clarification about TS chains below :-)

(snip)
> It is also not sufficient for long term
> validation of signatures, where you might have, e.g., a signature and a
> certificate with an expired crypto algorithm, and a chain of timestamps
> with valid algorithms, and where you want to verify the state of the
> certificate that made the signature. In this situation you cannot rely on
> the certificate itself as an evidence that a CA ever issued it, you must
> ask the CA.

This is wrong. A chain of time stamps protects against key
compromise, as well as weak algorithms, as long as the timestamps have been
applied before the key has been compromised or the algorithm has been found
weak. So there is no need to ask the CA.

[Tom Gindin] If I remember your presentation at IETF 46 correctly, the
actual claim is that a chain of time stamps protects against both key
compromise (of a time stamp) and weak algorithms as long as there was no
time T at which the most recently applied stamp (as of time T) had been
rendered questionable - whether by key compromise or by weak algorithm.
Key compromise or algorithm break only bring a chain into question if they
are claimed to have occurred before the next time stamp in the chain.





Received: from popmail.inbox.se (popmail.inbox.se [193.12.72.102]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id IAA26102 for <[e-mail]>; Thu, 27 Jul 2000 08:06:35 -0700 (PDT)
Received: from santesson.accurata.se (sfr-qbu-pqn-vty8.as.wcom.net [216.192.22.8]) by popmail.inbox.se (8.9.3/8.9.3) with ESMTP id RAA24016; Thu, 27 Jul 2000 17:09:29 +0200
Message-Id: <[e-mail]>
X-Sender: [e-mail] (Unverified)
X-Mailer: QUALCOMM Windows Eudora Version 4.3.2
Date: Thu, 27 Jul 2000 17:11:02 +0200
To: Denis Pinkas <[e-mail]>
From: Stefan Santesson <[e-mail]>
Subject: Re: QC DN "qualities". Was: I-DACTION:draft-ietf-pkix-qc-04.txt
Cc: [e-mail]
In-Reply-To: <[e-mail]>
References: <[e-mail]> <001201bff55f$457cac80$[e-mail]> <[e-mail]> <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed

Denis,

Let me first say that I'm glad that you liked the change in QC-05 regarding DN.

Many of the other issues you raise though are things that has been 
discussed in detail and where consensus has been reached in accordance with 
the current wording.

I hope you agree that it is generally would to change a reached consensus 
decision just based on a single "late" comment from someone that didn't 
participate in the discussion when it took place. At least not unless the 
suggested change fix a serious problem that was not known at time of 
original discussion.

That is why I make much resistance here if I don't see that your requests 
means MAJOR improvements or fix SERIOUS and REAL problems.

Generally I think that all your issues, except for the discussion of new 
extensions, could be discussed on the road between proposed to draft 
standard. There is no reason to uphold the RFC process over wordings that 
does not change the syntax of the standard.

I give more specific comments in line;

At 08:36 2000-07-26 +0200, you wrote:
>Stefan,
>
> > May I draw your attention to the updated QC 05 where the uniqueness
> > requirement stated in RFC 2459 (and son of) has been clarified to count for
> > the whole lifetime of the CA.
> >
> > section 2.4 now states:
> >     "The distinguished name MUST be unique for each subject
> >     entity certified by the one CA as defined by the issuer name field,
> >     during the whole life time of the CA."
> >
> > This is actually nothing new, rather a clarification of the existing
> > technical concept of DNs.
> > An compliant implementation can simply not be based on CA's using the same
> > DN for several different entities. It is reasonable to assume that this is
> > the intent behind the original X.501 definition of DNs.
> >     "Distinguished name is originally defined in X.501 [X.501] as a
> >      representation of a directory name, defined as a construct that
> >      identifies a particular object from among the set of all objects."
>
>
>This is fine with me and solves one of the seven issues I have
>posted on July 13 th. So COMMENT 1 is now solved. I re-post the six
>other comments, which up to now have not yet been answered:
>
>COMMENT 2
>
>Section 3.1.1. Issuer states:  "The issuer field SHALL identify the
>organization responsible for issuing the certificate, and SHALL
>include a registered name of the organization".
>
>The basic question is what is the meaning of a "registered" name.
>Who should be the registration authority ? Do we have such an
>authority for registered names in the IETF ? Is this authority
>adequate for such a usage ? Instead of trying to answer the
>question, it makes more sense to omit the second part of the
>sentence which leads to the following sentence: "The issuer field
>SHALL identify the organization responsible for issuing the
>certificate".

I disagree.

The meaning is to avoid organizations from specifying other names than they 
have registered for the organization. I have practical experiences with 
this when name collisions occur caused by organizations using common 
abbreviations or shorter versions of their name.

Typically we would like to avoid names as e.g. "RSV"  and "DSP" unless 
these organizations have registered these names.
What "registered" actually means is not important from a tecnical point of 
view. It is asumed that all organization names are "registered" according 
to local law.

We had a major discussion around this concluding in the current wording. I 
would like to keep it as it is.


>COMMENT 3
>
>Section 3.1.1. Issuer states:  "The legal jurisdiction for the
>issuing CA SHOULD be consistent with the issuer name.". However the
>abstract says: "   The goal of this document is to define a general
>syntax independent of local legal requirements." and also "It is
>important to note that the profile does not define any legal
>requirements for Qualified Certificates.". This is contradictory.

No I don't think that this is contradictory. The text above is putting 
requirements on the contet of the listed attributes which include the 
geographical attributes

         countryName;
          stateOrProvinceName; and
         localityName;

What we say is that the content of these attributes SHOULD be consistent 
with the legal jurisdiction. This means that it is not in line with this 
requirement to state Sweden as country if the CA is operating under French law.

I think that this is a legitimate requirement of content and fullfilles the 
need you express below.

> >From the discussions that recently took place in Stockholm, the
>agreement was to mandate the inclusion of the country where from the
>CA is operating. In this way, by indirection, the country where the
>CA is established may implement a supervision scheme, if required.
>
>The text should be modified to reflect this.

See above.

The text DOES reflect this by saying that the name should be consistent 
with the legal jurisdiction.


>It should be noticed
>that taking this into consideration, the first element of a DN for
>an issuer must then be a country name. This should be reflected in
>the text.

No. There are organizations that does not sort under a country. This 
standard is not only there for European CA operators.

This has been discussed, consensus has been reached and the issue closed.


>Full text proposal replacement for 3.1.1:
>
>3.1.1  Issuer
>
>The issuer field SHALL identify the organization responsible for
>issuing the certificate.
>
>The identity of the issuer SHALL be specified using an appropriate
>subset of the following attributes:
>
>          domainComponent;
>          countryName;
>          stateOrProvinceName;
>          organizationName;
>          localityName; and
>          serialNumber.
>
>Additional attributes MAY be present but they SHOULD NOT be
>necessary to identify the issuing organization. The first element of
>the DN shall be the country where the CA is operating from.

Disagree according to reasons above.


>COMMENT 4
>
>The text is not consistent when talking about certificate policies
>and public statements.
>
>In section 2.2. Statement of Purpose, the text says:
>
>"For a certificate to serve the purpose of being a Qualified
>Certificate, this profile assumes that the CA will have to include
>in the certificate a public statement that explicitly defines this
>intent."

Clarification: This says nothing about what method to use and this is 
further just part of the "scope section"

This is a EU directive requirement. So I see nothing wrong with it.


>In section 3.2.2.Certificate Policies, the text says:
>
>" A statement by the issuer stating the purpose of the certificate
>as discussed in Section 2.2 SHOULD be evident through indicated
>policies."

This means that the policy should indicate that the certificate is a QC. 
I.e. regardless of any QCStatamenet extension information.


>The later statement is not that "evident" at all, in particular
>since from section 2.2. any certificate policy may be used, provided
>that it is consistent with the policy for a QC.
>
>The basic question is the following: How is it possible to know that
>a certificate is a QC ?

By

1) Recognizing the policy OID and understanding that this is a QC; and/or
2) Recognizing a statement included in the QCStatement extension (if present).



>There are two possible answers:
>
>a) use a QC statement to tell it (and this "costs" a new extension),
>
>b) use some pre-defined Certificate Policy OID to tell it (and this
>costs no new extension).
>
>The text from section 2.2. mandates the inclusion of a QC statement.

Absolutely not:
1) Section 2.2 is just a scope section. It does not mandate anything
2) The wording in 2.2. says "assumes"
3) Section 3.2.2 makes it clear that such statement can be evident from a 
policy OID


>However, all current software is able to test for the presence of
>any Certificate Policy OID in a certificate and thus the current
>software could easily check for the presence of pre-defined
>Certificate Policy OIDs for QCs. The QC statement mandates the use
>of a new extension, that
>no one has yet implemented, both for the construction of the
>certificate and the checking of a certification path.
>
>Should we really mandate the presence of the QC statement (as being
>the only way to indicate that a certificate is a QC) or should we
>also allow the use of pre-defined Certificate Policy OID (making the
>QC statement non mandatory) ?
>
>I think both options should be mentioned as possible

They are.

Still there is a flaw in your logic with policy OID:s.
IETF will never issue such a policy, and I doubt that ETSI will.
Still, there is nothing that prevents it from being defined but it's use 
may not be as efficient and general as you think.


>Note: I must recognise that the following text belonging to section
>3.2.2 is not understandable to me:
>
>" In order to enhance path validation based on policy object
>identifiers any statement related to  Qualified Certificates, as
>defined in 3.2.5, SHOULD also be defined by included certificate
>policies."


This means that you should not include policy statement in the QCStatements 
ext. that are not also defined by present policies.

Also note that this is a SHOULD requirement.

The reason is that any relying party that doesn't care about QCStatement 
extensions should be fully informed by the policy. This is the fundamentals 
of handling policies in path validation, i.e. that each policy OID 
identifies a complete set of policy requirements.


>COMMENT 5
>
>Section 3.2.5. Qualified Certificate Statements, defines an
>extension for inclusion of defined statements related to Qualified
>Certificates. However, there is a major problem with the way the
>extension is built. It is constructed as:
>
>  QCStatements ::= SEQUENCE OF QCStatement
>
>Since nothing is said in the text about the criticality this
>extension is, by implication, non critical. This means that any
>individual  QCStatement is not mandatory to understand. So unless an
>application specifically looks for some pre-defined statement, it
>will miss the others and is not required to "understand them. Also
>remember that only ONE such extension may be present.
>
>In a profile of this document (not a PKIX document) this extension
>is being used to specify the maximum amount of money which is
>permissible for one transaction, this is what is referred in QC-04
>as "a maximum reliance limit for the certificate indicating
>restrictions on CA's liability".
>
>The basic question is whether we should have a separate extension
>for a maximum reliance from a CA.
>
>If the maximum reliance limit statement is part of the new
>extension, there is no guarantee that it will ever be seen or
>recognized. In principle any QCStatement in a non critical extension
>may be ignored by the application.
>
>If the maximum reliance limit statement is in a separate extension
>marked critical, no application could miss it, if it is present.
>
>The requirement comes from an annex of the European Directive. The
>definition of a maximum reliance limit is optional and it makes
>sense to have a dedicated extension to support it.
>
>I would thus propose to suppress the following sentence from 3.2.5:
>"As an example this MAY include a maximum reliance limit for the
>certificate indicating restrictions on CA's liability."
>
>Instead I would propose to define a separate extension to support a
>maximum reliance limit.

I completely disagree.

The QCStatement extension works just like the policy extension. It includes 
OID:s defining the statement (compare with an OID that define a policy). 
This OID can further be combined with some qualifying data.

The criticality bit does not give what you want anyway. It does only make 
sure that the relying party RECOGNIZE the extension. It doesn't even 
guarantee that the relying party recognize any of the information stored in 
the extension.

The criticality bit, when set, makes sure that the relying party knows what 
type of information he ignores, if he choose to ignore it.
If we would follow your logic then there would also be a "problem" with 
many other extensions, e.g. key usage. What if some key usage information 
is regarded as critical and other as informational? Should we then have 
different extensions for different key usages? I doubt it.

I don't think that we should litter the standard with yet another 
extension. The QC Statements ext works just fine.

There was also a big discussion in ETSI on this. Everybody in the ETSI 
discussion (except you) agreed to go forward with the current solution.


>COMMENT 6
>
>Section 4, Security considerations. This section has major problems.
>It uses some arguments to provide wrong conclusions. The current
>text is as follows:
>
>" Since the public keys are for public use with legal implications
>for involved parties, certain conditions should exist before CAs
>issues certificates as Qualified Certificates. The associated
>private keys must be unique for the subject, and must be maintained
>under the subject's sole control.  That is, a CA should not issue a
>qualified certificate if the private key is shared among entities,
>or the means to use the private key is not protected against
>unintended usage. This implies that the CA must perform
>proof-of-possession of the private key. In addition, it implies that
>the CA have some knowledge about the subject's cryptographic
>module."
>
>The text says that a "CA should not issue a qualified certificate if
>the private key is shared among entities". This is fine, but the CA
>has no way to know whether the private key has been given to someone
>else. Proof-of-possession of the private key does not solve the
>issue as well, since everyone who has been given the private key
>could provide proof-of-possession.
>
>What is transparent from the text, but not said correctly, is that
>if a physical device is used, then it becomes "more difficult" to
>share the private key. Proposed text full replacement for the text
>above:
>
>"The private keys must be maintained under the subject's sole
>control.  That is, a CA should not issue a qualified certificate if
>the means to use the private key is not protected against unintended
>usage. It implies that the CA should have some knowledge about the
>subject's cryptographic module."
>
>It should be realized also that proof-of-possession is NOT needed at
>all what using good cryptography practice. As soon as the identifier
>of the certificate being used is protected by the digital signature,
>then proof-of-possession becomes unnecessary. Why not say it ?

Well. POP must be performed and what I read in your wordings, you agree to 
that. It seams that you are locked on the idea that POP requires a separate 
protocol and to me that's NOT the case. A signed request, signed with the 
subject private key, also provides POP.


>COMMENT 7
>
>Section 4, Security considerations. The current text is as follows:
>
>"Comparing two qualified certificates to determine if they represent
>the same physical entity may provide misleading results and should
>be performed with care."
>
>This sentence does not help. Replace by:
>
>"Comparing two qualified certificates, that contain different DNs,
>to determine if they represent the same physical entity cannot be
>made."

No you can't say that.

It may be very possible, in cases where the certificate context allows it. 
I.e. If you have a Swedish certificate with Swedish civic registration 
number. Then you can know that the DN represent the same person even if 
some other data is differing.

It's simply dependent on context. This is a security consideration section 
with the purpose of informing implementers of possible security problems 
that they should be aware of in order to avoid them.

I think that in that context the current existing wording is better.

/Stefan


>Denis
>
> > We are not talking about unintentional mistakes here (which always can
> > happen) but the concept of operation.
> >
> > /Stefan




Received: from mystic1.trustcenter.de (mystic1.trustcenter.de [193.194.157.34]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id HAA25139 for <[e-mail]>; Thu, 27 Jul 2000 07:54:56 -0700 (PDT)
Received: by mystic1.trustcenter.de; id QAA09512; Thu, 27 Jul 2000 16:55:24 +0200
Received: from nodnsquery(192.168.200.3) by mystic1.trustcenter.de via smap (V5.0) id xma009506; Thu, 27 Jul 00 16:54:40 +0200
Received: from ew-jbr (titan.trustcenter.de [192.168.200.244]) by callisto.trustcenter.de (8.9.3/8.9.3) with SMTP id QAA21018; Thu, 27 Jul 2000 16:56:20 +0200 (MET DST)
Message-Id: <3.0.5.32.20000727165620.0376c5e0@localhost>
X-Sender: jbr@localhost
X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (32)
Date: Thu, 27 Jul 2000 16:56:20 +0200
To: Denis Pinkas <[e-mail]>
From: Juergen Brauckmann <[e-mail]>
Subject: Re: OCSP request
Cc: [e-mail]
In-Reply-To: <[e-mail]>
References: <3.0.5.32.20000726145755.03772bc0@localhost> <3.0.5.32.20000727140550.00a858f0@localhost>
Mime-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by ns.secondary.com id HAA25141

At 16:23 27.07.00 +0200, Denis Pinkas wrote:
>> The ISIS specification is for use with the German Signature Law. 
>
>I heard that the German Signature Law was in the process of being
>revised.

As far as I know the revision will have no impact on the interpretation of
the validity model by the RegTP.

>> The root
>> CA operated by the "Regulierungsbehoerde fuer Telekommunikation und Post"
>> <http://www.regtp.de/en> originally wanted to enforce a chain model, where
>To give a name to that "other model", should we call, for the time
>being, the "ISIS model" ?

Hm, regtp-model?

>No. Since, as you said, the reference to the certificate includes
>the hash of that certificate, this is not necessary to ask anything
>to the CA. 

Ups. You are right, sorry... .

Juergen
-- 
Juergen Brauckmann             Tel.:  +49 (0)40 / 80 80 26-3 11
TC TrustCenter GmbH            Fax.:  +49 (0)40 / 80 80 26-1 26
Sonninstraße 24-28   	    mailto:[e-mail]
D-20097 Hamburg 		    http://www.trustcenter.de	


Received: from odin2.bull.net (odin2.bull.net [192.90.70.84]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id HAA23421 for <[e-mail]>; Thu, 27 Jul 2000 07:21:45 -0700 (PDT)
Received: from lvt-mail.frlv.bull.fr (lvt-mail.frlv.bull.fr [129.184.62.223]) by odin2.bull.net (8.9.3/8.9.3) with ESMTP id QAA41838; Thu, 27 Jul 2000 16:28:32 +0200
Received: from bull.net (frpq6118.frpq.bull.fr [129.184.8.64]) by lvt-mail.frlv.bull.fr (8.9.2/8.9.1) with ESMTP id QAA05212; Thu, 27 Jul 2000 16:23:56 +0200
Message-ID: <[e-mail]>
Date: Thu, 27 Jul 2000 16:23:57 +0200
From: Denis Pinkas <[e-mail]>
Organization: Bull
X-Mailer: Mozilla 4.7 [fr] (Win98; I)
X-Accept-Language: fr
MIME-Version: 1.0
To: Juergen Brauckmann <[e-mail]>
CC: [e-mail]
Subject: Re: OCSP request
References: <3.0.5.32.20000726145755.03772bc0@localhost> <3.0.5.32.20000727140550.00a858f0@localhost>
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 8bit

Juergen,

> Hi Denis.
> 
> At 11:00 27.07.00 +0200, Denis Pinkas wrote:
> >> This means that a client *never* can get an authoritive answer that the
> >> certificate is faked (by the way of a CA key compromise) because a client
> >> has no way of knowing whether he talked to all OCSP Responders that may
> >> know something about the certificate.
> >
> >This is incorrect. You need to query an OCSP server you trust,
> >either directly (indicated by out-of-bands means), or because it is
> >indicated within the user certificate.
> 
> So a user must be sure that he configured his client software with all OCSP
> responders that a CA may have.
> 
> How is he informed if the CA adds another OCSP responder?
> 
> >This is pretty different from RF 2459.
> 
> The ISIS specification is for use with the German Signature Law. 

I heard that the German Signature Law was in the process of being
revised.

> The root
> CA operated by the "Regulierungsbehoerde fuer Telekommunikation und Post"
> <http://www.regtp.de/en> originally wanted to enforce a chain model, where
> a certificate may be valid at time T even if its CA certificate is revoked
> at T. They did this by revoking not any longer used CA certificates when
> they performed a regular certificate and key rollover. So all certificates
> under the old CA certificate were suddenly invalid with RFC2459
> verification procedures.
> 
> This means that there is some chance that we(=ISIS) must deal with
> non-RFC2459 validity models.

To give a name to that "other model", should we call, for the time
being, the "ISIS model" ?

> Most involved CAs are, eh, not *really* happy with this situation. The
> discussion with the RegTP is going on... .
> 
> >> It is also not sufficient for long term
> >> validation of signatures, where you might have, e.g., a signature and a
> >> certificate with an expired crypto algorithm, and a chain of timestamps
> >> with valid algorithms, and where you want to verify the state of the
> >> certificate that made the signature. In this situation you cannot rely on
> >> the certificate itself as an evidence that a CA ever issued it, you must
> >> ask the CA.
> >
> >This is wrong. A chain of time stamps protects against key
> >compromise,
> 
> You are right if the timestamp is made over the signature and the
> certificate. If the timestamp secures only the signature and a reference to
> the certificate (like issuerDN/serialnumber and hash), then the CA must be
> asked. OK, that's perhaps not too realistic... .

No. Since, as you said, the reference to the certificate includes
the hash of that certificate, this is not necessary to ask anything
to the CA. 

Denis
 
> Juergen
> --
> Juergen Brauckmann             Tel.:  +49 (0)40 / 80 80 26-3 11
> TC TrustCenter GmbH            Fax.:  +49 (0)40 / 80 80 26-1 26
> Sonninstraße 24-28          mailto:[e-mail]
> D-20097 Hamburg                     http://www.trustcenter.de


Received: from ns.celocom.se ([e-mail] [212.209.40.66]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id HAA22962 for <[e-mail]>; Thu, 27 Jul 2000 07:15:02 -0700 (PDT)
Received: by ns.celocom.se; id QAA13052; Thu, 27 Jul 2000 16:18:12 +0200 (CEST)
Received: from seexchange.celocom.se(10.10.10.11) by ns.celocom.se via smap (4.1) id xma010312; Thu, 27 Jul 00 15:31:37 +0200
Received: from celocom.se (levitte.celocom.se [10.10.10.124]) by seexchange.celocom.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21) id 3YLHHJHH; Thu, 27 Jul 2000 15:34:59 +0200
Sender: [e-mail]
Message-ID: <[e-mail]>
Date: Thu, 27 Jul 2000 15:31:12 +0200
From: Richard Levitte <[e-mail]>
Organization: Celo Communications, Ltd.
X-Mailer: Mozilla 4.74 [en] (X11; U; Linux 2.2.14-5.0 i686)
X-Accept-Language: en
MIME-Version: 1.0
To: Juergen Brauckmann <[e-mail]>
CC: Denis Pinkas <[e-mail]>, [e-mail]
Subject: Re: OCSP request
References: <3.0.5.32.20000726145755.03772bc0@localhost> <3.0.5.32.20000727140550.00a858f0@localhost>
Content-Type: multipart/mixed; boundary="------------78F69466A02B9F683A20A7BE"

This is a multi-part message in MIME format.
--------------78F69466A02B9F683A20A7BE
Content-Type: multipart/alternative;
 boundary="------------DFAA3542CBD93B647622E320"


--------------DFAA3542CBD93B647622E320
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Juergen Brauckmann wrote:

> >This is incorrect. You need to query an OCSP server you trust,
> >either directly (indicated by out-of-bands means), or because it is
> >indicated within the user certificate.
>
> So a user must be sure that he configured his client software with all OCSP
> responders that a CA may have.

Hmm, I think "or because it is indicated within the user certificate" might be
a key phrase here...  The other alternative is some kind of global trusted
responder that does the work for others.

> How is he informed if the CA adds another OCSP responder?

I think that a CA has to think carefully before they do that, by making sure
the new responder is reachable through already known names and transports.
This is not really a hard issue, it's just a question of using using other
technologies correctly and optimally, no?  Using DNS, The SRV RR could help a
lot here, for example.  Then again, perhaps I misunderstand what you mean...

In any case, if a CA doesn't make sure the new OCSP responder is reachable
through already known means, they either didn't want it to be reachable for
anything than possibly new certs with info about the new OCSP responder in an
AuthorityInfoAccess, or it has made a fool of itself.  Or some other
alternative I'm not thinking of...

--
Richard Levitte                 !!! New cell phone number !!!
[e-mail]

/* You might enjoy viewing the complete vCard */



--------------DFAA3542CBD93B647622E320
Content-Type: text/html; charset=us-ascii
Content-Transfer-Encoding: 7bit

<!doctype html public "-//w3c//dtd html 4.0 transitional//en">
<html>
Juergen Brauckmann wrote:
<blockquote TYPE=CITE>>This is incorrect. You need to query an OCSP server
you trust,
<br>>either directly (indicated by out-of-bands means), or because it is
<br>>indicated within the user certificate.
<p>So a user must be sure that he configured his client software with all
OCSP
<br>responders that a CA may have.</blockquote>
Hmm, I think "or because it is indicated within the user certificate" might
be a key phrase here...&nbsp; The other alternative is some kind of global
trusted responder that does the work for others.
<blockquote TYPE=CITE>How is he informed if the CA adds another OCSP responder?</blockquote>
I think that a CA has to think carefully before they do that, by making
sure the new responder is reachable through already known names and transports.&nbsp;
This is not really a hard issue, it's just a question of using using other
technologies correctly and optimally, no?&nbsp; Using DNS, The SRV RR could
help a lot here, for example.&nbsp; Then again, perhaps I misunderstand
what you mean...
<p>In any case, if a CA doesn't make sure the new OCSP responder is reachable
through already known means, they either didn't want it to be reachable
for anything than possibly new certs with info about the new OCSP responder
in an AuthorityInfoAccess, or it has made a fool of itself.&nbsp; Or some
other alternative I'm not thinking of...
<pre>--&nbsp;
Richard Levitte&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; !!! New cell phone number !!!
[e-mail]

/* You might enjoy viewing the complete vCard */</pre>
&nbsp;</html>

--------------DFAA3542CBD93B647622E320--

--------------78F69466A02B9F683A20A7BE
Content-Type: text/x-vcard; charset=us-ascii;
 name="richard.levitte.vcf"
Content-Transfer-Encoding: 7bit
Content-Description: Card for Richard Levitte
Content-Disposition: attachment;
 filename="richard.levitte.vcf"

begin:vcard 
n:Levitte;Richard
tel;cell:[phone]
tel;work:[phone]
x-mozilla-html:FALSE
org:<A HREF="http://www.celocom.com">Celo Communications</A>
version:2.1
email;internet:[e-mail]
title:Software Artist
adr;quoted-printable:;;Sveav=E4gen 145, 5tr=0D=0AStockholm;;;;SWEDEN
note;quoted-printable:<br>=0D=0A<table border=3D0>=0D=0A<tr>=0D=0A  <td bgcolor=3D"#00ffff">c=EAlo, =E2vi, =E2tum, (latin) 1,v.a.=0D=0A      to hide something from one, to keep secret, to conceal.=0D=0A  </td>=0D=0A</tr>=0D=0A</table>=0D=0A<br>=0D=0A<table border=3D3>=0D=0A<tr>=0D=0A <td>=0D=0A  <table>=0D=0A  <tr>=0D=0A   <td valign=3Dtop>o/~</td>=0D=0A   <td><font size=3D-1>Coding, coding, coding</font><br>=0D=0A          Keep'em hackers coding<br>=0D=0A          <font size=3D+1>And When They're Done Coding</font><br>=0D=0A          <font size=3D7>COMPIIIIIIILE!!</font></td>=0D=0A  </tr>=0D=0A  </table>=0D=0A </td>=0D=0A</tr>=0D=0A</table>
fn:Richard Levitte
end:vcard

--------------78F69466A02B9F683A20A7BE--



Received: from odin2.bull.net (odin2.bull.net [192.90.70.84]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id GAA20320 for <[e-mail]>; Thu, 27 Jul 2000 06:21:48 -0700 (PDT)
Received: from lvt-mail.frlv.bull.fr (lvt-mail.frlv.bull.fr [129.184.62.223]) by odin2.bull.net (8.9.3/8.9.3) with ESMTP id PAA13038; Thu, 27 Jul 2000 15:28:55 +0200
Received: from bull.net (frpq6118.frpq.bull.fr [129.184.8.64]) by lvt-mail.frlv.bull.fr (8.9.2/8.9.1) with ESMTP id PAA40672; Thu, 27 Jul 2000 15:24:19 +0200
Message-ID: <[e-mail]>
Date: Thu, 27 Jul 2000 15:24:21 +0200
From: Denis Pinkas <[e-mail]>
Organization: Bull
X-Mailer: Mozilla 4.7 [fr] (Win98; I)
X-Accept-Language: fr
MIME-Version: 1.0
To: Simon Tardell <[e-mail]>
CC: IETF PKIX Mailing List <[e-mail]>
Subject: Re: OCSP request
References: <[e-mail]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Simon,

(deleted text)
 
> Eh? This was a rational FOR time stamping (as is evident by the next two
> sentences).

I did not see it this way. This is a rational for an *extension* to
the current *basic* definition of a Time Stamping Service.

>> A practical system has to protect itself from
>> that somehow. Enters time stamping. A time stamping service would
>> probably check the revocation status of the signatory cert and store
>> that together with the time stamp.

>> This is certainly not the definition of a time stamping service
>> within the PKIX WG. The TSA does NOT "check the revocation status of
>> the signatory cert and store that together with the time stamp".
 
> draft-ietf-pkix-time-stamp-09.txt:
> extensions is a generic way to add additional information in the
> future. Extensions is defined in [RFC 2459].
> Particular extension field types may be specified in standards or
> may be defined and registered by any organization or community.
> 
> Seems like a definite "MAY" to me.

You may *add* anything else you like. Since we were talking of basic
features and optional features about OCSP it is important not to mix
basic features and options.

Denis

> 
> Simon.
> 
> Simon Tardell, Software Architect, iD2 Technologies
> voice [phone], fax [phone], cell [phone]
> [e-mail], http://www.iD2tech.com
> Securing the Internet economy


Received: from odin2.bull.net (odin2.bull.net [192.90.70.84]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id GAA19761 for <[e-mail]>; Thu, 27 Jul 2000 06:14:11 -0700 (PDT)
Received: from lvt-mail.frlv.bull.fr (lvt-mail.frlv.bull.fr [129.184.62.223]) by odin2.bull.net (8.9.3/8.9.3) with ESMTP id PAA13264; Thu, 27 Jul 2000 15:21:11 +0200
Received: from bull.net (frpq6118.frpq.bull.fr [129.184.8.64]) by lvt-mail.frlv.bull.fr (8.9.2/8.9.1) with ESMTP id PAA40630; Thu, 27 Jul 2000 15:16:40 +0200
Message-ID: <[e-mail]>
Date: Thu, 27 Jul 2000 15:16:42 +0200
From: Denis Pinkas <[e-mail]>
Organization: Bull
X-Mailer: Mozilla 4.7 [fr] (Win98; I)
X-Accept-Language: fr
MIME-Version: 1.0
To: Simon Tardell <[e-mail]>
CC: Juergen Brauckmann <[e-mail]>, [e-mail]
Subject: Re: OCSP request
References: <[e-mail]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Simon,

> Denis,
> 
> > > This is not sufficient for systems that must be  robust/tolerant 
> > > against CA key compromise or such things.

> > Key compromise is an exceptional event (that should not happen, but
> > might happen) that must be addressed under a disaster recovery plan
> > (i.e. revoke the CA whose key has been compromised in all the
> > certificates that has been issued for that CA by other CAs).
 
> I see the disaster, but I don't see the recovery in this.
 
> As I see it, the problem the German model tries to tackle is that a CA which

Someone from Germany told me not to call it the "German model". Let
us talk of that *other* model, which means that this model is
different from the current X.509/PKIX model and therefore is using
mechanisms that are different from PKIX. I am not saying that the
other model is bad or good, simply that it is different.

> has issued lots of certificates to the public (say millions) gets it keys
> compromised somehow. Time-stamping services secure documents signed before
> this moment, but there is another problem. Millions of germans are now
> unable to go about their daily business. Potentially the German economy
> grinds to a halt while the CA reissues millions of smart cards. 

Ambarish said:

"P.S. Again, if you do pose the problems you want to solve, there
might be other reasonable ways of extending OCSP [within the
framework of the protocol], that might better fit in with the RFC
itself".

Juergen responded: "We try that, see the certHash extension ..." .

My comments is that the certHash extension is one *solution* to the
real *problem* that you describe.

> Obviously
> this would be a very bad thing. I'd hate to know that this scenario has not
> been prepared in advance. Since the end-user keys did not get compromised
> they can still be trusted. 

True.

> What is a problem is the linkage between the
> holder and his keys, embodied in the certificates. The "directory service
> (SigG)" essentially works as a time-stamping service for certificates,
> ensuring that the certificates may still be used after the "big bang", just
> as a general time-stamping service may protect signed documents against
> problems that occur after the original signature, so that they may still be
> used.

This is *one* solution to the problem, ... but not the single
solution.

That solution is also not compatible with RFC 2560, section 2.2. 
where it is stated:

"All definitive response messages SHALL be digitally signed. The key
used to sign the response MUST belong to one of the following:

 -- the CA who issued the certificate in question
 -- a Trusted Responder whose public key is trusted by the requester
 -- a CA Designated Responder (Authorized Responder) who holds a
    specially marked certificate issued directly by the CA,
    indicating that the responder may issue OCSP responses for 
    that CA".

This means that the OSCP server is either directly known by out of
bands means or designated by the CA. For that "other model" to work,
the OCSP would need to be designated by an *upper* CA. This is not
allowed with the current text, because in the current PKIX model
only the CA that has issued the certificate is allowed to nominate
the server in charge of providing revocation status information. 

We are pretty far away of deciding whether we should add or not a
certHash to an OCSP response, but whether this WG is ready to
develop
a model that is not compatible with PKIX. In the past we had SPKI.
The basic question might be whether some interrested people would 
like to form a BOF for developping such a new model.

> There are some obvious requirements following from this line of reasoning,
> e.g. that the keys for OCSP responses have to be independent from the
> issuing keys, and you have to have direct trust in the OCSP responder.
> 
> > This
> > does not mean using means that *permanently* address that case. If
> > you mandate an OCSP response in the sense you mention, then this
> > means two things:
> >
> > 1) you deny the use of CRLs, and
> 
> For this purpose, yes.
> 
> > 2) you also deny the local checking of the digital signature
> >    from a CA over any certificate (it means that a local checking
> >    by a RP is never sufficient since anyway an access to a trusted
> >    copy certificate is necessary in a trusted database from the CA
> >    which has issued it). So your model is *very* different from the
> >    path validation model that is currently described in RFC 2459
> >    (or its successor).
> 
> Definitely an extra step, and different from "ordinary PKI".

So we strongly agree that this *other* model is fairly different
from
"ordinary PKI".

Denis

> Simon.
> 
> Simon Tardell, Software Architect, iD2 Technologies
> voice [phone], fax [phone], cell [phone]
> [e-mail], http://www.iD2tech.com
> Securing the Internet economy


Received: from mystic1.trustcenter.de (mystic1.trustcenter.de [193.194.157.34]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id FAA16532 for <[e-mail]>; Thu, 27 Jul 2000 05:04:46 -0700 (PDT)
Received: by mystic1.trustcenter.de; id OAA07973; Thu, 27 Jul 2000 14:05:12 +0200
Received: from nodnsquery(192.168.200.3) by mystic1.trustcenter.de via smap (V5.0) id xma007966; Thu, 27 Jul 00 14:04:12 +0200
Received: from ew-jbr (titan.trustcenter.de [192.168.200.244]) by callisto.trustcenter.de (8.9.3/8.9.3) with SMTP id OAA11245; Thu, 27 Jul 2000 14:05:51 +0200 (MET DST)
Message-Id: <3.0.5.32.20000727140550.00a858f0@localhost>
X-Sender: jbr@localhost
X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (32)
Date: Thu, 27 Jul 2000 14:05:50 +0200
To: Denis Pinkas <[e-mail]>
From: Juergen Brauckmann <[e-mail]>
Subject: Re: OCSP request
Cc: [e-mail]
In-Reply-To: <[e-mail]>
References: <3.0.5.32.20000726145755.03772bc0@localhost>
Mime-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by ns.secondary.com id FAA16533

Hi Denis.

At 11:00 27.07.00 +0200, Denis Pinkas wrote:
>> This means that a client *never* can get an authoritive answer that the
>> certificate is faked (by the way of a CA key compromise) because a client
>> has no way of knowing whether he talked to all OCSP Responders that may
>> know something about the certificate.
>
>This is incorrect. You need to query an OCSP server you trust,
>either directly (indicated by out-of-bands means), or because it is
>indicated within the user certificate.

So a user must be sure that he configured his client software with all OCSP
responders that a CA may have.

How is he informed if the CA adds another OCSP responder?

>This is pretty different from RF 2459.

The ISIS specification is for use with the German Signature Law. The root
CA operated by the "Regulierungsbehoerde fuer Telekommunikation und Post"
<http://www.regtp.de/en> originally wanted to enforce a chain model, where
a certificate may be valid at time T even if its CA certificate is revoked
at T. They did this by revoking not any longer used CA certificates when
they performed a regular certificate and key rollover. So all certificates
under the old CA certificate were suddenly invalid with RFC2459
verification procedures. 

This means that there is some chance that we(=ISIS) must deal with
non-RFC2459 validity models.

Most involved CAs are, eh, not *really* happy with this situation. The
discussion with the RegTP is going on... .

>> It is also not sufficient for long term
>> validation of signatures, where you might have, e.g., a signature and a
>> certificate with an expired crypto algorithm, and a chain of timestamps
>> with valid algorithms, and where you want to verify the state of the
>> certificate that made the signature. In this situation you cannot rely on
>> the certificate itself as an evidence that a CA ever issued it, you must
>> ask the CA.
>
>This is wrong. A chain of time stamps protects against key
>compromise,

You are right if the timestamp is made over the signature and the
certificate. If the timestamp secures only the signature and a reference to
the certificate (like issuerDN/serialnumber and hash), then the CA must be
asked. OK, that's perhaps not too realistic... .

Juergen
-- 
Juergen Brauckmann             Tel.:  +49 (0)40 / 80 80 26-3 11
TC TrustCenter GmbH            Fax.:  +49 (0)40 / 80 80 26-1 26
Sonninstraße 24-28   	    mailto:[e-mail]
D-20097 Hamburg 		    http://www.trustcenter.de	


Received: from naigwy (void1.ausys.se [62.20.78.253]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id EAA16222 for <[e-mail]>; Thu, 27 Jul 2000 04:55:00 -0700 (PDT)
Received: FROM aunt15.ausys.se BY naigwy ; Thu Jul 27 13:56:11 2000 +0200
Received: by aunt15.ausys.se with Internet Mail Service (5.5.2650.21) id <PXJF9ZNJ>; Thu, 27 Jul 2000 13:57:38 +0200
Message-ID: <[e-mail]>
From: Simon Tardell <[e-mail]>
To: "'Bob Jueneman'" <[e-mail]>, [e-mail], Simon Tardell <[e-mail]>, [e-mail]
Cc: [e-mail], [e-mail]
Subject: RE: OCSP request
Date: Thu, 27 Jul 2000 13:57:42 +0200
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain; charset="iso-8859-1"

Bob,

> I don't mean to pick on Simon twice in one day, but his 
> assertions regarding the benefit of timestamping don't make 
> legal sense.

That is a very categorical statement. And I don't see where you contradict
what I say. There may be legal systems, and business practices, as well as
technical circumstances that makes timestamping of no benefit. OTOH the
reverse is also true. In fact, the rest of your reasoning about who stands
the risk if there is a dispute only serves to underline that. 

Paying with bank cards in Sweden and in the US is an analogue world example
of such differences in business practices (more that than law). In Sweden
the merchant forces you to show photo ID, because the bank will make him
stand the risk if he doesn't. And he has to (sort of) prove that he did (by
writing the ID card number on the slip, and signing). It seems perfectly
reasonable to me that a translation to our world would be the bank forcing
the merchant to check your certificate and time stamp that together with the
transaction. Or the time stamping service doing that step for him. 

Note, even though the imposter that tries to use my bank card is responsible
for doing so, that does not relieve the merchant of the obligation to check
ID. Liability doesn't have to be connected to business risk (the imposter
may never show up to pay the money he owes).

So, yes, laws and business practices do make a difference, I agree. And
technology does to, to support laws and business practices.

Simon.
 

Simon Tardell, Software Architect, iD2 Technologies
voice [phone], fax [phone], cell [phone]
[e-mail], http://www.iD2tech.com
Securing the Internet economy


Received: from naigwy (void1.ausys.se [62.20.78.253]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id EAA14054 for <[e-mail]>; Thu, 27 Jul 2000 04:03:53 -0700 (PDT)
Received: FROM aunt15.ausys.se BY naigwy ; Thu Jul 27 13:05:05 2000 +0200
Received: by aunt15.ausys.se with Internet Mail Service (5.5.2650.21) id <PXJF9Y61>; Thu, 27 Jul 2000 13:06:32 +0200
Message-ID: <[e-mail]>
From: Simon Tardell <[e-mail]>
To: "'Denis Pinkas'" <[e-mail]>, Simon Tardell <[e-mail]>
Cc: IETF PKIX Mailing List <[e-mail]>
Subject: RE: OCSP request
Date: Thu, 27 Jul 2000 13:06:33 +0200
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain; charset="iso-8859-1"

Denis,

> Bob picked up the same sentence in one of your E-mails and replied.
> I would like to comment on the same sentence.
> 
> (text deleted) 
> 
> > Now, if a key gets compromised, you cannot trust *any* signatures by
that
> > key (before or after compromise), because you cannot trust the signer's
> > assertion of what time it was. 
> 
> This is untrue. See the paper I co-wrote with Hans Nilson about the
> rational for using a time stamp. If the key of the TSA is not
> compromised, then you can prove that a given digital signature was
> done after the key compromise.

Eh? This was a rational FOR time stamping (as is evident by the next two
sentences).
 
> > A practical system has to protect itself from
> > that somehow. Enters time stamping. A time stamping service would
probably
> > check the revocation status of the signatory cert and store  that
together
> > with the time stamp.
> 
> This is certainly not the definition of a time stamping service
> within the PKIX WG. The TSA does NOT "check the revocation status of
> the signatory cert and store that together with the time stamp".

draft-ietf-pkix-time-stamp-09.txt:
  extensions is a generic way to add additional information in the 
  future. Extensions is defined in [RFC 2459].
  Particular extension field types may be specified in standards or 
  may be defined and registered by any organization or community. 

Seems like a definite "MAY" to me. 
 
Simon.

Simon Tardell, Software Architect, iD2 Technologies
voice [phone], fax [phone], cell [phone]
[e-mail], http://www.iD2tech.com
Securing the Internet economy


Received: from naigwy (void1.ausys.se [62.20.78.253]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id CAA07277 for <[e-mail]>; Thu, 27 Jul 2000 02:44:07 -0700 (PDT)
Received: FROM aunt15.ausys.se BY naigwy ; Thu Jul 27 11:45:19 2000 +0200
Received: by aunt15.ausys.se with Internet Mail Service (5.5.2650.21) id <PXJF9X6Y>; Thu, 27 Jul 2000 11:46:46 +0200
Message-ID: <[e-mail]>
From: Simon Tardell <[e-mail]>
To: "'Denis Pinkas'" <[e-mail]>, Juergen Brauckmann <[e-mail]>
Cc: [e-mail]
Subject: RE: OCSP request
Date: Thu, 27 Jul 2000 11:46:49 +0200
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain; charset="iso-8859-1"

Denis,

> > This is not sufficient for systems that must be  robust/tolerant against
CA
> > key compromise or such things. 
> 
> Key compromise is an exceptional event (that should not happen, but
> might happen) that must be addressed under a disaster recovery plan
> (i.e. revoke the CA whose key has been compromised in all the
> certificates that has been issued for that CA by other CAs). 

I see the disaster, but I don't see the recovery in this.

As I see it, the problem the German model tries to tackle is that a CA which
has issued lots of certificates to the public (say millions) gets it keys
compromised somehow. Time-stamping services secure documents signed before
this moment, but there is another problem. Millions of germans are now
unable to go about their daily business. Potentially the German economy
grinds to a halt while the CA reissues millions of smart cards. Obviously
this would be a very bad thing. I'd hate to know that this scenario has not
been prepared in advance. Since the end-user keys did not get compromised
they can still be trusted. What is a problem is the linkage between the
holder and his keys, embodied in the certificates. The "directory service
(SigG)" essentially works as a time-stamping service for certificates,
ensuring that the certificates may still be used after the "big bang", just
as a general time-stamping service may protect signed documents against
problems that occur after the original signature, so that they may still be
used.

There are some obvious requirements following from this line of reasoning,
e.g. that the keys for OCSP responses have to be independent from the
issuing keys, and you have to have direct trust in the OCSP responder.

> This
> does not mean using means that *permanently* address that case. If
> you mandate an OCSP response in the sense you mention, then this
> means two things: 
> 
> 1) you deny the use of CRLs, and 

For this purpose, yes.

> 2) you also deny the local checking of the digital signature 
>    from a CA over any certificate (it means that a local checking 
>    by a RP is never sufficient since anyway an access to a trusted 
>    copy certificate is necessary in a trusted database from the CA 
>    which has issued it). So your model is *very* different from the 
>    path validation model that is currently described in RFC 2459 
>    (or its successor). 

Definitely an extra step, and different from "ordinary PKI".
 
Simon.

Simon Tardell, Software Architect, iD2 Technologies
voice [phone], fax [phone], cell [phone]
[e-mail], http://www.iD2tech.com
Securing the Internet economy


Received: from mystic1.trustcenter.de (mystic1.trustcenter.de [193.194.157.34]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id CAA07031 for <[e-mail]>; Thu, 27 Jul 2000 02:38:33 -0700 (PDT)
Received: by mystic1.trustcenter.de; id LAA06538; Thu, 27 Jul 2000 11:39:02 +0200
Received: from nodnsquery(192.168.200.3) by mystic1.trustcenter.de via smap (V5.0) id xma006534; Thu, 27 Jul 00 11:39:01 +0200
Received: from ew-jbr (titan.trustcenter.de [192.168.200.244]) by callisto.trustcenter.de (8.9.3/8.9.3) with SMTP id LAA02796; Thu, 27 Jul 2000 11:40:41 +0200 (MET DST)
Message-Id: <3.0.5.32.20000727114042.00a8b8a0@localhost>
X-Sender: jbr@localhost
X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (32)
Date: Thu, 27 Jul 2000 11:40:42 +0200
To: [e-mail]
From: Juergen Brauckmann <[e-mail]>
Subject: RE: OCSP request
Cc: [e-mail]
In-Reply-To: <[e-mail]>
References: <3.0.5.32.20000726164011.04531100@localhost> <3.0.5.32.20000726164011.04531100@localhost>
Mime-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by ns.secondary.com id CAA07032

At 16:52 26.07.00 +0200, Michael Fritscher wrote:
>The problem in this context is not so much to be able to rely upon the
>OCSP response, but rather that you may have a relyable OCSP response on a
>certificate that can have been "easily faked" in the meantime...

And therefore you need trusted, reliable directory services that can
confirm the existence of a certificate, e.g., OCSP with extensions, and
that can give the user a chance to validate that the certificate the
directory service is talking about is the certificate he has (this can be
done by letting the OCSP responder send a hash of the cert in the response).

Juergen
-- 
Juergen Brauckmann             Tel.:  +49 (0)40 / 80 80 26-3 11
TC TrustCenter GmbH            Fax.:  +49 (0)40 / 80 80 26-1 26
Sonninstraße 24-28   	    mailto:[e-mail]
D-20097 Hamburg 		    http://www.trustcenter.de	


Received: from mystic1.trustcenter.de (mystic1.trustcenter.de [193.194.157.34]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id CAA06778 for <[e-mail]>; Thu, 27 Jul 2000 02:35:04 -0700 (PDT)
Received: by mystic1.trustcenter.de; id LAA06477; Thu, 27 Jul 2000 11:36:02 +0200
Received: from nodnsquery(192.168.200.3) by mystic1.trustcenter.de via smap (V5.0) id xma006473; Thu, 27 Jul 00 11:35:24 +0200
Received: from ew-jbr (titan.trustcenter.de [192.168.200.244]) by callisto.trustcenter.de (8.9.3/8.9.3) with SMTP id LAA02568; Thu, 27 Jul 2000 11:37:03 +0200 (MET DST)
Message-Id: <3.0.5.32.20000727113704.00a87520@localhost>
X-Sender: jbr@localhost
X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (32)
Date: Thu, 27 Jul 2000 11:37:04 +0200
To: Frank Balluffi <[e-mail]>
From: Juergen Brauckmann <[e-mail]>
Subject: RE: OCSP request
Cc: [e-mail]
In-Reply-To: <[e-mail] m>
Mime-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by ns.secondary.com id CAA06779

At 07:47 26.07.00 -0700, Frank Balluffi wrote:
>In the case you described, why would the timestamper know to use a "chain of
>timestamps with valid algorithms", but not the CA (i.e., use a valid
>algorithm)? Just curious.

Well, if you received an important signature from someone, you can get
timestamps from TSAs as often as you like (each time with a fresh
algorithm). But it may be difficult/impossible for you to get a new
certificate from the person that gave you the signature.

Juergen  
-- 
Juergen Brauckmann             Tel.:  +49 (0)40 / 80 80 26-3 11
TC TrustCenter GmbH            Fax.:  +49 (0)40 / 80 80 26-1 26
Sonninstraße 24-28   	    mailto:[e-mail]
D-20097 Hamburg 		    http://www.trustcenter.de	


Received: from mystic1.trustcenter.de (mystic1.trustcenter.de [193.194.157.34]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id CAA06546 for <[e-mail]>; Thu, 27 Jul 2000 02:32:02 -0700 (PDT)
Received: by mystic1.trustcenter.de; id LAA06452; Thu, 27 Jul 2000 11:33:01 +0200
Received: from nodnsquery(192.168.200.3) by mystic1.trustcenter.de via smap (V5.0) id xma006446; Thu, 27 Jul 00 11:32:25 +0200
Received: from ew-jbr (titan.trustcenter.de [192.168.200.244]) by callisto.trustcenter.de (8.9.3/8.9.3) with SMTP id LAA02412; Thu, 27 Jul 2000 11:34:04 +0200 (MET DST)
Message-Id: <3.0.5.32.20000727113404.03a09be0@localhost>
X-Sender: jbr@localhost
X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (32)
Date: Thu, 27 Jul 2000 11:34:04 +0200
To: Ambarish Malpani <[e-mail]>
From: Juergen Brauckmann <[e-mail]>
Subject: RE: OCSP request
Cc: [e-mail]
In-Reply-To: <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by ns.secondary.com id CAA06547

Hello Ambarish.

At 07:10 26.07.00 -0700, Ambarish Malpani wrote:
>1. OCSP responses are not meant to be weak at all. The meaning of
>good is "not revoked" or "still good" (as long as the certificate
>was correctly issued and hadn't expired before the ArchiveCutoff
>date).

>From RFC 2560:
   The "good" state indicates a positive response to the status inquiry.
   At a minimum, this positive response indicates that the certificate
   is not revoked, but does not necessarily mean that the certificate
   was ever issued

By saying that OCSP responses are "weak" I had the last sentence in mind.
An OCSP responder can give me a "good" even if the CA did not issue the
certificate. Minimum-RFC2560-OCSP-responses with "Good" don't tell me
whether the certificate ever existed.

"Weak" is probably a bad word for it. 

>The problem you might run into,
>is say, somebody builds an ISIS OCSP server and somebody else
>tries to use it with say a Netscape Communicator OCSP client. The
>two products will claim to talk OCSP, but will actually be saying
>different things in their requests and responses and nobody else
>will ever know.

Yes, I see. 

One question (mainly an attempt to try to understand rfc 2560): Why didn't
you include specifications for the issuance questions into rfc 2560?
Obviously you were aware of the problem because the description of "good"
says that such information may be delivered by extensions. And why isn't
there a fourth state "noSuchCert" besides good,revoked,unknown? I
understand that it was the intention to be able to build CRL-based OCSP
Responders, but I don't see why it should have been impossible to combine
the two things.

>b. The reason why the change ISIS has proposed is "wrong" is:
>In an OCSP request, you identify a cert by the hash of the CA's
>public key [and the hash of the CA's name] and the certificate
>serial number. If somebody had compromised the CA's public key,
>all they would need to do, is create a new certificate with a
>serial number that corresponds to a legitimate serial number, but
>a different subject public key and there goes the ability of the
>OCSP responder to tell you anything useful.

Yes. Therefore the OCSP Response should contain a hash of the certificate
in an extension, see my mail
from yesterday "good in OCSP Responses. Was: Re: OCSP request". This is the
ISIS certHash extensions Simon is refering to in his mail from 10:28 today.

>Part of why it is valuable to at least pose desires to change the
>interpretations of RFCs on this kind of a list, is you might
>actually get some useful input from others, who might think about
>a problem in different ways.
>
>Does that make sense?

Well one problem is that it's difficult to see what the interpretation of
RFC2560 is that the authors had in mind... .

>P.S. Again, if you do pose the problems you want to solve, there
>might be other reasonable ways of extending OCSP [within the
>framework of the protocol], that might better fit in with the RFC
>itself.

We try that, see the certHash extension... .

Regards,
  Juergen
-- 
Juergen Brauckmann             Tel.:  +49 (0)40 / 80 80 26-3 11
TC TrustCenter GmbH            Fax.:  +49 (0)40 / 80 80 26-1 26
Sonninstraße 24-28   	    mailto:[e-mail]
D-20097 Hamburg 		    http://www.trustcenter.de	


Received: from odin2.bull.net (odin2.bull.net [192.90.70.84]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id CAA06077 for <[e-mail]>; Thu, 27 Jul 2000 02:10:02 -0700 (PDT)
Received: from lvt-mail.frlv.bull.fr (lvt-mail.frlv.bull.fr [129.184.62.223]) by odin2.bull.net (8.9.3/8.9.3) with ESMTP id LAA11792; Thu, 27 Jul 2000 11:17:09 +0200
Received: from bull.net (frpq6118.frpq.bull.fr [129.184.8.64]) by lvt-mail.frlv.bull.fr (8.9.2/8.9.1) with ESMTP id LAA31550; Thu, 27 Jul 2000 11:12:39 +0200
Message-ID: <[e-mail]>
Date: Thu, 27 Jul 2000 11:12:41 +0200
From: Denis Pinkas <[e-mail]>
Organization: Bull
X-Mailer: Mozilla 4.7 [fr] (Win98; I)
X-Accept-Language: fr
MIME-Version: 1.0
To: Simon Tardell <[e-mail]>
CC: IETF PKIX Mailing List <[e-mail]>
Subject: Re: OCSP request
References: <[e-mail]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Simon,

Bob picked up the same sentence in one of your E-mails and replied.
I would like to comment on the same sentence.

(text deleted) 

> Now, if a key gets compromised, you cannot trust *any* signatures by that
> key (before or after compromise), because you cannot trust the signer's
> assertion of what time it was. 

This is untrue. See the paper I co-wrote with Hans Nilson about the
rational for using a time stamp. If the key of the TSA is not
compromised, then you can prove that a given digital signature was
done after the key compromise.

> A practical system has to protect itself from
> that somehow. Enters time stamping. A time stamping service would probably
> check the revocation status of the signatory cert and store that together
> with the time stamp.

This is certainly not the definition of a time stamping service
within the PKIX WG. The TSA does NOT "check the revocation status of
the signatory cert and store that together with the time stamp".
 
Denis
 
> Simon
 
> Simon Tardell, Software Architect, iD2 Technologies
> voice [phone], fax [phone], cell [phone]
> [e-mail], http://www.iD2tech.com
> Securing the Internet economy


Received: from odin2.bull.net (odin2.bull.net [192.90.70.84]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id BAA05712 for <[e-mail]>; Thu, 27 Jul 2000 01:57:44 -0700 (PDT)
Received: from lvt-mail.frlv.bull.fr (lvt-mail.frlv.bull.fr [129.184.62.223]) by odin2.bull.net (8.9.3/8.9.3) with ESMTP id LAA20084; Thu, 27 Jul 2000 11:04:50 +0200
Received: from bull.net (frpq6118.frpq.bull.fr [129.184.8.64]) by lvt-mail.frlv.bull.fr (8.9.2/8.9.1) with ESMTP id LAA31720; Thu, 27 Jul 2000 11:00:20 +0200
Message-ID: <[e-mail]>
Date: Thu, 27 Jul 2000 11:00:22 +0200
From: Denis Pinkas <[e-mail]>
Organization: Bull
X-Mailer: Mozilla 4.7 [fr] (Win98; I)
X-Accept-Language: fr
MIME-Version: 1.0
To: Juergen Brauckmann <[e-mail]>
CC: [e-mail]
Subject: Re: OCSP request
References: <3.0.5.32.20000726145755.03772bc0@localhost>
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 8bit

Juergen,

See my comments below.

> Ambarish, Simon,
> 
> I'm a member of the group that worked on the ISIS. Comments below... .
> 
> >> -----Original Message-----
> >> From: Simon Tardell [mailto:[e-mail]]
> >> Sent: Tuesday, July 25, 2000 8:45 AM
> >> To: 'Ambarish Malpani'; Simon Tardell; 'Rich Salz'; Joerg Seidel
> >> Cc: [e-mail]
> >> Subject: RE: OCSP request

> [...]
> >> Also, in your interpretation (and mine) "unknown" means "I
> >> don't know or will not say". As a client a perfectly 
> >> reasonable reaction to that would be to come back and 
> >> check later or go to another OCSP responder (assuming I
> >> have a list to choose from) and query that responder.

> This means that a client *never* can get an authoritive answer that the
> certificate is faked (by the way of a CA key compromise) because a client
> has no way of knowing whether he talked to all OCSP Responders that may
> know something about the certificate.

This is incorrect. You need to query an OCSP server you trust,
either directly (indicated by out-of-bands means), or because it is
indicated within the user certificate.

> >> However, it is possible to interpret the "unknown" 
> >> definition as an assertion that "I know that this 
> >> certificate is not issued". This is the interpretation 
> >> taken by the German Trust Center Work Group in their ISIS spec.
 
> RFC2560:
>    The "unknown" state indicates that the responder doesn't know about
>    the certificate being requested.
 
> ISIS:
>         "Such a reply means that the queried directory service (SigG) cannot
>         provide information about this certificate, since it was not issued
>         by the corresponding certification authority or was not entered into
>         the directory service (SigG)."
 
> Let me try to explain why we want to have "hard" responses from directory
> services. The minimum requirements to OCSP in RFC2560 are "weak" in the
> sense that there is only one real answer ("revoked") and two answers
> ("unknown" and "good") which basically mean "Hm, I'm not sure". Minimum
> RFC2560-OCSP only provides blacklist functionality.

Nearly. It is not a "minimum" requirement, it is a "maximum"
requirement. Suppress "Minimum". The right sentence is:
"RFC2560-OCSP only provides blacklist functionality". This allows
OCSP responders to base their responses using CRLs only and no other
information.
 
> This is not sufficient for systems that must be robust/tolerant against CA
> key compromise or such things. 

Key compromise is an exceptional event (that should not happen, but
might happen) that must be addressed under a disaster recovery plan
(i.e. revoke the CA whose key has been compromised in all the
certificates that has been issued for that CA by other CAs). This
does not mean using means that *permanently* address that case. If
you mandate an OCSP response in the sense you mention, then this
means two things: 

1) you deny the use of CRLs, and 

2) you also deny the local checking of the digital signature 
   from a CA over any certificate (it means that a local checking 
   by a RP is never sufficient since anyway an access to a trusted 
   copy certificate is necessary in a trusted database from the CA 
   which has issued it). So your model is *very* different from the 
   path validation model that is currently described in RFC 2459 
   (or its successor). 

This is pretty different from RF 2459.

> It is also not sufficient for long term
> validation of signatures, where you might have, e.g., a signature and a
> certificate with an expired crypto algorithm, and a chain of timestamps
> with valid algorithms, and where you want to verify the state of the
> certificate that made the signature. In this situation you cannot rely on
> the certificate itself as an evidence that a CA ever issued it, you must
> ask the CA.

This is wrong. A chain of time stamps protects against key
compromise,
as well as weak algorithms, as long as the timestamps have been
applied
before the key has been compromised or the algorithm has been found
weak. So there is no need to ask the CA.

> In such systems a directory service must be able to give real *positive*
> answers about certificates ("Yes, my CA issued this certificate."). This
> means we need white lists. This can be done by using OCSP and interpreting
> "unknown" as "The certificate was not issued by this CA", and by
> interpreting "good" as "The certificate was issued by this CA and not
> revoked".

No. OCSP is not based on the use of white lists. RFC 2459 allows the
use of CRLs and also allows the use of on-line methods of revocation
notification (like OCSP) as another way of providing the same level
of service.

Section 3.3 on revocation of RFC 2459 explicitly states the
following:

" However, this profile does not require CAs to issue CRLs. Message
formats and protocols supporting on-line revocation notification may
be defined in other PKIX specifications.  On-line methods of
revocation notification may be applicable in some environments as an
alternative to the X.509 CRL."

Denis
 
> The semantics of "Good" is left rather unspecified in RFC2560, why
> shouldn't also "Unknown" be the subject of profile-specific
> interpretations? Why should that be "very, very wrong"?
> 
> Juergen
> --
> Juergen Brauckmann             Tel.:  +49 (0)40 / 80 80 26-3 11
> TC TrustCenter GmbH            Fax.:  +49 (0)40 / 80 80 26-1 26
> Sonninstraße 24-28          mailto:[e-mail]
> D-20097 Hamburg                     http://www.trustcenter.de


Received: from naigwy (void1.ausys.se [62.20.78.253]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id BAA05433 for <[e-mail]>; Thu, 27 Jul 2000 01:55:37 -0700 (PDT)
Received: FROM aunt15.ausys.se BY naigwy ; Thu Jul 27 10:56:48 2000 +0200
Received: by aunt15.ausys.se with Internet Mail Service (5.5.2650.21) id <PXJF9X21>; Thu, 27 Jul 2000 10:58:15 +0200
Message-ID: <[e-mail]>
From: Simon Tardell <[e-mail]>
To: "'Ambarish Malpani'" <[e-mail]>, "'Juergen Brauckmann'" <[e-mail]>
Cc: [e-mail]
Subject: RE: OCSP request
Date: Thu, 27 Jul 2000 10:58:17 +0200
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain; charset="iso-8859-1"

Ambarish,

> b. The reason why the change ISIS has proposed is "wrong" is:
> In an OCSP request, you identify a cert by the hash of the CA's
> public key [and the hash of the CA's name] and the certificate
> serial number. If somebody had compromised the CA's public key,
> all they would need to do, is create a new certificate with a
> serial number that corresponds to a legitimate serial number, but
> a different subject public key and there goes the ability of the
> OCSP responder to tell you anything useful.

ISIS defines an extension holding the hash of the certificate for this
purpose.

Simon.

Simon Tardell, Software Architect, iD2 Technologies
voice [phone], fax [phone], cell [phone]
[e-mail], http://www.iD2tech.com
Securing the Internet economy


Received: from odin2.bull.net (odin2.bull.net [192.90.70.84]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id AAA02029 for <[e-mail]>; Thu, 27 Jul 2000 00:11:01 -0700 (PDT)
Received: from lvt-mail.frlv.bull.fr (lvt-mail.frlv.bull.fr [129.184.62.223]) by odin2.bull.net (8.9.3/8.9.3) with ESMTP id JAA13118; Thu, 27 Jul 2000 09:18:06 +0200
Received: from bull.net (frpq6118.frpq.bull.fr [129.184.8.64]) by lvt-mail.frlv.bull.fr (8.9.2/8.9.1) with ESMTP id JAA30936; Thu, 27 Jul 2000 09:13:35 +0200
Message-ID: <[e-mail]>
Date: Thu, 27 Jul 2000 09:13:37 +0200
From: Denis Pinkas <[e-mail]>
Organization: Bull
X-Mailer: Mozilla 4.7 [fr] (Win98; I)
X-Accept-Language: fr
MIME-Version: 1.0
To: Bob Jueneman <[e-mail]>
CC: [e-mail]
Subject: Re: Dual-signed certificates
References: <[e-mail]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Bob,

(text deleted)

I will only comment on one point.

> Denis proposed:
> 
> There exists a way, including by a procedure that is verifiable for
> every received signature by any relying party. In the stuff that got
> signed, you include the identifier of the certificate. This may be
> done by using CMS (or is mandated in ES 201733). There is no need to
> invent a double-signed certificate.

> The point is that this procedure works for every legitimate 
> document that I signed, but is not enforceable AS AN EXPECTATION 
> against some illegitimate use of my certificate/key.
 
> Now I grant that a CA can easily create a key pair and a certificate 
> that would impersonate me for some small number of documents.  But 
> I would attempt to repudiate that so-called signature by saying, 
> "That signature and key is not mine, and I have never sees or made 
> beneficial use of that key.  

Not exactly. You are going to challenge the CA/RA to prove that you
asked for that public key, no matter if the private has been used.
If the CA/RA cannot present the right registration information, then
you win.

> My key is xxxxxxx, and in fact 
> I _have_ made extensive use of that key, and I have signalled my 
> acceptance of that key, the certificate, and the terms and 
> conditions of that certificate by counter-signing it and distributing 
> widely in that counter-signed format."

This would not prove anything in the case you just mention above,
because the (bad) CA could do that "for" you.
 
> The rogue CA could claim the same thing, of coruse, but then 
> I would ask to see demonstrated beneficial use on my behalf, 
> for example goods that were ordered and delivered (and accepted) 
> to my address, based on that key.

No. This is not necessary. The registration information is
essential.

Denis

(further text deleted)


Received: from florida.melco.co.jp (florida.melco.co.jp [192.218.140.46]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id AAA01643 for <[e-mail]>; Thu, 27 Jul 2000 00:06:51 -0700 (PDT)
Received: by florida.melco.co.jp (3.7W-florida) id QAA23915; Thu, 27 Jul 2000 16:09:59 +0900 (JST)
Received: by mailgw.melco.co.jp (3.7W-mailgw) id QAA15529; Thu, 27 Jul 2000 16:09:59 +0900 (JST)
Received: by inetgw.melco.co.jp (8.8.8+2.7Wbeta7/3.7W-inetgw) id QAA27173; Thu, 27 Jul 2000 16:09:59 +0900 (JST)
Received: from islgw.isl.melco.co.jp by elgw.isl.melco.co.jp (8.8.8/3.6W) id QAA24318; Thu, 27 Jul 2000 16:09:58 +0900 (JST)
Received: from iss.isl.melco.co.jp by islgw.isl.melco.co.jp (8.8.8/3.6W) id QAA27159; Thu, 27 Jul 2000 16:09:58 +0900 (JST)
Received: from belize by iss.isl.melco.co.jp (8.8.8/3.6W) id QAA19468; Thu, 27 Jul 2000 16:09:57 +0900 (JST)
Message-ID: <00d401bff799$e85191a0$[e-mail]>
From: "Hiroyuki Sakakibara" <[e-mail]>
To: <[e-mail]>
Subject: RE: Dual-signed certificates
Date: Thu, 27 Jul 2000 16:11:38 +0900
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-2022-jp"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.00.2314.1300
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300

Hi.
I am interested in this topic.

A self-signed certificate that contains the original
certificate as an extension within it, or, a dual-signed
certificate using CMS SignedData are recommended in this-list.

On Mon, 24 Jul 2000 Mr. Russ Housley wrote:
>Bob:

>There are some significant technical issues here.  The subject cannot sign
>first because it does not know the values that will be assigned for several
>fields, like the serial number.  The subject cannot sign second
>either.  The insertion of an additional extension will break the issuer
>signature.

>Thus, to proceed in this vain, complex processing must be defined that says
>which parts of the certificate a re coved by the subject signature in the
>extension.  I think that the processing is complex enough....

>Russ

Is a X.509 ver3 certificate,
including such as "Issuance Agreement"extension signed by a subject
not feasible ?

Extension : Issuance Agreement
means that "Subject agrees with issuance of his certificate
which includes fields and values described in this agreement."
Fields and values include public key, issuer name, subject name,
extensions etc..., but DO NOT include CA's signature.
When a CA receives a request from a subject,
creates "Issuance Agreement"
and shows it to the subject. If the subject agrees it before issuance,
he signs it and give it to the CA. The CA issues the subject certificate
including "signed Issuance Agreement" as an extension.
(I attach more detais to end)

I think that this style natural.

Because, in this style, CA's signature certifies
"the subject public key and the subject's signature on
Issance Agreement in the extension",
but the subject's signature DOES NOT certifies "CA's signature".

"the subject sign second" style,
such as a self-signed certificate that contains the original
certificate as an extension within it,
I think it means that
(1) the subject's self-signed signature certifies
the CA's signature on the subject certificate inside,
(2) the CA's signature on the subject certificate certifies
the subject public key.
(3) subject public key in (2) can be used to verify
    the subject's signature (1).

Eventhough the subject self-signed certificate contains
ID of the original certificate and its hash value,
instead of the original itself,
this also certifies the CA's signature of the
original certificate indirectly.

Is this kind of Cross-Certification or nested certification,
or the tail wags the dog ?
( Am I misunderstanding ??? )

However, as Mr.Housley wrote,
a new protocol, data, the processing must be specified for
such as a certificate including "Issuance Agreement" extension.
"the subject sign first" style.

I attach my idea to end of this mail.

Hiroyuki Sakakibara
MITSUBISHI ELECTRIC CORPORATION

-------------------------------------------------------

Indeed, I think that a new certificate issuance protocol for Issuance
Agreement extension is needed
in order to solve the chickenAndEgg probolem, like this.

1.Subject -----> CA : Cert request(including Subject PublicKey)

2.Subject <----- CA : Issuance Agreement

3.Subject -----> CA : Signed Issuance Agreement by Subject PrivateKey
                      (Subject confirms that "My cert are going to include
                       information described in Issuance Agreement",
                       if he agrees, then signs it.)

4.Subject <----- CA : Subject Cert including
                        "Signed" Issuance Agreement as a extension
                        of X.509 ver3

Contents of Issuance Agreement :

Fields and values in Subject Certificate to be issued in step 4,
{
version
Issuer name
Subject name
SerialNumber(optional),
Algorithm
Subject Public Key Information
notBefore(optional)
notAfter
extensions( certPolicies, nameConstraints, keyUsage ... etc )
CA's signature algorithm
}

If a subject checks the contents in step 2,
he can know what his certificate is going to include.
Some CAs may assign SerialNumber and notBefore(scheduled) field,
some CAs may not, when CAs create Issuance Agreement.

If a CA can assign scheduled notBefore value in Issuance Agreement,
like,
"Your certificate is going to be valid after 200007261200Z",
and if the issued subject certificate inculdes the same value in validity
notBefore field, I think that it is OK.

If RelyingPertiy finds that validity notBefore
does not match with notBefore in the Signed Issuance Agreement
extension field, then RP can reject it.

I think that eventhough the contents does not include SerialNmber field,
Subject can know that what his certificate should be avilable for,
"My public key is going to be certified by Issuer and I am the holder,
 and can be used by following these validity, certPolicies, keyUsage etc..."

But this Issuance Agreement extension is as large as his certificate itself.
So some techinique which can reduce this extension size
is needed, for example, applying a hash function etc...

( I think that a self-signed certificate that contains the original
  certificate as an extension within it has the same problem,
  maybe, the size would be twice ? )

------------------------------------------------------------------------
Hiroyuki Sakakibara
MITSUBISHI ELECTRIC CORPORATION
Information Technology R&D Center
5-1-1 Ofuna, Kamakura, Kanagawa, Japan
PHONE: [phone]
FAX:   [phone]
E-mail : [e-mail]




Received: from mail-fwd.verio-web.com (mail11a.verio-web.com [161.58.16.57]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id VAA25080 for <[e-mail]>; Wed, 26 Jul 2000 21:38:54 -0700 (PDT)
Received: from 161.58.117.181 (161.58.117.181) by mail11a.verio-web.com (RS ver 1.0.57s) with SMTP id 02311109; Thu, 27 Jul 2000 00:41:57 -0400 (EDT)
Received: from caveosystems.com (lynn1-pm3-s02-87.port.shore.net [204.167.109.87]) by pc1.caveosystems.com (8.9.3/8.9.3) with ESMTP id AAA30801; Thu, 27 Jul 2000 00:42:24 -0400
Message-ID: <[e-mail]>
Date: Thu, 27 Jul 2000 00:44:35 -0400
From: Rich Salz <[e-mail]>
X-Mailer: Mozilla 4.73 [en] (Win98; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Ambarish Malpani <[e-mail]>
CC: [e-mail]
Subject: Re: OCSP request
References: <[e-mail]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
X-Loop-Detect: 1

>     I was thinking of something like adding an extension in the
> request which asks: isCertInDirectory
> and the response is: yes, no, don'tknow

sure, all the more reason for my "reply signatures' controls. :)


Received: from ext-mail.valicert.com (ns1.valicert.com [63.65.221.10]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id TAA17767 for <[e-mail]>; Wed, 26 Jul 2000 19:57:17 -0700 (PDT)
Received: from CONVERSION-DAEMON.ext-mail.valicert.com by ext-mail.valicert.com (PMDF V6.0-24 #46243) id <[e-mail]> for [e-mail]; Wed, 26 Jul 2000 20:00:16 -0700 (PDT)
Received: from seine.valicert.com ([192.168.2.23]) by ext-mail.valicert.com (PMDF V6.0-24 #46243) with ESMTP id <[e-mail]> for [e-mail]; Wed, 26 Jul 2000 08:49:36 -0700 (PDT)
Received: by seine.valicert.com with Internet Mail Service (5.5.2650.21) id <36007D4W>; Wed, 26 Jul 2000 08:41:05 -0700
Content-return: allowed
Date: Wed, 26 Jul 2000 08:41:03 -0700
From: Ambarish Malpani <[e-mail]>
Subject: RE: OCSP request
To: [e-mail]
Message-id: <[e-mail]>
MIME-version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-type: text/plain; charset=iso-8859-1

Hi Rich,
    I was thinking of something like adding an extension in the
request which asks: isCertInDirectory

and the response is: yes, no, don'tknow

A

---------------------------------------------------------------------
Ambarish Malpani
Architect                                                650.567.5457
ValiCert, Inc.                                  [e-mail]
339 N. Bernardo Ave.                          http://www.valicert.com
Mountain View, CA 94043


> -----Original Message-----
> From: Rich Salz [mailto:[e-mail]]
> Sent: Wednesday, July 26, 2000 7:52 AM
> To: Ambarish Malpani
> Cc: [e-mail]
> Subject: Re: OCSP request
> 
> 
> > I like the idea of asking a separate question about whether a
> > cert is in a directory (or ever issued) and getting a separate
> > answer for that.
> 
> But then you need something like draft-salzr-ldap-repsig to 
> ensure that
> nobody has tampered with, or interecepted the communications to/from,
> the repository.
> 	/r$
> 


Received: from prv-mail20.provo.novell.com (prv-mail20.provo.novell.com [137.65.81.122]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id QAA04634 for <[e-mail]>; Wed, 26 Jul 2000 16:17:32 -0700 (PDT)
Received: from INET-PRV-Message_Server by prv-mail20.provo.novell.com with Novell_GroupWise; Wed, 26 Jul 2000 17:19:59 -0600
Message-Id: <[e-mail]>
X-Mailer: Novell GroupWise Internet Agent 5.5.3.1
Date: Wed, 26 Jul 2000 17:20:00 -0600
From: "Bob Jueneman" <[e-mail]>
To: <[e-mail]>, <[e-mail]>, <[e-mail]>
Cc: <[e-mail]>, <[e-mail]>
Subject: RE: OCSP request
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by ns.secondary.com id QAA04635

I don't mean to pick on Simon twice in one day, but his assertions regarding the benefit of timestamping don't make legal sense.

>Now, if a key gets compromised, you cannot trust *any* signatures by that
>key (before or after compromise), because you cannot trust the signer's
>assertion of what time it was. A practical system has to protect itself from
>that somehow. Enters time stamping. A time stamping service would probably
>check the revocation status of the signatory cert and store that together
>with the time stamp. 

If the certificate is revoked for cause, e.g, a change of name, change of status, etc., then (generally speaking) whoever did in fact sign the document is legally liable for the consequences, regardless of the revocation status.  (Note that I said whoever in fact signed the document, NOT necessarily the apparent subscriber.) All that the revocation does is to change the reasonableness of the presumption that the transaction was valid -- it doesn't change the _fact_ of who signed it -- they are still personally liable.

The other case is where a key compromise is suspected.  Depending on the circumstances, that compromise might or might not be known.  If a smart card is lost, the time could probably be pinned down to a day or so, but if someone's password for a software-encrypted key were compromised, no one is likely to know IF that occurred, much less when.

In the second case, therefore, it may be completely immaterial as to when a given document was signed, and all of the timestamps in the world won't help, if in fact the key was compromised a year earlier, covertly.

The real issue is not a technical one, but two legal ones.  The first is, in the event of a challenged signature (attempted repudiation), which party bears the burden of proof.

Depending upon the specific statutes, the revocation of a certificate MAY serve to transfer the burden of proof to the relying party, to show that the reliance on the transaction was commercially reasonable.  Some of the original digital signature statutes, such as the much maligned Utah Act, attempted to answer that question with a rebuttable presumption, assuming that the certificate was issued by a licensed CA.

The second issue is, regardless of who has the burden of proof, who bears the risk of loss in the event that the subscriber did not in fact sign the transaction.  is the subscriber strictly liable, or is the relying party required to show both commercial reasonableness and perhaps to bear some or all of the risk of loss?

Those aren't technical questions, they are legal ones, and OCSP can't help very much.

Bob




Received: from prv-mail20.provo.novell.com (prv-mail20.provo.novell.com [137.65.81.122]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id PAA03742 for <[e-mail]>; Wed, 26 Jul 2000 15:49:50 -0700 (PDT)
Received: from INET-PRV-Message_Server by prv-mail20.provo.novell.com with Novell_GroupWise; Wed, 26 Jul 2000 16:52:17 -0600
Message-Id: <[e-mail]>
X-Mailer: Novell GroupWise Internet Agent 5.5.3.1
Date: Wed, 26 Jul 2000 16:52:18 -0600
From: "Bob Jueneman" <[e-mail]>
To: <[e-mail]>
Subject: RE: Dual-signed certificates
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by ns.secondary.com id PAA03743

To respond to several of the Chicken and Egg points raised, obviously the second signature could not be included within the scope of the first.  I was remiss in describing this as a certificate attribute, because that would imply that it was embedded within the certificate signed by the issuer. So some new kind of format would have to be devised, where the signature would be appended.

I rather like the concept of a self-signed certificate that contains the original certificate as an extension within it.  If I trust the signer and his public key through some out of band mechanism, or thorough continued use, I can stop there, but if I haven't received the key any other way I can look inside and proceed from there.

After reading the comments by Simon Tardell and Denis Pinckas, I realized that perhaps I hadn't made my original point sufficiently clear.  In the meantime, some jocular references to 7-11 and McDonalds providing physical point of presense confirmation to a CA actually helps make my point.

The present, more or less-well-accepted CA model is that the subscriber goes to a local RA and requests a certificate be issued in his name.  That RA is then free to add or modify whatever it likes to the certificate request, and sends it on to the CA to be certified.

But the CA, depending on its CP and CPS, may add, modify, or delete information in the certificate request to suit its own purposes.  It could add DN qualification to make the DN unique, it could add various policy OIDs and policy constraints -- whatever it wishes to do.

It then sends the certificate back to the user, or posts it in a repository, but with no nonrepudiable evidence that either the RA or the subscriber had in fact agreed to those changes or additions!

Moreover, a rogue CA could create two such certificates, one containing terms favorable to it, and another closer to what the subscriber had originally requested.  Now, because the inclusion of the certificate in a transaction to be signed is (1) optional, and (2) only applies to transactions per se and not to session authentication or encryption, the relying party has no way of knowing whether the user in fact agreed to those terms..

This is why relying on a signed CMS object won't work -- the RP has no good way of knowing whether that format was expected or not.

Denis proposed:

><There exists a way, including by a procedure that is verifiable for
every received signature by any relying party. In the stuff that got
signed, you include the identifier of the certificate. This may be
done by using CMS (or is mandated in ES 201733). There is no need to
invent a double-signed certificate.

The point is that this procedure works for every legitimate document that I signed, but is not enforceable AS AN EXPECTATION against some illegitimate use of my certificate/key.

Now I grant that a CA can easily create a key pair and a certificate that would impersonate me for some small number of documents.  But I would attempt to repudiate that so-called signature by saying, "That signature and key is not mine, and I have never sees or made beneficial use of that key.  My key is xxxxxxx, and in fact I _have_ made extensive use of that key, and I have signalled my acceptance of that key, the certificate, and the terms and conditions of that certificate by counter-signing it and distributing widely in that counter-signed format."

The rogue CA could claim the same thing, of coruse, but then I would ask to see demonstrated beneficial use on my behalf, for example goods that were ordered and delivered (and accepted) to my address, based on that key.

A dual-signed certificate would also be beneficial to the good CAs, because it would provide a degree of proof that I had in fact accepted the certificate.

I believe that there is another point to be made here as well, and that is that trust accumulates incrementally with every accepted and reliable use of the key.

For the very first transaction with a particular subscriber, the relying party has little or no basis for trust, per se, except that if he trusts the CA he can presumably trust that the subscriber is correctly (if not unambiguously) identified.  So I know that the subject is "Bob Jones" or maybe "Village Idiot #13", but I don't know that I can trust that particular individual to either do or not do particular things.  Even if the certificate claims that the subscriber has agree to certain terms and conditions, I have no way of verifying the fact that that subscriber has really agreed to those terms, and I probably cannot sue the CA to enforce those terms if the subscriber defaults.  So I really want to know what representations the subscriber is making to me, directly.

However, for every transaction after the first, I have an additional degree of knowledge regarding that user.  I may not even care what his name is, or whether he has agreed to this, that, or the other certificate policy, so long as I get paid for the agreed upon transaction.

Sooner or later, the original identification by the RA and CA becomes almost irrelevant -- after all, they weren't testifying as to whether the person was financially solvent and a responsible bill payer, but I will come to know that.

Likewise, to switch metaphors, if I am a hospital administrator and I decide to revoke a doctor's staff priviledges because too many of his patients have been dying, I really don't care what some public CA happens to think about the validity of that doctor's certificate.

The point is that in many respects we tend to grant an excessive amount of authority to the CA in terms of establishing policy, etc., and yet in most cases (other than some closed user groups) the CA is not in a position to be able to enforce those policies against a particular user.  So the real issue is what terms and conditions the subscriber has agreed to, and how that acceptance can be reliably made known.

(This point of view may of course be anathema to those who espouse a top-down, authoritarian control structure, including many European countries and perhaps the US DOD.  Chacun a son gout.:-)

Bob

>>> Simon Tardell <[e-mail]> 07/22/00 06:46AM >>>
>      However, do people think it appropriate for the real external
> certificate to be carried around inside a CMS SignedData or a 
> self-signed certificate?  It certainly can be done, but should it?

If I've been reading the thread correctly the physical world analogy of the
"threat" that this would countermeasure is that a bank noone ever heard of
would issue an ID card with my picture (which they can do, because they saw
my ID card once) to someone who doesn't look like me and the question is not
whether you can trust the odd-looking fellow, but whether you can trust that
bank. 

When it comes to well-known banks, government branches, etc I assume they
won't do this, and I would not trust even my closest friends to be able to
assert with any degrees of certitude if a bank is honest or not issuing
certs. And no number of assertions that a Mickey Mouse CA issues a
certificate to the right guy would make me trust that CA to always do the
right thing (even if I would trust the particular certs it issued).

I am bit skeptical here, not because web-of-trust models don't have a
legitimate use, but rather because they don't mix very well with PKI.

Simon

Simon Tardell, Software Architect, iD2 Technologies
voice [phone], fax [phone], cell [phone]
[e-mail], http://www.iD2tech.com 
Securing the Internet economy


Received: from rom.antech.de (dns.antech.de [194.45.12.2]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id IAA11461 for <[e-mail]>; Wed, 26 Jul 2000 08:32:25 -0700 (PDT)
Received: from scherbius.secorvo.de (scherbius.secorvo.de [194.45.12.219]) by rom.antech.de (8.9.3/8.9.3) with ESMTP id RAA10343 for <[e-mail]>; Wed, 26 Jul 2000 17:19:02 +0200
Message-Id: <[e-mail]>
From: "Stefan Kelm" <[e-mail]>
Organization: Secorvo Security Consulting GmbH
To: [e-mail]
Date: Wed, 26 Jul 2000 17:34:25 +0200
MIME-Version: 1.0
Content-type: text/plain; charset=US-ASCII
Content-transfer-encoding: 7BIT
Subject: Re: QC DN "qualities". Was: I-DACTION:draft-ietf-pkix-qc-04.txt
Priority: normal
In-reply-to: <[e-mail]>
X-mailer: Pegasus Mail for Win32 (v3.12b)

Denis,

> Should we really mandate the presence of the QC statement (as being
> the only way to indicate that a certificate is a QC) or should we
> also allow the use of pre-defined Certificate Policy OID (making the
> QC statement non mandatory) ?
> 
> I think both options should be mentioned as possible

I wholeheartedly agree with you. The QCStatement, as useful as
it might be, should not be mandatory.

Cheers,

	Stefan.


--------------------------------------------------------
PKI-Symposium, 10.-11.Oktober 2000, www.pki-symposium.de
--------------------------------------------------------
Dipl.-Inform. Stefan Kelm
Security Consultant

Secorvo Security Consulting GmbH
Albert-Nestler-Strasse 9, D-76131 Karlsruhe

Tel. [phone], Fax [phone]
E-Mail [e-mail], http://www.secorvo.de
-------------------------------------------------------
PGP Fingerprint 87AE E858 CCBC C3A2 E633 D139 B0D9 212B


Received: from isis.wu-wien.ac.at (isis.wu-wien.ac.at [137.208.3.42]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id HAA07832 for <[e-mail]>; Wed, 26 Jul 2000 07:58:27 -0700 (PDT)
Received: from gourmet.wu-wien.ac.at ([e-mail] [137.208.224.124]) by isis.wu-wien.ac.at (8.8.7/8.8.7) with SMTP id RAA59374emf [e-mail]; Wed, 26 Jul 2000 17:01:37 +0200
From: Michael Fritscher <[e-mail]>
Reply-To: [e-mail]
Organization: WU Wien
To: Juergen Brauckmann <[e-mail]>
Subject: RE: OCSP request
Date: Wed, 26 Jul 2000 16:52:05 +0200
X-Mailer: KMail [version 1.0.28]
Content-Type: text/plain
Cc: [e-mail]
References: <3.0.5.32.20000726164011.04531100@localhost>
In-Reply-To: <3.0.5.32.20000726164011.04531100@localhost>
MIME-Version: 1.0
Message-Id: <[e-mail]>
Content-Transfer-Encoding: 8bit

On Wed, 26 Jul 2000, Juergen Brauckmann wrote:
> At 07:20 26.07.00 -0700, Frank Balluffi wrote:
> >Juergen,
> >
> >If by an "expired crypto algorithm" you mean an algorithm that is known to
> >be insecure, then it may also not be possible to rely upon signed OCSP
> >responses. This sounds like a red herring to me.
> 
> Simple example: Certificate from 1990 with 512-bit RSA signature by the CA,
> OCSP Response with an up-to-date certificate with 1024 or 2048 bit RSA key. 
> 
> You cannot necessarily rely on the 512-bit signature, but you could rely
> upon the OCSP response signature.
> 

The problem in this context is not so much to be able to rely upon the
OCSP response, but rather that you may have a relyable OCSP response on a
certificate that can have been "easily faked" in the meantime...

Michael

-- 
------------------------------------------------------------
| Michael Fritscher	[e-mail]
| Department of Information Systems, New Media
| Vienna University of Economics and Business Administration
| http://wwwi.wu-wien.ac.at/people/Fritscher.html
| "A computer without windows NT is like a fish without a 
|  bicycle."
------------------------------------------------------------ 


Received: from ext-mail.valicert.com (ns1.valicert.com [63.65.221.10]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id HAA07536 for <[e-mail]>; Wed, 26 Jul 2000 07:53:01 -0700 (PDT)
Received: from CONVERSION-DAEMON.ext-mail.valicert.com by ext-mail.valicert.com (PMDF V6.0-24 #46243) id <[e-mail]> for [e-mail]; Wed, 26 Jul 2000 07:56:08 -0700 (PDT)
Received: from seine.valicert.com ([192.168.2.23]) by ext-mail.valicert.com (PMDF V6.0-24 #46243) with ESMTP id <[e-mail]>; Wed, 26 Jul 2000 07:56:07 -0700 (PDT)
Received: by seine.valicert.com with Internet Mail Service (5.5.2650.21) id <36007DRR>; Wed, 26 Jul 2000 07:47:37 -0700
Content-return: allowed
Date: Wed, 26 Jul 2000 07:47:35 -0700
From: Frank Balluffi <[e-mail]>
Subject: RE: OCSP request
To: "'Juergen Brauckmann'" <[e-mail]>, Frank Balluffi <[e-mail]>
Cc: [e-mail]
Message-id: <[e-mail]>
MIME-version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by ns.secondary.com id HAA07537

Juergen,

Thank you for the clarification. I assumed that you meant an OCSP response
from around the same time that the certificate was issued. In this case, the
use of red herring inappropriate.

In the case you described, why would the timestamper know to use a "chain of
timestamps with valid algorithms", but not the CA (i.e., use a valid
algorithm)? Just curious.

Frank

> -----Original Message-----
> From: Juergen Brauckmann [mailto:[e-mail]]
> Sent: Wednesday, July 26, 2000 10:40 AM
> To: Frank Balluffi
> Cc: [e-mail]
> Subject: RE: OCSP request
> 
> 
> At 07:20 26.07.00 -0700, Frank Balluffi wrote:
> >Juergen,
> >
> >If by an "expired crypto algorithm" you mean an algorithm 
> that is known to
> >be insecure, then it may also not be possible to rely upon 
> signed OCSP
> >responses. This sounds like a red herring to me.
> 
> Simple example: Certificate from 1990 with 512-bit RSA 
> signature by the CA,
> OCSP Response with an up-to-date certificate with 1024 or 
> 2048 bit RSA key. 
> 
> You cannot necessarily rely on the 512-bit signature, but you 
> could rely
> upon the OCSP response signature.
> 
> Juergen
> -- 
> Juergen Brauckmann             Tel.:  +49 (0)40 / 80 80 26-3 11
> TC TrustCenter GmbH            Fax.:  +49 (0)40 / 80 80 26-1 26
> Sonninstraße 24-28   	    mailto:[e-mail]
> D-20097 Hamburg 		    http://www.trustcenter.de	
> 


Received: from mail-fwd.verio-web.com (mail11a.verio-web.com [161.58.16.57]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id HAA07293 for <[e-mail]>; Wed, 26 Jul 2000 07:49:19 -0700 (PDT)
Received: from 161.58.117.181 (161.58.117.181) by mail11a.verio-web.com (RS ver 1.0.57s) with SMTP id 02121978; Wed, 26 Jul 2000 10:51:57 -0400 (EDT)
Sender: rsalz
Message-ID: <[e-mail]>
Date: Wed, 26 Jul 2000 10:52:18 -0400
From: Rich Salz <[e-mail]>
X-Mailer: Mozilla 4.72 [en] (X11; U; Linux 2.2.14-5.0 i686)
X-Accept-Language: en
MIME-Version: 1.0
To: Ambarish Malpani <[e-mail]>
CC: [e-mail]
Subject: Re: OCSP request
References: <[e-mail]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
X-Loop-Detect: 1

> I like the idea of asking a separate question about whether a
> cert is in a directory (or ever issued) and getting a separate
> answer for that.

But then you need something like draft-salzr-ldap-repsig to ensure that
nobody has tampered with, or interecepted the communications to/from,
the repository.
	/r$


Received: from mystic1.trustcenter.de (mystic1.trustcenter.de [193.194.157.34]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id HAA06819 for <[e-mail]>; Wed, 26 Jul 2000 07:38:37 -0700 (PDT)
Received: by mystic1.trustcenter.de; id QAA29986; Wed, 26 Jul 2000 16:39:30 +0200
Received: from nodnsquery(192.168.200.3) by mystic1.trustcenter.de via smap (V5.0) id xma029975; Wed, 26 Jul 00 16:38:33 +0200
Received: from ew-jbr (titan.trustcenter.de [192.168.200.244]) by callisto.trustcenter.de (8.9.3/8.9.3) with SMTP id QAA23740; Wed, 26 Jul 2000 16:40:11 +0200 (MET DST)
Message-Id: <3.0.5.32.20000726164011.04531100@localhost>
X-Sender: jbr@localhost
X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (32)
Date: Wed, 26 Jul 2000 16:40:11 +0200
To: Frank Balluffi <[e-mail]>
From: Juergen Brauckmann <[e-mail]>
Subject: RE: OCSP request
Cc: [e-mail]
In-Reply-To: <[e-mail] m>
Mime-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by ns.secondary.com id HAA06820

At 07:20 26.07.00 -0700, Frank Balluffi wrote:
>Juergen,
>
>If by an "expired crypto algorithm" you mean an algorithm that is known to
>be insecure, then it may also not be possible to rely upon signed OCSP
>responses. This sounds like a red herring to me.

Simple example: Certificate from 1990 with 512-bit RSA signature by the CA,
OCSP Response with an up-to-date certificate with 1024 or 2048 bit RSA key. 

You cannot necessarily rely on the 512-bit signature, but you could rely
upon the OCSP response signature.

Juergen
-- 
Juergen Brauckmann             Tel.:  +49 (0)40 / 80 80 26-3 11
TC TrustCenter GmbH            Fax.:  +49 (0)40 / 80 80 26-1 26
Sonninstraße 24-28   	    mailto:[e-mail]
D-20097 Hamburg 		    http://www.trustcenter.de	


Received: from ext-mail.valicert.com (ns1.valicert.com [63.65.221.10]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id HAA06264 for <[e-mail]>; Wed, 26 Jul 2000 07:26:01 -0700 (PDT)
Received: from CONVERSION-DAEMON.ext-mail.valicert.com by ext-mail.valicert.com (PMDF V6.0-24 #46243) id <[e-mail]> for [e-mail]; Wed, 26 Jul 2000 07:29:08 -0700 (PDT)
Received: from seine.valicert.com ([192.168.2.23]) by ext-mail.valicert.com (PMDF V6.0-24 #46243) with ESMTP id <[e-mail]>; Wed, 26 Jul 2000 07:29:07 -0700 (PDT)
Received: by seine.valicert.com with Internet Mail Service (5.5.2650.21) id <36007D35>; Wed, 26 Jul 2000 07:20:36 -0700
Content-return: allowed
Date: Wed, 26 Jul 2000 07:20:34 -0700
From: Frank Balluffi <[e-mail]>
Subject: RE: OCSP request
To: "'Juergen Brauckmann'" <[e-mail]>, Ambarish Malpani <[e-mail]>, "'Simon Tardell'" <[e-mail]>, "'Rich Salz'" <[e-mail]>
Cc: [e-mail]
Message-id: <[e-mail]>
MIME-version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by ns.secondary.com id HAA06265

Juergen,

If by an "expired crypto algorithm" you mean an algorithm that is known to
be insecure, then it may also not be possible to rely upon signed OCSP
responses. This sounds like a red herring to me.

Frank

> -----Original Message-----
> From: Juergen Brauckmann [mailto:[e-mail]]
> Sent: Wednesday, July 26, 2000 8:58 AM
> To: Ambarish Malpani; 'Simon Tardell'; 'Rich Salz'
> Cc: [e-mail]
> Subject: RE: OCSP request
> 
> 
> Ambarish, Simon,
> 
> I'm a member of the group that worked on the ISIS. Comments below... .
> 
> >> -----Original Message-----
> >> From: Simon Tardell [mailto:[e-mail]]
> >> Sent: Tuesday, July 25, 2000 8:45 AM
> >> To: 'Ambarish Malpani'; Simon Tardell; 'Rich Salz'; Joerg Seidel
> >> Cc: [e-mail]
> >> Subject: RE: OCSP request
> >>
> [...]
> >> Also, in your interpretation (and mine) "unknown" means "I 
> >> don't know or
> >> will not say". As a client a perfectly reasonable reaction to 
> >> that would be
> >> to come back and check later or go to another OCSP responder 
> >> (assuming I
> >> have a list to choose from) and query that responder. 
> 
> This means that a client *never* can get an authoritive 
> answer that the
> certificate is faked (by the way of a CA key compromise) 
> because a client
> has no way of knowing whether he talked to all OCSP 
> Responders that may
> know something about the certificate.
> 
> >> However, it is
> >> possible to interpret the "unknown" definition as an 
> >> assertion that "I know
> >> that this certificate is not issued". This is the 
> >> interpretation taken by
> >> the German Trust Center Work Group in their ISIS spec. 
> 
> RFC2560:
>    The "unknown" state indicates that the responder doesn't know about
>    the certificate being requested.
> 
> ISIS:
>    	"Such a reply means that the queried directory service 
> (SigG) cannot 
> 	provide information about this certificate, since it 
> was not issued 
> 	by the corresponding certification authority or was not 
> entered into 
> 	the directory service (SigG)."
> 
> Let me try to explain why we want to have "hard" responses 
> from directory
> services. The minimum requirements to OCSP in RFC2560 are 
> "weak" in the
> sense that there is only one real answer ("revoked") and two answers
> ("unknown" and "good") which basically mean "Hm, I'm not 
> sure". Minimum
> RFC2560-OCSP only provides blacklist functionality.
> 
> This is not sufficient for systems that must be 
> robust/tolerant against CA
> key compromise or such things. It is also not sufficient for long term
> validation of signatures, where you might have, e.g., a 
> signature and a
> certificate with an expired crypto algorithm, and a chain of 
> timestamps
> with valid algorithms, and where you want to verify the state of the
> certificate that made the signature. In this situation you 
> cannot rely on
> the certificate itself as an evidence that a CA ever issued 
> it, you must
> ask the CA.
> 
> In such systems a directory service must be able to give real 
> *positive*
> answers about certificates ("Yes, my CA issued this 
> certificate."). This
> means we need white lists. This can be done by using OCSP and 
> interpreting
> "unknown" as "The certificate was not issued by this CA", and by
> interpreting "good" as "The certificate was issued by this CA and not
> revoked".
> 
> 
> The semantics of "Good" is left rather unspecified in RFC2560, why
> shouldn't also "Unknown" be the subject of profile-specific
> interpretations? Why should that be "very, very wrong"?
> 
> Juergen
> -- 
> Juergen Brauckmann             Tel.:  +49 (0)40 / 80 80 26-3 11
> TC TrustCenter GmbH            Fax.:  +49 (0)40 / 80 80 26-1 26
> Sonninstraße 24-28   	    mailto:[e-mail]
> D-20097 Hamburg 		    http://www.trustcenter.de	
> 


Received: from ext-mail.valicert.com (ns1.valicert.com [63.65.221.10]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id HAA06114 for <[e-mail]>; Wed, 26 Jul 2000 07:24:25 -0700 (PDT)
Received: from CONVERSION-DAEMON.ext-mail.valicert.com by ext-mail.valicert.com (PMDF V6.0-24 #46243) id <[e-mail]> for [e-mail]; Wed, 26 Jul 2000 07:27:32 -0700 (PDT)
Received: from seine.valicert.com ([192.168.2.23]) by ext-mail.valicert.com (PMDF V6.0-24 #46243) with ESMTP id <[e-mail]>; Wed, 26 Jul 2000 07:27:31 -0700 (PDT)
Received: by seine.valicert.com with Internet Mail Service (5.5.2650.21) id <36007D3Y>; Wed, 26 Jul 2000 07:19:01 -0700
Content-return: allowed
Date: Wed, 26 Jul 2000 07:18:59 -0700
From: Ambarish Malpani <[e-mail]>
Subject: RE: OCSP request
To: "'Simon Tardell'" <[e-mail]>
Cc: [e-mail]
Message-id: <[e-mail]>
MIME-version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by ns.secondary.com id HAA06115

Hi Simon,
    Again, we mostly agree... :-)

I like the idea of asking a separate question about whether a
cert is in a directory (or ever issued) and getting a separate
answer for that.

However, I don't agree that the B-and-W approach taken by ISIS
is reasonable, because of the hole I talked about in my previous
mail.

Also, it is unclear that the "big bang" thing works where
somebody uses the compomised CA's private key to issue a cert to
an "imposter OCSP responder". Now, if a CA's key is compromised,
the client still won't know, because it will see an OCSP response
issued by an apparantly legitimate responder [unless you insist
on the Direct Trust model in OCSP].



---------------------------------------------------------------------
Ambarish Malpani
Architect                                                650.567.5457
ValiCert, Inc.                                  [e-mail]
339 N. Bernardo Ave.                          http://www.valicert.com
Mountain View, CA 94043


> -----Original Message-----
> From: Simon Tardell [mailto:[e-mail]]
> Sent: Wednesday, July 26, 2000 7:16 AM
> To: 'Juergen Brauckmann'; Ambarish Malpani; Simon Tardell; 'Rich Salz'
> Cc: [e-mail]
> Subject: RE: OCSP request
> 
> 
> Jürgen,
> 
> The black-list AND white-list approach taken by German 
> signature legislation
> is good by me. It addresses the potential "big-bang" of CA 
> key compromise in
> ways that are reasonable. However, I don't think you need to 
> change OCSP
> semantics to do this. I see the German ISIS OCSP variety as a 
> change rather
> than a profile, because an OCSP client has to behave differently when
> talking to an ISIS OCSP responder than when talking to a world OCSP
> responder.
>  
> > The semantics of "Good" is left rather unspecified in RFC2560, why
> > shouldn't also "Unknown" be the subject of profile-specific
> > interpretations? Why should that be "very, very wrong"?
> 
> One problem with altering the definition of "unknown" from "I 
> don't know" to
> the assertion "I know this certificate has not been issued" 
> is that you may
> have several OCSP responders to choose from (for availability 
> reasons) and
> if one of them is unable to answer one or more of the 
> requests in an OCSP
> request, it should be possible to go down the list, or come 
> back later. If
> you don't distinguish between the "no" and "???" answer, you 
> don't have that
> possibility. Even if an ISIS compliant PKI may not use this, 
> the end-user
> may be part of other PKIs that do, and it'd be convenient to 
> be able to use
> the same clients.
> 
> Basically there are two independent assertions: revoked - 
> yes/no/don't-know
> and issued - yes/no/don't-know. My suggestion is to treat 
> them on equal
> footing. Restrict CertStatus to represent the first assertion
> (yes/no/don't-know on revocation) and introduce an extension 
> for the second
> assertion ("being inserted into the directory (SigG)") with the same
> structure (yes/no/don't-know). Let this extension be critical 
> if the value
> is "no" or "don't-know". In this way, non-ISIS compliant 
> clients will work
> together with ISIS PKIs and vice versa, without losses. Of 
> course, some
> combinations are unreasonable (you hardly revoke a 
> certificate that was
> never issued) or may be disallowed by policy (maybe the 
> "don't-know" answers
> are not possible due to policy).
> 
> Orthogonality between assertions means that further 
> assertions ("was valid
> at time X" was suggested) can be introduced in the same 
> manner, without
> breaking unaware clients. That is probably the biggest advantage.
> 
> One more comment:
> 
> > >> Also, in your interpretation (and mine) "unknown" means 
> "I don't know
> or
> > >> will not say". As a client a perfectly reasonable 
> reaction to  that
> would be
> > >> to come back and check later or go to another OCSP 
> responder (assuming
> I
> > >> have a list to choose from) and query that responder. 
> > 
> > This means that a client *never* can get an authoritive 
> answer that the
> > certificate is faked (by the way of a CA key compromise) 
> because a client
> > has no way of knowing whether he talked to all OCSP 
> Responders that may
> > know something about the certificate.
> 
> Sure he can. It's a matter of policy. Since you can't trust 
> the list of
> responders in the AIA extension (because you fear CA key 
> compromise) you
> have to have a hard-coded list. This is true whether you 
> allow for one or
> several responders.
> 
> Regards,
> 
> Simon
> 
>  
> Simon Tardell, Software Architect, iD2 Technologies
> voice [phone], fax [phone], cell [phone]
> [e-mail], http://www.iD2tech.com
> Securing the Internet economy
>  
> 


Received: from ext-mail.valicert.com (ns1.valicert.com [63.65.221.10]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id HAA05514 for <[e-mail]>; Wed, 26 Jul 2000 07:16:08 -0700 (PDT)
Received: from CONVERSION-DAEMON.ext-mail.valicert.com by ext-mail.valicert.com (PMDF V6.0-24 #46243) id <[e-mail]> for [e-mail]; Wed, 26 Jul 2000 07:19:15 -0700 (PDT)
Received: from seine.valicert.com ([192.168.2.23]) by ext-mail.valicert.com (PMDF V6.0-24 #46243) with ESMTP id <[e-mail]>; Wed, 26 Jul 2000 07:19:15 -0700 (PDT)
Received: by seine.valicert.com with Internet Mail Service (5.5.2650.21) id <36007D3M>; Wed, 26 Jul 2000 07:10:44 -0700
Content-return: allowed
Date: Wed, 26 Jul 2000 07:10:43 -0700
From: Ambarish Malpani <[e-mail]>
Subject: RE: OCSP request
To: "'Juergen Brauckmann'" <[e-mail]>
Cc: [e-mail]
Message-id: <[e-mail]>
MIME-version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-type: text/plain; charset=iso-8859-1
Content-transfer-encoding: 8BIT

Hi Juergen,

    A few issues:

1. OCSP responses are not meant to be weak at all. The meaning of
good is "not revoked" or "still good" (as long as the certificate
was correctly issued and hadn't expired before the ArchiveCutoff
date).

2. The meaning on unknown is "I don't know [or am not saying]"

By changing these meanings, you do the following:
a. You aren't doing OCSP any more - at least not as most of the
rest of the world interprets it. The problem you might run into,
is say, somebody builds an ISIS OCSP server and somebody else
tries to use it with say a Netscape Communicator OCSP client. The
two products will claim to talk OCSP, but will actually be saying
different things in their requests and responses and nobody else
will ever know.

b. The reason why the change ISIS has proposed is "wrong" is:
In an OCSP request, you identify a cert by the hash of the CA's
public key [and the hash of the CA's name] and the certificate
serial number. If somebody had compromised the CA's public key,
all they would need to do, is create a new certificate with a
serial number that corresponds to a legitimate serial number, but
a different subject public key and there goes the ability of the
OCSP responder to tell you anything useful.

Part of why it is valuable to at least pose desires to change the
interpretations of RFCs on this kind of a list, is you might
actually get some useful input from others, who might think about
a problem in different ways.

Does that make sense?

Regards,
Ambarish

P.S. Again, if you do pose the problems you want to solve, there
might be other reasonable ways of extending OCSP [within the
framework of the protocol], that might better fit in with the RFC
itself.

A

---------------------------------------------------------------------
Ambarish Malpani
Architect                                                650.567.5457
ValiCert, Inc.                                  [e-mail]
339 N. Bernardo Ave.                          http://www.valicert.com
Mountain View, CA 94043


> -----Original Message-----
> From: Juergen Brauckmann [mailto:[e-mail]]
> Sent: Wednesday, July 26, 2000 5:58 AM
> To: Ambarish Malpani; 'Simon Tardell'; 'Rich Salz'
> Cc: [e-mail]
> Subject: RE: OCSP request
> 
> 
> Ambarish, Simon,
> 
> I'm a member of the group that worked on the ISIS. Comments below... .
> 
> >> -----Original Message-----
> >> From: Simon Tardell [mailto:[e-mail]]
> >> Sent: Tuesday, July 25, 2000 8:45 AM
> >> To: 'Ambarish Malpani'; Simon Tardell; 'Rich Salz'; Joerg Seidel
> >> Cc: [e-mail]
> >> Subject: RE: OCSP request
> >>
> [...]
> >> Also, in your interpretation (and mine) "unknown" means "I 
> >> don't know or
> >> will not say". As a client a perfectly reasonable reaction to 
> >> that would be
> >> to come back and check later or go to another OCSP responder 
> >> (assuming I
> >> have a list to choose from) and query that responder. 
> 
> This means that a client *never* can get an authoritive 
> answer that the
> certificate is faked (by the way of a CA key compromise) 
> because a client
> has no way of knowing whether he talked to all OCSP 
> Responders that may
> know something about the certificate.
> 
> >> However, it is
> >> possible to interpret the "unknown" definition as an 
> >> assertion that "I know
> >> that this certificate is not issued". This is the 
> >> interpretation taken by
> >> the German Trust Center Work Group in their ISIS spec. 
> 
> RFC2560:
>    The "unknown" state indicates that the responder doesn't know about
>    the certificate being requested.
> 
> ISIS:
>    	"Such a reply means that the queried directory service 
> (SigG) cannot 
> 	provide information about this certificate, since it 
> was not issued 
> 	by the corresponding certification authority or was not 
> entered into 
> 	the directory service (SigG)."
> 
> Let me try to explain why we want to have "hard" responses 
> from directory
> services. The minimum requirements to OCSP in RFC2560 are 
> "weak" in the
> sense that there is only one real answer ("revoked") and two answers
> ("unknown" and "good") which basically mean "Hm, I'm not 
> sure". Minimum
> RFC2560-OCSP only provides blacklist functionality.
> 
> This is not sufficient for systems that must be 
> robust/tolerant against CA
> key compromise or such things. It is also not sufficient for long term
> validation of signatures, where you might have, e.g., a 
> signature and a
> certificate with an expired crypto algorithm, and a chain of 
> timestamps
> with valid algorithms, and where you want to verify the state of the
> certificate that made the signature. In this situation you 
> cannot rely on
> the certificate itself as an evidence that a CA ever issued 
> it, you must
> ask the CA.
> 
> In such systems a directory service must be able to give real 
> *positive*
> answers about certificates ("Yes, my CA issued this 
> certificate."). This
> means we need white lists. This can be done by using OCSP and 
> interpreting
> "unknown" as "The certificate was not issued by this CA", and by
> interpreting "good" as "The certificate was issued by this CA and not
> revoked".
> 
> 
> The semantics of "Good" is left rather unspecified in RFC2560, why
> shouldn't also "Unknown" be the subject of profile-specific
> interpretations? Why should that be "very, very wrong"?
> 
> Juergen
> -- 
> Juergen Brauckmann             Tel.:  +49 (0)40 / 80 80 26-3 11
> TC TrustCenter GmbH            Fax.:  +49 (0)40 / 80 80 26-1 26
> Sonninstraße 24-28   	    mailto:[e-mail]
> D-20097 Hamburg 		    http://www.trustcenter.de	
> 


Received: from naigwy (void1.ausys.se [62.20.78.253]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id HAA05361 for <[e-mail]>; Wed, 26 Jul 2000 07:13:48 -0700 (PDT)
Received: FROM aunt15.ausys.se BY naigwy ; Wed Jul 26 16:14:55 2000 +0200
Received: by aunt15.ausys.se with Internet Mail Service (5.5.2650.21) id <PLMLF8VK>; Wed, 26 Jul 2000 16:16:21 +0200
Message-ID: <[e-mail]>
From: Simon Tardell <[e-mail]>
To: "'Juergen Brauckmann'" <[e-mail]>, Ambarish Malpani <[e-mail]>, Simon Tardell <[e-mail]>, "'Rich Salz'" <[e-mail]>
Cc: [e-mail]
Subject: RE: OCSP request
Date: Wed, 26 Jul 2000 16:16:10 +0200
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by ns.secondary.com id HAA05369

Jürgen,

The black-list AND white-list approach taken by German signature legislation
is good by me. It addresses the potential "big-bang" of CA key compromise in
ways that are reasonable. However, I don't think you need to change OCSP
semantics to do this. I see the German ISIS OCSP variety as a change rather
than a profile, because an OCSP client has to behave differently when
talking to an ISIS OCSP responder than when talking to a world OCSP
responder.
 
> The semantics of "Good" is left rather unspecified in RFC2560, why
> shouldn't also "Unknown" be the subject of profile-specific
> interpretations? Why should that be "very, very wrong"?

One problem with altering the definition of "unknown" from "I don't know" to
the assertion "I know this certificate has not been issued" is that you may
have several OCSP responders to choose from (for availability reasons) and
if one of them is unable to answer one or more of the requests in an OCSP
request, it should be possible to go down the list, or come back later. If
you don't distinguish between the "no" and "???" answer, you don't have that
possibility. Even if an ISIS compliant PKI may not use this, the end-user
may be part of other PKIs that do, and it'd be convenient to be able to use
the same clients.

Basically there are two independent assertions: revoked - yes/no/don't-know
and issued - yes/no/don't-know. My suggestion is to treat them on equal
footing. Restrict CertStatus to represent the first assertion
(yes/no/don't-know on revocation) and introduce an extension for the second
assertion ("being inserted into the directory (SigG)") with the same
structure (yes/no/don't-know). Let this extension be critical if the value
is "no" or "don't-know". In this way, non-ISIS compliant clients will work
together with ISIS PKIs and vice versa, without losses. Of course, some
combinations are unreasonable (you hardly revoke a certificate that was
never issued) or may be disallowed by policy (maybe the "don't-know" answers
are not possible due to policy).

Orthogonality between assertions means that further assertions ("was valid
at time X" was suggested) can be introduced in the same manner, without
breaking unaware clients. That is probably the biggest advantage.

One more comment:

> >> Also, in your interpretation (and mine) "unknown" means "I don't know
or
> >> will not say". As a client a perfectly reasonable reaction to  that
would be
> >> to come back and check later or go to another OCSP responder (assuming
I
> >> have a list to choose from) and query that responder. 
> 
> This means that a client *never* can get an authoritive answer that the
> certificate is faked (by the way of a CA key compromise) because a client
> has no way of knowing whether he talked to all OCSP Responders that may
> know something about the certificate.

Sure he can. It's a matter of policy. Since you can't trust the list of
responders in the AIA extension (because you fear CA key compromise) you
have to have a hard-coded list. This is true whether you allow for one or
several responders.

Regards,

Simon

 
Simon Tardell, Software Architect, iD2 Technologies
voice [phone], fax [phone], cell [phone]
[e-mail], http://www.iD2tech.com
Securing the Internet economy
 


Received: from mystic1.trustcenter.de (mystic1.trustcenter.de [193.194.157.34]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id FAA00428 for <[e-mail]>; Wed, 26 Jul 2000 05:55:28 -0700 (PDT)
Received: by mystic1.trustcenter.de; id OAA29055; Wed, 26 Jul 2000 14:56:20 +0200
Received: from nodnsquery(192.168.200.3) by mystic1.trustcenter.de via smap (V5.0) id xma029044; Wed, 26 Jul 00 14:56:16 +0200
Received: from ew-jbr (titan.trustcenter.de [192.168.200.244]) by callisto.trustcenter.de (8.9.3/8.9.3) with SMTP id OAA17975; Wed, 26 Jul 2000 14:57:55 +0200 (MET DST)
Message-Id: <3.0.5.32.20000726145755.03772bc0@localhost>
X-Sender: jbr@localhost
X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (32)
Date: Wed, 26 Jul 2000 14:57:55 +0200
To: Ambarish Malpani <[e-mail]>, "'Simon Tardell'" <[e-mail]>, "'Rich Salz'" <[e-mail]>
From: Juergen Brauckmann <[e-mail]>
Subject: RE: OCSP request
Cc: [e-mail]
In-Reply-To: <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by ns.secondary.com id FAA00429

Ambarish, Simon,

I'm a member of the group that worked on the ISIS. Comments below... .

>> -----Original Message-----
>> From: Simon Tardell [mailto:[e-mail]]
>> Sent: Tuesday, July 25, 2000 8:45 AM
>> To: 'Ambarish Malpani'; Simon Tardell; 'Rich Salz'; Joerg Seidel
>> Cc: [e-mail]
>> Subject: RE: OCSP request
>>
[...]
>> Also, in your interpretation (and mine) "unknown" means "I 
>> don't know or
>> will not say". As a client a perfectly reasonable reaction to 
>> that would be
>> to come back and check later or go to another OCSP responder 
>> (assuming I
>> have a list to choose from) and query that responder. 

This means that a client *never* can get an authoritive answer that the
certificate is faked (by the way of a CA key compromise) because a client
has no way of knowing whether he talked to all OCSP Responders that may
know something about the certificate.

>> However, it is
>> possible to interpret the "unknown" definition as an 
>> assertion that "I know
>> that this certificate is not issued". This is the 
>> interpretation taken by
>> the German Trust Center Work Group in their ISIS spec. 

RFC2560:
   The "unknown" state indicates that the responder doesn't know about
   the certificate being requested.

ISIS:
   	"Such a reply means that the queried directory service (SigG) cannot 
	provide information about this certificate, since it was not issued 
	by the corresponding certification authority or was not entered into 
	the directory service (SigG)."

Let me try to explain why we want to have "hard" responses from directory
services. The minimum requirements to OCSP in RFC2560 are "weak" in the
sense that there is only one real answer ("revoked") and two answers
("unknown" and "good") which basically mean "Hm, I'm not sure". Minimum
RFC2560-OCSP only provides blacklist functionality.

This is not sufficient for systems that must be robust/tolerant against CA
key compromise or such things. It is also not sufficient for long term
validation of signatures, where you might have, e.g., a signature and a
certificate with an expired crypto algorithm, and a chain of timestamps
with valid algorithms, and where you want to verify the state of the
certificate that made the signature. In this situation you cannot rely on
the certificate itself as an evidence that a CA ever issued it, you must
ask the CA.

In such systems a directory service must be able to give real *positive*
answers about certificates ("Yes, my CA issued this certificate."). This
means we need white lists. This can be done by using OCSP and interpreting
"unknown" as "The certificate was not issued by this CA", and by
interpreting "good" as "The certificate was issued by this CA and not
revoked".


The semantics of "Good" is left rather unspecified in RFC2560, why
shouldn't also "Unknown" be the subject of profile-specific
interpretations? Why should that be "very, very wrong"?

Juergen
-- 
Juergen Brauckmann             Tel.:  +49 (0)40 / 80 80 26-3 11
TC TrustCenter GmbH            Fax.:  +49 (0)40 / 80 80 26-1 26
Sonninstraße 24-28   	    mailto:[e-mail]
D-20097 Hamburg 		    http://www.trustcenter.de	


Received: from sonne.darmstadt.gmd.de (sonne.darmstadt.gmd.de [141.12.62.20]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id EAA27352 for <[e-mail]>; Wed, 26 Jul 2000 04:56:53 -0700 (PDT)
Received: from secude.com ([141.12.207.27]) by sonne.darmstadt.gmd.de (8.8.8/8.8.5) with ESMTP id NAA02114; Wed, 26 Jul 2000 13:59:24 +0200 (MET DST)
Message-ID: <[e-mail]>
Date: Wed, 26 Jul 2000 13:59:12 +0200
From: Hans Schupp <[e-mail]>
Organization: SECUDE GmbH
X-Mailer: Mozilla 4.7 [de] (WinNT; U)
X-Accept-Language: de
MIME-Version: 1.0
To: [e-mail]
Subject: CRMF problems
Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms318D14A5D9E1A9AD9E371545"

Dies ist eine kryptographisch unterzeichnete Nachricht im MIME-Format.

--------------ms318D14A5D9E1A9AD9E371545
Content-Type: multipart/mixed;
 boundary="------------E34C9A8BC25B1F7F047294CE"

Dies ist eine mehrteilige Nachricht im MIME-Format.
--------------E34C9A8BC25B1F7F047294CE
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Hello,

we just stepped over some possible problems with CRMF regInfo encoding.

The format of the regInfo-utf8Pairs value is defined in appendix B.1 to
be "[name?value][%name?value]*%", i.e. the percent sign is the delimiter
of each pair.

Two sentences later, the percent sign is "overloaded" to be used in the
escaping of reserved characters (with reference to URL-encoding).

IMHO this is a serious mistake and doesn't really work.
Is there already a fix/amendment, or did nobody come across this
problem  yet?

Why was such a kludge-like solution ([UTF-8]-encoding inside
[ASN.1]-encoding) chosen in the first place?

best regards,
Hans Schupp

PS: In RFC 2511, there is a slight inconsistency regarding the naming of
the following OID:
The first definition is
  id-regInfo-asciiPairs    OBJECT IDENTIFIER ::= { id-regInfo 1 }
later, it's defined as
  id-regInfo-utf8Pairs    OBJECT IDENTIFIER ::= { id-regInfo 1 }
--------------E34C9A8BC25B1F7F047294CE
Content-Type: text/x-vcard; charset=us-ascii;
 name="schupp.vcf"
Content-Transfer-Encoding: 7bit
Content-Description: Visitenkarte für Hans Schupp
Content-Disposition: attachment;
 filename="schupp.vcf"

begin:vcard 
n:Schupp;Hans
tel;cell:(+49) 177 / 2452088 (private)
tel;fax:(+49) 6151 / 82897 - 26
tel;work:(+49) 6151 / 82897 - 37
x-mozilla-html:FALSE
url:http://www.secude.com
org:<hr size=1><p align=right><b><font color=green>SECUDE</font></b> <i>Sicherheitstechnologie<br>Informationssysteme GmbH<br><font color=green>e-security for e-business</font></i>
version:2.1
email;internet:[e-mail]
adr;quoted-printable:;;NEW ADDRESS:=0D=0ADolivostr. 11=0D=0A;Darmstadt;;D-64293;Germany
fn:Hans Schupp
end:vcard

--------------E34C9A8BC25B1F7F047294CE--

--------------ms318D14A5D9E1A9AD9E371545
Content-Type: application/x-pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: Kryptographische Unterschrift mit S/MIME

MIIFGAYJKoZIhvcNAQcCoIIFCTCCBQUCAQExCzAJBgUrDgMCGgUAMAsGCSqGSIb3DQEHAaCC
AzEwggMtMIICFaADAgECAgFOMA0GCSqGSIb3DQEBBQUAMFAxCzAJBgNVBAYTAkRFMRQwEgYD
VQQKEwtTRUNVREUgR21iSDErMCkGA1UECxMiU0VDVURFIFRydXN0RmFjdG9yeSBJbmRpdmlk
dWFscyBDQTAeFw05OTEwMjgxNTI2MzNaFw0wMTEwMjgxNTI2MzNaMDkxCzAJBgNVBAYTAkRF
MRQwEgYDVQQKEwtTRUNVREUgR21iSDEUMBIGA1UEAxMLSGFucyBTY2h1cHAwgZ8wDQYJKoZI
hvcNAQEBBQADgY0AMIGJAoGBAP4CQoNsxm0rCW/ncYHxEGE9H4IStq2k0sAUJrKzBXvA1gkn
c1jrMoQDEORcPjdIVoppbgt4xcmGz59GbGzrHQLDYX4wWtbpeuRQ5p//Dpw+ilA+dfH2WvOi
v/OT4q04anv4tI1bHmfHjX0K/T9JoWJNduV1mhhBOvi+G/XG6VgjAgMBAAGjgawwgakwDgYD
VR0PAQH/BAQDAgTwMBwGA1UdEQQVMBOBEXNjaHVwcEBzZWN1ZGUuY29tMFgGA1UdEgRRME+B
F3RydXN0ZmFjdG9yeUBzZWN1ZGUuY29thjRodHRwOi8vd3d3LnNlY3VkZS5jb20vdHJ1c3Rm
YWN0b3J5L2luZGl2aWR1YWxzY2EuY3J0MAwGA1UdEwEB/wQCMAAwEQYJYIZIAYb4QgEBBAQD
AgCgMA0GCSqGSIb3DQEBBQUAA4IBAQDB4naym+cwkZ9vjIIAJzoiNzsuywA1QiSElOnfnADa
dD7NH3DyfRGjI5sjZBKpFuj2GDHXQBQnZikMxWI1H/J14IyZhv8CORIli8OboSfjavpMlQiJ
oQOzO8FDk0j2dJBhOsBxkhGoO/GxTMy+xOdFHsBWsHHyQAFWlgdaCSPrgpq9fSDZ8+Kt5XIj
pkyiWjkwnGr7espfevPB1weHlrO5tmD+KFKyVZ+cuDjf0ABAQDXP29HFWxve246Ga2SBnv0Y
DTdDfIpVkeHbPd9n8LPGte7MNxM4s2GSJ7lY+p/z33TW0na+ZNmhdhaz8jmXSI/BP0Qvjy/b
xKYfAKwvBFvLMYIBrzCCAasCAQEwVTBQMQswCQYDVQQGEwJERTEUMBIGA1UEChMLU0VDVURF
IEdtYkgxKzApBgNVBAsTIlNFQ1VERSBUcnVzdEZhY3RvcnkgSW5kaXZpZHVhbHMgQ0ECAU4w
CQYFKw4DAhoFAKCBsTAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEP
Fw0wMDA3MjYxMTU5MTdaMCMGCSqGSIb3DQEJBDEWBBQ3cey2tgXZCVRDBvvEmzU46MjdozBS
BgkqhkiG9w0BCQ8xRTBDMAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIAgDAHBgUrDgMCBzAN
BggqhkiG9w0DAgIBQDANBggqhkiG9w0DAgIBKDANBgkqhkiG9w0BAQEFAASBgEptbGKbSUHu
zvMdBL3YQzrS/AHOPa1NBjnL6hBoXqLewnrWTvbUq474Efs8KOUk+PNl7txTFAUpL1EEzmZ3
zNs3WDubqm7YULuaqZ32ofTaqzvsoJN9S5esIZAyuLcDadCdIA/jjgTuCIYrgEs5190tosQg
sihv4OPLsQJ5wP9K
--------------ms318D14A5D9E1A9AD9E371545--



Received: from odin2.bull.net (odin2.bull.net [192.90.70.84]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id AAA13396 for <[e-mail]>; Wed, 26 Jul 2000 00:24:45 -0700 (PDT)
Received: from lvt-mail.frlv.bull.fr (lvt-mail.frlv.bull.fr [129.184.62.223]) by odin2.bull.net (8.9.3/8.9.3) with ESMTP id JAA42032; Wed, 26 Jul 2000 09:31:41 +0200
Received: from bull.net (frpq6118.frpq.bull.fr [129.184.8.64]) by lvt-mail.frlv.bull.fr (8.9.2/8.9.1) with ESMTP id JAA40478; Wed, 26 Jul 2000 09:27:13 +0200
Message-ID: <[e-mail]>
Date: Wed, 26 Jul 2000 09:27:14 +0200
From: Denis Pinkas <[e-mail]>
Organization: Bull
X-Mailer: Mozilla 4.7 [fr] (Win98; I)
X-Accept-Language: fr
MIME-Version: 1.0
To: Ambarish Malpani <[e-mail]>
CC: "'Simon Tardell'" <[e-mail]>, "'Rich Salz'" <[e-mail]>, Joerg Seidel <[e-mail]>, [e-mail]
Subject: Re: OCSP request
References: <[e-mail]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Ambarish,

> Hi Simon,
>     Yes, we do, violently agree!
> 
> I didn't know of the German ISIS interpretation of "unknown". That
> is *not* the interpretation that any other group is taking. Do
> you know who I can contact to help sort this out? I think it is
> very, very wrong!

I support your last assertion. As you stated "unknown" means "I
don't know or will not say". This means I also agree with Simon. :-)

Denis

> Given this interpretation, I agree, the
> wording could and should have been more explicit.
> 
> Regards,
> Ambarish
> 
> ---------------------------------------------------------------------
> Ambarish Malpani
> Architect                                                650.567.5457
> ValiCert, Inc.                                  [e-mail]
> 339 N. Bernardo Ave.                          http://www.valicert.com
> Mountain View, CA 94043
> 
> > -----Original Message-----
> > From: Simon Tardell [mailto:[e-mail]]
> > Sent: Tuesday, July 25, 2000 8:45 AM
> > To: 'Ambarish Malpani'; Simon Tardell; 'Rich Salz'; Joerg Seidel
> > Cc: [e-mail]
> > Subject: RE: OCSP request
> >
> >
> > Ambarish,
> >
> > Let me just start by pointing out that I agree with you
> > (mostly). But not
> > everybody agrees with me....
> >
> > > Hi Simon,
> > >     Here is the text from RFC 2560:
> > >
> > > ---------------Start quote from RFC----------------------
> > >  The "good" state indicates a positive response to the
> > status inquiry.
> > >    At a minimum, this positive response indicates that the
> > certificate
> > >    is not revoked, but does not necessarily mean that the
> > certificate
> > >    was ever issued or that the time at which the response
> > was produced
> > >    is within the certificate's validity interval. Response
> > extensions
> > >    may be used to convey additional information on
> > assertions made by
> > >    the responder regarding the status of the certificate such as
> > >    positive statement about issuance, validity, etc.
> > >
> > >    The "revoked" state indicates that the certificate has
> > been revoked
> > >    (either permanantly or temporarily (on hold)).
> > >
> > >    The "unknown" state indicates that the responder doesn't
> > know about
> > >    the certificate being requested.
> > >
> > > ---------------End quote from RFC----------------------
> > >
> > >
> > > Good means that it is not on the revoked list. If you wish to
> > > assert other things, you can do so with extensions.
> > >
> > > Revoked means that it is on the revoked list (you can still assert
> > > other things with extensions - nothing says you can't do that,
> > > although I agree, it would have been better to say so explicitly.
> > >
> > > Unknown means you don't know - aren't willing to say either good
> > > or bad (again, you can still use extensions to say more things).
> > >
> > > I am not sure which part of the language you are objecting
> > > to.
> >
> > The problem I have is that a responder may through "good"
> > assert that any
> > number properties are true, *without* qualifying with
> > extensions. On the
> > other hand "revoked" means a negative assertion to only one of these
> > properties.
> >
> > Also, in your interpretation (and mine) "unknown" means "I
> > don't know or
> > will not say". As a client a perfectly reasonable reaction to
> > that would be
> > to come back and check later or go to another OCSP responder
> > (assuming I
> > have a list to choose from) and query that responder. However, it is
> > possible to interpret the "unknown" definition as an
> > assertion that "I know
> > that this certificate is not issued". This is the
> > interpretation taken by
> > the German Trust Center Work Group in their ISIS spec. Under those
> > semantics, I can't expect any other responder to have better
> > information.
> >
> > > Would it have
> > > been satisfactory if we had the line starting "Response
> > extensions...
> > > validity, etc." in each of the 3 states? Would you have
> > > preferred that we not have allowed for any extensions in responses?
> >
> > The preferred way would have been to restrict CertStatus to carry
> > information only on revocation and force issuance, validity
> > or any other
> > property that you want to assert into extensions. Preferrably those
> > extensions should have the same structure (assertion true,
> > assertion false,
> > i-don't-know).
> >
> > Simon.
> >
> >
> > Simon Tardell, Software Architect, iD2 Technologies
> > voice [phone], fax [phone], cell [phone]
> > [e-mail], http://www.iD2tech.com
> > Securing the Internet economy
> >


Received: from iaik.tu-graz.ac.at (excalibur.iaik.tu-graz.ac.at [129.27.152.30]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id AAA11362 for <[e-mail]>; Wed, 26 Jul 2000 00:05:55 -0700 (PDT)
Received: from hades [129.27.152.143] by iaik.tu-graz.ac.at (SMTPD32-6.00) id AE8B87D013C; Wed, 26 Jul 2000 09:08:59 +0200
Received: from localhost [127.0.0.1] by hades (IAIK S/MIME Mapper 2.0beta1 14/January/2000); Wed, 26 Jul 2000 09:08:24 +0100
From: "Karl Scheibelhofer" <[e-mail]>
To: "IETF PKIX Mailing List" <[e-mail]>
Subject: OCSP request
Date: Wed, 26 Jul 2000 09:08:23 +0200
Message-ID: <[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0)
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400
Importance: Normal

if a certificate can only have the simple histories (issue)-valid-expired
and (issue)-valid-revoked, there is no problem. generalized: when a
certificate becomes invalid (revoked or expired) it remains invalid forever.
but, if a certificate can be suspended (= invalid for some time), i cannot
use OCSP as is to find that out later on when the certificate is no longer
suspended.

what i would like to have:
from the client's point of view, i want to ask the OCSP server: was this
certificate valid during the whole time interval [t1,t2]?
in case of successful processing of request the server should respone:

- certificate was valid during whole time interval [t1,t2]
- certificate was invalid during whole time interval [t1,t2], because of
(revocation,suspension,...)
- status of certificate changed during time interval [t1,t2], type of change
was (valid-suspended, valid-revoked, suspended-valid, ...)

in case of unsuccessful processing the server should tell the reason
(certificate unknown, , unsupported certificate format, internal error,...)

this approach would support any life-cycle of certificates.
by now, it seems to me that a lot of protocols assume implicitly that
certificates can become invalid just once, and once they are invalid they
can never become valid once again. i agree that this is mostly the case.

does this idea also make sense to others?

best regards,

  Karl Scheibelhofer

--

Karl Scheibelhofer, <mailto:[e-mail]>
Institute for Applied Information Processing and Communications (IAIK)
at Technical University of Graz, Austria, http://www.iaik.at
Phone: (+43) [phone]



Received: from odin2.bull.net (odin2.bull.net [192.90.70.84]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id XAA10754 for <[e-mail]>; Tue, 25 Jul 2000 23:54:43 -0700 (PDT)
Received: from lvt-mail.frlv.bull.fr (lvt-mail.frlv.bull.fr [129.184.62.223]) by odin2.bull.net (8.9.3/8.9.3) with ESMTP id JAA42992; Wed, 26 Jul 2000 09:01:32 +0200
Received: from bull.net (frpq6118.frpq.bull.fr [129.184.8.64]) by lvt-mail.frlv.bull.fr (8.9.2/8.9.1) with ESMTP id IAA19240; Wed, 26 Jul 2000 08:57:01 +0200
Message-ID: <[e-mail]>
Date: Wed, 26 Jul 2000 08:57:02 +0200
From: Denis Pinkas <[e-mail]>
Organization: Bull
X-Mailer: Mozilla 4.7 [fr] (Win98; I)
X-Accept-Language: fr
MIME-Version: 1.0
To: Oscar Jacobsson <[e-mail]>
CC: Joerg Seidel <[e-mail]>, [e-mail]
Subject: Re: OCSP request
References: <3.0.5.32.20000725152251.00aac160@localhost> <3.0.5.32.20000725155017.03aee580@localhost> <[e-mail]> <[e-mail]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Oscar,

> Joerg Seidel wrote:
> > Or as Karl puts it you need "to
> > attach all this verification stuff to all signed documents."
> 
> Which is the method ETSI have selected for their ES-C (Electronic
> Signature with Complete validation data) electronic signature format,
> IIRC.

To reply to your question, ETSI (in ES 201733) has chosen to keep
the *references* (including a hash code of the referenced data)
together with the electronic signature, i.e. not the actual data.
The idea was to make the verification stuff kept with the signature
short.

The referenced data can be stored:

1) either with the signed message, or
2) anywhere else (e.g. in a data base), where you can find it again.

Denis

> //oscar


Received: from odin2.bull.net (odin2.bull.net [192.90.70.84]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id XAA09635 for <[e-mail]>; Tue, 25 Jul 2000 23:34:03 -0700 (PDT)
Received: from lvt-mail.frlv.bull.fr (lvt-mail.frlv.bull.fr [129.184.62.223]) by odin2.bull.net (8.9.3/8.9.3) with ESMTP id IAA35776; Wed, 26 Jul 2000 08:41:02 +0200
Received: from bull.net (frpq6118.frpq.bull.fr [129.184.8.64]) by lvt-mail.frlv.bull.fr (8.9.2/8.9.1) with ESMTP id IAA39494; Wed, 26 Jul 2000 08:36:30 +0200
Message-ID: <[e-mail]>
Date: Wed, 26 Jul 2000 08:36:31 +0200
From: Denis Pinkas <[e-mail]>
Organization: Bull
X-Mailer: Mozilla 4.7 [fr] (Win98; I)
X-Accept-Language: fr
MIME-Version: 1.0
To: Stefan Santesson <[e-mail]>
CC: [e-mail]
Subject: Re: QC DN "qualities". Was: I-DACTION:draft-ietf-pkix-qc-04.txt
References: <[e-mail]> <001201bff55f$457cac80$[e-mail]> <[e-mail]> <[e-mail]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Stefan,

> May I draw your attention to the updated QC 05 where the uniqueness
> requirement stated in RFC 2459 (and son of) has been clarified to count for
> the whole lifetime of the CA.
> 
> section 2.4 now states:
>     "The distinguished name MUST be unique for each subject
>     entity certified by the one CA as defined by the issuer name field,
>     during the whole life time of the CA."
> 
> This is actually nothing new, rather a clarification of the existing
> technical concept of DNs.
> An compliant implementation can simply not be based on CA's using the same
> DN for several different entities. It is reasonable to assume that this is
> the intent behind the original X.501 definition of DNs.
>     "Distinguished name is originally defined in X.501 [X.501] as a
>      representation of a directory name, defined as a construct that
>      identifies a particular object from among the set of all objects."


This is fine with me and solves one of the seven issues I have
posted on July 13 th. So COMMENT 1 is now solved. I re-post the six
other comments, which up to now have not yet been answered:

COMMENT 2

Section 3.1.1. Issuer states:  "The issuer field SHALL identify the
organization responsible for issuing the certificate, and SHALL
include a registered name of the organization".

The basic question is what is the meaning of a "registered" name.
Who should be the registration authority ? Do we have such an
authority for registered names in the IETF ? Is this authority
adequate for such a usage ? Instead of trying to answer the
question, it makes more sense to omit the second part of the
sentence which leads to the following sentence: "The issuer field
SHALL identify the organization responsible for issuing the
certificate".

COMMENT 3

Section 3.1.1. Issuer states:  "The legal jurisdiction for the
issuing CA SHOULD be consistent with the issuer name.". However the 
abstract says: "   The goal of this document is to define a general
syntax independent of local legal requirements." and also "It is
important to note that the profile does not define any legal
requirements for Qualified Certificates.". This is contradictory.

>From the discussions that recently took place in Stockholm, the
agreement was to mandate the inclusion of the country where from the
CA is operating. In this way, by indirection, the country where the
CA is established may implement a supervision scheme, if required.

The text should be modified to reflect this. It should be noticed
that taking this into consideration, the first element of a DN for
an issuer must then be a country name. This should be reflected in
the text.

Full text proposal replacement for 3.1.1:

3.1.1  Issuer

The issuer field SHALL identify the organization responsible for
issuing the certificate.

The identity of the issuer SHALL be specified using an appropriate
subset of the following attributes:

         domainComponent;
         countryName;
         stateOrProvinceName;
         organizationName;
         localityName; and
         serialNumber.

Additional attributes MAY be present but they SHOULD NOT be
necessary to identify the issuing organization. The first element of
the DN shall be the country where the CA is operating from.


COMMENT 4

The text is not consistent when talking about certificate policies
and public statements.

In section 2.2. Statement of Purpose, the text says:

"For a certificate to serve the purpose of being a Qualified
Certificate, this profile assumes that the CA will have to include
in the certificate a public statement that explicitly defines this
intent."

In section 3.2.2.Certificate Policies, the text says:

" A statement by the issuer stating the purpose of the certificate
as discussed in Section 2.2 SHOULD be evident through indicated
policies."

The later statement is not that "evident" at all, in particular
since from section 2.2. any certificate policy may be used, provided
that it is consistent with the policy for a QC.

The basic question is the following: How is it possible to know that
a certificate is a QC ?

There are two possible answers:

a) use a QC statement to tell it (and this "costs" a new extension),
b) use some pre-defined Certificate Policy OID to tell it (and this
costs no new extension).

The text from section 2.2. mandates the inclusion of a QC statement.
However, all current software is able to test for the presence of
any Certificate Policy OID in a certificate and thus the current
software could easily check for the presence of pre-defined
Certificate Policy OIDs for QCs. The QC statement mandates the use
of a new extension, that
no one has yet implemented, both for the construction of the
certificate and the checking of a certification path.

Should we really mandate the presence of the QC statement (as being
the only way to indicate that a certificate is a QC) or should we
also allow the use of pre-defined Certificate Policy OID (making the
QC statement non mandatory) ?

I think both options should be mentioned as possible

Note: I must recognise that the following text belonging to section
3.2.2 is not understandable to me:

" In order to enhance path validation based on policy object
identifiers any statement related to  Qualified Certificates, as
defined in 3.2.5, SHOULD also be defined by included certificate
policies."

COMMENT 5

Section 3.2.5. Qualified Certificate Statements, defines an
extension for inclusion of defined statements related to Qualified
Certificates. However, there is a major problem with the way the
extension is built. It is constructed as:

 QCStatements ::= SEQUENCE OF QCStatement

Since nothing is said in the text about the criticality this
extension is, by implication, non critical. This means that any
individual  QCStatement is not mandatory to understand. So unless an
application specifically looks for some pre-defined statement, it
will miss the others and is not required to "understand them. Also
remember that only ONE such extension may be present.

In a profile of this document (not a PKIX document) this extension
is being used to specify the maximum amount of money which is
permissible for one transaction, this is what is referred in QC-04
as "a maximum reliance limit for the certificate indicating
restrictions on CA's liability".

The basic question is whether we should have a separate extension
for a maximum reliance from a CA.

If the maximum reliance limit statement is part of the new
extension, there is no guarantee that it will ever be seen or
recognized. In principle any QCStatement in a non critical extension
may be ignored by the application.

If the maximum reliance limit statement is in a separate extension
marked critical, no application could miss it, if it is present.

The requirement comes from an annex of the European Directive. The
definition of a maximum reliance limit is optional and it makes
sense to have a dedicated extension to support it.

I would thus propose to suppress the following sentence from 3.2.5:
"As an example this MAY include a maximum reliance limit for the
certificate indicating restrictions on CA's liability."

Instead I would propose to define a separate extension to support a
maximum reliance limit.

COMMENT 6

Section 4, Security considerations. This section has major problems.
It uses some arguments to provide wrong conclusions. The current
text is as follows:

" Since the public keys are for public use with legal implications
for involved parties, certain conditions should exist before CAs
issues certificates as Qualified Certificates. The associated
private keys must be unique for the subject, and must be maintained
under the subject's sole control.  That is, a CA should not issue a
qualified certificate if the private key is shared among entities,
or the means to use the private key is not protected against
unintended usage. This implies that the CA must perform
proof-of-possession of the private key. In addition, it implies that
the CA have some knowledge about the subject's cryptographic
module."

The text says that a "CA should not issue a qualified certificate if
the private key is shared among entities". This is fine, but the CA
has no way to know whether the private key has been given to someone
else. Proof-of-possession of the private key does not solve the
issue as well, since everyone who has been given the private key
could provide proof-of-possession.

What is transparent from the text, but not said correctly, is that
if a physical device is used, then it becomes "more difficult" to
share the private key. Proposed text full replacement for the text
above:

"The private keys must be maintained under the subject's sole
control.  That is, a CA should not issue a qualified certificate if
the means to use the private key is not protected against unintended
usage. It implies that the CA should have some knowledge about the
subject's cryptographic module."

It should be realized also that proof-of-possession is NOT needed at
all what using good cryptography practice. As soon as the identifier
of the certificate being used is protected by the digital signature,
then proof-of-possession becomes unnecessary. Why not say it ?

COMMENT 7

Section 4, Security considerations. The current text is as follows:

"Comparing two qualified certificates to determine if they represent
the same physical entity may provide misleading results and should
be performed with care."

This sentence does not help. Replace by:

"Comparing two qualified certificates, that contain different DNs,
to determine if they represent the same physical entity cannot be
made."


Denis

> We are not talking about unintentional mistakes here (which always can
> happen) but the concept of operation.
> 
> /Stefan


Received: from mail.arabtrust.com (mail.arabtrust.com [216.247.149.19]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id WAA03429 for <[e-mail]>; Tue, 25 Jul 2000 22:39:39 -0700 (PDT)
Received: from jean [195.39.160.127] by mail.arabtrust.com (SMTPD32-6.00) id AAE21B000FE; Wed, 26 Jul 2000 01:45:06 -0400
From: "Jean Abraham" <[e-mail]>
To: <[e-mail]>
Subject: unsubscribe
Date: Wed, 26 Jul 2000 08:41:04 +0300
Message-ID: <[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset="Windows-1252"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0)
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6600

unsubscribe


Received: from ts16-a550.dial.sovam.com (ts16-a550.dial.sovam.com [195.239.7.42]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id PAA15071 for <[e-mail]>; Tue, 25 Jul 2000 15:33:54 -0700 (PDT)
From: <[e-mail]>
To: <[e-mail]>
Date: ×ò, 06 èþë 2000 12:01:05 +0400
Message-ID: <[e-mail]>
Subject: Hi, its for you !
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit

Hi! We are Russian girls - Lilia, Alyona, Natalia. We would like to
correspond with you. Visit our site and see our photos.
http://www.rusladies.h1.ru
With interest, Lilia, Alyona, Natalia.


P.S. This is not spam. You can unsubscribe at any time by sending an email to
[e-mail] with the subject UNSUBSCRIBE.
P.P.S. This message is being sent to you in compliance with the proposed Federal
legislation for commercial e-mail (S.1618-SECTION 301).  "Pursuant to
Section 301, Paragraph (a)(2)(C) of S. 1618, further
transmissions to you by the sender of this e-mail may be stopped at no
cost to you by clicking mailto:[e-mail] and placing REMOVE in the
subject.



Received: from blue.identrus.com ([216.213.93.121]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id LAA11108 for <[e-mail]>; Tue, 25 Jul 2000 11:15:13 -0700 (PDT)
Received: by blue.identrus.com with Internet Mail Service (5.5.2650.21) id <N9QAN2RK>; Tue, 25 Jul 2000 14:18:09 -0400
Message-ID: <[e-mail]>
From: Khaja Ahmed <[e-mail]>
To: "'Karl Scheibelhofer '" <[e-mail]>, "'IETF PKIX Mailing List '" <[e-mail]>
Subject: RE: OCSP request
Date: Tue, 25 Jul 2000 14:18:03 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
List-Unsubscribe: mailto:[e-mail]?body=unsubscribe
Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01BFF664.AFC29920"

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01BFF664.AFC29920
Content-Type: text/plain;
	charset="iso-8859-1"

Karl,

I would like to second your request for this capability.  This is a very
important feature/capability and should really be added to the standard.  

To answer your question, I am aware of work being done to add this to OCSP.
However, it is in the way of proprietary implementations.  The proprietary
nature of any soluion poses it's challenges and so it is best if this body
could take this on as an enhancement to the standard.  

It would be great if someone could propose a revision to the protocol to
included this capability.

It is probably not much more than:

- Stating that a signer may make an OCSP reqest for the status of his
certificate and attach the response to the signature in a specified format.

- Requiring that a relying party OCSP client recognize the proof that the
certificate was not revoked when the signature was made (or within some
reasonable tolerances).

Some other things that would need to be and could easiliy be accomodated
are:

-If the relying party does not trust the OCSP response (Freshness Proof)
attached to the signature it may do it's own checking regardless.  

The nice thing about this is that along with the signed data (which may be
archived) exists proof that the signature was valid when it was made.

An example application that would benefit greatly is: A notebook user /
travellers who downloads her e-mail and reads it off line.  No online access
to OCSP server is needed.  The "Freshness Proof" with each message shows
that the certificate was good when the message was signed.

I recognize that that this will not accomodate all needs and cover all cases
but it covers enough cases that it would constitute a substantial
iimprovement.

Khaja

-----Original Message-----
From: Karl Scheibelhofer
To: IETF PKIX Mailing List
Sent: 7/25/00 9:03 AM
Subject: OCSP request

to verify a signature, it is necessary to find out, if the certificate
used
for signing was valid when the signature was created. normally it is
only
possible to fix the time the signature was created in a time interval;
e.g.
between two timestamps.
to find out, if the certificate was valid during this time interval, i
see
two options:

1. i can get the certificate status information when i create the
signature,
timestamp it, and attach the whole thing to the signed document.

2. have a extended OCSP protocol that allows to request this information

are there any attempts to integrate such a feature to OCSP?
i think that this would be a valuable feature for OCSP. it would avoid
the
necessity to attach all this verification stuff to all signed documents.

with best regards,

  Karl Scheibelhofer

--

Karl Scheibelhofer, <mailto:[e-mail]>
Institute for Applied Information Processing and Communications (IAIK)
at Technical University of Graz, Austria, http://www.iaik.at
Phone: (+43) [phone]

------_=_NextPart_001_01BFF664.AFC29920
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Diso-8859-1">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
5.5.2650.12">
<TITLE>RE: OCSP request</TITLE>
</HEAD>
<BODY>

<P><FONT SIZE=3D2>Karl,</FONT>
</P>

<P><FONT SIZE=3D2>I would like to second your request for this =
capability.&nbsp; This is a very important feature/capability and =
should really be added to the standard.&nbsp; </FONT></P>

<P><FONT SIZE=3D2>To answer your question, I am aware of work being =
done to add this to OCSP.&nbsp; However, it is in the way of =
proprietary implementations.&nbsp; The proprietary nature of any =
soluion poses it's challenges and so it is best if this body could take =
this on as an enhancement to the standard.&nbsp; </FONT></P>

<P><FONT SIZE=3D2>It would be great if someone could propose a revision =
to the protocol to included this capability.</FONT>
</P>

<P><FONT SIZE=3D2>It is probably not much more than:</FONT>
</P>

<P><FONT SIZE=3D2>- Stating that a signer may make an OCSP reqest for =
the status of his certificate and attach the response to the signature =
in a specified format.</FONT></P>

<P><FONT SIZE=3D2>- Requiring that a relying party OCSP client =
recognize the proof that the certificate was not revoked when the =
signature was made (or within some reasonable tolerances).</FONT></P>

<P><FONT SIZE=3D2>Some other things that would need to be and could =
easiliy be accomodated are:</FONT>
</P>

<P><FONT SIZE=3D2>-If the relying party does not trust the OCSP =
response (Freshness Proof) attached to the signature it may do it's own =
checking regardless.&nbsp; </FONT></P>

<P><FONT SIZE=3D2>The nice thing about this is that along with the =
signed data (which may be archived) exists proof that the signature was =
valid when it was made.</FONT></P>

<P><FONT SIZE=3D2>An example application that would benefit greatly is: =
A notebook user /&nbsp; travellers who downloads her e-mail and reads =
it off line.&nbsp; No online access to OCSP server is needed.&nbsp; The =
&quot;Freshness Proof&quot; with each message shows that the =
certificate was good when the message was signed.</FONT></P>

<P><FONT SIZE=3D2>I recognize that that this will not accomodate all =
needs and cover all cases but it covers enough cases that it would =
constitute a substantial iimprovement.</FONT></P>

<P><FONT SIZE=3D2>Khaja</FONT>
</P>

<P><FONT SIZE=3D2>-----Original Message-----</FONT>
<BR><FONT SIZE=3D2>From: Karl Scheibelhofer</FONT>
<BR><FONT SIZE=3D2>To: IETF PKIX Mailing List</FONT>
<BR><FONT SIZE=3D2>Sent: 7/25/00 9:03 AM</FONT>
<BR><FONT SIZE=3D2>Subject: OCSP request</FONT>
</P>

<P><FONT SIZE=3D2>to verify a signature, it is necessary to find out, =
if the certificate</FONT>
<BR><FONT SIZE=3D2>used</FONT>
<BR><FONT SIZE=3D2>for signing was valid when the signature was =
created. normally it is</FONT>
<BR><FONT SIZE=3D2>only</FONT>
<BR><FONT SIZE=3D2>possible to fix the time the signature was created =
in a time interval;</FONT>
<BR><FONT SIZE=3D2>e.g.</FONT>
<BR><FONT SIZE=3D2>between two timestamps.</FONT>
<BR><FONT SIZE=3D2>to find out, if the certificate was valid during =
this time interval, i</FONT>
<BR><FONT SIZE=3D2>see</FONT>
<BR><FONT SIZE=3D2>two options:</FONT>
</P>

<P><FONT SIZE=3D2>1. i can get the certificate status information when =
i create the</FONT>
<BR><FONT SIZE=3D2>signature,</FONT>
<BR><FONT SIZE=3D2>timestamp it, and attach the whole thing to the =
signed document.</FONT>
</P>

<P><FONT SIZE=3D2>2. have a extended OCSP protocol that allows to =
request this information</FONT>
</P>

<P><FONT SIZE=3D2>are there any attempts to integrate such a feature to =
OCSP?</FONT>
<BR><FONT SIZE=3D2>i think that this would be a valuable feature for =
OCSP. it would avoid</FONT>
<BR><FONT SIZE=3D2>the</FONT>
<BR><FONT SIZE=3D2>necessity to attach all this verification stuff to =
all signed documents.</FONT>
</P>

<P><FONT SIZE=3D2>with best regards,</FONT>
</P>

<P><FONT SIZE=3D2>&nbsp; Karl Scheibelhofer</FONT>
</P>

<P><FONT SIZE=3D2>--</FONT>
</P>

<P><FONT SIZE=3D2>Karl Scheibelhofer, &lt;<A =
HREF=3D"mailto:[e-mail]">mailto:Karl.Scheibelhofer@iai=
k.at</A>&gt;</FONT>
<BR><FONT SIZE=3D2>Institute for Applied Information Processing and =
Communications (IAIK)</FONT>
<BR><FONT SIZE=3D2>at Technical University of Graz, Austria, <A =
HREF=3D"http://www.iaik.at" =
TARGET=3D"_blank">http://www.iaik.at</A></FONT>
<BR><FONT SIZE=3D2>Phone: (+43) [phone]</FONT>
</P>

</BODY>
</HTML>
------_=_NextPart_001_01BFF664.AFC29920--


Received: from ext-mail.valicert.com (ns1.valicert.com [63.65.221.10]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id KAA10142 for <[e-mail]>; Tue, 25 Jul 2000 10:19:43 -0700 (PDT)
Received: from CONVERSION-DAEMON.ext-mail.valicert.com by ext-mail.valicert.com (PMDF V6.0-24 #46243) id <[e-mail]> for [e-mail]; Tue, 25 Jul 2000 10:22:45 -0700 (PDT)
Received: from seine.valicert.com ([192.168.2.23]) by ext-mail.valicert.com (PMDF V6.0-24 #46243) with ESMTP id <[e-mail]>; Tue, 25 Jul 2000 10:22:45 -0700 (PDT)
Received: by seine.valicert.com with Internet Mail Service (5.5.2650.21) id <3600606P>; Tue, 25 Jul 2000 10:14:17 -0700
Content-return: allowed
Date: Tue, 25 Jul 2000 10:14:17 -0700
From: Ambarish Malpani <[e-mail]>
Subject: RE: OCSP request
To: "'Simon Tardell'" <[e-mail]>, "'Rich Salz'" <[e-mail]>, Joerg Seidel <[e-mail]>
Cc: [e-mail]
Message-id: <[e-mail]>
MIME-version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-type: text/plain; charset=iso-8859-1

Hi Simon,
    Yes, we do, violently agree!

I didn't know of the German ISIS interpretation of "unknown". That
is *not* the interpretation that any other group is taking. Do
you know who I can contact to help sort this out? I think it is
very, very wrong!

Given this interpretation, I agree, the
wording could and should have been more explicit.

Regards,
Ambarish

---------------------------------------------------------------------
Ambarish Malpani
Architect                                                650.567.5457
ValiCert, Inc.                                  [e-mail]
339 N. Bernardo Ave.                          http://www.valicert.com
Mountain View, CA 94043


> -----Original Message-----
> From: Simon Tardell [mailto:[e-mail]]
> Sent: Tuesday, July 25, 2000 8:45 AM
> To: 'Ambarish Malpani'; Simon Tardell; 'Rich Salz'; Joerg Seidel
> Cc: [e-mail]
> Subject: RE: OCSP request
> 
> 
> Ambarish, 
> 
> Let me just start by pointing out that I agree with you 
> (mostly). But not
> everybody agrees with me....
> 
> > Hi Simon,
> >     Here is the text from RFC 2560:
> > 
> > ---------------Start quote from RFC----------------------
> >  The "good" state indicates a positive response to the 
> status inquiry.
> >    At a minimum, this positive response indicates that the 
> certificate
> >    is not revoked, but does not necessarily mean that the 
> certificate
> >    was ever issued or that the time at which the response 
> was produced
> >    is within the certificate's validity interval. Response 
> extensions
> >    may be used to convey additional information on 
> assertions made by
> >    the responder regarding the status of the certificate such as
> >    positive statement about issuance, validity, etc.
> > 
> >    The "revoked" state indicates that the certificate has 
> been revoked
> >    (either permanantly or temporarily (on hold)).
> > 
> >    The "unknown" state indicates that the responder doesn't 
> know about
> >    the certificate being requested.
> > 
> > ---------------End quote from RFC----------------------
> > 
> > 
> > Good means that it is not on the revoked list. If you wish to
> > assert other things, you can do so with extensions.
> > 
> > Revoked means that it is on the revoked list (you can still assert
> > other things with extensions - nothing says you can't do that,
> > although I agree, it would have been better to say so explicitly.
> > 
> > Unknown means you don't know - aren't willing to say either good
> > or bad (again, you can still use extensions to say more things).
> > 
> > I am not sure which part of the language you are objecting 
> > to.
> 
> The problem I have is that a responder may through "good" 
> assert that any
> number properties are true, *without* qualifying with 
> extensions. On the
> other hand "revoked" means a negative assertion to only one of these
> properties.
> 
> Also, in your interpretation (and mine) "unknown" means "I 
> don't know or
> will not say". As a client a perfectly reasonable reaction to 
> that would be
> to come back and check later or go to another OCSP responder 
> (assuming I
> have a list to choose from) and query that responder. However, it is
> possible to interpret the "unknown" definition as an 
> assertion that "I know
> that this certificate is not issued". This is the 
> interpretation taken by
> the German Trust Center Work Group in their ISIS spec. Under those
> semantics, I can't expect any other responder to have better 
> information.
> 
> > Would it have
> > been satisfactory if we had the line starting "Response 
> extensions...
> > validity, etc." in each of the 3 states? Would you have
> > preferred that we not have allowed for any extensions in responses?
> 
> The preferred way would have been to restrict CertStatus to carry
> information only on revocation and force issuance, validity 
> or any other
> property that you want to assert into extensions. Preferrably those
> extensions should have the same structure (assertion true, 
> assertion false,
> i-don't-know). 
> 
> Simon.
> 
> 
> Simon Tardell, Software Architect, iD2 Technologies
> voice [phone], fax [phone], cell [phone]
> [e-mail], http://www.iD2tech.com
> Securing the Internet economy
> 


Received: from mailserver2.hrz.tu-darmstadt.de ([e-mail] [130.83.22.129]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id KAA09941 for <[e-mail]>; Tue, 25 Jul 2000 10:18:51 -0700 (PDT)
Received: from hrz2.hrz.tu-darmstadt.de (hrz2.hrz.tu-darmstadt.de [130.83.47.115]) by mailserver2.hrz.tu-darmstadt.de (8.9.1a/8.9.1) with ESMTP id TAA21611 for <[e-mail]>; Tue, 25 Jul 2000 19:21:22 +0200 (MET DST)
Received: from HRZ2/SpoolDir by hrz2.hrz.tu-darmstadt.de (Mercury 1.47); 25 Jul 00 19:20:17 +0200
Received: from SpoolDir by HRZ2 (Mercury 1.47); 25 Jul 00 18:08:29 +0200
Received: from pc132 (130.83.244.93) by hrz2.hrz.tu-darmstadt.de (Mercury 1.47); 25 Jul 00 18:08:22 +0200
From: "Markus Ruppert" <[e-mail]>
To: <[e-mail]>
Subject: OCSP - Transportprotocol?
Date: Tue, 25 Jul 2000 18:13:30 +0200
Message-ID: <000101bff653$45bb8960$[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook 8.5, Build 4.71.2377.0
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V4.72.2120.0

Hallo,

  does anybody know if there is an other transport
  protocol than http implemented and in use for
  OCSP?

  Where are other protocols specified? 

  Is there anything like 

  Transport Protocols for CMP
  <draft-ietf-pkix-cmp-transport-protocols-01.txt>

  available for OCSP?


Thanks
     Markus 


Received: from ext-mail.valicert.com (ns1.valicert.com [63.65.221.10]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id KAA09609 for <[e-mail]>; Tue, 25 Jul 2000 10:10:11 -0700 (PDT)
Received: from CONVERSION-DAEMON.ext-mail.valicert.com by ext-mail.valicert.com (PMDF V6.0-24 #46243) id <[e-mail]> for [e-mail]; Tue, 25 Jul 2000 10:13:13 -0700 (PDT)
Received: from seine.valicert.com ([192.168.2.23]) by ext-mail.valicert.com (PMDF V6.0-24 #46243) with ESMTP id <[e-mail]>; Tue, 25 Jul 2000 10:13:13 -0700 (PDT)
Received: by seine.valicert.com with Internet Mail Service (5.5.2650.21) id <3600605L>; Tue, 25 Jul 2000 10:04:45 -0700
Content-return: allowed
Date: Tue, 25 Jul 2000 10:04:43 -0700
From: Ambarish Malpani <[e-mail]>
Subject: RE: OCSP request
To: "'Rich Salz'" <[e-mail]>, Joerg Seidel <[e-mail]>
Cc: [e-mail]
Message-id: <[e-mail]>
MIME-version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-type: text/plain; charset=iso-8859-1

Hi Rich,
    Not true. We have the ability to say unknown also. We can
also do secondary checks, where you actually look for the
existance of a cert in a directory, if that is what people want.
People just need to decide that they want that functionality.

Regards,
Ambarish

---------------------------------------------------------------------
Ambarish Malpani
Architect                                                650.567.5457
ValiCert, Inc.                                  [e-mail]
339 N. Bernardo Ave.                          http://www.valicert.com
Mountain View, CA 94043


> -----Original Message-----
> From: Rich Salz [mailto:[e-mail]]
> Sent: Tuesday, July 25, 2000 7:13 AM
> To: Joerg Seidel
> Cc: [e-mail]
> Subject: Re: OCSP request
> 
> 
> > The problem is that OCSP does not tell you whether the 
> certificate was already
> > issued at the time of the signature. It only says it was 
> not revoked.
> 
> Depends on the OCSP implementation.  Some (e.g., Valicert 
> last I looked)
> can only say "not revoked" while some (e.g., CertCo last I looked) can
> also say "not known"
> 	/r$
> 


Received: from mail-fwd.verio-web.com (mail11a.verio-web.com [161.58.16.57]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id IAA07701 for <[e-mail]>; Tue, 25 Jul 2000 08:59:34 -0700 (PDT)
Received: from 161.58.117.181 (161.58.117.181) by mail11a.verio-web.com (RS ver 1.0.57s) with SMTP id 01855087; Tue, 25 Jul 2000 12:02:29 -0400 (EDT)
Sender: rsalz
Message-ID: <[e-mail]>
Date: Tue, 25 Jul 2000 12:02:42 -0400
From: Rich Salz <[e-mail]>
X-Mailer: Mozilla 4.72 [en] (X11; U; Linux 2.2.14-5.0 i686)
X-Accept-Language: en
MIME-Version: 1.0
To: Richard Levitte <[e-mail]>
CC: [e-mail]
Subject: Re: OCSP request
References: <3.0.5.32.20000725152251.00aac160@localhost> <3.0.5.32.20000725155017.03aee580@localhost> <[e-mail]> <[e-mail]> <[e-mail]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
X-Loop-Detect: 1

> I just made a request with a cert they
> have no chance of knowing, and I got the status "unknown".

Make a request for a mythical cert with a CA that they know about --
i.e., take a CertID where you got a "good" answer, and change only the
serialNumber to something likely to be unissued (e.g., 99999999992).

As the discussion here (yet again :) shows, full understanding of the
OCSP standard is tricky, and requires subtlety that is probably beyond
most potential PKI customers.
	/r$


Received: from naigwy (void1.ausys.se [62.20.78.253]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id IAA06503 for <[e-mail]>; Tue, 25 Jul 2000 08:41:55 -0700 (PDT)
Received: FROM aunt15.ausys.se BY naigwy ; Tue Jul 25 17:43:21 2000 +0200
Received: by aunt15.ausys.se with Internet Mail Service (5.5.2650.21) id <PLMLFS0F>; Tue, 25 Jul 2000 17:44:46 +0200
Message-ID: <[e-mail]>
From: Simon Tardell <[e-mail]>
To: "'Ambarish Malpani'" <[e-mail]>, Simon Tardell <[e-mail]>, "'Rich Salz'" <[e-mail]>, Joerg Seidel <[e-mail]>
Cc: [e-mail]
Subject: RE: OCSP request
Date: Tue, 25 Jul 2000 17:45:20 +0200
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain; charset="iso-8859-1"

Ambarish, 

Let me just start by pointing out that I agree with you (mostly). But not
everybody agrees with me....

> Hi Simon,
>     Here is the text from RFC 2560:
> 
> ---------------Start quote from RFC----------------------
>  The "good" state indicates a positive response to the status inquiry.
>    At a minimum, this positive response indicates that the certificate
>    is not revoked, but does not necessarily mean that the certificate
>    was ever issued or that the time at which the response was produced
>    is within the certificate's validity interval. Response extensions
>    may be used to convey additional information on assertions made by
>    the responder regarding the status of the certificate such as
>    positive statement about issuance, validity, etc.
> 
>    The "revoked" state indicates that the certificate has been revoked
>    (either permanantly or temporarily (on hold)).
> 
>    The "unknown" state indicates that the responder doesn't know about
>    the certificate being requested.
> 
> ---------------End quote from RFC----------------------
> 
> 
> Good means that it is not on the revoked list. If you wish to
> assert other things, you can do so with extensions.
> 
> Revoked means that it is on the revoked list (you can still assert
> other things with extensions - nothing says you can't do that,
> although I agree, it would have been better to say so explicitly.
> 
> Unknown means you don't know - aren't willing to say either good
> or bad (again, you can still use extensions to say more things).
> 
> I am not sure which part of the language you are objecting 
> to.

The problem I have is that a responder may through "good" assert that any
number properties are true, *without* qualifying with extensions. On the
other hand "revoked" means a negative assertion to only one of these
properties.

Also, in your interpretation (and mine) "unknown" means "I don't know or
will not say". As a client a perfectly reasonable reaction to that would be
to come back and check later or go to another OCSP responder (assuming I
have a list to choose from) and query that responder. However, it is
possible to interpret the "unknown" definition as an assertion that "I know
that this certificate is not issued". This is the interpretation taken by
the German Trust Center Work Group in their ISIS spec. Under those
semantics, I can't expect any other responder to have better information.

> Would it have
> been satisfactory if we had the line starting "Response extensions...
> validity, etc." in each of the 3 states? Would you have
> preferred that we not have allowed for any extensions in responses?

The preferred way would have been to restrict CertStatus to carry
information only on revocation and force issuance, validity or any other
property that you want to assert into extensions. Preferrably those
extensions should have the same structure (assertion true, assertion false,
i-don't-know). 

Simon.


Simon Tardell, Software Architect, iD2 Technologies
voice [phone], fax [phone], cell [phone]
[e-mail], http://www.iD2tech.com
Securing the Internet economy


Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id IAA05409 for <[e-mail]>; Tue, 25 Jul 2000 08:37:51 -0700 (PDT)
Received: from bag-wts.UK.Sun.COM ([129.156.81.5]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id IAA24271; Tue, 25 Jul 2000 08:40:48 -0700 (PDT)
Received: from uk.sun.com ([129.156.134.64]) by bag-wts.UK.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.9) with ESMTP id QAA15451; Tue, 25 Jul 2000 16:40:45 +0100 (BST)
Message-ID: <[e-mail]>
Date: Tue, 25 Jul 2000 16:43:59 +0100
From: Jonathan Sowler <[e-mail]>
X-Mailer: Mozilla 4.7 [en] (WinNT; I)
X-Accept-Language: en,pdf
MIME-Version: 1.0
To: Simon Tardell <[e-mail]>
CC: "'Rich Salz'" <[e-mail]>, Joerg Seidel <[e-mail]>, [e-mail]
Subject: Re: OCSP request
References: <[e-mail]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Good point - the language consistently causes a problem - "good" implies some
sort of judgement that you can take proceed with a transaction/session based on
the status of the certificate.   It would be good to define the response "issued
and not revoked" and avoid more loaded terms - as dull as it may make reading
PKIX specs!  If a certificate has been revoked and the reason for revocation is
benign,  I may still chose to proceed with a signed transaction on the basis
that there is minimal risk to me - i.e. interpret the OCSP response as good.



Simon Tardell wrote:

> > > The problem is that OCSP does not tell you whether the
> > certificate was already
> > > issued at the time of the signature. It only says it was
> > not revoked.
> >
> > Depends on the OCSP implementation.  Some (e.g., Valicert
> > last I looked)
> > can only say "not revoked" while some (e.g., CertCo last I looked) can
> > also say "not known"
>
> The problem with the OCSP protocol is that there are three non-orthogonal
> answers: good, revoked, unknown. It'd all be well if "good" was identical to
> "not revoked" and "unknown" meant "I can't tell if it is either, go ask
> someone else, or come back later, I might find out". But that is not the way
> it is expressed in the RFC. In the RFC "good" is an assertion that A && B &&
> C .. any number of conditions is true, while revoked only means !B and
> unknown could be interpreted to mean !C ("I KNOW this cert was never
> issued"). Different groups have different requirements and will want to
> include different assertions in OCSP or something very similar (e.g. some
> want to assert that a cert was ever issued) in a way that will make the
> clients un-interoperable. That is, they will comply in the sense that the
> bits on the wire are the same, but the intended interpretation is different.
> Since end-users may very well be members of different PKIs this is
> unfortunate.
>
> Simon.
>
> Simon Tardell, Software Architect, iD2 Technologies
> voice [phone], fax [phone], cell [phone]
> [e-mail], http://www.iD2tech.com
> Securing the Internet economy

--

Best Regards,

Jonathan Sowler
Product Management Group

-------------------------------------------------------------
-------------------------------------------------------------

TRUSTBASE HAS MOVED!!  The new contact details are:

For more information about iPlanet's Trustbase products visit:
http://www.trustbase.com

iPlanet Electronic Commerce Solutions       Tel: [phone]
A Sun-Netscape Alliance                     Ext: 29916
Equitable House        Fax: [phone]
47/51 King William Street      E-Mail: [e-mail]
London
EC4R 9AF
United Kingdom

-------------------------------------------------------------

"Trust only those who stand to lose as much as you when things go wrong."

Bralek's Rule for Success, in Arthur Bloch, comp.
"Expertsmanship," Murphy's Law: Book Three, 1982

-------------------------------------------------------------




Received: from ns.celocom.se ([e-mail] [212.209.40.66]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id IAA01449 for <[e-mail]>; Tue, 25 Jul 2000 08:24:02 -0700 (PDT)
Received: by ns.celocom.se; id RAA10278; Tue, 25 Jul 2000 17:27:03 +0200 (CEST)
Received: from seexchange.celocom.se(10.10.10.11) by ns.celocom.se via smap (4.1) id xma010263; Tue, 25 Jul 00 17:26:24 +0200
Received: from celocom.se (levitte.celocom.se [10.10.10.124]) by seexchange.celocom.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21) id 3YLHH2Q1; Tue, 25 Jul 2000 17:29:44 +0200
Sender: [e-mail]
Message-ID: <[e-mail]>
Date: Tue, 25 Jul 2000 17:25:56 +0200
From: Richard Levitte <[e-mail]>
Organization: Celo Communications, Ltd.
X-Mailer: Mozilla 4.74 [en] (X11; U; Linux 2.2.14-5.0 i686)
X-Accept-Language: en
MIME-Version: 1.0
To: Rich Salz <[e-mail]>
CC: Joerg Seidel <[e-mail]>, [e-mail]
Subject: Re: OCSP request
References: <3.0.5.32.20000725152251.00aac160@localhost> <3.0.5.32.20000725155017.03aee580@localhost> <[e-mail]> <[e-mail]>
Content-Type: multipart/mixed; boundary="------------5B042D65A07B5E4A482951C7"

This is a multi-part message in MIME format.
--------------5B042D65A07B5E4A482951C7
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Rich Salz wrote:

> Depends on the OCSP implementation.  Some (e.g., Valicert last I looked)
> can only say "not revoked"

In that case, they've corrected themselves.  I just made a request with a cert they
have no chance of knowing, and I got the status "unknown".

--
Richard Levitte                 !!! New cell phone number !!!
[e-mail]

/* You might enjoy viewing the complete vCard */


--------------5B042D65A07B5E4A482951C7
Content-Type: text/x-vcard; charset=us-ascii;
 name="richard.levitte.vcf"
Content-Transfer-Encoding: 7bit
Content-Description: Card for Richard Levitte
Content-Disposition: attachment;
 filename="richard.levitte.vcf"

begin:vcard 
n:Levitte;Richard
tel;cell:[phone]
tel;work:[phone]
x-mozilla-html:FALSE
org:<A HREF="http://www.celocom.com">Celo Communications</A>
version:2.1
email;internet:[e-mail]
title:Software Artist
adr;quoted-printable:;;Sveav=E4gen 145, 5tr=0D=0AStockholm;;;;SWEDEN
note;quoted-printable:<br>=0D=0A<table border=3D0>=0D=0A<tr>=0D=0A  <td bgcolor=3D"#00ffff">c=EAlo, =E2vi, =E2tum, (latin) 1,v.a.=0D=0A      to hide something from one, to keep secret, to conceal.=0D=0A  </td>=0D=0A</tr>=0D=0A</table>=0D=0A<br>=0D=0A<table border=3D3>=0D=0A<tr>=0D=0A <td>=0D=0A  <table>=0D=0A  <tr>=0D=0A   <td valign=3Dtop>o/~</td>=0D=0A   <td><font size=3D-1>Coding, coding, coding</font><br>=0D=0A          Keep'em hackers coding<br>=0D=0A          <font size=3D+1>And When They're Done Coding</font><br>=0D=0A          <font size=3D7>COMPIIIIIIILE!!</font></td>=0D=0A  </tr>=0D=0A  </table>=0D=0A </td>=0D=0A</tr>=0D=0A</table>
fn:Richard Levitte
end:vcard

--------------5B042D65A07B5E4A482951C7--



Received: from thalia.fm.intel.com (thalia.fm.intel.com [132.233.247.11]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id IAA29489 for <[e-mail]>; Tue, 25 Jul 2000 08:13:49 -0700 (PDT)
Received: from fmsmsx28.FM.INTEL.COM (fmsmsx28.fm.intel.com [132.233.42.28]) by thalia.fm.intel.com (8.9.1a+p1/8.9.1/d: relay.m4,v 1.30 2000/06/08 18:25:35 dmccart Exp $) with ESMTP id PAA13297 for <[e-mail]>; Tue, 25 Jul 2000 15:17:46 GMT
Received: by fmsmsx28.fm.intel.com with Internet Mail Service (5.5.2650.21) id <PSGSBZMS>; Tue, 25 Jul 2000 08:16:49 -0700
Message-ID: <[e-mail]>
From: "Eissa, Mohamed" <[e-mail]>
To: "'[e-mail]'" <[e-mail]>
Subject: OCSP, SCVP vendors
Date: Tue, 25 Jul 2000 08:16:47 -0700
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain; charset="iso-8859-1"

Hi all,

I need to know if there are any vendors doing interoperability tests for
OCSP and SCVP, and where to get more information about the products passed
the tests.


Mohamed A. Eissa

Intel of Canada, Ltd.
[phone]
2 Eva Road, Suite 220
Toronto, 
Ontario, M9C 2A8




Received: from mta5.snfc21.pbi.net (mta5.snfc21.pbi.net [206.13.28.241]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id IAA28664 for <[e-mail]>; Tue, 25 Jul 2000 08:01:39 -0700 (PDT)
Received: from [192.168.1.71] ([208.233.228.110]) by mta5.snfc21.pbi.net (Sun Internet Mail Server sims.3.5.2000.01.05.12.18.p9) with ESMTP id <[e-mail]> for [e-mail]; Tue, 25 Jul 2000 08:01:30 -0700 (PDT)
Date: Tue, 25 Jul 2000 08:02:25 -0700
From: Aram Perez <[e-mail]>
Subject: Re: A Real Rationale for Dedicated Keys
In-reply-to: <03bd01bff605$887f3290$[e-mail]>
To: PKIX <[e-mail]>
Message-id: <[e-mail]>
MIME-version: 1.0
Content-type: text/plain; charset="US-ASCII"
Content-transfer-encoding: 7bit
User-Agent: Microsoft-Outlook-Express-Macintosh-Edition/5.02.2022

Hi Simon M.,

> Hi Aram,
>> 
>> I haven't tried, but I believe that you can open up a bank account with
> one
>> of the "Internet Banks" without physically showing up.
>> 
> They must depend on some existing on-line identity that they can
> authenticate you against or not care about your identity just the amount of
> $$ you can deposit with them. How safe are your funds with these banks ? How
> much credit do they give you ?

In the US I believe they are as "safe" as a brick and mortar bank. They will
give you as much credit as the credit reporting agencies deem you are worth.

>> 
>> Again, I don't want to regurgitate last year's discussion on the validity
> of
>> the NR bit. I believe that you can have non-repudiation without NR=1, and
>> that I can repudiate, whether or not NR=1.
>> 
> Fair enough but this list has been discussing two uses of certificates, that
> is NR-type signatures and authentication type ones (non-NR). Whether the
> NR-bit is the mechanism to support that or not I dont know but it sounds
> like something that should be decided soon to prevent implementations
> diverging on this point and becoming less interoperable.

I totally agree with you. An we (PKIX) better hurry up before the legal
system overrides whatever we produce (no offense to the lawyers on the
list).

Regards,
Aram Perez



Received: from ext-mail.valicert.com (ns1.valicert.com [63.65.221.10]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id IAA28520 for <[e-mail]>; Tue, 25 Jul 2000 08:01:19 -0700 (PDT)
Received: from CONVERSION-DAEMON.ext-mail.valicert.com by ext-mail.valicert.com (PMDF V6.0-24 #46243) id <[e-mail]> for [e-mail]; Tue, 25 Jul 2000 08:04:16 -0700 (PDT)
Received: from seine.valicert.com ([192.168.2.23]) by ext-mail.valicert.com (PMDF V6.0-24 #46243) with ESMTP id <[e-mail]>; Tue, 25 Jul 2000 08:04:16 -0700 (PDT)
Received: by seine.valicert.com with Internet Mail Service (5.5.2650.21) id <360060GA>; Tue, 25 Jul 2000 07:55:48 -0700
Content-return: allowed
Date: Tue, 25 Jul 2000 07:55:38 -0700
From: Ambarish Malpani <[e-mail]>
Subject: RE: OCSP request
To: "'Simon Tardell'" <[e-mail]>, "'Rich Salz'" <[e-mail]>, Joerg Seidel <[e-mail]>
Cc: [e-mail]
Message-id: <[e-mail]>
MIME-version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-type: text/plain; charset=iso-8859-1

Hi Simon,
    Here is the text from RFC 2560:

---------------Start quote from RFC----------------------
 The "good" state indicates a positive response to the status inquiry.
   At a minimum, this positive response indicates that the certificate
   is not revoked, but does not necessarily mean that the certificate
   was ever issued or that the time at which the response was produced
   is within the certificate's validity interval. Response extensions
   may be used to convey additional information on assertions made by
   the responder regarding the status of the certificate such as
   positive statement about issuance, validity, etc.

   The "revoked" state indicates that the certificate has been revoked
   (either permanantly or temporarily (on hold)).

   The "unknown" state indicates that the responder doesn't know about
   the certificate being requested.

---------------End quote from RFC----------------------


Good means that it is not on the revoked list. If you wish to
assert other things, you can do so with extensions.

Revoked means that it is on the revoked list (you can still assert
other things with extensions - nothing says you can't do that,
although I agree, it would have been better to say so explicitly.

Unknown means you don't know - aren't willing to say either good
or bad (again, you can still use extensions to say more things).

I am not sure which part of the language you are objecting to. Would it have
been satisfactory if we had the line starting "Response extensions...
validity, etc." in each of the 3 states? Would you have
preferred that we not have allowed for any extensions in responses?

I agree that we should have indicated that extensions could be used
to convey additional information in any type of a response (which
was the whole point of using extensions in responses IMHO). I
disagree that we should not have allowed people to put extensions in
responses that are not defined in the RFC - people are using OCSP
for a wide variety of applications that have different needs - I
would not want them to discard OCSP because they can't convey
anything other than revocation status in responses.

As a server or client, my attitude to extensions is: If the
information in the extension is something that you don't want the
recipient to ignore, mark it critical. Otherwise mark it
non-critical.

Regards,
Ambarish

---------------------------------------------------------------------
Ambarish Malpani
Architect                                                650.567.5457
ValiCert, Inc.                                  [e-mail]
339 N. Bernardo Ave.                          http://www.valicert.com
Mountain View, CA 94043


> -----Original Message-----
> From: Simon Tardell [mailto:[e-mail]]
> Sent: Tuesday, July 25, 2000 7:41 AM
> To: 'Rich Salz'; Joerg Seidel
> Cc: [e-mail]
> Subject: RE: OCSP request
> 
> 
> > > The problem is that OCSP does not tell you whether the 
> > certificate was already
> > > issued at the time of the signature. It only says it was 
> > not revoked.
> > 
> > Depends on the OCSP implementation.  Some (e.g., Valicert 
> > last I looked)
> > can only say "not revoked" while some (e.g., CertCo last I 
> looked) can
> > also say "not known"
> 
> The problem with the OCSP protocol is that there are three 
> non-orthogonal
> answers: good, revoked, unknown. It'd all be well if "good" 
> was identical to
> "not revoked" and "unknown" meant "I can't tell if it is 
> either, go ask
> someone else, or come back later, I might find out". But that 
> is not the way
> it is expressed in the RFC. In the RFC "good" is an assertion 
> that A && B &&
> C .. any number of conditions is true, while revoked only means !B and
> unknown could be interpreted to mean !C ("I KNOW this cert was never
> issued"). Different groups have different requirements and 
> will want to
> include different assertions in OCSP or something very 
> similar (e.g. some
> want to assert that a cert was ever issued) in a way that 
> will make the
> clients un-interoperable. That is, they will comply in the 
> sense that the
> bits on the wire are the same, but the intended 
> interpretation is different.
> Since end-users may very well be members of different PKIs this is
> unfortunate. 
> 
> Simon.
> 
> 
> Simon Tardell, Software Architect, iD2 Technologies
> voice [phone], fax [phone], cell [phone]
> [e-mail], http://www.iD2tech.com
> Securing the Internet economy
> 


Received: from mystic1.trustcenter.de (mystic1.trustcenter.de [193.194.157.34]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id IAA28414 for <[e-mail]>; Tue, 25 Jul 2000 08:00:57 -0700 (PDT)
Received: by mystic1.trustcenter.de; id RAA21433; Tue, 25 Jul 2000 17:01:46 +0200
Received: from nodnsquery(192.168.200.3) by mystic1.trustcenter.de via smap (V5.0) id xma021425; Tue, 25 Jul 00 17:00:55 +0200
Received: from ew-jbr (titan.trustcenter.de [192.168.200.244]) by callisto.trustcenter.de (8.9.3/8.9.3) with SMTP id RAA03707; Tue, 25 Jul 2000 17:02:35 +0200 (MET DST)
Message-Id: <3.0.5.32.20000725170235.00a9ca50@localhost>
X-Sender: jbr@localhost
X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (32)
Date: Tue, 25 Jul 2000 17:02:35 +0200
To: Rich Salz <[e-mail]>, [e-mail]
From: Juergen Brauckmann <[e-mail]>
Subject: good in OCSP Responses. Was: Re: OCSP request
In-Reply-To: <[e-mail]>
References: <3.0.5.32.20000725152251.00aac160@localhost> <3.0.5.32.20000725155017.03aee580@localhost> <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by ns.secondary.com id IAA28415

At 10:12 25.07.00 -0400, Rich Salz wrote:
>Depends on the OCSP implementation.  Some (e.g., Valicert last I looked)
>can only say "not revoked" while some (e.g., CertCo last I looked) can
>also say "not known"

BTW: We think that theres is a real need for OCSP responders to be able to
say "Yes, I know this cert" instead of the normal OCSP "good=not revoked".
It is necessary to extend OCSP so real positive answers can be expressed in
the OCSP response. The extension of the protocol must be made in such a way
that existing clients can still understand "new" OCSP responses, so
changing or extending the CertStatus field is probably not really a good
thing.

It would work as follows:
Let's first define a OCSP Extension certHash, which contains the hash of
the certificate as an OCTET STRING.
This extension may be present (flagged non critical) in OCSP Responses, but
SHOULD NOT be present in OCSP requests.

Now if an OCSP responder can present the certHash in it's response as part
of the singleExtensions, a client can be sure that the OCSP Responder knows
what it's talking about, because it can check the hash from the server
against the certificate. The hash is a real proof, not just a vague assurance.

OCSP Responder can include the certHash extension in all responses, because
OCSP clients must be able to handle arbitrary extensions anyway. Clients
which don't understand certHash can ignore it without any risk.


The idea was developed with people from some other German CAs, it is
planned to make something like an internet draft from it. What do you think?

Juergen
-- 
Juergen Brauckmann             Tel.:  +49 (0)40 / 80 80 26-3 11
TC TrustCenter GmbH            Fax.:  +49 (0)40 / 80 80 26-1 26
Sonninstraße 24-28   	    mailto:[e-mail]
D-20097 Hamburg 		    http://www.trustcenter.de	


Received: from naigwy (void1.ausys.se [62.20.78.253]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id HAA27505 for <[e-mail]>; Tue, 25 Jul 2000 07:38:19 -0700 (PDT)
Received: FROM aunt15.ausys.se BY naigwy ; Tue Jul 25 16:39:24 2000 +0200
Received: by aunt15.ausys.se with Internet Mail Service (5.5.2650.21) id <PLMLFSKM>; Tue, 25 Jul 2000 16:40:49 +0200
Message-ID: <[e-mail]>
From: Simon Tardell <[e-mail]>
To: "'Rich Salz'" <[e-mail]>, Joerg Seidel <[e-mail]>
Cc: [e-mail]
Subject: RE: OCSP request
Date: Tue, 25 Jul 2000 16:41:22 +0200
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain; charset="iso-8859-1"

> > The problem is that OCSP does not tell you whether the 
> certificate was already
> > issued at the time of the signature. It only says it was 
> not revoked.
> 
> Depends on the OCSP implementation.  Some (e.g., Valicert 
> last I looked)
> can only say "not revoked" while some (e.g., CertCo last I looked) can
> also say "not known"

The problem with the OCSP protocol is that there are three non-orthogonal
answers: good, revoked, unknown. It'd all be well if "good" was identical to
"not revoked" and "unknown" meant "I can't tell if it is either, go ask
someone else, or come back later, I might find out". But that is not the way
it is expressed in the RFC. In the RFC "good" is an assertion that A && B &&
C .. any number of conditions is true, while revoked only means !B and
unknown could be interpreted to mean !C ("I KNOW this cert was never
issued"). Different groups have different requirements and will want to
include different assertions in OCSP or something very similar (e.g. some
want to assert that a cert was ever issued) in a way that will make the
clients un-interoperable. That is, they will comply in the sense that the
bits on the wire are the same, but the intended interpretation is different.
Since end-users may very well be members of different PKIs this is
unfortunate. 

Simon.


Simon Tardell, Software Architect, iD2 Technologies
voice [phone], fax [phone], cell [phone]
[e-mail], http://www.iD2tech.com
Securing the Internet economy



Received: from mail.arabtrust.com (mail.arabtrust.com [216.247.149.19]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id HAA27190 for <[e-mail]>; Tue, 25 Jul 2000 07:33:15 -0700 (PDT)
Received: from jean [195.39.160.204] by mail.arabtrust.com (SMTPD32-6.00) id A6391FA008E; Tue, 25 Jul 2000 10:37:45 -0400
From: "Jean Abraham" <[e-mail]>
To: <[e-mail]>
Subject: unsubscribe
Date: Tue, 25 Jul 2000 17:33:42 +0300
Message-ID: <[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset="Windows-1252"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0)
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6600
Importance: Normal

unsubscribe


Received: from ns.celocom.se ([e-mail] [212.209.40.66]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id HAA26047 for <[e-mail]>; Tue, 25 Jul 2000 07:17:03 -0700 (PDT)
Received: by ns.celocom.se; id QAA05269; Tue, 25 Jul 2000 16:20:03 +0200 (CEST)
Received: from zap.celocom.se(10.10.10.1) by ns.celocom.se via smap (4.1) id xma005252; Tue, 25 Jul 00 16:19:40 +0200
Received: from celocom.com (dhcp121.celocom.se [10.10.11.21]) by zap.celocom.se (8.8.7/8.8.7) with ESMTP id QAA12622; Tue, 25 Jul 2000 16:19:40 +0200
Message-ID: <[e-mail]>
Date: Tue, 25 Jul 2000 16:19:39 +0200
From: Oscar Jacobsson <[e-mail]>
Organization: Celo Communications
X-Mailer: Mozilla 4.73 [en] (Windows NT 5.0; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Joerg Seidel <[e-mail]>
CC: [e-mail]
Subject: Re: OCSP request
References: <3.0.5.32.20000725152251.00aac160@localhost> <3.0.5.32.20000725155017.03aee580@localhost> <[e-mail]>
Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms37DFA3252E5CB540AA82D9AB"

This is a cryptographically signed message in MIME format.

--------------ms37DFA3252E5CB540AA82D9AB
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Joerg Seidel wrote:
> Or as Karl puts it you need "to
> attach all this verification stuff to all signed documents."

Which is the method ETSI have selected for their ES-C (Electronic
Signature with Complete validation data) electronic signature format,
IIRC.

//oscar
--------------ms37DFA3252E5CB540AA82D9AB
Content-Type: application/x-pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: S/MIME Cryptographic Signature

MIIH/gYJKoZIhvcNAQcCoIIH7zCCB+sCAQExCzAJBgUrDgMCGgUAMAsGCSqGSIb3DQEHAaCC
Bc8wggKzMIICHKADAgECAgMCjYUwDQYJKoZIhvcNAQEEBQAwgZQxCzAJBgNVBAYTAlpBMRUw
EwYDVQQIEwxXZXN0ZXJuIENhcGUxFDASBgNVBAcTC0R1cmJhbnZpbGxlMQ8wDQYDVQQKEwZU
aGF3dGUxHTAbBgNVBAsTFENlcnRpZmljYXRlIFNlcnZpY2VzMSgwJgYDVQQDEx9QZXJzb25h
bCBGcmVlbWFpbCBSU0EgMTk5OS45LjE2MB4XDTAwMDUxMzAwMDEzOVoXDTAxMDUxMzAwMDEz
OVowTTEfMB0GA1UEAxMWVGhhd3RlIEZyZWVtYWlsIE1lbWJlcjEqMCgGCSqGSIb3DQEJARYb
b3NjYXIuamFjb2Jzc29uQGNlbG9jb20uY29tMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKB
gQCZB2URw+NGaMMV/cSk9JoOb4OGMunL44lk/ioXoBR5brSVUcVaB+s+8UmcqOmi9RAAc+Uy
wY69hjPn/LWS3HzN4N4KW6jTEiDm0jPE1aVyxMg7un4rjRSGe9htdPL0ut8QoKXLCjafLKIo
v/pyudWgC1PxSglWECgKyKVVMl13KwIDAQABo1kwVzAmBgNVHREEHzAdgRtvc2Nhci5qYWNv
YnNzb25AY2Vsb2NvbS5jb20wDAYDVR0TAQH/BAIwADAfBgNVHSMEGDAWgBSIq/Fgg2ZV9ORY
x0YdwGG9I9fDjDANBgkqhkiG9w0BAQQFAAOBgQB8NkKsoEJaIAfecEv+NJp6bBs3xM+ynX5F
qJ/ave0p7v2eBBO/fovRoMsmFjF0jHf4RFJqxm9NrpoZWlhehM5nOdS0AyPwFIMEWl7PdSxO
pKkxGS8wgEsVammWQc8MAwULu4qy8SdL9LnszsvEKtrsJFG+bILsOf1qBkC6UuSR4DCCAxQw
ggJ9oAMCAQICAQswDQYJKoZIhvcNAQEEBQAwgdExCzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxX
ZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEaMBgGA1UEChMRVGhhd3RlIENvbnN1
bHRpbmcxKDAmBgNVBAsTH0NlcnRpZmljYXRpb24gU2VydmljZXMgRGl2aXNpb24xJDAiBgNV
BAMTG1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBDQTErMCkGCSqGSIb3DQEJARYccGVyc29u
YWwtZnJlZW1haWxAdGhhd3RlLmNvbTAeFw05OTA5MTYxNDAxNDBaFw0wMTA5MTUxNDAxNDBa
MIGUMQswCQYDVQQGEwJaQTEVMBMGA1UECBMMV2VzdGVybiBDYXBlMRQwEgYDVQQHEwtEdXJi
YW52aWxsZTEPMA0GA1UEChMGVGhhd3RlMR0wGwYDVQQLExRDZXJ0aWZpY2F0ZSBTZXJ2aWNl
czEoMCYGA1UEAxMfUGVyc29uYWwgRnJlZW1haWwgUlNBIDE5OTkuOS4xNjCBnzANBgkqhkiG
9w0BAQEFAAOBjQAwgYkCgYEAs2lal9TQFgt6tcVd6SGcI3LNEkxL937Px/vKciT0QlKsV5Xj
e2F6F4Tn/XI5OJS06u1lp5IGXr3gZfYZu5R5dkw+uWhwdYQc9BF0ALwFLE8JAxcxzPRB1HLG
pl3iiESwiy7ETfHw1oU+bPOVlHiRfkDpnNGNFVeOwnPlMN5G9U8CAwEAAaM3MDUwEgYDVR0T
AQH/BAgwBgEB/wIBADAfBgNVHSMEGDAWgBRyScJzNMZV9At2coF+d/SH58ayDjANBgkqhkiG
9w0BAQQFAAOBgQBrxlnpMfrptuyxA9jfcnL+kWBI6sZV3XvwZ47GYXDnbcKlN9idtxcoVgWL
3Vx1b8aRkMZsZnET0BB8a5FvhuAhNi3B1+qyCa3PLW3Gg1Kb+7v+nIed/LfpdJLkXJeu/H6s
yg1vcnpnLGtz9Yb5nfUAbvQdB86dnoJjKe+TCX5V3jGCAfcwggHzAgEBMIGcMIGUMQswCQYD
VQQGEwJaQTEVMBMGA1UECBMMV2VzdGVybiBDYXBlMRQwEgYDVQQHEwtEdXJiYW52aWxsZTEP
MA0GA1UEChMGVGhhd3RlMR0wGwYDVQQLExRDZXJ0aWZpY2F0ZSBTZXJ2aWNlczEoMCYGA1UE
AxMfUGVyc29uYWwgRnJlZW1haWwgUlNBIDE5OTkuOS4xNgIDAo2FMAkGBSsOAwIaBQCggbEw
GAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMDAwNzI1MTQxOTQw
WjAjBgkqhkiG9w0BCQQxFgQUha3f19z0GxCaeHDzmGZjpjlpdP8wUgYJKoZIhvcNAQkPMUUw
QzAKBggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwBwYFKw4DAgcwDQYIKoZIhvcNAwICAUAw
DQYIKoZIhvcNAwICASgwDQYJKoZIhvcNAQEBBQAEgYBMdeYtcPlry/gsDEHfhg46Nai3Rw4K
x+u6NOaXwQwA/xVeiauDXPfra/dbxaeaJ+pUWXCmeP2G82ZNSC6n0UJIdwQd1bgkxwEBsDyY
gEGJIcOX2znw8iAe/yETxz8O3Xwkj6RN8Cx7lxsxnPXb4CO/2wNOBIMolrWmlEMXSlIFiA==
--------------ms37DFA3252E5CB540AA82D9AB--



Received: from mail-fwd.verio-web.com (mail11a.verio-web.com [161.58.16.57]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id HAA25413 for <[e-mail]>; Tue, 25 Jul 2000 07:09:51 -0700 (PDT)
Received: from 161.58.117.181 (161.58.117.181) by mail11a.verio-web.com (RS ver 1.0.57s) with SMTP id 01831958; Tue, 25 Jul 2000 10:12:40 -0400 (EDT)
Sender: rsalz
Message-ID: <[e-mail]>
Date: Tue, 25 Jul 2000 10:12:53 -0400
From: Rich Salz <[e-mail]>
X-Mailer: Mozilla 4.72 [en] (X11; U; Linux 2.2.14-5.0 i686)
X-Accept-Language: en
MIME-Version: 1.0
To: Joerg Seidel <[e-mail]>
CC: [e-mail]
Subject: Re: OCSP request
References: <3.0.5.32.20000725152251.00aac160@localhost> <3.0.5.32.20000725155017.03aee580@localhost> <[e-mail]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
X-Loop-Detect: 1

> The problem is that OCSP does not tell you whether the certificate was already
> issued at the time of the signature. It only says it was not revoked.

Depends on the OCSP implementation.  Some (e.g., Valicert last I looked)
can only say "not revoked" while some (e.g., CertCo last I looked) can
also say "not known"
	/r$


Received: from naigwy (void1.ausys.se [62.20.78.253]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id HAA24850 for <[e-mail]>; Tue, 25 Jul 2000 07:03:32 -0700 (PDT)
Received: FROM aunt15.ausys.se BY naigwy ; Tue Jul 25 16:04:36 2000 +0200
Received: by aunt15.ausys.se with Internet Mail Service (5.5.2650.21) id <PLMLFRZ0>; Tue, 25 Jul 2000 16:06:01 +0200
Message-ID: <[e-mail]>
From: Simon Tardell <[e-mail]>
To: "'Richard Levitte'" <[e-mail]>, Juergen Brauckmann <[e-mail]>
Cc: Karl Scheibelhofer <[e-mail]>, IETF PKIX Mailing List <[e-mail]>
Subject: RE: OCSP request
Date: Tue, 25 Jul 2000 16:06:34 +0200
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain; charset="iso-8859-1"

> > Why isn't it sufficient to get a fresh OCSP response? The OCSP response
> > itself contains either a revocation date or "good". The  first you can
> > compare against your time interval, and in the latter case you have the
> > validity period of the certificate... .
> 
> If I understand everything correctly, Karl is after verifying 
> the signature of a
> 
> document that was signed, say, 3 months ago.  2 months ago, the
certificate
> got compromised and is therefore not "good" anymore, but it may still be
> interesting to check if the certificate was valid at the time of
signature, and
> from what I understand item 2 above, Karl would like to see 
> the possibility to do that kind of check with OCSP.

If you don't allow for certificate suspension there is no problem. If the
certificate revocation date is less than two months ago, it's ok. If the
certificate is expired now, you also have to know if and for how long the
status of the certificate will be kept in the database. Certificate
suspension is not allowed under German signature law, and perhaps also not
Austrian, so if we're talking SigG compliant certs there is no such need.

Now, if a key gets compromised, you cannot trust *any* signatures by that
key (before or after compromise), because you cannot trust the signer's
assertion of what time it was. A practical system has to protect itself from
that somehow. Enters time stamping. A time stamping service would probably
check the revocation status of the signatory cert and store that together
with the time stamp. 

If you are willing to take the consequences reverse time effects of key
compromise (you don't do timestamping), and if you allow for certificate
suspension, the question "was this certificate valid at this time" makes
sense.

Simon

Simon Tardell, Software Architect, iD2 Technologies
voice [phone], fax [phone], cell [phone]
[e-mail], http://www.iD2tech.com
Securing the Internet economy


Received: from mail-relay-1.maz.net (mail-relay-1.maz.net [194.163.252.17]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id HAA24673 for <[e-mail]>; Tue, 25 Jul 2000 07:02:36 -0700 (PDT)
Received: from sysiphos.maz-hh.de (sysiphos.maz-hh.de [192.109.56.14]) by mail-relay-1.maz.net (8.9.3) with ESMTP id <QAA04080> for <[e-mail]>; Tue, 25 Jul 2000 16:05:36 +0200 (MET DST)
Received: from maz-hh.de (sp-pc-sej.maz-hh.de [192.109.56.145]) by sysiphos.maz-hh.de (8.9.3/8.9.3) with ESMTP id QAA26181 for <[e-mail]>; Tue, 25 Jul 2000 16:05:06 +0200 (MEST)
Message-ID: <[e-mail]>
Date: Tue, 25 Jul 2000 16:05:30 +0200
From: Joerg Seidel <[e-mail]>
Organization: timeproof
X-Mailer: Mozilla 4.5 [de] (WinNT; U)
X-Accept-Language: de
MIME-Version: 1.0
To: [e-mail]
Subject: Re: OCSP request
References: <3.0.5.32.20000725152251.00aac160@localhost> <3.0.5.32.20000725155017.03aee580@localhost>
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 8bit

Juergen Brauckmann schrieb:
> 
> At 15:43 25.07.00 +0200, Richard Levitte wrote:
> >document that was signed, say, 3 months ago.  2 months ago, the certificate
> >got compromised and is therefore not "good" anymore, but it may still be
> >interesting to check if the certificate was valid at the time of signature,
> 
> And this is possible with plain OCSP because the OCSP response contains the
> state "revoked" and the date of the revocation, which would hopefully be
> *after* the assumed signature generation date.

The problem is that OCSP does not tell you whether the certificate was already
issued at the time of the signature. It only says it was not revoked. OCSP can
therefore not answer "historical questions". You need to keep a timestamped
certificate yourself besides the signature. Or as Karl puts it you need "to
attach all this verification stuff to all signed documents."

Joerg
-- 
__________________________________________________________________

Jörg Seidel                             phone  [phone]
Director Technology                     fax    [phone]
timeproof GmbH                          
Harburger Schloßstraße 6-12             mailto:[e-mail]
DE 21079 Hamburg                        http://www.timeproof.de
__________________________________________________________________


Received: from mail-fwd.verio-web.com (mail11a.verio-web.com [161.58.16.57]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id GAA24091 for <[e-mail]>; Tue, 25 Jul 2000 06:55:45 -0700 (PDT)
Received: from 161.58.117.181 (161.58.117.181) by mail11a.verio-web.com (RS ver 1.0.57s) with SMTP id 01804917; Tue, 25 Jul 2000 09:58:12 -0400 (EDT)
Sender: rsalz
Message-ID: <[e-mail]>
Date: Tue, 25 Jul 2000 09:58:23 -0400
From: Rich Salz <[e-mail]>
X-Mailer: Mozilla 4.72 [en] (X11; U; Linux 2.2.14-5.0 i686)
X-Accept-Language: en
MIME-Version: 1.0
To: Richard Levitte <[e-mail]>
CC: Juergen Brauckmann <[e-mail]>, Karl Scheibelhofer <[e-mail]>, IETF PKIX Mailing List <[e-mail]>
Subject: Re: OCSP request
References: <3.0.5.32.20000725152251.00aac160@localhost> <[e-mail]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
X-Loop-Detect: 1

What about the OCSP "archive cutoff" extension?

A signer who wishes proof of validity could generate an OCSP query on
himself, using a NONCE which is the "real" signature. The signed OCSP
reply could then "be" the signature, right?


Received: from mystic1.trustcenter.de (mystic1.trustcenter.de [193.194.157.34]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id GAA23188 for <[e-mail]>; Tue, 25 Jul 2000 06:47:51 -0700 (PDT)
Received: by mystic1.trustcenter.de; id PAA20620; Tue, 25 Jul 2000 15:48:42 +0200
Received: from nodnsquery(192.168.200.3) by mystic1.trustcenter.de via smap (V5.0) id xma020614; Tue, 25 Jul 00 15:48:39 +0200
Received: from ew-jbr (titan.trustcenter.de [192.168.200.244]) by callisto.trustcenter.de (8.9.3/8.9.3) with SMTP id PAA29640; Tue, 25 Jul 2000 15:50:18 +0200 (MET DST)
Message-Id: <3.0.5.32.20000725155017.03aee580@localhost>
X-Sender: jbr@localhost
X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (32)
Date: Tue, 25 Jul 2000 15:50:17 +0200
To: [e-mail]
From: Juergen Brauckmann <[e-mail]>
Subject: Re: OCSP request
Cc: Karl Scheibelhofer <[e-mail]>
In-Reply-To: <[e-mail]>
References: <3.0.5.32.20000725152251.00aac160@localhost>
Mime-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by ns.secondary.com id GAA23191

At 15:43 25.07.00 +0200, Richard Levitte wrote:
>document that was signed, say, 3 months ago.  2 months ago, the certificate
>got compromised and is therefore not "good" anymore, but it may still be
>interesting to check if the certificate was valid at the time of signature, 

And this is possible with plain OCSP because the OCSP response contains the
state "revoked" and the date of the revocation, which would hopefully be
*after* the assumed signature generation date.

Juergen 
-- 
Juergen Brauckmann             Tel.:  +49 (0)40 / 80 80 26-3 11
TC TrustCenter GmbH            Fax.:  +49 (0)40 / 80 80 26-1 26
Sonninstraße 24-28   	    mailto:[e-mail]
D-20097 Hamburg 		    http://www.trustcenter.de	


Received: from ns.celocom.se ([e-mail] [212.209.40.66]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id GAA22304 for <[e-mail]>; Tue, 25 Jul 2000 06:41:04 -0700 (PDT)
Received: by ns.celocom.se; id PAA03400; Tue, 25 Jul 2000 15:44:04 +0200 (CEST)
Received: from seexchange.celocom.se(10.10.10.11) by ns.celocom.se via smap (4.1) id xma003332; Tue, 25 Jul 00 15:43:40 +0200
Received: from celocom.se (levitte.celocom.se [10.10.10.124]) by seexchange.celocom.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21) id 3YLHH2NK; Tue, 25 Jul 2000 15:47:00 +0200
Sender: [e-mail]
Message-ID: <[e-mail]>
Date: Tue, 25 Jul 2000 15:43:12 +0200
From: Richard Levitte <[e-mail]>
Organization: Celo Communications, Ltd.
X-Mailer: Mozilla 4.74 [en] (X11; U; Linux 2.2.14-5.0 i686)
X-Accept-Language: en
MIME-Version: 1.0
To: Juergen Brauckmann <[e-mail]>
CC: Karl Scheibelhofer <[e-mail]>, IETF PKIX Mailing List <[e-mail]>
Subject: Re: OCSP request
References: <3.0.5.32.20000725152251.00aac160@localhost>
Content-Type: multipart/mixed; boundary="------------BF1F32DEA19E9ED875CC6C81"

This is a multi-part message in MIME format.
--------------BF1F32DEA19E9ED875CC6C81
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Juergen Brauckmann wrote:

> At 15:03 25.07.00 +0200, Karl Scheibelhofer wrote:
> >to verify a signature, it is necessary to find out, if the certificate used
> >for signing was valid when the signature was created. normally it is only
> >possible to fix the time the signature was created in a time interval; e.g.
> >between two timestamps.
> >to find out, if the certificate was valid during this time interval, i see
> >two options:
> >
> >1. i can get the certificate status information when i create the signature,
> >timestamp it, and attach the whole thing to the signed document.
> >
> >2. have a extended OCSP protocol that allows to request this information
>
> Why isn't it sufficient to get a fresh OCSP response? The OCSP response
> itself contains either a revocation date or "good". The first you can
> compare against your time interval, and in the latter case you have the
> validity period of the certificate... .

If I understand everything correctly, Karl is after verifying the signature of a

document that was signed, say, 3 months ago.  2 months ago, the certificate
got compromised and is therefore not "good" anymore, but it may still be
interesting to check if the certificate was valid at the time of signature, and
from what I understand item 2 above, Karl would like to see the possibility
to do that kind of check with OCSP.

Karl, have I understood you correctly?

--
Richard Levitte                 !!! New cell phone number !!!
[e-mail]

/* You might enjoy viewing the complete vCard */


--------------BF1F32DEA19E9ED875CC6C81
Content-Type: text/x-vcard; charset=us-ascii;
 name="richard.levitte.vcf"
Content-Transfer-Encoding: 7bit
Content-Description: Card for Richard Levitte
Content-Disposition: attachment;
 filename="richard.levitte.vcf"

begin:vcard 
n:Levitte;Richard
tel;cell:[phone]
tel;work:[phone]
x-mozilla-html:FALSE
org:<A HREF="http://www.celocom.com">Celo Communications</A>
version:2.1
email;internet:[e-mail]
title:Software Artist
adr;quoted-printable:;;Sveav=E4gen 145, 5tr=0D=0AStockholm;;;;SWEDEN
note;quoted-printable:<br>=0D=0A<table border=3D0>=0D=0A<tr>=0D=0A  <td bgcolor=3D"#00ffff">c=EAlo, =E2vi, =E2tum, (latin) 1,v.a.=0D=0A      to hide something from one, to keep secret, to conceal.=0D=0A  </td>=0D=0A</tr>=0D=0A</table>=0D=0A<br>=0D=0A<table border=3D3>=0D=0A<tr>=0D=0A <td>=0D=0A  <table>=0D=0A  <tr>=0D=0A   <td valign=3Dtop>o/~</td>=0D=0A   <td><font size=3D-1>Coding, coding, coding</font><br>=0D=0A          Keep'em hackers coding<br>=0D=0A          <font size=3D+1>And When They're Done Coding</font><br>=0D=0A          <font size=3D7>COMPIIIIIIILE!!</font></td>=0D=0A  </tr>=0D=0A  </table>=0D=0A </td>=0D=0A</tr>=0D=0A</table>
fn:Richard Levitte
end:vcard

--------------BF1F32DEA19E9ED875CC6C81--



Received: from mystic1.trustcenter.de (mystic1.trustcenter.de [193.194.157.34]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id GAA20880 for <[e-mail]>; Tue, 25 Jul 2000 06:21:22 -0700 (PDT)
Received: by mystic1.trustcenter.de; id PAA20416; Tue, 25 Jul 2000 15:21:42 +0200
Received: from nodnsquery(192.168.200.3) by mystic1.trustcenter.de via smap (V5.0) id xma020409; Tue, 25 Jul 00 15:21:11 +0200
Received: from ew-jbr (titan.trustcenter.de [192.168.200.244]) by callisto.trustcenter.de (8.9.3/8.9.3) with SMTP id PAA28438; Tue, 25 Jul 2000 15:22:51 +0200 (MET DST)
Message-Id: <3.0.5.32.20000725152251.00aac160@localhost>
X-Sender: jbr@localhost
X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (32)
Date: Tue, 25 Jul 2000 15:22:51 +0200
To: "Karl Scheibelhofer" <[e-mail]>, "IETF PKIX Mailing List" <[e-mail]>
From: Juergen Brauckmann <[e-mail]>
Subject: Re: OCSP request
In-Reply-To: <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by ns.secondary.com id GAA20881

At 15:03 25.07.00 +0200, Karl Scheibelhofer wrote:
>to verify a signature, it is necessary to find out, if the certificate used
>for signing was valid when the signature was created. normally it is only
>possible to fix the time the signature was created in a time interval; e.g.
>between two timestamps.
>to find out, if the certificate was valid during this time interval, i see
>two options:
>
>1. i can get the certificate status information when i create the signature,
>timestamp it, and attach the whole thing to the signed document.
>
>2. have a extended OCSP protocol that allows to request this information

Why isn't it sufficient to get a fresh OCSP response? The OCSP response
itself contains either a revocation date or "good". The first you can
compare against your time interval, and in the latter case you have the
validity period of the certificate... .

Juergen  
-- 
Juergen Brauckmann             Tel.:  +49 (0)40 / 80 80 26-3 11
TC TrustCenter GmbH            Fax.:  +49 (0)40 / 80 80 26-1 26
Sonninstraße 24-28   	    mailto:[e-mail]
D-20097 Hamburg 		    http://www.trustcenter.de	


Received: from iaik.tu-graz.ac.at (excalibur.iaik.tu-graz.ac.at [129.27.152.30]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id GAA19903 for <[e-mail]>; Tue, 25 Jul 2000 06:00:39 -0700 (PDT)
Received: from hades [129.27.152.143] by iaik.tu-graz.ac.at (SMTPD32-6.00) id A02C3580094; Tue, 25 Jul 2000 15:03:40 +0200
Received: from localhost [127.0.0.1] by hades (IAIK S/MIME Mapper 2.0beta1 14/January/2000); Tue, 25 Jul 2000 15:03:01 +0100
From: "Karl Scheibelhofer" <[e-mail]>
To: "IETF PKIX Mailing List" <[e-mail]>
Subject: OCSP request
Date: Tue, 25 Jul 2000 15:03:01 +0200
Message-ID: <[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0)
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400
Importance: Normal

to verify a signature, it is necessary to find out, if the certificate used
for signing was valid when the signature was created. normally it is only
possible to fix the time the signature was created in a time interval; e.g.
between two timestamps.
to find out, if the certificate was valid during this time interval, i see
two options:

1. i can get the certificate status information when i create the signature,
timestamp it, and attach the whole thing to the signed document.

2. have a extended OCSP protocol that allows to request this information

are there any attempts to integrate such a feature to OCSP?
i think that this would be a valuable feature for OCSP. it would avoid the
necessity to attach all this verification stuff to all signed documents.

with best regards,

  Karl Scheibelhofer

--

Karl Scheibelhofer, <mailto:[e-mail]>
Institute for Applied Information Processing and Communications (IAIK)
at Technical University of Graz, Austria, http://www.iaik.at
Phone: (+43) [phone]



Received: from auemlsrv.firewall.lucent.com (auemail1.lucent.com [192.11.223.161]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id EAA11372 for <[e-mail]>; Tue, 25 Jul 2000 04:12:27 -0700 (PDT)
Received: from auemlsrv.firewall.lucent.com (localhost [127.0.0.1]) by auemlsrv.firewall.lucent.com (Pro-8.9.3/8.9.3) with ESMTP id HAA09557 for <[e-mail]>; Tue, 25 Jul 2000 07:15:24 -0400 (EDT)
Received: from anuxc.mv.lucent.com (h135-13-160-12.lucent.com [135.13.160.12]) by auemlsrv.firewall.lucent.com (Pro-8.9.3/8.9.3) with ESMTP id HAA09552; Tue, 25 Jul 2000 07:15:23 -0400 (EDT)
Received: from irene by anuxc.mv.lucent.com (8.8.8+Sun/EMS-1.5 sol2) id HAA05125; Tue, 25 Jul 2000 07:12:46 -0400 (EDT)
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1 
Date: Tue, 25 Jul 2000 07:02:05 -0400
To: Aram Perez <[e-mail]>
From: Irene Gassko <[e-mail]>
Subject: Re: A Real Rationale for Dedicated Keys
Cc: PKIX <[e-mail]>
In-Reply-To: <[e-mail]>
References: <02fb01bff529$10467360$[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"

Hi folks,

At 01:45 PM 07/24/2000 -0700, Aram Perez wrote:
>Hi Simon M.,
>> Hi Aram,
>>>> Much more likely is that the owner *will* show up to the CA or one of its
>>>> RAs to get a NR certificate. Anything less will probably fail to meet the
>>>> legal requirements for NR and be worth no more than a NR=0 cert.
>>> While I mostly agree, what you are stating is impractical. Very few
will use
>>> digital signatures that "meet the legal requirements for NR" if they
have to
>>> physically show up to the CA.
>> They just have to show up to an RA. You cant open a bank account without
>> showing up to a bank branch and authenticating yourself yourself. Bank staff
>> are required to sight authentication documentation usually including photo
>> ID such as a passport.
>I haven't tried, but I believe that you can open up a bank account with one
>of the "Internet Banks" without physically showing up.
>
This this true. I  opened a bank account by mail just by filling out an
application they sent me and sending them a check. I believe that 
a money order would also be fine with them. 

Irene
----------------------------------------------------------------------------
-------------------------------------------------------
Irene Gassko			 Bell Laboratories		http://www.lucent.com
Lucent Technologies		Secure Technologies Dept.
1600 Osgood Street			 phone:	[phone]
Room 30-2-A31			 e-mail: 	[e-mail]
N. Andover, MA 01845		 fax: 	[phone]


Received: from ietf.org (odin.ietf.org [132.151.1.176]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id DAA08578 for <[e-mail]>; Tue, 25 Jul 2000 03:35:10 -0700 (PDT)
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA24645; Tue, 25 Jul 2000 06:38:09 -0400 (EDT)
Message-Id: <[e-mail]>
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
Cc: [e-mail]
From: [e-mail]
Reply-to: [e-mail]
Subject: I-D ACTION:draft-ietf-pkix-technr-01.txt
Date: Tue, 25 Jul 2000 06:38:09 -0400
Sender: [e-mail]

--NextPart

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Public-Key Infrastructure (X.509) Working Group of the IETF.

	Title		: Internet X.509 Public Key Infrastructure Technical Requirements for a non-Repudiation Service
	Author(s)	: T. Gindin
	Filename	: draft-ietf-pkix-technr-01.txt
	Pages		: 7
	Date		: 24-Jul-00
	
This document describes those features of a service which processes
signed documents which must be present in order for that service to
constitute a 'technical non-repudiation' service.  A technical
non-repudiation service must permit an independent verifier to
determine whether a given signature was applied to a given data
object by the private key associated with a given valid certificate,
at a time later than the signature.  The features of a technical non-
repudiation service are expected to be necessary for a full non-
repudiation service, although they may not be sufficient.
This document is intended to clarify the definition of the
'non-repudiation' service in RFC 2459.  It should thus serve as a
guide to when the nonRepudiation bit of the keyUsage extension should
be set and to when a Certificate Authority is required to archive
CRL's.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-pkix-technr-01.txt

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-ietf-pkix-technr-01.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt


Internet-Drafts can also be obtained by e-mail.

Send a message to:
	[e-mail].
In the body type:
	"FILE /internet-drafts/draft-ietf-pkix-technr-01.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.
		
		
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"

--OtherAccess
Content-Type: Message/External-body;
	access-type="mail-server";
	server="[e-mail]"

Content-Type: text/plain
Content-ID:	<[e-mail]>

ENCODING mime
FILE /internet-drafts/draft-ietf-pkix-technr-01.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-pkix-technr-01.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID:	<[e-mail]>

--OtherAccess--

--NextPart--




Received: from prithvi.psi.soft.net (prithvi.psi.soft.net [164.164.48.3]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id AAA22534 for <[e-mail]>; Tue, 25 Jul 2000 00:31:35 -0700 (PDT)
Received: from psi.soft.net ([164.164.48.70]) by prithvi.psi.soft.net (8.9.0/8.9.0) with ESMTP id MAA15470; Tue, 25 Jul 2000 12:56:36 +0500
Message-ID: <[e-mail]>
Date: Tue, 25 Jul 2000 13:06:47 +0530
From: Venkateswara Reddy A <[e-mail]>
X-Mailer: Mozilla 4.7 [en] (WinNT; I)
X-Accept-Language: en
MIME-Version: 1.0
To: Jean Abraham <[e-mail]>, [e-mail]
Subject: Re: Signing what you don't understand
References: <[e-mail]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Jean Abraham wrote:

> Paul,
>
> Private keys are also embeded in the browser as well as on a Luna Token.
>
> MD5 or hash.... are algorithms that generate the public key and private key
> and also used for encryption purposes.

MD5 or hash algos generate public key and private key. huh

absolutely wrong stmt

regards
Venkat


> Now if a application has to be
> subverted it can only be done with the operators knowledge or the creator of
> the application.  Regarding the virus,  a virus cannot attack a private key.
> The virus creator needs to know the algorithm of the private key or the
> public key which will enable the virus to act.  Which is why any CA that
> generates end-user certificates are generated or created with utmost
> security in mind.
>
> I hope that clears everything
>
> Jean
>
> -----Original Message-----
> From: Paul Koning [mailto:[e-mail]]
> Sent: Wednesday, July 19, 2000 4:53 PM
> To: [e-mail]
> Cc: [e-mail]
> Subject: RE: Signing what you don't understand
>
> >>>>> "Jean" == Jean Abraham <[e-mail]> writes:
>
>  Jean> Digital signatures generation or creation is not based on the
>  Jean> O/S of a particular PC but on the software that is used to
>  Jean> generate it.  The most important apsect in a digital
>  Jean> certificate(which is used to create a digital signature - end
>  Jean> user) is that the private key is always with the owner and
>  Jean> never in transist.
>
> You're entirely missing the issue that started this long string of
> notes.
>
> First of all, the private key is "always with the owner" *only* if you
> have a smartcard with embedded PKI engine.  Those exist but there
> certainly are plenty of PK signing scenarios where they are not used.
>
> Second, and this is what started things, the data being signed (hash
> or whatever) are supplied to the signing engine by application
> software.  If the application is subverted (easy to do with a number
> of very popular applications) OR the underlying OS is subverted, an
> attacker can supply different data to be signed from what you thought
> you were signing.
>
> So the OS is absolutely part of the puzzle; it is not sufficient to
> consider only "the software that is used to generate [the
> signature]".  The application may well be the weakest link, of course;
> certainly in a number of well-known cases the application is indeed
> the open barn door through which the viruses enter.  But it is by no
> means the only possible barn door.
>
>        paul



Received: from d1o69.telia.com ([e-mail] [62.20.144.241]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id XAA19902 for <[e-mail]>; Mon, 24 Jul 2000 23:52:40 -0700 (PDT)
Received: from mega (t6o69p18.telia.com [213.64.110.138]) by d1o69.telia.com (8.8.8/8.8.8) with SMTP id IAA21804; Tue, 25 Jul 2000 08:55:31 +0200 (CEST)
Message-ID: <002001bff60d$971d70c0$[e-mail]>
From: "Anders Rundgren" <[e-mail]>
To: "Stephen Kent" <[e-mail]>, "Stefan Santesson" <[e-mail]>
Cc: <[e-mail]>
Subject: Re: I-D ACTION:draft-ietf-pkix-qc-05.txt
Date: Tue, 25 Jul 2000 09:54:35 +0200
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 4.72.3110.5
X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by ns.secondary.com id XAA19905

Stefan,
some comments¨


>May I draw your attention to the updated QC 05 where the uniqueness 
>requirement stated in RFC 2459 (and son of) has been clarified to count for 
>the whole lifetime of the CA.


Congratulations!
To me it seems that it is now actually possible to express a software algorithm
for comparing certificates for *equality*.  I.e. removing "handled with care"
to case A: do this (if you like).  cases B: don't try this at home kids!


>From the same section (security considerations)

"This implies that the CA must perform proof-of-possession of the
private key. In addition, it implies that the CA have some knowledge
about the subject's cryptographic module."

Why is there not a pre-defined policy attribute for specifying something
about the key container?  The Germans have it already AFIK.  It seems possible
that a single QC CA could allow different container types but some RPs may
not accept soft containers.  A commercial CA is highly likely to have to do
some compromizes like that and let "the market decide".   Then this "market"
needs a way to qualify products in a *simple* way.   It would probably work in such a way that
*if* a user ever got a soft certificate the "account" as a whole will be treated
as "soft" due to lowered security standards.  

Anders




Received: from diablo.OntheNet.com.au (diablo.OntheNet.com.au [203.10.89.2]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id XAA19153 for <[e-mail]>; Mon, 24 Jul 2000 23:45:32 -0700 (PDT)
Received: from msimon (pc3.eracom.com.au [203.144.16.147]) by diablo.OntheNet.com.au (8.9.3/8.9.3) with SMTP id QAA13398; Tue, 25 Jul 2000 16:47:54 +1000 (EST)
Message-ID: <03bd01bff605$887f3290$[e-mail]>
From: "Simon McMahon" <[e-mail]>
To: "Aram Perez" <[e-mail]>, "PKIX" <[e-mail]>
References: <[e-mail]>
Subject: Re: A Real Rationale for Dedicated Keys
Date: Tue, 25 Jul 2000 16:56:08 +1000
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.00.2314.1300
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300

Hi Aram,
>
> I haven't tried, but I believe that you can open up a bank account with
one
> of the "Internet Banks" without physically showing up.
>
They must depend on some existing on-line identity that they can
authenticate you against or not care about your identity just the amount of
$$ you can deposit with them. How safe are your funds with these banks ? How
much credit do they give you ?
>
> Again, I don't want to regurgitate last year's discussion on the validity
of
> the NR bit. I believe that you can have non-repudiation without NR=1, and
> that I can repudiate, whether or not NR=1.
>
Fair enough but this list has been discussing two uses of certificates, that
is NR-type signatures and authentication type ones (non-NR). Whether the
NR-bit is the mechanism to support that or not I dont know but it sounds
like something that should be decided soon to prevent implementations
diverging on this point and becoming less interoperable.

Regards,

Simon




Received: from popmail.inbox.se (popmail.inbox.se [193.12.72.102]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id OAA23891 for <[e-mail]>; Mon, 24 Jul 2000 14:47:31 -0700 (PDT)
Received: from santesson.accurata.se (t3o68p118.telia.com [62.20.139.118]) by popmail.inbox.se (8.9.3/8.9.3) with ESMTP id XAA08299; Mon, 24 Jul 2000 23:50:16 +0200
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Version 4.3.2
Date: Mon, 24 Jul 2000 23:51:04 +0200
To: Stephen Kent <[e-mail]>, Paul Koning <[e-mail]>
From: Stefan Santesson <[e-mail]>
Subject: Re: QC DN "qualities". Was: I-D ACTION:draft-ietf-pkix-qc-04.txt
Cc: [e-mail]
In-Reply-To: <v04220801b5a1fc3cfe4f@[171.78.30.107]>
References: <[e-mail]> <001201bff55f$457cac80$[e-mail]> <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed

May I draw your attention to the updated QC 05 where the uniqueness 
requirement stated in RFC 2459 (and son of) has been clarified to count for 
the whole lifetime of the CA.

section 2.4 now states:
    "The distinguished name MUST be unique for each subject
    entity certified by the one CA as defined by the issuer name field,
    during the whole life time of the CA."

This is actually nothing new, rather a clarification of the existing 
technical concept of DNs.
An compliant implementation can simply not be based on CA's using the same 
DN for several different entities. It is reasonable to assume that this is 
the intent behind the original X.501 definition of DNs.
    "Distinguished name is originally defined in X.501 [X.501] as a
     representation of a directory name, defined as a construct that
     identifies a particular object from among the set of all objects."

We are not talking about unintentional mistakes here (which always can 
happen) but the concept of operation.

/Stefan


At 10:02 2000-07-24 -0400, Stephen Kent wrote:
>At 9:32 AM -0400 7/24/00, Paul Koning wrote:
>>  >>>>> "Anders" == Anders Rundgren <[e-mail]> writes:
>>
>>  Anders>...
>>  Anders> Pardon the flaming tone, but I think that this discussion is
>>  Anders> purely theoretical (=totally uninteresting) as long as no
>>  Anders> representatives from any CAs have confirmed that they will
>>  Anders> reuse DNs.  Cowards?  No, pure reality....  Not a single
>>  Anders> serious CA will reuse DNs!
>>
>>I don't believe that for a moment.
>>
>>The only plausible requirement on DNs is that they are unique at a
>>given point in time.
>>
>>It is in no way credible that DNs would be unique over all time.
>>That's like saying DNS hostnames are unique over all time (i.e., once
>>I pick a name no one else may ever use that name in the future).
>>
>>To put it differently, I've *never* seen a naming system that
>>pretended to implement the "unique for all time" restriction.  Numeric
>>ID systems, sure.  (Consider the UUID in OSF RPC, copied by
>>Microsoft.)  DNs I've seen tend to consist of the usual combinations
>>of organization name, personal name, etc.  No sign ever of a
>>guaranteed not to be reused sequence number or the like that would
>>cause it to act as you claim.
>>
>>I could imagine that some CA might want to attempt to create such a
>>guarantee for some specialized purpose applied to a select set of
>>names, but to claim that every CA does this for every DN is something
>>I don't see supported by any evidence I've ever come across.
>
>Although I rarely find myself agreeing with Anders, I must do so here 
>:-).  While the phrase "for all time" may be a bit strong, it is 
>reasonable to assume that a CA can maintain records on all the subjects 
>they certify for a very long time. I believe some laws that have evolved 
>to support the use of digital signatures impose pretty strong requirements 
>on CAs to do precisely this.
>
>Steve



Received: from mta5.snfc21.pbi.net (mta5.snfc21.pbi.net [206.13.28.241]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id OAA22891 for <[e-mail]>; Mon, 24 Jul 2000 14:04:50 -0700 (PDT)
Received: from [192.168.1.71] ([208.233.228.110]) by mta5.snfc21.pbi.net (Sun Internet Mail Server sims.3.5.2000.01.05.12.18.p9) with ESMTP id <[e-mail]> for [e-mail]; Mon, 24 Jul 2000 13:44:23 -0700 (PDT)
Date: Mon, 24 Jul 2000 13:45:12 -0700
From: Aram Perez <[e-mail]>
Subject: Re: A Real Rationale for Dedicated Keys
In-reply-to: <02fb01bff529$10467360$[e-mail]>
To: PKIX <[e-mail]>
Message-id: <[e-mail]>
MIME-version: 1.0
Content-type: text/plain; charset="US-ASCII"
Content-transfer-encoding: 7bit
User-Agent: Microsoft-Outlook-Express-Macintosh-Edition/5.02.2022

Hi Simon M.,

> Hi Aram,
> 
>>> 
>>> Much more likely is that the owner *will* show up to the CA or one of
> its
>>> RAs to get a NR certificate. Anything less will probably fail to meet
> the
>>> legal requirements for NR and be worth no more than a NR=0 cert.
>> 
>> While I mostly agree, what you are stating is impractical. Very few will
> use
>> digital signatures that "meet the legal requirements for NR" if they have
> to
>> physically show up to the CA.
>> 
> They just have to show up to an RA. You cant open a bank account without
> showing up to a bank branch and authenticating yourself yourself. Bank staff
> are required to sight authentication documentation usually including photo
> ID such as a passport.

I haven't tried, but I believe that you can open up a bank account with one
of the "Internet Banks" without physically showing up.

> 
> I suspect that any commercial CA will partner with some organisation that
> has a branch network such as a Bank or Post Office to make showing up less
> of a problem. Maybe even McDonalds will get into the RA business :-). Would
> you like a certificate with that burger ?

The US Post Office has been trying to into the CA business for years without
success. And what is McDonalds going to prove? That you ordered a burger ;-)

> 
> You cant support trust to the level where NR is possible without
> authenticating the subjects and making them accountable for what they
> declare at registration time. E.g. that they understand their obligations
> regarding their private key. This really has to happen OOB since most people
> and organisations dont have an established authenticatable on-line presence.
> Perhaps at some time people and organisations will have a sufficient level
> of on-line identity so that they can be authenticated on line but they have
> to start off-line somewhere.
> 
> I would suspect that NR=1 quality certificates will start with few big
> businesses and filter down to small businesses that wish to participate,
> then to individuals who may be used to NR=0 certificates.

Again, I don't want to regurgitate last year's discussion on the validity of
the NR bit. I believe that you can have non-repudiation without NR=1, and
that I can repudiate, whether or not NR=1.

Regards,
Aram Perez



Received: from tholian.securitydynamics.com (tholian.securid.com [204.167.112.129]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id NAA21047 for <[e-mail]>; Mon, 24 Jul 2000 13:22:35 -0700 (PDT)
Received: from sdtihq24.securitydynamics.com by tholian.securitydynamics.com via smtpd (for mail.imc.org [208.184.76.43]) with SMTP; 24 Jul 2000 20:25:21 UT
Received: from exna00.securitydynamics.com (exna00.securitydynamics.com [10.2.1.110]) by sdtihq24.securid.com (Pro-8.9.3/Pro-8.9.3) with ESMTP id QAA21331 for <[e-mail]>; Mon, 24 Jul 2000 16:24:15 -0400 (EDT)
Received: by exna00.securitydynamics.com with Internet Mail Service (5.5.2448.0) id <PDC2Y976>; Mon, 24 Jul 2000 16:25:30 -0400
Message-ID: <[e-mail]>
From: "Linn, John" <[e-mail]>
To: [e-mail]
Subject: RE: I-D ACTION:draft-ietf-pkix-ipki-pkalgs-00.txt
Date: Mon, 24 Jul 2000 16:25:21 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2448.0)
Content-Type: text/plain; charset="iso-8859-1"

A few quick comments re pkalgs-00:

Some of the contents of Section 2 seem incongruous, given the
algorithm-focused scope of this document.  I'm not sure, for example,
whether or how the contents of 2.1 (about assumed communications
environments) are intended to relate to the algorithms within; this seems a
system-level issue which might fit in son-of-2459 but is a higher level of
abstraction than the algorithms discussed here.  Other subsections of
Section 2 have the same character. Also, sections 2.2 and 2.4 describe the
document's goals as specific to ECDSA; if retained, they should probably be
broadened to cover all of the algorithm families described in the document.

Per 3.1.1, an IPR statement posted earlier this year on
http://www.ietf.org/ietf/IPR/RSA-MD-all removes the PEM-specific treatment
of MD2, permitting (like MD4 and MD5) its implementation independent of
usage. 

Per 3.2.1, suggest updating PKCS #1 reference from RFC-2313 (corresponding
to PKCS #1, v. 1.5) to RFC-2437 (corresponding to PKCS #1, v. 2), which
obsoleted 2313; the defined signature method and associated OIDs are
unchanged between these versions. 

--jl
 


Received: from enigma.qualcomm.com (enigma.qualcomm.com [129.46.2.228]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id NAA20715 for <[e-mail]>; Mon, 24 Jul 2000 13:18:07 -0700 (PDT)
Received: (from root@localhost) by enigma.qualcomm.com (8.9.3/8.9.3/8.9) id NAA13405; Mon, 24 Jul 2000 13:20:30 -0700 (PDT)
Received: from qualcomm.com (qualcomm.com [192.35.156.11]) by enigma.qualcomm.com (8.9.3/8.9.3/8.9) with ESMTP id NAA13395 for <[e-mail]>; Mon, 24 Jul 2000 13:20:29 -0700 (PDT)
Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by qualcomm.com  with ESMTP id NAA15070 for <[e-mail]>; Mon, 24 Jul 2000 13:21:03 -0700 (PDT)
Received: from localhost (daemon@localhost) by ns.secondary.com (8.9.3/8.9.3) with SMTP id NAA20434; Mon, 24 Jul 2000 13:12:45 -0700 (PDT)
Received: by mail.imc.org (bulk_mailer v1.12); Mon, 24 Jul 2000 13:12:07 -0700
Received: from ntserver2.chrysalis-its.com ([209.47.245.163]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id NAA20325 for <[e-mail]>; Mon, 24 Jul 2000 13:12:06 -0700 (PDT)
From: [e-mail]
Received: by NTSERVER2 with Internet Mail Service (5.5.2650.21) id <PGAB5CB2>; Mon, 24 Jul 2000 16:15:50 -0400
Message-ID: <[e-mail]>
To: [e-mail]
Cc: [e-mail], [e-mail], [e-mail]
Subject: RE: I-D ACTION:draft-ietf-pkix-new-part1-02.txt
Date: Mon, 24 Jul 2000 16:15:35 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01BFF5AB.F534425E"
Precedence: bulk
List-Archive: http://www.imc.org/ietf-pkix/mail-archive/
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: mailto:[e-mail]?body=unsubscribe

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01BFF5AB.F534425E
Content-Type: text/plain;
	charset="iso-8859-1"

Russ,

I agree with Peter, there was a long debate on the Time Stamping draft about
the use of AIA extension. It was resolved by replacing the reference to the
AIA extension in Section 2.3 of the draft-ietf-pkix-time-stamp-08.txt
version to a reference to the Subject Information Access (SIA) extension,
which was supposed to be defined in the next version of the son of RFC2459.

Francois
___________________________________
Francois Rousseau
Director of Standards and Conformance
Chrysalis-ITS
1688 Woodward Drive
Ottawa, Ontario, CANADA, K2C 3R7
[e-mail]      Tel. [phone] ext. 419
http://www.chrysalis-its.com     Fax. [phone]



-----Original Message-----
From: Russ Housley [mailto:[e-mail]]
Sent: Monday, July 24, 2000 2:10 PM
To: Peter Sylvester
Cc: [e-mail]
Subject: Re: I-D ACTION:draft-ietf-pkix-new-part1-02.txt


It was dropped because no one found a need for the certificate to include a 
pointer to other information about the subject.  AIA is used to locate 
certificates, OCSP responders, CRLs, and so on, but there is not a similar 
requirement for the subject.

Russ


At 01:55 PM 07/24/2000 +0200, Peter Sylvester wrote:


>Some time ago I had asked the question about the history
>of the Subject Access Information which is mentioned
>in the latest time stamping draft and which was available
>at least in draft 4 of the rfc 2459, and no longer in draft 6.
>
>I might have overlooked the message explaining why it had been
>dropped.
>
>My question might also been swamped by many other message,
>thus I'd like to repeat to ask one of the document editors
>of either 2459bis or the time stamping about the current
>situation.
>
>Thanks in advance

------_=_NextPart_001_01BFF5AB.F534425E
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Diso-8859-1">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
5.5.2650.12">
<TITLE>RE: I-D ACTION:draft-ietf-pkix-new-part1-02.txt</TITLE>
</HEAD>
<BODY>

<P><FONT SIZE=3D2>Russ,</FONT>
</P>

<P><FONT SIZE=3D2>I agree with Peter, there was a long debate on the =
Time Stamping draft about the use of AIA extension. It was resolved by =
replacing the reference to the AIA extension in Section 2.3 of the =
draft-ietf-pkix-time-stamp-08.txt version to a reference to the Subject =
Information Access (SIA) extension, which was supposed to be defined in =
the next version of the son of RFC2459.</FONT></P>

<P><FONT SIZE=3D2>Francois</FONT>
<BR><FONT SIZE=3D2>___________________________________</FONT>
<BR><FONT SIZE=3D2>Francois Rousseau</FONT>
<BR><FONT SIZE=3D2>Director of Standards and Conformance</FONT>
<BR><FONT SIZE=3D2>Chrysalis-ITS</FONT>
<BR><FONT SIZE=3D2>1688 Woodward Drive</FONT>
<BR><FONT SIZE=3D2>Ottawa, Ontario, CANADA, K2C 3R7</FONT>
<BR><FONT =
SIZE=3D2>[e-mail]&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Tel. =
[phone] ext. 419</FONT>
<BR><FONT SIZE=3D2><A HREF=3D"http://www.chrysalis-its.com" =
TARGET=3D"_blank">http://www.chrysalis-its.com</A>&nbsp;&nbsp;&nbsp;&nbs=
p; Fax. [phone]</FONT>
</P>
<BR>
<BR>

<P><FONT SIZE=3D2>-----Original Message-----</FONT>
<BR><FONT SIZE=3D2>From: Russ Housley [<A =
HREF=3D"mailto:[e-mail]">mailto:[e-mail]</A>]</FONT>=

<BR><FONT SIZE=3D2>Sent: Monday, July 24, 2000 2:10 PM</FONT>
<BR><FONT SIZE=3D2>To: Peter Sylvester</FONT>
<BR><FONT SIZE=3D2>Cc: [e-mail]</FONT>
<BR><FONT SIZE=3D2>Subject: Re: I-D =
ACTION:draft-ietf-pkix-new-part1-02.txt</FONT>
</P>
<BR>

<P><FONT SIZE=3D2>It was dropped because no one found a need for the =
certificate to include a </FONT>
<BR><FONT SIZE=3D2>pointer to other information about the =
subject.&nbsp; AIA is used to locate </FONT>
<BR><FONT SIZE=3D2>certificates, OCSP responders, CRLs, and so on, but =
there is not a similar </FONT>
<BR><FONT SIZE=3D2>requirement for the subject.</FONT>
</P>

<P><FONT SIZE=3D2>Russ</FONT>
</P>
<BR>

<P><FONT SIZE=3D2>At 01:55 PM 07/24/2000 +0200, Peter Sylvester =
wrote:</FONT>
</P>
<BR>

<P><FONT SIZE=3D2>&gt;Some time ago I had asked the question about the =
history</FONT>
<BR><FONT SIZE=3D2>&gt;of the Subject Access Information which is =
mentioned</FONT>
<BR><FONT SIZE=3D2>&gt;in the latest time stamping draft and which was =
available</FONT>
<BR><FONT SIZE=3D2>&gt;at least in draft 4 of the rfc 2459, and no =
longer in draft 6.</FONT>
<BR><FONT SIZE=3D2>&gt;</FONT>
<BR><FONT SIZE=3D2>&gt;I might have overlooked the message explaining =
why it had been</FONT>
<BR><FONT SIZE=3D2>&gt;dropped.</FONT>
<BR><FONT SIZE=3D2>&gt;</FONT>
<BR><FONT SIZE=3D2>&gt;My question might also been swamped by many =
other message,</FONT>
<BR><FONT SIZE=3D2>&gt;thus I'd like to repeat to ask one of the =
document editors</FONT>
<BR><FONT SIZE=3D2>&gt;of either 2459bis or the time stamping about the =
current</FONT>
<BR><FONT SIZE=3D2>&gt;situation.</FONT>
<BR><FONT SIZE=3D2>&gt;</FONT>
<BR><FONT SIZE=3D2>&gt;Thanks in advance</FONT>
</P>

</BODY>
</HTML>
------_=_NextPart_001_01BFF5AB.F534425E--



Received: from ntserver2.chrysalis-its.com ([209.47.245.163]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id NAA20325 for <[e-mail]>; Mon, 24 Jul 2000 13:12:06 -0700 (PDT)
From: [e-mail]
Received: by NTSERVER2 with Internet Mail Service (5.5.2650.21) id <PGAB5CB2>; Mon, 24 Jul 2000 16:15:50 -0400
Message-ID: <[e-mail]>
To: [e-mail]
Cc: [e-mail], [e-mail], [e-mail]
Subject: RE: I-D ACTION:draft-ietf-pkix-new-part1-02.txt
Date: Mon, 24 Jul 2000 16:15:35 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01BFF5AB.F534425E"

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01BFF5AB.F534425E
Content-Type: text/plain;
	charset="iso-8859-1"

Russ,

I agree with Peter, there was a long debate on the Time Stamping draft about
the use of AIA extension. It was resolved by replacing the reference to the
AIA extension in Section 2.3 of the draft-ietf-pkix-time-stamp-08.txt
version to a reference to the Subject Information Access (SIA) extension,
which was supposed to be defined in the next version of the son of RFC2459.

Francois
___________________________________
Francois Rousseau
Director of Standards and Conformance
Chrysalis-ITS
1688 Woodward Drive
Ottawa, Ontario, CANADA, K2C 3R7
[e-mail]      Tel. [phone] ext. 419
http://www.chrysalis-its.com     Fax. [phone]



-----Original Message-----
From: Russ Housley [mailto:[e-mail]]
Sent: Monday, July 24, 2000 2:10 PM
To: Peter Sylvester
Cc: [e-mail]
Subject: Re: I-D ACTION:draft-ietf-pkix-new-part1-02.txt


It was dropped because no one found a need for the certificate to include a 
pointer to other information about the subject.  AIA is used to locate 
certificates, OCSP responders, CRLs, and so on, but there is not a similar 
requirement for the subject.

Russ


At 01:55 PM 07/24/2000 +0200, Peter Sylvester wrote:


>Some time ago I had asked the question about the history
>of the Subject Access Information which is mentioned
>in the latest time stamping draft and which was available
>at least in draft 4 of the rfc 2459, and no longer in draft 6.
>
>I might have overlooked the message explaining why it had been
>dropped.
>
>My question might also been swamped by many other message,
>thus I'd like to repeat to ask one of the document editors
>of either 2459bis or the time stamping about the current
>situation.
>
>Thanks in advance

------_=_NextPart_001_01BFF5AB.F534425E
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Diso-8859-1">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
5.5.2650.12">
<TITLE>RE: I-D ACTION:draft-ietf-pkix-new-part1-02.txt</TITLE>
</HEAD>
<BODY>

<P><FONT SIZE=3D2>Russ,</FONT>
</P>

<P><FONT SIZE=3D2>I agree with Peter, there was a long debate on the =
Time Stamping draft about the use of AIA extension. It was resolved by =
replacing the reference to the AIA extension in Section 2.3 of the =
draft-ietf-pkix-time-stamp-08.txt version to a reference to the Subject =
Information Access (SIA) extension, which was supposed to be defined in =
the next version of the son of RFC2459.</FONT></P>

<P><FONT SIZE=3D2>Francois</FONT>
<BR><FONT SIZE=3D2>___________________________________</FONT>
<BR><FONT SIZE=3D2>Francois Rousseau</FONT>
<BR><FONT SIZE=3D2>Director of Standards and Conformance</FONT>
<BR><FONT SIZE=3D2>Chrysalis-ITS</FONT>
<BR><FONT SIZE=3D2>1688 Woodward Drive</FONT>
<BR><FONT SIZE=3D2>Ottawa, Ontario, CANADA, K2C 3R7</FONT>
<BR><FONT =
SIZE=3D2>[e-mail]&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Tel. =
[phone] ext. 419</FONT>
<BR><FONT SIZE=3D2><A HREF=3D"http://www.chrysalis-its.com" =
TARGET=3D"_blank">http://www.chrysalis-its.com</A>&nbsp;&nbsp;&nbsp;&nbs=
p; Fax. [phone]</FONT>
</P>
<BR>
<BR>

<P><FONT SIZE=3D2>-----Original Message-----</FONT>
<BR><FONT SIZE=3D2>From: Russ Housley [<A =
HREF=3D"mailto:[e-mail]">mailto:[e-mail]</A>]</FONT>=

<BR><FONT SIZE=3D2>Sent: Monday, July 24, 2000 2:10 PM</FONT>
<BR><FONT SIZE=3D2>To: Peter Sylvester</FONT>
<BR><FONT SIZE=3D2>Cc: [e-mail]</FONT>
<BR><FONT SIZE=3D2>Subject: Re: I-D =
ACTION:draft-ietf-pkix-new-part1-02.txt</FONT>
</P>
<BR>

<P><FONT SIZE=3D2>It was dropped because no one found a need for the =
certificate to include a </FONT>
<BR><FONT SIZE=3D2>pointer to other information about the =
subject.&nbsp; AIA is used to locate </FONT>
<BR><FONT SIZE=3D2>certificates, OCSP responders, CRLs, and so on, but =
there is not a similar </FONT>
<BR><FONT SIZE=3D2>requirement for the subject.</FONT>
</P>

<P><FONT SIZE=3D2>Russ</FONT>
</P>
<BR>

<P><FONT SIZE=3D2>At 01:55 PM 07/24/2000 +0200, Peter Sylvester =
wrote:</FONT>
</P>
<BR>

<P><FONT SIZE=3D2>&gt;Some time ago I had asked the question about the =
history</FONT>
<BR><FONT SIZE=3D2>&gt;of the Subject Access Information which is =
mentioned</FONT>
<BR><FONT SIZE=3D2>&gt;in the latest time stamping draft and which was =
available</FONT>
<BR><FONT SIZE=3D2>&gt;at least in draft 4 of the rfc 2459, and no =
longer in draft 6.</FONT>
<BR><FONT SIZE=3D2>&gt;</FONT>
<BR><FONT SIZE=3D2>&gt;I might have overlooked the message explaining =
why it had been</FONT>
<BR><FONT SIZE=3D2>&gt;dropped.</FONT>
<BR><FONT SIZE=3D2>&gt;</FONT>
<BR><FONT SIZE=3D2>&gt;My question might also been swamped by many =
other message,</FONT>
<BR><FONT SIZE=3D2>&gt;thus I'd like to repeat to ask one of the =
document editors</FONT>
<BR><FONT SIZE=3D2>&gt;of either 2459bis or the time stamping about the =
current</FONT>
<BR><FONT SIZE=3D2>&gt;situation.</FONT>
<BR><FONT SIZE=3D2>&gt;</FONT>
<BR><FONT SIZE=3D2>&gt;Thanks in advance</FONT>
</P>

</BODY>
</HTML>
------_=_NextPart_001_01BFF5AB.F534425E--


Received: from mail.spyrus.com (mail.spyrus.com [207.212.34.20]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id LAA17905 for <[e-mail]>; Mon, 24 Jul 2000 11:08:09 -0700 (PDT)
Received: from rhousley_laptop ([209.172.119.205]) by mail.spyrus.com (8.9.3/8.9.3) with ESMTP id LAA06588; Mon, 24 Jul 2000 11:10:30 -0700 (PDT)
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58 
Date: Mon, 24 Jul 2000 14:09:54 -0400
To: Peter Sylvester <[e-mail]>
From: Russ Housley <[e-mail]>
Subject: Re: I-D ACTION:draft-ietf-pkix-new-part1-02.txt
Cc: [e-mail]
In-Reply-To: <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed

It was dropped because no one found a need for the certificate to include a 
pointer to other information about the subject.  AIA is used to locate 
certificates, OCSP responders, CRLs, and so on, but there is not a similar 
requirement for the subject.

Russ


At 01:55 PM 07/24/2000 +0200, Peter Sylvester wrote:


>Some time ago I had asked the question about the history
>of the Subject Access Information which is mentioned
>in the latest time stamping draft and which was available
>at least in draft 4 of the rfc 2459, and no longer in draft 6.
>
>I might have overlooked the message explaining why it had been
>dropped.
>
>My question might also been swamped by many other message,
>thus I'd like to repeat to ask one of the document editors
>of either 2459bis or the time stamping about the current
>situation.
>
>Thanks in advance



Received: from mail.spyrus.com (mail.spyrus.com [207.212.34.20]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id IAA14715 for <[e-mail]>; Mon, 24 Jul 2000 08:44:12 -0700 (PDT)
Received: from rhousley_laptop ([209.172.119.205]) by mail.spyrus.com (8.9.3/8.9.3) with ESMTP id IAA04388; Mon, 24 Jul 2000 08:46:01 -0700 (PDT)
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58 
Date: Sat, 22 Jul 2000 16:13:04 -0400
To: "Bob Jueneman" <[e-mail]>
From: Russ Housley <[e-mail]>
Subject: Re: Dual-signed certificates
Cc: <[e-mail]>, <[e-mail]>, <[e-mail]>
In-Reply-To: <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed

Bob:

There are some significant technical issues here.  The subject cannot sign 
first because it does not know the values that will be assigned for several 
fields, like the serial number.  The subject cannot sign second 
either.  The insertion of an additional extension will break the issuer 
signature.

Thus, to proceed in this vain, complex processing must be defined that says 
which parts of the certificate a re coved by the subject signature in the 
extension.  I think that the processing is complex enough....

Russ


At 10:41 AM 07/21/2000 -0600, Bob Jueneman wrote:
>Ben,
>
>[snip]
>
> >Since a certificate is comprised of public information signed by a CA,
> >clearly a CA can create a certificate saying more-or-less what they
> >want. I suppose this is an argument for having certificates that are
> >dual-signed (by the CA and the public key the contain).
>
>Duh!  Head-slapping!  What a great idea!  I'd love to see this added to
>X.509 v3 as an optional, noncritical extension.
>
>For years, especially within the ABA, we have talked about the need
>for the user to explicitly confirm acceptance of the certificate, but at 
>present
>there is no good way to confirm acceptance, except by procedures
>that are not verifiable by any relying party.  Obviously, having the user
>sign the certificate herself would confirm acceptance.
>
>Now, granted, if a rogue CA wanted to create a bogus certificate
>containing my name and their public key, they could also sign the
>certificate, since they would possess the private key.
>
>However, this threat tends to evaporate as soon as the real user signs
>something which in all likelihood only that user could have done.
>and the more transactions that are signed, the more confidence that
>it really is the user -- in fact irrespective of the certificate, because the
>confidence in a signature tends to increase though repetitive use.
>
>As an aside, I sometimes get into arguments with people about whether,
>and how, trusted roots should be incorporated within browsers, etc.
>
>My experience is that I often receive a signed e-mail from someone whose
>root is not in my cache of trusted roots.  Because in most cases the 
>authentication
>of the user isn't exactly life and death (users who post to this list, for 
>example),
>I tend to click OK and add that root to my cache.  Now, one certificate
>authenticated by that root doesn't prove much, but by the time I've received
>three or four certificates all signed by the US DOD Medium Assurance CA,
>for example, I have a greatly increased confidence that that root is bone 
>fide.
>
>Bob



Received: from po1.bbn.com (PO1.BBN.COM [192.1.50.38]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id HAA06758 for <[e-mail]>; Mon, 24 Jul 2000 07:00:54 -0700 (PDT)
Received: from [171.78.30.107] (fixed030-107.bbn.com [171.78.30.107] (may be forged)) by po1.bbn.com (8.9.1/8.9.1) with ESMTP id KAA10980; Mon, 24 Jul 2000 10:03:45 -0400 (EDT)
Mime-Version: 1.0
X-Sender: [e-mail]
Message-Id: <v04220801b5a1fc3cfe4f@[171.78.30.107]>
In-Reply-To: <[e-mail]>
References: <001201bff55f$457cac80$[e-mail]> <[e-mail]>
Date: Mon, 24 Jul 2000 10:02:39 -0400
To: Paul Koning <[e-mail]>
From: Stephen Kent <[e-mail]>
Subject: Re: QC DN "qualities". Was: I-D ACTION:draft-ietf-pkix-qc-04.txt
Cc: [e-mail]
Content-Type: text/plain; charset="us-ascii" ; format="flowed"

At 9:32 AM -0400 7/24/00, Paul Koning wrote:
>  >>>>> "Anders" == Anders Rundgren <[e-mail]> writes:
>
>  Anders>...
>  Anders> Pardon the flaming tone, but I think that this discussion is
>  Anders> purely theoretical (=totally uninteresting) as long as no
>  Anders> representatives from any CAs have confirmed that they will
>  Anders> reuse DNs.  Cowards?  No, pure reality....  Not a single
>  Anders> serious CA will reuse DNs!
>
>I don't believe that for a moment.
>
>The only plausible requirement on DNs is that they are unique at a
>given point in time.
>
>It is in no way credible that DNs would be unique over all time.
>That's like saying DNS hostnames are unique over all time (i.e., once
>I pick a name no one else may ever use that name in the future).
>
>To put it differently, I've *never* seen a naming system that
>pretended to implement the "unique for all time" restriction.  Numeric
>ID systems, sure.  (Consider the UUID in OSF RPC, copied by
>Microsoft.)  DNs I've seen tend to consist of the usual combinations
>of organization name, personal name, etc.  No sign ever of a
>guaranteed not to be reused sequence number or the like that would
>cause it to act as you claim.
>
>I could imagine that some CA might want to attempt to create such a
>guarantee for some specialized purpose applied to a select set of
>names, but to claim that every CA does this for every DN is something
>I don't see supported by any evidence I've ever come across.

Although I rarely find myself agreeing with Anders, I must do so here 
:-).  While the phrase "for all time" may be a bit strong, it is 
reasonable to assume that a CA can maintain records on all the 
subjects they certify for a very long time. I believe some laws that 
have evolved to support the use of digital signatures impose pretty 
strong requirements on CAs to do precisely this.

Steve



Received: from dfw7-1.relay.mail.uu.net (dfw7-1.relay.mail.uu.net [199.171.54.106]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id GAA05674 for <[e-mail]>; Mon, 24 Jul 2000 06:29:38 -0700 (PDT)
Received: from xedia.com by dfw7sosrv11.alter.net with SMTP  (peer crosschecked as: madway.xedia.com [198.202.232.199]) id QQizfq09622; Mon, 24 Jul 2000 13:32:15 GMT
Received: from tonga.xedia.com by xedia.com (4.1/SMI-4.1) id AA16626; Mon, 24 Jul 00 09:28:19 EDT
Received: by tonga.xedia.com (SMI-8.6/SMI-SVR4) id JAA16355; Mon, 24 Jul 2000 09:32:14 -0400
From: Paul Koning <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-Id: <[e-mail]>
Date: Mon, 24 Jul 2000 09:32:13 -0400 (EDT)
To: [e-mail]
Cc: [e-mail], [e-mail], [e-mail]
Subject: Re: QC DN "qualities". Was: I-D ACTION:draft-ietf-pkix-qc-04.txt
References: <001201bff55f$457cac80$[e-mail]>
X-Mailer: VM 6.72 under 21.1 (patch 9) "Canyonlands" XEmacs Lucid

>>>>> "Anders" == Anders Rundgren <[e-mail]> writes:

 Anders>...
 Anders> Pardon the flaming tone, but I think that this discussion is
 Anders> purely theoretical (=totally uninteresting) as long as no
 Anders> representatives from any CAs have confirmed that they will
 Anders> reuse DNs.  Cowards?  No, pure reality....  Not a single
 Anders> serious CA will reuse DNs!

I don't believe that for a moment.

The only plausible requirement on DNs is that they are unique at a
given point in time.

It is in no way credible that DNs would be unique over all time.
That's like saying DNS hostnames are unique over all time (i.e., once
I pick a name no one else may ever use that name in the future).

To put it differently, I've *never* seen a naming system that
pretended to implement the "unique for all time" restriction.  Numeric
ID systems, sure.  (Consider the UUID in OSF RPC, copied by
Microsoft.)  DNs I've seen tend to consist of the usual combinations
of organization name, personal name, etc.  No sign ever of a
guaranteed not to be reused sequence number or the like that would
cause it to act as you claim.

I could imagine that some CA might want to attempt to create such a
guarantee for some specialized purpose applied to a select set of
names, but to claim that every CA does this for every DN is something
I don't see supported by any evidence I've ever come across.

     paul


Received: from edelweb.fr (edelweb.fr [193.51.12.16]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id GAA04960 for <[e-mail]>; Mon, 24 Jul 2000 06:07:22 -0700 (PDT)
Received: from champagne.edelweb.fr (localhost.edelweb.fr [127.0.0.1]) by edelweb.fr with ESMTP id PAA00306; Mon, 24 Jul 2000 15:10:18 +0200 (MET DST)
Received: from champagne.edelweb.fr (champagne.edelweb.fr [193.51.14.161]) by edelweb.fr (nospam/1.3); Mon, 24 Jul 2000 15:10:18 +0200 (MET DST)
Received: from emeriau.edelweb.fr (emeriau.edelweb.fr [193.51.14.5]) by champagne.edelweb.fr (8.7.6/8.6.6) with ESMTP id PAA12809; Mon, 24 Jul 2000 15:10:16 +0200 (MET DST)
From: Peter Sylvester <[e-mail]>
Received: (sylvest@localhost) by emeriau.edelweb.fr (8.7.6/8.6.6) id PAA27558; Mon, 24 Jul 2000 15:10:16 +0200 (MET DST)
Date: Mon, 24 Jul 2000 15:10:16 +0200 (MET DST)
Message-Id: <[e-mail]>
To: [e-mail], [e-mail]
Subject: Re: QC DN "qualities". Was: I-D ACTION:draft-ietf-pkix-qc-04.txt

Since I have been CC:ed in this, here it goes. 

> Peter,
> 
> I have a feeling that this discussion has not much to do with technicalties.
Are you negatively criticising or appreaciating this? Do you want
to discuss techniques or other things? 

You are asking for a technical big brother feature that can be exploited
by RPs in order to solve a possible organisational problem, and this
technical final solution is not exactly acceptable in many places.


> It will be the *market* that will tell what is right and what is wrong!
Since I do not really know what you mean by market, and since I do
not agree with your first sentence I am not sure what I should answer. 
At least this is not a technical comment.

> 
> I don't think that the guys who sell certs with non-unique/resissued DNs will be very
> successful.  And that is what counts seen from my $-perspective.
IMHO a CA will do what the RPs require, and not the other way around. See below.
But this again is not a technical comment, so I don't care. 

> 
> You and Ed and other firm believers in other models will have to prove
> that there is a market for your ideas otherwise you will just find that your
> (probably) home-brewed certificates aren't accepted in too many places.
I am not clear of what model you are talking. If your model is that
you get a unique ID after birth tatooed on you body in a bar code together
with an implanted electronic device inside your body, no I do not
believe in that. I believe that technology is a means to help people
to live together or alone, and the technology can never require to
change organisational and cultural principles.

I don't have to prove anything, and I never had talked about what I think
would be a market, at least not recently during this thread (threat?) .

> 
> Pardon the flaming tone, but I think that this discussion is purely theoretical
> (=totally uninteresting) as long as no representatives from any CAs
> have confirmed that they will reuse DNs.  Cowards?  No, pure reality....
Request accepted, this applies also to me :-)

This is theoretical even when CAs will talk; as long as you do not know
what the requirement from RPs,  = application contexts,
the discussion is also useless.

> Not a single serious CA will reuse DNs! 
I have never said the contrary, nor did I confirm that. This depends on the
understanding and the context on how DN are constructed. 

If you allow to rely on that in any application context, you explicitely
put a requireemnt on the CA operator in a standard.  

If in a application context a CA operates the certificate management in that way, 
RPs may or may not rely on that, for example a tax payer ID is probabaly never allocated
twice. But this ID is created in the beginning in such a way that avoids
collisions. 

Or in other words, at least, I do not see that a CA would reuse a DN, 
if there is anything left to get to the old information by some reasonable means.  

> 
> >> Actually the only reason for me requiring that DNs are not reused is to cope with
> >> (the highly likely) situation where a user "shows" a newly issued cert containing 
> >> a DN/CA that the particular RP already knows about.  It should be a no-brainer
> >> (=pure/simple/stupid software algorithm) to conclude that it is the same person. 
> >> 
> >Which can be done differently: You sign with the old cert and the new cert a doc
> >explaining that this belongs to the same person. 
> 
> Which requires that the old certs still exists which is not the case if you dropt it somewhere.
So: get the CA give you that statement of equivalence. This CAN be done
by reusing the DN, but you can also be done differently. 

If you loose everything of your identity, and you go to the RA
asking that you need a replacement of something that you do no longer 
have, what are you doing to prove that your are really the person?

> 
> >Or, in other words, the
> >equivalence will be established explicitely by the only interested party,
> >and not implicitely in an error prone way.
> 
> In what way (again assuming that the CA "knows" its subjects and do not reissue DNs) 
> whould my proposal be error-prone?

If you don't have to rely on something, you cannot have an error. 

If you rely on that, and either in the context of successor CAs or multiple
CAs, you just have at least moved the 'cert equivalence' problem to a CA cert equivalence
problem. 

How do you know that it is the same CA that issues the data? How do you
establish in a correct way the fact that two certs represent the same entity when
several CAs are involved? 

Or, I would like to see the simple algorithm to determine whether two certs
are identical, even in case of CA cert roll-over or replacement etc. 


W
/PS


Received: from fep03-svc.tin.it (mta03-acc.tin.it [212.216.176.34]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id FAA04521 for <[e-mail]>; Mon, 24 Jul 2000 05:51:58 -0700 (PDT)
From: [e-mail]
Received: from fep12-svc.tin.it ([212.216.177.132]) by fep03-svc.tin.it (InterMail vM.4.01.02.27 201-229-119-110) with ESMTP id <[e-mail]> for <[e-mail]>; Mon, 24 Jul 2000 14:54:10 +0200
To: <[e-mail]>
Reply-To: [e-mail]
Subject: Re: Dual-signed certificates: Attribute Certificate ??
MIME-Version: 1.0
Content-Type: text/plain
Message-Id: <[e-mail]>
Date: Mon, 24 Jul 2000 14:54:10 +0200

Maybe this can be considered out of topic, but following this
discussion it came in to my mind a well established procedure that in
Italy
dramatically speeds up the relationships with public administration
bureaucracy, this is called "auto certificazione" (litteraly self
certification). In a few words, everyone can self sign and subscribe
declarations about his status (civil status, domicile, family status,
etc.)
and use this declarations, together with Identity card, when interacting
with civil autorities.
For a digital equivalent my first thought is about attribute certificates,
I am not very familiar with AC and I don't know if this can be achieved
with
present specifications and profile.
Perhaps something like self signed AC can be useful not only for public
administration but also for enterprise PKI for attributes that are not
delegated to specific attribute autorithy but are under the direct
responsability of the employee.

Sergio Tabanelli
Project Manager & Consultant
Fabbrica Servizi Telematici (FST)
[e-mail]



Received: from edelweb.fr (edelweb.fr [193.51.12.16]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id EAA03411 for <[e-mail]>; Mon, 24 Jul 2000 04:52:28 -0700 (PDT)
Received: from champagne.edelweb.fr (localhost.edelweb.fr [127.0.0.1]) by edelweb.fr with ESMTP id NAA29549 for <[e-mail]>; Mon, 24 Jul 2000 13:55:23 +0200 (MET DST)
Received: from champagne.edelweb.fr (champagne.edelweb.fr [193.51.14.161]) by edelweb.fr (nospam/1.3); Mon, 24 Jul 2000 13:55:23 +0200 (MET DST)
Received: from emeriau.edelweb.fr (emeriau.edelweb.fr [193.51.14.5]) by champagne.edelweb.fr (8.7.6/8.6.6) with ESMTP id NAA12294 for <[e-mail]>; Mon, 24 Jul 2000 13:55:22 +0200 (MET DST)
From: Peter Sylvester <[e-mail]>
Received: (sylvest@localhost) by emeriau.edelweb.fr (8.7.6/8.6.6) id NAA27533 for [e-mail]; Mon, 24 Jul 2000 13:55:22 +0200 (MET DST)
Date: Mon, 24 Jul 2000 13:55:22 +0200 (MET DST)
Message-Id: <[e-mail]>
To: [e-mail]
Subject: Re: I-D ACTION:draft-ietf-pkix-new-part1-02.txt

Some time ago I had asked the question about the history
of the Subject Access Information which is mentioned
in the latest time stamping draft and which was available
at least in draft 4 of the rfc 2459, and no longer in draft 6.

I might have overlooked the message explaining why it had been
dropped. 

My question might also been swamped by many other message,
thus I'd like to repeat to ask one of the document editors
of either 2459bis or the time stamping about the current
situation.  

Thanks in advance


Received: from ietf.org (odin.ietf.org [132.151.1.176]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id DAA01680 for <[e-mail]>; Mon, 24 Jul 2000 03:35:11 -0700 (PDT)
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA09123; Mon, 24 Jul 2000 06:38:06 -0400 (EDT)
Message-Id: <[e-mail]>
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
Cc: [e-mail]
From: [e-mail]
Reply-to: [e-mail]
Subject: I-D ACTION:draft-ietf-pkix-cmp-transport-protocols-01.txt
Date: Mon, 24 Jul 2000 06:38:06 -0400
Sender: [e-mail]

--NextPart

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Public-Key Infrastructure (X.509) Working Group of the IETF.

	Title		: Transport Protocols for CMP
	Author(s)	: A. Kapoor, R. Tschalar
	Filename	: draft-ietf-pkix-cmp-transport-protocols-01.txt
	Pages		: 
	Date		: 21-Jul-00
	
This document describes how to layer Certificate Management
Protocols [CMP] over various transport protocols.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-pkix-cmp-transport-protocols-01.txt

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-ietf-pkix-cmp-transport-protocols-01.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt


Internet-Drafts can also be obtained by e-mail.

Send a message to:
	[e-mail].
In the body type:
	"FILE /internet-drafts/draft-ietf-pkix-cmp-transport-protocols-01.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.
		
		
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"

--OtherAccess
Content-Type: Message/External-body;
	access-type="mail-server";
	server="[e-mail]"

Content-Type: text/plain
Content-ID:	<[e-mail]>

ENCODING mime
FILE /internet-drafts/draft-ietf-pkix-cmp-transport-protocols-01.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-pkix-cmp-transport-protocols-01.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID:	<[e-mail]>

--OtherAccess--

--NextPart--




Received: from ietf.org (odin.ietf.org [132.151.1.176]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id DAA01631 for <[e-mail]>; Mon, 24 Jul 2000 03:35:06 -0700 (PDT)
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA09111; Mon, 24 Jul 2000 06:38:02 -0400 (EDT)
Message-Id: <[e-mail]>
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
Cc: [e-mail]
From: [e-mail]
Reply-to: [e-mail]
Subject: I-D ACTION:draft-ietf-pkix-pkixrep-00.txt
Date: Mon, 24 Jul 2000 06:38:02 -0400
Sender: [e-mail]

--NextPart

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Public-Key Infrastructure (X.509) Working Group of the IETF.

	Title		: Internet X.509 Public Key Infrastructure Repository 
                          Locator Service
	Author(s)	: S. Boeyen, P. Hallam-Baker
	Filename	: draft-ietf-pkix-pkixrep-00.txt
	Pages		: 3
	Date		: 21-Jul-00
	
This document defines a PKI repository locator service. The service
makes use of DNS SRV records defined in accordance with RFC 2782. The
service enables certificate using systems to locate PKI repositories 
based on a domain name, identify the protocols that can be used to 
access the repository, and obtain addresses for the servers that host 
the repository service.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-pkix-pkixrep-00.txt

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-ietf-pkix-pkixrep-00.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt


Internet-Drafts can also be obtained by e-mail.

Send a message to:
	[e-mail].
In the body type:
	"FILE /internet-drafts/draft-ietf-pkix-pkixrep-00.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.
		
		
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"

--OtherAccess
Content-Type: Message/External-body;
	access-type="mail-server";
	server="[e-mail]"

Content-Type: text/plain
Content-ID:	<[e-mail]>

ENCODING mime
FILE /internet-drafts/draft-ietf-pkix-pkixrep-00.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-pkix-pkixrep-00.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID:	<[e-mail]>

--OtherAccess--

--NextPart--




Received: from ietf.org (odin.ietf.org [132.151.1.176]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id DAA01569 for <[e-mail]>; Mon, 24 Jul 2000 03:35:02 -0700 (PDT)
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA09067; Mon, 24 Jul 2000 06:37:57 -0400 (EDT)
Message-Id: <[e-mail]>
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
Cc: [e-mail]
From: [e-mail]
Reply-to: [e-mail]
Subject: I-D ACTION:draft-ietf-pkix-qc-05.txt
Date: Mon, 24 Jul 2000 06:37:57 -0400
Sender: [e-mail]

--NextPart

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Public-Key Infrastructure (X.509) Working Group of the IETF.

	Title		: Internet X.509 Public Key Infrastructure Qualified 
                          Certificates Profile
	Author(s)	: S. Santesson, T. Polk, P. Barzin, M. Nystrom
	Filename	: draft-ietf-pkix-qc-05.txt
	Pages		: 34
	Date		: 21-Jul-00
	
This document forms a certificate profile for Qualified Certificates,
based on RFC 2459, for use in the Internet. The term Qualified
Certificate is used to describe a certificate with a certain
qualified status within applicable governing law. Further, Qualified
Certificates are issued exclusively to physical persons.
The goal of this document is to define a general syntax independent
of local legal requirements. The profile is however designed to allow
further profiling in order to meet specific local needs.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-pkix-qc-05.txt

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-ietf-pkix-qc-05.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt


Internet-Drafts can also be obtained by e-mail.

Send a message to:
	[e-mail].
In the body type:
	"FILE /internet-drafts/draft-ietf-pkix-qc-05.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.
		
		
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"

--OtherAccess
Content-Type: Message/External-body;
	access-type="mail-server";
	server="[e-mail]"

Content-Type: text/plain
Content-ID:	<[e-mail]>

ENCODING mime
FILE /internet-drafts/draft-ietf-pkix-qc-05.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-pkix-qc-05.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID:	<[e-mail]>

--OtherAccess--

--NextPart--




Received: from ietf.org (odin.ietf.org [132.151.1.176]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id DAA01556 for <[e-mail]>; Mon, 24 Jul 2000 03:34:57 -0700 (PDT)
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA09042; Mon, 24 Jul 2000 06:37:53 -0400 (EDT)
Message-Id: <[e-mail]>
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
Cc: [e-mail]
From: [e-mail]
Reply-to: [e-mail]
Subject: I-D ACTION:draft-ietf-pkix-ipki-pkalgs-00.txt
Date: Mon, 24 Jul 2000 06:37:52 -0400
Sender: [e-mail]

--NextPart

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Public-Key Infrastructure (X.509) Working Group of the IETF.

	Title		: Internet X.509 Public Key Infrastructure    
                          Representation of Public Keys and Digital Signatures
                          in Internet X.509 Public Key Infrastructure  
                          Certificates
	Author(s)	: L. Bassham, R. Housley, W. Polk
	Filename	: draft-ietf-pkix-ipki-pkalgs-00.txt
	Pages		: 28
	Date		: 21-Jul-00
	
This is the first draft of a specification of algorithm identifiers
and encoding formats for the representation of cryptographic keys,
associated parameters and digital sigantures in Internet Public Key
Infrastructure X.509 certificates and certificate revocation lists.
This specification was created by combining Section 7, Cryptographic
Support, from RFC 2459 with the Internet-Draft 'Representation of
Elliptic Curve Digital Signature Algorithm (ECDSA) Keys and
Signatures in Internet X.509 Public Key Infrastructure Certificates'.
This specification is a companion to the 'son of 2459';
implementations must also conform to 'son of 2459'.  This document
does not define the cryptographic algorithms themselves; instead, it
references other appropriate standards.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-pkix-ipki-pkalgs-00.txt

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-ietf-pkix-ipki-pkalgs-00.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt


Internet-Drafts can also be obtained by e-mail.

Send a message to:
	[e-mail].
In the body type:
	"FILE /internet-drafts/draft-ietf-pkix-ipki-pkalgs-00.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.
		
		
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"

--OtherAccess
Content-Type: Message/External-body;
	access-type="mail-server";
	server="[e-mail]"

Content-Type: text/plain
Content-ID:	<[e-mail]>

ENCODING mime
FILE /internet-drafts/draft-ietf-pkix-ipki-pkalgs-00.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-pkix-ipki-pkalgs-00.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID:	<[e-mail]>

--OtherAccess--

--NextPart--




Received: from ietf.org (odin.ietf.org [132.151.1.176]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id DAA01544 for <[e-mail]>; Mon, 24 Jul 2000 03:34:52 -0700 (PDT)
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA08995; Mon, 24 Jul 2000 06:37:48 -0400 (EDT)
Message-Id: <[e-mail]>
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
Cc: [e-mail]
From: [e-mail]
Reply-to: [e-mail]
Subject: I-D ACTION:draft-ietf-pkix-new-part1-02.txt
Date: Mon, 24 Jul 2000 06:37:48 -0400
Sender: [e-mail]

--NextPart

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Public-Key Infrastructure (X.509) Working Group of the IETF.

	Title		: Internet X.509 Public Key Infrastructure
                          Certificate and CRL Profile
	Author(s)	: R. Housley, W. Ford, W. Polk, D. Solo
	Filename	: draft-ietf-pkix-new-part1-02.txt
	Pages		: 115
	Date		: 21-Jul-00
	
This is the first draft of a specification based upon RFC 2459.  When
complete, this specification will obsolete RFC 2459.  This
specification includes numerous edits and clarifications.  The most
notable departures from RFC 2459 are found in Section 6, Path
Validation.  In RFC 2459, the reader was expected to augment the path
validation algorithm, which concentrated upon policy processing, with
information embedded in earlier sections.  For example, parameter
inheritance is discussed in Section 7, Algorithm Support, and can
certainly affect the validity of a certification path.  However,
parameter inheritance was omitted from the path validation algorithm in RFC 2459.  In this draft, the path validation algorithm has a
comprehensive and extremely detailed description.  Details such as
parameter inheritance are covered thoroughly.  In addition, this
draft anticipates certain corrections proposed in the X.509 standard
for the policy processing aspects of path validation.
A new section 6.3, CRL validation, has been added as well.  This
section provides a supplement to the path validation algorithm that
determines if a particular CRL may be used to verify the status of a
particular certificate.  (The basic path validation algorithm is, by
design, independent of the type and format of status information.)
This memo profiles the X.509 v3 certificate and X.509 v2 CRL for use
in the Internet.  An overview of the approach and model are provided
as an introduction.  The X.509 v3 certificate format is described in
detail, with additional information regarding the format and
semantics of Internet name forms (e.g., IP addresses).  Standard
certificate extensions are described and one new Internet-specific
extension is defined.  A required set of certificate extensions is
specified.  The X.509 v2 CRL format is described and a required
extension set is defined as well.  An algorithm for X.509 certificate
path validation is described. Supplemental infor

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-pkix-new-part1-02.txt

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-ietf-pkix-new-part1-02.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt


Internet-Drafts can also be obtained by e-mail.

Send a message to:
	[e-mail].
In the body type:
	"FILE /internet-drafts/draft-ietf-pkix-new-part1-02.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.
		
		
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"

--OtherAccess
Content-Type: Message/External-body;
	access-type="mail-server";
	server="[e-mail]"

Content-Type: text/plain
Content-ID:	<[e-mail]>

ENCODING mime
FILE /internet-drafts/draft-ietf-pkix-new-part1-02.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-pkix-new-part1-02.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID:	<[e-mail]>

--OtherAccess--

--NextPart--




Received: from d1o69.telia.com ([e-mail] [62.20.144.241]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id DAA28622 for <[e-mail]>; Mon, 24 Jul 2000 03:04:52 -0700 (PDT)
Received: from mega (t4o69p36.telia.com [62.20.145.156]) by d1o69.telia.com (8.8.8/8.8.8) with SMTP id MAA12606; Mon, 24 Jul 2000 12:07:46 +0200 (CEST)
Message-ID: <001201bff55f$457cac80$[e-mail]>
From: "Anders Rundgren" <[e-mail]>
To: "PKIX-List" <[e-mail]>, "Peter Sylvester" <[e-mail]>
Cc: "Ed Gerck" <[e-mail]>
Subject: Re: QC DN "qualities". Was: I-D ACTION:draft-ietf-pkix-qc-04.txt
Date: Mon, 24 Jul 2000 13:06:51 +0200
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 4.72.3110.5
X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by ns.secondary.com id DAA28623

Peter,

I have a feeling that this discussion has not much to do with technicalties.
It will be the *market* that will tell what is right and what is wrong!

I don't think that the guys who sell certs with non-unique/resissued DNs will be very
successful.  And that is what counts seen from my $-perspective.

You and Ed and other firm believers in other models will have to prove
that there is a market for your ideas otherwise you will just find that your
(probably) home-brewed certificates aren't accepted in too many places.

Pardon the flaming tone, but I think that this discussion is purely theoretical
(=totally uninteresting) as long as no representatives from any CAs
have confirmed that they will reuse DNs.  Cowards?  No, pure reality....
Not a single serious CA will reuse DNs! 

Anders


>> Actually the only reason for me requiring that DNs are not reused is to cope with
>> (the highly likely) situation where a user "shows" a newly issued cert containing 
>> a DN/CA that the particular RP already knows about.  It should be a no-brainer
>> (=pure/simple/stupid software algorithm) to conclude that it is the same person. 
>> 
>Which can be done differently: You sign with the old cert and the new cert a doc
>explaining that this belongs to the same person. 

Which requires that the old certs still exists which is not the case if you dropt it somewhere.

>Or, in other words, the
>equivalence will be established explicitely by the only interested party,
>and not implicitely in an error prone way.

In what way (again assuming that the CA "knows" its subjects and do not reissue DNs) 
whould my proposal be error-prone?


Anders



Received: from freeby.ben.algroup.co.uk (sockittome.aldigital.co.uk [194.128.162.252]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id CAA27862 for <[e-mail]>; Mon, 24 Jul 2000 02:36:48 -0700 (PDT)
Received: from algroup.co.uk (naughty.ben.algroup.co.uk [193.133.15.107]) by freeby.ben.algroup.co.uk (8.6.12/8.6.12) with ESMTP id KAA19834; Mon, 24 Jul 2000 10:54:57 +0100
Message-ID: <[e-mail]>
Date: Mon, 24 Jul 2000 10:38:37 +0100
From: Ben Laurie <[e-mail]>
Organization: A.L. Group plc
X-Mailer: Mozilla 4.7 [en] (WinNT; I)
MIME-Version: 1.0
To: [e-mail]
CC: [e-mail], [e-mail], [e-mail]
Subject: Re: Dual-signed certificates
References: <[e-mail]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

[e-mail] wrote:
> 
>      Responses below.  I don't think parallel signatures from the CA and
> the user are a very good idea, but the user's enveloping signature might be
> another matter.

Agreed, now I've thought about it some more.

> >      Getting the acceptance itself into the ordinary certificate would
> not
> > be feasible.
> 
> Why not?
> 
> [Tom Gindin] Because an acceptance signature comes after the issuer
> signature, or else it doesn't cover the issuer signature.  In any case, the
> current signature format is not designed for dual simultaneous signatures.

Right - I was assuming an updated certificate format!

Cheers,

Ben.

--
http://www.apache-ssl.org/ben.html

Coming to ApacheCon Europe 2000? http://apachecon.com/


Received: from odin2.bull.net (odin2.bull.net [192.90.70.84]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id CAA27829 for <[e-mail]>; Mon, 24 Jul 2000 02:36:39 -0700 (PDT)
Received: from lvt-mail.frlv.bull.fr (lvt-mail.frlv.bull.fr [129.184.62.223]) by odin2.bull.net (8.9.3/8.9.3) with ESMTP id LAA29120; Mon, 24 Jul 2000 11:43:26 +0200
Received: from bull.net (frpq6118.frpq.bull.fr [129.184.8.64]) by lvt-mail.frlv.bull.fr (8.9.2/8.9.1) with ESMTP id LAA19228; Mon, 24 Jul 2000 11:39:01 +0200
Message-ID: <[e-mail]>
Date: Mon, 24 Jul 2000 11:39:02 +0200
From: Denis Pinkas <[e-mail]>
Organization: Bull
X-Mailer: Mozilla 4.7 [fr] (Win98; I)
X-Accept-Language: fr
MIME-Version: 1.0
To: Aram Perez <[e-mail]>
CC: PKIX <[e-mail]>
Subject: Re: Signing what you don't understand
References: <[e-mail]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Aram,

> Hi Denis P.,
> 
> > ETSI Standard ES 201733 mandates the signature time as a signed
> > attribute of the CMS structure.
> 
> How widely implemented/used is this standard? 

This standard has been published in April 2000. It will take some
time before it gets implemented. 

> Who determines the signature
> time? Is the signature time "certified"?

Look at the details. Everything is explained within the document.

> > An informational draft RFC based on
> > that standard is available from:
> >
> > http://www.ietf.org/internet-drafts/draft-ietf-smime-esformats-01.txt
> 
> How long before this "informational draft RFC" becomes a standard?

Since the basic document (i.e. ES 201733) is copyrighted by ETSI,
but the IETF has been given the right to publish the document, but
not to modify it. Hence the reason why it will stay has
INFORMATIONAL. The basic document is available for free from the
ETSI site. (http://www.etsi.org)

Denis

> Regards,
> Aram Perez


Received: from freeby.ben.algroup.co.uk (sockittome.aldigital.co.uk [194.128.162.252]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id CAA27584 for <[e-mail]>; Mon, 24 Jul 2000 02:34:04 -0700 (PDT)
Received: from algroup.co.uk (naughty.ben.algroup.co.uk [193.133.15.107]) by freeby.ben.algroup.co.uk (8.6.12/8.6.12) with ESMTP id KAA19824; Mon, 24 Jul 2000 10:53:37 +0100
Message-ID: <[e-mail]>
Date: Mon, 24 Jul 2000 10:37:18 +0100
From: Ben Laurie <[e-mail]>
Organization: A.L. Group plc
X-Mailer: Mozilla 4.7 [en] (WinNT; I)
MIME-Version: 1.0
To: Simon Tardell <[e-mail]>
CC: "'[e-mail]'" <[e-mail]>
Subject: Re: Dual-signed certificates
References: <[e-mail]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Simon Tardell wrote:
> 
> > Eh? What does this have to do with web-of-trust? This is to do with
> > contracts (i.e. the one between the subject and the issuer).
> 
> It is? If there is a contract involved, the certificate is only half of it,
> the other half being your certificate request.

Perhaps so, but I don't see how this either invalidates my point or has
anything to do with web-of-trust.

> Is a driver's license a
> contract? Does it put me under any obligations simply having one? Or does
> using it put me under obligations?

This seems like a red herring to me, but perhaps I'm missing something.

> > Anyway, the point you are making appears to reinforce my point, not
> > argue against it: no-one can work out whether a CA is honest, but the
> > subject signs the cert, they can at least work out that _the subject_
> > trusts them (within the context of the issued cert, of course)!
> 
> The parenthesis is my problem with this. You have to anchor your trust
> somewhere, either in the CA, or in the subject. And if you already trust the
> subject public key, what use is the cert in the first place (especially
> since you don't derive any further trust from it)?

A certificate is more than a simple wrapper for a public key - it binds
the key to a set of attributes. The fact that I trust the key does not
allow me to know that, for example, the issuer has authorised them to
perform some actions, but the cert does.

> But I think there is a much simpler answer to this. If I don't agree to what
> the CA wrote into my cert, I don't use that cert (if you don't agree to the
> name that goes with the picture in your driver's license, don't drive on
> that license).

That would mean that any signature would also have to include (a
reference to) the cert(s) that are agreed to by the signer, which would
be another way to approach the matter, but doesn't just drop out of
existing standards.

Cheers,

Ben.

--
http://www.apache-ssl.org/ben.html

Coming to ApacheCon Europe 2000? http://apachecon.com/


Received: from odin2.bull.net (odin2.bull.net [192.90.70.84]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id BAA26024 for <[e-mail]>; Mon, 24 Jul 2000 01:35:24 -0700 (PDT)
Received: from lvt-mail.frlv.bull.fr (lvt-mail.frlv.bull.fr [129.184.62.223]) by odin2.bull.net (8.9.3/8.9.3) with ESMTP id KAA28140; Mon, 24 Jul 2000 10:42:10 +0200
Received: from bull.net (frpq6118.frpq.bull.fr [129.184.8.64]) by lvt-mail.frlv.bull.fr (8.9.2/8.9.1) with ESMTP id KAA37092; Mon, 24 Jul 2000 10:37:45 +0200
Message-ID: <[e-mail]>
Date: Mon, 24 Jul 2000 10:37:46 +0200
From: Denis Pinkas <[e-mail]>
Organization: Bull
X-Mailer: Mozilla 4.7 [fr] (Win98; I)
X-Accept-Language: fr
MIME-Version: 1.0
To: Bob Jueneman <[e-mail]>
CC: [e-mail]
Subject: Re: Dual-signed certificates
References: <[e-mail]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Bob,

Altough there has been other people commenting on your initial
message, I re-use it.

> Ben,
> 
> [snip]
> 
> >Since a certificate is comprised of public information signed by a CA,
> >clearly a CA can create a certificate saying more-or-less what they
> >want. I suppose this is an argument for having certificates that are
> >dual-signed (by the CA and the public key the contain).
> 
> Duh!  Head-slapping!  What a great idea!  I'd love to see this added to
> X.509 v3 as an optional, noncritical extension.
> 
> For years, especially within the ABA, we have talked about the need
> for the user to explicitly confirm acceptance of the certificate, but at present
> there is no good way to confirm acceptance, except by procedures
> that are not verifiable by any relying party.  Obviously, having the user
> sign the certificate herself would confirm acceptance.

There exists a way, including by a procedure that is verifiable for
every received signature by any relying party. In the stuff that got
signed, you include the identifier of the certificate. This may be
done by using CMS (or is mandated in ES 201733). There is no need to
invent a double-signed certificate.

Denis
 
> Now, granted, if a rogue CA wanted to create a bogus certificate
> containing my name and their public key, they could also sign the
> certificate, since they would possess the private key.
> 
> However, this threat tends to evaporate as soon as the real user signs
> something which in all likelihood only that user could have done.
> and the more transactions that are signed, the more confidence that
> it really is the user -- in fact irrespective of the certificate, because the
> confidence in a signature tends to increase though repetitive use.
> 
> As an aside, I sometimes get into arguments with people about whether,
> and how, trusted roots should be incorporated within browsers, etc.
> 
> My experience is that I often receive a signed e-mail from someone whose
> root is not in my cache of trusted roots.  Because in most cases the authentication
> of the user isn't exactly life and death (users who post to this list, for example),
> I tend to click OK and add that root to my cache.  Now, one certificate
> authenticated by that root doesn't prove much, but by the time I've received
> three or four certificates all signed by the US DOD Medium Assurance CA,
> for example, I have a greatly increased confidence that that root is bone fide.
> 
> Bob


Received: from naigwy (void1.ausys.se [62.20.78.253]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id BAA25549 for <[e-mail]>; Mon, 24 Jul 2000 01:03:52 -0700 (PDT)
Received: FROM aunt15.ausys.se BY naigwy ; Mon Jul 24 10:04:51 2000 +0200
Received: by aunt15.ausys.se with Internet Mail Service (5.5.2650.21) id <PLMLFCBG>; Mon, 24 Jul 2000 10:06:15 +0200
Message-ID: <[e-mail]>
From: Simon Tardell <[e-mail]>
To: "'Ben Laurie'" <[e-mail]>, Simon Tardell <[e-mail]>
Cc: "'[e-mail]'" <[e-mail]>
Subject: RE: Dual-signed certificates
Date: Mon, 24 Jul 2000 10:06:22 +0200
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain; charset="iso-8859-1"

> Eh? What does this have to do with web-of-trust? This is to do with
> contracts (i.e. the one between the subject and the issuer).

It is? If there is a contract involved, the certificate is only half of it,
the other half being your certificate request. Is a driver's license a
contract? Does it put me under any obligations simply having one? Or does
using it put me under obligations?

> I do find it strange that there seems to be this kind of knee-jerk
> reaction that says "if it isn't a CA signing, then it must be
> web-of-trust, and that's bad".

No, I believe there are perfectly valid domains for web-of-trust. 

> Anyway, the point you are making appears to reinforce my point, not
> argue against it: no-one can work out whether a CA is honest, but the
> subject signs the cert, they can at least work out that _the subject_
> trusts them (within the context of the issued cert, of course)!

The parenthesis is my problem with this. You have to anchor your trust
somewhere, either in the CA, or in the subject. And if you already trust the
subject public key, what use is the cert in the first place (especially
since you don't derive any further trust from it)? 

But I think there is a much simpler answer to this. If I don't agree to what
the CA wrote into my cert, I don't use that cert (if you don't agree to the
name that goes with the picture in your driver's license, don't drive on
that license).

Cheers,

Simon

Simon Tardell, Software Architect, iD2 Technologies
voice [phone], fax [phone], cell [phone]
[e-mail], http://www.iD2tech.com
Securing the Internet economy


Received: from odin2.bull.net (odin2.bull.net [192.90.70.84]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id AAA25077 for <[e-mail]>; Mon, 24 Jul 2000 00:46:11 -0700 (PDT)
Received: from lvt-mail.frlv.bull.fr (lvt-mail.frlv.bull.fr [129.184.62.223]) by odin2.bull.net (8.9.3/8.9.3) with ESMTP id JAA34294; Mon, 24 Jul 2000 09:52:57 +0200
Received: from bull.net (frpq6118.frpq.bull.fr [129.184.8.64]) by lvt-mail.frlv.bull.fr (8.9.2/8.9.1) with ESMTP id JAA19202; Mon, 24 Jul 2000 09:48:33 +0200
Message-ID: <[e-mail]>
Date: Mon, 24 Jul 2000 09:48:33 +0200
From: Denis Pinkas <[e-mail]>
Organization: Bull
X-Mailer: Mozilla 4.7 [fr] (Win98; I)
X-Accept-Language: fr
MIME-Version: 1.0
To: Tony Bartoletti <[e-mail]>
CC: [e-mail]
Subject: Re: A Real Rationale for Dedicated Keys
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Tony,

See my response at the bottom.

> At 11:20 AM 7/21/00 +0200, Denis Pinkas wrote:
> > > I agree with the main points, and I worked from the assumption that
> > > CAs will not certify without POP (certainly not NR without POP!).
> >
> >This is just the contrary: A CA can issue a certificate without POP,
> >if the certificate contains the NR bit. Hence is the reason: That
> >certificate shall only be used in a trusted environment (e.g. *not*
> >a door lock) where, by some means, there is some assurance of *what*
> >is being signed; in particular, which document is being signed and
> >which format is being used for the signature. Since the certificate
> >shall only be used with a trusted sofwtare, it is possible to
> >mandate properties for that trusted software; in particular, that it
> >SHALL always include the identifier of the signer's certificate and
> >protect it under the digital signature.
> >
> >As soon as the private key is *only* used with signature formats
> >that contain the identifier of the certificate protected under the
> >digital signature, this provides "real-time" POP. In other words,
> >only the entity owning the private key is able to include the right
> >certificate identifier. If a CA has issued a certificate without
> >POP, this does not matter anymore, since only the legitimate entity
> >able to use the private key will be able to sign under the
> >certificate that contains the matching public key. Security is a mix
> >of security mechanisms and security procedures. In this case, we
> >rely on "good cryptography" rather than security procedures (that
> >may be hard and long to verify "after the fact").
> 
> Denis,
> 
> What you write implies that NR-keys will not be employed by "ordinary
> users" for undertaking mid-high level internet transactions.
> 
> Maybe that is a "good thing".
> 
> But while I support the real-time-POP, I question the guarantee that
> the "right" person possess the key in the first place.
> 
> Are you suggesting that a CA might create a key-pair (via trusted
> key-device) and then create/issue an NR-certificate under your
> name, BEFORE (or EVER) ascertaining that the private key/device
> is in your hands?

No. It is not what I had in mind.

The scenario I am think of, does not imply that the CA creates the
key-pair. A user will ask the CA to have an identity associated with
a public key usable for NR purposes (i.e. with the NR bit set, DS
bit not set). The CA will of course keep track of the request (i.e.
will keep the registration information provides at that time). In
that case, after proper warning of the user, the CA does not need to
perform POP.

Denis

> 
> ___tony___
> 
> Tony Bartoletti 925-422-3881 <[e-mail]>
> Information Operations, Warfare and Assurance Center
> Lawrence Livermore National Laboratory
> Livermore, CA 94551-9900


Received: from d1o69.telia.com ([e-mail] [62.20.144.241]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id XAA23673 for <[e-mail]>; Sun, 23 Jul 2000 23:54:33 -0700 (PDT)
Received: from mega (t2o69p49.telia.com [62.20.144.169]) by d1o69.telia.com (8.8.8/8.8.8) with SMTP id IAA11762; Mon, 24 Jul 2000 08:57:22 +0200 (CEST)
Message-ID: <002001bff544$acd3dbd0$[e-mail]>
From: "Anders Rundgren" <[e-mail]>
To: "Ed Gerck" <[e-mail]>
Cc: "IETF-PXIX" <[e-mail]>
Subject: Re: QC DN "qualities". Was: I-D ACTION:draft-ietf-pkix-qc-04.txt
Date: Mon, 24 Jul 2000 09:56:28 +0200
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 4.72.3110.5
X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by ns.secondary.com id XAA23674

Ed,
short reply

>> Probably you don't agree to the idea that a CA/RA should/can keep records of its subjects.
>> That makes the discussion somewhat uninteresting as this is the foundation of
>> most CAs in the X500-world.
>
>I don't see the connection between keeping records (which is mandated by law, for
>example) and *permanently using* those records.  Those records are history, not
>present.


The problem is that "history" means different things to different people.  If someone
dies he/she is "history" but not all RPs knows that.   I.e. "history" simply *cannot* be
a parameter in this ball-game!  

Or, maybe you could *here and now* describe how CAs should resissue DNs?!

Actually the only reason for me requiring that DNs are not reused is to cope with
(the highly likely) situation where a user "shows" a newly issued cert containing 
a DN/CA that the particular RP already knows about.  It should be a no-brainer
(=pure/simple/stupid software algorithm) to conclude that it is the same person. 

AGAIN: This requirement is COMPLETELY *independent* of the CA scope.
Be it national, federal, local, corporate, customer register etc.

Anders



Received: from mta6.snfc21.pbi.net (mta6.snfc21.pbi.net [206.13.28.240]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id XAA22731 for <[e-mail]>; Sun, 23 Jul 2000 23:11:19 -0700 (PDT)
Received: from nma.com ([63.204.17.82]) by mta6.snfc21.pbi.net (Sun Internet Mail Server sims.3.5.2000.01.05.12.18.p9) with ESMTP id <[e-mail]> for [e-mail]; Sun, 23 Jul 2000 23:12:32 -0700 (PDT)
Date: Sun, 23 Jul 2000 23:13:02 -0700
From: Ed Gerck <[e-mail]>
Subject: Re: QC DN "qualities". Was: I-D ACTION:draft-ietf-pkix-qc-04.txt
To: Anders Rundgren <[e-mail]>
Cc: IETF-PXIX <[e-mail]>
Message-id: <[e-mail]>
MIME-version: 1.0
X-Mailer: Mozilla 4.7 [en]C-CCK-MCD {Sony}  (Win98; I)
Content-type: text/plain; charset=us-ascii
Content-transfer-encoding: 7bit
X-Accept-Language: en
References: <001801bff534$3317b740$[e-mail]>

Anders Rundgren wrote:

> Ed,
>
> I think you take the concept of not reisssuing DNs to a level where it does not belong!

I see no difficulties in reissuing DNs. In fact, I see a clear need.  Artificially making
DNs one-shot names will not work IMO but you are free to try to convince others.

> Probably you don't agree to the idea that a CA/RA should/can keep records of its subjects.
> That makes the discussion somewhat uninteresting as this is the foundation of
> most CAs in the X500-world.

I don't see the connection between keeping records (which is mandated by law, for
example) and *permanently using* those records.  Those records are history, not
present.

> >Besides, note that creating national IDs in order to uniquely identify people is
> >forbidden by the constittution of ALL EC countries.
>
> I doubt that this can be confitmed  as both Finland and Sweden have national IDs!

I do not intend to tell you about the constitution of your own country but it is a
public fact that the EC demands as condition for countries to enter the EC that
they must change their constitution if they do not have the provision I mentioned.

Personally, I think that national IDs are a security risk but others may surely think
otherwise and see then as a security *gain*.   And if to have security you must
break everyone's privacy, then you are not making a good choice IMO.  Privacy
is a long term asset whereas security is a short term goal.  Ask yourself -- what has
full security but zero privacy?  A prison.

If you really want to have national IDs and identify people by data in them,
then you need first to cope with Tony Bartoletti's suggestion -- that users
facing such threat should immediately publish their IDs so that anyone
else could use them!

> > What would a certificate
> >that purports to uniquely identify people within a country be but ... a national ID?
>
> There are two *big* errors here

Again, we diverge.  Thanks for the comments.

Cheers,

Ed Gerck



Received: from d1o69.telia.com ([e-mail] [62.20.144.241]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id VAA20938 for <[e-mail]>; Sun, 23 Jul 2000 21:56:35 -0700 (PDT)
Received: from mega (t3o69p36.telia.com [62.20.145.36]) by d1o69.telia.com (8.8.8/8.8.8) with SMTP id GAA00485; Mon, 24 Jul 2000 06:59:26 +0200 (CEST)
Message-ID: <001801bff534$3317b740$[e-mail]>
From: "Anders Rundgren" <[e-mail]>
To: "Ed Gerck" <[e-mail]>
Cc: "IETF-PXIX" <[e-mail]>
Subject: Re: QC DN "qualities". Was: I-D ACTION:draft-ietf-pkix-qc-04.txt
Date: Mon, 24 Jul 2000 07:58:31 +0200
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 4.72.3110.5
X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by ns.secondary.com id VAA20940

Ed,

I think you take the concept of not reisssuing DNs to a level where it does not belong!

Probably you don't agree to the idea that a CA/RA should/can keep records of its subjects.
That makes the discussion somewhat uninteresting as this is the foundation of
most CAs in the X500-world.

<large cutoff>

>Besides, note that creating national IDs in order to uniquely identify people is
>forbidden by the constittution of ALL EC countries.

I doubt that this can be confitmed  as both Finland and Sweden have national IDs!


> What would a certificate
>that purports to uniquely identify people within a country be but ... a national ID?

There are two *big* errors here

1.  "Uniquely identify" to be useful by RPs requires UIDs which is *not* a QC requirement.
Not reissuing DNs does *not* imply that certs will use UIDs.   A name distinguisher may even be
counting between certs for the same user!  But if the real problem is that the CA knows its
subjects then you are back to square one...

2. The scope of CAs that knows its subjects is completely arbitrary. 

>Where is Sweden, BTW?


In deep s**t guess...

Anders




Received: from diablo.OntheNet.com.au (diablo.OntheNet.com.au [203.10.89.2]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id VAA20418 for <[e-mail]>; Sun, 23 Jul 2000 21:27:21 -0700 (PDT)
Received: from msimon (pc3.eracom.com.au [203.144.16.147]) by diablo.OntheNet.com.au (8.9.3/8.9.3) with SMTP id OAA87244; Mon, 24 Jul 2000 14:29:47 +1000 (EST)
Message-ID: <02fb01bff529$10467360$[e-mail]>
From: "Simon McMahon" <[e-mail]>
To: "Aram Perez" <[e-mail]>, <[e-mail]>
References: <[e-mail]>
Subject: Re: A Real Rationale for Dedicated Keys
Date: Mon, 24 Jul 2000 14:38:04 +1000
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.00.2314.1300
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300

Hi Aram,

> >
> > Much more likely is that the owner *will* show up to the CA or one of
its
> > RAs to get a NR certificate. Anything less will probably fail to meet
the
> > legal requirements for NR and be worth no more than a NR=0 cert.
>
> While I mostly agree, what you are stating is impractical. Very few will
use
> digital signatures that "meet the legal requirements for NR" if they have
to
> physically show up to the CA.
>
They just have to show up to an RA. You cant open a bank account without
showing up to a bank branch and authenticating yourself yourself. Bank staff
are required to sight authentication documentation usually including photo
ID such as a passport.

I suspect that any commercial CA will partner with some organisation that
has a branch network such as a Bank or Post Office to make showing up less
of a problem. Maybe even McDonalds will get into the RA business :-). Would
you like a certificate with that burger ?

You cant support trust to the level where NR is possible without
authenticating the subjects and making them accountable for what they
declare at registration time. E.g. that they understand their obligations
regarding their private key. This really has to happen OOB since most people
and organisations dont have an established authenticatable on-line presence.
Perhaps at some time people and organisations will have a sufficient level
of on-line identity so that they can be authenticated on line but they have
to start off-line somewhere.

I would suspect that NR=1 quality certificates will start with few big
businesses and filter down to small businesses that wish to participate,
then to individuals who may be used to NR=0 certificates.

Simon McMahon
ERACOM Pty. Ltd.




Received: from aspams52.cai.com (aspams52.cai.com [155.35.248.76]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id UAA19578 for <[e-mail]>; Sun, 23 Jul 2000 20:27:49 -0700 (PDT)
Received: by aspams52.cai.com with Internet Mail Service (5.5.2650.21) id <3X7BA3PJ>; Mon, 24 Jul 2000 13:30:22 +1000
Message-ID: <[e-mail]>
From: "Ramsay, Ron" <[e-mail]>
To: Bob Jueneman <[e-mail]>, [e-mail]
Cc: [e-mail]
Subject: RE: Signing what you don't understand
Date: Mon, 24 Jul 2000 13:30:25 +1000
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain; charset="iso-8859-1"

I don't have more specific information, but I think they saw the strength of
their method as being impervious to the compromise of a single server. You
seem to be addressing password cracking. Password cracking wou

-----Original Message-----
From: Bob Jueneman [mailto:[e-mail]]
Sent: Saturday, 22 July 2000 0:54
To: Ramsay, Ron; [e-mail]
Cc: [e-mail]
Subject: RE: Signing what you don't understand


I can't tell from the brief description, but it appears that they are using
a simple password to log on sequentially to multiple sites, and then
assembling the collected secret shares at that point.
 
Granted that this makes it impossible for a rogue administrator at one
institution to access a user's keys, but what is to prevent an attacker from
collecting the shares himself, using a multiplicity of simple passwords?
 
Even if the user is scrupulous about using a different password for each
server (making it very difficult to remember them all), the effort to break
the system would seem to be merely additive, rather than exponential.
Guessing the or four simple passwords is still simple.
 
I must be missing something.  Does anyone have the patent application, or
further details?
 
Bob

>>> "Ramsay, Ron" <[e-mail]> 07/20/00 10:48PM >>>

Very interesting. It would have been interesting to have heard from Warwick
on the issue of non-repudiation. Verisign would seem to have placed a stake
in the ground.

Ron.
-----Original Message-----
From: Peter Williams [ mailto:[e-mail]]
<mailto:[e-mail]]> 
Sent: Friday, 21 July 2000 12:52
To: 'Richard Levitte'; Anders Rundgren
Cc: Peter Lipp; [e-mail]; [e-mail]
Subject: RE: Signing what you don't understand




http://www.verisign.com/press/2000/roaming.html
<http://www.verisign.com/press/2000/roaming.html> 



"VeriSign's revolutionary technology allows an end-user to securely 
store digital certificates and/or any other type of data, such as 
financial information or an online patient record, on distributed 
network servers operated by multiple trusted service providers. This 
technology enables portability of digital certificates, providing 
convenience for users to access and download their certificates and 
private keys for online authentication. It also enables the generation 
of binding digital signatures for conducting high-value e-commerce 
transactions, regardless of whether users are accessing the Internet 
from work, home, or another location such as an Internet kiosk. Digital 
certificates are electronic credentials that identify parties online, 
enabling encrypted communications and legally binding, valid digital 
signatures. 
"

-----Original Message-----
From: Richard Levitte [ mailto:[e-mail]]
<mailto:[e-mail]]> 
Sent: Thursday, July 20, 2000 11:24 AM
To: Anders Rundgren
Cc: Peter Lipp; [e-mail]; [e-mail]
Subject: Re: Signing what you don't understand


Anders Rundgren wrote:

> Peter,
>
> >> Several leading PKI vendors have implemented systems where the private
key
> >> is held on a central Web server and then downloaded at run time to a
web
> >> browser.  Are you saying that signatures created using these keys are
> >> invalid?
> >Are you sure? Could you provide a reference? I doubt that strongly...
> >
> >Peter
>
> I think this is one...
>
> http://www.arcot.com/products/webfort.html
<http://www.arcot.com/products/webfort.html> 

I think not, at least from reading the papers "Protecting Digital
Identities" and
"Protecting Your Private Key".  All they say is that they've invented some
kind
of key database ("key wallet" to use their term) that is more secure than
what
comes with for example MSIE and Netscape Communicator...

Personally, if I was confronted with a CA that wanted to create my private
key
for me, and store it centrally to boot, I'd go somewhere else.  Very fast.
It
contradicts anything even remotely close to being called "secure".

--
Richard Levitte   !!! New cell phone number !!!
[e-mail]

/* You might enjoy viewing the complete vCard */




Received: from e2.ny.us.ibm.com (e2.ny.us.ibm.com [32.97.182.102]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id IAA29065 for <[e-mail]>; Sun, 23 Jul 2000 08:55:26 -0700 (PDT)
From: [e-mail]
Received: from northrelay02.pok.ibm.com (northrelay02.pok.ibm.com [9.117.200.22]) by e2.ny.us.ibm.com (8.9.3/8.9.3) with ESMTP id LAA78224; Sun, 23 Jul 2000 11:57:46 -0400
Received: from D51MTA04.pok.ibm.com (d51mta04.pok.ibm.com [9.117.200.32]) by northrelay02.pok.ibm.com (8.8.8m3/NCO v4.92) with SMTP id LAA26192; Sun, 23 Jul 2000 11:57:45 -0400
Received: by D51MTA04.pok.ibm.com(Lotus SMTP MTA v4.6.5  (863.2 5-20-1999))  id 85256925.0057AB71 ; Sun, 23 Jul 2000 11:57:35 -0400
X-Lotus-FromDomain: IBMUS
To: Ben Laurie <[e-mail]>
cc: [e-mail], [e-mail], [e-mail]
Message-ID: <[e-mail]>
Date: Sun, 23 Jul 2000 11:57:31 -0400
Subject: Re: Dual-signed certificates
Mime-Version: 1.0
Content-type: text/plain; charset=us-ascii
Content-Disposition: inline

     Responses below.  I don't think parallel signatures from the CA and
the user are a very good idea, but the user's enveloping signature might be
another matter.

          Tom Gindin

Ben Laurie <[e-mail]> on 07/22/2000 11:39:24 AM

To:   Tom Gindin/Watson/IBM@IBMUS
cc:   [e-mail], [e-mail], [e-mail]
Subject:  Re: Dual-signed certificates



[e-mail] wrote:
>
>      Although a certificate with these exact characteristics might not be
> feasible, how about a CMS SignedData containing the certificate with an
> signedAttribute called "CertificateAccepted" with value GeneralizedTime?
> The other alternative would be a self-signed certificate with an
> "ExternalCertificate" extension, with a value containing the certificate.
> Of course, all these prove is that whoever has the private key agrees
that
> the certificate is valid - they don't do anything to prove who it is who
> has the private key.

Absolutely, but please don't let's get into the whole identity
discussion again. All I care about is the private key.

[Tom Gindin] I was just pointing out the limitation.  I don't want to start
another round of that debate - NR is enough.

>      Getting the acceptance itself into the ordinary certificate would
not
> be feasible.

Why not?

[Tom Gindin] Because an acceptance signature comes after the issuer
signature, or else it doesn't cover the issuer signature.  In any case, the
current signature format is not designed for dual simultaneous signatures.

>      However, do people think it appropriate for the real external
> certificate to be carried around inside a CMS SignedData or a self-signed
> certificate?  It certainly can be done, but should it?

The certificate should be extended to carry two signatures, IMO.

Cheers,

Ben.

--
http://www.apache-ssl.org/ben.html

Coming to ApacheCon Europe 2000? http://apachecon.com/





Received: from e2.ny.us.ibm.com (e2.ny.us.ibm.com [32.97.182.102]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id IAA28746 for <[e-mail]>; Sun, 23 Jul 2000 08:45:24 -0700 (PDT)
From: [e-mail]
Received: from northrelay02.pok.ibm.com (northrelay02.pok.ibm.com [9.117.200.22]) by e2.ny.us.ibm.com (8.9.3/8.9.3) with ESMTP id LAA103948; Sun, 23 Jul 2000 11:47:44 -0400
Received: from D51MTA04.pok.ibm.com (d51mta04.pok.ibm.com [9.117.200.32]) by northrelay02.pok.ibm.com (8.8.8m3/NCO v4.92) with SMTP id LAA15254; Sun, 23 Jul 2000 11:47:43 -0400
Received: by D51MTA04.pok.ibm.com(Lotus SMTP MTA v4.6.5  (863.2 5-20-1999))  id 85256925.0056C2F6 ; Sun, 23 Jul 2000 11:47:40 -0400
X-Lotus-FromDomain: IBMUS
To: Sharon Boeyen <[e-mail]>
cc: "'Stephen Kent'" <[e-mail]>, [e-mail]
Message-ID: <[e-mail]>
Date: Sun, 23 Jul 2000 11:47:34 -0400
Subject: RE: forward & reverse confusion
Mime-Version: 1.0
Content-type: text/plain; charset=us-ascii
Content-Disposition: inline

     This naming does cause implementors to need to go over the standards
very carefully.  I would certainly favor "certForThis" and "certIssuedBy"
(not the plural, since there can only be one certificate in the element)
over the current wording, or perhaps "asSubject" and "asIssuer".  If even
one of the labels is changed, the confusion will vanish.

          Tom Gindin

Sharon Boeyen <[e-mail]> on 07/21/2000 11:33:06 AM

To:   "'Stephen Kent'" <[e-mail]>
cc:   [e-mail]
Subject:  RE: forward & reverse confusion



side issue:

In any conversation I have on these attributes or on path development or
on path processing, the terms 'forward' and 'reverse' cause confusion. I
suspect
I'm not alone in this.

How do folks feel about submitting a defect report that would replace those
terms in the crossCertificatePair attribute with less confusing ones (e.g.
certsIssuedToThisCA, certsIssuedByThisCA)? I'm certainly not wed to those
terms, but something along those lines that better conveys what they really
are.

Sharon

> -----Original Message-----
> From: Stephen Kent [mailto:[e-mail]]
> Sent: Friday, July 21, 2000 9:41 AM
> To: Sharon Boeyen
> Cc: [e-mail]
> Subject: RE: Reverse paths
>
>
> Sharon,
>
> >Steve,
> >I don't think I've been able to clearly describe what I meant. I am
> >NOT proposing ANY additional certificate issuance by anybody. I think
> >the terms reverse and forward are very unfortunate and always confuse
> >these discussions. Can we chat offline just to make sure that you
> >understand what it is I am proposing. Email makes this type of
> >discussion difficult at best.
> >
> >Within a hierarchy I don't believe any change is required.
> If the root
> >of a hierarchy issued a certificate to some CA that is NOT a
> subordinate
> >of the root, then currently PKIX does not require the root
> CA to place
> >that certificate in the root CA's entry. What I am proposing is that
> >such a certificate, IF ISSUED, be placed in the issuer's
> entry as well
> >as in the subject CA's entry.
>
> Ok, I think this clarification makes me more comfortable.
>
> Steve
>
> P.S.  All the negative comments about bridge CAs in my previous
> message still apply.
>





Received: from janus.hosting4u.net (janus.hosting4u.net [209.15.2.37]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id HAA22861 for <[e-mail]>; Sun, 23 Jul 2000 07:48:27 -0700 (PDT)
Received: (qmail 12292 invoked from network); 23 Jul 2000 14:51:19 -0000
Received: from taurus.hosting4u.net (209.15.2.33) by mail-gate.hosting4u.net with SMTP; 23 Jul 2000 14:51:19 -0000
Received: from nma.com ([63.204.17.82]) by taurus.hosting4u.net ; Sun, 23 Jul 2000 09:51:17 -0500
Message-ID: <[e-mail]>
Date: Sun, 23 Jul 2000 07:51:22 -0700
From: Ed Gerck <[e-mail]>
X-Mailer: Mozilla 4.7 [en]C-CCK-MCD {Sony}  (Win98; I)
X-Accept-Language: en
MIME-Version: 1.0
To: Anders Rundgren <[e-mail]>
CC: Denis Pinkas <[e-mail]>, Stefan Santesson <[e-mail]>, [e-mail], Paul Halliden <[e-mail]>, IETF-PXIX <[e-mail]>
Subject: Re: QC DN "qualities". Was: I-D ACTION:draft-ietf-pkix-qc-04.txt
References: <000c01bff4b0$c698fe40$[e-mail]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Anders Rundgren wrote:

> Ed Gerck wrote:
> >Anders,
> >what you ask cannot be done in X.509/PKIX and will fail if tried.
> >There are three main reasons for failure:
> >
> >1. technical:  The old Bob Jones example.
>
> Information about the old, the dead, and the young Bob Jones etc. is stored
> in variuos registers that the QC RA/CA has access to.

In the Internet no one can control both sides of the communication
channel, neither sending nor receiving.   This is the major problem in
trying to define unique DNs based on X.500 -- you think you have all your
bases covered, that DN "X" uniquely identifies A and yet, it may also
identify B, C and so on.  You have an example right in my phrase!

I wrote "The old Bob Jones example" and meant the old example
of "Bob Jones."   You understood the example of  "old Bob Jones"!

The same happens when you try to identify Bob Jones, and I will cite
from the "old example" of Bob Jones (with yet another use of "old"
because Bob Jones is an "old friend" -- which does not mean that Bob
Jones is old, either):

 The second [problem] is that even if some large corporation were to deploy
 X.500 internally and generate X.509 certificates using those DNs [X509], it
 would make those DNs unique by addition of information of relevance to the
corporation, such as operational unit, building name or mail stop. Such a
 unique name is not adequate to disambiguate a common name from the point
 of view of all possible users of the certificate. That is, Alice may have an old
 friend, Bob Jones, at IBM but have no idea of his mail stop, building name or
 operational unit. Although she has a fully trusted identity certificate from IBM
 for each employed Bob Jones, she can not trust any of them to be her friend.
 Therefore, the certificate has failed in its task of binding identity to a public key.

This old example is from my old friend Carl Ellison and is given in the old URL
of 1996:
http://usenix.org/publications/library/proceedings/sec96/full_papers/ellison/index.html

Besides the other two problems I mentioned:

> >2. commercial: CAs make mistakes and may issue the same DN for
> >two different people. They do not want to be liable for it.
> >3. revocation: if a cert is revoked with DN "X" for entity A then that DN
> >may be reused for entity B. However, revocation of certificates does
> >not revoke certs -- it merely puts them in a black list. There may be
> >any number of certs with "X" for A in the world which have not yet
> >been revoked by a client app, and may thus clash with  a cert that also
> >has  "X" but for B.

there are still more problems as we follow the logic in second-order, third-order,
etc.

> >There are also other reasons. It is thus much better security-wise to avoid
> >a false sense of security and leave matters as they are now.  A certificate
> >is a hint, QC or not QC, no more, no less.
>
> If QC is just a hint it is REDUNDANT.  I can we *great* ease produce QC-like
> certificates on my W2K-server and distribute them out-of-band to RPs.  Does it make me a
> QC-CA?  I hope not.

You already accept that you can produce QC-like certificates. You just need to
ask ... why not?  If you have clients, you are already trusted by them and you may
as well issue their QC-certificates.  You know them much better than another
company that never even heard of them, no?

Besides, note that creating national IDs in order to uniquely identify people is
forbidden by the constittution of ALL EC countries.  What would a certificate
that purports to uniquely identify people within a country be but ... a national ID?
Where is Sweden, BTW?

Cheers,

Ed Gerck



Received: from d1o69.telia.com ([e-mail] [62.20.144.241]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id GAA21586 for <[e-mail]>; Sun, 23 Jul 2000 06:16:03 -0700 (PDT)
Received: from mega (t1o69p16.telia.com [62.20.144.16]) by d1o69.telia.com (8.8.8/8.8.8) with SMTP id PAA14654; Sun, 23 Jul 2000 15:18:39 +0200 (CEST)
Message-ID: <000c01bff4b0$c698fe40$[e-mail]>
From: "Anders Rundgren" <[e-mail]>
To: "Ed Gerck" <[e-mail]>
Cc: "Denis Pinkas" <[e-mail]>, "Stefan Santesson" <[e-mail]>, <[e-mail]>, "Paul Halliden" <[e-mail]>, "IETF-PXIX" <[e-mail]>
Subject: Re: QC DN "qualities". Was: I-D ACTION:draft-ietf-pkix-qc-04.txt
Date: Sun, 23 Jul 2000 16:17:44 +0200
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 4.72.3110.5
X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by ns.secondary.com id GAA21588

Ed,
I know that you can go on and on forever (me too!) so I think we can conclude
that we differ in opinions and thats about it.  But of course I will answer...

>Anders,
>what you ask cannot be done in X.509/PKIX and will fail if tried.

The idea to make QC a PKIX-item was probably not that great given the wide scope of such a thing.
But technically I don't see any unsolvable problems.

>There are three main reasons for failure:
>
>1. technical:  The old Bob Jones example.


Information about the old, the dead, and the young Bob Jones etc. is stored
in variuos registers that the QC RA/CA has access to.

>2. commercial: CAs make mistakes and may issue the same DN for
>two different people. They do not want to be liable for it.

Exactly how much it will cost a CA to make a mistake (which has happened
and will happen) will vary quite a bit.   It will not be a part of the QC-draft.
Actually a *minor* error rate does not at all make the system useless.  Compare
it to anyhting else we have today and it should be a vast improvement!

Then there is something that the CAs in Sweden don't understand,
but which I believe is very important: To "absolutely identify" (whatever that
really means) an individual is NOT as important as guaranteeing that two different individuals
do not get the same ID (DN).  The former is getting pretty impossible given the society we
live in with a lot of brief contacts and high mobility, while the latter can be done with
high precision using fairly simple technical procdures such a biometrics, register data, 
various credentials like old ID-cards etc.  Cheap and quick DNA-fingerprinting may be in
reach within 5-10 years.  There are other smarter ways of differentiating which I unfortunately
(for commercial reasons) can't go into here...

Maybe the term "relative identity" is applicable :-)

The reason that the differentiator mechanism is much more important is that you
usually don't get access to huge values without being known as an individual in
the first place. 

>3. revocation: if a cert is revoked with DN "X" for entity A then that DN
>may be reused for entity B. However, revocation of certificates does
>not revoke certs -- it merely puts them in a black list. There may be
>any number of certs with "X" for A in the world which have not yet
>been revoked by a client app, and may thus clash with  a cert that also
>has  "X" but for B.


We will see what the *final* QC draft will ends up with!  I would say I will be *very*
surpriced if it allows DN reuse as it is technically a no-brainer given that
the CA knows its subjects.  And if it does not, why bother with QCs?

>There are also other reasons. It is thus much better security-wise to avoid
>a false sense of security and leave matters as they are now.  A certificate
>is a hint, QC or not QC, no more, no less.

If QC is just a hint it is REDUNDANT.  I can we *great* ease produce QC-like
certificates on my W2K-server and distribute them out-of-band to RPs.  Does it make me a
QC-CA?  I hope not.

>Cheers,


U 2!
Anders




Received: from janus.hosting4u.net (janus.hosting4u.net [209.15.2.37]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id BAA10120 for <[e-mail]>; Sun, 23 Jul 2000 01:17:50 -0700 (PDT)
Received: (qmail 28562 invoked from network); 23 Jul 2000 08:20:40 -0000
Received: from taurus.hosting4u.net (209.15.2.33) by mail-gate.hosting4u.net with SMTP; 23 Jul 2000 08:20:40 -0000
Received: from nma.com ([63.204.17.82]) by taurus.hosting4u.net ; Sun, 23 Jul 2000 03:20:38 -0500
Message-ID: <[e-mail]>
Date: Sun, 23 Jul 2000 01:20:41 -0700
From: Ed Gerck <[e-mail]>
X-Mailer: Mozilla 4.7 [en]C-CCK-MCD {Sony}  (Win98; I)
X-Accept-Language: en
MIME-Version: 1.0
To: Anders Rundgren <[e-mail]>
CC: Denis Pinkas <[e-mail]>, Stefan Santesson <[e-mail]>, [e-mail], Paul Halliden <[e-mail]>, IETF-PXIX <[e-mail]>
Subject: Re: QC DN "qualities". Was: I-D ACTION:draft-ietf-pkix-qc-04.txt
References: <001701bfedc5$26f65000$[e-mail]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Anders,

what you ask cannot be done in X.509/PKIX and will fail if tried.

There are three main reasons for failure:

1. technical:  The old Bob Jones example.

2. commercial: CAs make mistakes and may issue the same DN for
two different people. They do not want to be liable for it.

3. revocation: if a cert is revoked with DN "X" for entity A then that DN
may be reused for entity B. However, revocation of certificates does
not revoke certs -- it merely puts them in a black list. There may be
any number of certs with "X" for A in the world which have not yet
been revoked by a client app, and may thus clash with  a cert that also
has  "X" but for B.

There are also other reasons. It is thus much better security-wise to avoid
a false sense of security and leave matters as they are now.  A certificate
is a hint, QC or not QC, no more, no less.

Cheers,

Ed Gerck

Anders Rundgren wrote:

> >In fact, X.509v3 section 11.2 has a note which
> >>states "a certification authority shall not issue certificates for two
> >>users with the same name",
> >>
> >This is not the point at dispute. The QC text used to have an additional
> >requirement that a QC contained "an unmistakable identity ... which ...
> >relates to a specific entity."  It also contained the concept of "a
> >corresponding officially registered identity".
> >
> >The contentious point is that this requirement has been dropped.  the reason
> >is that, in some jurisdictions there is simply no support for the
> >"unmistakable" concept.  Thus the subject name can be unique within the CA's
> >name space.
>
> This last line is actually the thing requested by Denis and by me!
>
> But even that is said to be impossible to achieve for reasons so
> far not particularly well explained.
>
> I.e. this requirement is purely technical and has nothing to do with official
> identities etc.  It simply requires CAs to keep track of its own subjects and
> not issue ambigious DNs or resissue already used DNs.
>
> Involves IMO no politics or magic, just plain engineering.
>
> If resolved it affects things like cert compares.
>
> Anders



Received: from mail.spyrus.com (mail.spyrus.com [207.212.34.20]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id MAA14715 for <[e-mail]>; Sat, 22 Jul 2000 12:16:05 -0700 (PDT)
Received: from rhousley_laptop (dial03.spyrus.com [207.212.34.123]) by mail.spyrus.com (8.9.3/8.9.3) with ESMTP id MAA19204; Sat, 22 Jul 2000 12:18:15 -0700 (PDT)
Message-Id: <[e-mail]>
X-Sender: [e-mail] (Unverified)
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58 
Date: Fri, 21 Jul 2000 19:22:35 -0400
To: Stephen Kent <[e-mail]>
From: Russ Housley <[e-mail]>
Subject: RE: Reverse paths
Cc: Sharon Boeyen <[e-mail]>, [e-mail], [e-mail]
In-Reply-To: <v0422080cb59d2878c417@[171.78.30.107]>
References: < <[e-mail]> <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed

At 06:14 PM 07/20/2000 -0400, Stephen Kent wrote:
>I think the Federal Bridge CA model is broken.  It is appropriate to use a 
>bridge CA as a convenient means of distributing certificates between 
>communities, to avoid the order N**2 cross certification problem.  CA-1 
>could go to the bridge CA to acquire the public key for CA-2, then import 
>that key into CA-1's domain, by issuing a cross certificate from CA-1 to 
>CA-2.  In this fashion CA-1 van impose the appropriate name constraints 
>extension, appropriate  policy mapping constrains, even basic constraints 
>on the depth of cert paths.  Then the existing processing methods we have 
>should work, right?
>
>If one tries to process a path via a bridge CA, then  one looses the 
>ability to impose name constraints, and to apply selective policy mapping 
>etc, because the bridge CA is in the path, getting in the way :-).  So, 
>no, I am not persuaded by the suggestion that bridge CAs are the wave of 
>the future.  I think they are ill conceived in their current use, but they 
>could be rehabilitated!

If the Federal Bridge CA is not employing name constraints, then I agree 
with you.  Certificates issued by a Department to the Federal Bridge should 
exclude the name space of the issuing Department.  This will ensure that no 
one else can issue a certificate with a subject name that is in the 
Department's name space that will be validated by relying parties within 
the Department.  Also, certificates issued by Federal Bridge to a 
Department should include the name space of the subject Department.  This 
will ensure that Department cannot issue a certificate with a subject name 
in the name space of another Department that will be validated by relying 
parties outside of the misbehaving Department.

It has been over a year since I looked at the certification policies 
proposed for the Federal Bridge.  I recall at least one briefing that 
included name constraints.  They were a good idea back then, and they are 
still a good idea.

Assuming that name constraints are employed, the biggest problem with the 
Federal Bridge is certificate path construction.  It is not possible to use 
the linkage provided by the subject key identifier and the authority key 
identifier extensions.  Without this tool, certificate path creation is 
more complex, and several widely deployed implementations are not up to the 
task.  These implementations must become more robust for the Bridge to 
achieve its potential.

Russ



Received: from freeby.ben.algroup.co.uk (sockittome.aldigital.co.uk [194.128.162.252]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id IAA09693 for <[e-mail]>; Sat, 22 Jul 2000 08:37:43 -0700 (PDT)
Received: from algroup.co.uk (naughty.ben.algroup.co.uk [193.133.15.107]) by freeby.ben.algroup.co.uk (8.6.12/8.6.12) with ESMTP id QAA08010; Sat, 22 Jul 2000 16:55:08 +0100
Message-ID: <[e-mail]>
Date: Sat, 22 Jul 2000 16:39:24 +0100
From: Ben Laurie <[e-mail]>
Organization: A.L. Group plc
X-Mailer: Mozilla 4.7 [en] (WinNT; I)
MIME-Version: 1.0
To: [e-mail]
CC: [e-mail], [e-mail], [e-mail]
Subject: Re: Dual-signed certificates
References: <[e-mail]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

[e-mail] wrote:
> 
>      Although a certificate with these exact characteristics might not be
> feasible, how about a CMS SignedData containing the certificate with an
> signedAttribute called "CertificateAccepted" with value GeneralizedTime?
> The other alternative would be a self-signed certificate with an
> "ExternalCertificate" extension, with a value containing the certificate.
> Of course, all these prove is that whoever has the private key agrees that
> the certificate is valid - they don't do anything to prove who it is who
> has the private key.

Absolutely, but please don't let's get into the whole identity
discussion again. All I care about is the private key.

>      Getting the acceptance itself into the ordinary certificate would not
> be feasible.

Why not?

>      However, do people think it appropriate for the real external
> certificate to be carried around inside a CMS SignedData or a self-signed
> certificate?  It certainly can be done, but should it?

The certificate should be extended to carry two signatures, IMO.

Cheers,

Ben.

--
http://www.apache-ssl.org/ben.html

Coming to ApacheCon Europe 2000? http://apachecon.com/


Received: from freeby.ben.algroup.co.uk (sockittome.aldigital.co.uk [194.128.162.252]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id IAA08467 for <[e-mail]>; Sat, 22 Jul 2000 08:32:58 -0700 (PDT)
Received: from algroup.co.uk (naughty.ben.algroup.co.uk [193.133.15.107]) by freeby.ben.algroup.co.uk (8.6.12/8.6.12) with ESMTP id QAA07989; Sat, 22 Jul 2000 16:51:39 +0100
Message-ID: <[e-mail]>
Date: Sat, 22 Jul 2000 16:35:55 +0100
From: Ben Laurie <[e-mail]>
Organization: A.L. Group plc
X-Mailer: Mozilla 4.7 [en] (WinNT; I)
MIME-Version: 1.0
To: Simon Tardell <[e-mail]>
CC: "'[e-mail]'" <[e-mail]>
Subject: Re: Dual-signed certificates
References: <[e-mail]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Simon Tardell wrote:
> 
> >      However, do people think it appropriate for the real external
> > certificate to be carried around inside a CMS SignedData or a
> > self-signed certificate?  It certainly can be done, but should it?
> 
> If I've been reading the thread correctly the physical world analogy of the
> "threat" that this would countermeasure is that a bank noone ever heard of
> would issue an ID card with my picture (which they can do, because they saw
> my ID card once) to someone who doesn't look like me and the question is not
> whether you can trust the odd-looking fellow, but whether you can trust that
> bank.
> 
> When it comes to well-known banks, government branches, etc I assume they
> won't do this, and I would not trust even my closest friends to be able to
> assert with any degrees of certitude if a bank is honest or not issuing
> certs. And no number of assertions that a Mickey Mouse CA issues a
> certificate to the right guy would make me trust that CA to always do the
> right thing (even if I would trust the particular certs it issued).
> 
> I am bit skeptical here, not because web-of-trust models don't have a
> legitimate use, but rather because they don't mix very well with PKI.

Eh? What does this have to do with web-of-trust? This is to do with
contracts (i.e. the one between the subject and the issuer).

I do find it strange that there seems to be this kind of knee-jerk
reaction that says "if it isn't a CA signing, then it must be
web-of-trust, and that's bad".

Anyway, the point you are making appears to reinforce my point, not
argue against it: no-one can work out whether a CA is honest, but the
subject signs the cert, they can at least work out that _the subject_
trusts them (within the context of the issued cert, of course)!

Cheers,

Ben.

--
http://www.apache-ssl.org/ben.html

Coming to ApacheCon Europe 2000? http://apachecon.com/


Received: from naigwy (void1.ausys.se [62.20.78.253]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id FAA29109 for <[e-mail]>; Sat, 22 Jul 2000 05:44:11 -0700 (PDT)
Received: FROM aunt15.ausys.se BY naigwy ; Sat Jul 22 14:45:03 2000 +0200
Received: by aunt15.ausys.se with Internet Mail Service (5.5.2650.21) id <PLML1V45>; Sat, 22 Jul 2000 14:46:25 +0200
Message-ID: <[e-mail]>
From: Simon Tardell <[e-mail]>
To: "'[e-mail]'" <[e-mail]>
Subject: RE: Dual-signed certificates
Date: Sat, 22 Jul 2000 14:46:09 +0200
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain; charset="iso-8859-1"

>      However, do people think it appropriate for the real external
> certificate to be carried around inside a CMS SignedData or a 
> self-signed certificate?  It certainly can be done, but should it?

If I've been reading the thread correctly the physical world analogy of the
"threat" that this would countermeasure is that a bank noone ever heard of
would issue an ID card with my picture (which they can do, because they saw
my ID card once) to someone who doesn't look like me and the question is not
whether you can trust the odd-looking fellow, but whether you can trust that
bank. 

When it comes to well-known banks, government branches, etc I assume they
won't do this, and I would not trust even my closest friends to be able to
assert with any degrees of certitude if a bank is honest or not issuing
certs. And no number of assertions that a Mickey Mouse CA issues a
certificate to the right guy would make me trust that CA to always do the
right thing (even if I would trust the particular certs it issued).

I am bit skeptical here, not because web-of-trust models don't have a
legitimate use, but rather because they don't mix very well with PKI.

Simon

Simon Tardell, Software Architect, iD2 Technologies
voice [phone], fax [phone], cell [phone]
[e-mail], http://www.iD2tech.com
Securing the Internet economy


Received: from sngrel5.hp.com (sngrel5.hp.com [192.6.86.210]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id CAA20482 for <[e-mail]>; Sat, 22 Jul 2000 02:44:14 -0700 (PDT)
From: [e-mail]
Received: from hkmail.hkg.hp.com (hkmail.hkg.hp.com [15.106.56.21]) by sngrel5.hp.com (Postfix) with ESMTP id F34971DC for <[e-mail]>; Sat, 22 Jul 2000 17:46:53 +0800 (SGP)
Received: from localhost (root@localhost) by hkmail.hkg.hp.com (8.9.3 (PHNE_18979)/8.9.3 SMKit6.0.6 OpenMail) with SMTP id RAA08773 for [e-mail]; Sat, 22 Jul 2000 17:46:52 +0800 (HKG)
X-OpenMail-Hops: 1
Date: Sat, 22 Jul 2000 17:46:47 +0800
Message-Id: <H00012891250125e@MHS>
Subject: unsubscribe
MIME-Version: 1.0
Cc: [e-mail]
Content-Type: text/plain; charset=US-ASCII; name="BDY.TXT"
Content-Disposition: inline; filename="BDY.TXT"
Content-Transfer-Encoding: 7bit

unsubscribe




Received: from mail.arabtrust.com (mail.arabtrust.com [216.247.149.19]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id XAA15028 for <[e-mail]>; Fri, 21 Jul 2000 23:57:59 -0700 (PDT)
Received: from jean [195.39.160.178] by mail.arabtrust.com (SMTPD32-6.00) id A6F131FE0126; Sat, 22 Jul 2000 03:02:09 -0400
From: "Jean Abraham" <[e-mail]>
To: "Tony Bartoletti" <[e-mail]>, "Simon McMahon" <[e-mail]>, <[e-mail]>
Subject: RE: A Real Rationale for Dedicated Keys
Date: Sat, 22 Jul 2000 09:58:27 +0300
Message-ID: <[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0)
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6600
Importance: Normal
In-reply-to: <[e-mail]>

How could one sign or encrypt an email with a public key shouldnt a private
key be used.






-----Original Message-----
From: Tony Bartoletti [mailto:[e-mail]]
Sent: Friday, July 21, 2000 3:37 AM
To: Simon McMahon; Jean Abraham; [e-mail]
Subject: Re: A Real Rationale for Dedicated Keys


At 10:04 AM 7/21/00 +1000, Simon McMahon wrote:
> >
> > Could you tell me what has NR (Non-Repudation) to do with CA control key
> > generation.
> >
>By "CA controlled key generation" I mean that the CA specifies minimum
>standards and one option of the CA may be to do the key gen itself. The CA
>should verify that the minimum standards are being followed if it specifies
>any.

Agreed!

>Non-repudiation requires (at least) that the private key does not get
>exposed or used by someone else without the owner knowing it. That means
>that how the private key is used and how it is stored when not in use is
>very relevant to NR. CAs can (and should) insist that key pairs are
>generated and the private part is stored to some minimum standard before
>they certify the public part.

Agreed!

>As a merchant I would be more inclined to trust NR signatures verified by
>certs from a CA that operated this way than from a CA that only checked the
>key owner's identity.

Agreed!

>I know of one commercial CA that only certified public keys for key pairs
>that it (the CA) generated. Their rationale was that they did not want the
>risk of certifying a dodgy key pair because of the risk of bad publicity
>undermining their reputation as a CA. The generated private key was
>transfered securely to the client. They wanted to take the next step and
>start storing the private key directly onto smart cards.

Some reservations here!  I would be wary of a process that actually
allows the "key-generating operator" to learn the value of the secret.

If there were ways to guarantee that the secret key were actually generated
"in the card", (and could not be extracted, of course) I would feel better
about such a process.

But, this does not address the issue of the dishonest user who would
have the corresponding public key "certified for authentication, NR=0",
use it for signing email receipts, and then try to repudiate a contract
by arguing they were fooled into signing it with their NR=0 usage.

I don't think "Just Say No" to key multi-certification will work.

What will?

___tony___


Tony Bartoletti 925-422-3881 <[e-mail]>
Information Operations, Warfare and Assurance Center
Lawrence Livermore National Laboratory
Livermore, CA 94551-9900




Received: from e2.ny.us.ibm.com (e2.ny.us.ibm.com [32.97.182.102]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id OAA19970 for <[e-mail]>; Fri, 21 Jul 2000 14:18:22 -0700 (PDT)
From: [e-mail]
Received: from northrelay02.pok.ibm.com (northrelay02.pok.ibm.com [9.117.200.22]) by e2.ny.us.ibm.com (8.9.3/8.9.3) with ESMTP id RAA24788; Fri, 21 Jul 2000 17:20:35 -0400
Received: from D51MTA04.pok.ibm.com (d51mta04.pok.ibm.com [9.117.200.32]) by northrelay02.pok.ibm.com (8.8.8m3/NCO v4.92) with SMTP id RAA38046; Fri, 21 Jul 2000 17:20:33 -0400
Received: by D51MTA04.pok.ibm.com(Lotus SMTP MTA v4.6.5  (863.2 5-20-1999))  id 85256923.00753BFF ; Fri, 21 Jul 2000 17:20:30 -0400
X-Lotus-FromDomain: IBMUS
To: Ben Laurie <[e-mail]>
cc: [e-mail], [e-mail], [e-mail]
Message-ID: <[e-mail]>
Date: Fri, 21 Jul 2000 17:20:26 -0400
Subject: Re: Dual-signed certificates
Mime-Version: 1.0
Content-type: text/plain; charset=us-ascii
Content-Disposition: inline

     Although a certificate with these exact characteristics might not be
feasible, how about a CMS SignedData containing the certificate with an
signedAttribute called "CertificateAccepted" with value GeneralizedTime?
The other alternative would be a self-signed certificate with an
"ExternalCertificate" extension, with a value containing the certificate.
Of course, all these prove is that whoever has the private key agrees that
the certificate is valid - they don't do anything to prove who it is who
has the private key.
     Getting the acceptance itself into the ordinary certificate would not
be feasible.
     However, do people think it appropriate for the real external
certificate to be carried around inside a CMS SignedData or a self-signed
certificate?  It certainly can be done, but should it?

          Tom Gindin


Ben Laurie <[e-mail]> on 07/21/2000 02:27:15 PM

To:   [e-mail]
cc:   [e-mail], [e-mail]
Subject:  Re: Dual-signed certificates



Peter Gutmann wrote:
>
> "Bob Jueneman" <[e-mail]> writes:
>
> >[snip]
> >
> >>Since a certificate is comprised of public information signed by a CA,
> >>clearly a CA can create a certificate saying more-or-less what they
> >>want. I suppose this is an argument for having certificates that are
> >>dual-signed (by the CA and the public key the contain).
>
> >Duh!  Head-slapping!  What a great idea!  I'd love to see this added to
X.509
> >v3 as an optional, noncritical extension.
>
> The chickenAndEgg extension I presume?  How do you process this (or
generate
> it)?

Eh? Or are you referring to the difficulty of having the signature
within the cert? If so, quite!

Cheers,

Ben.

--
http://www.apache-ssl.org/ben.html

Coming to ApacheCon Europe 2000? http://apachecon.com/





Received: from po1.bbn.com (PO1.BBN.COM [192.1.50.38]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id NAA18202 for <[e-mail]>; Fri, 21 Jul 2000 13:16:23 -0700 (PDT)
Received: from [171.78.30.107] (fixed030-107.bbn.com [171.78.30.107] (may be forged)) by po1.bbn.com (8.9.1/8.9.1) with ESMTP id QAA23092; Fri, 21 Jul 2000 16:18:53 -0400 (EDT)
Mime-Version: 1.0
X-Sender: [e-mail]
Message-Id: <v04220817b59e5f630840@[171.78.30.107]>
In-Reply-To: <[e-mail]>
References: <[e-mail]>
Date: Fri, 21 Jul 2000 16:13:56 -0400
To: [e-mail]
From: Stephen Kent <[e-mail]>
Subject: Re: Signing what you don't understand
Cc: [e-mail], [e-mail]
Content-Type: text/plain; charset="us-ascii" ; format="flowed"

John,

>Steve,
>
>  >>You are missing what I'm trying to say.  I'm not disputing that the
>  >>signature was created at the time claimed.
>  >>
>  >>The fact that CRLs include an invalidityDate field, which can indicate
>that
>  >>a certificate was invalid well before that CRL was published means that
>it
>  >>is possible for a certificate revocation to be "backdated" - i.e. even
>  >>though a perfectly valid CRL was referenced in the signature and
>indicated
>  >>that the certificate was valid at the time the signature was constructed,
>  >>another CRL can be published (possibly much) later that will say the
>  >>certificate was invalid at the signing time.
>  >
>  >>
>  >>This renders signer-provided evidence of non-revocation of little use
>  >>(unless you are willing to let the signer-provided evidence of
>  >>non-revocation trump the more recent CRL that asserts that the
>certificate
>  >>was invalid, which would open up a lot of security holes).
>  >
>  >The inclusion of the invalidity date in a CRL does not allow
>  >backdating, although it may appear that way.  The argument put forth
>  >to justify approval of this extension was to allow the CA to alert
>  >RPs to newly gained info re a revocation so that IF the RP had not
>  >acted upon a transaction (or the like) THEN the RP could elect to
>  >treat the signature as invalid.  However, if an RP has collected a
>  >CRL that covers the interval during which the transaction took place,
>  >then any later CRL with an invalidity date does not prevent the RP
>  >from using the CRL he acquired to support NR, i.e., the RP has
>  >exercised due diligence by obtaining the first CRL.
>
>Note that I was talking about initial signature verification by the RP, not
>subsequent NR.  The situation that I described had a signature with
>embedded, signer-provided NR evidence which contained a CRL reference that
>indicated one of the certificates was valid, but the RP obtains a more
>recent CRL indicating that it has expired.  To decide whether to trust the
>signature, the RP should use the most recent revocation data available to
>him - the CRL that flags the certificate as revoked - and ignore the
>earlier one referenced in the signature.

Under that circumstance, you're right.  Sorry I lost the context.

Steve



Received: from arista.iris.com (arista.iris.com [198.112.211.42]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id MAA17319 for <[e-mail]>; Fri, 21 Jul 2000 12:33:08 -0700 (PDT)
From: [e-mail]
Subject: Re: Signing what you don't understand
To: Stephen Kent <[e-mail]>
Cc: [e-mail], [e-mail]
X-Mailer: Lotus Notes Release 5.0.2c  February 2, 2000
Message-ID: <[e-mail]>
Date: Fri, 21 Jul 2000 15:35:38 -0400
X-MIMETrack: Serialize by Router on Arista/Iris(Build V505_07112000 |July 11, 2000) at 07/21/2000 03:35:54 PM
MIME-Version: 1.0
Content-type: text/plain; charset=us-ascii

Steve,

>>You are missing what I'm trying to say.  I'm not disputing that the
>>signature was created at the time claimed.
>>
>>The fact that CRLs include an invalidityDate field, which can indicate
that
>>a certificate was invalid well before that CRL was published means that
it
>>is possible for a certificate revocation to be "backdated" - i.e. even
>>though a perfectly valid CRL was referenced in the signature and
indicated
>>that the certificate was valid at the time the signature was constructed,
>>another CRL can be published (possibly much) later that will say the
>>certificate was invalid at the signing time.
>
>>
>>This renders signer-provided evidence of non-revocation of little use
>>(unless you are willing to let the signer-provided evidence of
>>non-revocation trump the more recent CRL that asserts that the
certificate
>>was invalid, which would open up a lot of security holes).
>
>The inclusion of the invalidity date in a CRL does not allow
>backdating, although it may appear that way.  The argument put forth
>to justify approval of this extension was to allow the CA to alert
>RPs to newly gained info re a revocation so that IF the RP had not
>acted upon a transaction (or the like) THEN the RP could elect to
>treat the signature as invalid.  However, if an RP has collected a
>CRL that covers the interval during which the transaction took place,
>then any later CRL with an invalidity date does not prevent the RP
>from using the CRL he acquired to support NR, i.e., the RP has
>exercised due diligence by obtaining the first CRL.

Note that I was talking about initial signature verification by the RP, not
subsequent NR.  The situation that I described had a signature with
embedded, signer-provided NR evidence which contained a CRL reference that
indicated one of the certificates was valid, but the RP obtains a more
recent CRL indicating that it has expired.  To decide whether to trust the
signature, the RP should use the most recent revocation data available to
him - the CRL that flags the certificate as revoked - and ignore the
earlier one referenced in the signature.

John








Received: from poptop.llnl.gov (poptop.llnl.gov [128.115.41.70]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id MAA16696 for <[e-mail]>; Fri, 21 Jul 2000 12:02:35 -0700 (PDT)
Received: from catalyst (catalyst.llnl.gov [128.115.222.68]) by poptop.llnl.gov (8.8.8/LLNL-3.0.2/pop.llnl.gov-5.1) with ESMTP id MAA13058; Fri, 21 Jul 2000 12:04:07 -0700 (PDT)
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.2 
Date: Fri, 21 Jul 2000 12:11:54 -0700
To: Denis Pinkas <[e-mail]>
From: Tony Bartoletti <[e-mail]>
Subject: Re: A Real Rationale for Dedicated Keys
Cc: [e-mail]
In-Reply-To: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed

At 11:20 AM 7/21/00 +0200, Denis Pinkas wrote:
> > I agree with the main points, and I worked from the assumption that
> > CAs will not certify without POP (certainly not NR without POP!).
>
>This is just the contrary: A CA can issue a certificate without POP,
>if the certificate contains the NR bit. Hence is the reason: That
>certificate shall only be used in a trusted environment (e.g. *not*
>a door lock) where, by some means, there is some assurance of *what*
>is being signed; in particular, which document is being signed and
>which format is being used for the signature. Since the certificate
>shall only be used with a trusted sofwtare, it is possible to
>mandate properties for that trusted software; in particular, that it
>SHALL always include the identifier of the signer's certificate and
>protect it under the digital signature.
>
>As soon as the private key is *only* used with signature formats
>that contain the identifier of the certificate protected under the
>digital signature, this provides "real-time" POP. In other words,
>only the entity owning the private key is able to include the right
>certificate identifier. If a CA has issued a certificate without
>POP, this does not matter anymore, since only the legitimate entity
>able to use the private key will be able to sign under the
>certificate that contains the matching public key. Security is a mix
>of security mechanisms and security procedures. In this case, we
>rely on "good cryptography" rather than security procedures (that
>may be hard and long to verify "after the fact").


Denis,

What you write implies that NR-keys will not be employed by "ordinary
users" for undertaking mid-high level internet transactions.

Maybe that is a "good thing".

But while I support the real-time-POP, I question the guarantee that
the "right" person possess the key in the first place.

Are you suggesting that a CA might create a key-pair (via trusted
key-device) and then create/issue an NR-certificate under your
name, BEFORE (or EVER) ascertaining that the private key/device
is in your hands?

___tony___





Tony Bartoletti 925-422-3881 <[e-mail]>
Information Operations, Warfare and Assurance Center
Lawrence Livermore National Laboratory
Livermore, CA 94551-9900



Received: from poptop.llnl.gov (poptop.llnl.gov [128.115.41.70]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id LAA15986 for <[e-mail]>; Fri, 21 Jul 2000 11:41:33 -0700 (PDT)
Received: from catalyst (catalyst.llnl.gov [128.115.222.68]) by poptop.llnl.gov (8.8.8/LLNL-3.0.2/pop.llnl.gov-5.1) with ESMTP id LAA01649; Fri, 21 Jul 2000 11:43:45 -0700 (PDT)
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.2 
Date: Fri, 21 Jul 2000 11:51:31 -0700
To: "David P. Kemp" <[e-mail]>, [e-mail]
From: Tony Bartoletti <[e-mail]>
Subject: Re: A Real Rationale for Dedicated Keys
In-Reply-To: <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed

At 02:06 PM 7/21/00 -0400, David P. Kemp wrote:
> > > Much more likely is that the owner *will* show up to the CA or one of its
> > > RAs to get a NR certificate. Anything less will probably fail to meet the
> > > legal requirements for NR and be worth no more than a NR=0 cert.
> >
> > While I mostly agree, what you are stating is impractical. Very few 
> will use
> > digital signatures that "meet the legal requirements for NR" if they 
> have to
> > physically show up to the CA.
>
>The U.S. postal service once wanted to be the CA for the masses; maybe
>7-11 or Exxon could take over that job :-).  User takes his cereal box
>token to the corner gas station, the operator looks at his driver's license
>and notarizes the cert request.

I LIKE IT! (LOL)

___tony___


Tony Bartoletti 925-422-3881 <[e-mail]>
Information Operations, Warfare and Assurance Center
Lawrence Livermore National Laboratory
Livermore, CA 94551-9900



Received: from poptop.llnl.gov (poptop.llnl.gov [128.115.41.70]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id LAA15695 for <[e-mail]>; Fri, 21 Jul 2000 11:36:07 -0700 (PDT)
Received: from catalyst (catalyst.llnl.gov [128.115.222.68]) by poptop.llnl.gov (8.8.8/LLNL-3.0.2/pop.llnl.gov-5.1) with ESMTP id LAA28395 for <[e-mail]>; Fri, 21 Jul 2000 11:38:19 -0700 (PDT)
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.2 
Date: Fri, 21 Jul 2000 11:46:06 -0700
To: [e-mail]
From: Tony Bartoletti <[e-mail]>
Subject: Re: A Real Rationale for Dedicated Keys
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed

At 08:33 AM 7/21/00 -0700, Aram Perez wrote:
>Hi Simon M.,
>
> >> Without the owner physically showing up, how can a CA know whether or not
> > a
> >> key pair was "generated and the private part is stored to some minimum
> >> standard"?
> >>
> > The key generation device has its own private key and signs the cert 
> request
> > for the newly generated user key pair. The CA then knows that the key pair
> > originated in a device it (the CA) trusts and probably provides as part of
> > its service. The CA certifies the public key of the device so it can verify
> > the device's cert requests.
>
>I'll restate my question: If the CA does not physically see the device that
>generates the key pair, how can the CA know "that the key pair originated in
>a device it (the CA) trusts"? And if the CA provides the device "as part of
>its service", then I have to physically show up to get the device and
>participate in the key generation process.
>
> >
> > Such a device is obviously not cheap but without such a device the CA 
> cannot
> > control the quality of remotely generated keys or how the private key is
> > stored and protected from duplication (necessary for NR).
> >
> > Much more likely is that the owner *will* show up to the CA or one of its
> > RAs to get a NR certificate. Anything less will probably fail to meet the
> > legal requirements for NR and be worth no more than a NR=0 cert.
>
>While I mostly agree, what you are stating is impractical. Very few will use
>digital signatures that "meet the legal requirements for NR" if they have to
>physically show up to the CA.

Could not the CA (stocked with such devices) simply ship the device to the
purported subscriber?  If it is embedded with its own (CA established)
device-key, then the CA will be able to trust the device remotely.

As far as guaranteeing that the device landed in the hands of the right
person, this is harder.  Perhaps it will come with a biometric input that
captures the subscriber's "vitals" as part of the key-certificate request.

___tony___


Tony Bartoletti 925-422-3881 <[e-mail]>
Information Operations, Warfare and Assurance Center
Lawrence Livermore National Laboratory
Livermore, CA 94551-9900



Received: from freeby.ben.algroup.co.uk (sockittome.aldigital.co.uk [194.128.162.252]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id LAA15218 for <[e-mail]>; Fri, 21 Jul 2000 11:25:20 -0700 (PDT)
Received: from algroup.co.uk (naughty.ben.algroup.co.uk [193.133.15.107]) by freeby.ben.algroup.co.uk (8.6.12/8.6.12) with ESMTP id TAA29239; Fri, 21 Jul 2000 19:42:40 +0100
Message-ID: <[e-mail]>
Date: Fri, 21 Jul 2000 19:27:15 +0100
From: Ben Laurie <[e-mail]>
Organization: A.L. Group plc
X-Mailer: Mozilla 4.7 [en] (WinNT; I)
MIME-Version: 1.0
To: [e-mail]
CC: [e-mail], [e-mail]
Subject: Re: Dual-signed certificates
References: <[e-mail]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Peter Gutmann wrote:
> 
> "Bob Jueneman" <[e-mail]> writes:
> 
> >[snip]
> >
> >>Since a certificate is comprised of public information signed by a CA,
> >>clearly a CA can create a certificate saying more-or-less what they
> >>want. I suppose this is an argument for having certificates that are
> >>dual-signed (by the CA and the public key the contain).
> 
> >Duh!  Head-slapping!  What a great idea!  I'd love to see this added to X.509
> >v3 as an optional, noncritical extension.
> 
> The chickenAndEgg extension I presume?  How do you process this (or generate
> it)?

Eh? Or are you referring to the difficulty of having the signature
within the cert? If so, quite!

Cheers,

Ben.

--
http://www.apache-ssl.org/ben.html

Coming to ApacheCon Europe 2000? http://apachecon.com/


Received: from poptop.llnl.gov (poptop.llnl.gov [128.115.41.70]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id LAA14824 for <[e-mail]>; Fri, 21 Jul 2000 11:20:47 -0700 (PDT)
Received: from catalyst (catalyst.llnl.gov [128.115.222.68]) by poptop.llnl.gov (8.8.8/LLNL-3.0.2/pop.llnl.gov-5.1) with ESMTP id LAA19076; Fri, 21 Jul 2000 11:22:56 -0700 (PDT)
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.2 
Date: Fri, 21 Jul 2000 11:30:43 -0700
To: "Bob Jueneman" <[e-mail]>, <[e-mail]>
From: Tony Bartoletti <[e-mail]>
Subject: Re: A Real Rationale for Dedicated Keys
Cc: <[e-mail]>
In-Reply-To: <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed

At 09:22 AM 7/21/00 -0600, Bob Jueneman wrote:
>Tony,
>
>I agree that creating multiple certificates containing the same key is a 
>dumb idea, because it makes it very difficult to know which set of 
>assertions (contained in the certificate) were supposed to apply to a 
>given transaction.
>
>But since the individual CA cannot possible detect or prevent someone from 
>going to two different CAs with the same public key, and making two 
>different sets of assertions, complete with full-blown POP, the only 
>reasonable solution to to place the burden firmly on the subscriber/user.
>
>If he creates two certificates for the same key, one with NR and one 
>without (or any other assertion), then unless the certificate is bound to 
>the transaction by more than just the signature, the relying party should 
>be permitted to make his case using which ever certificate is most 
>favorable to his case.

I think I agree :)

For such a "burden" to be considered reasonable by the courts, there need be
some manner of evidence that this "should have been obvious" to the user.

There are ways to make this "reasonably obvious" to the user, but I don't
want "its there in black and white in chapter 6, paragraph 23 of our CP."

Nor do I want to force the user to "deduce" that the burden may fall upon
their shoulders, based only on the "common knowledge" that a signature may
be taken as having "NR-intent" when ANY extant certificate for that key
states NR=1.

(I once wrote, only half in jest, that archived with every NR-certificate
issued should be the voiceprint of the user, reciting the CP/CPS verbatim.)

Perhaps much of my fear come from ignorance of the actual implementations,
existing and proposed, by which such signatures would become affixed.

I recall learning, via conversations with Ed Gerck, that the strength
of DES (for one example) depends critically upon what the material
being encrypted.  A "random sentence" is not really random if it is
embedded in a (say) MS Word document, the entire body of which is
being encrypted, and for which the first block of "file" will be a
constant for practically all users.  This makes an entropy-based
attack to recover the key far easier to perform.

The point being, how will the user be assured that an operation is
covering precisely what is being presented?  Where such assurance is
lacking, reliance upon minimalist NR conditions become more dangerous.

___tony___




Tony Bartoletti 925-422-3881 <[e-mail]>
Information Operations, Warfare and Assurance Center
Lawrence Livermore National Laboratory
Livermore, CA 94551-9900



Received: from roadblock.missi.ncsc.mil (roadblock.missi.ncsc.mil [144.51.50.70]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id LAA14357 for <[e-mail]>; Fri, 21 Jul 2000 11:07:36 -0700 (PDT)
Received: from roadblock.missi.ncsc.mil (root@localhost) by roadblock.missi.ncsc.mil with ESMTP id NAA23251 for <[e-mail]>; Fri, 21 Jul 2000 13:58:41 -0400 (EDT)
Message-Id: <[e-mail]>
Date: Fri, 21 Jul 2000 14:06:26 -0400 (EDT)
From: "David P. Kemp" <[e-mail]>
Reply-To: "David P. Kemp" <[e-mail]>
Subject: Re: A Real Rationale for Dedicated Keys
To: [e-mail]
MIME-Version: 1.0
Content-Type: TEXT/plain; charset=us-ascii
Content-MD5: ZDo0i7s0JKNQH8CDSRlezA==
X-Mailer: dtmail 1.3.0 CDE Version 1.3 SunOS 5.7 sun4u sparc

> From: Aram Perez <[e-mail]>
>
> > The key generation device has its own private key and signs the cert request
> > for the newly generated user key pair. The CA then knows that the key pair
> > originated in a device it (the CA) trusts and probably provides as part of
> > its service. The CA certifies the public key of the device so it can verify
> > the device's cert requests.
> 
> I'll restate my question: If the CA does not physically see the device that
> generates the key pair, how can the CA know "that the key pair originated in
> a device it (the CA) trusts"? And if the CA provides the device "as part of
> its service", then I have to physically show up to get the device and
> participate in the key generation process.

If company X produces such a device, using designs and processes that
have been evaluated, company X can give the device public key to
the CA.  The CA then knows, to the extent that the CA trusts the
manufacturing process, that any cert request including the device
signature could have come from nowhere else.  Even if the devices were
distributed in cereal boxes (with no link to a specific human) there is
assurance that user keypairs cannot be extracted or replicated.


> > Much more likely is that the owner *will* show up to the CA or one of its
> > RAs to get a NR certificate. Anything less will probably fail to meet the
> > legal requirements for NR and be worth no more than a NR=0 cert.
> 
> While I mostly agree, what you are stating is impractical. Very few will use
> digital signatures that "meet the legal requirements for NR" if they have to
> physically show up to the CA.

The U.S. postal service once wanted to be the CA for the masses; maybe
7-11 or Exxon could take over that job :-).  User takes his cereal box
token to the corner gas station, the operator looks at his driver's license
and notarizes the cert request.



Received: from mail.ec.auckland.ac.nz (mail.student.auckland.ac.nz [130.216.35.201]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id KAA13900 for <[e-mail]>; Fri, 21 Jul 2000 10:50:29 -0700 (PDT)
Received: from kahu.cs.auckland.ac.nz ([e-mail] [130.216.36.13]) by mail.ec.auckland.ac.nz (8.9.3/8.8.6/cs-master) with SMTP id FAA04593; Sat, 22 Jul 2000 05:50:54 +1200 (NZST) (sender [e-mail])
Received: by kahu.cs.auckland.ac.nz (relaymail v0.9) id <96420185332042>; Sat, 22 Jul 2000 05:50:53 (NZST)
From: [e-mail] (Peter Gutmann)
To: [e-mail]
Subject: Re:  Dual-signed certificates
Cc: [e-mail]
Sender: [e-mail]
Reply-To: [e-mail]
X-Charge-To: pgut001
X-Authenticated: relaymail v0.9 on kahu.cs.auckland.ac.nz
Date: Sat, 22 Jul 2000 05:50:53 (NZST)
Message-ID: <[e-mail]>

"Bob Jueneman" <[e-mail]> writes:

>[snip]
>
>>Since a certificate is comprised of public information signed by a CA,
>>clearly a CA can create a certificate saying more-or-less what they
>>want. I suppose this is an argument for having certificates that are
>>dual-signed (by the CA and the public key the contain).

>Duh!  Head-slapping!  What a great idea!  I'd love to see this added to X.509
>v3 as an optional, noncritical extension.

The chickenAndEgg extension I presume?  How do you process this (or generate
it)?

Peter.



Received: from mta5.snfc21.pbi.net (mta5.snfc21.pbi.net [206.13.28.241]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id KAA13089 for <[e-mail]>; Fri, 21 Jul 2000 10:17:41 -0700 (PDT)
Received: from [192.168.1.7] ([208.233.228.110]) by mta5.snfc21.pbi.net (Sun Internet Mail Server sims.3.5.2000.01.05.12.18.p9) with ESMTP id <[e-mail]> for [e-mail]; Fri, 21 Jul 2000 10:07:22 -0700 (PDT)
Date: Fri, 21 Jul 2000 10:07:46 -0700
From: Aram Perez <[e-mail]>
Subject: Re: Signing what you don't understand
In-reply-to: <[e-mail]>
To: PKIX <[e-mail]>
Message-id: <[e-mail]>
MIME-version: 1.0
Content-type: text/plain; charset="US-ASCII"
Content-transfer-encoding: 7bit
User-Agent: Microsoft-Outlook-Express-Macintosh-Edition/5.02.2022

Hi Peter S.,

[snip]
> An interesting part in the ETSI standard and the
> Internet-draft is the following reference:
> 
> 
> [TSP] C. Adams, P. Cain, D. Pinkas, R. Zuccherato. Time Stamp Protocol
> (TSP), (under progress). June 2000.

Are you saying that the ETSI standard is referring and possibly mandated the
use of something that is "under progress"? The lawyers should have a field
day!

Regards,
Aram Perez



Received: from po1.bbn.com (PO1.BBN.COM [192.1.50.38]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id KAA13030 for <[e-mail]>; Fri, 21 Jul 2000 10:16:50 -0700 (PDT)
Received: from [171.78.30.107] (fixed030-107.bbn.com [171.78.30.107] (may be forged)) by po1.bbn.com (8.9.1/8.9.1) with ESMTP id NAA26167; Fri, 21 Jul 2000 13:19:19 -0400 (EDT)
Mime-Version: 1.0
X-Sender: [e-mail]
Message-Id: <v04220811b59e34bd031a@[171.78.30.107]>
In-Reply-To: <[e-mail]>
References: <[e-mail]>
Date: Fri, 21 Jul 2000 13:16:35 -0400
To: [e-mail]
From: Stephen Kent <[e-mail]>
Subject: Re: Signing what you don't understand
Cc: [e-mail]
Content-Type: text/plain; charset="us-ascii" ; format="flowed"

John,

<snip>


>You are missing what I'm trying to say.  I'm not disputing that the
>signature was created at the time claimed.
>
>The fact that CRLs include an invalidityDate field, which can indicate that
>a certificate was invalid well before that CRL was published means that it
>is possible for a certificate revocation to be "backdated" - i.e. even
>though a perfectly valid CRL was referenced in the signature and indicated
>that the certificate was valid at the time the signature was constructed,
>another CRL can be published (possibly much) later that will say the
>certificate was invalid at the signing time.

>
>This renders signer-provided evidence of non-revocation of little use
>(unless you are willing to let the signer-provided evidence of
>non-revocation trump the more recent CRL that asserts that the certificate
>was invalid, which would open up a lot of security holes).

The inclusion of the invalidity date in a CRL does not allow 
backdating, although it may appear that way.  The argument put forth 
to justify approval of this extension was to allow the CA to alert 
RPs to newly gained info re a revocation so that IF the RP had not 
acted upon a transaction (or the like) THEN the RP could elect to 
treat the signature as invalid.  However, if an RP has collected a 
CRL that covers the interval during which the transaction took place, 
then any later CRL with an invalidity date does not prevent the RP 
from using the CRL he acquired to support NR, i.e., the RP has 
exercised due diligence by obtaining the first CRL.

<snip>

Steve



Received: from ntserver2.chrysalis-its.com ([209.47.245.163]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id KAA12419 for <[e-mail]>; Fri, 21 Jul 2000 10:00:07 -0700 (PDT)
From: [e-mail]
Received: by NTSERVER2 with Internet Mail Service (5.5.2650.21) id <PGABZ01V>; Fri, 21 Jul 2000 13:03:35 -0400
Message-ID: <[e-mail]>
To: [e-mail]
Cc: [e-mail]
Subject: RE: Indicating How Private Keys are Generated/Stored (was RE: A R eal Rationale for Dedicated Keys)
Date: Fri, 21 Jul 2000 13:03:19 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01BFF335.9AE5232C"

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01BFF335.9AE5232C
Content-Type: text/plain;
	charset="iso-8859-1"

Bob,

Yes the Novell Security Attributes keyQuality and cryptoProcessQuality from
Section 4 of your document seem to contain the basis of the information that
the subscriber (i.e. the key generation device in my case) could put in the
registration information in CRMF of a certificate request message. However,
a common standardised method would have to be supported by the IETF.

Francois
___________________________________
Francois Rousseau
Director of Standards and Conformance
Chrysalis-ITS
1688 Woodward Drive
Ottawa, Ontario, CANADA, K2C 3R7
[e-mail]      Tel. [phone] ext. 419
http://www.chrysalis-its.com     Fax. [phone]

P.S. Although the URL mentions the v1.0 for this Novell document, once
downloaded it is only version 0.998 of Aug 98.

-----Original Message-----
From: Bob Jueneman [mailto:[e-mail]]
Sent: Friday, July 21, 2000 11:40 AM
To: [e-mail]; [e-mail]
Cc: [e-mail]
Subject: Indicating How Private Keys are Generated/Stored (was RE: A
Real Rationale for Dedicated Keys)


Francois,

I completely agree.

All certificates issue by Novell, or created using Novell Certificate
Server, contain a X.509 extension called the Novell Security Attributes. An
important component of these attributes is the notion of a "certificate
quality indicator", and one of the factors of the certificate quality is an
indication of how the key was created (both the computer security and
cryptographic security of the creating process, e.g., the TCSEC, ITSEC, or
Common Criteria rating of the computing platform, together with the FIPS
140-1 rating). But in addition, it is necessary to have either a
representation from the subscriber as to how the key will be used in the
future (same parameters), and where and how the key will be stored in the
meantime.

Ideally, these representations should be enforced as constraints, with a bit
provide to indicate that fact.

For the details , including the ASN.1 encoding, see
http://developer.novell.com/repository/attributes/certattrs_v10.htm

Bob


>>><[e-mail]> 07/21/00 09:20AM >>>


Hi Simon,

I totally agree with you that if a key generation device had its own private
key that is trusted by a CA and this key was used to sign a certificate
request for a newly generated end user's key pair, this would certainly
provide more confidence for this CA to certify the end user's public key for
NR.

Currently neither the CMP protocol [RFC2510] nor the CMC protocol [RFC2797]
include a standard way for a key generation device to explicitly indicate in
a certificate request the quality of remotely generated key pair and also
how the private key will be stored and protected in the future. However,
both CMP and CMC use CRMF [RFC2511] and Section 3 on the certificate request
message indicates that the optional registration information field can
contain supplementary information related to the context of the
certification request when such information is required to fulfil a
certification request.

Wouldn't it make sense to define additional type(s) for the registration
information in CRMF for this particular purpose of indicating the quality of
remotely generated key pair and also how the private key will be stored and
protected in the future? Certificate request messages containing this new
registration information and the end user's public key would then be signed
with the private key of the key generation device, which would acting as an
RA in this case, and be forwarded to another RA or directly to the CA to be
certified. What do others think about this suggestion?

Regards,

Francois
___________________________________
Francois Rousseau
Director of Standards and Conformance
Chrysalis-ITS
1688 Woodward Drive
Ottawa, Ontario, CANADA, K2C 3R7
[e-mail] Tel. [phone] ext. 419
http://www.chrysalis-its.com Fax. [phone]

-----Original Message-----
From: Simon McMahon [mailto:[e-mail] 
Sent: Friday, July 21, 2000 12:15 AM
To: Aram Perez; [e-mail] 
Subject: Re: A Real Rationale for Dedicated Keys

>
> Without the owner physically showing up, how can a CA know whether or not

> key pair was "generated and the private part is stored to some minimum
> standard"?
>
The key generation device has its own private key and signs the cert request
for the newly generated user key pair. The CA then knows that the key pair
originated in a device it (the CA) trusts and probably provides as part of
its service. The CA certifies the public key of the device so it can verify
the device's cert requests.

Such a device is obviously not cheap but without such a device the CA cannot
control the quality of remotely generated keys or how the private key is
stored and protected from duplication (necessary for NR).
Much more likely is that the owner *will* show up to the CA or one of its
RAs to get a NR certificate. Anything less will probably fail to meet the
legal requirements for NR and be worth no more than a NR=0 cert.

Simon McMahon
ERACOM Pty. Ltd.

------_=_NextPart_001_01BFF335.9AE5232C
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Diso-8859-1">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
5.5.2650.12">
<TITLE>RE: Indicating How Private Keys are Generated/Stored (was RE: A =
Real Rationale for Dedicated Keys)</TITLE>
</HEAD>
<BODY>

<P><FONT SIZE=3D2>Bob,</FONT>
</P>

<P><FONT SIZE=3D2>Yes the Novell Security Attributes keyQuality and =
cryptoProcessQuality from Section 4 of your document seem to contain =
the basis of the information that the subscriber (i.e. the key =
generation device in my case) could put in the registration information =
in CRMF of a certificate request message. However, a common =
standardised method would have to be supported by the IETF.</FONT></P>

<P><FONT SIZE=3D2>Francois</FONT>
<BR><FONT SIZE=3D2>___________________________________</FONT>
<BR><FONT SIZE=3D2>Francois Rousseau</FONT>
<BR><FONT SIZE=3D2>Director of Standards and Conformance</FONT>
<BR><FONT SIZE=3D2>Chrysalis-ITS</FONT>
<BR><FONT SIZE=3D2>1688 Woodward Drive</FONT>
<BR><FONT SIZE=3D2>Ottawa, Ontario, CANADA, K2C 3R7</FONT>
<BR><FONT =
SIZE=3D2>[e-mail]&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Tel. =
[phone] ext. 419</FONT>
<BR><FONT SIZE=3D2><A HREF=3D"http://www.chrysalis-its.com" =
TARGET=3D"_blank">http://www.chrysalis-its.com</A>&nbsp;&nbsp;&nbsp;&nbs=
p; Fax. [phone]</FONT>
</P>

<P><FONT SIZE=3D2>P.S. Although the URL mentions the v1.0 for this =
Novell document, once downloaded it is only version 0.998 of Aug =
98.</FONT>
</P>

<P><FONT SIZE=3D2>-----Original Message-----</FONT>
<BR><FONT SIZE=3D2>From: Bob Jueneman [<A =
HREF=3D"mailto:[e-mail]">mailto:[e-mail]</A>]</F=
ONT>
<BR><FONT SIZE=3D2>Sent: Friday, July 21, 2000 11:40 AM</FONT>
<BR><FONT SIZE=3D2>To: [e-mail]; =
[e-mail]</FONT>
<BR><FONT SIZE=3D2>Cc: [e-mail]</FONT>
<BR><FONT SIZE=3D2>Subject: Indicating How Private Keys are =
Generated/Stored (was RE: A</FONT>
<BR><FONT SIZE=3D2>Real Rationale for Dedicated Keys)</FONT>
</P>
<BR>

<P><FONT SIZE=3D2>Francois,</FONT>
</P>

<P><FONT SIZE=3D2>I completely agree.</FONT>
</P>

<P><FONT SIZE=3D2>All certificates issue by Novell, or created using =
Novell Certificate Server, contain a X.509 extension called the Novell =
Security Attributes. An important component of these attributes is the =
notion of a &quot;certificate quality indicator&quot;, and one of the =
factors of the certificate quality is an indication of how the key was =
created (both the computer security and cryptographic security of the =
creating process, e.g., the TCSEC, ITSEC, or Common Criteria rating of =
the computing platform, together with the FIPS 140-1 rating). But in =
addition, it is necessary to have either a representation from the =
subscriber as to how the key will be used in the future (same =
parameters), and where and how the key will be stored in the =
meantime.</FONT></P>

<P><FONT SIZE=3D2>Ideally, these representations should be enforced as =
constraints, with a bit provide to indicate that fact.</FONT>
</P>

<P><FONT SIZE=3D2>For the details , including the ASN.1 encoding, see =
<A =
HREF=3D"http://developer.novell.com/repository/attributes/certattrs_v10.=
htm" =
TARGET=3D"_blank">http://developer.novell.com/repository/attributes/cert=
attrs_v10.htm</A></FONT>
</P>

<P><FONT SIZE=3D2>Bob</FONT>
</P>
<BR>

<P><FONT SIZE=3D2>&gt;&gt;&gt;&lt;[e-mail]&gt; =
07/21/00 09:20AM &gt;&gt;&gt;</FONT>
</P>
<BR>

<P><FONT SIZE=3D2>Hi Simon,</FONT>
</P>

<P><FONT SIZE=3D2>I totally agree with you that if a key generation =
device had its own private key that is trusted by a CA and this key was =
used to sign a certificate request for a newly generated end user's key =
pair, this would certainly provide more confidence for this CA to =
certify the end user's public key for NR.</FONT></P>

<P><FONT SIZE=3D2>Currently neither the CMP protocol [RFC2510] nor the =
CMC protocol [RFC2797] include a standard way for a key generation =
device to explicitly indicate in a certificate request the quality of =
remotely generated key pair and also how the private key will be stored =
and protected in the future. However, both CMP and CMC use CRMF =
[RFC2511] and Section 3 on the certificate request message indicates =
that the optional registration information field can contain =
supplementary information related to the context of the certification =
request when such information is required to fulfil a certification =
request.</FONT></P>

<P><FONT SIZE=3D2>Wouldn't it make sense to define additional type(s) =
for the registration information in CRMF for this particular purpose of =
indicating the quality of remotely generated key pair and also how the =
private key will be stored and protected in the future? Certificate =
request messages containing this new registration information and the =
end user's public key would then be signed with the private key of the =
key generation device, which would acting as an RA in this case, and be =
forwarded to another RA or directly to the CA to be certified. What do =
others think about this suggestion?</FONT></P>

<P><FONT SIZE=3D2>Regards,</FONT>
</P>

<P><FONT SIZE=3D2>Francois</FONT>
<BR><FONT SIZE=3D2>___________________________________</FONT>
<BR><FONT SIZE=3D2>Francois Rousseau</FONT>
<BR><FONT SIZE=3D2>Director of Standards and Conformance</FONT>
<BR><FONT SIZE=3D2>Chrysalis-ITS</FONT>
<BR><FONT SIZE=3D2>1688 Woodward Drive</FONT>
<BR><FONT SIZE=3D2>Ottawa, Ontario, CANADA, K2C 3R7</FONT>
<BR><FONT SIZE=3D2>[e-mail] Tel. [phone] ext. =
419</FONT>
<BR><FONT SIZE=3D2><A HREF=3D"http://www.chrysalis-its.com" =
TARGET=3D"_blank">http://www.chrysalis-its.com</A> Fax. (613) =
723-5078</FONT>
</P>

<P><FONT SIZE=3D2>-----Original Message-----</FONT>
<BR><FONT SIZE=3D2>From: Simon McMahon [<A =
HREF=3D"mailto:[e-mail]">mailto:[e-mail]</A> =
</FONT>
<BR><FONT SIZE=3D2>Sent: Friday, July 21, 2000 12:15 AM</FONT>
<BR><FONT SIZE=3D2>To: Aram Perez; [e-mail] </FONT>
<BR><FONT SIZE=3D2>Subject: Re: A Real Rationale for Dedicated =
Keys</FONT>
</P>

<P><FONT SIZE=3D2>&gt;</FONT>
<BR><FONT SIZE=3D2>&gt; Without the owner physically showing up, how =
can a CA know whether or not</FONT>
</P>

<P><FONT SIZE=3D2>&gt; key pair was &quot;generated and the private =
part is stored to some minimum</FONT>
<BR><FONT SIZE=3D2>&gt; standard&quot;?</FONT>
<BR><FONT SIZE=3D2>&gt;</FONT>
<BR><FONT SIZE=3D2>The key generation device has its own private key =
and signs the cert request</FONT>
<BR><FONT SIZE=3D2>for the newly generated user key pair. The CA then =
knows that the key pair</FONT>
<BR><FONT SIZE=3D2>originated in a device it (the CA) trusts and =
probably provides as part of</FONT>
<BR><FONT SIZE=3D2>its service. The CA certifies the public key of the =
device so it can verify</FONT>
<BR><FONT SIZE=3D2>the device's cert requests.</FONT>
</P>

<P><FONT SIZE=3D2>Such a device is obviously not cheap but without such =
a device the CA cannot</FONT>
<BR><FONT SIZE=3D2>control the quality of remotely generated keys or =
how the private key is</FONT>
<BR><FONT SIZE=3D2>stored and protected from duplication (necessary for =
NR).</FONT>
<BR><FONT SIZE=3D2>Much more likely is that the owner *will* show up to =
the CA or one of its</FONT>
<BR><FONT SIZE=3D2>RAs to get a NR certificate. Anything less will =
probably fail to meet the</FONT>
<BR><FONT SIZE=3D2>legal requirements for NR and be worth no more than =
a NR=3D0 cert.</FONT>
</P>

<P><FONT SIZE=3D2>Simon McMahon</FONT>
<BR><FONT SIZE=3D2>ERACOM Pty. Ltd.</FONT>
</P>

</BODY>
</HTML>
------_=_NextPart_001_01BFF335.9AE5232C--


Received: from mta5.snfc21.pbi.net (mta5.snfc21.pbi.net [206.13.28.241]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id JAA12100 for <[e-mail]>; Fri, 21 Jul 2000 09:53:01 -0700 (PDT)
Received: from [192.168.1.7] ([208.233.228.110]) by mta5.snfc21.pbi.net (Sun Internet Mail Server sims.3.5.2000.01.05.12.18.p9) with ESMTP id <[e-mail]> for [e-mail]; Fri, 21 Jul 2000 09:54:15 -0700 (PDT)
Date: Fri, 21 Jul 2000 09:54:39 -0700
From: Aram Perez <[e-mail]>
Subject: Re: A Real Rationale for Dedicated Keys
In-reply-to: <[e-mail]>
To: PKIX <[e-mail]>
Message-id: <[e-mail]>
MIME-version: 1.0
Content-type: text/plain; charset="US-ASCII"
Content-transfer-encoding: 7bit
User-Agent: Microsoft-Outlook-Express-Macintosh-Edition/5.02.2022

Hi Bob J.,

> I agree that creating multiple certificates containing the same key is a dumb
> idea, because it makes it very difficult to know which set of assertions
> (contained in the certificate) were supposed to apply to a given transaction.

Whether it is dumb or not, I have personally heard a major financial
institution state that they plan to have at least 3 certificates for the
same key. The first is a self-signed certificate since they plan to run an
internal CA. The next is a certificate issued by the ABA, since they are a
member of ABA. And the third was a certificate issued by another major
organization (which I don't recall), again because they belong to that
organization.

And speaking of dumb, PKIX allows several dumb things to happen that are
perfectly legal according to the standards.

Regards,
Aram Perez

[snip]



Received: from po1.bbn.com (PO1.BBN.COM [192.1.50.38]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id JAA11823 for <[e-mail]>; Fri, 21 Jul 2000 09:47:29 -0700 (PDT)
Received: from [171.78.30.107] (fixed030-107.bbn.com [171.78.30.107] (may be forged)) by po1.bbn.com (8.9.1/8.9.1) with ESMTP id MAA22127; Fri, 21 Jul 2000 12:49:23 -0400 (EDT)
Mime-Version: 1.0
X-Sender: [e-mail]
Message-Id: <v0422080eb59e2d1e3897@[171.78.30.107]>
In-Reply-To: <[e-mail]>
References: <[e-mail]>
Date: Fri, 21 Jul 2000 12:42:51 -0400
To: Aram Perez <[e-mail]>
From: Stephen Kent <[e-mail]>
Subject: Re: Signing what you don't understand
Cc: [e-mail]
Content-Type: text/plain; charset="us-ascii" ; format="flowed"

Aram,

>Hi Steve K.,
>
>  > Aram,
>  >
>  >> Hi Steve K.,
>  >>
>  >>> When we check a signature for NR, and significant time has elapsed
>  >>> since the signature was applied, then different rules must be
>  >>> employed.
>  >>
>  >> How do you know how much "time has elapsed since the signature 
>was applied"?
>  >> I am not aware of any standard that mandates the time of the signature.
>  >> S/MIME/PKCS#7 has provision for the signature time, but they don't mandate
>  >> it.
>  >
>  > If one is looking to effect NR, one has to do a number of things
>  > beyond simple signature checking of the sort required for typical
>  > authentication for input to an access control process.  For example,
>  > one often needs to time stamp the signature on the data, collect the
>  > certs and CRLs and have them time stamped, etc.  This creates a
>  > context that allows NR signature verification for the longer term
>  > than the validity of the signer's cert, or the signer's CAs' cert,
>  > etc.
>
>Without regurgitating the previous discussions on the validity of the NR
>bit, where would someone know that if you are trying "to effect NR, one has
>to do a number of things beyond simple signature checking"?


 From my perspective most of the NR burden usually is on the RP, and 
an RP knows when it is interested in NR vs. simple authentication.

>Denis P. pointed
>out ETSI Standard ES 201733, but how many implementers of digital signatures
>that effect NR have read that standard and implemented it?

I doubt that this is widely used yet, but then I see very little if 
any use of digital signatures for high value, long term NR anyway.

Steve



Received: from prv-mail20.provo.novell.com (prv-mail20.provo.novell.com [137.65.81.122]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id JAA11328 for <[e-mail]>; Fri, 21 Jul 2000 09:38:56 -0700 (PDT)
Received: from INET-PRV-Message_Server by prv-mail20.provo.novell.com with Novell_GroupWise; Fri, 21 Jul 2000 10:40:59 -0600
Message-Id: <[e-mail]>
X-Mailer: Novell GroupWise Internet Agent 5.5.3.1
Date: Fri, 21 Jul 2000 10:41:01 -0600
From: "Bob Jueneman" <[e-mail]>
To: <[e-mail]>, <[e-mail]>
Cc: <[e-mail]>
Subject: Dual-signed certificates
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by ns.secondary.com id JAA11329

Ben,

[snip]

>Since a certificate is comprised of public information signed by a CA,
>clearly a CA can create a certificate saying more-or-less what they
>want. I suppose this is an argument for having certificates that are
>dual-signed (by the CA and the public key the contain).

Duh!  Head-slapping!  What a great idea!  I'd love to see this added to
X.509 v3 as an optional, noncritical extension.

For years, especially within the ABA, we have talked about the need
for the user to explicitly confirm acceptance of the certificate, but at present 
there is no good way to confirm acceptance, except by procedures
that are not verifiable by any relying party.  Obviously, having the user 
sign the certificate herself would confirm acceptance.

Now, granted, if a rogue CA wanted to create a bogus certificate
containing my name and their public key, they could also sign the
certificate, since they would possess the private key.

However, this threat tends to evaporate as soon as the real user signs 
something which in all likelihood only that user could have done.
and the more transactions that are signed, the more confidence that 
it really is the user -- in fact irrespective of the certificate, because the 
confidence in a signature tends to increase though repetitive use. 

As an aside, I sometimes get into arguments with people about whether, 
and how, trusted roots should be incorporated within browsers, etc.

My experience is that I often receive a signed e-mail from someone whose
root is not in my cache of trusted roots.  Because in most cases the authentication
of the user isn't exactly life and death (users who post to this list, for example),
I tend to click OK and add that root to my cache.  Now, one certificate 
authenticated by that root doesn't prove much, but by the time I've received 
three or four certificates all signed by the US DOD Medium Assurance CA,
for example, I have a greatly increased confidence that that root is bone fide.

Bob



Received: from po1.bbn.com (PO1.BBN.COM [192.1.50.38]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id JAA11127 for <[e-mail]>; Fri, 21 Jul 2000 09:36:43 -0700 (PDT)
Received: from [171.78.30.107] (fixed030-107.bbn.com [171.78.30.107] (may be forged)) by po1.bbn.com (8.9.1/8.9.1) with ESMTP id MAA20850; Fri, 21 Jul 2000 12:39:23 -0400 (EDT)
Mime-Version: 1.0
X-Sender: [e-mail]
Message-Id: <v0422080db59e2c23fdc9@[171.78.30.107]>
In-Reply-To: <[e-mail]>
References: <[e-mail]>
Date: Fri, 21 Jul 2000 12:38:26 -0400
To: "David P. Kemp" <[e-mail]>
From: Stephen Kent <[e-mail]>
Subject: RE: Reverse paths
Cc: [e-mail]
Content-Type: text/plain; charset="us-ascii" ; format="flowed"

Save,

>Steve,
>
>If the intent of the bridge is to enable universal cryptographic
>connectivity (which I believe it is), then using a bridge CA merely
>as a "super certifier" for obtaining trusted copies of other
>communities' keys doesn't avoid having to issue and manage N**2
>cross certs.

Agreed.  It just provides a way for each CA that WANTS to cross 
certify with other CAs to acquire the public key of the other CAs.

>And including the bridge CA in paths does not preclude name
>constraints - it is feasible and reasonable for each community
>to distinguish between "my namespace" and "everyone else" in it's
>outbound cert, and it is also feasible to use the bridge CA as a
>namespace allocation authority to enforce disjointness using the
>inbound certs.

Yes, one can use the exclusion feature of name constraints to enforce 
that distinction, but that's a pretty wimpy feature compared to 
forcing each cross certified CA to issue certs ONLY within the name 
space for which it is authoritative.  Similarly, for policy stuff, 
one seems tp be restricted to a one size fits all model for dealing 
with other CAs, as opposed to being able to make pairwise decisions.

Steve



Received: from raptor.access.net.id ([e-mail] [202.180.0.14]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id JAA10953 for <[e-mail]>; Fri, 21 Jul 2000 09:32:39 -0700 (PDT)
Received: from mahatel (pteredon137.access.net.id [202.180.8.137]) by raptor.access.net.id (8.10.0/8.10.0) with SMTP id e6LGOYM04901; Fri, 21 Jul 2000 23:24:38 +0700
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Light Version 3.0.6 (32)
Date: Fri, 21 Jul 2000 23:15:17 +0700
To: [e-mail]
From: Teddy A Purwadi <[e-mail]>
Subject: Re: Value of smart cards. Re: Signing what you don't understand
Cc: "Anders Rundgren" <[e-mail]>, [e-mail]
In-Reply-To: <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"

Folks,
Is there an idea to discuss new Internet-Smart-Card?
It might be IIN application on it.
IMHO:
Since we will have Standard PKI for each country,
Internet-Smart-Card might be the one to be chosen.  

-Teddy

At 11:49 AM 7/20/00 -0400, [e-mail] wrote:
>
>
>
>>The discrete credit-sized smart card is probably not going to take over the
>world
>>as you say.  But the SIM/WIM card will. Actually 300 million *existing*
>customers
>>can't be wrong!
>
>I just want to add a comment for the SIM card - It is a smaller version of
>Smartcard in a different footprint.  The program in the GSM card use
>non-standard encryption, it is not truely secure (both phyical/logical).
>
>>It provides a cheap tamper-resistant storage and crypto-processor that
*will*
>also
>>be apart of PDAs when they are "connected".  It is the ability to insert a
>>subscription into a mobile phone and PDA that is the driving factor now.
>>Later it will be PKI.
>IMHO: I do like to see the PDA or phone will accept personal (crypto)
smartcard
>that could perform secure operations (ie. Sign Document, payment...)
>
>Mcken Mak
>
>
ISOC: Indonesian Information-Internet Society
Grha Citra Caraka, Mezzanine Fl, IIX-NAP NOC 
Jln Gatot Subroto 52, Jakarta 12710 - INDONESIA
V:[phone]; F: [phone]; M: [phone]
E: [e-mail]; I: http://www.mii.or.id


Received: from roadblock.missi.ncsc.mil (roadblock.missi.ncsc.mil [144.51.50.70]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id JAA10536 for <[e-mail]>; Fri, 21 Jul 2000 09:17:40 -0700 (PDT)
Received: from roadblock.missi.ncsc.mil (root@localhost) by roadblock.missi.ncsc.mil with ESMTP id MAA21402 for <[e-mail]>; Fri, 21 Jul 2000 12:08:45 -0400 (EDT)
Message-Id: <[e-mail]>
Date: Fri, 21 Jul 2000 12:16:30 -0400 (EDT)
From: "David P. Kemp" <[e-mail]>
Reply-To: "David P. Kemp" <[e-mail]>
Subject: RE: Reverse paths
To: [e-mail]
MIME-Version: 1.0
Content-Type: TEXT/plain; charset=us-ascii
Content-MD5: E87srE3220l3uuz9FMiuHQ==
X-Mailer: dtmail 1.3.0 CDE Version 1.3 SunOS 5.7 sun4u sparc

Steve,

If the intent of the bridge is to enable universal cryptographic
connectivity (which I believe it is), then using a bridge CA merely
as a "super certifier" for obtaining trusted copies of other
communities' keys doesn't avoid having to issue and manage N**2
cross certs.

And including the bridge CA in paths does not preclude name
constraints - it is feasible and reasonable for each community
to distinguish between "my namespace" and "everyone else" in it's
outbound cert, and it is also feasible to use the bridge CA as a
namespace allocation authority to enforce disjointness using the
inbound certs.

Dave




> From: Stephen Kent <[e-mail]>
> 
> Sharon,
> 
> I think the Federal Bridge CA model is broken.  It is appropriate to 
> use a bridge CA as a convenient means of distributing certificates 
> between communities, to avoid the order N**2 cross certification 
> problem.  CA-1 could go to the bridge CA to acquire the public key 
> for CA-2, then import that key into CA-1's domain, by issuing a cross 
> certificate from CA-1 to CA-2.  In this fashion CA-1 van impose the 
> appropriate name constraints extension, appropriate  policy mapping 
> constrains, even basic constraints on the depth of cert paths.  Then 
> the existing processing methods we have should work, right?
> 
> If one tries to process a path via a bridge CA, then  one looses the 
> ability to impose name constraints, and to apply selective policy 
> mapping etc, because the bridge CA is in the path, getting in the way 
> :-).  So, no, I am not persuaded by the suggestion that bridge CAs 
> are the wave of the future.  I think they are ill conceived in their 
> current use, but they could be rehabilitated!
> 
> <snip>
> 
> Steve



Received: from odin2.bull.net (odin2.bull.net [192.90.70.84]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id JAA10181 for <[e-mail]>; Fri, 21 Jul 2000 09:09:44 -0700 (PDT)
Received: from lvt-mail.frlv.bull.fr (lvt-mail.frlv.bull.fr [129.184.62.223]) by odin2.bull.net (8.9.3/8.9.3) with ESMTP id SAA46768; Fri, 21 Jul 2000 18:16:07 +0200
Received: from bull.net (frpq6118.frpq.bull.fr [129.184.8.64]) by lvt-mail.frlv.bull.fr (8.9.2/8.9.1) with ESMTP id SAA39594; Fri, 21 Jul 2000 18:11:42 +0200
Message-ID: <[e-mail]>
Date: Fri, 21 Jul 2000 18:11:44 +0200
From: Denis Pinkas <[e-mail]>
Organization: Bull
X-Mailer: Mozilla 4.7 [fr] (Win98; I)
X-Accept-Language: fr
MIME-Version: 1.0
To: [e-mail]
CC: [e-mail]
Subject: Re: Signing what you don't understand
References: <[e-mail]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

John,

(deleted text)
 
> You are missing what I'm trying to say.  I'm not disputing that the
> signature was created at the time claimed.
> 
> The fact that CRLs include an invalidityDate field, which can indicate that
> a certificate was invalid well before that CRL was published means that it
> is possible for a certificate revocation to be "backdated" - i.e. even
> though a perfectly valid CRL was referenced in the signature and indicated
> that the certificate was valid at the time the signature was constructed,
> another CRL can be published (possibly much) later that will say the
> certificate was invalid at the signing time.

OK. I now understand better ! The point you are raising is
interesting.

If the RP uses the current CRL then he is *sure* that he is missing
revocations that recently occured. In any case the time to wait for
fetching the revocation status of a certificate is "signature policy
dependent". But let us suppose that the time is set to a very short
period of time. In that case the RP thinks he holds a valid proof
(this is the case you mention) and the signer, in order to object
would have to ask for the CA to prove when his certificate was
revoked.

The case you mention also exists with OCSP server, even if it
provide "real time" information just because it is reasonable to
give time to the real signer to report a key compromise. 

The conclusion is that the signature policy must set a period which
is "big enough and reasonable". This is for this reason why when
validating an electronic signature you may get "incomplete
validation" which means that you have to try again later on.

For high value transactions, the time to wait might be counted in
days (to make sure that the real user noticed that his private key
has been compromised and to give him the time to report).


> This renders signer-provided evidence of non-revocation of little use
> (unless you are willing to let the signer-provided evidence of
> non-revocation trump the more recent CRL that asserts that the certificate
> was invalid, which would open up a lot of security holes).

(deleted text)

> I think you're agreeing with the point I was originally trying to make.

In that case that's fine !

Denis

> This conversation started because it was suggested that simply using the
> correct certificate chain would obviate the need for putting anything
> special into the signature in support of NR - my response was that binding
> the cert chain into the signature has some disadvantages, notably that the
> signature can be rendered unverifiable _by_the_RP_ by circumstances that
> ought to have no bearing on the signer's trustworthiness.  You appear to be
> countering this with a requirement that the signer put special evidence
> designed in support of NR (but in this case used by the RP to perform an
> initial signature verification) into the signature in addition to the cert
> chain.  I pointed out above that, due to the possibility of backdated
> revocations, this doesn't really work, but that's really beside the point,
> since requiring putting NR evidence into the signature is itself an
> addition to the signature.
 
> John


Received: from mta5.snfc21.pbi.net (mta5.snfc21.pbi.net [206.13.28.241]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id JAA09919 for <[e-mail]>; Fri, 21 Jul 2000 09:05:56 -0700 (PDT)
Received: from [192.168.1.7] ([208.233.228.110]) by mta5.snfc21.pbi.net (Sun Internet Mail Server sims.3.5.2000.01.05.12.18.p9) with ESMTP id <[e-mail]> for [e-mail]; Fri, 21 Jul 2000 09:05:41 -0700 (PDT)
Date: Fri, 21 Jul 2000 09:06:15 -0700
From: Aram Perez <[e-mail]>
Subject: AW: Signing what you don't understand
To: PKIX <[e-mail]>
Message-id: <[e-mail]>
MIME-version: 1.0
Content-type: text/plain; charset="US-ASCII"
Content-transfer-encoding: 7bit
User-Agent: Microsoft-Outlook-Express-Macintosh-Edition/5.02.2022

Hi Peter L.,

>> Several leading PKI vendors have implemented systems where the private key
>> is held on a central Web server and then downloaded at run time to a web
>> browser.  Are you saying that signatures created using these keys are
>> invalid?
>Are you sure? Could you provide a reference? I doubt that strongly...

Sorry for the delay, but I thought someone on PKIX had mentioned something
on this and it took me a while to find it in the PKIX archives. Partly
because these keys are referred to as one of the following: mobile or
roaming credentials. Anyway, on 15 Mar 2000, Magnus Nystrom wrote:

"Please find attached to this email a memo discussing the use of and
potential need for a PDU format and associated protocol for down- (and
potentiall up-) load of personal credentials, such as private keys and
X.509 certificates.

Stephen Farrell of Baltimore is likely to give a presentation on this
subject at the upcoming IETF meeting in Adelaide. We are currently
unsure of whether this would be a work item for PKIX or for some BOF
(or at all), but at least it seems as if this mailing list would be a
good starting point. Comments are of course welcome and solicited."

On 3 Jul 2000, Stephen Farrel wrote:

"I put up a slide in Adelaide about roaming credentials and it
looks like we're on for a BOF in Pittsburgh (date TBD). The
strawman charter/BOF description is attached. So, if you're
interested then subscribe to the list and let's see how much
progress we can make prior to Pittsburgh.

Paul Hoffman has kindly agreed to host the mailing list which
he'll open for postings in a day or two, as soon as subscribing
is seen to be working without problems, (but you can subscribe
right now). Paul's also hosting the web site at:

           http://www.imc.org/ietf-sacred

If you have any questions in the meantime, feel free to
mail Magnus and/or me directly."

Regards,
Aram Perez



Received: from po1.bbn.com (PO1.BBN.COM [192.1.50.38]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id IAA09422 for <[e-mail]>; Fri, 21 Jul 2000 08:57:28 -0700 (PDT)
Received: from [171.78.30.107] (fixed030-107.bbn.com [171.78.30.107] (may be forged)) by po1.bbn.com (8.9.1/8.9.1) with ESMTP id LAA14166; Fri, 21 Jul 2000 11:59:32 -0400 (EDT)
Mime-Version: 1.0
X-Sender: [e-mail]
Message-Id: <v0422080ab59e2219a1d8@[171.78.30.107]>
In-Reply-To:  <[e-mail]>
References:  <[e-mail]>
Date: Fri, 21 Jul 2000 11:52:18 -0400
To: Sharon Boeyen <[e-mail]>
From: Stephen Kent <[e-mail]>
Subject: RE: Reverse paths
Cc: [e-mail]
Content-Type: text/plain; charset="us-ascii" ; format="flowed"

Sharon,

>OK, I think we've cleared up the confusion.
>
>So what I'd propose is the addition of a sentence along these lines:
>
>If a CA issues a certificate to a CA that is not a subordinate to the
>issuing
>CA, the issuing CA must place the certificate in its own directory entry in
>the crossCertificatePair attribute as a value of the reverse element.
>
>Is that ok?
>

Sounds OK to me.

Steve



Received: from po1.bbn.com (PO1.BBN.COM [192.1.50.38]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id IAA09427 for <[e-mail]>; Fri, 21 Jul 2000 08:57:29 -0700 (PDT)
Received: from [171.78.30.107] (fixed030-107.bbn.com [171.78.30.107] (may be forged)) by po1.bbn.com (8.9.1/8.9.1) with ESMTP id LAA14175; Fri, 21 Jul 2000 11:59:36 -0400 (EDT)
Mime-Version: 1.0
X-Sender: [e-mail]
Message-Id: <v0422080bb59e22c1c958@[171.78.30.107]>
In-Reply-To:  <[e-mail]>
References:  <[e-mail]>
Date: Fri, 21 Jul 2000 11:55:20 -0400
To: Sharon Boeyen <[e-mail]>
From: Stephen Kent <[e-mail]>
Subject: RE: forward & reverse confusion
Cc: [e-mail]
Content-Type: text/plain; charset="us-ascii" ; format="flowed"

Sharon,

>Another side issue:
>
>In any conversation I have on these attributes or on path development or
>on path processing, the terms 'forward' and 'reverse' cause confusion. I
>suspect
>I'm not alone in this.
>
>How do folks feel about submitting a defect report that would replace those
>terms in the crossCertificatePair attribute with less confusing ones (e.g.
>certsIssuedToThisCA, certsIssuedByThisCA)? I'm certainly not wed to those
>terms, but something along those lines that better conveys what they really
>are.

Yes, I agree that it would be beneficial to change the terminology.

Steve



Received: from mta5.snfc21.pbi.net (mta5.snfc21.pbi.net [206.13.28.241]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id IAA08869 for <[e-mail]>; Fri, 21 Jul 2000 08:48:49 -0700 (PDT)
Received: from [192.168.1.7] ([208.233.228.110]) by mta5.snfc21.pbi.net (Sun Internet Mail Server sims.3.5.2000.01.05.12.18.p9) with ESMTP id <[e-mail]> for [e-mail]; Fri, 21 Jul 2000 08:44:36 -0700 (PDT)
Date: Fri, 21 Jul 2000 08:45:16 -0700
From: Aram Perez <[e-mail]>
Subject: Re: Signing what you don't understand
In-reply-to: <v04220800b59e009cc38f@[171.78.30.107]>
To: Stephen Kent <[e-mail]>
Cc: [e-mail]
Message-id: <[e-mail]>
MIME-version: 1.0
Content-type: text/plain; charset="US-ASCII"
Content-transfer-encoding: 7bit
User-Agent: Microsoft-Outlook-Express-Macintosh-Edition/5.02.2022

Hi Steve K.,

> Aram,
> 
>> Hi Steve K.,
>> 
>>> When we check a signature for NR, and significant time has elapsed
>>> since the signature was applied, then different rules must be
>>> employed.
>> 
>> How do you know how much "time has elapsed since the signature was applied"?
>> I am not aware of any standard that mandates the time of the signature.
>> S/MIME/PKCS#7 has provision for the signature time, but they don't mandate
>> it.
> 
> If one is looking to effect NR, one has to do a number of things
> beyond simple signature checking of the sort required for typical
> authentication for input to an access control process.  For example,
> one often needs to time stamp the signature on the data, collect the
> certs and CRLs and have them time stamped, etc.  This creates a
> context that allows NR signature verification for the longer term
> than the validity of the signer's cert, or the signer's CAs' cert,
> etc.

Without regurgitating the previous discussions on the validity of the NR
bit, where would someone know that if you are trying "to effect NR, one has
to do a number of things beyond simple signature checking"? Denis P. pointed
out ETSI Standard ES 201733, but how many implementers of digital signatures
that effect NR have read that standard and implemented it?

Regards,
Aram Perez



Received: from mta5.snfc21.pbi.net (mta5.snfc21.pbi.net [206.13.28.241]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id IAA08770 for <[e-mail]>; Fri, 21 Jul 2000 08:48:08 -0700 (PDT)
Received: from [192.168.1.7] ([208.233.228.110]) by mta5.snfc21.pbi.net (Sun Internet Mail Server sims.3.5.2000.01.05.12.18.p9) with ESMTP id <[e-mail]> for [e-mail]; Fri, 21 Jul 2000 08:33:55 -0700 (PDT)
Date: Fri, 21 Jul 2000 08:33:44 -0700
From: Aram Perez <[e-mail]>
Subject: Re: A Real Rationale for Dedicated Keys
In-reply-to: <028d01bff2ca$4956e3d0$[e-mail]>
To: [e-mail]
Message-id: <[e-mail]>
MIME-version: 1.0
Content-type: text/plain; charset="US-ASCII"
Content-transfer-encoding: 7bit
User-Agent: Microsoft-Outlook-Express-Macintosh-Edition/5.02.2022

Hi Simon M.,

>> Without the owner physically showing up, how can a CA know whether or not
> a
>> key pair was "generated and the private part is stored to some minimum
>> standard"?
>> 
> The key generation device has its own private key and signs the cert request
> for the newly generated user key pair. The CA then knows that the key pair
> originated in a device it (the CA) trusts and probably provides as part of
> its service. The CA certifies the public key of the device so it can verify
> the device's cert requests.

I'll restate my question: If the CA does not physically see the device that
generates the key pair, how can the CA know "that the key pair originated in
a device it (the CA) trusts"? And if the CA provides the device "as part of
its service", then I have to physically show up to get the device and
participate in the key generation process.

> 
> Such a device is obviously not cheap but without such a device the CA cannot
> control the quality of remotely generated keys or how the private key is
> stored and protected from duplication (necessary for NR).
> 
> Much more likely is that the owner *will* show up to the CA or one of its
> RAs to get a NR certificate. Anything less will probably fail to meet the
> legal requirements for NR and be worth no more than a NR=0 cert.

While I mostly agree, what you are stating is impractical. Very few will use
digital signatures that "meet the legal requirements for NR" if they have to
physically show up to the CA.

Just my opinion,
Aram Perez



Received: from mta5.snfc21.pbi.net (mta5.snfc21.pbi.net [206.13.28.241]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id IAA08768 for <[e-mail]>; Fri, 21 Jul 2000 08:48:08 -0700 (PDT)
Received: from [192.168.1.7] ([208.233.228.110]) by mta5.snfc21.pbi.net (Sun Internet Mail Server sims.3.5.2000.01.05.12.18.p9) with ESMTP id <[e-mail]> for [e-mail]; Fri, 21 Jul 2000 08:39:06 -0700 (PDT)
Date: Fri, 21 Jul 2000 08:38:36 -0700
From: Aram Perez <[e-mail]>
Subject: Re: Signing what you don't understand
In-reply-to: <[e-mail]>
To: PKIX <[e-mail]>
Message-id: <[e-mail]>
MIME-version: 1.0
Content-type: text/plain; charset="US-ASCII"
Content-transfer-encoding: 7bit
User-Agent: Microsoft-Outlook-Express-Macintosh-Edition/5.02.2022

Hi Denis P.,

> ETSI Standard ES 201733 mandates the signature time as a signed
> attribute of the CMS structure.

How widely implemented/used is this standard? Who determines the signature
time? Is the signature time "certified"?

> An informational draft RFC based on
> that standard is available from:
> 
> http://www.ietf.org/internet-drafts/draft-ietf-smime-esformats-01.txt

How long before this "informational draft RFC" becomes a standard?

Regards,
Aram Perez



Received: from prv-mail20.provo.novell.com (prv-mail20.provo.novell.com [137.65.81.122]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id IAA06938 for <[e-mail]>; Fri, 21 Jul 2000 08:38:38 -0700 (PDT)
Received: from INET-PRV-Message_Server by prv-mail20.provo.novell.com with Novell_GroupWise; Fri, 21 Jul 2000 09:40:35 -0600
Message-Id: <[e-mail]>
X-Mailer: Novell GroupWise Internet Agent 5.5.3.1
Date: Fri, 21 Jul 2000 09:40:29 -0600
From: "Bob Jueneman" <[e-mail]>
To: <[e-mail]>, <[e-mail]>
Cc: <[e-mail]>
Subject: Indicating How Private Keys are Generated/Stored (was RE: A Real Rationale for Dedicated Keys)
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by ns.secondary.com id IAA06940

Francois,

I completely agree.

All certificates issue by Novell, or created using Novell Certificate Server, contain a X.509 extension called the Novell Security Attributes. An important component of these attributes is the notion of a "certificate quality indicator", and one of the factors of the certificate quality is an indication of how the key was created (both the computer security and cryptographic security of the creating process, e.g., the TCSEC, ITSEC, or Common Criteria rating of the computing platform, together with the FIPS 140-1 rating). But in addition, it is necessary to have either a representation from the subscriber as to how the key will be used in the future (same parameters), and where and how the key will be stored in the meantime.

Ideally, these representations should be enforced as constraints, with a bit provide to indicate that fact.

For the details , including the ASN.1 encoding, see http://developer.novell.com/repository/attributes/certattrs_v10.htm

Bob


>>><[e-mail]> 07/21/00 09:20AM >>>


Hi Simon,
I totally agree with you that if a key generation device had its own private key that is trusted by a CA and this key was used to sign a certificate request for a newly generated end user's key pair, this would certainly provide more confidence for this CA to certify the end user's public key for NR.
Currently neither the CMP protocol [RFC2510] nor the CMC protocol [RFC2797] include a standard way for a key generation device to explicitly indicate in a certificate request the quality of remotely generated key pair and also how the private key will be stored and protected in the future. However, both CMP and CMC use CRMF [RFC2511] and Section 3 on the certificate request message indicates that the optional registration information field can contain supplementary information related to the context of the certification request when such information is required to fulfil a certification request.
Wouldn't it make sense to define additional type(s) for the registration information in CRMF for this particular purpose of indicating the quality of remotely generated key pair and also how the private key will be stored and protected in the future? Certificate request messages containing this new registration information and the end user's public key would then be signed with the private key of the key generation device, which would acting as an RA in this case, and be forwarded to another RA or directly to the CA to be certified. What do others think about this suggestion?
Regards,
Francois
___________________________________
Francois Rousseau
Director of Standards and Conformance
Chrysalis-ITS
1688 Woodward Drive
Ottawa, Ontario, CANADA, K2C 3R7
[e-mail] Tel. [phone] ext. 419
http://www.chrysalis-its.com Fax. [phone]

-----Original Message-----
From: Simon McMahon [mailto:[e-mail] 
Sent: Friday, July 21, 2000 12:15 AM
To: Aram Perez; [e-mail] 
Subject: Re: A Real Rationale for Dedicated Keys

>
> Without the owner physically showing up, how can a CA know whether or not

> key pair was "generated and the private part is stored to some minimum
> standard"?
>
The key generation device has its own private key and signs the cert request
for the newly generated user key pair. The CA then knows that the key pair
originated in a device it (the CA) trusts and probably provides as part of
its service. The CA certifies the public key of the device so it can verify
the device's cert requests.
Such a device is obviously not cheap but without such a device the CA cannot
control the quality of remotely generated keys or how the private key is
stored and protected from duplication (necessary for NR).
Much more likely is that the owner *will* show up to the CA or one of its
RAs to get a NR certificate. Anything less will probably fail to meet the
legal requirements for NR and be worth no more than a NR=0 cert.
Simon McMahon
ERACOM Pty. Ltd.



Received: from arista.iris.com (arista.iris.com [198.112.211.42]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id IAA06332 for <[e-mail]>; Fri, 21 Jul 2000 08:36:30 -0700 (PDT)
From: [e-mail]
Subject: Re: Signing what you don't understand
To: Denis Pinkas <[e-mail]>
Cc: [e-mail], [e-mail]
X-Mailer: Lotus Notes Release 5.0.2c  February 2, 2000
Message-ID: <[e-mail]>
Date: Fri, 21 Jul 2000 11:39:30 -0400
X-MIMETrack: Serialize by Router on Arista/Iris(Build V505_07112000 |July 11, 2000) at 07/21/2000 11:39:15 AM
MIME-Version: 1.0
Content-type: text/plain; charset=us-ascii

Denis,


>> >This is contradictory. "if it includes evidence that at the time of
>> >signature creation, those certificates had not yet been revoked"
>> >means that you must provide a proof that the certificates whre not
>> >revoked at the time of the signature, so you cannot say at the same
>> >time "certificate chain that contains revoked certificates".
>>
>> It's not contradictory:  Evidence that a certificate had not been
revoked
>> at time T could include a CRL that was valid at T, and that did not list
>> the certificate.  However, if later a CRL were published (and were
>> available to the RP) that included the certificate, along with an
>> invalidityDate before time T, then the RP can conclude that the
certificate
>> has been revoked, and should not be trusted to verify a signature made
at
>> T.
>
>You should talk a closer look at <draft-ietf-smime-esformats-01.txt>
>section 4.1.1  Signature Timestamp Attribute Definition
>
>The Signature Validation Policy specifies, in the
>signatureTimestampDelay field of TimestampTrustConditions, a maximum
>acceptable time difference which is allowed between the time
>indicated in the signing time attribute and the time indicated by
>the Signature Timestamp attribute. If this delay is exceeded then
>the electronic signature *must* be considered as invalid.
>
>This means that the signed data *must* include a signing time (as a
>signed attribute from the CMS construct). This allows to solve
>unambiguously the case.

You are missing what I'm trying to say.  I'm not disputing that the
signature was created at the time claimed.

The fact that CRLs include an invalidityDate field, which can indicate that
a certificate was invalid well before that CRL was published means that it
is possible for a certificate revocation to be "backdated" - i.e. even
though a perfectly valid CRL was referenced in the signature and indicated
that the certificate was valid at the time the signature was constructed,
another CRL can be published (possibly much) later that will say the
certificate was invalid at the signing time.

This renders signer-provided evidence of non-revocation of little use
(unless you are willing to let the signer-provided evidence of
non-revocation trump the more recent CRL that asserts that the certificate
was invalid, which would open up a lot of security holes).


>> >So what are you talking about ???
>>
>> The case where an RP receives a document and is trying to verify a
>> signature.  The significance of the NR bit in a certificate was the
>> starting point for this discussion, but for now I'm simply concerned
with
>> the initial signature verification (if the RP doesn't believe my
signature,
>> he certainly can't expect to hold me to it :).  Note I'm not restricting
>> this to simple E-mail, where because of the one-to-one, low-latency
nature
>> of the communications involved, there is unlikely to be a significant
time
>> between signing and verifying (and if there is, the RP can simply ask
the
>> sender for a freshly-signed copy).  Rather, I'm talking about
high-latency
>> or one-to-many environments.  An extreme example of this might be
signing a
>> document and placing it on a web-site or in a directory - here I am
signing
>> the document without any knowledge of the identity of the RPs, and with
the
>> possibility of significant delay before an RP will try to verify the
>> signature.
>
>Your are talking NR without knowing it. :-)
>
>In your example, the signed data does not have NR properties but the
>RP would like to get the the NR properties. So unless the signer
>places signed data that have NR properties, the case CANNOT be
>solved, i.e. disputes cannot be solved, just because there is not
>enough information available to solve the dispute.  So unless
>"sufficient" information is orginally placed, the signed message
>does not have long term properties.

I think you're agreeing with the point I was originally trying to make.
This conversation started because it was suggested that simply using the
correct certificate chain would obviate the need for putting anything
special into the signature in support of NR - my response was that binding
the cert chain into the signature has some disadvantages, notably that the
signature can be rendered unverifiable _by_the_RP_ by circumstances that
ought to have no bearing on the signer's trustworthiness.  You appear to be
countering this with a requirement that the signer put special evidence
designed in support of NR (but in this case used by the RP to perform an
initial signature verification) into the signature in addition to the cert
chain.  I pointed out above that, due to the possibility of backdated
revocations, this doesn't really work, but that's really beside the point,
since requiring putting NR evidence into the signature is itself an
addition to the signature.

John




Received: from sothmxs01.entrust.com (gatekeeper.entrust.com [204.101.128.170]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id IAA05406 for <[e-mail]>; Fri, 21 Jul 2000 08:32:36 -0700 (PDT)
Received: by sothmxs01.entrust.com with Internet Mail Service (5.5.2650.21) id <PHL2HG57>; Fri, 21 Jul 2000 11:34:47 -0400
Message-ID: <[e-mail]>
From: Sharon Boeyen <[e-mail]>
To: "'Stephen Kent'" <[e-mail]>
Cc: [e-mail]
Subject: RE: forward & reverse confusion
Date: Fri, 21 Jul 2000 11:33:06 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain; charset="iso-8859-1"

Another side issue:

In any conversation I have on these attributes or on path development or 
on path processing, the terms 'forward' and 'reverse' cause confusion. I
suspect
I'm not alone in this. 

How do folks feel about submitting a defect report that would replace those 
terms in the crossCertificatePair attribute with less confusing ones (e.g. 
certsIssuedToThisCA, certsIssuedByThisCA)? I'm certainly not wed to those 
terms, but something along those lines that better conveys what they really
are.

Sharon

> -----Original Message-----
> From: Stephen Kent [mailto:[e-mail]]
> Sent: Friday, July 21, 2000 9:41 AM
> To: Sharon Boeyen
> Cc: [e-mail]
> Subject: RE: Reverse paths
> 
> 
> Sharon,
> 
> >Steve,
> >I don't think I've been able to clearly describe what I meant. I am
> >NOT proposing ANY additional certificate issuance by anybody. I think
> >the terms reverse and forward are very unfortunate and always confuse
> >these discussions. Can we chat offline just to make sure that you
> >understand what it is I am proposing. Email makes this type of
> >discussion difficult at best.
> >
> >Within a hierarchy I don't believe any change is required. 
> If the root
> >of a hierarchy issued a certificate to some CA that is NOT a 
> subordinate
> >of the root, then currently PKIX does not require the root 
> CA to place
> >that certificate in the root CA's entry. What I am proposing is that
> >such a certificate, IF ISSUED, be placed in the issuer's 
> entry as well
> >as in the subject CA's entry.
> 
> Ok, I think this clarification makes me more comfortable.
> 
> Steve
> 
> P.S.  All the negative comments about bridge CAs in my previous 
> message still apply.
> 


Received: from sothmxs01.entrust.com (gatekeeper.entrust.com [204.101.128.170]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id IAA03891 for <[e-mail]>; Fri, 21 Jul 2000 08:26:28 -0700 (PDT)
Received: by sothmxs01.entrust.com with Internet Mail Service (5.5.2650.21) id <PHL2HGXW>; Fri, 21 Jul 2000 11:28:37 -0400
Message-ID: <[e-mail]>
From: Sharon Boeyen <[e-mail]>
To: "'Stephen Kent'" <[e-mail]>
Cc: [e-mail]
Subject: RE: Reverse paths
Date: Fri, 21 Jul 2000 11:26:55 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain; charset="iso-8859-1"

OK, I think we've cleared up the confusion. 

So what I'd propose is the addition of a sentence along these lines:

If a CA issues a certificate to a CA that is not a subordinate to the
issuing 
CA, the issuing CA must place the certificate in its own directory entry in 
the crossCertificatePair attribute as a value of the reverse element.

Is that ok?

Sharon

					
> -----Original Message-----
> From: Stephen Kent [mailto:[e-mail]]
> Sent: Friday, July 21, 2000 9:41 AM
> To: Sharon Boeyen
> Cc: [e-mail]
> Subject: RE: Reverse paths
> 
> 
> Sharon,
> 
> >Steve,
> >I don't think I've been able to clearly describe what I meant. I am
> >NOT proposing ANY additional certificate issuance by anybody. I think
> >the terms reverse and forward are very unfortunate and always confuse
> >these discussions. Can we chat offline just to make sure that you
> >understand what it is I am proposing. Email makes this type of
> >discussion difficult at best.
> >
> >Within a hierarchy I don't believe any change is required. 
> If the root
> >of a hierarchy issued a certificate to some CA that is NOT a 
> subordinate
> >of the root, then currently PKIX does not require the root 
> CA to place
> >that certificate in the root CA's entry. What I am proposing is that
> >such a certificate, IF ISSUED, be placed in the issuer's 
> entry as well
> >as in the subject CA's entry.
> 
> Ok, I think this clarification makes me more comfortable.
> 
> Steve
> 
> P.S.  All the negative comments about bridge CAs in my previous 
> message still apply.
> 


Received: from prv-mail20.provo.novell.com (prv-mail20.provo.novell.com [137.65.81.122]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id IAA02135 for <[e-mail]>; Fri, 21 Jul 2000 08:20:15 -0700 (PDT)
Received: from INET-PRV-Message_Server by prv-mail20.provo.novell.com with Novell_GroupWise; Fri, 21 Jul 2000 09:22:05 -0600
Message-Id: <[e-mail]>
X-Mailer: Novell GroupWise Internet Agent 5.5.3.1
Date: Fri, 21 Jul 2000 09:22:01 -0600
From: "Bob Jueneman" <[e-mail]>
To: <[e-mail]>, <[e-mail]>
Cc: <[e-mail]>
Subject: Re: A Real Rationale for Dedicated Keys
Mime-Version: 1.0
Content-Type: multipart/alternative; boundary="=_CE96828D.BBDAB31A"

This is a MIME message. If you are reading this text, you may want to 
consider changing to a mail reader or gateway that understands how to 
properly handle MIME multipart messages.

--=_CE96828D.BBDAB31A
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: quoted-printable

Tony,

I agree that creating multiple certificates containing the same key is a =
dumb idea, because it makes it very difficult to know which set of =
assertions (contained in the certificate) were supposed to apply to a =
given transaction.

But since the individual CA cannot possible detect or prevent someone from =
going to two different CAs with the same public key, and making two =
different sets of assertions, complete with full-blown POP, the only =
reasonable solution to to place the burden firmly on the subscriber/user.

If he creates two certificates for the same key, one with NR and one =
without (or any other assertion), then unless the certificate is bound to =
the transaction by more than just the signature, the relying party should =
be permitted to make his case using which ever certificate is most =
favorable to his case.

Bob


>>> Tony Bartoletti <[e-mail]> 07/20/00 05:20PM >>>
At 05:48 PM 7/20/00 -0400, Stephen Kent wrote:
>Tony,
>
>You cited the ability of a user (or someone else) to bind a public key=20
>into multiple certs, some with and some without the NR bit enabled as =
a=20
>reason that the NR bit is not useful for the purpose I stated.  I think =
I=20
>pointed out in my response to John Wary why this line of reasoning is =
not=20
>necessarily true. It would be a mistake for a user to have the same =
public=20
>key in multiple certs, and anyone other than the user should not be =
able=20
>to effect POP and get a CA to issue a cert.  Yes, a user could act in =
this=20
>inappropriate fashion, in some instances, but then too a user could=20
>undermine most of the safeguards that we envision through negligent =
conduct.

Steve,

I agree with the main points, and I worked from the assumption that
CAs will not certify without POP (certainly not NR without POP!).

Thus, if a user (wisely, naively, or unscrupulously) has an NR-key
"differently certified", it is largely under the user's control,
since they are the only ones that can satisfy POP.

So, my tack becomes "How best to work from this assumption?"

Bad as such a practice may be, I asked myself how close one could come
to making such a situation "workable", and the answer (to me) was a
protocol that forces a conscious selection of certificate be bound
into the transaction.  (I suppose they will always have the "Ooops,
I thought I selected the NR=3D0 cert that time, honest mistake...) but
the signed content would at least implicate a usage (and for NR and
the RP, more importantly, the strength of a DN-Person binding that
is commensurate with such a usage.)

To a Relying Party, the value of the NR bit on ANY certificate for a
given key (even where the same key may have been lightly certified
elsewhere) is that someone (who but the CA?) has gone to greater
lengths to ensure the "reasonableness" of the DN as a reliable
indicator of an identifiable party.  (Of what value an NR-cert
binding a key to the DN-equivalent of "someone@mailbox"?)

To my understanding, a re-certification of such a "strong" key
does not in itself weaken the established DN-Entity binding.

(It DOES allow a "lightweight CA" to leverage the hard work
of the diligent NR-certifying CA ... Is that an issue?)

It (NR-bit) may also be a declaration from the CA that the key
was generated in a secure device.  But all of this lends a degree
of value to ANY use of the key, EXCEPT for a use requiring some
measure of anonymity.  Fortunately, the user is self-motivated
to employ a distinct key for such purposes.

As far as this being a reason that the "NR-bit is not useful"
for the purpose you stated, I am not quite sure.  From your
response to John Wray, I can only suppose that this use centers
on the reduction of "added mechanisms" to support Non-Repudiation.

But I feel that "additional mechanisms" are required for such
a weighty use as legally binding signatures.

I really want to avoid people buying into the semantic that
"Valid Signature" plus "I found a certificate that says NR"
somehow equates to "signature was made with NR intent."
(Even binding a selected NR-cert into the signature is
insufficient, but moves us a step closer.)

There are really two motivations I consider:

1.  What can be done to help prevent a "criminal" user from
     perpetrating a fraud.

2.  What can the legitimate user do to protect herself from
     misapplication by others.

If we agree that we cannot (easily) prevent a user from having
a key "multiply-certified", the goal must shift to how we might
best prevent the unscrupulous user from profiting by the practice.

My point about the privacy/anonymity issue is that the user has
legitimate control over this by applying different keys.

___tony___


Tony Bartoletti 925-422-3881 <[e-mail]>
Information Operations, Warfare and Assurance Center
Lawrence Livermore National Laboratory
Livermore, CA 94551-9900

--=_CE96828D.BBDAB31A
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META content=3D"text/html; charset=3Diso-8859-1" http-equiv=3DContent-Type=
>
<META content=3D"MSHTML 5.00.2614.3401" name=3DGENERATOR></HEAD>
<BODY style=3D"FONT: 8pt MS Sans Serif; MARGIN-LEFT: 2px; MARGIN-TOP: =
2px">
<DIV><FONT size=3D1>Tony,</FONT></DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT size=3D1>I agree that creating multiple certificates containing =
the=20
same key is a dumb idea, because it makes it very difficult to know which =
set of=20
assertions (contained in the certificate) were supposed to apply to a =
given=20
transaction.</FONT></DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT size=3D1>But since the individual CA cannot possible detect or =
prevent=20
someone from going to two different CAs with the same public key, and =
making two=20
different sets of assertions, complete with full-blown POP, the only =
reasonable=20
solution to to place the burden firmly on the subscriber/user.</FONT></DIV>=

<DIV>&nbsp;</DIV>
<DIV><FONT size=3D1>If he creates two certificates for the same key, one =
with NR=20
and one without (or any other assertion), then unless the certificate is =
bound=20
to the transaction by more than just the signature, the relying party =
should be=20
permitted to make his case using which ever certificate is most favorable =
to his=20
case.</FONT></DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT size=3D1>Bob</FONT></DIV>
<DIV>&nbsp;</DIV>
<DIV><BR>&gt;&gt;&gt; Tony Bartoletti &lt;[e-mail]&gt; 07/20/00 =
05:20PM=20
&gt;&gt;&gt;<BR>At 05:48 PM 7/20/00 -0400, Stephen Kent=20
wrote:<BR>&gt;Tony,<BR>&gt;<BR>&gt;You cited the ability of a user (or =
someone=20
else) to bind a public key <BR>&gt;into multiple certs, some with and =
some=20
without the NR bit enabled as a <BR>&gt;reason that the NR bit is not =
useful for=20
the purpose I stated.&nbsp; I think I <BR>&gt;pointed out in my response =
to John=20
Wary why this line of reasoning is not <BR>&gt;necessarily true. It would =
be a=20
mistake for a user to have the same public <BR>&gt;key in multiple certs, =
and=20
anyone other than the user should not be able <BR>&gt;to effect POP and =
get a CA=20
to issue a cert.&nbsp; Yes, a user could act in this <BR>&gt;inappropriate=
=20
fashion, in some instances, but then too a user could <BR>&gt;undermine =
most of=20
the safeguards that we envision through negligent=20
conduct.<BR><BR>Steve,<BR><BR>I agree with the main points, and I worked =
from=20
the assumption that<BR>CAs will not certify without POP (certainly not =
NR=20
without POP!).<BR><BR>Thus, if a user (wisely, naively, or unscrupulously) =
has=20
an NR-key<BR>"differently certified", it is largely under the user's=20
control,<BR>since they are the only ones that can satisfy POP.<BR><BR>So, =
my=20
tack becomes "How best to work from this assumption?"<BR><BR>Bad as such =
a=20
practice may be, I asked myself how close one could come<BR>to making such =
a=20
situation "workable", and the answer (to me) was a<BR>protocol that forces =
a=20
conscious selection of certificate be bound<BR>into the transaction.&nbsp; =
(I=20
suppose they will always have the "Ooops,<BR>I thought I selected the =
NR=3D0 cert=20
that time, honest mistake...) but<BR>the signed content would at least =
implicate=20
a usage (and for NR and<BR>the RP, more importantly, the strength of a =
DN-Person=20
binding that<BR>is commensurate with such a usage.)<BR><BR>To a Relying =
Party,=20
the value of the NR bit on ANY certificate for a<BR>given key (even where =
the=20
same key may have been lightly certified<BR>elsewhere) is that someone =
(who but=20
the CA?) has gone to greater<BR>lengths to ensure the "reasonableness" of =
the DN=20
as a reliable<BR>indicator of an identifiable party.&nbsp; (Of what value =
an=20
NR-cert<BR>binding a key to the DN-equivalent of "someone@mailbox"?)<BR><BR=
>To=20
my understanding, a re-certification of such a "strong" key<BR>does not =
in=20
itself weaken the established DN-Entity binding.<BR><BR>(It DOES allow =
a=20
"lightweight CA" to leverage the hard work<BR>of the diligent NR-certifying=
 CA=20
... Is that an issue?)<BR><BR>It (NR-bit) may also be a declaration from =
the CA=20
that the key<BR>was generated in a secure device.&nbsp; But all of this =
lends a=20
degree<BR>of value to ANY use of the key, EXCEPT for a use requiring=20
some<BR>measure of anonymity.&nbsp; Fortunately, the user is=20
self-motivated<BR>to employ a distinct key for such purposes.<BR><BR>As =
far as=20
this being a reason that the "NR-bit is not useful"<BR>for the purpose =
you=20
stated, I am not quite sure.&nbsp; From your<BR>response to John Wray, I =
can=20
only suppose that this use centers<BR>on the reduction of "added mechanisms=
" to=20
support Non-Repudiation.<BR><BR>But I feel that "additional mechanisms" =
are=20
required for such<BR>a weighty use as legally binding signatures.<BR><BR>I=
=20
really want to avoid people buying into the semantic that<BR>"Valid =
Signature"=20
plus "I found a certificate that says NR"<BR>somehow equates to "signature =
was=20
made with NR intent."<BR>(Even binding a selected NR-cert into the =
signature=20
is<BR>insufficient, but moves us a step closer.)<BR><BR>There are really =
two=20
motivations I consider:<BR><BR>1.&nbsp; What can be done to help prevent =
a=20
"criminal" user from<BR>&nbsp;&nbsp;&nbsp;&nbsp; perpetrating a=20
fraud.<BR><BR>2.&nbsp; What can the legitimate user do to protect =
herself=20
from<BR>&nbsp;&nbsp;&nbsp;&nbsp; misapplication by others.<BR><BR>If we =
agree=20
that we cannot (easily) prevent a user from having<BR>a key=20
"multiply-certified", the goal must shift to how we might<BR>best prevent =
the=20
unscrupulous user from profiting by the practice.<BR><BR>My point about =
the=20
privacy/anonymity issue is that the user has<BR>legitimate control over =
this by=20
applying different keys.<BR><BR>___tony___<BR><BR><BR>Tony Bartoletti=20
925-422-3881 &lt;[e-mail]&gt;<BR>Information Operations, Warfare =
and=20
Assurance Center<BR>Lawrence Livermore National Laboratory<BR>Livermore, =
CA=20
94551-9900<BR><BR></DIV></BODY></HTML>

--=_CE96828D.BBDAB31A--


Received: from ntserver2.chrysalis-its.com ([209.47.245.163]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id IAA01906 for <[e-mail]>; Fri, 21 Jul 2000 08:17:15 -0700 (PDT)
From: [e-mail]
Received: by NTSERVER2 with Internet Mail Service (5.5.2650.21) id <PGABZ976>; Fri, 21 Jul 2000 11:20:43 -0400
Message-ID: <[e-mail]>
To: [e-mail]
Cc: [e-mail]
Subject: Indicating How Private Keys are Generated/Stored (was RE: A Real  Rationale for Dedicated Keys)
Date: Fri, 21 Jul 2000 11:20:30 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01BFF327.3BC79D38"

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01BFF327.3BC79D38
Content-Type: text/plain;
	charset="iso-8859-1"

Hi Simon,

I totally agree with you that if a key generation device had its own private
key that is trusted by a CA and this key was used to sign a certificate
request for a newly generated end user's key pair, this would certainly
provide more confidence for this CA to certify the end user's public key for
NR.

Currently neither the CMP protocol [RFC2510] nor the CMC protocol [RFC2797]
include a standard way for a key generation device to explicitly indicate in
a certificate request the quality of remotely generated key pair and also
how the private key will be stored and protected in the future. However,
both CMP and CMC use CRMF [RFC2511] and Section 3 on the certificate request
message indicates that the optional registration information field can
contain supplementary information related to the context of the
certification request when such information is required to fulfil a
certification request.

Wouldn't it make sense to define additional type(s) for the registration
information in CRMF for this particular purpose of indicating the quality of
remotely generated key pair and also how the private key will be stored and
protected in the future? Certificate request messages containing this new
registration information and the end user's public key would then be signed
with the private key of the key generation device, which would acting as an
RA in this case, and be forwarded to another RA or directly to the CA to be
certified. What do others think about this suggestion?

Regards,

Francois
___________________________________
Francois Rousseau
Director of Standards and Conformance
Chrysalis-ITS
1688 Woodward Drive
Ottawa, Ontario, CANADA, K2C 3R7
[e-mail]      Tel. [phone] ext. 419
http://www.chrysalis-its.com     Fax. [phone]


-----Original Message-----
From: Simon McMahon [mailto:[e-mail]]
Sent: Friday, July 21, 2000 12:15 AM
To: Aram Perez; [e-mail]
Subject: Re: A Real Rationale for Dedicated Keys


>
> Without the owner physically showing up, how can a CA know whether or not
a
> key pair was "generated and the private part is stored to some minimum
> standard"?
>
The key generation device has its own private key and signs the cert request
for the newly generated user key pair. The CA then knows that the key pair
originated in a device it (the CA) trusts and probably provides as part of
its service. The CA certifies the public key of the device so it can verify
the device's cert requests.

Such a device is obviously not cheap but without such a device the CA cannot
control the quality of remotely generated keys or how the private key is
stored and protected from duplication (necessary for NR).

Much more likely is that the owner *will* show up to the CA or one of its
RAs to get a NR certificate. Anything less will probably fail to meet the
legal requirements for NR and be worth no more than a NR=0 cert.

Simon McMahon
ERACOM Pty. Ltd.


------_=_NextPart_001_01BFF327.3BC79D38
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Diso-8859-1">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
5.5.2650.12">
<TITLE>Indicating How Private Keys are Generated/Stored (was RE: A Real =
Rationale for Dedicated Keys)</TITLE>
</HEAD>
<BODY>

<P><FONT SIZE=3D2>Hi Simon,</FONT>
</P>

<P><FONT SIZE=3D2>I totally agree with you that if a key generation =
device had its own private key that is trusted by a CA and this key was =
used to sign a certificate request for a newly generated end user's key =
pair, this would certainly provide more confidence for this CA to =
certify the end user's public key for NR.</FONT></P>

<P><FONT SIZE=3D2>Currently neither the CMP protocol [RFC2510] nor the =
CMC protocol [RFC2797] include a standard way for a key generation =
device to explicitly indicate in a certificate request the quality of =
remotely generated key pair and also how the private key will be stored =
and protected in the future. However, both CMP and CMC use CRMF =
[RFC2511] and Section 3 on the certificate request message indicates =
that the optional registration information field can contain =
supplementary information related to the context of the certification =
request when such information is required to fulfil a certification =
request.</FONT></P>

<P><FONT SIZE=3D2>Wouldn't it make sense to define additional type(s) =
for the registration information in CRMF for this particular purpose of =
indicating the quality of remotely generated key pair and also how the =
private key will be stored and protected in the future? Certificate =
request messages containing this new registration information and the =
end user's public key would then be signed with the private key of the =
key generation device, which would acting as an RA in this case, and be =
forwarded to another RA or directly to the CA to be certified. What do =
others think about this suggestion?</FONT></P>

<P><FONT SIZE=3D2>Regards,</FONT>
</P>

<P><FONT SIZE=3D2>Francois</FONT>
<BR><FONT SIZE=3D2>___________________________________</FONT>
<BR><FONT SIZE=3D2>Francois Rousseau</FONT>
<BR><FONT SIZE=3D2>Director of Standards and Conformance</FONT>
<BR><FONT SIZE=3D2>Chrysalis-ITS</FONT>
<BR><FONT SIZE=3D2>1688 Woodward Drive</FONT>
<BR><FONT SIZE=3D2>Ottawa, Ontario, CANADA, K2C 3R7</FONT>
<BR><FONT =
SIZE=3D2>[e-mail]&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Tel. =
[phone] ext. 419</FONT>
<BR><FONT SIZE=3D2><A HREF=3D"http://www.chrysalis-its.com" =
TARGET=3D"_blank">http://www.chrysalis-its.com</A>&nbsp;&nbsp;&nbsp;&nbs=
p; Fax. [phone]</FONT>
</P>
<BR>

<P><FONT SIZE=3D2>-----Original Message-----</FONT>
<BR><FONT SIZE=3D2>From: Simon McMahon [<A =
HREF=3D"mailto:[e-mail]">mailto:[e-mail]</A>]<=
/FONT>
<BR><FONT SIZE=3D2>Sent: Friday, July 21, 2000 12:15 AM</FONT>
<BR><FONT SIZE=3D2>To: Aram Perez; [e-mail]</FONT>
<BR><FONT SIZE=3D2>Subject: Re: A Real Rationale for Dedicated =
Keys</FONT>
</P>
<BR>

<P><FONT SIZE=3D2>&gt;</FONT>
<BR><FONT SIZE=3D2>&gt; Without the owner physically showing up, how =
can a CA know whether or not</FONT>
<BR><FONT SIZE=3D2>a</FONT>
<BR><FONT SIZE=3D2>&gt; key pair was &quot;generated and the private =
part is stored to some minimum</FONT>
<BR><FONT SIZE=3D2>&gt; standard&quot;?</FONT>
<BR><FONT SIZE=3D2>&gt;</FONT>
<BR><FONT SIZE=3D2>The key generation device has its own private key =
and signs the cert request</FONT>
<BR><FONT SIZE=3D2>for the newly generated user key pair. The CA then =
knows that the key pair</FONT>
<BR><FONT SIZE=3D2>originated in a device it (the CA) trusts and =
probably provides as part of</FONT>
<BR><FONT SIZE=3D2>its service. The CA certifies the public key of the =
device so it can verify</FONT>
<BR><FONT SIZE=3D2>the device's cert requests.</FONT>
</P>

<P><FONT SIZE=3D2>Such a device is obviously not cheap but without such =
a device the CA cannot</FONT>
<BR><FONT SIZE=3D2>control the quality of remotely generated keys or =
how the private key is</FONT>
<BR><FONT SIZE=3D2>stored and protected from duplication (necessary for =
NR).</FONT>
</P>

<P><FONT SIZE=3D2>Much more likely is that the owner *will* show up to =
the CA or one of its</FONT>
<BR><FONT SIZE=3D2>RAs to get a NR certificate. Anything less will =
probably fail to meet the</FONT>
<BR><FONT SIZE=3D2>legal requirements for NR and be worth no more than =
a NR=3D0 cert.</FONT>
</P>

<P><FONT SIZE=3D2>Simon McMahon</FONT>
<BR><FONT SIZE=3D2>ERACOM Pty. Ltd.</FONT>
</P>

</BODY>
</HTML>
------_=_NextPart_001_01BFF327.3BC79D38--


Received: from prv-mail20.provo.novell.com (prv-mail20.provo.novell.com [137.65.81.122]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id IAA01631 for <[e-mail]>; Fri, 21 Jul 2000 08:10:36 -0700 (PDT)
Received: from INET-PRV-Message_Server by prv-mail20.provo.novell.com with Novell_GroupWise; Fri, 21 Jul 2000 09:12:40 -0600
Message-Id: <[e-mail]>
X-Mailer: Novell GroupWise Internet Agent 5.5.3.1
Date: Fri, 21 Jul 2000 09:12:34 -0600
From: "Bob Jueneman" <[e-mail]>
To: <[e-mail]>, <[e-mail]>
Subject: Re: A Real Rationale for Dedicated Keys
Mime-Version: 1.0
Content-Type: multipart/alternative; boundary="=_39617578.A4C5AC03"

This is a MIME message. If you are reading this text, you may want to 
consider changing to a mail reader or gateway that understands how to 
properly handle MIME multipart messages.

--=_39617578.A4C5AC03
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: quoted-printable

Hi, Aram,

Let me first observe that we seem to be greatly overloading a poor single =
NR bit.

Suggestions have been made that certain standards of key control must =
apply, that various time stamping and/or other certificate validation =
standards must apply, maybe some kind of biometrics must be used to =
protect against the possibility that they user accidentally or deliberately=
 gave away his key or smart card, that somehow we have to have proof that =
what the user through he was signing was in fact what was signed, that the =
mechanism should somehow protect against multiple signature operations =
taking place during a single card insertion, and that somehow we should =
ensure that they user really intended to sign that particular transaction =
as his volitional act.  Whew!

But with respect to how the CA can or should know that the keys were =
properly generated, stored, and used, let me just say that I believe that =
is putting too much responsibility on the CA.

The contents of a certificate should be primarily viewed as a set of =
representations made by the subscriber to the CA, with the CA acting as a =
trusted witness.  If certificates are to be reasonably affordable, we =
cannot require that the CA employ a vast network of Pinkerton agents to go =
out and independently investigate the truth of every assertion made.  It =
should be sufficient that the CA verify the identity of the subscriber and =
the possession of the private key corresponding to the public key -- =
everything else should be viewed as a representation by the subscriber =
(not that the CA should turn a blind eye to an obvious error or falsehood.)=


Particularly in the case of a digital signature certificate (less so in =
the case of encryption, but NR presumably doesn't apply there), if the =
subscriber claims a certain degree of key protection, and essentially says =
to the relying party, ":You can trust this transaction, because I have =
taken scrupulous care to ensure than no one can access my keys without my =
permission," then the subscriber would clearly have a very difficult time =
trying to repudiate the transaction based on a key compromise -- he would =
be hung with his own rope.

Bob

>>> Aram Perez <[e-mail]> 07/20/00 08:10PM >>>
Hi Tony B.,

> At 10:04 AM 7/21/00 +1000, Simon McMahon wrote:
>>>=20
>>> Could you tell me what has NR (Non-Repudation) to do with CA control =
key
>>> generation.
>>>=20
>> By "CA controlled key generation" I mean that the CA specifies minimum
>> standards and one option of the CA may be to do the key gen itself. The =
CA
>> should verify that the minimum standards are being followed if it =
specifies
>> any.
>=20
> Agreed!
>=20
>> Non-repudiation requires (at least) that the private key does not get
>> exposed or used by someone else without the owner knowing it. That =
means
>> that how the private key is used and how it is stored when not in use =
is
>> very relevant to NR. CAs can (and should) insist that key pairs are
>> generated and the private part is stored to some minimum standard =
before
>> they certify the public part.
>=20
> Agreed!

Without the owner physically showing up, how can a CA know whether or not =
a
key pair was "generated and the private part is stored to some minimum
standard"?

Regards,
Aram Perez

[snip]

--=_39617578.A4C5AC03
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META content=3D"text/html; charset=3Diso-8859-1" http-equiv=3DContent-Type=
>
<META content=3D"MSHTML 5.00.2614.3401" name=3DGENERATOR></HEAD>
<BODY style=3D"FONT: 8pt MS Sans Serif; MARGIN-LEFT: 2px; MARGIN-TOP: =
2px">
<DIV><FONT size=3D1>Hi, Aram,</FONT></DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT size=3D1>Let me first observe that we seem to be greatly =
overloading a=20
poor single NR bit.</FONT></DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT size=3D1>Suggestions have been made that certain standards of =
key=20
control must apply, that </FONT><FONT size=3D1>various time stamping =
and/or other=20
certificate validation standards must apply, </FONT><FONT size=3D1>maybe =
some kind=20
of biometrics must be used to protect against the possibility that they =
user=20
accidentally or deliberately gave away his key or smart card, that somehow =
we=20
have to have proof that what the user through he was signing was in fact =
what=20
was signed, that the mechanism should somehow protect against multiple =
signature=20
operations taking place during a single card insertion, and that somehow =
we=20
should ensure that they user really intended to sign that particular =
transaction=20
as his volitional act.&nbsp; Whew!</FONT></DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT size=3D1>But with respect to how the CA can or should know that =
the=20
keys were properly generated, stored, and used, let me just say that I =
believe=20
that is putting too much responsibility on the CA.</FONT></DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT size=3D1>The contents of a certificate should be primarily =
viewed as a=20
set of representations made by the subscriber to the CA, with the CA =
acting as a=20
trusted witness.&nbsp; If certificates are to be reasonably affordable, =
we=20
cannot require that the CA employ a vast network of Pinkerton agents to go =
out=20
and independently investigate the truth of every assertion made.&nbsp; It =
should=20
be sufficient that the CA verify the identity of the subscriber and the=20
possession of the private key corresponding to the public key -- everything=
 else=20
should be viewed as a representation by the subscriber (not that the CA =
should=20
turn a blind eye to an obvious error or falsehood.)</FONT></DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT size=3D1>Particularly in the case of a digital signature =
certificate=20
(less so in the case of encryption, but NR presumably doesn't apply =
there), if=20
the subscriber claims a certain degree of key protection, and essentially =
says=20
to the relying party, ":You can trust this transaction, because I have =
taken=20
scrupulous care to ensure than no one can access my keys without my =
permission,"=20
then the subscriber would clearly have a very difficult time trying to =
repudiate=20
the transaction based on a key compromise -- he would be hung with his =
own=20
rope.</FONT></DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT size=3D1>Bob</FONT><BR><BR>&gt;&gt;&gt; Aram Perez=20
&lt;[e-mail]&gt; 07/20/00 08:10PM &gt;&gt;&gt;<BR>Hi Tony=20
B.,<BR><BR>&gt; At 10:04 AM 7/21/00 +1000, Simon McMahon wrote:<BR>&gt;&gt;=
&gt;=20
<BR>&gt;&gt;&gt; Could you tell me what has NR (Non-Repudation) to do with =
CA=20
control key<BR>&gt;&gt;&gt; generation.<BR>&gt;&gt;&gt; <BR>&gt;&gt; By =
"CA=20
controlled key generation" I mean that the CA specifies minimum<BR>&gt;&gt;=
=20
standards and one option of the CA may be to do the key gen itself. The=20
CA<BR>&gt;&gt; should verify that the minimum standards are being followed =
if it=20
specifies<BR>&gt;&gt; any.<BR>&gt; <BR>&gt; Agreed!<BR>&gt; <BR>&gt;&gt;=20=

Non-repudiation requires (at least) that the private key does not=20
get<BR>&gt;&gt; exposed or used by someone else without the owner knowing =
it.=20
That means<BR>&gt;&gt; that how the private key is used and how it is =
stored=20
when not in use is<BR>&gt;&gt; very relevant to NR. CAs can (and should) =
insist=20
that key pairs are<BR>&gt;&gt; generated and the private part is stored to =
some=20
minimum standard before<BR>&gt;&gt; they certify the public part.<BR>&gt;=
=20
<BR>&gt; Agreed!<BR><BR>Without the owner physically showing up, how can a =
CA=20
know whether or not a<BR>key pair was "generated and the private part is =
stored=20
to some minimum<BR>standard"?<BR><BR>Regards,<BR>Aram=20
Perez<BR><BR>[snip]<BR><BR></DIV></BODY></HTML>

--=_39617578.A4C5AC03--


Received: from prv-mail20.provo.novell.com (prv-mail20.provo.novell.com [137.65.81.122]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id HAA01094 for <[e-mail]>; Fri, 21 Jul 2000 07:51:48 -0700 (PDT)
Received: from INET-PRV-Message_Server by prv-mail20.provo.novell.com with Novell_GroupWise; Fri, 21 Jul 2000 08:53:56 -0600
Message-Id: <[e-mail]>
X-Mailer: Novell GroupWise Internet Agent 5.5.3.1
Date: Fri, 21 Jul 2000 08:53:53 -0600
From: "Bob Jueneman" <[e-mail]>
To: <[e-mail]>, <[e-mail]>
Cc: <[e-mail]>
Subject: RE: Signing what you don't understand
Mime-Version: 1.0
Content-Type: multipart/alternative; boundary="=_59011514.86E78E2D"

This is a MIME message. If you are reading this text, you may want to 
consider changing to a mail reader or gateway that understands how to 
properly handle MIME multipart messages.

--=_59011514.86E78E2D
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: quoted-printable

I can't tell from the brief description, but it appears that they are =
using a simple password to log on sequentially to multiple sites, and then =
assembling the collected secret shares at that point.

Granted that this makes it impossible for a rogue administrator at one =
institution to access a user's keys, but what is to prevent an attacker =
from collecting the shares himself, using a multiplicity of simple =
passwords?

Even if the user is scrupulous about using a different password for each =
server (making it very difficult to remember them all), the effort to =
break the system would seem to be merely additive, rather than exponential.=
  Guessing the or four simple passwords is still simple.

I must be missing something.  Does anyone have the patent application, or =
further details?

Bob

>>> "Ramsay, Ron" <[e-mail]> 07/20/00 10:48PM >>>

Very interesting. It would have been interesting to have heard from =
Warwick
on the issue of non-repudiation. Verisign would seem to have placed a =
stake
in the ground.

Ron.
-----Original Message-----
From: Peter Williams [mailto:[e-mail]]
Sent: Friday, 21 July 2000 12:52
To: 'Richard Levitte'; Anders Rundgren
Cc: Peter Lipp; [e-mail]; [e-mail]
Subject: RE: Signing what you don't understand




http://www.verisign.com/press/2000/roaming.html



"VeriSign's revolutionary technology allows an end-user to securely=20
store digital certificates and/or any other type of data, such as=20
financial information or an online patient record, on distributed=20
network servers operated by multiple trusted service providers. This=20
technology enables portability of digital certificates, providing=20
convenience for users to access and download their certificates and=20
private keys for online authentication. It also enables the generation=20
of binding digital signatures for conducting high-value e-commerce=20
transactions, regardless of whether users are accessing the Internet=20
from work, home, or another location such as an Internet kiosk. Digital=20
certificates are electronic credentials that identify parties online,=20
enabling encrypted communications and legally binding, valid digital=20
signatures.=20
"

-----Original Message-----
From: Richard Levitte [mailto:[e-mail]]
Sent: Thursday, July 20, 2000 11:24 AM
To: Anders Rundgren
Cc: Peter Lipp; [e-mail]; [e-mail]
Subject: Re: Signing what you don't understand


Anders Rundgren wrote:

> Peter,
>
> >> Several leading PKI vendors have implemented systems where the =
private
key
> >> is held on a central Web server and then downloaded at run time to a
web
> >> browser.  Are you saying that signatures created using these keys are
> >> invalid?
> >Are you sure? Could you provide a reference? I doubt that strongly...
> >
> >Peter
>
> I think this is one...
>
> http://www.arcot.com/products/webfort.html

I think not, at least from reading the papers "Protecting Digital
Identities" and
"Protecting Your Private Key".  All they say is that they've invented some
kind
of key database ("key wallet" to use their term) that is more secure than
what
comes with for example MSIE and Netscape Communicator...

Personally, if I was confronted with a CA that wanted to create my private
key
for me, and store it centrally to boot, I'd go somewhere else.  Very fast.
It
contradicts anything even remotely close to being called "secure".

--
Richard Levitte   !!! New cell phone number !!!
[e-mail]

/* You might enjoy viewing the complete vCard */

--=_59011514.86E78E2D
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META content=3D"text/html; charset=3Diso-8859-1" http-equiv=3DContent-Type=
>
<META content=3D"MSHTML 5.00.2614.3401" name=3DGENERATOR></HEAD>
<BODY style=3D"FONT: 8pt MS Sans Serif; MARGIN-LEFT: 2px; MARGIN-TOP: =
2px">
<DIV><FONT size=3D1>I can't tell from the brief description, but it =
appears that=20
they are using a simple password to log on sequentially to multiple sites, =
and=20
then assembling the collected secret shares at that point.</FONT></DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT size=3D1>Granted that this makes it impossible for a rogue=20
administrator at one institution to access a user's keys, but what is to =
prevent=20
an attacker from collecting the shares himself, using a multiplicity of =
simple=20
passwords?</FONT></DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT size=3D1>Even if the user is scrupulous about using a =
different=20
password for each server (making it very difficult to remember them all), =
the=20
effort to break the system would seem to be merely additive, rather =
than=20
exponential.&nbsp; Guessing the or four simple passwords is still=20
simple.</FONT></DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT size=3D1>I must be missing something.&nbsp; Does anyone have =
the patent=20
application, or further details?</FONT></DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT size=3D1>Bob</FONT><BR><BR>&gt;&gt;&gt; "Ramsay, Ron"=20
&lt;[e-mail]&gt; 07/20/00 10:48PM &gt;&gt;&gt;<BR><BR>Very =
interesting.=20
It would have been interesting to have heard from Warwick<BR>on the issue =
of=20
non-repudiation. Verisign would seem to have placed a stake<BR>in the=20
ground.<BR><BR>Ron.<BR>-----Original Message-----<BR>From: Peter Williams =
[<A=20
href=3D"mailto:[e-mail]]">mailto:[e-mail]]</A><BR>Sen=
t:=20
Friday, 21 July 2000 12:52<BR>To: 'Richard Levitte'; Anders Rundgren<BR>Cc:=
=20
Peter Lipp; [e-mail]; [e-mail]<BR>Subject: RE: Signing what =
you=20
don't understand<BR><BR><BR><BR><BR><A=20
href=3D"http://www.verisign.com/press/2000/roaming.html">http://www.verisig=
n.com/press/2000/roaming.html</A><BR><BR><BR><BR>"VeriSign's=20
revolutionary technology allows an end-user to securely <BR>store =
digital=20
certificates and/or any other type of data, such as <BR>financial =
information or=20
an online patient record, on distributed <BR>network servers operated =
by=20
multiple trusted service providers. This <BR>technology enables portability=
 of=20
digital certificates, providing <BR>convenience for users to access and =
download=20
their certificates and <BR>private keys for online authentication. It =
also=20
enables the generation <BR>of binding digital signatures for conducting=20
high-value e-commerce <BR>transactions, regardless of whether users are=20
accessing the Internet <BR>from work, home, or another location such as =
an=20
Internet kiosk. Digital <BR>certificates are electronic credentials =
that=20
identify parties online, <BR>enabling encrypted communications and =
legally=20
binding, valid digital <BR>signatures. <BR>"<BR><BR>-----Original=20
Message-----<BR>From: Richard Levitte [<A=20
href=3D"mailto:[e-mail]]">mailto:richard.levitte@celocom.=
se]</A><BR>Sent:=20
Thursday, July 20, 2000 11:24 AM<BR>To: Anders Rundgren<BR>Cc: Peter =
Lipp;=20
[e-mail]; [e-mail]<BR>Subject: Re: Signing what you =
don't=20
understand<BR><BR><BR>Anders Rundgren wrote:<BR><BR>&gt; Peter,<BR>&gt;<BR>=
&gt;=20
&gt;&gt; Several leading PKI vendors have implemented systems where the=20
private<BR>key<BR>&gt; &gt;&gt; is held on a central Web server and =
then=20
downloaded at run time to a<BR>web<BR>&gt; &gt;&gt; browser.&nbsp; Are =
you=20
saying that signatures created using these keys are<BR>&gt; &gt;&gt;=20
invalid?<BR>&gt; &gt;Are you sure? Could you provide a reference? I doubt =
that=20
strongly...<BR>&gt; &gt;<BR>&gt; &gt;Peter<BR>&gt;<BR>&gt; I think this =
is=20
one...<BR>&gt;<BR>&gt; <A=20
href=3D"http://www.arcot.com/products/webfort.html">http://www.arcot.com/pr=
oducts/webfort.html</A><BR><BR>I=20
think not, at least from reading the papers "Protecting Digital<BR>Identiti=
es"=20
and<BR>"Protecting Your Private Key".&nbsp; All they say is that they've=20=

invented some<BR>kind<BR>of key database ("key wallet" to use their term) =
that=20
is more secure than<BR>what<BR>comes with for example MSIE and Netscape=20
Communicator...<BR><BR>Personally, if I was confronted with a CA that =
wanted to=20
create my private<BR>key<BR>for me, and store it centrally to boot, I'd =
go=20
somewhere else.&nbsp; Very fast.<BR>It<BR>contradicts anything even =
remotely=20
close to being called "secure".<BR><BR>--<BR>Richard Levitte&nbsp;&nbsp; =
!!! New=20
cell phone number !!!<BR>[e-mail]<BR><BR>/* You might =
enjoy=20
viewing the complete vCard */<BR></DIV></BODY></HTML>

--=_59011514.86E78E2D--


Received: from ns.celocom.se ([e-mail] [212.209.40.66]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id HAA29478 for <[e-mail]>; Fri, 21 Jul 2000 07:06:06 -0700 (PDT)
Received: by ns.celocom.se; id QAA05065; Fri, 21 Jul 2000 16:08:47 +0200 (CEST)
Received: from zap.celocom.se(10.10.10.1) by ns.celocom.se via smap (4.1) id xma029855; Fri, 21 Jul 00 14:49:56 +0200
Received: from celocom.com (dhcp121.celocom.se [10.10.11.21]) by zap.celocom.se (8.8.7/8.8.7) with ESMTP id OAA28234; Fri, 21 Jul 2000 14:49:55 +0200
Message-ID: <[e-mail]>
Date: Fri, 21 Jul 2000 14:49:55 +0200
From: Oscar Jacobsson <[e-mail]>
Organization: Celo Communications
X-Mailer: Mozilla 4.73 [en] (Windows NT 5.0; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Richard Levitte <[e-mail]>
CC: [e-mail]
Subject: Re: Signing what you don't understand
References: <001301bff26e$86043410$[e-mail]> <[e-mail]>
Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------msCDF0A6BC020D37BBF8FCF625"

This is a cryptographically signed message in MIME format.

--------------msCDF0A6BC020D37BBF8FCF625
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Richard Levitte wrote:
> Personally, if I was confronted with a CA that wanted to create my private key
> for me, and store it centrally to boot, I'd go somewhere else.  Very fast.  It
> contradicts anything even remotely close to being called "secure".

This gets a bit problematic when you're dealing with a party that is
literally authoritative, for instance the Swedish government, who will
assign you a unique identifier whether you agree with their practises or
not.

I myself have, as an example, tried to inform the Swedish tax
authorities that I'd prefer to take my business elsewhere on a number of
occasions, since they tend to be a bit pricey for my taste. No luck yet
though. :-(

//oscar
--------------msCDF0A6BC020D37BBF8FCF625
Content-Type: application/x-pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: S/MIME Cryptographic Signature

MIIH/gYJKoZIhvcNAQcCoIIH7zCCB+sCAQExCzAJBgUrDgMCGgUAMAsGCSqGSIb3DQEHAaCC
Bc8wggKzMIICHKADAgECAgMCjYUwDQYJKoZIhvcNAQEEBQAwgZQxCzAJBgNVBAYTAlpBMRUw
EwYDVQQIEwxXZXN0ZXJuIENhcGUxFDASBgNVBAcTC0R1cmJhbnZpbGxlMQ8wDQYDVQQKEwZU
aGF3dGUxHTAbBgNVBAsTFENlcnRpZmljYXRlIFNlcnZpY2VzMSgwJgYDVQQDEx9QZXJzb25h
bCBGcmVlbWFpbCBSU0EgMTk5OS45LjE2MB4XDTAwMDUxMzAwMDEzOVoXDTAxMDUxMzAwMDEz
OVowTTEfMB0GA1UEAxMWVGhhd3RlIEZyZWVtYWlsIE1lbWJlcjEqMCgGCSqGSIb3DQEJARYb
b3NjYXIuamFjb2Jzc29uQGNlbG9jb20uY29tMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKB
gQCZB2URw+NGaMMV/cSk9JoOb4OGMunL44lk/ioXoBR5brSVUcVaB+s+8UmcqOmi9RAAc+Uy
wY69hjPn/LWS3HzN4N4KW6jTEiDm0jPE1aVyxMg7un4rjRSGe9htdPL0ut8QoKXLCjafLKIo
v/pyudWgC1PxSglWECgKyKVVMl13KwIDAQABo1kwVzAmBgNVHREEHzAdgRtvc2Nhci5qYWNv
YnNzb25AY2Vsb2NvbS5jb20wDAYDVR0TAQH/BAIwADAfBgNVHSMEGDAWgBSIq/Fgg2ZV9ORY
x0YdwGG9I9fDjDANBgkqhkiG9w0BAQQFAAOBgQB8NkKsoEJaIAfecEv+NJp6bBs3xM+ynX5F
qJ/ave0p7v2eBBO/fovRoMsmFjF0jHf4RFJqxm9NrpoZWlhehM5nOdS0AyPwFIMEWl7PdSxO
pKkxGS8wgEsVammWQc8MAwULu4qy8SdL9LnszsvEKtrsJFG+bILsOf1qBkC6UuSR4DCCAxQw
ggJ9oAMCAQICAQswDQYJKoZIhvcNAQEEBQAwgdExCzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxX
ZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEaMBgGA1UEChMRVGhhd3RlIENvbnN1
bHRpbmcxKDAmBgNVBAsTH0NlcnRpZmljYXRpb24gU2VydmljZXMgRGl2aXNpb24xJDAiBgNV
BAMTG1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBDQTErMCkGCSqGSIb3DQEJARYccGVyc29u
YWwtZnJlZW1haWxAdGhhd3RlLmNvbTAeFw05OTA5MTYxNDAxNDBaFw0wMTA5MTUxNDAxNDBa
MIGUMQswCQYDVQQGEwJaQTEVMBMGA1UECBMMV2VzdGVybiBDYXBlMRQwEgYDVQQHEwtEdXJi
YW52aWxsZTEPMA0GA1UEChMGVGhhd3RlMR0wGwYDVQQLExRDZXJ0aWZpY2F0ZSBTZXJ2aWNl
czEoMCYGA1UEAxMfUGVyc29uYWwgRnJlZW1haWwgUlNBIDE5OTkuOS4xNjCBnzANBgkqhkiG
9w0BAQEFAAOBjQAwgYkCgYEAs2lal9TQFgt6tcVd6SGcI3LNEkxL937Px/vKciT0QlKsV5Xj
e2F6F4Tn/XI5OJS06u1lp5IGXr3gZfYZu5R5dkw+uWhwdYQc9BF0ALwFLE8JAxcxzPRB1HLG
pl3iiESwiy7ETfHw1oU+bPOVlHiRfkDpnNGNFVeOwnPlMN5G9U8CAwEAAaM3MDUwEgYDVR0T
AQH/BAgwBgEB/wIBADAfBgNVHSMEGDAWgBRyScJzNMZV9At2coF+d/SH58ayDjANBgkqhkiG
9w0BAQQFAAOBgQBrxlnpMfrptuyxA9jfcnL+kWBI6sZV3XvwZ47GYXDnbcKlN9idtxcoVgWL
3Vx1b8aRkMZsZnET0BB8a5FvhuAhNi3B1+qyCa3PLW3Gg1Kb+7v+nIed/LfpdJLkXJeu/H6s
yg1vcnpnLGtz9Yb5nfUAbvQdB86dnoJjKe+TCX5V3jGCAfcwggHzAgEBMIGcMIGUMQswCQYD
VQQGEwJaQTEVMBMGA1UECBMMV2VzdGVybiBDYXBlMRQwEgYDVQQHEwtEdXJiYW52aWxsZTEP
MA0GA1UEChMGVGhhd3RlMR0wGwYDVQQLExRDZXJ0aWZpY2F0ZSBTZXJ2aWNlczEoMCYGA1UE
AxMfUGVyc29uYWwgRnJlZW1haWwgUlNBIDE5OTkuOS4xNgIDAo2FMAkGBSsOAwIaBQCggbEw
GAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMDAwNzIxMTI0OTU2
WjAjBgkqhkiG9w0BCQQxFgQU9a6L1WUW3TbcEdvODdaguYoSdzkwUgYJKoZIhvcNAQkPMUUw
QzAKBggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwBwYFKw4DAgcwDQYIKoZIhvcNAwICAUAw
DQYIKoZIhvcNAwICASgwDQYJKoZIhvcNAQEBBQAEgYALmFweEi6NcAftqFh8Pn3p3V9/d8YC
QPt5uKj8hsio0Q7PTx7Cu9/su0D6gdZLrzsJv0H1SvX//bqSY4DOtqL/PhYlPH5rWniHqxPM
Q6HZEiJkhUB1SoUY7iqfuV1OpDsNjuGc7uMkZ/qO+Bv8l9Njgy3Y7ras9/q5ACcUtZQa3g==
--------------msCDF0A6BC020D37BBF8FCF625--



Received: from ns.celocom.se ([e-mail] [212.209.40.66]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id HAA29227 for <[e-mail]>; Fri, 21 Jul 2000 07:02:01 -0700 (PDT)
Received: by ns.celocom.se; id QAA04938; Fri, 21 Jul 2000 16:04:41 +0200 (CEST)
Received: from zap.celocom.se(10.10.10.1) by ns.celocom.se via smap (4.1) id xma001677; Fri, 21 Jul 00 15:13:58 +0200
Received: from celocom.se (dhcp013.celocom.se [10.10.10.193]) by zap.celocom.se (8.8.7/8.8.7) with ESMTP id PAA28291; Fri, 21 Jul 2000 15:13:58 +0200
Message-ID: <[e-mail]>
Date: Fri, 21 Jul 2000 15:13:27 +0200
From: Richard Levitte <[e-mail]>
Organization: Celo Communications, Ltd.
X-Mailer: Mozilla 4.73 [en] (WinNT; I)
X-Accept-Language: en
MIME-Version: 1.0
To: Oscar Jacobsson <[e-mail]>
CC: [e-mail]
Subject: Re: Signing what you don't understand
References: <001301bff26e$86043410$[e-mail]> <[e-mail]> <[e-mail]>
Content-Type: multipart/mixed; boundary="------------23C7D395CD03F6790F5076FA"

This is a multi-part message in MIME format.
--------------23C7D395CD03F6790F5076FA
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Oscar Jacobsson wrote:

> Richard Levitte wrote:
> > Personally, if I was confronted with a CA that wanted to create my private key
> > for me, and store it centrally to boot, I'd go somewhere else.  Very fast.  It
> > contradicts anything even remotely close to being called "secure".
>
> This gets a bit problematic when you're dealing with a party that is
> literally authoritative, for instance the Swedish government, who will
> assign you a unique identifier whether you agree with their practises or
> not.

Thanks for kicking me back into reality...  :-)

--
Richard Levitte   !!! New cell phone number !!!
[e-mail]

/* You might enjoy viewing the complete vCard */


--------------23C7D395CD03F6790F5076FA
Content-Type: text/x-vcard; charset=us-ascii;
 name="richard.levitte.vcf"
Content-Transfer-Encoding: 7bit
Content-Description: Card for Richard Levitte
Content-Disposition: attachment;
 filename="richard.levitte.vcf"

begin:vcard 
n:Levitte;Richard
tel;cell:[phone]
tel;work:[phone]
x-mozilla-html:FALSE
org:<A HREF="http://www.celocom.com">Celo Communications</A>
version:2.1
email;internet:[e-mail]
title:Software Artist
adr;quoted-printable:;;Sveav=E4gen 145, 5tr=0D=0AStockholm;;;;SWEDEN
note;quoted-printable:<br>=0D=0A<table border=3D0>=0D=0A<tr>=0D=0A  <td bgcolor=3D"#00ffff">c=EAlo, =E2vi, =E2tum, (latin) 1,v.a.=0D=0A      to hide something from one, to keep secret, to conceal.=0D=0A  </td>=0D=0A</tr>=0D=0A</table>=0D=0A<br>=0D=0A<table border=3D3>=0D=0A<tr>=0D=0A <td>=0D=0A  <table>=0D=0A  <tr>=0D=0A   <td valign=3Dtop>o/~</td>=0D=0A   <td><font size=3D-1>Coding, coding, coding</font><br>=0D=0A          Keep'em hackers coding<br>=0D=0A          <font size=3D+1>And When They're Done Coding</font><br>=0D=0A          <font size=3D7>COMPIIIIIIILE!!</font></td>=0D=0A  </tr>=0D=0A  </table>=0D=0A </td>=0D=0A</tr>=0D=0A</table>
fn:Richard Levitte
end:vcard

--------------23C7D395CD03F6790F5076FA--



Received: from po1.bbn.com (PO1.BBN.COM [192.1.50.38]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id GAA28760 for <[e-mail]>; Fri, 21 Jul 2000 06:47:42 -0700 (PDT)
Received: from [171.78.30.107] (fixed030-107.bbn.com [171.78.30.107] (may be forged)) by po1.bbn.com (8.9.1/8.9.1) with ESMTP id JAA22452; Fri, 21 Jul 2000 09:49:52 -0400 (EDT)
Mime-Version: 1.0
X-Sender: [e-mail]
Message-Id: <v04220804b59e0447a045@[171.78.30.107]>
In-Reply-To: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
Date: Fri, 21 Jul 2000 09:46:05 -0400
To: Tony Bartoletti <[e-mail]>
From: Stephen Kent <[e-mail]>
Subject: Re: Reverse paths
Cc: [e-mail]
Content-Type: text/plain; charset="us-ascii" ; format="flowed"

Tony,

>At 06:05 PM 7/20/00 -0400, Stephen Kent wrote:
>>Steve,
>>
>><snip>
>>
>>>As to how you can display the network of trust in a mesh topology, 
>>>X.500 DNs provide a nice hierarchy.
>>>Certificates are directional arcs between nodes in the tree. Trust 
>>>anchors can be displayed as arcs
>>>from the RP to the trusted party (in a different color, if you like).
>>
>>Experience with user behavior says that displaying cert paths is 
>>almost worthless.  Almost nobody will view them, and few would be 
>>able to understand the implications of such paths if they did view 
>>them.
>>
>><snip>
>
>Actually displaying the mesh to users, I hope, would not be the issue.
>
>Rather, given the mesh can be uniquely represented in "memory", can
>one write software that can reply accurately to queries of the form
>"Is there a path from A to B that satisfies my set of constraints?"
>
>And would the behavior of such a tool become intractably slow (as it
>certainly must on a general graph with many nodes, and most painfully
>if each "satisfies constraints" requires a net-fetch from a directory.)

Even if the user doesn't have to visually examine a complex cert 
path, I think all evidence to date suggests that users will not be 
amenable to formulating queries to pose to underlying software of 
this sort.

Steve



Received: from po1.bbn.com (PO1.BBN.COM [192.1.50.38]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id GAA28280 for <[e-mail]>; Fri, 21 Jul 2000 06:39:43 -0700 (PDT)
Received: from [171.78.30.107] (fixed030-107.bbn.com [171.78.30.107] (may be forged)) by po1.bbn.com (8.9.1/8.9.1) with ESMTP id JAA21013; Fri, 21 Jul 2000 09:39:50 -0400 (EDT)
Mime-Version: 1.0
X-Sender: [e-mail]
Message-Id: <v04220800b59e009cc38f@[171.78.30.107]>
In-Reply-To: <[e-mail]>
References: <[e-mail]>
Date: Fri, 21 Jul 2000 09:34:34 -0400
To: Aram Perez <[e-mail]>
From: Stephen Kent <[e-mail]>
Subject: Re: Signing what you don't understand
Cc: [e-mail]
Content-Type: text/plain; charset="us-ascii" ; format="flowed"

Aram,

>Hi Steve K.,
>
>  > When we check a signature for NR, and significant time has elapsed
>  > since the signature was applied, then different rules must be
>  > employed.
>
>How do you know how much "time has elapsed since the signature was applied"?
>I am not aware of any standard that mandates the time of the signature.
>S/MIME/PKCS#7 has provision for the signature time, but they don't mandate
>it.

If one is looking to effect NR, one has to do a number of things 
beyond simple signature checking of the sort required for typical 
authentication for input to an access control process.  For example, 
one often needs to time stamp the signature on the data, collect the 
certs and CRLs and have them time stamped, etc.  This creates a 
context that allows NR signature verification for the longer term 
than the validity of the signer's cert, or the signer's CAs' cert, 
etc.

Steve



Received: from po1.bbn.com (PO1.BBN.COM [192.1.50.38]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id GAA28134 for <[e-mail]>; Fri, 21 Jul 2000 06:37:26 -0700 (PDT)
Received: from [171.78.30.107] (fixed030-107.bbn.com [171.78.30.107] (may be forged)) by po1.bbn.com (8.9.1/8.9.1) with ESMTP id JAA21089; Fri, 21 Jul 2000 09:40:02 -0400 (EDT)
Mime-Version: 1.0
X-Sender: [e-mail]
Message-Id: <v04220802b59e03205b00@[171.78.30.107]>
In-Reply-To:  <[e-mail]>
References:  <[e-mail]>
Date: Fri, 21 Jul 2000 09:40:47 -0400
To: Sharon Boeyen <[e-mail]>
From: Stephen Kent <[e-mail]>
Subject: RE: Reverse paths
Cc: [e-mail]
Content-Type: text/plain; charset="us-ascii" ; format="flowed"

Sharon,

>Steve,
>I don't think I've been able to clearly describe what I meant. I am
>NOT proposing ANY additional certificate issuance by anybody. I think
>the terms reverse and forward are very unfortunate and always confuse
>these discussions. Can we chat offline just to make sure that you
>understand what it is I am proposing. Email makes this type of
>discussion difficult at best.
>
>Within a hierarchy I don't believe any change is required. If the root
>of a hierarchy issued a certificate to some CA that is NOT a subordinate
>of the root, then currently PKIX does not require the root CA to place
>that certificate in the root CA's entry. What I am proposing is that
>such a certificate, IF ISSUED, be placed in the issuer's entry as well
>as in the subject CA's entry.

Ok, I think this clarification makes me more comfortable.

Steve

P.S.  All the negative comments about bridge CAs in my previous 
message still apply.



Received: from sothmxs01.entrust.com (gatekeeper.entrust.com [204.101.128.170]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id FAA26695 for <[e-mail]>; Fri, 21 Jul 2000 05:52:59 -0700 (PDT)
Received: by sothmxs01.entrust.com with Internet Mail Service (5.5.2650.21) id <PHL2H1MW>; Fri, 21 Jul 2000 08:55:10 -0400
Message-ID: <[e-mail]>
From: Sharon Boeyen <[e-mail]>
To: "'Stephen Kent'" <[e-mail]>, Steve Hanna <[e-mail]>
Cc: [e-mail]
Subject: RE: Reverse paths
Date: Fri, 21 Jul 2000 08:53:30 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain; charset="iso-8859-1"

Steve,
I don't think I've been able to clearly describe what I meant. I am 
NOT proposing ANY additional certificate issuance by anybody. I think
the terms reverse and forward are very unfortunate and always confuse 
these discussions. Can we chat offline just to make sure that you 
understand what it is I am proposing. Email makes this type of 
discussion difficult at best. 

Within a hierarchy I don't believe any change is required. If the root
of a hierarchy issued a certificate to some CA that is NOT a subordinate
of the root, then currently PKIX does not require the root CA to place 
that certificate in the root CA's entry. What I am proposing is that 
such a certificate, IF ISSUED, be placed in the issuer's entry as well 
as in the subject CA's entry. 

> -----Original Message-----
> From: Stephen Kent [mailto:[e-mail]]
> Sent: Thursday, July 20, 2000 6:04 PM
> To: Steve Hanna
> Cc: [e-mail]
> Subject: Re: Reverse paths
> 
> 
> At 10:04 AM -0400 7/20/00, Steve Hanna wrote:
> >Stephen Kent wrote:
> >  > I am uncomfortable with the proposal that we mandate 
> both elements,
> >  > as this would seem to imply that every CA would have to engage in
> >  > reverse path certificate generation in all contexts.  Did I
> >  > misunderstand the implication?
> >
> >I'm not sure what you mean by "reverse path certificate generation". 
> >This change would require that
> >when a CA issues a cross certificate, they would have to place a 
> >copy of it in their own directory
> >entry (in the reverse element of a value of the crossCertificate 
> >attribute). It would not require the
> >generation of any additional certificates.
> 
> I though Sharon suggested that each CA entry would hold mandated 
> pairs of cross certs, one forward and one back, for each CA it was 
> being linked to. In today's mostly hierarchic environment, a CA 
> issues a forward cert (using X.509 terminology) to CAs "below" it and 
> is certified by CAs "above" it, but CAs do not usually generate the 
> other, reverse certs, even though they are defined and a valid part 
> of the X.509 model.  Only when CAs in different organizational 
> domains certify one another is there typically a a pair of certs 
> available. Thus, if one were to impose a constraint, via LDAP, that 
> caused CAs to issues reverse certs, it would constitute a major 
> change in the way most PKIs today are arranged.
> 
> >
> >  > I know that Entrust has always encouraged (required?) 
> this type of
> >  > cross certification among CAs, but it doesn't seem that other CA
> >  > vendors or most users have. I would not think it appropriate to
> >  > impose this sort of requirement, given the vendor-specific
> >  > implications of such a change.
> >
> >I don't see this as a vendor-specific issue, but rather as an aid to 
> >building certification paths.
> 
> It is vendor specific in so far as Entrust products have long 
> (always?) issued reverse certs, while no other major products have.
> 
> Steve
> 



Received: from odin2.bull.net (odin2.bull.net [192.90.70.84]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id CAA15255 for <[e-mail]>; Fri, 21 Jul 2000 02:18:41 -0700 (PDT)
Received: from lvt-mail.frlv.bull.fr (lvt-mail.frlv.bull.fr [129.184.62.223]) by odin2.bull.net (8.9.3/8.9.3) with ESMTP id LAA45696; Fri, 21 Jul 2000 11:25:09 +0200
Received: from bull.net (frpq6118.frpq.bull.fr [129.184.8.64]) by lvt-mail.frlv.bull.fr (8.9.2/8.9.1) with ESMTP id LAA27174; Fri, 21 Jul 2000 11:20:45 +0200
Message-ID: <[e-mail]>
Date: Fri, 21 Jul 2000 11:20:48 +0200
From: Denis Pinkas <[e-mail]>
Organization: Bull
X-Mailer: Mozilla 4.7 [fr] (Win98; I)
X-Accept-Language: fr
MIME-Version: 1.0
To: Tony Bartoletti <[e-mail]>
CC: [e-mail]
Subject: Re: A Real Rationale for Dedicated Keys
References: <[e-mail]> <[e-mail]> <[e-mail]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

 
> >Tony,

> >You cited the ability of a user (or someone else) to bind a public key
> >into multiple certs, some with and some without the NR bit enabled as a
> >reason that the NR bit is not useful for the purpose I stated.  I think I
> >pointed out in my response to John Wary why this line of reasoning is not
> >necessarily true. It would be a mistake for a user to have the same public
> >key in multiple certs, and anyone other than the user should not be able
> >to effect POP and get a CA to issue a cert.  Yes, a user could act in this
> >inappropriate fashion, in some instances, but then too a user could
> >undermine most of the safeguards that we envision through negligent conduct.
> 
> Steve,
> 
> I agree with the main points, and I worked from the assumption that
> CAs will not certify without POP (certainly not NR without POP!).

This is just the contrary: A CA can issue a certificate without POP,
if the certificate contains the NR bit. Hence is the reason: That
certificate shall only be used in a trusted environment (e.g. *not*
a door lock) where, by some means, there is some assurance of *what*
is being signed; in particular, which document is being signed and
which format is being used for the signature. Since the certificate
shall only be used with a trusted sofwtare, it is possible to
mandate properties for that trusted software; in particular, that it
SHALL always include the identifier of the signer's certificate and
protect it under the digital signature.

As soon as the private key is *only* used with signature formats
that contain the identifier of the certificate protected under the
digital signature, this provides "real-time" POP. In other words,
only the entity owning the private key is able to include the right
certificate identifier. If a CA has issued a certificate without
POP, this does not matter anymore, since only the legitimate entity
able to use the private key will be able to sign under the
certificate that contains the matching public key. Security is a mix
of security mechanisms and security procedures. In this case, we
rely on "good cryptography" rather than security procedures (that
may be hard and long to verify "after the fact").

Denis

(further text deleted)

> ___tony___
> 
> Tony Bartoletti 925-422-3881 <[e-mail]>
> Information Operations, Warfare and Assurance Center
> Lawrence Livermore National Laboratory
> Livermore, CA 94551-9900


Received: from odin2.bull.net (odin2.bull.net [192.90.70.84]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id AAA11299 for <[e-mail]>; Fri, 21 Jul 2000 00:52:26 -0700 (PDT)
Received: from lvt-mail.frlv.bull.fr (lvt-mail.frlv.bull.fr [129.184.62.223]) by odin2.bull.net (8.9.3/8.9.3) with ESMTP id JAA18090; Fri, 21 Jul 2000 09:58:46 +0200
Received: from bull.net (frpq6118.frpq.bull.fr [129.184.8.64]) by lvt-mail.frlv.bull.fr (8.9.2/8.9.1) with ESMTP id JAA39622; Fri, 21 Jul 2000 09:54:22 +0200
Message-ID: <[e-mail]>
Date: Fri, 21 Jul 2000 09:23:38 +0200
From: Denis Pinkas <[e-mail]>
Organization: Bull
X-Mailer: Mozilla 4.7 [fr] (Win98; I)
X-Accept-Language: fr
MIME-Version: 1.0
To: Aram Perez <[e-mail]>
CC: [e-mail]
Subject: Re: Signing what you don't understand
References: <[e-mail]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Aram,

ETSI Standard ES 201733 mandates the signature time as a signed
attribute of the CMS structure. An informational draft RFC based on
that standard is available from:

http://www.ietf.org/internet-drafts/draft-ietf-smime-esformats-01.txt

Denis

> Hi Steve K.,
> 
> > When we check a signature for NR, and significant time has elapsed
> > since the signature was applied, then different rules must be
> > employed.
> 
> How do you know how much "time has elapsed since the signature was applied"?
> I am not aware of any standard that mandates the time of the signature.
> S/MIME/PKCS#7 has provision for the signature time, but they don't mandate
> it.
> 
> Regards,
> Aram Perez




Received: from odin2.bull.net (odin2.bull.net [192.90.70.84]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id AAA11275 for <[e-mail]>; Fri, 21 Jul 2000 00:52:21 -0700 (PDT)
Received: from lvt-mail.frlv.bull.fr (lvt-mail.frlv.bull.fr [129.184.62.223]) by odin2.bull.net (8.9.3/8.9.3) with ESMTP id JAA23348; Fri, 21 Jul 2000 09:58:46 +0200
Received: from bull.net (frpq6118.frpq.bull.fr [129.184.8.64]) by lvt-mail.frlv.bull.fr (8.9.2/8.9.1) with ESMTP id JAA15398; Fri, 21 Jul 2000 09:54:21 +0200
Message-ID: <[e-mail]>
Date: Fri, 21 Jul 2000 09:15:34 +0200
From: Denis Pinkas <[e-mail]>
Organization: Bull
X-Mailer: Mozilla 4.7 [fr] (Win98; I)
X-Accept-Language: fr
MIME-Version: 1.0
To: [e-mail]
CC: [e-mail]
Subject: Re: Signing what you don't understand
References: <[e-mail]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

John,

If you attend the next meeting in Pittsburgh, I propose that we
continue this discussion in the corridors. I will nevertheless
answer your questions.

 
> Denis,
> 
> >> Note I'm not talking about NR here -
> >
> >So what are you talking about ???
> 
> The case where an RP receives a document and is trying to verify a
> signature.  The significance of the NR bit in a certificate was the
> starting point for this discussion, but for now I'm simply concerned with
> the initial signature verification (if the RP doesn't believe my signature,
> he certainly can't expect to hold me to it :).  Note I'm not restricting
> this to simple E-mail, where because of the one-to-one, low-latency nature
> of the communications involved, there is unlikely to be a significant time
> between signing and verifying (and if there is, the RP can simply ask the
> sender for a freshly-signed copy).  Rather, I'm talking about high-latency
> or one-to-many environments.  An extreme example of this might be signing a
> document and placing it on a web-site or in a directory - here I am signing
> the document without any knowledge of the identity of the RPs, and with the
> possibility of significant delay before an RP will try to verify the
> signature.

Your are talking NR without knowing it. :-)

In your example, the signed data does not have NR properties but the
RP would like to get the the NR properties. So unless the signer
places signed data that have NR properties, the case CANNOT be
solved, i.e. disputes cannot be solved, just because there is not
enough information available to solve the dispute.  So unless
"sufficient" information is orginally placed, the signed message
does not have long term properties.


> >> >A RP can be responsible for acquiring all the requisite evidence for
> >> >later support of signed document validity, including time stamping
> >> >this evidence. I think this addresses the scenario you described
> >> >above.
> >>
> >> That addresses the case where the document is processed by the RP prior
> to
> >> my CA going out of business, but it doesn't help if trust in the CA has
> >> already been revoked at the time the RP tries to verify the signature.
> >
> >Don't you think that if a RP receives a siganture it has better to
> >make sure that what it gets is "fine" ? So he should validate the
> >signature as soon as possible and in order to cover the case of a
> >possible (volontary) revocation of the signer certificate, he should
> >time stamp the signature as soon as possible. So the case you are
> >considering is not a practical case.
> 
> In the situation I'm discussing, one of the CAs that the signer chose to
> embed in his signature has already gone out of business by the time the RP
> sees the signature.
> 
> >> But that doesn't help
> >> unless the RP directly trusts the signer's root CA.
> >
> >There is no concept of root CA. There is a concept of a Signature
> >Policy that may involve one or more root CAs but involves many other
> >conditions.
> >
> >> If the RP doesn't trust the root that the signer chooses,
> >
> > ... you mean : If the RP thinks that the Signature Policy is not
> >adequate for his context of use, then this is the end of the story.
> 
> Yes, that's a concise statement of the problem.  By requiring that the
> signer choose a specific Signature Policy (including, in the context of
> this discussion, the certificate chain), rather than leaving it to the RP
> to construct the chain, there is a possibility of a signature being
> incorrectly determined as invalid.  

This is incorrect. If in this specific case, all the chain is built
by the signer (including proof that every certificate from the chain
was not revoked at the time of the signature) then there is only ONE
determination possible. This means the chain must be constructed
while all the CAs are still in business, ... and this solves the
case.

> By omitting the signer's certificate
> chain, and leaving it up to the RP to construct an appropriate chain, then
> if my CA goes out of business, it wouldn't necessarily invalidate my prior
> signatures (providing my key can be certified by another CA).


(snip) 

> >This is contradictory. "if it includes evidence that at the time of
> >signature creation, those certificates had not yet been revoked"
> >means that you must provide a proof that the certificates whre not
> >revoked at the time of the signature, so you cannot say at the same
> >time "certificate chain that contains revoked certificates".
> 
> It's not contradictory:  Evidence that a certificate had not been revoked
> at time T could include a CRL that was valid at T, and that did not list
> the certificate.  However, if later a CRL were published (and were
> available to the RP) that included the certificate, along with an
> invalidityDate before time T, then the RP can conclude that the certificate
> has been revoked, and should not be trusted to verify a signature made at
> T.

You should talk a closer look at <draft-ietf-smime-esformats-01.txt>
section 4.1.1  Signature Timestamp Attribute Definition  

The Signature Validation Policy specifies, in the
signatureTimestampDelay field of TimestampTrustConditions, a maximum
acceptable time difference which is allowed between the time
indicated in the signing time attribute and the time indicated by
the Signature Timestamp attribute. If this delay is exceeded then
the electronic signature *must* be considered as invalid.

This means that the signed data *must* include a signing time (as a
signed attribute from the CMS construct). This allows to solve
unambiguously the case.

Denis

> 
> John




Received: from iaik.tu-graz.ac.at (excalibur.iaik.tu-graz.ac.at [129.27.152.30]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id XAA09852 for <[e-mail]>; Thu, 20 Jul 2000 23:48:45 -0700 (PDT)
Received: from PLIPP2 [129.27.152.34] by iaik.tu-graz.ac.at (SMTPD32-6.00) id A2EA24A0090; Fri, 21 Jul 2000 08:51:22 +0200
Received: from 127.0.0.1 [127.0.0.1] by PLIPP2 (IAIK S/MIME Mapper 2.0beta3 22/March/2000); Fr, 21 Jul 2000 08:52:32 +0100
From: "Peter Lipp" <[e-mail]>
To: "Peter Williams" <[e-mail]>
Cc: <[e-mail]>
Subject: AW: Signing what you don't understand
Date: Fri, 21 Jul 2000 08:52:32 +0200
Message-ID: <[e-mail]>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=sha1; boundary="--IAIK.SMIME.MAPPER.542A9105--"; protocol="application/x-pkcs7-signature"
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0)
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700
In-Reply-To: <[e-mail]>
Importance: Normal

This is a multipart MIME message, it may require a MIME capable user agent.
----IAIK.SMIME.MAPPER.542A9105--
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

> "VeriSign's revolutionary technology allows an end-user to securely
> store digital certificates and/or any other type of data, such as
> financial information or an online patient record, on distributed
> network servers operated by multiple trusted service providers. This
> technology enables portability of digital certificates, providing
> convenience for users to access and download their certificates and
> private keys for online authentication. It also enables the generation
> of binding digital signatures for conducting high-value e-commerce
> transactions, regardless of whether users are accessing the Internet
> from work, home, or another location such as an Internet kiosk. Digital
> certificates are electronic credentials that identify parties online,
> enabling encrypted communications and legally binding, valid digital
> signatures.

Admittedly you don't explicitly claim that technology to be able to generate
legally binding digital signatures, even if the last sentence seems to imply
that... at least you wouldn't be able to in Europe.

Peter



----IAIK.SMIME.MAPPER.542A9105--
Content-Type: application/x-pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAA
oIIVIDCCBE0wggM5oAMCAQICAwGGrTAJBgUrDgMCHQUAMIIBEzELMAkGA1UEBhMC
QVQxDzANBgNVBAgTBlN0eXJpYTENMAsGA1UEBxMER1JBWjEZMBcGA1UECRMQSW5m
ZmVsZGdhc3NlIDE2YTEmMCQGA1UEChMdR1JBWiBVTklWRVJTSVRZIE9GIFRFQ0hO
T0xPR1kxRzBFBgNVBAsTPkluc2l0dXRlIGZvciBBcHBsaWVkIEluZm9ybWF0aW9u
IFByb2Nlc3NpbmcgYW5kIENvbW11bmljYXRpb25zMRkwFwYDVQQLExBJQUlLIElO
VFJBTkVUIENBMRkwFwYDVQQDExBJQUlLIFRVLUdSQVogU0lHMSIwIAYDVQQMExlJ
QUlLIGVsZWN0cm9uaWMgc2lnbmF0dXJlMB4XDTk5MTEyODIwMjIzOVoXDTAwMTEy
ODIwMjIzOVowgZMxCzAJBgNVBAYTAkFUMSYwJAYDVQQKEx1HUkFaIFVOSVZFUlNJ
VFkgT0YgVEVDSE5PTE9HWTFHMEUGA1UECxM+SW5zaXR1dGUgZm9yIEFwcGxpZWQg
SW5mb3JtYXRpb24gUHJvY2Vzc2luZyBhbmQgQ29tbXVuaWNhdGlvbnMxEzARBgNV
BAMTClBldGVyIExpcHAwgZ0wDQYJKoZIhvcNAQEBBQADgYsAMIGHAoGBAM5s1aJQ
xXxczmMNSJtL4cv9nhMA+dtbUN4+DA5qfZBqcwR2zWw2VulPyrAeZDA1HFP8zlpk
PlC5C4hNnX+p7QdG8u0LMk45FwaatOm2r2gEmTYGH/znwQSrKTsZXi0d0VHZV0TX
yU/I3SlYxSXfjFafAVE09KKa2m8jcUOhF97dAgEDo4G0MIGxMDgGA1UdHwQxMC8w
LaAroCmkJzAlMRAwDgYDVQQKEwdpYWlrLmF0MREwDwYDVQQDEwhJQUlLQ1JMMTAR
BglghkgBhvhCAQEEBAMCAKAwKAYJYIZIAYb4QgENBBsWGVVzZXItQ2VydGlmaWNh
dGUgSU5UUkFORVQwDAYDVR0TBAUwAwEBADAdBgNVHREEFjAUgRJQZXRlci5MaXBw
QGlhaWsuYXQwCwYDVR0PBAQDAgbAMAkGBSsOAwIdBQADggEBAA4r/qDOLW8ChbuC
2pGzcf74Uv190Q45aHj99lMgNhPQRIVaLLNXJH+NYJxEvIwmVOWIXjdA03TqkOOq
FJ/tK31wV+RbrvaPaVUwRjPhC2f8rr+K6pp9mzUC1SolUEbRWVHgOZGsbnEJkTEr
oJOelFdKr0coT+Xeje/fI5d50P3CwsJLR2PFkiswnOoWBINi2nq6MGZ7fwmzW8F9
ZVstrNMQYCeEj4V2SR/YIUrDxsdqMQyorBe/su3eab3fOpPlonb86KKWH6jLdgpi
KGRoHGWeGgAWlMB0HdxaupX7Lm8LhVYZOdh9SpvO8AdhMyOXNHOKF6sMXCZvSEHy
2XUvbmAwggRUMIIDQKADAgECAgJOIDAJBgUrDgMCHQUAMIGZMQswCQYDVQQGEwJB
VDEmMCQGA1UEChMdR1JBWiBVTklWRVJTSVRZIE9GIFRFQ0hOT0xPR1kxRzBFBgNV
BAsTPkluc2l0dXRlIGZvciBBcHBsaWVkIEluZm9ybWF0aW9uIFByb2Nlc3Npbmcg
YW5kIENvbW11bmljYXRpb25zMRkwFwYDVQQDExBJQUlLIElOVFJBTkVUIENBMB4X
DTk5MTExNDEyNTE0OVoXDTAyMTIzMTIyNTkzMFowggETMQswCQYDVQQGEwJBVDEP
MA0GA1UECBMGU3R5cmlhMQ0wCwYDVQQHEwRHUkFaMRkwFwYDVQQJExBJbmZmZWxk
Z2Fzc2UgMTZhMSYwJAYDVQQKEx1HUkFaIFVOSVZFUlNJVFkgT0YgVEVDSE5PTE9H
WTFHMEUGA1UECxM+SW5zaXR1dGUgZm9yIEFwcGxpZWQgSW5mb3JtYXRpb24gUHJv
Y2Vzc2luZyBhbmQgQ29tbXVuaWNhdGlvbnMxGTAXBgNVBAsTEElBSUsgSU5UUkFO
RVQgQ0ExGTAXBgNVBAMTEElBSUsgVFUtR1JBWiBTSUcxIjAgBgNVBAwTGUlBSUsg
ZWxlY3Ryb25pYyBzaWduYXR1cmUwggEgMA0GCSqGSIb3DQEBAQUAA4IBDQAwggEI
AoIBAQDSyhKuZGsL1EPk5mOTG8RzhHS/Va+/WYjs7Zm91nwVHu1+XFLJeJ85AICk
SQ7yq9lWa9ur34cywbNhl/9QxaOBOiHkMvAuXxs2Bq/uhe/hEb1T7XgO12ptG80q
SOP8/nKxw1PXlbUkd1rD9727mO/5tpvagEQfz7CZQ5wI4HkrNw5uH/vsJ72wRcRT
FzmHy/nOX3Y9sXLd/V7TG8j1x0oNWsR3b0tHEWM+Oc1Qq5FfCknoMMCitSD38cUL
CCcLJtVxkOiapWaZrDXUAuhvshhsRPjkXh6IzpqsZEtRI64SurLoUUShPv108ELE
6rfQKtm9FNnlFRD954diwfFHko/lAgEFozMwMTARBglghkgBhvhCAQEEBAMCAAIw
DwYDVR0TBAgwBgEB/wIBATALBgNVHQ8EBAMCAQYwCQYFKw4DAh0FAAOCAQEAc26n
vl5jQspoqD0fzjpZkqGARmFVj9uHNqVoWttqw/y6t46OhJUcePEmXkKsFP4NuCFx
2MyvmbWb6R6QNQ5WfoarGWyQ382cQN6mccPS5weDjXAzYeGZUkx99K70ncVxkwq7
rINAhJtari2XSLxmfBJyTYrZuWEgd5C9NBuf2u3iZyArarOKPbrBjZxjmXwBbZ7t
sfAhSVMGSr2ODgQcQjf7ZndNIsQZL75HkN21Pj+/x3wnMCAQF50+Pt8ioAgZ/SAu
dxmdYNr2itI0vmsV/xjD1NQuwb6+HwmR2LxclhMzrT1VbtTDkRLD/h8LKC1OpKV8
lQlS7Ir+Od/XNafKJjCCA8owggKyoAMCAQICAQEwDQYJKoZIhvcNAQEEBQAwgZkx
CzAJBgNVBAYTAkFUMSYwJAYDVQQKEx1HUkFaIFVOSVZFUlNJVFkgT0YgVEVDSE5P
TE9HWTFHMEUGA1UECxM+SW5zaXR1dGUgZm9yIEFwcGxpZWQgSW5mb3JtYXRpb24g
UHJvY2Vzc2luZyBhbmQgQ29tbXVuaWNhdGlvbnMxGTAXBgNVBAMTEElBSUsgSU5U
UkFORVQgQ0EwHhcNOTkxMTE0MTIzMTU5WhcNMDIxMjMxMjI1OTMwWjCBmTELMAkG
A1UEBhMCQVQxJjAkBgNVBAoTHUdSQVogVU5JVkVSU0lUWSBPRiBURUNITk9MT0dZ
MUcwRQYDVQQLEz5JbnNpdHV0ZSBmb3IgQXBwbGllZCBJbmZvcm1hdGlvbiBQcm9j
ZXNzaW5nIGFuZCBDb21tdW5pY2F0aW9uczEZMBcGA1UEAxMQSUFJSyBJTlRSQU5F
VCBDQTCCASAwDQYJKoZIhvcNAQEBBQADggENADCCAQgCggEBAMLr+IHe6qeAtYLk
fvxyRI6ogrvBP5iKPEBZ7j3T1yVJL7CDPGH8hgPsI4qt6Fnzh2MuAq84JS58zX5x
LqEUC/E5xw1xyAzorC6yWwxGRhb+fvTg4OlM2JVsTlyJO6F/BWlXuZU33lgGky/R
X84sItXKhmhbUPscnHYBsVKcQO5rFcRrJK/5c1Mha/bcQNVDQaQw+HRCvr7T4mAV
Yi+DVJv6jb393CoDBnffGP/mcIkFGFO5D6lyfP8QiSs06+0unIYWwUn1YzQI2RNB
AjXrCuAJtlf4qYrGXC09Neg8ymoI2uOglo6scWiZXt/prxWoi+btPX8oWDl5+7DE
tCf0rx8CAQejHTAbMAwGA1UdEwQFMAMBAf8wCwYDVR0PBAQDAgEGMA0GCSqGSIb3
DQEBBAUAA4IBAQAfdOMJ/ePlmrY0flkgiL6vyRDBuWGcIaB/oGofngJzbQLa7X2s
hWzpIiVpvo64XcjIBuocpErhIQfc2UZTSqYYT7R2Uydh0wVeqScURuwuihFURPhI
7GWCSrNwym2lrwsva2Xh/MTyzhXs9vo29dP2djjelN8n347dXhKJOYJ0tsA583af
EKmKvkfzAb+sQLxEmPyasQTCGJMec/iWjLTsEDRfCrROYVgDZ4NcCpiRSv9mWw6s
PYB8Chf5fJq1waFzluFYSUkuF24NKVopr1E4dKt2Lc1zdMRGRztKQWeUiBLkqFCQ
xsi6iZrl1nvMCdF+scuLj7G4lNshx6n1ZcabMIIETTCCAzmgAwIBAgIDAw1NMAkG
BSsOAwIdBQAwggETMQswCQYDVQQGEwJBVDEPMA0GA1UECBMGU3R5cmlhMQ0wCwYD
VQQHEwRHcmF6MRkwFwYDVQQJExBJbmZmZWxkZ2Fzc2UgMTZhMSYwJAYDVQQKEx1H
UkFaIFVOSVZFUlNJVFkgT0YgVEVDSE5PTE9HWTFHMEUGA1UECxM+SW5zaXR1dGUg
Zm9yIEFwcGxpZWQgSW5mb3JtYXRpb24gUHJvY2Vzc2luZyBhbmQgQ29tbXVuaWNh
dGlvbnMxGTAXBgNVBAsTEElBSUsgSU5UUkFORVQgQ0ExGzAZBgNVBAMTEklBSUsg
VFUtR1JBWiBDUllQVDEgMB4GA1UEDBMXSUFJSyBjb25maWRlbnRpYWxpdHkgQ0Ew
HhcNOTkxMTI4MjAyMzM4WhcNMDAxMTI4MjAyMzM4WjCBkzELMAkGA1UEBhMCQVQx
JjAkBgNVBAoTHUdSQVogVU5JVkVSU0lUWSBPRiBURUNITk9MT0dZMUcwRQYDVQQL
Ez5JbnNpdHV0ZSBmb3IgQXBwbGllZCBJbmZvcm1hdGlvbiBQcm9jZXNzaW5nIGFu
ZCBDb21tdW5pY2F0aW9uczETMBEGA1UEAxMKUGV0ZXIgTGlwcDCBnTANBgkqhkiG
9w0BAQEFAAOBiwAwgYcCgYEAvQe3ZdxrE2Nv5z2ZLink1P2MFeQb5gYrS55w4jsX
ZGD5v9Ajnv3w30Ajcn7jI+blIvYYpmNQV476+aUHNZFUML/KN5WGVXfdBOxb2n+6
Porez8KMnUlq3cCvAdhVdquFjwaRHO5k7gY80hNAfVker52A1aXbrT0TaWGlCl25
sq0CAQWjgbQwgbEwOAYDVR0fBDEwLzAtoCugKaQnMCUxEDAOBgNVBAoTB2lhaWsu
YXQxETAPBgNVBAMTCElBSUtDUkwxMBEGCWCGSAGG+EIBAQQEAwIAoDAoBglghkgB
hvhCAQ0EGxYZVXNlci1DZXJ0aWZpY2F0ZSBJTlRSQU5FVDAMBgNVHRMEBTADAQEA
MB0GA1UdEQQWMBSBElBldGVyLkxpcHBAaWFpay5hdDALBgNVHQ8EBAMCA3gwCQYF
Kw4DAh0FAAOCAQEAhvbZ0/1a47YqiCYjsnsqxWhFufL9oPQzzK9sBDjZZwbpPnhD
ZN8PmBqWUXAo74a6oz7Q0W1QieAPCIGenFcVe5ui9m+9TDwtrQN1ECE5k3VuGlh9
l+1Sw5GjFEynARTDmaSRIc75EV/nx4a1LuHLkRYGC5Mg6LskWpIw7ShdPD54U/3Q
19iboaASh0ynfySjBsy1549hQcmi9UfMMX7u1QCCia2kd15u+YaVxtWoMHFB59q6
ELx+9XseEpEI/zBlvSwdyDTXWtnlxnzZjsyk0a/W+FpdeuZ7k2Dbf/Owx0nXS70M
HrH/AErvvbhxJ1BaAPC6TAN6da4xPpwy5XSRfjCCBFQwggNAoAMCAQICAnUwMAkG
BSsOAwIdBQAwgZkxCzAJBgNVBAYTAkFUMSYwJAYDVQQKEx1HUkFaIFVOSVZFUlNJ
VFkgT0YgVEVDSE5PTE9HWTFHMEUGA1UECxM+SW5zaXR1dGUgZm9yIEFwcGxpZWQg
SW5mb3JtYXRpb24gUHJvY2Vzc2luZyBhbmQgQ29tbXVuaWNhdGlvbnMxGTAXBgNV
BAMTEElBSUsgSU5UUkFORVQgQ0EwHhcNOTkxMTE0MTI1NTM2WhcNMDIxMjMxMjI1
OTMwWjCCARMxCzAJBgNVBAYTAkFUMQ8wDQYDVQQIEwZTdHlyaWExDTALBgNVBAcT
BEdyYXoxGTAXBgNVBAkTEEluZmZlbGRnYXNzZSAxNmExJjAkBgNVBAoTHUdSQVog
VU5JVkVSU0lUWSBPRiBURUNITk9MT0dZMUcwRQYDVQQLEz5JbnNpdHV0ZSBmb3Ig
QXBwbGllZCBJbmZvcm1hdGlvbiBQcm9jZXNzaW5nIGFuZCBDb21tdW5pY2F0aW9u
czEZMBcGA1UECxMQSUFJSyBJTlRSQU5FVCBDQTEbMBkGA1UEAxMSSUFJSyBUVS1H
UkFaIENSWVBUMSAwHgYDVQQMExdJQUlLIGNvbmZpZGVudGlhbGl0eSBDQTCCASAw
DQYJKoZIhvcNAQEBBQADggENADCCAQgCggEBAMEnzjatic90xi5VRmr0i2O16Z1a
SElQFZitoNvAzGw+KehOTuKeUr5ALHib9tGInNm+jPTWVGl/u5Hab1JRzXj0xAKy
qvZ+KphGy6ag6VcCVySJmeY1AqTM0W78XdFQXnlZuciBv00Ktoulb/Ktgh6c0YNg
o4UMVdxjGHJweibT1AGvlFe2BqulwtuwOLovMIuIyHHh+o6F2HXYKUB54GJpia1B
2IfmqcpBBFdYtDlHyrxugB5QhuhLo0BjD8jCe8B2gkQnI2wIeyfpLlH+u3/VQAl1
2cZKkqaqPpOgP/znsdh62QBSabrRluvCp9OQW9M8u+mJlrxIIVwtThfzIW0CAQWj
MzAxMBEGCWCGSAGG+EIBAQQEAwIAAjAPBgNVHRMECDAGAQH/AgEBMAsGA1UdDwQE
AwIBBjAJBgUrDgMCHQUAA4IBAQBa+v4JIzqbBydvFOaP/dA5D/GLWEWjPTF8tKcP
hxlEYABH8dW5E2tk/nNE2CDyGjkJtR+o9kiCDCa4N/qlc2LepJpa0I28Hi4wCd0C
uxSWpEuDHNDrW6Y/bU8gJ8DpskVl+lR0QFkqSCWAu3bY0e2VvUffk2ltrx1KvO64
vGX+ayZn2P7naGHPfYjCBWUKzW0zS8chVf0aehu/qXFuZDfy1MlDgEnPl1DQ1vSL
CMmFEDc99iNzcCU7ILn+RgWPNYPVhCUqoDQ6buX00ohfNVS/OHgqkWpa1HLvLRXq
E9NmYUJvfhE2zCY6w6bTME3IfDCXRat2Q3twP4/iP9xtsTbPMYICeDCCAnQCAQEw
ggEcMIIBEzELMAkGA1UEBhMCQVQxDzANBgNVBAgTBlN0eXJpYTENMAsGA1UEBxME
R1JBWjEZMBcGA1UECRMQSW5mZmVsZGdhc3NlIDE2YTEmMCQGA1UEChMdR1JBWiBV
TklWRVJTSVRZIE9GIFRFQ0hOT0xPR1kxRzBFBgNVBAsTPkluc2l0dXRlIGZvciBB
cHBsaWVkIEluZm9ybWF0aW9uIFByb2Nlc3NpbmcgYW5kIENvbW11bmljYXRpb25z
MRkwFwYDVQQLExBJQUlLIElOVFJBTkVUIENBMRkwFwYDVQQDExBJQUlLIFRVLUdS
QVogU0lHMSIwIAYDVQQMExlJQUlLIGVsZWN0cm9uaWMgc2lnbmF0dXJlAgMBhq0w
CQYFKw4DAhoFAKCBsTAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3
DQEJBTEPFw0wMDA3MjEwNjUyMzJaMCMGCSqGSIb3DQEJBDEWBBR7isd2IdxCuWKI
78jSUeGeUJI4vTBSBgkqhkiG9w0BCQ8xRTBDMAoGCCqGSIb3DQMHMA4GCCqGSIb3
DQMCAgIAgDANBggqhkiG9w0DAgIBQDANBggqhkiG9w0DAgIBKDAHBgUrDgMCBzAN
BgkqhkiG9w0BAQEFAASBgF3L605S2d/S4b2oiWamlzQqXiDQdmrx5flmKDNe+Y+Q
vVNtegz+BQ98O69+3r0t/8Mik+VOBOHdrBcjzL42c32UqcjG3mokNWV8T4Llf3Eb
3no+/bsbLLpBaRajPYj/uM1HS13l20ZJ1Cy0gQMSuTGjgXs0azVbJMZDUQfjjCtx
AAAAAAAA
----IAIK.SMIME.MAPPER.542A9105----



Received: from aspams52.cai.com (aspams52.cai.com [155.35.248.76]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id VAA03998 for <[e-mail]>; Thu, 20 Jul 2000 21:47:14 -0700 (PDT)
Received: by aspams52.cai.com with Internet Mail Service (5.5.2650.21) id <3X7BA2LS>; Fri, 21 Jul 2000 14:48:11 +1000
Message-ID: <[e-mail]>
From: "Ramsay, Ron" <[e-mail]>
To: Peter Williams <[e-mail]>
Cc: [e-mail]
Subject: RE: Signing what you don't understand
Date: Fri, 21 Jul 2000 14:48:08 +1000
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain; charset="iso-8859-1"

Very interesting. It would have been interesting to have heard from Warwick
on the issue of non-repudiation. Verisign would seem to have placed a stake
in the ground.

Ron.
-----Original Message-----
From: Peter Williams [mailto:[e-mail]]
Sent: Friday, 21 July 2000 12:52
To: 'Richard Levitte'; Anders Rundgren
Cc: Peter Lipp; [e-mail]; [e-mail]
Subject: RE: Signing what you don't understand


 

http://www.verisign.com/press/2000/roaming.html

 

"VeriSign's revolutionary technology allows an end-user to securely 
store digital certificates and/or any other type of data, such as 
financial information or an online patient record, on distributed 
network servers operated by multiple trusted service providers. This 
technology enables portability of digital certificates, providing 
convenience for users to access and download their certificates and 
private keys for online authentication. It also enables the generation 
of binding digital signatures for conducting high-value e-commerce 
transactions, regardless of whether users are accessing the Internet 
from work, home, or another location such as an Internet kiosk. Digital 
certificates are electronic credentials that identify parties online, 
enabling encrypted communications and legally binding, valid digital 
signatures. 
"
 
-----Original Message-----
From: Richard Levitte [mailto:[e-mail]]
Sent: Thursday, July 20, 2000 11:24 AM
To: Anders Rundgren
Cc: Peter Lipp; [e-mail]; [e-mail]
Subject: Re: Signing what you don't understand


Anders Rundgren wrote:

> Peter,
>
> >> Several leading PKI vendors have implemented systems where the private
key
> >> is held on a central Web server and then downloaded at run time to a
web
> >> browser.  Are you saying that signatures created using these keys are
> >> invalid?
> >Are you sure? Could you provide a reference? I doubt that strongly...
> >
> >Peter
>
> I think this is one...
>
> http://www.arcot.com/products/webfort.html

I think not, at least from reading the papers "Protecting Digital
Identities" and
"Protecting Your Private Key".  All they say is that they've invented some
kind
of key database ("key wallet" to use their term) that is more secure than
what
comes with for example MSIE and Netscape Communicator...

Personally, if I was confronted with a CA that wanted to create my private
key
for me, and store it centrally to boot, I'd go somewhere else.  Very fast.
It
contradicts anything even remotely close to being called "secure".

--
Richard Levitte   !!! New cell phone number !!!
[e-mail]

/* You might enjoy viewing the complete vCard */


Received: from diablo.OntheNet.com.au (diablo.OntheNet.com.au [203.10.89.2]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id VAA02612 for <[e-mail]>; Thu, 20 Jul 2000 21:04:14 -0700 (PDT)
Received: from msimon (pc3.eracom.com.au [203.144.16.147]) by diablo.OntheNet.com.au (8.9.3/8.9.3) with SMTP id OAA61074; Fri, 21 Jul 2000 14:06:27 +1000 (EST)
Message-ID: <028d01bff2ca$4956e3d0$[e-mail]>
From: "Simon McMahon" <[e-mail]>
To: "Aram Perez" <[e-mail]>, <[e-mail]>
References: <[e-mail]>
Subject: Re: A Real Rationale for Dedicated Keys
Date: Fri, 21 Jul 2000 14:14:51 +1000
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.00.2314.1300
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300

>
> Without the owner physically showing up, how can a CA know whether or not
a
> key pair was "generated and the private part is stored to some minimum
> standard"?
>
The key generation device has its own private key and signs the cert request
for the newly generated user key pair. The CA then knows that the key pair
originated in a device it (the CA) trusts and probably provides as part of
its service. The CA certifies the public key of the device so it can verify
the device's cert requests.

Such a device is obviously not cheap but without such a device the CA cannot
control the quality of remotely generated keys or how the private key is
stored and protected from duplication (necessary for NR).

Much more likely is that the owner *will* show up to the CA or one of its
RAs to get a NR certificate. Anything less will probably fail to meet the
legal requirements for NR and be worth no more than a NR=0 cert.

Simon McMahon
ERACOM Pty. Ltd.




Received: from diablo.OntheNet.com.au (diablo.OntheNet.com.au [203.10.89.2]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id UAA01714 for <[e-mail]>; Thu, 20 Jul 2000 20:50:04 -0700 (PDT)
Received: from msimon (pc3.eracom.com.au [203.144.16.147]) by diablo.OntheNet.com.au (8.9.3/8.9.3) with SMTP id NAA58099; Fri, 21 Jul 2000 13:52:28 +1000 (EST)
Message-ID: <028a01bff2c8$5845e5a0$[e-mail]>
From: "Simon McMahon" <[e-mail]>
To: "Jean Abraham" <[e-mail]>, <[e-mail]>, "Tony Bartoletti" <[e-mail]>
References: <[e-mail]><[e-mail]> <[e-mail]>
Subject: Re: A Real Rationale for Dedicated Keys
Date: Fri, 21 Jul 2000 14:00:49 +1000
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.00.2314.1300
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300

> At 11:41 AM 7/21/00 +1000, Simon McMahon wrote:
> >I am are not saying "no" to multi-certification. Just "no" to its use as
a
> >repudiation defense. Appropriate CA policy can make it harder for the
> >dishonest user to make repudiation claims based on being "fooled". If the
> >user has declared that they will not multi-certify a NR=1 key down to
NR=0,
> >then goes and does it anyway their repudiation claim is going to look
pretty
> >weak.
>
> OK, that is a good point.  Now, I set my mind to thinking of how
> the (bad) user might argue that the policy was not conveyed to them,
> and wonder how to "bind" the user's "expression of understanding"
> into the certificate.
>
If the bad user gets away with it then the CA's policy or procedures failed.
Either the bad user or the CA is liable so someone will be held accountable
for it.

> Granted, the user/subscriber is "duty-bound" to be aware of policy,
> but in most instances (e.g., detailed credit card agreements) they
> are not, and the laws are usually crafted to keep the foolish from
> hurting themselves too badly.

How can any party to an "agreement" not be duty-bound to be aware of policy
relating to the agreement ? But as you say laws will be crafted to minimise
losses where they aren't.

>  The protocol for applying for and
> receiving a (hypothetical) NR-certificate, especially through an
> electronic transaction, will need to be both involved and rigorous,
> in order to thwart a claim that "the policy wasn't obvious" or
> "my screen displayed no policy".
>

Thats for sure.
I personally doubt that legally enforcible NR-certificates will ever granted
fully on-line. You would need a legally enforcible on-line authentication of
the subject for a start. That sort of thing is usually done by an agent of
the CA sighting documents like passport, drivers license etc.

Simon.




Received: from ext-mail.valicert.com (ns1.valicert.com [63.65.221.10]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id TAA27838 for <[e-mail]>; Thu, 20 Jul 2000 19:57:09 -0700 (PDT)
Received: from CONVERSION-DAEMON.ext-mail.valicert.com by ext-mail.valicert.com (PMDF V6.0-24 #46243) id <[e-mail]> for [e-mail]; Thu, 20 Jul 2000 19:59:48 -0700 (PDT)
Received: from seine.valicert.com ([192.168.2.23]) by ext-mail.valicert.com (PMDF V6.0-24 #46243) with ESMTP id <[e-mail]>; Thu, 20 Jul 2000 19:59:48 -0700 (PDT)
Received: by seine.valicert.com with Internet Mail Service (5.5.2650.21) id <36006T9Y>; Thu, 20 Jul 2000 19:51:36 -0700
Content-return: allowed
Date: Thu, 20 Jul 2000 19:51:31 -0700
From: Peter Williams <[e-mail]>
Subject: RE: Signing what you don't understand
To: "'Richard Levitte'" <[e-mail]>, Anders Rundgren <[e-mail]>
Cc: Peter Lipp <[e-mail]>, [e-mail], [e-mail]
Message-id: <[e-mail]>
MIME-version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-type: text/plain; charset=iso-8859-1

 

http://www.verisign.com/press/2000/roaming.html

 

"VeriSign's revolutionary technology allows an end-user to securely 
store digital certificates and/or any other type of data, such as 
financial information or an online patient record, on distributed 
network servers operated by multiple trusted service providers. This 
technology enables portability of digital certificates, providing 
convenience for users to access and download their certificates and 
private keys for online authentication. It also enables the generation 
of binding digital signatures for conducting high-value e-commerce 
transactions, regardless of whether users are accessing the Internet 
from work, home, or another location such as an Internet kiosk. Digital 
certificates are electronic credentials that identify parties online, 
enabling encrypted communications and legally binding, valid digital 
signatures. 
"
 
-----Original Message-----
From: Richard Levitte [mailto:[e-mail]]
Sent: Thursday, July 20, 2000 11:24 AM
To: Anders Rundgren
Cc: Peter Lipp; [e-mail]; [e-mail]
Subject: Re: Signing what you don't understand


Anders Rundgren wrote:

> Peter,
>
> >> Several leading PKI vendors have implemented systems where the private
key
> >> is held on a central Web server and then downloaded at run time to a
web
> >> browser.  Are you saying that signatures created using these keys are
> >> invalid?
> >Are you sure? Could you provide a reference? I doubt that strongly...
> >
> >Peter
>
> I think this is one...
>
> http://www.arcot.com/products/webfort.html

I think not, at least from reading the papers "Protecting Digital
Identities" and
"Protecting Your Private Key".  All they say is that they've invented some
kind
of key database ("key wallet" to use their term) that is more secure than
what
comes with for example MSIE and Netscape Communicator...

Personally, if I was confronted with a CA that wanted to create my private
key
for me, and store it centrally to boot, I'd go somewhere else.  Very fast.
It
contradicts anything even remotely close to being called "secure".

--
Richard Levitte   !!! New cell phone number !!!
[e-mail]

/* You might enjoy viewing the complete vCard */



Received: from mta6.snfc21.pbi.net (mta6.snfc21.pbi.net [206.13.28.240]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id TAA24594 for <[e-mail]>; Thu, 20 Jul 2000 19:08:38 -0700 (PDT)
Received: from [192.168.1.7] ([208.233.228.110]) by mta6.snfc21.pbi.net (Sun Internet Mail Server sims.3.5.2000.01.05.12.18.p9) with ESMTP id <[e-mail]> for [e-mail]; Thu, 20 Jul 2000 19:10:27 -0700 (PDT)
Date: Thu, 20 Jul 2000 19:10:55 -0700
From: Aram Perez <[e-mail]>
Subject: Re: A Real Rationale for Dedicated Keys
In-reply-to: <[e-mail]>
To: [e-mail]
Message-id: <[e-mail]>
MIME-version: 1.0
Content-type: text/plain; charset="US-ASCII"
Content-transfer-encoding: 7bit
User-Agent: Microsoft-Outlook-Express-Macintosh-Edition/5.02.2022

Hi Tony B.,

> At 10:04 AM 7/21/00 +1000, Simon McMahon wrote:
>>> 
>>> Could you tell me what has NR (Non-Repudation) to do with CA control key
>>> generation.
>>> 
>> By "CA controlled key generation" I mean that the CA specifies minimum
>> standards and one option of the CA may be to do the key gen itself. The CA
>> should verify that the minimum standards are being followed if it specifies
>> any.
> 
> Agreed!
> 
>> Non-repudiation requires (at least) that the private key does not get
>> exposed or used by someone else without the owner knowing it. That means
>> that how the private key is used and how it is stored when not in use is
>> very relevant to NR. CAs can (and should) insist that key pairs are
>> generated and the private part is stored to some minimum standard before
>> they certify the public part.
> 
> Agreed!

Without the owner physically showing up, how can a CA know whether or not a
key pair was "generated and the private part is stored to some minimum
standard"?

Regards,
Aram Perez

[snip]



Received: from poptop.llnl.gov (poptop.llnl.gov [128.115.41.70]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id SAA23558 for <[e-mail]>; Thu, 20 Jul 2000 18:51:38 -0700 (PDT)
Received: from catalyst (catalyst.llnl.gov [128.115.222.68]) by poptop.llnl.gov (8.8.8/LLNL-3.0.2/pop.llnl.gov-5.1) with ESMTP id SAA25128; Thu, 20 Jul 2000 18:52:26 -0700 (PDT)
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.2 
Date: Thu, 20 Jul 2000 19:00:14 -0700
To: "Simon McMahon" <[e-mail]>, "Jean Abraham" <[e-mail]>, <[e-mail]>
From: Tony Bartoletti <[e-mail]>
Subject: Re: A Real Rationale for Dedicated Keys
In-Reply-To: <025601bff2b4$e1d7e200$[e-mail]>
References: <[e-mail]> <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed

At 11:41 AM 7/21/00 +1000, Simon McMahon wrote:
>I am are not saying "no" to multi-certification. Just "no" to its use as a
>repudiation defense. Appropriate CA policy can make it harder for the
>dishonest user to make repudiation claims based on being "fooled". If the
>user has declared that they will not multi-certify a NR=1 key down to NR=0,
>then goes and does it anyway their repudiation claim is going to look pretty
>weak.

OK, that is a good point.  Now, I set my mind to thinking of how
the (bad) user might argue that the policy was not conveyed to them,
and wonder how to "bind" the user's "expression of understanding"
into the certificate.

Granted, the user/subscriber is "duty-bound" to be aware of policy,
but in most instances (e.g., detailed credit card agreements) they
are not, and the laws are usually crafted to keep the foolish from
hurting themselves too badly.  The protocol for applying for and
receiving a (hypothetical) NR-certificate, especially through an
electronic transaction, will need to be both involved and rigorous,
in order to thwart a claim that "the policy wasn't obvious" or
"my screen displayed no policy".

___tony___

Tony Bartoletti 925-422-3881 <[e-mail]>
Information Operations, Warfare and Assurance Center
Lawrence Livermore National Laboratory
Livermore, CA 94551-9900



Received: from mta5.snfc21.pbi.net (mta5.snfc21.pbi.net [206.13.28.241]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id SAA22853 for <[e-mail]>; Thu, 20 Jul 2000 18:46:51 -0700 (PDT)
Received: from [192.168.1.7] ([208.233.228.110]) by mta5.snfc21.pbi.net (Sun Internet Mail Server sims.3.5.2000.01.05.12.18.p9) with ESMTP id <[e-mail]> for [e-mail]; Thu, 20 Jul 2000 18:38:47 -0700 (PDT)
Date: Thu, 20 Jul 2000 18:38:08 -0700
From: Aram Perez <[e-mail]>
Subject: Re: Signing what you don't understand
In-reply-to: <v0422080db59d2d88f4ad@[171.78.30.107]>
To: [e-mail]
Message-id: <[e-mail]>
MIME-version: 1.0
Content-type: text/plain; charset="US-ASCII"
Content-transfer-encoding: 7bit
User-Agent: Microsoft-Outlook-Express-Macintosh-Edition/5.02.2022

Hi Steve K.,

> When we check a signature for NR, and significant time has elapsed
> since the signature was applied, then different rules must be
> employed.

How do you know how much "time has elapsed since the signature was applied"?
I am not aware of any standard that mandates the time of the signature.
S/MIME/PKCS#7 has provision for the signature time, but they don't mandate
it.

Regards,
Aram Perez



Received: from diablo.OntheNet.com.au (diablo.OntheNet.com.au [203.10.89.2]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id SAA20957 for <[e-mail]>; Thu, 20 Jul 2000 18:30:44 -0700 (PDT)
Received: from msimon (pc3.eracom.com.au [203.144.16.147]) by diablo.OntheNet.com.au (8.9.3/8.9.3) with SMTP id LAA33093; Fri, 21 Jul 2000 11:33:08 +1000 (EST)
Message-ID: <025601bff2b4$e1d7e200$[e-mail]>
From: "Simon McMahon" <[e-mail]>
To: "Jean Abraham" <[e-mail]>, <[e-mail]>, "Tony Bartoletti" <[e-mail]>
References: <[e-mail]> <[e-mail]>
Subject: Re: A Real Rationale for Dedicated Keys
Date: Fri, 21 Jul 2000 11:41:31 +1000
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.00.2314.1300
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300

>
> >I know of one commercial CA that only certified public keys for key pairs
> >that it (the CA) generated. Their rationale was that they did not want
the
> >risk of certifying a dodgy key pair because of the risk of bad publicity
> >undermining their reputation as a CA. The generated private key was
> >transfered securely to the client. They wanted to take the next step and
> >start storing the private key directly onto smart cards.
>
> Some reservations here!  I would be wary of a process that actually
> allows the "key-generating operator" to learn the value of the secret.
>
CA's have internal policies and procedures to prevent that and they have
good reason to follow them too since they are in the business of selling
trust.

> If there were ways to guarantee that the secret key were actually
generated
> "in the card", (and could not be extracted, of course) I would feel better
> about such a process.
>
Me too, but if the CA I have to use (and everybody else uses) does it their
way I have to accept it or not participate.

> But, this does not address the issue of the dishonest user who would
> have the corresponding public key "certified for authentication, NR=0",
> use it for signing email receipts, and then try to repudiate a contract
> by arguing they were fooled into signing it with their NR=0 usage.
>
> I don't think "Just Say No" to key multi-certification will work.
>
> What will?
>
As long as the dishonest user can be made accountable for their actions you
should have a workable solution. You can not prevent dishonesty, only raise
the cost for dishonest behaviour.

I am are not saying "no" to multi-certification. Just "no" to its use as a
repudiation defense. Appropriate CA policy can make it harder for the
dishonest user to make repudiation claims based on being "fooled". If the
user has declared that they will not multi-certify a NR=1 key down to NR=0,
then goes and does it anyway their repudiation claim is going to look pretty
weak.

Regards,

Simon McMahon
ERACOM Pty. Ltd.




Received: from poptop.llnl.gov (poptop.llnl.gov [128.115.41.70]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id SAA17913 for <[e-mail]>; Thu, 20 Jul 2000 18:08:35 -0700 (PDT)
Received: from catalyst (catalyst.llnl.gov [128.115.222.68]) by poptop.llnl.gov (8.8.8/LLNL-3.0.2/pop.llnl.gov-5.1) with ESMTP id SAA15428; Thu, 20 Jul 2000 18:10:41 -0700 (PDT)
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.2 
Date: Thu, 20 Jul 2000 18:18:28 -0700
To: Stephen Kent <[e-mail]>, Steve Hanna <[e-mail]>
From: Tony Bartoletti <[e-mail]>
Subject: Re: Reverse paths
Cc: [e-mail]
In-Reply-To: <v0422080bb59d27c098db@[171.78.30.107]>
References: <[e-mail]> <[e-mail]> <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed

At 06:05 PM 7/20/00 -0400, Stephen Kent wrote:
>Steve,
>
><snip>
>
>>As to how you can display the network of trust in a mesh topology, X.500 
>>DNs provide a nice hierarchy.
>>Certificates are directional arcs between nodes in the tree. Trust 
>>anchors can be displayed as arcs
>>from the RP to the trusted party (in a different color, if you like).
>
>Experience with user behavior says that displaying cert paths is almost 
>worthless.  Almost nobody will view them, and few would be able to 
>understand the implications of such paths if they did view them.
>
><snip>

Actually displaying the mesh to users, I hope, would not be the issue.

Rather, given the mesh can be uniquely represented in "memory", can
one write software that can reply accurately to queries of the form
"Is there a path from A to B that satisfies my set of constraints?"

And would the behavior of such a tool become intractably slow (as it
certainly must on a general graph with many nodes, and most painfully
if each "satisfies constraints" requires a net-fetch from a directory.)

___tony___


Tony Bartoletti 925-422-3881 <[e-mail]>
Information Operations, Warfare and Assurance Center
Lawrence Livermore National Laboratory
Livermore, CA 94551-9900



Received: from poptop.llnl.gov (poptop.llnl.gov [128.115.41.70]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id RAA14369 for <[e-mail]>; Thu, 20 Jul 2000 17:27:25 -0700 (PDT)
Received: from catalyst (catalyst.llnl.gov [128.115.222.68]) by poptop.llnl.gov (8.8.8/LLNL-3.0.2/pop.llnl.gov-5.1) with ESMTP id RAA00049; Thu, 20 Jul 2000 17:28:55 -0700 (PDT)
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.2 
Date: Thu, 20 Jul 2000 17:36:42 -0700
To: "Simon McMahon" <[e-mail]>, "Jean Abraham" <[e-mail]>, <[e-mail]>
From: Tony Bartoletti <[e-mail]>
Subject: Re: A Real Rationale for Dedicated Keys
In-Reply-To: <01d201bff2a7$51738a50$[e-mail]>
References: <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed

At 10:04 AM 7/21/00 +1000, Simon McMahon wrote:
> >
> > Could you tell me what has NR (Non-Repudation) to do with CA control key
> > generation.
> >
>By "CA controlled key generation" I mean that the CA specifies minimum
>standards and one option of the CA may be to do the key gen itself. The CA
>should verify that the minimum standards are being followed if it specifies
>any.

Agreed!

>Non-repudiation requires (at least) that the private key does not get
>exposed or used by someone else without the owner knowing it. That means
>that how the private key is used and how it is stored when not in use is
>very relevant to NR. CAs can (and should) insist that key pairs are
>generated and the private part is stored to some minimum standard before
>they certify the public part.

Agreed!

>As a merchant I would be more inclined to trust NR signatures verified by
>certs from a CA that operated this way than from a CA that only checked the
>key owner's identity.

Agreed!

>I know of one commercial CA that only certified public keys for key pairs
>that it (the CA) generated. Their rationale was that they did not want the
>risk of certifying a dodgy key pair because of the risk of bad publicity
>undermining their reputation as a CA. The generated private key was
>transfered securely to the client. They wanted to take the next step and
>start storing the private key directly onto smart cards.

Some reservations here!  I would be wary of a process that actually
allows the "key-generating operator" to learn the value of the secret.

If there were ways to guarantee that the secret key were actually generated
"in the card", (and could not be extracted, of course) I would feel better
about such a process.

But, this does not address the issue of the dishonest user who would
have the corresponding public key "certified for authentication, NR=0",
use it for signing email receipts, and then try to repudiate a contract
by arguing they were fooled into signing it with their NR=0 usage.

I don't think "Just Say No" to key multi-certification will work.

What will?

___tony___


Tony Bartoletti 925-422-3881 <[e-mail]>
Information Operations, Warfare and Assurance Center
Lawrence Livermore National Laboratory
Livermore, CA 94551-9900



Received: from diablo.OntheNet.com.au (diablo.OntheNet.com.au [203.10.89.2]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id RAA14059 for <[e-mail]>; Thu, 20 Jul 2000 17:17:29 -0700 (PDT)
Received: from msimon (pc3.eracom.com.au [203.144.16.147]) by diablo.OntheNet.com.au (8.9.3/8.9.3) with SMTP id KAA18384; Fri, 21 Jul 2000 10:19:57 +1000 (EST)
Message-ID: <01fe01bff2aa$a5eba830$[e-mail]>
From: "Simon McMahon" <[e-mail]>
To: <[e-mail]>
Cc: <[e-mail]>, "Tony Bartoletti" <[e-mail]>
References: <[e-mail]>
Subject: Re: A Real Rationale for Dedicated Keys
Date: Fri, 21 Jul 2000 10:28:21 +1000
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.00.2314.1300
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300

>
> > My point being, the key-owner is the primary point of
> > control in enforcing a "one-key, one-cert" personal regime.
> >
> The "key generator" is really the primary point of control and need not be
> the same as the "key owner" (the one who makes signatures). Some CAs
insist
> on having some control over key origin, key generation, or at least the
> equipment used to do it so that uncontrolled certifications and hackable
> private keys can be avoided. I would expect that all commercial CAs that
> generate certs intended for NR usage will have to control key generation.
>
> Does it really matter how many certificates there are for a public key as
> long as the one specifying NR relates to a private key that cannot be
> duplicated ? I dont see how multiple certs for a key is a threat to
> non-repudiation of signatures. Only private key exposure / duplication is.
>
> [Tom Gindin] The threat is that the subject could claim, as an attempt to
> repudiate, that he was using an ordinary authentication key, and he didn't
> know that it was for NR.  For this reason and similar ones, having
multiple
> certificates with conflicting key usages but the same key is surely bad
> practice - having multiple certificates with the same key usages and the
> same key from different issuers is much less so.  There is a converse
> threat, in that an untrustworthy CA could (in theory) issue certificates
> for users it has no relationship with, based on existing valid
> certificates, but with stronger key usage and an RP could claim reliance
on
> such certificates.  Then the CA goes out of operation and the RP claims
> non-repudiation.
>
I think reputable CAs will counter this threat by controlling key pair
generation and private key storage or by making subjects declare (backed up
with a handwritten signature) that the key they have presented for an NR
certificate will only ever be certified for NR use.

I dont think the concept of an "untrustworthy CA" is a realistic threat to
consider. Why would anyone trust certificates from an untrustworthy CA ?

> Regards,
>
> Simon McMahon.
> ERACOM Pty. Ltd.
>
>
>



Received: from prv-mail20.provo.novell.com (prv-mail20.provo.novell.com [137.65.81.122]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id RAA13760 for <[e-mail]>; Thu, 20 Jul 2000 17:08:35 -0700 (PDT)
From: [e-mail]
Message-Id: <[e-mail]>
Received: from INET-PRV-Message_Server by prv-mail20.provo.novell.com with Novell_GroupWise; Thu, 20 Jul 2000 18:10:23 -0600
Mime-Version: 1.0
Date: Thu, 20 Jul 2000 18:11:00 -0600
X-Mailer: Groupwise 5.5.3.1
Subject: Re: Signing what you don't understand
To: [e-mail]
Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="____VDCOGBZYLUKMFWUAOQMZ____"

--____VDCOGBZYLUKMFWUAOQMZ____
Content-Type: multipart/alternative; boundary="____XGVTDUZAZWKBBJMXHBFC____"


--____XGVTDUZAZWKBBJMXHBFC____
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: quoted-printable

Peter,

The Novell Certificate Server is included with every copy of NDS, and thus =
is potentially available to some 50 million users, plus or minus.  =
Although I certainly wouldn't claim that all of those customers are using =
our certificate server, they could, and for free, using servers running on =
NetWare, NT, and Solaris.=20

For a number of reasons, including a certain mistrust of both the physical =
 security, computer security, and  cryptographic security of existing =
browser and e-mail implementations, together with the requirement to do =
_something_ about business key recovery for encryption and mixed usage =
keys, we made the decision to generate such keys on the (normally more =
secure) server, and then download the keys securely to the browser or =
e-mail client for use.

I can hear the screams now -- "but the system administrator might have =
access to my keys in that case" -- and that is true, and deliberately so.  =
And by the way, at least in most corporate environments, the system =
administrator is also the guy who installed the browsers, configured the =
operating system, specified what roots are to be trusted, etc..  It's not =
that I trust systems administrators for everything under the sun, but you =
can hardly expect the secretaries, clerks, or even the General Counsel or =
CEO in most corporations to have a Ph.D. in computer science/cryptography =
AND have the time to do all of this stuff themselves.  And of course, if =
our certificate server doesn't meet their needs, they can go pay lots of =
money to someone else.  It's a free product -- if they don't like it, =
we'll cheerfully refund what they paid for it.

Having said that, there are a couple of caveats.  First, these keys are =
primarily used for authentication to corporate resources that are under =
the control of the system administrator in any case, and secondarily for =
use in encrypting internal e-mail, for which the company may choose to =
assert a business key recovery right and responsibility.

Secondly, in part due to my frustration in not having an agreed-upon =
definition for nonrepudiation, and in particular the semantic requirements =
as to what to do or not do when presented such a certificate, the Novell =
Certificate Server does not at this time create certs with the NR bit =
asserted. =20

Whatever the NR bit is finally determined to mean, it will almost =
certainly call for a higher level of trust than what is currently provided =
within existing browsers and e-mail packages, which at present is our =
primary market segment.

I hope that clarifies the issue somewhat.

Regards,

Bob






Robert R. Jueneman
Consultant Engineer, PKI/Security Architect

Novell, Inc. -- the leading provider of Net services software
1800 South Novell Place
Provo, UT 84606
www.novell.com

[e-mail]
1-801-861-7387

DISCLAIMER:
  If this message (with or without attached documents) is digitally =
signed, and/or if certificates are attached, the intended purpose is to=20
   (1) Ensure that e-mail came from the apparent sender
   (2) Protect e-mail from tampering
   (3) Ensure that the content of e-mail sent to me and encrypted in  my =
dual-use key cannot be viewed by others.
  It is explicitly NOT the intent of any such signed message or document =
to represent any type or form of legally binding contract or other =
representation, and any such interpretation should not be considered =
commercially reasonable and will be repudiated, notwithstanding any =
wording or implications to the opposite effect in the text of the message =
itself.

>>> Ronald A Martin <[e-mail]> 07/20/00 02:20PM >>>
Another...

http://www.rsasecurity.com/products/keon/advancedpkiservices.html

    Ron

Anders Rundgren wrote:

> Peter,
>
> >> Several leading PKI vendors have implemented systems where the =
private key
> >> is held on a central Web server and then downloaded at run time to a =
web
> >> browser.  Are you saying that signatures created using these keys are
> >> invalid?
> >Are you sure? Could you provide a reference? I doubt that strongly...
> >
> >Peter
>
> I think this is one...
>
> http://www.arcot.com/products/webfort.html
>
> Anders

--____XGVTDUZAZWKBBJMXHBFC____
Content-Type: multipart/related; boundary="____LDRLFIKOSBKEMECJKSLQ____"


--____LDRLFIKOSBKEMECJKSLQ____
Content-Type: text/html; charset=iso-8859-1
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META content=3D"text/html; charset=3Diso-8859-1" http-equiv=3DContent-Type=
>
<META content=3D"MSHTML 5.00.2614.3401" name=3DGENERATOR></HEAD>
<BODY style=3D"FONT: 8pt MS Sans Serif; MARGIN-LEFT: 2px; MARGIN-TOP: =
2px">
<DIV><FONT size=3D1>Peter,</FONT></DIV>
<DIV><FONT size=3D1></FONT>&nbsp;</DIV>
<DIV><FONT size=3D1>The Novell Certificate Server is included with every =
copy of=20
NDS, and thus is potentially available to some 50 million users, plus =
or=20
minus.&nbsp; Although&nbsp;I certainly wouldn't claim that all of those=20
customers are using our certificate server, they could, and for free, =
using=20
servers running on NetWare, NT, and Solaris. </FONT></DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT size=3D1>For a number of reasons, including a certain mistrust =
of both=20
the physical&nbsp; security, computer security, and&nbsp; cryptographic =
security=20
of existing browser and e-mail implementations, together with the =
requirement to=20
do _something_ about business key recovery for encryption and mixed usage =
keys,=20
we made the decision to generate such keys on the (normally more secure) =
server,=20
and then download the keys securely to the browser or e-mail client for=20
use.</FONT></DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT size=3D1>I can hear the screams now -- "but the system =
administrator=20
might have access to my keys in that case" -- and that is true, and =
deliberately=20
so.&nbsp; And by the way, at least in most corporate environments, the =
system=20
administrator is also the guy who installed the browsers, configured =
the=20
operating system, specified what roots are to be trusted, etc..&nbsp; It's =
not=20
that I trust systems administrators for everything under the sun, but you =
can=20
hardly expect the secretaries, clerks, or even the General Counsel or =
CEO=20
in&nbsp;most corporations to have a Ph.D. in computer science/cryptography =
AND=20
have the time to do all of this stuff themselves.&nbsp; And of course, if =
our=20
certificate server doesn't meet their needs, they can go pay lots of money =
to=20
someone else.&nbsp; It's a free product -- if they don't like it, we'll=20
cheerfully refund what they paid for it.</FONT></DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT size=3D1>Having said that, there are a couple of caveats.&nbsp; =
First,=20
these keys are primarily used for authentication to corporate resources =
that are=20
under the control of the system administrator in any case, and secondarily =
for=20
use in encrypting internal e-mail, for which the company may choose to =
assert a=20
business key recovery right and responsibility.</FONT></DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT size=3D1>Secondly, in part due to my frustration in not having =
an=20
agreed-upon definition for nonrepudiation, and in particular the =
semantic=20
requirements as to what to do or not do when presented such a certificate, =
the=20
Novell Certificate Server does not at this time create certs with the NR =
bit=20
asserted.&nbsp; </FONT></DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT size=3D1>Whatever the NR bit is finally determined to mean, it =
will=20
almost certainly call for a higher level of trust than what is currently=20=

provided within existing browsers and e-mail packages, which at present is =
our=20
primary market segment.</FONT></DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT size=3D1>I hope that clarifies the issue somewhat.</FONT></DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT size=3D1>Regards,</FONT></DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT size=3D1>Bob</FONT></DIV>
<DIV>&nbsp;</DIV>
<DIV>&nbsp;</DIV>
<DIV>&nbsp;</DIV>
<DIV>&nbsp;</DIV>
<DIV>&nbsp;</DIV>
<DIV>&nbsp;</DIV>
<DIV>Robert R. Jueneman<BR>Consultant Engineer, PKI/Security Architect</DIV=
>
<DIV>&nbsp;</DIV>
<DIV>Novell, Inc. -- the leading provider of Net services software<BR>1800 =
South=20
Novell Place<BR>Provo, UT 84606<BR><A=20
href=3D"http://www.novell.com">www.novell.com</A></DIV>
<DIV>&nbsp;</DIV>
<DIV><A=20
href=3D"mailto:[e-mail]">[e-mail]</A><BR>1-801-861-=
7387</DIV>
<DIV>&nbsp;</DIV>
<DIV>DISCLAIMER:<BR>&nbsp; If this message (with or without attached =
documents)=20
is digitally signed, and/or if certificates are attached, the intended =
purpose=20
is to <BR>&nbsp;&nbsp; (1) Ensure that e-mail came from the apparent=20
sender<BR>&nbsp;&nbsp; (2) Protect e-mail from tampering<BR>&nbsp;&nbsp; =
(3)=20
Ensure that the content of e-mail sent to me and encrypted in&nbsp; my =
dual-use=20
key cannot be viewed by others.<BR>&nbsp; It is explicitly NOT the intent =
of any=20
such signed message or document to represent any type or form of legally =
binding=20
contract or other representation, and any such interpretation should not =
be=20
considered commercially reasonable and will be repudiated, notwithstanding =
any=20
wording or implications to the opposite effect in the text of the =
message=20
itself.<BR><BR>&gt;&gt;&gt; Ronald A Martin &lt;[e-mail]&gt;=
=20
07/20/00 02:20PM &gt;&gt;&gt;<BR>Another...<BR><BR><A=20
href=3D"http://www.rsasecurity.com/products/keon/advancedpkiservices.html">=
http://www.rsasecurity.com/products/keon/advancedpkiservices.html</A><BR><B=
R>&nbsp;&nbsp;&nbsp;=20
Ron<BR><BR>Anders Rundgren wrote:<BR><BR>&gt; Peter,<BR>&gt;<BR>&gt; =
&gt;&gt;=20
Several leading PKI vendors have implemented systems where the private=20
key<BR>&gt; &gt;&gt; is held on a central Web server and then downloaded =
at run=20
time to a web<BR>&gt; &gt;&gt; browser.&nbsp; Are you saying that =
signatures=20
created using these keys are<BR>&gt; &gt;&gt; invalid?<BR>&gt; &gt;Are you =
sure?=20
Could you provide a reference? I doubt that strongly...<BR>&gt; &gt;<BR>&gt=
;=20
&gt;Peter<BR>&gt;<BR>&gt; I think this is one...<BR>&gt;<BR>&gt; <A=20
href=3D"http://www.arcot.com/products/webfort.html">http://www.arcot.com/pr=
oducts/webfort.html</A><BR>&gt;<BR>&gt;=20
Anders<BR><BR></DIV></BODY></HTML>

--____LDRLFIKOSBKEMECJKSLQ____--

--____XGVTDUZAZWKBBJMXHBFC____--

--____VDCOGBZYLUKMFWUAOQMZ____
Content-Type: application/x-pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"
CONTENT-DESCRIPTION: S/MIME Cryptographic Signature

MIIMlwYJKoZIhvcNAQcCoIIMiDCCDIQCAQExCzAJBgUrDgMCGgUAMAsGCSqGSIb3DQEHAaCCCh8w
ggUIMIID8KADAgECAhoCFAAAABQ0/V7yZC4krZCad8s8I/9yAgID2jANBgkqhkiG9w0BAQUFADAy
MRswGQYDVQQLExJOb3ZlbGwgRW1wbG95ZWUgQ0ExEzARBgNVBAoUCk5PVkVMTF9JTkMwHhcNOTkx
MDA5MTcyMDAwWhcNMDkxMDA5MTcyMDAwWjAyMRswGQYDVQQLExJOb3ZlbGwgRW1wbG95ZWUgQ0Ex
EzARBgNVBAoUCk5PVkVMTF9JTkMwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDFXNJ5
6dllO0vfXHFpTJKFXsPp4/ODFGguxqQOt/gRB+jEILRth9kko6r1DRMVtdJ3vYFxujArU9E1dEUL
mf12vQOHveLyiu3+2QWFoWxGMRzdeziJkB5lk8noS3yhCCBoEOh+8UZ8xbeXRiBE9Trn4e5mojH8
+ao7khHpd5tw2MbfDgEh7ngp0jg7ZvLUz/UW4ki8em35g3KC3UFdUO/q+V/n2NUqnpgUH2bkpoib
kSMjwAfVn50B1PpK/MJMGvtYGiVtTvq6VKDR+wa8WC7uVEQiPbEiH8KOKd9fFBCsZvd12fbfUeNI
FmrnNkk5Ob/p/GRKrppExWbGueulpBExAgMBAAGjggIOMIICCjAKBgNVHQ4EAwQBATAMBgNVHSME
BTADgAEBMA8GA1UdEwEBAAQFMAMBAf8wDgYDVR0PAQEABAQDAgEGMIIBywYLYIZIAYb4NwEJBAEB
AQAEggG3MIIBswQCAQABAf8THU5vdmVsbCBTZWN1cml0eSBBdHRyaWJ1dGUodG0pFkNodHRwOi8v
ZGV2ZWxvcGVyLm5vdmVsbC5jb20vcmVwb3NpdG9yeS9hdHRyaWJ1dGVzL2NlcnRhdHRyc192MTAu
aHRtMIIBRKAaAQEAMAgwBgIBAQIBRjAIMAYCAQECAQoCAWmhGgEBADAIMAYCAQECAUYwCDAGAgEB
AgEKAgFpogYCARgBAf+jggEAoFoCAQICAgD/AgEAAw0AgAAAAAAAAAAAAAAAAwkAgAAAAAAAAAAw
GDAQAgEAAgh//////////wEBAAIEBvDfSDAYMBACAQACCH//////////AQEAAgQG8N9IMFKhUgIB
AgICAP8CAQADDQBAAAAAAAAAAAAAAAADCQBAAAAAAAAAADAVMBACAQACCH//////////AQEAAgEU
MBUwEAIBAAIIf/////////8BAQACARSiTjBMAgECAgIA/wIBAAMNAID//////////////wMJAID/
////////MBIwEAIBAAIIf/////////8BAf8wEjAQAgEAAgh//////////wEB/zANBgkqhkiG9w0B
AQUFAAOCAQEAaiESm7ALSKkCI86jYyeRPzNazTY4f0GepqTPidwM546hDZKxkFfKjop9nhZDEg0S
xj69kL7mlqowVlU6dgoEPgqwPglP0jBO60EyzqjorrVbnpuSNUVoY+6OyymyrdNrx2DGTBTqsI/i
urILrt1V2b8ioTAWSp9lHr5LxAOxQgTeNMMI/b5B0sTlAlwBNbn2K1b11EfYdxSmkQZfsQVCmfKl
8y2xqF7X2+W45Zgdev0/JQxCXlRVoGEMbshs7V5AECg9qezn9dTyfCX1nS+YoLkJf0khv2MrcfrN
1SG2EGusV2NVDxCdXFuLhyWxwAxVLoI5LNIMLFa4P8vAinCxJTCCBQ8wggP3oAMCAQICGgIUAAAA
FDT9XvJkLiStkJp3yzwj/3ICAgTqMA0GCSqGSIb3DQEBBQUAMDIxGzAZBgNVBAsTEk5vdmVsbCBF
bXBsb3llZSBDQTETMBEGA1UEChQKTk9WRUxMX0lOQzAeFw05OTEwMDkxODE4MDBaFw0wMTEwMDkx
ODE4MDBaMEIxEjAQBgNVBAMTCUJKdWVuZW1hbjENMAsGA1UECxMETlNSRDEMMAoGA1UECxMDUFJW
MQ8wDQYDVQQKEwZOb3ZlbGwwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQC3eHuGT669
GWzGuMYSIvezmPdEFF0nbdlhqv0KwebG5WHi4TiLyX7s8l6+0CQRAF9rFQhEdh7I2lti9hgrNOjo
4SZvxU0PstQcN9ad6usXMzHBa36Xj31kJUhguKEKpCaUYGmWPcq6ehLcuxTv0nuq1QvAGTIqjCT5
y/tpSwo2nXpb9UXOEpZg8CmL6OTKj44cAmHzPk6dElXxF7SjnhkNOYNvwgs/Afa+7iOX0Lv6vTYJ
eaz1eklKMSoJf5mZ/EZfJjUkf5jDRdIb5Rog2/HWMEsBvP2vgiBrV1nwVFGBkpfs1qwq0A7h3UdG
bm8NlzgFMs2lltqtONbGiZK5UMoDAgMBAAGjggIFMIICATAMBgNVHSMEBTADgAEBMCIGA1UdEQEB
AAQYMBaBFEJKVUVORU1BTkBub3ZlbGwuY29tMIIBywYLYIZIAYb4NwEJBAEBAQAEggG3MIIBswQC
AQABAf8THU5vdmVsbCBTZWN1cml0eSBBdHRyaWJ1dGUodG0pFkNodHRwOi8vZGV2ZWxvcGVyLm5v
dmVsbC5jb20vcmVwb3NpdG9yeS9hdHRyaWJ1dGVzL2NlcnRhdHRyc192MTAuaHRtMIIBRKAaAQEA
MAgwBgIBAQIBRjAIMAYCAQECAQoCAWmhGgEBADAIMAYCAQECAUYwCDAGAgEBAgEKAgFpogYCARQB
Af+jggEAoFoCAQICAgD/AgEAAw0AgAAAAAAAAAAAAAAAAwkAgAAAAAAAAAAwGDAQAgEAAgh/////
/////wEBAAIEBvDfSDAYMBACAQACCH//////////AQEAAgQG8N9IMFKhUgIBAgICAP8CAQADDQBA
AAAAAAAAAAAAAAADCQBAAAAAAAAAADAVMBACAQACCH//////////AQEAAgEUMBUwEAIBAAIIf///
//////8BAQACARSiTjBMAgECAgEAAgIA/wMNAIAAAAAAAAAAAAAAAAMJAIAAAAAAAAAAMBIwEAIB
AAIIf/////////8BAQAwEjAQAgEAAgh//////////wEBADANBgkqhkiG9w0BAQUFAAOCAQEAiEId
iox84BfJlz8suOJdTEwkuJsT1AbsLBwWzEpwfBS5FRGglOyKwlj8Fq+bFmgnBX//wbW4gjutgAEu
w8fXGUaQ9d2qwUn06Ta8C8AeBr7XmxrHe1Hs4YBQfqtVpdbZDasgeOhJhKSAMmIbv7jajwI9oZ93
aS5w/ArkTGFm+hpexZsSHtTjcKFAQ977M+QwbnilmnBfPYiQk+y/uGcAeJqJRnmzbfrbmzlpsyqg
yJENC+zD4O5tq9Gn53pHpG1EnjX/ZN3+jM0HKIc/rDuQ+yQ4e3LReenrRbmAoDlD5krF2sfFXphb
P86HUMcytbnXDgBbtKYdVtH/kDDMHCMQBTGCAkAwggI8AgEBMFAwMjEbMBkGA1UECxMSTm92ZWxs
IEVtcGxveWVlIENBMRMwEQYDVQQKFApOT1ZFTExfSU5DAhoCFAAAABQ0/V7yZC4krZCad8s8I/9y
AgIE6jAJBgUrDgMCGgUAoIHGMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkF
MQ8XDTAwMDcyMDE4MTEzMFowIwYJKoZIhvcNAQkEMRYEFNg9QFD+hWGYdRFTo0XcDyhW+kbPMGcG
CSqGSIb3DQEJDzFaMFgwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwICAgCAMAoGCCqGSIb3DQMEMA0G
CCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMAcGBSsOAwIaMA0GCSqGSIb3DQEB
AQUABIIBAGi0Vn/PNo1Bg7mCWsu7Xad/8BLvsTyfInUTNx0G6oKnKtCcTJTYRQjAueg7fyJ81Vzo
r3K2jf8KooOQe3qFheVuPuSfoo/XFVrNHWdOOYHLf059ADnfmTajF/zP6HsIVVoCS1R9UPX1vKfd
4qjYpUirXIM/Gm7mQQCqgqs/CgcuhrDL76ROfXecB2/Cz+wTf1QyB0kBuQvK+67n7r4F++7ltEOf
lRpFULabARw9pl53sMt71P0CfnpQlghathr7gqgjitiYYBOMIgMQ3z97y8T9KTblH6+WG2vBDfKl
1lNE4sBpfUuU8J/CUt1QyUYCw7hqJ6gCvdeyHmxa37Ivs6o=

--____VDCOGBZYLUKMFWUAOQMZ____--


Received: from diablo.OntheNet.com.au (diablo.OntheNet.com.au [203.10.89.2]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id QAA13241 for <[e-mail]>; Thu, 20 Jul 2000 16:53:38 -0700 (PDT)
Received: from msimon (pc3.eracom.com.au [203.144.16.147]) by diablo.OntheNet.com.au (8.9.3/8.9.3) with SMTP id JAA13803; Fri, 21 Jul 2000 09:56:07 +1000 (EST)
Message-ID: <01d201bff2a7$51738a50$[e-mail]>
From: "Simon McMahon" <[e-mail]>
To: "Jean Abraham" <[e-mail]>, <[e-mail]>, "Tony Bartoletti" <[e-mail]>
References: <[e-mail]>
Subject: Re: A Real Rationale for Dedicated Keys
Date: Fri, 21 Jul 2000 10:04:30 +1000
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.00.2314.1300
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300

>
> Could you tell me what has NR (Non-Repudation) to do with CA control key
> generation.
>
By "CA controlled key generation" I mean that the CA specifies minimum
standards and one option of the CA may be to do the key gen itself. The CA
should verify that the minimum standards are being followed if it specifies
any.

Non-repudiation requires (at least) that the private key does not get
exposed or used by someone else without the owner knowing it. That means
that how the private key is used and how it is stored when not in use is
very relevant to NR. CAs can (and should) insist that key pairs are
generated and the private part is stored to some minimum standard before
they certify the public part.

As a merchant I would be more inclined to trust NR signatures verified by
certs from a CA that operated this way than from a CA that only checked the
key owner's identity.

I know of one commercial CA that only certified public keys for key pairs
that it (the CA) generated. Their rationale was that they did not want the
risk of certifying a dodgy key pair because of the risk of bad publicity
undermining their reputation as a CA. The generated private key was
transfered securely to the client. They wanted to take the next step and
start storing the private key directly onto smart cards.

Regards,

Simon




Received: from poptop.llnl.gov (poptop.llnl.gov [128.115.41.70]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id QAA13208 for <[e-mail]>; Thu, 20 Jul 2000 16:52:58 -0700 (PDT)
Received: from catalyst (catalyst.llnl.gov [128.115.222.68]) by poptop.llnl.gov (8.8.8/LLNL-3.0.2/pop.llnl.gov-5.1) with ESMTP id QAA25138; Thu, 20 Jul 2000 16:12:59 -0700 (PDT)
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.2 
Date: Thu, 20 Jul 2000 16:20:47 -0700
To: Stephen Kent <[e-mail]>
From: Tony Bartoletti <[e-mail]>
Subject: Re: A Real Rationale for Dedicated Keys
Cc: [e-mail]
In-Reply-To: <v04220809b59d230d7e55@[171.78.30.107]>
References: <[e-mail]> <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed

At 05:48 PM 7/20/00 -0400, Stephen Kent wrote:
>Tony,
>
>You cited the ability of a user (or someone else) to bind a public key 
>into multiple certs, some with and some without the NR bit enabled as a 
>reason that the NR bit is not useful for the purpose I stated.  I think I 
>pointed out in my response to John Wary why this line of reasoning is not 
>necessarily true. It would be a mistake for a user to have the same public 
>key in multiple certs, and anyone other than the user should not be able 
>to effect POP and get a CA to issue a cert.  Yes, a user could act in this 
>inappropriate fashion, in some instances, but then too a user could 
>undermine most of the safeguards that we envision through negligent conduct.

Steve,

I agree with the main points, and I worked from the assumption that
CAs will not certify without POP (certainly not NR without POP!).

Thus, if a user (wisely, naively, or unscrupulously) has an NR-key
"differently certified", it is largely under the user's control,
since they are the only ones that can satisfy POP.

So, my tack becomes "How best to work from this assumption?"

Bad as such a practice may be, I asked myself how close one could come
to making such a situation "workable", and the answer (to me) was a
protocol that forces a conscious selection of certificate be bound
into the transaction.  (I suppose they will always have the "Ooops,
I thought I selected the NR=0 cert that time, honest mistake...) but
the signed content would at least implicate a usage (and for NR and
the RP, more importantly, the strength of a DN-Person binding that
is commensurate with such a usage.)

To a Relying Party, the value of the NR bit on ANY certificate for a
given key (even where the same key may have been lightly certified
elsewhere) is that someone (who but the CA?) has gone to greater
lengths to ensure the "reasonableness" of the DN as a reliable
indicator of an identifiable party.  (Of what value an NR-cert
binding a key to the DN-equivalent of "someone@mailbox"?)

To my understanding, a re-certification of such a "strong" key
does not in itself weaken the established DN-Entity binding.

(It DOES allow a "lightweight CA" to leverage the hard work
of the diligent NR-certifying CA ... Is that an issue?)

It (NR-bit) may also be a declaration from the CA that the key
was generated in a secure device.  But all of this lends a degree
of value to ANY use of the key, EXCEPT for a use requiring some
measure of anonymity.  Fortunately, the user is self-motivated
to employ a distinct key for such purposes.

As far as this being a reason that the "NR-bit is not useful"
for the purpose you stated, I am not quite sure.  From your
response to John Wray, I can only suppose that this use centers
on the reduction of "added mechanisms" to support Non-Repudiation.

But I feel that "additional mechanisms" are required for such
a weighty use as legally binding signatures.

I really want to avoid people buying into the semantic that
"Valid Signature" plus "I found a certificate that says NR"
somehow equates to "signature was made with NR intent."
(Even binding a selected NR-cert into the signature is
insufficient, but moves us a step closer.)

There are really two motivations I consider:

1.  What can be done to help prevent a "criminal" user from
     perpetrating a fraud.

2.  What can the legitimate user do to protect herself from
     misapplication by others.

If we agree that we cannot (easily) prevent a user from having
a key "multiply-certified", the goal must shift to how we might
best prevent the unscrupulous user from profiting by the practice.

My point about the privacy/anonymity issue is that the user has
legitimate control over this by applying different keys.

___tony___


Tony Bartoletti 925-422-3881 <[e-mail]>
Information Operations, Warfare and Assurance Center
Lawrence Livermore National Laboratory
Livermore, CA 94551-9900



Received: from po1.bbn.com (PO1.BBN.COM [192.1.50.38]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id PAA11913 for <[e-mail]>; Thu, 20 Jul 2000 15:37:42 -0700 (PDT)
Received: from [171.78.30.107] (fixed030-107.bbn.com [171.78.30.107] (may be forged)) by po1.bbn.com (8.9.1/8.9.1) with ESMTP id SAA04848; Thu, 20 Jul 2000 18:40:19 -0400 (EDT)
Mime-Version: 1.0
X-Sender: [e-mail]
Message-Id: <v0422080db59d2d88f4ad@[171.78.30.107]>
In-Reply-To: <[e-mail]>
References: <[e-mail]>
Date: Thu, 20 Jul 2000 18:38:28 -0400
To: [e-mail]
From: Stephen Kent <[e-mail]>
Subject: Re: Signing what you don't understand
Cc: [e-mail], <[e-mail]>
Content-Type: text/plain; charset="us-ascii" ; format="flowed"

John,

>Steve,
>
>  >>What other mechanisms would cover that case of my issuing CA going out of
>  >>business?  If a CA's assets (including its keys) are sold as part of a
>  >>bankruptcy process, I would think that trust in those keys would be
>fairly
>  >>quickly revoked by other CAs that might have cross-certified it.  In this
>  >>case, invalidityDate on those revocations would probably be set so that
>no
>  >>certificate that had been issued by the former CA's key would be trusted
>  >>(to prevent the keys' new owners from issuing new backdated
>certificates).
>  >>However, as a subscriber to the former CA, I don't see why my signatures
>  >>should suddenly become less trustworthy, if my key can be verified via
>  >>another path.
>  >
>  >A RP can be responsible for acquiring all the requisite evidence for
>  >later support of signed document validity, including time stamping
>  >this evidence. I think this addresses the scenario you described
>  >above.
>
>That addresses the case where the document is processed by the RP prior to
>my CA going out of business, but it doesn't help if trust in the CA has
>already been revoked at the time the RP tries to verify the signature.
>Note I'm not talking about NR here - In the scenario I'm concerned with,
>the RP will itself not trust my signature, even though it should be valid.
>In an e-mail environment, this may not matter too much, as the RP could
>simply ask the signer to re-send a freshly signed copy of the e-mail, but
>in a work-flow or EDI environment, where documents move through a system
>acquiring multiple counter-signatures over portions of the documents, it
>may be impractical to simply re-start the process.

I agree that in a more slowly moving processes you describe above the 
window for the CA vanishing is greater, but in practice I think it 
would be quite rare.  If it's quite rare, it's feasible to restart 
the process.

>It is possible for the signer to timestamp his signature, along with a
>complete certification path from some root CA, along with CRL- or
>OCSP-based liveness evidence for every certificate on that path.  This is,
>I think, what ESS terms a signer-generated ES-X.  But that doesn't help
>unless the RP directly trusts the signer's root CA.  If the RP doesn't
>trust the root that the signer chooses, then the timestamped chain is of
>little use to him, since it won't say anything about the certificates in
>the chain the RP constructs (although if a chain from one of the RP's
>trusted roots happens to "join up" with some fraction of the signer's
>timestamped chain, then the timestamp can be used as evidence of validity
>at signing time of the fraction of the chain below the intersection point).

In practice today (and maybe the right way in the long run anyway) 
there are not multiple choices for a root relative to a specific 
signer.  For example, if I operate in an organization context, my 
cert is issued by my org, period.  My org may not choose to be 
certified by any TTPs, or it may choose only one.  In such cases, an 
RP has a take it or leave it option.  In the physical world we often 
have this sort of credential situation.  If you don't trust the bank 
from which I got a letter of credit, we don't do business. If you 
don't trust D&B for a background check on a U.S. business, your 
options are severely limited.

>Even if the RP does trust the signer's root, though, it's not clear why the
>RP's software should believe a signature based on a certificate chain that
>contains revoked certificates (with invalidity dates that precede the
>signature date), even if it includes evidence that at the time of signature
>creation, those certificates had not yet been revoked.  Even if not
>rejected outright, such a signature should be treated as at best
>suspicious.

When we check a signature for NR, and significant time has elapsed 
since the signature was applied, then different rules must be 
employed.  After all, the certs may have expired and, unless we make 
use of the private key validity interval extension (which is not too 
common), we still consider the signature to be potentially valid. One 
might define this as an "archival signature validation" process, with 
different rules and additional inputs (e.g., TSA signed data ...).

Steve



Received: from po1.bbn.com (PO1.BBN.COM [192.1.50.38]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id PAA11104 for <[e-mail]>; Thu, 20 Jul 2000 15:10:18 -0700 (PDT)
Received: from [171.78.30.107] (fixed030-107.bbn.com [171.78.30.107] (may be forged)) by po1.bbn.com (8.9.1/8.9.1) with ESMTP id SAA02895; Thu, 20 Jul 2000 18:12:55 -0400 (EDT)
Mime-Version: 1.0
X-Sender: [e-mail]
Message-Id: <v0422080cb59d2878c417@[171.78.30.107]>
In-Reply-To:  <[e-mail]>
References:  <[e-mail]>
Date: Thu, 20 Jul 2000 18:14:23 -0400
To: Sharon Boeyen <[e-mail]>
From: Stephen Kent <[e-mail]>
Subject: RE: Reverse paths
Cc: [e-mail]
Content-Type: text/plain; charset="us-ascii" ; format="flowed"

Sharon,

><snip>
>
>It is my opinion that recent events, such as the US Federal Bridge CA
>activity
>have shown that a single global hierarchy does not work, that distributed
>trust
>models are, in fact necessary as well. Because of these events and because
>the
>issue was raised, not by me but by another vendor (Sean Mullan from Sun), I
>thought
>it was a reasonable recommendation to support now. Having said that, let me
>clarify
>what I meant. To answer your first question, no I don't mean to impose
>reverse in
>all contexts. Nor do I mean to impose bilateral cross-certification. Rather,
>I am
>suggesting mandating that, in addition to what PKIX says currently, a CA
>that issues a certificate to another CA (where the subject CA is NOT a
>subordinate CA to the issuing CA within a hierarchy), must place that
>certificate in the reverse element of the cross certificate pairs attribute
>of the its own directory entry. No impact within a hierarchy at all, no
>requirement that cross certification be bilateral. Sorry for the confusion
>and I hope this is a bit clearer. So I guess to summarize:


I think the Federal Bridge CA model is broken.  It is appropriate to 
use a bridge CA as a convenient means of distributing certificates 
between communities, to avoid the order N**2 cross certification 
problem.  CA-1 could go to the bridge CA to acquire the public key 
for CA-2, then import that key into CA-1's domain, by issuing a cross 
certificate from CA-1 to CA-2.  In this fashion CA-1 van impose the 
appropriate name constraints extension, appropriate  policy mapping 
constrains, even basic constraints on the depth of cert paths.  Then 
the existing processing methods we have should work, right?

If one tries to process a path via a bridge CA, then  one looses the 
ability to impose name constraints, and to apply selective policy 
mapping etc, because the bridge CA is in the path, getting in the way 
:-).  So, no, I am not persuaded by the suggestion that bridge CAs 
are the wave of the future.  I think they are ill conceived in their 
current use, but they could be rehabilitated!

<snip>

Steve



Received: from po1.bbn.com (PO1.BBN.COM [192.1.50.38]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id PAA10920 for <[e-mail]>; Thu, 20 Jul 2000 15:08:31 -0700 (PDT)
Received: from [171.78.30.107] (fixed030-107.bbn.com [171.78.30.107] (may be forged)) by po1.bbn.com (8.9.1/8.9.1) with ESMTP id SAA02763; Thu, 20 Jul 2000 18:11:05 -0400 (EDT)
Mime-Version: 1.0
X-Sender: [e-mail]
Message-Id: <v0422080bb59d27c098db@[171.78.30.107]>
In-Reply-To: <[e-mail]>
References: <[e-mail]> <[e-mail]>
Date: Thu, 20 Jul 2000 18:05:58 -0400
To: Steve Hanna <[e-mail]>
From: Stephen Kent <[e-mail]>
Subject: Re: Reverse paths
Cc: [e-mail]
Content-Type: text/plain; charset="us-ascii" ; format="flowed"

Steve,

<snip>

>As to how you can display the network of trust in a mesh topology, 
>X.500 DNs provide a nice hierarchy.
>Certificates are directional arcs between nodes in the tree. Trust 
>anchors can be displayed as arcs
>from the RP to the trusted party (in a different color, if you like).

Experience with user behavior says that displaying cert paths is 
almost worthless.  Almost nobody will view them, and few would be 
able to understand the implications of such paths if they did view 
them.

<snip>



Received: from po1.bbn.com (PO1.BBN.COM [192.1.50.38]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id PAA10906 for <[e-mail]>; Thu, 20 Jul 2000 15:08:30 -0700 (PDT)
Received: from [171.78.30.107] (fixed030-107.bbn.com [171.78.30.107] (may be forged)) by po1.bbn.com (8.9.1/8.9.1) with ESMTP id SAA02758; Thu, 20 Jul 2000 18:11:04 -0400 (EDT)
Mime-Version: 1.0
X-Sender: [e-mail]
Message-Id: <v0422080ab59d257e1108@[171.78.30.107]>
In-Reply-To: <[e-mail]>
References:  <[e-mail]> <v04220807b59baae71151@[128.33.238.44]> <[e-mail]>
Date: Thu, 20 Jul 2000 18:03:32 -0400
To: Steve Hanna <[e-mail]>
From: Stephen Kent <[e-mail]>
Subject: Re: Reverse paths
Cc: [e-mail]
Content-Type: text/plain; charset="us-ascii" ; format="flowed"

At 10:04 AM -0400 7/20/00, Steve Hanna wrote:
>Stephen Kent wrote:
>  > I am uncomfortable with the proposal that we mandate both elements,
>  > as this would seem to imply that every CA would have to engage in
>  > reverse path certificate generation in all contexts.  Did I
>  > misunderstand the implication?
>
>I'm not sure what you mean by "reverse path certificate generation". 
>This change would require that
>when a CA issues a cross certificate, they would have to place a 
>copy of it in their own directory
>entry (in the reverse element of a value of the crossCertificate 
>attribute). It would not require the
>generation of any additional certificates.

I though Sharon suggested that each CA entry would hold mandated 
pairs of cross certs, one forward and one back, for each CA it was 
being linked to. In today's mostly hierarchic environment, a CA 
issues a forward cert (using X.509 terminology) to CAs "below" it and 
is certified by CAs "above" it, but CAs do not usually generate the 
other, reverse certs, even though they are defined and a valid part 
of the X.509 model.  Only when CAs in different organizational 
domains certify one another is there typically a a pair of certs 
available. Thus, if one were to impose a constraint, via LDAP, that 
caused CAs to issues reverse certs, it would constitute a major 
change in the way most PKIs today are arranged.

>
>  > I know that Entrust has always encouraged (required?) this type of
>  > cross certification among CAs, but it doesn't seem that other CA
>  > vendors or most users have. I would not think it appropriate to
>  > impose this sort of requirement, given the vendor-specific
>  > implications of such a change.
>
>I don't see this as a vendor-specific issue, but rather as an aid to 
>building certification paths.

It is vendor specific in so far as Entrust products have long 
(always?) issued reverse certs, while no other major products have.

Steve



Received: from po1.bbn.com (PO1.BBN.COM [192.1.50.38]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id OAA10366 for <[e-mail]>; Thu, 20 Jul 2000 14:48:24 -0700 (PDT)
Received: from [171.78.30.107] (fixed030-107.bbn.com [171.78.30.107] (may be forged)) by po1.bbn.com (8.9.1/8.9.1) with ESMTP id RAA00986; Thu, 20 Jul 2000 17:50:29 -0400 (EDT)
Mime-Version: 1.0
X-Sender: [e-mail]
Message-Id: <v04220809b59d230d7e55@[171.78.30.107]>
In-Reply-To: <[e-mail]>
References: <[e-mail]>
Date: Thu, 20 Jul 2000 17:48:17 -0400
To: Tony Bartoletti <[e-mail]>
From: Stephen Kent <[e-mail]>
Subject: Re: A Real Rationale for Dedicated Keys
Cc: [e-mail]
Content-Type: text/plain; charset="us-ascii" ; format="flowed"

Tony,

You cited the ability of a user (or someone else) to bind a public 
key into multiple certs, some with and some without the NR bit 
enabled as a reason that the NR bit is not useful for the purpose I 
stated.  I think I pointed out in my response to John Wary why this 
line of reasoning is not necessarily true. It would be a mistake for 
a user to have the same public key in multiple certs, and anyone 
other than the user should not be able to effect POP and get a CA to 
issue a cert.  Yes, a user could act in this inappropriate fashion, 
in some instances, but then too a user could undermine most of the 
safeguards that we envision through negligent conduct.

Steve


Received: from po1.bbn.com (PO1.BBN.COM [192.1.50.38]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id OAA09998 for <[e-mail]>; Thu, 20 Jul 2000 14:37:57 -0700 (PDT)
Received: from [171.78.30.107] (fixed030-107.bbn.com [171.78.30.107] (may be forged)) by po1.bbn.com (8.9.1/8.9.1) with ESMTP id RAA00132; Thu, 20 Jul 2000 17:40:34 -0400 (EDT)
Mime-Version: 1.0
X-Sender: [e-mail]
Message-Id: <v04220805b59d2010ca78@[171.78.30.107]>
In-Reply-To: <[e-mail]>
References: <001301bff26e$86043410$[e-mail]> <[e-mail]>
Date: Thu, 20 Jul 2000 17:33:22 -0400
To: Ronald A Martin <[e-mail]>
From: Stephen Kent <[e-mail]>
Subject: Re: Signing what you don't understand
Cc: [e-mail]
Content-Type: text/plain; charset="us-ascii" ; format="flowed"

Ron,

>Another...
>
>  http://www.rsasecurity.com/products/keon/advancedpkiservices.html
>
>     Ron

I think what you cite here is one way to facilitate credential 
portability in the absence of hardware tokens. It might also be 
construed as a way to keep selling SecurID cards :-).  It does not 
fundamentally change the focus of our discussion; it is only an 
remote option for encrypted private key and cert storage.

Steve



Received: from lukla.Sun.COM (lukla.Sun.COM [192.18.98.31]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id NAA08581 for <[e-mail]>; Thu, 20 Jul 2000 13:28:10 -0700 (PDT)
Received: from eastmail1.East.Sun.COM ([129.148.1.240]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id OAA13828; Thu, 20 Jul 2000 14:30:46 -0600 (MDT)
Received: from sunlabs.East.Sun.COM (sunlabs.East.Sun.COM [129.148.75.250]) by eastmail1.East.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id QAA06853; Thu, 20 Jul 2000 16:30:09 -0400 (EDT)
Received: from sun.com (dhcp75-155 [129.148.75.155]) by sunlabs.East.Sun.COM (8.9.3+Sun/8.9.1) with ESMTP id QAA13443; Thu, 20 Jul 2000 16:29:54 -0400 (EDT)
Message-ID: <[e-mail]>
Date: Thu, 20 Jul 2000 16:29:16 -0400
From: Steve Hanna <[e-mail]>
Organization: Sun Microsystems, Inc.
X-Mailer: Mozilla 4.73 [en] (WinNT; U)
X-Accept-Language: en
MIME-Version: 1.0
To: [e-mail]
CC: [e-mail], [e-mail], [e-mail]
Subject: Re: Reverse paths
References: <[e-mail]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Peter Gutmann wrote:
> Steve Hanna <[e-mail]> writes:
> >As to how you can display the network of trust in a mesh topology, X.500 DNs
> >provide a nice hierarchy. Certificates are directional arcs between nodes in
> >the tree. Trust anchors can be displayed as arcs from the RP to the trusted
> >party (in a different color, if you like).
> 
> This only works if DN's in certs are ordered hierarchically.  We rejected
> displaying certs ordered by DN almost instantly because the DN's can be more or
> less random, or even pseudo-flat (only the CN changes as you go up the chain).
> The best attempt was to display them arranged by issuer chaining, but this also
> fails when there are multiple effective issuers, the spaghetti of trust is
> rather difficult to display graphically (specifically as a tree control rather
> than having to draw graphs).

You seem to be trying to arrange certificates into a single order. Perhaps you are trying to display
them in a text format. Certainly, this doesn't work well with a non-hierarchical topology. It isn't
even an accurate depiction of a hierarchy, since the hierarchy must be flattened in some way. But I
don't think the PKIX working group had a design goal of making it easy to display a certificate
network in an ordered text file. Other concerns (like security and business requirements) must come
first. And a *graphical representation* can provide a superior visualization, as my earlier note
indicated.

This is a bit of a tangent from the original discussion and probably not of interest to the list as a
whole. Let's take it off-line. If anyone wants to follow us, let me know.

-Steve


Received: from bos-gate3.raytheon.com (bos-gate3.raytheon.com [199.46.198.232]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id NAA08101 for <[e-mail]>; Thu, 20 Jul 2000 13:17:45 -0700 (PDT)
Received: from ds02e00.directory.ray.com (ds02e00.rsc.raytheon.com [147.25.130.245]) by bos-gate3.raytheon.com (8.11.0.Beta3/8.11.0.Beta3) with ESMTP id e6KKKFQ20100; Thu, 20 Jul 2000 16:20:15 -0400 (EDT)
Received: from eoits2.eo.ray.com (localhost [127.0.0.1]) by ds02e00.directory.ray.com (8.9.3/8.9.3) with ESMTP id QAA25838; Thu, 20 Jul 2000 16:20:14 -0400 (EDT)
Received: from raytheon.com (marnas-async22.ed.ray.com [138.125.18.222]) by eoits2.eo.ray.com (8.8.8+Sun/8.8.8) with ESMTP id QAA08843; Thu, 20 Jul 2000 16:20:12 -0400 (EDT)
Message-ID: <[e-mail]>
Date: Thu, 20 Jul 2000 16:20:19 -0400
From: Ronald A Martin <[e-mail]>
Organization: Raytheon Company Corporate IT
X-Mailer: Mozilla 4.73 [en] (Win95; U)
X-Accept-Language: en
MIME-Version: 1.0
CC: Peter Lipp <[e-mail]>, [e-mail]
Subject: Re: Signing what you don't understand
References: <001301bff26e$86043410$[e-mail]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Another...

 http://www.rsasecurity.com/products/keon/advancedpkiservices.html

    Ron

Anders Rundgren wrote:

> Peter,
>
> >> Several leading PKI vendors have implemented systems where the private key
> >> is held on a central Web server and then downloaded at run time to a web
> >> browser.  Are you saying that signatures created using these keys are
> >> invalid?
> >Are you sure? Could you provide a reference? I doubt that strongly...
> >
> >Peter
>
> I think this is one...
>
> http://www.arcot.com/products/webfort.html
>
> Anders



Received: from mail.ec.auckland.ac.nz (mail.student.auckland.ac.nz [130.216.35.201]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id MAA06966 for <[e-mail]>; Thu, 20 Jul 2000 12:30:24 -0700 (PDT)
Received: from kahu.cs.auckland.ac.nz ([e-mail] [130.216.36.13]) by mail.ec.auckland.ac.nz (8.9.3/8.8.6/cs-master) with SMTP id HAA27726; Fri, 21 Jul 2000 07:33:00 +1200 (NZST) (sender [e-mail])
Received: by kahu.cs.auckland.ac.nz (relaymail v0.9) id <96412158014910>; Fri, 21 Jul 2000 07:33:00 (NZST)
From: [e-mail] (Peter Gutmann)
To: [e-mail], [e-mail]
Subject: Re: Reverse paths
Cc: [e-mail], [e-mail], [e-mail]
Sender: [e-mail]
Reply-To: [e-mail]
X-Charge-To: pgut001
X-Authenticated: relaymail v0.9 on kahu.cs.auckland.ac.nz
Date: Fri, 21 Jul 2000 07:33:00 (NZST)
Message-ID: <[e-mail]>

Steve Hanna <[e-mail]> writes:

>As to how you can display the network of trust in a mesh topology, X.500 DNs
>provide a nice hierarchy. Certificates are directional arcs between nodes in
>the tree. Trust anchors can be displayed as arcs from the RP to the trusted
>party (in a different color, if you like).

This only works if DN's in certs are ordered hierarchically.  We rejected
displaying certs ordered by DN almost instantly because the DN's can be more or
less random, or even pseudo-flat (only the CN changes as you go up the chain).
The best attempt was to display them arranged by issuer chaining, but this also
fails when there are multiple effective issuers, the spaghetti of trust is
rather difficult to display graphically (specifically as a tree control rather
than having to draw graphs).

Peter.



Received: from mail.ec.auckland.ac.nz (mail.student.auckland.ac.nz [130.216.35.201]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id MAA06547 for <[e-mail]>; Thu, 20 Jul 2000 12:15:04 -0700 (PDT)
Received: from kahu.cs.auckland.ac.nz ([e-mail] [130.216.36.13]) by mail.ec.auckland.ac.nz (8.9.3/8.8.6/cs-master) with SMTP id HAA13645; Fri, 21 Jul 2000 07:17:38 +1200 (NZST) (sender [e-mail])
Received: by kahu.cs.auckland.ac.nz (relaymail v0.9) id <96412065804050>; Fri, 21 Jul 2000 07:17:38 (NZST)
From: [e-mail] (Peter Gutmann)
To: [e-mail], [e-mail]
Subject: RE: Reverse paths
Cc: [e-mail], [e-mail], [e-mail]
Sender: [e-mail]
Reply-To: [e-mail]
X-Charge-To: pgut001
X-Authenticated: relaymail v0.9 on kahu.cs.auckland.ac.nz
Date: Fri, 21 Jul 2000 07:17:38 (NZST)
Message-ID: <[e-mail]>

Paul Koning <[e-mail]> writes:

>>>>>> "Peter" == Peter Gutmann <[e-mail]> writes:
>
>Peter> ...  (I've seen a
>Peter> paper which tries to formally model PKIX path processing and
>Peter> finds that it's somewhat problematic once you try to create a
>Peter> precise, formal spec rather than the informal description in
>Peter> the RFC, there are some things which actually require the
>Peter> informal spec because they can't be specified in a precise,
>Peter> formal manner).

>A program (algorithm) is a precise formal specification, so does what you say
>mean that the RFC cannot be translated into an algorithm? That would be a
>problem, indeed...

A program constitutes one interpretation of the text in the RFC, however the
RFC really presents an entire class of solutions (or alternatively a rather
large solution space) within which it's possible to construct many different
concrete implementations, all of which are compliant but none of which produce
the same result.  This is why trying to formally specify the path processing
was so difficult, you're trying to construct an unambiguous, exact
specification for something which isn't unambiguous or exact.  In the (draft)
paper I saw they couldn't go as far as they would have liked because it turned
out to be a lot harder than expected to produce a formal spec for the path
processing.  Originally the intent was to model all the path processing stuff,
in the end I think the only thing they managed to complete was policies, and
even then there were some areas where there was no clear indication of what to
do.

The paper is "The PKI Specification Dilemna: A Formal Solution", it was (or at
least will have been by now) published at a conference in Australia, but I
can't find any reference to it online.

Peter.



Received: from lukla.Sun.COM (lukla.Sun.COM [192.18.98.31]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id LAA05698 for <[e-mail]>; Thu, 20 Jul 2000 11:33:19 -0700 (PDT)
Received: from eastmail1.East.Sun.COM ([129.148.1.240]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id MAA19127; Thu, 20 Jul 2000 12:35:47 -0600 (MDT)
Received: from sunlabs.East.Sun.COM (sunlabs.East.Sun.COM [129.148.75.250]) by eastmail1.East.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id OAA12667; Thu, 20 Jul 2000 14:35:21 -0400 (EDT)
Received: from sun.com (dhcp75-155 [129.148.75.155]) by sunlabs.East.Sun.COM (8.9.3+Sun/8.9.1) with ESMTP id OAA03382; Thu, 20 Jul 2000 14:35:20 -0400 (EDT)
Message-ID: <[e-mail]>
Date: Thu, 20 Jul 2000 14:34:42 -0400
From: Steve Hanna <[e-mail]>
Organization: Sun Microsystems, Inc.
X-Mailer: Mozilla 4.73 [en] (WinNT; U)
X-Accept-Language: en
MIME-Version: 1.0
To: [e-mail]
CC: [e-mail], [e-mail], [e-mail]
Subject: Re: Reverse paths
References: <[e-mail]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Peter Gutmann wrote:
> The result is that instead of cert decisions being "yes" or "no", they become
> "probably" (there may be another path which says otherwise) and "maybe" (again,
> there may be another path which says otherwise).  Since you can never know
> where all the paths lead or if you've examined all of them, you can never
> really know whether you're making a valid decision based on the information
> you've got (this is a generalisation of the original problem, which was "how
> the *#^&$ can we display this mess in a meaningful manner?").

Even in a hierarchical trust model, it is often difficult to say definitively "there is no valid
certification path from point A to point B". Especially if there exist certificates that you don't
have. All you can say is "I didn't find a valid path" or "I did find a valid path". However, this
should be sufficient for most purposes (IPsec, SSL, S/MIME, etc). If you're able to find a valid path,
you can proceed. If not, you must fail safe.

This is similar to the behavior if you're trying to determine revocation  status for a certificate
using CRLs and you can't find a current CRL that covers that cert. All you can say is "I don't know if
this certificate has been revoked." Of course, you should fail safe and reject the certificate in this
circumstance.

As to how you can display the network of trust in a mesh topology, X.500 DNs provide a nice hierarchy.
Certificates are directional arcs between nodes in the tree. Trust anchors can be displayed as arcs
from the RP to the trusted party (in a different color, if you like).

Of course, this doesn't represent the namespace of subject alternative names. Nor does it handle the
case where two distinct CAs (or EEs) have the same name or a single CA (or EE) has multiple keys that
have been separately certified. Like most visualizations, it's a simplification.

-Steve


Received: from ns.celocom.se ([e-mail] [212.209.40.66]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id LAA05349 for <[e-mail]>; Thu, 20 Jul 2000 11:22:03 -0700 (PDT)
Received: by ns.celocom.se; id UAA11579; Thu, 20 Jul 2000 20:24:39 +0200 (CEST)
Received: from zap.celocom.se(10.10.10.1) by ns.celocom.se via smap (4.1) id xma011572; Thu, 20 Jul 00 20:24:35 +0200
Received: from celocom.se (dhcp013.celocom.se [10.10.10.193]) by zap.celocom.se (8.8.7/8.8.7) with ESMTP id UAA24953; Thu, 20 Jul 2000 20:24:34 +0200
Message-ID: <[e-mail]>
Date: Thu, 20 Jul 2000 20:23:51 +0200
From: Richard Levitte <[e-mail]>
Organization: Celo Communications, Ltd.
X-Mailer: Mozilla 4.73 [en] (WinNT; I)
X-Accept-Language: en
MIME-Version: 1.0
To: Anders Rundgren <[e-mail]>
CC: Peter Lipp <[e-mail]>, [e-mail], [e-mail]
Subject: Re: Signing what you don't understand
References: <001301bff26e$86043410$[e-mail]>
Content-Type: multipart/mixed; boundary="------------8A211C6186195BEB17D478B9"

This is a multi-part message in MIME format.
--------------8A211C6186195BEB17D478B9
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Anders Rundgren wrote:

> Peter,
>
> >> Several leading PKI vendors have implemented systems where the private key
> >> is held on a central Web server and then downloaded at run time to a web
> >> browser.  Are you saying that signatures created using these keys are
> >> invalid?
> >Are you sure? Could you provide a reference? I doubt that strongly...
> >
> >Peter
>
> I think this is one...
>
> http://www.arcot.com/products/webfort.html

I think not, at least from reading the papers "Protecting Digital Identities" and
"Protecting Your Private Key".  All they say is that they've invented some kind
of key database ("key wallet" to use their term) that is more secure than what
comes with for example MSIE and Netscape Communicator...

Personally, if I was confronted with a CA that wanted to create my private key
for me, and store it centrally to boot, I'd go somewhere else.  Very fast.  It
contradicts anything even remotely close to being called "secure".

--
Richard Levitte   !!! New cell phone number !!!
[e-mail]

/* You might enjoy viewing the complete vCard */


--------------8A211C6186195BEB17D478B9
Content-Type: text/x-vcard; charset=us-ascii;
 name="richard.levitte.vcf"
Content-Transfer-Encoding: 7bit
Content-Description: Card for Richard Levitte
Content-Disposition: attachment;
 filename="richard.levitte.vcf"

begin:vcard 
n:Levitte;Richard
tel;cell:[phone]
tel;work:[phone]
x-mozilla-html:FALSE
org:<A HREF="http://www.celocom.com">Celo Communications</A>
version:2.1
email;internet:[e-mail]
title:Software Artist
adr;quoted-printable:;;Sveav=E4gen 145, 5tr=0D=0AStockholm;;;;SWEDEN
note;quoted-printable:<br>=0D=0A<table border=3D0>=0D=0A<tr>=0D=0A  <td bgcolor=3D"#00ffff">c=EAlo, =E2vi, =E2tum, (latin) 1,v.a.=0D=0A      to hide something from one, to keep secret, to conceal.=0D=0A  </td>=0D=0A</tr>=0D=0A</table>=0D=0A<br>=0D=0A<table border=3D3>=0D=0A<tr>=0D=0A <td>=0D=0A  <table>=0D=0A  <tr>=0D=0A   <td valign=3Dtop>o/~</td>=0D=0A   <td><font size=3D-1>Coding, coding, coding</font><br>=0D=0A          Keep'em hackers coding<br>=0D=0A          <font size=3D+1>And When They're Done Coding</font><br>=0D=0A          <font size=3D7>COMPIIIIIIILE!!</font></td>=0D=0A  </tr>=0D=0A  </table>=0D=0A </td>=0D=0A</tr>=0D=0A</table>
fn:Richard Levitte
end:vcard

--------------8A211C6186195BEB17D478B9--



Received: from wssone.bj.co.uk (wssone.bj.co.uk [194.72.164.250]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id LAA05041 for <[e-mail]>; Thu, 20 Jul 2000 11:15:07 -0700 (PDT)
Received: from 194.72.164.27 by wssone.bj.co.uk with ESMTP (WorldSecure Server SMTP Relay(WSS) v4.3); Thu, 20 Jul 00 19:21:17 +0100
X-Server-Uuid: 1407cc62-e1e1-11d2-808b-0060971f0dc2
Received: from piers2k (host212-140-80-197.host.btclick.com [212.140.80.197]) by bjex1.bj.co.uk with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2448.0) id MC4C48TZ; Thu, 20 Jul 2000 19:19:31 +0100
Reply-to: [e-mail]
From: "Piers Chivers" <[e-mail]>
To: "'Peter Lipp'" <[e-mail]>
cc: [e-mail]
Subject: RE: Signing what you don't understand
Date: Thu, 20 Jul 2000 19:19:04 +0100
Message-ID: <000901bff276$fdc126e0$[e-mail]>
MIME-Version: 1.0
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2910.0)
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700
In-Reply-To: <[e-mail]>
X-WSS-ID: 15699C9769027-01-01
Content-Type: text/plain;  charset=iso-8859-1
Content-Transfer-Encoding: 7bit

Entrust TruePass

Baltimore did something similar for a UK bank.  I don't think it's
commercially available but was presented at Infosec 2000. Maybe someone from
Baltimore can expand??

Piers

-----Original Message-----
From: Peter Lipp [mailto:[e-mail]]
Sent: 20 July 2000 16:59
To: [e-mail]
Cc: [e-mail]
Subject: AW: Signing what you don't understand



> Several leading PKI vendors have implemented systems where the private key
> is held on a central Web server and then downloaded at run time to a web
> browser.  Are you saying that signatures created using these keys are
> invalid?
Are you sure? Could you provide a reference? I doubt that strongly...

Peter


------------------------------------------------------------------------------------------
This message is for the named persons use only.  It may contain confidential, proprietary or legally privileged information.  No confidentiality or privilege is waived or lost by any mistransmission.  If you receive this message in error, please immediately delete it and all copies of it from your system, destroy any hard copies of it and notify the sender.  You must not, directly or indirectly, use, disclose, distribute, print, or copy any part of this message if you are not the intended recipient. PROTEK Network Management Group and each of its subsidiaries reserve the right to monitor all e-mail communications through its networks.  Any views expressed in this message are those of the individual sender, except where the message states otherwise and the sender is authorised to state them to be the views of any such entity.






Received: from arista.iris.com (arista.iris.com [198.112.211.42]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id LAA04744 for <[e-mail]>; Thu, 20 Jul 2000 11:07:02 -0700 (PDT)
From: [e-mail]
Subject: Re: Signing what you don't understand
To: Denis Pinkas <[e-mail]>
Cc: [e-mail], [e-mail]
X-Mailer: Lotus Notes Release 5.0.2c  February 2, 2000
Message-ID: <[e-mail]>
Date: Thu, 20 Jul 2000 14:09:56 -0400
X-MIMETrack: Serialize by Router on Arista/Iris(Build V505_07112000 |July 11, 2000) at 07/20/2000 02:09:43 PM
MIME-Version: 1.0
Content-type: text/plain; charset=us-ascii

Denis,

>> Note I'm not talking about NR here -
>
>So what are you talking about ???

The case where an RP receives a document and is trying to verify a
signature.  The significance of the NR bit in a certificate was the
starting point for this discussion, but for now I'm simply concerned with
the initial signature verification (if the RP doesn't believe my signature,
he certainly can't expect to hold me to it :).  Note I'm not restricting
this to simple E-mail, where because of the one-to-one, low-latency nature
of the communications involved, there is unlikely to be a significant time
between signing and verifying (and if there is, the RP can simply ask the
sender for a freshly-signed copy).  Rather, I'm talking about high-latency
or one-to-many environments.  An extreme example of this might be signing a
document and placing it on a web-site or in a directory - here I am signing
the document without any knowledge of the identity of the RPs, and with the
possibility of significant delay before an RP will try to verify the
signature.


>> >A RP can be responsible for acquiring all the requisite evidence for
>> >later support of signed document validity, including time stamping
>> >this evidence. I think this addresses the scenario you described
>> >above.
>>
>> That addresses the case where the document is processed by the RP prior
to
>> my CA going out of business, but it doesn't help if trust in the CA has
>> already been revoked at the time the RP tries to verify the signature.
>
>Don't you think that if a RP receives a siganture it has better to
>make sure that what it gets is "fine" ? So he should validate the
>signature as soon as possible and in order to cover the case of a
>possible (volontary) revocation of the signer certificate, he should
>time stamp the signature as soon as possible. So the case you are
>considering is not a practical case.

In the situation I'm discussing, one of the CAs that the signer chose to
embed in his signature has already gone out of business by the time the RP
sees the signature.

>> But that doesn't help
>> unless the RP directly trusts the signer's root CA.
>
>There is no concept of root CA. There is a concept of a Signature
>Policy that may involve one or more root CAs but involves many other
>conditions.
>
>> If the RP doesn't trust the root that the signer chooses,
>
> ... you mean : If the RP thinks that the Signature Policy is not
>adequate for his context of use, then this is the end of the story.

Yes, that's a concise statement of the problem.  By requiring that the
signer choose a specific Signature Policy (including, in the context of
this discussion, the certificate chain), rather than leaving it to the RP
to construct the chain, there is a possibility of a signature being
incorrectly determined as invalid.  By omitting the signer's certificate
chain, and leaving it up to the RP to construct an appropriate chain, then
if my CA goes out of business, it wouldn't necessarily invalidate my prior
signatures (providing my key can be certified by another CA).


>> then the timestamped chain is of
>> little use to him, since it won't say anything about the certificates in
>> the chain the RP constructs (although if a chain from one of the RP's
>> trusted roots happens to "join up" with some fraction of the signer's
>> timestamped chain, then the timestamp can be used as evidence of
validity
>> at signing time of the fraction of the chain below the intersection
point).
>>
>> Even if the RP does trust the signer's root, though, it's not clear why
the
>> RP's software should believe a signature based on a certificate chain
that
>> contains revoked certificates (with invalidity dates that precede the
>> signature date), even if it includes evidence that at the time of
signature
>> creation, those certificates had not yet been revoked.
>
>This is contradictory. "if it includes evidence that at the time of
>signature creation, those certificates had not yet been revoked"
>means that you must provide a proof that the certificates whre not
>revoked at the time of the signature, so you cannot say at the same
>time "certificate chain that contains revoked certificates".

It's not contradictory:  Evidence that a certificate had not been revoked
at time T could include a CRL that was valid at T, and that did not list
the certificate.  However, if later a CRL were published (and were
available to the RP) that included the certificate, along with an
invalidityDate before time T, then the RP can conclude that the certificate
has been revoked, and should not be trusted to verify a signature made at
T.

John




Received: from dfw7-1.relay.mail.uu.net (dfw7-1.relay.mail.uu.net [199.171.54.106]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id KAA03571 for <[e-mail]>; Thu, 20 Jul 2000 10:10:04 -0700 (PDT)
Received: from xedia.com by dfw7sosrv11.alter.net with SMTP  (peer crosschecked as: madway.xedia.com [198.202.232.199]) id QQiyrk08767; Thu, 20 Jul 2000 17:12:37 GMT
Received: from tonga.xedia.com by xedia.com (4.1/SMI-4.1) id AA17285; Thu, 20 Jul 00 13:08:42 EDT
Received: by tonga.xedia.com (SMI-8.6/SMI-SVR4) id NAA07477; Thu, 20 Jul 2000 13:12:36 -0400
From: Paul Koning <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-Id: <[e-mail]>
Date: Thu, 20 Jul 2000 13:12:35 -0400 (EDT)
To: [e-mail]
Cc: [e-mail], [e-mail], [e-mail]
Subject: RE: Reverse paths
References: <[e-mail]>
X-Mailer: VM 6.72 under 21.1 (patch 9) "Canyonlands" XEmacs Lucid

>>>>> "Peter" == Peter Gutmann <[e-mail]> writes:

 Peter> ...  (I've seen a
 Peter> paper which tries to formally model PKIX path processing and
 Peter> finds that it's somewhat problematic once you try to create a
 Peter> precise, formal spec rather than the informal description in
 Peter> the RFC, there are some things which actually require the
 Peter> informal spec because they can't be specified in a precise,
 Peter> formal manner).

A program (algorithm) is a precise formal specification, so does what
you say mean that the RFC cannot be translated into an algorithm?
That would be a problem, indeed...

     paul


Received: from mail.ec.auckland.ac.nz (mail.student.auckland.ac.nz [130.216.35.201]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id JAA02888 for <[e-mail]>; Thu, 20 Jul 2000 09:50:01 -0700 (PDT)
Received: from kahu.cs.auckland.ac.nz ([e-mail] [130.216.36.13]) by mail.ec.auckland.ac.nz (8.9.3/8.8.6/cs-master) with SMTP id EAA10785; Fri, 21 Jul 2000 04:52:35 +1200 (NZST) (sender [e-mail])
Received: by kahu.cs.auckland.ac.nz (relaymail v0.9) id <96411195511841>; Fri, 21 Jul 2000 04:52:35 (NZST)
From: [e-mail] (Peter Gutmann)
To: [e-mail], [e-mail]
Subject: RE: Reverse paths
Cc: [e-mail]
Sender: [e-mail]
Reply-To: [e-mail]
X-Charge-To: pgut001
X-Authenticated: relaymail v0.9 on kahu.cs.auckland.ac.nz
Date: Fri, 21 Jul 2000 04:52:35 (NZST)
Message-ID: <[e-mail]>

Sharon Boeyen <[e-mail]> writes:

>However, once you start connecting hierarchies together, e.g. through bridge
>CAs and once you moved out of hierarchies into distributed trust models, that
>condition no longer holds true. As bridges become more common and the
>certificates issued to and by bridges increases, the number of potential paths
>becomes quite large.

I had a long talk with some people a few weeks back about how to write code to
display cert chains in the presence of bridge CA's, and it turns out to be an
almost unsolveable problem because the bridges turn a hierarchy of trust into a
spaghetti of trust (I won't use the PGP term "web of trust" because PGP was
designed for this model and handles it reasonably well, whereas X.509 wasn't
and doesn't - I'm not trying to start a PGP flame war here, just pointing out
that X.509 was never intended to work this way).

The result is that instead of cert decisions being "yes" or "no", they become
"probably" (there may be another path which says otherwise) and "maybe" (again,
there may be another path which says otherwise).  Since you can never know
where all the paths lead or if you've examined all of them, you can never
really know whether you're making a valid decision based on the information
you've got (this is a generalisation of the original problem, which was "how
the *#^&$ can we display this mess in a meaningful manner?").

For example, if I start by collecting my set of initial policy identifiers and
find a cert for which I don't have a path leading to a member of the policy
set, this doesn't mean that the cert isn't acceptable, merely that I haven't
found one of the fifteen other paths to another CA which could end in an
acceptable policy.  Revocation is even messier ("It's revoked!  Not it isn't!
Yes it is!").

Has anyone ever done an analysis of the potential mess bridge CA's are leading
into, or was it just tacked onto the side of the original hierarchical model as
a quick fix?  (I've seen a paper which tries to formally model PKIX path
processing and finds that it's somewhat problematic once you try to create a
precise, formal spec rather than the informal description in the RFC, there are
some things which actually require the informal spec because they can't be
specified in a precise, formal manner).

As a subset of this question, how *do* you display the spaghetti of trust in a
meaningful manner?

Peter.



Received: from d1o69.telia.com ([e-mail] [62.20.144.241]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id JAA01705 for <[e-mail]>; Thu, 20 Jul 2000 09:16:52 -0700 (PDT)
Received: from mega (t2o69p98.telia.com [62.20.144.218]) by d1o69.telia.com (8.8.8/8.8.8) with SMTP id SAA04575; Thu, 20 Jul 2000 18:19:22 +0200 (CEST)
Message-ID: <001301bff26e$86043410$[e-mail]>
From: "Anders Rundgren" <[e-mail]>
To: "Peter Lipp" <[e-mail]>, <[e-mail]>
Cc: <[e-mail]>
Subject: Re: Signing what you don't understand
Date: Thu, 20 Jul 2000 19:18:27 +0200
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 4.72.3110.5
X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by ns.secondary.com id JAA01710

Peter,

>> Several leading PKI vendors have implemented systems where the private key
>> is held on a central Web server and then downloaded at run time to a web
>> browser.  Are you saying that signatures created using these keys are
>> invalid?
>Are you sure? Could you provide a reference? I doubt that strongly...
>
>Peter


I think this is one...

http://www.arcot.com/products/webfort.html

Anders



Received: from odin2.bull.net (odin2.bull.net [192.90.70.84]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id JAA01675 for <[e-mail]>; Thu, 20 Jul 2000 09:16:46 -0700 (PDT)
Received: from lvt-mail.frlv.bull.fr (lvt-mail.frlv.bull.fr [129.184.62.223]) by odin2.bull.net (8.9.3/8.9.3) with ESMTP id SAA28016; Thu, 20 Jul 2000 18:23:10 +0200
Received: from bull.net (frpq6118.frpq.bull.fr [129.184.8.64]) by lvt-mail.frlv.bull.fr (8.9.2/8.9.1) with ESMTP id SAA41600; Thu, 20 Jul 2000 18:18:45 +0200
Message-ID: <[e-mail]>
Date: Thu, 20 Jul 2000 18:16:27 +0200
From: Denis Pinkas <[e-mail]>
Organization: Bull
X-Mailer: Mozilla 4.7 [fr] (Win98; I)
X-Accept-Language: fr
MIME-Version: 1.0
To: [e-mail]
CC: [e-mail]
Subject: Re: Signing what you don't understand
References: <[e-mail]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

John,

Let me jump in this discussion (and hopefully go out very quickly).

> Steve,

> (...)

> >A RP can be responsible for acquiring all the requisite evidence for
> >later support of signed document validity, including time stamping
> >this evidence. I think this addresses the scenario you described
> >above.
> 
> That addresses the case where the document is processed by the RP prior to
> my CA going out of business, but it doesn't help if trust in the CA has
> already been revoked at the time the RP tries to verify the signature.

Don't you think that if a RP receives a siganture it has better to
make sure that what it gets is "fine" ? So he should validate the
signature as soon as possible and in order to cover the case of a
possible (volontary) revocation of the signer certificate, he should
time stamp the signature as soon as possible. So the case you are
considering is not a practical case.

> Note I'm not talking about NR here - 

So what are you talking about ???

> In the scenario I'm concerned with,
> the RP will itself not trust my signature, even though it should be valid.
> In an e-mail environment, this may not matter too much, as the RP could
> simply ask the signer to re-send a freshly signed copy of the e-mail, but
> in a work-flow or EDI environment, where documents move through a system
> acquiring multiple counter-signatures over portions of the documents, it
> may be impractical to simply re-start the process.
> 
> It is possible for the signer to timestamp his signature, along with a
> complete certification path from some root CA, along with CRL- or
> OCSP-based liveness evidence for every certificate on that path.  This is,
> I think, what ESS terms a signer-generated ES-X.  

Yes. This is one of the formats that may be used.

> But that doesn't help
> unless the RP directly trusts the signer's root CA.  

There is no concept of root CA. There is a concept of a Signature
Policy that may involve one or more root CAs but involves many other
conditions.

> If the RP doesn't
> trust the root that the signer chooses, 

 ... you mean : If the RP thinks that the Signature Policy is not
adequate for his context of use, then this is the end of the story.

> then the timestamped chain is of
> little use to him, since it won't say anything about the certificates in
> the chain the RP constructs (although if a chain from one of the RP's
> trusted roots happens to "join up" with some fraction of the signer's
> timestamped chain, then the timestamp can be used as evidence of validity
> at signing time of the fraction of the chain below the intersection point).
> 
> Even if the RP does trust the signer's root, though, it's not clear why the
> RP's software should believe a signature based on a certificate chain that
> contains revoked certificates (with invalidity dates that precede the
> signature date), even if it includes evidence that at the time of signature
> creation, those certificates had not yet been revoked.  

This is contradictory. "if it includes evidence that at the time of
signature creation, those certificates had not yet been revoked"
means that you must provide a proof that the certificates whre not
revoked at the time of the signature, so you cannot say at the same
time "certificate chain that contains revoked certificates".   

Denis


> Even if not
> rejected outright, such a signature should be treated as at best
> suspicious.
> 
> John


Received: from iaik.tu-graz.ac.at (excalibur.iaik.tu-graz.ac.at [129.27.152.30]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id IAA01112 for <[e-mail]>; Thu, 20 Jul 2000 08:55:06 -0700 (PDT)
Received: from PLIPP2 [129.27.152.34] by iaik.tu-graz.ac.at (SMTPD32-6.00) id A165D00134; Thu, 20 Jul 2000 17:57:25 +0200
From: "Peter Lipp" <[e-mail]>
To: <[e-mail]>
Cc: <[e-mail]>
Subject: AW: Signing what you don't understand
Date: Thu, 20 Jul 2000 17:58:35 +0200
Message-ID: <[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0)
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700
In-reply-to: <000301bff227$44419be0$[e-mail]>

> Several leading PKI vendors have implemented systems where the private key
> is held on a central Web server and then downloaded at run time to a web
> browser.  Are you saying that signatures created using these keys are
> invalid?
Are you sure? Could you provide a reference? I doubt that strongly...

Peter



Received: from smtp1.atl.equifax.com (smtp1.atl.equifax.com [216.46.96.117]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id IAA00838 for <[e-mail]>; Thu, 20 Jul 2000 08:47:36 -0700 (PDT)
From: [e-mail]
Received: from postoffice-2.equifax.com (unknown [192.168.4.11]) by smtp1.atl.equifax.com (Postfix) with ESMTP id 039E374EAA; Thu, 20 Jul 2000 11:49:41 -0400 (EDT)
Received: from noteswetc15.fin.equifax.com (noteswetc15.fin.equifax.com [172.18.113.65]) by postoffice-2.equifax.com (Postfix) with SMTP id 404B36A2AC; Thu, 20 Jul 2000 11:49:43 -0400 (EDT)
Received: by noteswetc15.fin.equifax.com(Lotus SMTP MTA v4.6.5  (863.2 5-20-1999))  id 85256922.0056EE12 ; Thu, 20 Jul 2000 11:49:30 -0400
X-Lotus-FromDomain: EQUIFAX
To: "Anders Rundgren" <[e-mail]>
Cc: [e-mail]
Message-ID: <[e-mail]>
Date: Thu, 20 Jul 2000 11:49:22 -0400
Subject: Re: Value of smart cards. Re: Signing what you don't understand
Mime-Version: 1.0
Content-type: text/plain; charset=us-ascii
Content-Disposition: inline

>The discrete credit-sized smart card is probably not going to take over the
world
>as you say.  But the SIM/WIM card will. Actually 300 million *existing*
customers
>can't be wrong!

I just want to add a comment for the SIM card - It is a smaller version of
Smartcard in a different footprint.  The program in the GSM card use
non-standard encryption, it is not truely secure (both phyical/logical).

>It provides a cheap tamper-resistant storage and crypto-processor that *will*
also
>be apart of PDAs when they are "connected".  It is the ability to insert a
>subscription into a mobile phone and PDA that is the driving factor now.
>Later it will be PKI.
IMHO: I do like to see the PDA or phone will accept personal (crypto) smartcard
that could perform secure operations (ie. Sign Document, payment...)

Mcken Mak




Received: from e3.ny.us.ibm.com (e3.ny.us.ibm.com [32.97.182.103]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id IAA24590 for <[e-mail]>; Thu, 20 Jul 2000 08:04:10 -0700 (PDT)
From: [e-mail]
Received: from northrelay02.pok.ibm.com (northrelay02.pok.ibm.com [9.117.200.22]) by e3.ny.us.ibm.com (8.9.3/8.9.3) with ESMTP id LAA24110; Thu, 20 Jul 2000 11:06:15 -0400
Received: from D51MTA04.pok.ibm.com (d51mta04.pok.ibm.com [9.117.200.32]) by northrelay02.pok.ibm.com (8.8.8m3/NCO v4.92) with SMTP id LAA37018; Thu, 20 Jul 2000 11:06:13 -0400
Received: by D51MTA04.pok.ibm.com(Lotus SMTP MTA v4.6.5  (863.2 5-20-1999))  id 85256922.0052F626 ; Thu, 20 Jul 2000 11:06:09 -0400
X-Lotus-FromDomain: IBMUS
To: "Simon McMahon" <[e-mail]>
cc: [e-mail], "Tony Bartoletti" <[e-mail]>
Message-ID: <[e-mail]>
Date: Thu, 20 Jul 2000 11:06:04 -0400
Subject: Re: A Real Rationale for Dedicated Keys
Mime-Version: 1.0
Content-type: text/plain; charset=us-ascii
Content-Disposition: inline

"Simon McMahon" <[e-mail]> on 07/20/2000 05:05:01 AM

To:   <[e-mail]>, "Tony Bartoletti" <[e-mail]>
cc:
Subject:  Re: A Real Rationale for Dedicated Keys



> My point being, the key-owner is the primary point of
> control in enforcing a "one-key, one-cert" personal regime.
>
The "key generator" is really the primary point of control and need not be
the same as the "key owner" (the one who makes signatures). Some CAs insist
on having some control over key origin, key generation, or at least the
equipment used to do it so that uncontrolled certifications and hackable
private keys can be avoided. I would expect that all commercial CAs that
generate certs intended for NR usage will have to control key generation.

Does it really matter how many certificates there are for a public key as
long as the one specifying NR relates to a private key that cannot be
duplicated ? I dont see how multiple certs for a key is a threat to
non-repudiation of signatures. Only private key exposure / duplication is.

[Tom Gindin] The threat is that the subject could claim, as an attempt to
repudiate, that he was using an ordinary authentication key, and he didn't
know that it was for NR.  For this reason and similar ones, having multiple
certificates with conflicting key usages but the same key is surely bad
practice - having multiple certificates with the same key usages and the
same key from different issuers is much less so.  There is a converse
threat, in that an untrustworthy CA could (in theory) issue certificates
for users it has no relationship with, based on existing valid
certificates, but with stronger key usage and an RP could claim reliance on
such certificates.  Then the CA goes out of operation and the RP claims
non-repudiation.

Regards,

Simon McMahon.
ERACOM Pty. Ltd.




Received: from arista.iris.com (arista.iris.com [198.112.211.42]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id HAA24290 for <[e-mail]>; Thu, 20 Jul 2000 07:55:18 -0700 (PDT)
From: [e-mail]
Subject: Re: Signing what you don't understand
To: Stephen Kent <[e-mail]>
Cc: [e-mail], <[e-mail]>
X-Mailer: Lotus Notes Release 5.0.2c  February 2, 2000
Message-ID: <[e-mail]>
Date: Thu, 20 Jul 2000 10:58:08 -0400
X-MIMETrack: Serialize by Router on Arista/Iris(Build V505_07112000 |July 11, 2000) at 07/20/2000 10:57:58 AM
MIME-Version: 1.0
Content-type: text/plain; charset=us-ascii

Steve,

>>What other mechanisms would cover that case of my issuing CA going out of
>>business?  If a CA's assets (including its keys) are sold as part of a
>>bankruptcy process, I would think that trust in those keys would be
fairly
>>quickly revoked by other CAs that might have cross-certified it.  In this
>>case, invalidityDate on those revocations would probably be set so that
no
>>certificate that had been issued by the former CA's key would be trusted
>>(to prevent the keys' new owners from issuing new backdated
certificates).
>>However, as a subscriber to the former CA, I don't see why my signatures
>>should suddenly become less trustworthy, if my key can be verified via
>>another path.
>
>A RP can be responsible for acquiring all the requisite evidence for
>later support of signed document validity, including time stamping
>this evidence. I think this addresses the scenario you described
>above.

That addresses the case where the document is processed by the RP prior to
my CA going out of business, but it doesn't help if trust in the CA has
already been revoked at the time the RP tries to verify the signature.
Note I'm not talking about NR here - In the scenario I'm concerned with,
the RP will itself not trust my signature, even though it should be valid.
In an e-mail environment, this may not matter too much, as the RP could
simply ask the signer to re-send a freshly signed copy of the e-mail, but
in a work-flow or EDI environment, where documents move through a system
acquiring multiple counter-signatures over portions of the documents, it
may be impractical to simply re-start the process.

It is possible for the signer to timestamp his signature, along with a
complete certification path from some root CA, along with CRL- or
OCSP-based liveness evidence for every certificate on that path.  This is,
I think, what ESS terms a signer-generated ES-X.  But that doesn't help
unless the RP directly trusts the signer's root CA.  If the RP doesn't
trust the root that the signer chooses, then the timestamped chain is of
little use to him, since it won't say anything about the certificates in
the chain the RP constructs (although if a chain from one of the RP's
trusted roots happens to "join up" with some fraction of the signer's
timestamped chain, then the timestamp can be used as evidence of validity
at signing time of the fraction of the chain below the intersection point).


Even if the RP does trust the signer's root, though, it's not clear why the
RP's software should believe a signature based on a certificate chain that
contains revoked certificates (with invalidity dates that precede the
signature date), even if it includes evidence that at the time of signature
creation, those certificates had not yet been revoked.  Even if not
rejected outright, such a signature should be treated as at best
suspicious.


John




Received: from ext-mail.valicert.com (ns1.valicert.com [63.65.221.10]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id HAA23964 for <[e-mail]>; Thu, 20 Jul 2000 07:45:44 -0700 (PDT)
Received: from CONVERSION-DAEMON.ext-mail.valicert.com by ext-mail.valicert.com (PMDF V6.0-24 #46243) id <[e-mail]> for [e-mail]; Thu, 20 Jul 2000 07:48:11 -0700 (PDT)
Received: from seine.valicert.com ([192.168.2.23]) by ext-mail.valicert.com (PMDF V6.0-24 #46243) with ESMTP id <[e-mail]>; Thu, 20 Jul 2000 07:48:10 -0700 (PDT)
Received: by seine.valicert.com with Internet Mail Service (5.5.2650.21) id <36006Q06>; Thu, 20 Jul 2000 07:40:00 -0700
Content-return: allowed
Date: Thu, 20 Jul 2000 07:39:59 -0700
From: Frank Balluffi <[e-mail]>
Subject: RE: Signing what you don't understand
To: "'[e-mail]'" <[e-mail]>, "Golkin, Ken (CAP, CMC)" <[e-mail]>
Cc: "'Stephen Kent'" <[e-mail]>, [e-mail]
Message-id: <[e-mail]>
MIME-version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-type: text/plain; charset=iso-8859-1

Byron Stump wrote:

> With transactions that are not direct equivalents of paper 
> contracts, the issues
> get even murkier, but perhaps commonsense practices could be 
> proposed to include
> an explicit acknowledgement of the intent to be bound within 
> the material being
> signed.   In an online ordering system, this could be a 
> prominent notice such as
> "By proceeding, I understand that I am entering into a 
> contract to buy the
> widget."  along with a completed NAME field that can be 
> matched to the name
> bound to the verification key.

I agree.

Please note Byron's use of "explicit" above. Every meaningful document that
I have ever signed has explicitly included one or more verbs. There is no
reason why explicit verbs cannot or should not be included in signed
authentication responses. For example, "I received the following bytes ..."
could be signed. Just because authentication protocols exist that include
implicit verbs does not mean this is good practice. If explicit verbs are
included, I really do not see a difference between signing an authentication
response, a credit card slip [or whatever it is called] to purchase a pizza
or a purchase order for a jet aircraft.

Frank

> -----Original Message-----
> From: [e-mail] [mailto:[e-mail]]
> Sent: Thursday, July 20, 2000 10:13 AM
> To: Golkin, Ken (CAP, CMC)
> Cc: 'Stephen Kent'; [e-mail]
> Subject: RE: Signing what you don't understand
> 
> 
> 
> 
> I've been monitoring this discussion for a couple of weeks.
> 
> May I offer an example to try to crystallize a key point of 
> this discussion?
> 
> Assume I am negotiating the language of a contract with a 
> third party and my
> purchasing department.  We may send numerous drafts back and 
> forth as e-mail
> attachments, in an effort to arrive at agreeable language.  
> Obviously I can
> digitally sign each draft of the contract document before 
> attaching it, just to
> make sure no third party substitutes language in my name.  It 
> should be clear
> that in doing so, however, I have not "signed the contract" 
> in the normal sense.
> 
> Now assuming that all parties accept digital signatures as 
> binding, the question
> is how do I sign it differently when I mean to execute the contract?
> 
> That is the crux of the matter.  In protecting the drafts, I 
> am neither signing
> something that I do not understand, nor am I not executing a contract.
> 
> Seems to me absent some elaborate schemes involving multiple 
> keys, the answer is
> that the content and context must be used to determine the 
> intent.   It could be
> argued that in this instance, if the contract document 
> contains "DRAFT", or does
> not have my name in the document on a signature line, then it 
> could be expected
> that a reasonable person (or court) would correctly infer 
> that it was merely a
> digitally signed document, not a legally signed contract.  
> But what if the final
> draft does not say DRAFT, and has the signature lines filled 
> in?   That is the
> problem, and I think its resolution is in the realms of 
> evolving practices,
> legislation and case law, and cannot be addressed completely 
> by a technical
> spec.
> 
> With transactions that are not direct equivalents of paper 
> contracts, the issues
> get even murkier, but perhaps commonsense practices could be 
> proposed to include
> an explicit acknowledgement of the intent to be bound within 
> the material being
> signed.   In an online ordering system, this could be a 
> prominent notice such as
> "By proceeding, I understand that I am entering into a 
> contract to buy the
> widget."  along with a completed NAME field that can be 
> matched to the name
> bound to the verification key.
> 
> Byron
> 
> 
> 
> 
> 


Received: from ext-mail.valicert.com (ns1.valicert.com [63.65.221.10]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id HAA23563 for <[e-mail]>; Thu, 20 Jul 2000 07:35:21 -0700 (PDT)
Received: from CONVERSION-DAEMON.ext-mail.valicert.com by ext-mail.valicert.com (PMDF V6.0-24 #46243) id <[e-mail]> for [e-mail]; Thu, 20 Jul 2000 07:36:50 -0700 (PDT)
Received: from seine.valicert.com ([192.168.2.23]) by ext-mail.valicert.com (PMDF V6.0-24 #46243) with ESMTP id <[e-mail]> for [e-mail]; Thu, 20 Jul 2000 07:36:50 -0700 (PDT)
Received: by seine.valicert.com with Internet Mail Service (5.5.2650.21) id <36006Q9L>; Thu, 20 Jul 2000 07:28:40 -0700
Content-return: allowed
Date: Thu, 20 Jul 2000 07:28:31 -0700
From: Frank Balluffi <[e-mail]>
Subject: Self-Signed Certificate
To: "'[e-mail]'" <[e-mail]>
Message-id: <[e-mail]>
MIME-version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-type: text/plain; charset=iso-8859-1

PKIX uses the term self-signed certificate without defining it (e.g., RFC
2459, draft-ietf-pkix-new-part1-01.txt and draft-ietf-pkix-scvp-03.txt).

Clearly, a self-signed certificate's subject public key MUST verify its
signature. MUST a self-signed certificate's issuer equal its subject?

Frank


Received: from d1o69.telia.com ([e-mail] [62.20.144.241]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id HAA22694 for <[e-mail]>; Thu, 20 Jul 2000 07:12:54 -0700 (PDT)
Received: from mega (t2o69p46.telia.com [62.20.144.166]) by d1o69.telia.com (8.8.8/8.8.8) with SMTP id QAA17727; Thu, 20 Jul 2000 16:15:26 +0200 (CEST)
Message-ID: <001f01bff25d$35f06310$[e-mail]>
From: "Anders Rundgren" <[e-mail]>
To: "Paul Koning" <[e-mail]>
Cc: <[e-mail]>
Subject: Re: Signing what you don't understand
Date: Thu, 20 Jul 2000 17:14:31 +0200
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 4.72.3110.5
X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by ns.secondary.com id HAA22695

Paul,

> Anders> Piers,
> >> I would welcome comments from this forum on their opinion of the
> >> validity of signatures where the private key and end-user are not
> >> co-located.
>
> Anders> This is now for real as VISA-EU has lost faith in the
> Anders> original SET model with local key/cert and will aggresively
> Anders> push a server-based model.  Way to go IMO!
>
>What does that mean?


It means that the SET card-holder certificate+private key is stored and
excuted on the customer's bank instead of in his/her PC,  Why do that?

This I have talked about several times on this list so I will not go into
details but this one is easy: Most potential customers already have an Internet-
bank facility that uses some kind of proprietary security solution.  In
Sweden most banks use a hardware box like secureID or Activecard.
With the Server Wallet you use the same security solution for credit-card
payments.  Assuming that the issuer is the very same bank which is true
in 99 cases out of 100.  A small step closer to SSO [Single Sign On] :-).

I.e. you redirect the merchants's payment request to your bank and
authenticate to the cert/key using a bank-specific security solution and
then the bank does the rest.   All communication is shielded by SSL of course.

> Anders> But this was maybe more than you asked for, beacuse the
> Anders> signatures are also created on the server (wallet) which is
> Anders> not the same as downloading private keys when needed.
>
> Anders> In German unfortunately:
>
> Anders> http://www.visa.de/df/presse/pressetexte/000619_001.htm
>
>Unfortunately that document doesn't actually say anything.  It's just
>marketing vapor.  
>
>Do you have a reference that contains information?


Currently not.  This is information gathered from Commerce.Net and it does
not contain very much technical details.  However, I have confirmed that it
works as describe.

Anders



Received: from tpamail2.bdi.gte.com (tpamail2.bdi.gte.com [192.76.82.136]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id HAA22630 for <[e-mail]>; Thu, 20 Jul 2000 07:11:53 -0700 (PDT)
From: [e-mail]
Received: from tpamail2.bdi.gte.com (localhost [127.0.0.1]) by tpamail2.bdi.gte.com (8.9.3/8.9.3) with ESMTP id KAA29124 for <[e-mail]>; Thu, 20 Jul 2000 10:13:58 -0400 (EDT)
Received: from smtptpa.interwan.gte.com ([138.83.66.45]) by tpamail2.bdi.gte.com (8.9.3/8.9.3) with ESMTP id KAA28976; Thu, 20 Jul 2000 10:13:48 -0400 (EDT)
Received: from imr01.bellatlantic.com ([141.152.156.12]) by smtptpa.interwan.gte.com (8.9.3/8.9.3) with ESMTP id KAA15635; Thu, 20 Jul 2000 10:13:26 -0400 (EDT)
Received: from fhsmtp03.bell-atl.com (is051952.bellatlantic.com [141.152.101.51]) by imr01.bellatlantic.com (8.8.8/8.8.5) with SMTP id KAA29094; Thu, 20 Jul 2000 10:13:08 -0400 (EDT)
Received: by fhsmtp03.bell-atl.com(Lotus SMTP MTA v4.6.7  (934.1 12-30-1999))  id 85256922.004E153B ; Thu, 20 Jul 2000 10:12:52 -0400
X-Lotus-FromDomain: BELL-ATL
To: "Golkin, Ken (CAP, CMC)" <[e-mail]>
cc: "'Stephen Kent'" <[e-mail]>, [e-mail]
Message-ID: <[e-mail]>
Date: Thu, 20 Jul 2000 10:12:54 -0400
Subject: RE: Signing what you don't understand
Mime-Version: 1.0
Content-type: text/plain; charset=us-ascii
Content-Disposition: inline

I've been monitoring this discussion for a couple of weeks.

May I offer an example to try to crystallize a key point of this discussion?

Assume I am negotiating the language of a contract with a third party and my
purchasing department.  We may send numerous drafts back and forth as e-mail
attachments, in an effort to arrive at agreeable language.  Obviously I can
digitally sign each draft of the contract document before attaching it, just to
make sure no third party substitutes language in my name.  It should be clear
that in doing so, however, I have not "signed the contract" in the normal sense.

Now assuming that all parties accept digital signatures as binding, the question
is how do I sign it differently when I mean to execute the contract?

That is the crux of the matter.  In protecting the drafts, I am neither signing
something that I do not understand, nor am I not executing a contract.

Seems to me absent some elaborate schemes involving multiple keys, the answer is
that the content and context must be used to determine the intent.   It could be
argued that in this instance, if the contract document contains "DRAFT", or does
not have my name in the document on a signature line, then it could be expected
that a reasonable person (or court) would correctly infer that it was merely a
digitally signed document, not a legally signed contract.  But what if the final
draft does not say DRAFT, and has the signature lines filled in?   That is the
problem, and I think its resolution is in the realms of evolving practices,
legislation and case law, and cannot be addressed completely by a technical
spec.

With transactions that are not direct equivalents of paper contracts, the issues
get even murkier, but perhaps commonsense practices could be proposed to include
an explicit acknowledgement of the intent to be bound within the material being
signed.   In an online ordering system, this could be a prominent notice such as
"By proceeding, I understand that I am entering into a contract to buy the
widget."  along with a completed NAME field that can be matched to the name
bound to the verification key.

Byron







Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id HAA22205 for <[e-mail]>; Thu, 20 Jul 2000 07:02:46 -0700 (PDT)
Received: from eastmail2.East.Sun.COM ([129.148.1.241]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id HAA03745; Thu, 20 Jul 2000 07:05:06 -0700 (PDT)
Received: from sunlabs.East.Sun.COM (sunlabs-74.East.Sun.COM [129.148.74.250]) by eastmail2.East.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id KAA00911; Thu, 20 Jul 2000 10:05:02 -0400 (EDT)
Received: from sun.com (dhcp75-155 [129.148.75.155]) by sunlabs.East.Sun.COM (8.9.3+Sun/8.9.1) with ESMTP id KAA12225; Thu, 20 Jul 2000 10:05:01 -0400 (EDT)
Message-ID: <[e-mail]>
Date: Thu, 20 Jul 2000 10:04:23 -0400
From: Steve Hanna <[e-mail]>
Organization: Sun Microsystems, Inc.
X-Mailer: Mozilla 4.73 [en] (WinNT; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Stephen Kent <[e-mail]>
CC: Sharon Boeyen <[e-mail]>, [e-mail]
Subject: Re: Reverse paths
References: <[e-mail]> <v04220807b59baae71151@[128.33.238.44]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Stephen Kent wrote:
> I am uncomfortable with the proposal that we mandate both elements,
> as this would seem to imply that every CA would have to engage in
> reverse path certificate generation in all contexts.  Did I
> misunderstand the implication?

I'm not sure what you mean by "reverse path certificate generation". This change would require that
when a CA issues a cross certificate, they would have to place a copy of it in their own directory
entry (in the reverse element of a value of the crossCertificate attribute). It would not require the
generation of any additional certificates.

> I know that Entrust has always encouraged (required?) this type of
> cross certification among CAs, but it doesn't seem that other CA
> vendors or most users have. I would not think it appropriate to
> impose this sort of requirement, given the vendor-specific
> implications of such a change.

I don't see this as a vendor-specific issue, but rather as an aid to building certification paths.

-Steve


Received: from sothmxs01.entrust.com (gatekeeper.entrust.com [204.101.128.170]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id GAA21549 for <[e-mail]>; Thu, 20 Jul 2000 06:52:25 -0700 (PDT)
Received: by sothmxs01.entrust.com with Internet Mail Service (5.5.2650.21) id <PHL2GYQX>; Thu, 20 Jul 2000 09:54:31 -0400
Message-ID: <[e-mail]>
From: Sharon Boeyen <[e-mail]>
To: "'Stephen Kent'" <[e-mail]>
Cc: [e-mail]
Subject: RE: Reverse paths
Date: Thu, 20 Jul 2000 09:52:53 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain; charset="iso-8859-1"

Hi Steve,

I guess I should have made my thoughts a little clearer.

Rather than vendors, lets talk about trust models. Within a single 
hierarchy I agree that the current text is optimum, because of the point
that every certificate has one and only one superior certificate.

However, once you start connecting hierarchies together, e.g. through 
bridge CAs and once you moved out of hierarchies into distributed trust 
models, that condition no longer holds true. As bridges become more common 
and the certificates issued to and by bridges increases, the number of 
potential paths becomes quite large.In that trust model, the 
ONLY way that you prune branches, and eliminate potential paths that are 
not appropriate, is by building in the reverse direction. Building in the 
same direction as one would in a hierarchy means that you must build each 
complete path before processing any of the certificates. Building in the
reverse
direction for the distribution trust model allows early elimination 
of paths based on such issues as name constraints, policy constraints and 
many others. 

It is my opinion that recent events, such as the US Federal Bridge CA
activity 
have shown that a single global hierarchy does not work, that distributed
trust 
models are, in fact necessary as well. Because of these events and because
the 
issue was raised, not by me but by another vendor (Sean Mullan from Sun), I
thought
it was a reasonable recommendation to support now. Having said that, let me
clarify
what I meant. To answer your first question, no I don't mean to impose
reverse in 
all contexts. Nor do I mean to impose bilateral cross-certification. Rather,
I am 
suggesting mandating that, in addition to what PKIX says currently, a CA
that issues a certificate to another CA (where the subject CA is NOT a
subordinate CA to the issuing CA within a hierarchy), must place that
certificate in the reverse element of the cross certificate pairs attribute
of the its own directory entry. No impact within a hierarchy at all, no
requirement that cross certification be bilateral. Sorry for the confusion
and I hope this is a bit clearer. So I guess to summarize: 

- Within a strict hierarchy, the forward element must be populated
- At the root of a strict hierarchy that has cross-certified with CAs
outside  
  that hierarchy, both forward and reverse must be populated. In addition to
any 
  certificates that applied to the hierarchy itself, the forward element
would contain 
  any certificates issued to the root by an external CA and reverse would
contain 
  any certificates that the root had issued to external CAs - these need not
be pairs)
- Within a distributed trust model, both forward and reverse must be
populated (actually
  I suspect that only reverse is really needed but for backward
compatibility we'd 
  need to mandate both).

Finally, I don't normally talk about Entrust products on any public list,
but since
you raised it I feel it necessary to respond. Entrust products support both
hierarchical and distributed trust models. In the hierarchical case, we
build certification paths from the end-entity certificate to the root, in
the same way as other vendors and the same way PKIX outlines. In the
distributed trust model, we build certification paths in the opposite
direction (for efficiency reasons) using the reverse element. I don't
believe this is a vendor specific issue (note it was raised by Sun not by
Entrust), but I am certainly interested in hearing from other vendors and
especially from users and will support the consensus. In no way do I wish to
pursue another long drawn out debate on this, along the lines of a few years
ago. I merely thought that we had progressed to a point where bridge CAs and
distributed trust models were more generally accepted and the requirements
for populating reverse go hand in hand with that model.

Hope this clarifies my intent.

Cheers,
Sharon  
 

> -----Original Message-----
> From: Stephen Kent [mailto:[e-mail]]
> Sent: Wednesday, July 19, 2000 3:03 PM
> To: Sharon Boeyen
> Cc: [e-mail]
> Subject: RE: Reverse paths
> 
> 
> Sharon,
> 
> <snip>
> 
> 
> >I would like to support Sean's request that for the LDAPv3 schema we
> >consider making the reverse element mandatory along with the forward
> >element.
> >This would be a great step forward in supporting 
> interoperability among PKI
> >products and services and, since it does not impact existing 
> LDAPv2 systems,
> >
> >doesn't cause those previously deployed systems to be non-conformant.
> >
> >With both elements mandatory, regardless of the direction the path is
> >being built, the certificate using system will be able to locate the
> >information
> >it seeks.
> >
> 
> I am uncomfortable with the proposal that we mandate both elements, 
> as this would seem to imply that every CA would have to engage in 
> reverse path certificate generation in all contexts.  Did I 
> misunderstand the implication?
> I know that Entrust has always encouraged (required?) this type of 
> cross certification among CAs, but it doesn't seem that other CA 
> vendors or most users have. I would not think it appropriate to 
> impose this sort of requirement, given the vendor-specific 
> implications of such a change.
> 
> Steve
> 


Received: from dfw7-1.relay.mail.uu.net (dfw7-1.relay.mail.uu.net [199.171.54.106]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id GAA20416 for <[e-mail]>; Thu, 20 Jul 2000 06:22:32 -0700 (PDT)
Received: from xedia.com by dfw7sosrv11.alter.net with SMTP  (peer crosschecked as: madway.xedia.com [198.202.232.199]) id QQiyqv09495; Thu, 20 Jul 2000 13:25:06 GMT
Received: from tonga.xedia.com by xedia.com (4.1/SMI-4.1) id AA14254; Thu, 20 Jul 00 09:21:12 EDT
Received: by tonga.xedia.com (SMI-8.6/SMI-SVR4) id JAA00877; Thu, 20 Jul 2000 09:25:05 -0400
From: Paul Koning <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-Id: <[e-mail]>
Date: Thu, 20 Jul 2000 09:25:05 -0400 (EDT)
To: [e-mail]
Cc: [e-mail]
Subject: Re: Signing what you don't understand
References: <001b01bff250$38e01be0$[e-mail]>
X-Mailer: VM 6.72 under 21.1 (patch 9) "Canyonlands" XEmacs Lucid

>>>>> "Anders" == Anders Rundgren <[e-mail]> writes:

 Anders> Piers,
 >> I would welcome comments from this forum on their opinion of the
 >> validity of signatures where the private key and end-user are not
 >> co-located.

 Anders> This is now for real as VISA-EU has lost faith in the
 Anders> original SET model with local key/cert and will aggresively
 Anders> push a server-based model.  Way to go IMO!

What does that mean?

 Anders> But this was maybe more than you asked for, beacuse the
 Anders> signatures are also created on the server (wallet) which is
 Anders> not the same as downloading private keys when needed.

 Anders> In German unfortunately:

 Anders> http://www.visa.de/df/presse/pressetexte/000619_001.htm

Unfortunately that document doesn't actually say anything.  It's just
marketing vapor.  

Do you have a reference that contains information?

      paul


Received: from dfw7-1.relay.mail.uu.net (dfw7-1.relay.mail.uu.net [199.171.54.106]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id GAA19942 for <[e-mail]>; Thu, 20 Jul 2000 06:14:32 -0700 (PDT)
Received: from xedia.com by dfw7sosrv11.alter.net with SMTP  (peer crosschecked as: madway.xedia.com [198.202.232.199]) id QQiyqv29910; Thu, 20 Jul 2000 13:17:03 GMT
Received: from tonga.xedia.com by xedia.com (4.1/SMI-4.1) id AA14108; Thu, 20 Jul 00 09:13:09 EDT
Received: by tonga.xedia.com (SMI-8.6/SMI-SVR4) id JAA00867; Thu, 20 Jul 2000 09:17:02 -0400
From: Paul Koning <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-Id: <[e-mail]>
Date: Thu, 20 Jul 2000 09:17:02 -0400 (EDT)
To: [e-mail]
Cc: [e-mail], [e-mail]
Subject: Re: Signing what you don't understand
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
X-Mailer: VM 6.72 under 21.1 (patch 9) "Canyonlands" XEmacs Lucid

>>>>> "Ben" == Ben Laurie <[e-mail]> writes:

 Ben> Eric Murray wrote:
 >>  On Wed, Jul 19, 2000 at 06:53:00PM +0100, Ben Laurie wrote: >
 >> Paul Koning wrote: > > > > First of all, the private key is
 >> "always with the owner" *only* if you > > have a smartcard with
 >> embedded PKI engine.  Those exist but there > > certainly are
 >> plenty of PK signing scenarios where they are not used.  > > Woah!
 >> Smartcard salesman detected... what about, say, a Palm, or a >
 >> Psion? These have an advantage over smartcards, too, in that they
 >> have > UIs.
 >> 
 >> The UI on a Palm is really useful from a security standpoint.
 >> However, the OS with no memory protection negates any use that
 >> requires security.  The slow crypto performance doesn't help
 >> either.

 Ben> I'm not arguing with that - but how about the newer PC-style
 Ben> PDAs (haven't got around to finding out what's in them, but an
 Ben> MMU seems likely)?

If the applications are well-controlled the lack of MMU doesn't
matter.  I could point you to several examples of secure timesharing
systems built on top of apparently-insecure hardware.

Conversely, PC-style PDAs run PC-style applications and a PC-style OS,
and therefore are likely to be just as virus-friendly as the PCs are.

It's easy to build insecure products on any hardware, if your design
rule is to aim for flashy "features" and use those as a justification
for designing security chasms into the product.

The interesting question is where the Palm OS fits in this scale.  I
don't know from personal analysis.  I'd expect it to be somewhere in
the middle, though how far to the insecure side is the critical
question. 

    paul


Received: from unknown-147.101.pilot.net (unknown-147-101.pilot.net [198.232.147.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id FAA19013 for <[e-mail]>; Thu, 20 Jul 2000 05:49:16 -0700 (PDT)
Received: from unknown-24-5.pilot.net (unknown-24-5.pilot.net [206.189.24.5]) by unknown-147.101.pilot.net with ESMTP id FAA09670; Thu, 20 Jul 2000 05:51:48 -0700 (PDT)
Received: from ralsimcout.gecmc.ge.com (localhost [127.0.0.1]) by unknown-24-5.pilot.net with ESMTP id FAA19218; Thu, 20 Jul 2000 05:51:48 -0700 (PDT)
Received: by ralsimcout.gecmc.ge.COM with Internet Mail Service (5.5.2651.58) id <PFYKKF34>; Thu, 20 Jul 2000 08:51:45 -0400
Message-ID: <[e-mail]>
From: "Golkin, Ken (CAP, CMC)" <[e-mail]>
To: "'Stephen Kent'" <[e-mail]>
Cc: [e-mail]
Subject: RE: Signing what you don't understand
Date: Thu, 20 Jul 2000 08:51:45 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2651.58)
Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01BFF249.42DAC070"

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01BFF249.42DAC070
Content-Type: text/plain;
	charset="iso-8859-1"

I didn't sign in and most importantly there is persistent record of me
having entered.  There are other places that I have "signed in" and there
are indeed persistent records there.

-----Original Message-----
From: Stephen Kent [mailto:[e-mail]]
Sent: Wednesday, July 19, 2000 02:32 PM
To: Golkin, Ken (CAP, CMC)
Cc: [e-mail]
Subject: RE: Signing what you don't understand


Ken,

>This discussion seems to be confusing two different uses for certificates
>1) Authentication (I am who I say I am)
>2) Signature (I signed a legally binding document)
>
>In the first case I showed my company issue picture ID (certificate) 
>to the guard at the door and he let me in the building this morning.

Or, maybe you "signed in" as part of entering your workplace, ....

<snip>

Steve

------_=_NextPart_001_01BFF249.42DAC070
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Diso-8859-1">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
5.5.2651.75">
<TITLE>RE: Signing what you don't understand</TITLE>
</HEAD>
<BODY>

<P><FONT SIZE=3D2>I didn't sign in and most importantly there is =
persistent record of me having entered.&nbsp; There are other places =
that I have &quot;signed in&quot; and there are indeed persistent =
records there.</FONT></P>

<P><FONT SIZE=3D2>-----Original Message-----</FONT>
<BR><FONT SIZE=3D2>From: Stephen Kent [<A =
HREF=3D"mailto:[e-mail]">mailto:[e-mail]</A>]</FONT>
<BR><FONT SIZE=3D2>Sent: Wednesday, July 19, 2000 02:32 PM</FONT>
<BR><FONT SIZE=3D2>To: Golkin, Ken (CAP, CMC)</FONT>
<BR><FONT SIZE=3D2>Cc: [e-mail]</FONT>
<BR><FONT SIZE=3D2>Subject: RE: Signing what you don't =
understand</FONT>
</P>
<BR>

<P><FONT SIZE=3D2>Ken,</FONT>
</P>

<P><FONT SIZE=3D2>&gt;This discussion seems to be confusing two =
different uses for certificates</FONT>
<BR><FONT SIZE=3D2>&gt;1) Authentication (I am who I say I am)</FONT>
<BR><FONT SIZE=3D2>&gt;2) Signature (I signed a legally binding =
document)</FONT>
<BR><FONT SIZE=3D2>&gt;</FONT>
<BR><FONT SIZE=3D2>&gt;In the first case I showed my company issue =
picture ID (certificate) </FONT>
<BR><FONT SIZE=3D2>&gt;to the guard at the door and he let me in the =
building this morning.</FONT>
</P>

<P><FONT SIZE=3D2>Or, maybe you &quot;signed in&quot; as part of =
entering your workplace, ....</FONT>
</P>

<P><FONT SIZE=3D2>&lt;snip&gt;</FONT>
</P>

<P><FONT SIZE=3D2>Steve</FONT>
</P>

</BODY>
</HTML>
------_=_NextPart_001_01BFF249.42DAC070--


Received: from d1o69.telia.com ([e-mail] [62.20.144.241]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id FAA18397 for <[e-mail]>; Thu, 20 Jul 2000 05:39:59 -0700 (PDT)
Received: from mega (t3o69p114.telia.com [62.20.145.114]) by d1o69.telia.com (8.8.8/8.8.8) with SMTP id OAA17667; Thu, 20 Jul 2000 14:42:27 +0200 (CEST)
Message-ID: <001b01bff250$38e01be0$[e-mail]>
From: "Anders Rundgren" <[e-mail]>
To: <[e-mail]>, "'Jean Abraham'" <[e-mail]>, "'Paul Koning'" <[e-mail]>
Cc: <[e-mail]>
Subject: Re: Signing what you don't understand
Date: Thu, 20 Jul 2000 15:41:32 +0200
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 4.72.3110.5
X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by ns.secondary.com id FAA18399

Piers,

>I would welcome comments from this forum on their opinion of the validity of
>signatures where the private key and end-user are not co-located.

This is now for real as VISA-EU has lost faith in the original SET model
with local key/cert and will aggresively push a server-based model.  Way to go IMO!

But this was maybe more than you asked for, beacuse the signatures are
also created on the server (wallet) which is not the same as downloading
private keys when needed.

In German unfortunately:

http://www.visa.de/df/presse/pressetexte/000619_001.htm

Anders




Received: from mail.arabtrust.com (mail.arabtrust.com [216.247.149.19]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id CAA08448 for <[e-mail]>; Thu, 20 Jul 2000 02:39:31 -0700 (PDT)
Received: from jean [195.39.160.196] by mail.arabtrust.com (SMTPD32-6.00) id A9F826EE00CE; Thu, 20 Jul 2000 05:44:24 -0400
From: "Jean Abraham" <[e-mail]>
To: "Simon McMahon" <[e-mail]>, <[e-mail]>, "Tony Bartoletti" <[e-mail]>
Subject: RE: A Real Rationale for Dedicated Keys
Date: Thu, 20 Jul 2000 12:40:42 +0300
Message-ID: <[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0)
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6600
In-reply-to: <01a601bff229$a8bcf540$[e-mail]>

Simon,

Could you tell me what has NR (Non-Repudation) to do with CA control key
generation.

Jean

-----Original Message-----
From: Simon McMahon [mailto:[e-mail]]
Sent: Thursday, July 20, 2000 12:05 PM
To: [e-mail]; Tony Bartoletti
Subject: Re: A Real Rationale for Dedicated Keys


> My point being, the key-owner is the primary point of
> control in enforcing a "one-key, one-cert" personal regime.
>
The "key generator" is really the primary point of control and need not be
the same as the "key owner" (the one who makes signatures). Some CAs insist
on having some control over key origin, key generation, or at least the
equipment used to do it so that uncontrolled certifications and hackable
private keys can be avoided. I would expect that all commercial CAs that
generate certs intended for NR usage will have to control key generation.

Does it really matter how many certificates there are for a public key as
long as the one specifying NR relates to a private key that cannot be
duplicated ? I dont see how multiple certs for a key is a threat to
non-repudiation of signatures. Only private key exposure / duplication is.

Regards,

Simon McMahon.
ERACOM Pty. Ltd.





Received: from mail.arabtrust.com (mail.arabtrust.com [216.247.149.19]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id CAA08067 for <[e-mail]>; Thu, 20 Jul 2000 02:32:27 -0700 (PDT)
Received: from jean [195.39.160.196] by mail.arabtrust.com (SMTPD32-6.00) id A84A26DA00CE; Thu, 20 Jul 2000 05:37:14 -0400
From: "Jean Abraham" <[e-mail]>
To: <[e-mail]>, "'Paul Koning'" <[e-mail]>
Cc: <[e-mail]>
Subject: RE: Signing what you don't understand
Date: Thu, 20 Jul 2000 12:33:31 +0300
Message-ID: <[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0)
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6600
In-reply-to: <000301bff227$44419be0$[e-mail]>

Piers,

If you would take in to consideration certs that sign emails only then the
private key is in the browser or in the machine from which the cert was
requested for.  When you speak of web server certs then the private key is
with the client's web server.  If a private key is not with the owner then
the owner cannot encrypt or sign or open any email that has been previously
signed.  At runtime you are speaking of is online shopping then you would
have https:// which is SSL then no private key downloaded to someone's PC.

You can test the above by applying for a cert that signs email, then before
installation of the cert reformat the system and you will see that the cert
will not install.  For the web server cert you can test, before installation
of the cert reconfigure the web server or format the system.

The phyical location of the private key is relevant because with that anyone
can decrypt any messages encrypted by the persons public key by getting hold
of the private key. But the phyiscal location of the public key is
irrelevant.

Validity of the signatures have nothing to do with the private key and
end-user.  It should be validity of certs rather than signatures.  A cert
signs and encrypts a particular information.



Jean

-----Original Message-----
From: Piers Chivers [mailto:[e-mail]]
Sent: Thursday, July 20, 2000 11:48 AM
To: 'Jean Abraham'; 'Paul Koning'
Cc: [e-mail]
Subject: RE: Signing what you don't understand


Jean,
I disagree with your comment that the "most important apsect...is that the
private key is always with the owner and never in transist" (I think you
meant transit).

Several leading PKI vendors have implemented systems where the private key
is held on a central Web server and then downloaded at run time to a web
browser.  Are you saying that signatures created using these keys are
invalid?

I would argue that the important point is that the key and user are
"strongly-bound".  The system should ensure that the key is only useable by
the intended end-user.  The physical location of the key is irrelevant.
Indeed, it could be located thousand of miles away over the Internet.

I would welcome comments from this forum on their opinion of the validity of
signatures where the private key and end-user are not co-located.

Thanks,
Piers

-----Original Message-----
From: Jean Abraham [mailto:[e-mail]]
Sent: 19 July 2000 14:32
To: Paul Koning
Cc: [e-mail]
Subject: RE: Signing what you don't understand


Digital signatures generation or creation is not based on the O/S of a
particular PC but on the software that is used to generate it.  The most
important apsect in a digital certificate(which is used to create a digital
signature - end user) is that the private key is always with the owner and
never in transist.  And the private key of the CA that signs the end-user
certs are NEVER in transist, therefore the authenticity of the certificate
is good and compromise of the end-user certificate ia void only from the PC
it would be installed on.

Jean

-----Original Message-----
From: Paul Koning [mailto:[e-mail]]
Sent: Wednesday, July 19, 2000 4:27 PM
To: [e-mail]
Cc: [e-mail]
Subject: RE: Signing what you don't understand


>>>>> "Jean" == Jean Abraham <[e-mail]> writes:

 Jean> Hi, There is a difference actually,

 Jean> When you sign the fedex package the person taking your
 Jean> signature doesnot know if its who you say you are. But in the
 Jean> case of a digital certificate only you can sign a email and
 Jean> from YOUR OWN computer which YOU ONLY have access for.

If the computer is a PC running the most popular PC operating systems,
that statement is extremely optimistic at best.

So long as security remains a non-goal of such operating systems,
digital signatures produduced by such systems will not offer any
meaningful guarantees of any kind.

	   paul



----------------------------------------------------------------------------
--------------
This message is for the named persons use only.  It may contain
confidential, proprietary or legally privileged information.  No
confidentiality or privilege is waived or lost by any mistransmission.  If
you receive this message in error, please immediately delete it and all
copies of it from your system, destroy any hard copies of it and notify the
sender.  You must not, directly or indirectly, use, disclose, distribute,
print, or copy any part of this message if you are not the intended
recipient. PROTEK Network Management Group and each of its subsidiaries
reserve the right to monitor all e-mail communications through its networks.
Any views expressed in this message are those of the individual sender,
except where the message states otherwise and the sender is authorised to
state them to be the views of any such entity.







Received: from diablo.OntheNet.com.au (diablo.OntheNet.com.au [203.10.89.2]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id BAA06586 for <[e-mail]>; Thu, 20 Jul 2000 01:54:06 -0700 (PDT)
Received: from msimon (pc3.eracom.com.au [203.144.16.147]) by diablo.OntheNet.com.au (8.9.3/8.9.3) with SMTP id SAA22665; Thu, 20 Jul 2000 18:56:38 +1000 (EST)
Message-ID: <01a601bff229$a8bcf540$[e-mail]>
From: "Simon McMahon" <[e-mail]>
To: <[e-mail]>, "Tony Bartoletti" <[e-mail]>
References: <[e-mail]>
Subject: Re: A Real Rationale for Dedicated Keys
Date: Thu, 20 Jul 2000 19:05:01 +1000
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.00.2314.1300
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300

> My point being, the key-owner is the primary point of
> control in enforcing a "one-key, one-cert" personal regime.
>
The "key generator" is really the primary point of control and need not be
the same as the "key owner" (the one who makes signatures). Some CAs insist
on having some control over key origin, key generation, or at least the
equipment used to do it so that uncontrolled certifications and hackable
private keys can be avoided. I would expect that all commercial CAs that
generate certs intended for NR usage will have to control key generation.

Does it really matter how many certificates there are for a public key as
long as the one specifying NR relates to a private key that cannot be
duplicated ? I dont see how multiple certs for a key is a threat to
non-repudiation of signatures. Only private key exposure / duplication is.

Regards,

Simon McMahon.
ERACOM Pty. Ltd.




Received: from wssone.bj.co.uk (wssone.bj.co.uk [194.72.164.250]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id BAA06087 for <[e-mail]>; Thu, 20 Jul 2000 01:45:49 -0700 (PDT)
Received: from 194.72.164.27 by wssone.bj.co.uk with ESMTP (WorldSecure Server SMTP Relay(WSS) v4.3); Thu, 20 Jul 00 09:50:55 +0100
X-Server-Uuid: 1407cc62-e1e1-11d2-808b-0060971f0dc2
Received: from piers2k (host62-6-112-70.host.btclick.com [62.6.112.70]) by bjex1.bj.co.uk with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2448.0) id MC4C48C1; Thu, 20 Jul 2000 09:49:04 +0100
Reply-to: [e-mail]
From: "Piers Chivers" <[e-mail]>
To: "'Jean Abraham'" <[e-mail]>, "'Paul Koning'" <[e-mail]>
cc: [e-mail]
Subject: RE: Signing what you don't understand
Date: Thu, 20 Jul 2000 09:48:23 +0100
Message-ID: <000301bff227$44419be0$[e-mail]>
MIME-Version: 1.0
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2910.0)
In-Reply-To: <[e-mail]>
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700
Importance: Normal
X-WSS-ID: 156862E565363-01-01
Content-Type: text/plain;  charset=iso-8859-1
Content-Transfer-Encoding: 7bit

Jean,
I disagree with your comment that the "most important apsect...is that the
private key is always with the owner and never in transist" (I think you
meant transit).

Several leading PKI vendors have implemented systems where the private key
is held on a central Web server and then downloaded at run time to a web
browser.  Are you saying that signatures created using these keys are
invalid?

I would argue that the important point is that the key and user are
"strongly-bound".  The system should ensure that the key is only useable by
the intended end-user.  The physical location of the key is irrelevant.
Indeed, it could be located thousand of miles away over the Internet.

I would welcome comments from this forum on their opinion of the validity of
signatures where the private key and end-user are not co-located.

Thanks,
Piers

-----Original Message-----
From: Jean Abraham [mailto:[e-mail]]
Sent: 19 July 2000 14:32
To: Paul Koning
Cc: [e-mail]
Subject: RE: Signing what you don't understand


Digital signatures generation or creation is not based on the O/S of a
particular PC but on the software that is used to generate it.  The most
important apsect in a digital certificate(which is used to create a digital
signature - end user) is that the private key is always with the owner and
never in transist.  And the private key of the CA that signs the end-user
certs are NEVER in transist, therefore the authenticity of the certificate
is good and compromise of the end-user certificate ia void only from the PC
it would be installed on.

Jean

-----Original Message-----
From: Paul Koning [mailto:[e-mail]]
Sent: Wednesday, July 19, 2000 4:27 PM
To: [e-mail]
Cc: [e-mail]
Subject: RE: Signing what you don't understand


>>>>> "Jean" == Jean Abraham <[e-mail]> writes:

 Jean> Hi, There is a difference actually,

 Jean> When you sign the fedex package the person taking your
 Jean> signature doesnot know if its who you say you are. But in the
 Jean> case of a digital certificate only you can sign a email and
 Jean> from YOUR OWN computer which YOU ONLY have access for.

If the computer is a PC running the most popular PC operating systems,
that statement is extremely optimistic at best.

So long as security remains a non-goal of such operating systems,
digital signatures produduced by such systems will not offer any
meaningful guarantees of any kind.

	   paul



------------------------------------------------------------------------------------------
This message is for the named persons use only.  It may contain confidential, proprietary or legally privileged information.  No confidentiality or privilege is waived or lost by any mistransmission.  If you receive this message in error, please immediately delete it and all copies of it from your system, destroy any hard copies of it and notify the sender.  You must not, directly or indirectly, use, disclose, distribute, print, or copy any part of this message if you are not the intended recipient. PROTEK Network Management Group and each of its subsidiaries reserve the right to monitor all e-mail communications through its networks.  Any views expressed in this message are those of the individual sender, except where the message states otherwise and the sender is authorised to state them to be the views of any such entity.






Received: from d1o69.telia.com ([e-mail] [62.20.144.241]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id BAA05647 for <[e-mail]>; Thu, 20 Jul 2000 01:37:54 -0700 (PDT)
Received: from mega (t5o69p12.telia.com [213.64.110.12]) by d1o69.telia.com (8.8.8/8.8.8) with SMTP id KAA12519; Thu, 20 Jul 2000 10:40:25 +0200 (CEST)
Message-ID: <001401bff22e$699b5c30$[e-mail]>
From: "Anders Rundgren" <[e-mail]>
To: "Peter Lipp" <[e-mail]>
Cc: <[e-mail]>
Subject: Re: Value of smart cards. Re: Signing what you don't understand
Date: Thu, 20 Jul 2000 11:39:31 +0200
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 4.72.3110.5
X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by ns.secondary.com id BAA05649

Peter,
regarding WAP I think it was "invented" to cope with the extremely
low bandwith and high latency available in GSM.  Unfortuntely such bandwidth
and latency is useless anyway.  And prices on circuit-switched GSM are
much too high to make WAP interesting except for a few proffesionals.
And time has showed that only when technology reaches the masses it
becomes really interesting.  So we will have to wait a while to get
GPRS/UMTS, Bluettooth, Palm-like displays and JVMs etc.
And to get phones that update themselves whenever there is
a new OS-version.  The mobile phone makers are already facing
considerable "PC-misery" with incompatibility between WAP-browsers,
upgrading hassles and unreliable operation.  Although it is
nice with standards I still believe that it is too hard to implement
many standards so the best is really that just 2-3 mobile OS survives.
This is awkward for mobile phones makers who believe(d) that they
should "differentiate" with software.  I don't think that strategy scales
very well as it will lock the market to certain operators and content
providers.  Essentially they can only differentiate on purely exernal stuff
such as display quality, battery capacity, packaging, chicness, pricing
and only to a minor extent on local software features. 

Anders


-----Original Message-----
From: Peter Lipp <[e-mail]>
To: Anders Rundgren <[e-mail]>
Cc: [e-mail] <[e-mail]>
Date: Thursday, July 20, 2000 09:47
Subject: AW: Value of smart cards. Re: Signing what you don't understand


> as you say.  But the SIM/WIM card will. Actually 300 million
> *existing* customers can't be wrong!
While the pure number of customers does not prove anything (they would have
used that technology without any card on it) it definitely could provide a
solid basis for deployment. Pity is that the vendors decide to reinvent the
world with all the WAP-versions of whatever already had been defined... Our
experience with one of the vendors in an EU-project showed lack of interest
in implementing relevant standards upcoming in the EU, as long as they don't
start with WA(P).

Peter






Received: from freeby.ben.algroup.co.uk (sockittome.aldigital.co.uk [194.128.162.252]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id BAA05328 for <[e-mail]>; Thu, 20 Jul 2000 01:34:30 -0700 (PDT)
Received: from algroup.co.uk (naughty.ben.algroup.co.uk [193.133.15.107]) by freeby.ben.algroup.co.uk (8.6.12/8.6.12) with ESMTP id JAA16339; Thu, 20 Jul 2000 09:51:44 +0100
Message-ID: <[e-mail]>
Date: Thu, 20 Jul 2000 09:36:49 +0100
From: Ben Laurie <[e-mail]>
Organization: A.L. Group plc
X-Mailer: Mozilla 4.7 [en] (WinNT; I)
MIME-Version: 1.0
To: Eric Murray <[e-mail]>
CC: [e-mail]
Subject: Re: Signing what you don't understand
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Eric Murray wrote:
> 
> On Wed, Jul 19, 2000 at 06:53:00PM +0100, Ben Laurie wrote:
> > Paul Koning wrote:
> > >
> > > First of all, the private key is "always with the owner" *only* if you
> > > have a smartcard with embedded PKI engine.  Those exist but there
> > > certainly are plenty of PK signing scenarios where they are not used.
> >
> > Woah! Smartcard salesman detected... what about, say, a Palm, or a
> > Psion? These have an advantage over smartcards, too, in that they have
> > UIs.
> 
> The UI on a Palm is really useful from a security standpoint.  However,
> the OS with no memory protection negates any use that requires security.
> The slow crypto performance doesn't help either.

I'm not arguing with that - but how about the newer PC-style PDAs
(haven't got around to finding out what's in them, but an MMU seems
likely)?

> The ideal token for carrying private keys and digitally signing
> documents would be something with a display (like a Palm) and an OS like
> a smartcard's that protects the different applications and their keys
> from each other.

EROS!!!

> Unfortunately that display costs a lot.  The CPU power to render anything
> interesting on it the display, and to do crypto in reasonable speed adds
> to the price.  With a readable display (but not pressure-sensitive
> like a Palm), probably 5-10x a high-end smartcard.

See below.

> > Smartcards are a technology whose time never really arrived, and is
> > rapidly passing. IMO.
> 
> The problem isn't that they're not being used, it's that they've
> never come close to matching the hype, and they probably won't ever.

Quite. Whereas PDAs are everywhere.

Cheers,

Ben.

--
http://www.apache-ssl.org/ben.html

Coming to ApacheCon Europe 2000? http://apachecon.com/


Received: from freeby.ben.algroup.co.uk (sockittome.aldigital.co.uk [194.128.162.252]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id BAA04892 for <[e-mail]>; Thu, 20 Jul 2000 01:26:53 -0700 (PDT)
Received: from algroup.co.uk (naughty.ben.algroup.co.uk [193.133.15.107]) by freeby.ben.algroup.co.uk (8.6.12/8.6.12) with ESMTP id JAA16271; Thu, 20 Jul 2000 09:43:30 +0100
Message-ID: <[e-mail]>
Date: Thu, 20 Jul 2000 09:28:35 +0100
From: Ben Laurie <[e-mail]>
Organization: A.L. Group plc
X-Mailer: Mozilla 4.7 [en] (WinNT; I)
MIME-Version: 1.0
To: Irene Gassko <[e-mail]>
CC: Simon McMahon <[e-mail]>, [e-mail], [e-mail]
Subject: Re: Current signature formats insufficient
References: <000901bfeb64$38642f50$0201010a@intergalactic> <[e-mail]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Irene Gassko wrote:
> 
> Hello,
> 
> Blind signatures provide another viewpoint. Here a signer does not
> know what it is signing but the key used indicates the value of a
> monetary unit.

Very good point (BTW, see http://anoncvs.aldigital.co.uk/lucre/ for a
free implementation of blinded signing) - but in this case the signer
_does_ know that it is effectively signing a random number. But this is
a good example of why the _key_ should say what it can be used for (I
realise the signature could, too, but that's a waste of space, surely?).

Cheers,

Ben.

--
http://www.apache-ssl.org/ben.html

Coming to ApacheCon Europe 2000? http://apachecon.com/


Received: from iaik.tu-graz.ac.at (excalibur.iaik.tu-graz.ac.at [129.27.152.30]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id AAA02982 for <[e-mail]>; Thu, 20 Jul 2000 00:45:02 -0700 (PDT)
Received: from PLIPP2 [129.27.152.34] by iaik.tu-graz.ac.at (SMTPD32-6.00) id AE805650116; Thu, 20 Jul 2000 09:47:12 +0200
Received: from 127.0.0.1 [127.0.0.1] by PLIPP2 (IAIK S/MIME Mapper 2.0beta3 22/March/2000); Do, 20 Jul 2000 09:48:23 +0100
From: "Peter Lipp" <[e-mail]>
To: "Anders Rundgren" <[e-mail]>
Cc: <[e-mail]>
Subject: AW: Value of smart cards. Re: Signing what you don't understand
Date: Thu, 20 Jul 2000 09:48:22 +0200
Message-ID: <[e-mail]>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=sha1; boundary="--IAIK.SMIME.MAPPER.F12BC676--"; protocol="application/x-pkcs7-signature"
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0)
In-reply-to: <003901bff1c7$9e2e3ec0$[e-mail]>
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700
Importance: Normal

This is a multipart MIME message, it may require a MIME capable user agent.
----IAIK.SMIME.MAPPER.F12BC676--
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

> as you say.  But the SIM/WIM card will. Actually 300 million
> *existing* customers can't be wrong!
While the pure number of customers does not prove anything (they would have
used that technology without any card on it) it definitely could provide a
solid basis for deployment. Pity is that the vendors decide to reinvent the
world with all the WAP-versions of whatever already had been defined... Our
experience with one of the vendors in an EU-project showed lack of interest
in implementing relevant standards upcoming in the EU, as long as they don't
start with WA(P).

Peter



----IAIK.SMIME.MAPPER.F12BC676--
Content-Type: application/x-pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAA
oIIVIDCCBE0wggM5oAMCAQICAwGGrTAJBgUrDgMCHQUAMIIBEzELMAkGA1UEBhMC
QVQxDzANBgNVBAgTBlN0eXJpYTENMAsGA1UEBxMER1JBWjEZMBcGA1UECRMQSW5m
ZmVsZGdhc3NlIDE2YTEmMCQGA1UEChMdR1JBWiBVTklWRVJTSVRZIE9GIFRFQ0hO
T0xPR1kxRzBFBgNVBAsTPkluc2l0dXRlIGZvciBBcHBsaWVkIEluZm9ybWF0aW9u
IFByb2Nlc3NpbmcgYW5kIENvbW11bmljYXRpb25zMRkwFwYDVQQLExBJQUlLIElO
VFJBTkVUIENBMRkwFwYDVQQDExBJQUlLIFRVLUdSQVogU0lHMSIwIAYDVQQMExlJ
QUlLIGVsZWN0cm9uaWMgc2lnbmF0dXJlMB4XDTk5MTEyODIwMjIzOVoXDTAwMTEy
ODIwMjIzOVowgZMxCzAJBgNVBAYTAkFUMSYwJAYDVQQKEx1HUkFaIFVOSVZFUlNJ
VFkgT0YgVEVDSE5PTE9HWTFHMEUGA1UECxM+SW5zaXR1dGUgZm9yIEFwcGxpZWQg
SW5mb3JtYXRpb24gUHJvY2Vzc2luZyBhbmQgQ29tbXVuaWNhdGlvbnMxEzARBgNV
BAMTClBldGVyIExpcHAwgZ0wDQYJKoZIhvcNAQEBBQADgYsAMIGHAoGBAM5s1aJQ
xXxczmMNSJtL4cv9nhMA+dtbUN4+DA5qfZBqcwR2zWw2VulPyrAeZDA1HFP8zlpk
PlC5C4hNnX+p7QdG8u0LMk45FwaatOm2r2gEmTYGH/znwQSrKTsZXi0d0VHZV0TX
yU/I3SlYxSXfjFafAVE09KKa2m8jcUOhF97dAgEDo4G0MIGxMDgGA1UdHwQxMC8w
LaAroCmkJzAlMRAwDgYDVQQKEwdpYWlrLmF0MREwDwYDVQQDEwhJQUlLQ1JMMTAR
BglghkgBhvhCAQEEBAMCAKAwKAYJYIZIAYb4QgENBBsWGVVzZXItQ2VydGlmaWNh
dGUgSU5UUkFORVQwDAYDVR0TBAUwAwEBADAdBgNVHREEFjAUgRJQZXRlci5MaXBw
QGlhaWsuYXQwCwYDVR0PBAQDAgbAMAkGBSsOAwIdBQADggEBAA4r/qDOLW8ChbuC
2pGzcf74Uv190Q45aHj99lMgNhPQRIVaLLNXJH+NYJxEvIwmVOWIXjdA03TqkOOq
FJ/tK31wV+RbrvaPaVUwRjPhC2f8rr+K6pp9mzUC1SolUEbRWVHgOZGsbnEJkTEr
oJOelFdKr0coT+Xeje/fI5d50P3CwsJLR2PFkiswnOoWBINi2nq6MGZ7fwmzW8F9
ZVstrNMQYCeEj4V2SR/YIUrDxsdqMQyorBe/su3eab3fOpPlonb86KKWH6jLdgpi
KGRoHGWeGgAWlMB0HdxaupX7Lm8LhVYZOdh9SpvO8AdhMyOXNHOKF6sMXCZvSEHy
2XUvbmAwggRUMIIDQKADAgECAgJOIDAJBgUrDgMCHQUAMIGZMQswCQYDVQQGEwJB
VDEmMCQGA1UEChMdR1JBWiBVTklWRVJTSVRZIE9GIFRFQ0hOT0xPR1kxRzBFBgNV
BAsTPkluc2l0dXRlIGZvciBBcHBsaWVkIEluZm9ybWF0aW9uIFByb2Nlc3Npbmcg
YW5kIENvbW11bmljYXRpb25zMRkwFwYDVQQDExBJQUlLIElOVFJBTkVUIENBMB4X
DTk5MTExNDEyNTE0OVoXDTAyMTIzMTIyNTkzMFowggETMQswCQYDVQQGEwJBVDEP
MA0GA1UECBMGU3R5cmlhMQ0wCwYDVQQHEwRHUkFaMRkwFwYDVQQJExBJbmZmZWxk
Z2Fzc2UgMTZhMSYwJAYDVQQKEx1HUkFaIFVOSVZFUlNJVFkgT0YgVEVDSE5PTE9H
WTFHMEUGA1UECxM+SW5zaXR1dGUgZm9yIEFwcGxpZWQgSW5mb3JtYXRpb24gUHJv
Y2Vzc2luZyBhbmQgQ29tbXVuaWNhdGlvbnMxGTAXBgNVBAsTEElBSUsgSU5UUkFO
RVQgQ0ExGTAXBgNVBAMTEElBSUsgVFUtR1JBWiBTSUcxIjAgBgNVBAwTGUlBSUsg
ZWxlY3Ryb25pYyBzaWduYXR1cmUwggEgMA0GCSqGSIb3DQEBAQUAA4IBDQAwggEI
AoIBAQDSyhKuZGsL1EPk5mOTG8RzhHS/Va+/WYjs7Zm91nwVHu1+XFLJeJ85AICk
SQ7yq9lWa9ur34cywbNhl/9QxaOBOiHkMvAuXxs2Bq/uhe/hEb1T7XgO12ptG80q
SOP8/nKxw1PXlbUkd1rD9727mO/5tpvagEQfz7CZQ5wI4HkrNw5uH/vsJ72wRcRT
FzmHy/nOX3Y9sXLd/V7TG8j1x0oNWsR3b0tHEWM+Oc1Qq5FfCknoMMCitSD38cUL
CCcLJtVxkOiapWaZrDXUAuhvshhsRPjkXh6IzpqsZEtRI64SurLoUUShPv108ELE
6rfQKtm9FNnlFRD954diwfFHko/lAgEFozMwMTARBglghkgBhvhCAQEEBAMCAAIw
DwYDVR0TBAgwBgEB/wIBATALBgNVHQ8EBAMCAQYwCQYFKw4DAh0FAAOCAQEAc26n
vl5jQspoqD0fzjpZkqGARmFVj9uHNqVoWttqw/y6t46OhJUcePEmXkKsFP4NuCFx
2MyvmbWb6R6QNQ5WfoarGWyQ382cQN6mccPS5weDjXAzYeGZUkx99K70ncVxkwq7
rINAhJtari2XSLxmfBJyTYrZuWEgd5C9NBuf2u3iZyArarOKPbrBjZxjmXwBbZ7t
sfAhSVMGSr2ODgQcQjf7ZndNIsQZL75HkN21Pj+/x3wnMCAQF50+Pt8ioAgZ/SAu
dxmdYNr2itI0vmsV/xjD1NQuwb6+HwmR2LxclhMzrT1VbtTDkRLD/h8LKC1OpKV8
lQlS7Ir+Od/XNafKJjCCA8owggKyoAMCAQICAQEwDQYJKoZIhvcNAQEEBQAwgZkx
CzAJBgNVBAYTAkFUMSYwJAYDVQQKEx1HUkFaIFVOSVZFUlNJVFkgT0YgVEVDSE5P
TE9HWTFHMEUGA1UECxM+SW5zaXR1dGUgZm9yIEFwcGxpZWQgSW5mb3JtYXRpb24g
UHJvY2Vzc2luZyBhbmQgQ29tbXVuaWNhdGlvbnMxGTAXBgNVBAMTEElBSUsgSU5U
UkFORVQgQ0EwHhcNOTkxMTE0MTIzMTU5WhcNMDIxMjMxMjI1OTMwWjCBmTELMAkG
A1UEBhMCQVQxJjAkBgNVBAoTHUdSQVogVU5JVkVSU0lUWSBPRiBURUNITk9MT0dZ
MUcwRQYDVQQLEz5JbnNpdHV0ZSBmb3IgQXBwbGllZCBJbmZvcm1hdGlvbiBQcm9j
ZXNzaW5nIGFuZCBDb21tdW5pY2F0aW9uczEZMBcGA1UEAxMQSUFJSyBJTlRSQU5F
VCBDQTCCASAwDQYJKoZIhvcNAQEBBQADggENADCCAQgCggEBAMLr+IHe6qeAtYLk
fvxyRI6ogrvBP5iKPEBZ7j3T1yVJL7CDPGH8hgPsI4qt6Fnzh2MuAq84JS58zX5x
LqEUC/E5xw1xyAzorC6yWwxGRhb+fvTg4OlM2JVsTlyJO6F/BWlXuZU33lgGky/R
X84sItXKhmhbUPscnHYBsVKcQO5rFcRrJK/5c1Mha/bcQNVDQaQw+HRCvr7T4mAV
Yi+DVJv6jb393CoDBnffGP/mcIkFGFO5D6lyfP8QiSs06+0unIYWwUn1YzQI2RNB
AjXrCuAJtlf4qYrGXC09Neg8ymoI2uOglo6scWiZXt/prxWoi+btPX8oWDl5+7DE
tCf0rx8CAQejHTAbMAwGA1UdEwQFMAMBAf8wCwYDVR0PBAQDAgEGMA0GCSqGSIb3
DQEBBAUAA4IBAQAfdOMJ/ePlmrY0flkgiL6vyRDBuWGcIaB/oGofngJzbQLa7X2s
hWzpIiVpvo64XcjIBuocpErhIQfc2UZTSqYYT7R2Uydh0wVeqScURuwuihFURPhI
7GWCSrNwym2lrwsva2Xh/MTyzhXs9vo29dP2djjelN8n347dXhKJOYJ0tsA583af
EKmKvkfzAb+sQLxEmPyasQTCGJMec/iWjLTsEDRfCrROYVgDZ4NcCpiRSv9mWw6s
PYB8Chf5fJq1waFzluFYSUkuF24NKVopr1E4dKt2Lc1zdMRGRztKQWeUiBLkqFCQ
xsi6iZrl1nvMCdF+scuLj7G4lNshx6n1ZcabMIIETTCCAzmgAwIBAgIDAw1NMAkG
BSsOAwIdBQAwggETMQswCQYDVQQGEwJBVDEPMA0GA1UECBMGU3R5cmlhMQ0wCwYD
VQQHEwRHcmF6MRkwFwYDVQQJExBJbmZmZWxkZ2Fzc2UgMTZhMSYwJAYDVQQKEx1H
UkFaIFVOSVZFUlNJVFkgT0YgVEVDSE5PTE9HWTFHMEUGA1UECxM+SW5zaXR1dGUg
Zm9yIEFwcGxpZWQgSW5mb3JtYXRpb24gUHJvY2Vzc2luZyBhbmQgQ29tbXVuaWNh
dGlvbnMxGTAXBgNVBAsTEElBSUsgSU5UUkFORVQgQ0ExGzAZBgNVBAMTEklBSUsg
VFUtR1JBWiBDUllQVDEgMB4GA1UEDBMXSUFJSyBjb25maWRlbnRpYWxpdHkgQ0Ew
HhcNOTkxMTI4MjAyMzM4WhcNMDAxMTI4MjAyMzM4WjCBkzELMAkGA1UEBhMCQVQx
JjAkBgNVBAoTHUdSQVogVU5JVkVSU0lUWSBPRiBURUNITk9MT0dZMUcwRQYDVQQL
Ez5JbnNpdHV0ZSBmb3IgQXBwbGllZCBJbmZvcm1hdGlvbiBQcm9jZXNzaW5nIGFu
ZCBDb21tdW5pY2F0aW9uczETMBEGA1UEAxMKUGV0ZXIgTGlwcDCBnTANBgkqhkiG
9w0BAQEFAAOBiwAwgYcCgYEAvQe3ZdxrE2Nv5z2ZLink1P2MFeQb5gYrS55w4jsX
ZGD5v9Ajnv3w30Ajcn7jI+blIvYYpmNQV476+aUHNZFUML/KN5WGVXfdBOxb2n+6
Porez8KMnUlq3cCvAdhVdquFjwaRHO5k7gY80hNAfVker52A1aXbrT0TaWGlCl25
sq0CAQWjgbQwgbEwOAYDVR0fBDEwLzAtoCugKaQnMCUxEDAOBgNVBAoTB2lhaWsu
YXQxETAPBgNVBAMTCElBSUtDUkwxMBEGCWCGSAGG+EIBAQQEAwIAoDAoBglghkgB
hvhCAQ0EGxYZVXNlci1DZXJ0aWZpY2F0ZSBJTlRSQU5FVDAMBgNVHRMEBTADAQEA
MB0GA1UdEQQWMBSBElBldGVyLkxpcHBAaWFpay5hdDALBgNVHQ8EBAMCA3gwCQYF
Kw4DAh0FAAOCAQEAhvbZ0/1a47YqiCYjsnsqxWhFufL9oPQzzK9sBDjZZwbpPnhD
ZN8PmBqWUXAo74a6oz7Q0W1QieAPCIGenFcVe5ui9m+9TDwtrQN1ECE5k3VuGlh9
l+1Sw5GjFEynARTDmaSRIc75EV/nx4a1LuHLkRYGC5Mg6LskWpIw7ShdPD54U/3Q
19iboaASh0ynfySjBsy1549hQcmi9UfMMX7u1QCCia2kd15u+YaVxtWoMHFB59q6
ELx+9XseEpEI/zBlvSwdyDTXWtnlxnzZjsyk0a/W+FpdeuZ7k2Dbf/Owx0nXS70M
HrH/AErvvbhxJ1BaAPC6TAN6da4xPpwy5XSRfjCCBFQwggNAoAMCAQICAnUwMAkG
BSsOAwIdBQAwgZkxCzAJBgNVBAYTAkFUMSYwJAYDVQQKEx1HUkFaIFVOSVZFUlNJ
VFkgT0YgVEVDSE5PTE9HWTFHMEUGA1UECxM+SW5zaXR1dGUgZm9yIEFwcGxpZWQg
SW5mb3JtYXRpb24gUHJvY2Vzc2luZyBhbmQgQ29tbXVuaWNhdGlvbnMxGTAXBgNV
BAMTEElBSUsgSU5UUkFORVQgQ0EwHhcNOTkxMTE0MTI1NTM2WhcNMDIxMjMxMjI1
OTMwWjCCARMxCzAJBgNVBAYTAkFUMQ8wDQYDVQQIEwZTdHlyaWExDTALBgNVBAcT
BEdyYXoxGTAXBgNVBAkTEEluZmZlbGRnYXNzZSAxNmExJjAkBgNVBAoTHUdSQVog
VU5JVkVSU0lUWSBPRiBURUNITk9MT0dZMUcwRQYDVQQLEz5JbnNpdHV0ZSBmb3Ig
QXBwbGllZCBJbmZvcm1hdGlvbiBQcm9jZXNzaW5nIGFuZCBDb21tdW5pY2F0aW9u
czEZMBcGA1UECxMQSUFJSyBJTlRSQU5FVCBDQTEbMBkGA1UEAxMSSUFJSyBUVS1H
UkFaIENSWVBUMSAwHgYDVQQMExdJQUlLIGNvbmZpZGVudGlhbGl0eSBDQTCCASAw
DQYJKoZIhvcNAQEBBQADggENADCCAQgCggEBAMEnzjatic90xi5VRmr0i2O16Z1a
SElQFZitoNvAzGw+KehOTuKeUr5ALHib9tGInNm+jPTWVGl/u5Hab1JRzXj0xAKy
qvZ+KphGy6ag6VcCVySJmeY1AqTM0W78XdFQXnlZuciBv00Ktoulb/Ktgh6c0YNg
o4UMVdxjGHJweibT1AGvlFe2BqulwtuwOLovMIuIyHHh+o6F2HXYKUB54GJpia1B
2IfmqcpBBFdYtDlHyrxugB5QhuhLo0BjD8jCe8B2gkQnI2wIeyfpLlH+u3/VQAl1
2cZKkqaqPpOgP/znsdh62QBSabrRluvCp9OQW9M8u+mJlrxIIVwtThfzIW0CAQWj
MzAxMBEGCWCGSAGG+EIBAQQEAwIAAjAPBgNVHRMECDAGAQH/AgEBMAsGA1UdDwQE
AwIBBjAJBgUrDgMCHQUAA4IBAQBa+v4JIzqbBydvFOaP/dA5D/GLWEWjPTF8tKcP
hxlEYABH8dW5E2tk/nNE2CDyGjkJtR+o9kiCDCa4N/qlc2LepJpa0I28Hi4wCd0C
uxSWpEuDHNDrW6Y/bU8gJ8DpskVl+lR0QFkqSCWAu3bY0e2VvUffk2ltrx1KvO64
vGX+ayZn2P7naGHPfYjCBWUKzW0zS8chVf0aehu/qXFuZDfy1MlDgEnPl1DQ1vSL
CMmFEDc99iNzcCU7ILn+RgWPNYPVhCUqoDQ6buX00ohfNVS/OHgqkWpa1HLvLRXq
E9NmYUJvfhE2zCY6w6bTME3IfDCXRat2Q3twP4/iP9xtsTbPMYICeDCCAnQCAQEw
ggEcMIIBEzELMAkGA1UEBhMCQVQxDzANBgNVBAgTBlN0eXJpYTENMAsGA1UEBxME
R1JBWjEZMBcGA1UECRMQSW5mZmVsZGdhc3NlIDE2YTEmMCQGA1UEChMdR1JBWiBV
TklWRVJTSVRZIE9GIFRFQ0hOT0xPR1kxRzBFBgNVBAsTPkluc2l0dXRlIGZvciBB
cHBsaWVkIEluZm9ybWF0aW9uIFByb2Nlc3NpbmcgYW5kIENvbW11bmljYXRpb25z
MRkwFwYDVQQLExBJQUlLIElOVFJBTkVUIENBMRkwFwYDVQQDExBJQUlLIFRVLUdS
QVogU0lHMSIwIAYDVQQMExlJQUlLIGVsZWN0cm9uaWMgc2lnbmF0dXJlAgMBhq0w
CQYFKw4DAhoFAKCBsTAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3
DQEJBTEPFw0wMDA3MjAwNzQ4MjNaMCMGCSqGSIb3DQEJBDEWBBRisRXrVulKQ/gr
frpAKVDnYvSEiDBSBgkqhkiG9w0BCQ8xRTBDMAoGCCqGSIb3DQMHMA4GCCqGSIb3
DQMCAgIAgDANBggqhkiG9w0DAgIBQDANBggqhkiG9w0DAgIBKDAHBgUrDgMCBzAN
BgkqhkiG9w0BAQEFAASBgE3lASw8jZhcQi4DLL4avnt3KrhabSxBqfEgNI6kJBZ4
Kmd8z29WvOgPZdJEMwtwSLxEmtZ9PexuzUymGU4enxS15gx5e+uluRvGPhyDAymx
mLIGizlDAK8OawEKQT5m6u5uZdvwP4Hra3JI9zTmtpj2qse+oHVUmPde6muRPhuU
AAAAAAAA
----IAIK.SMIME.MAPPER.F12BC676----



Received: from odin2.bull.net (odin2.bull.net [192.90.70.84]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id XAA00287 for <[e-mail]>; Wed, 19 Jul 2000 23:31:02 -0700 (PDT)
Received: from lvt-mail.frlv.bull.fr (lvt-mail.frlv.bull.fr [129.184.62.223]) by odin2.bull.net (8.9.3/8.9.3) with ESMTP id IAA12468; Thu, 20 Jul 2000 08:37:24 +0200
Received: from bull.net (frpq6118.frpq.bull.fr [129.184.8.64]) by lvt-mail.frlv.bull.fr (8.9.2/8.9.1) with ESMTP id RAA20310; Tue, 18 Jul 2000 17:05:12 +0200
Message-ID: <[e-mail]>
Date: Tue, 18 Jul 2000 17:05:13 +0200
From: Denis Pinkas <[e-mail]>
Organization: Bull
X-Mailer: Mozilla 4.7 [fr] (Win98; I)
X-Accept-Language: fr
MIME-Version: 1.0
To: [e-mail]
CC: [e-mail]
Subject: Re: Signing what you don't understand
References: <[e-mail]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

John,

May I suggest again that you take a closer look at 

http://www.ietf.org/internet-drafts/draft-ietf-smime-esformats-01.txt

which answers most of your basic questions.

Regards,

Denis

 
> Steve,
> 
> >>Anything in the certificate that's used to imply something about the
> intent
> >>behind a signature is asking for trouble, unless the specific certificate
> >>that a relying party should use is bound to the signature.  What's to
> >>prevent me from obtaining certificates from two different CAs, certifying
> >>the same key, but with different settings of the NR bit in the two
> >>certificates, and then using the certificate with the NR bit clear to
> >>repudiate a signature I originally represented as being non-repudiable
> >>using the other certificate?
> >
> >Not necessarily. You seem to assume that a signer could escape
> >responsibility for signing in an NR context by producing a
> >certificate with the same public key but without the NR bit asserted.
> >I don't subscribe to that assumption.  if I, as an RP, collect a cert
> >associated with the user and it has the right public key and NR
> >asserted, then why is my assertion of which cert was used in the
> >transaction untenable?  A legitimate user should never put the same
> >public key into two certs that differ in terms of this key usage bit
> >(and probably not if they differ in other, significant ways).  If
> >push came to shove and the user asserted that the NR-enabled cert was
> >not really issued at his request, a check of CA records for POP could
> >resolve the problem. [I assume that any CA issuing a cert with an NR
> >bit enabled ought to insist on POP, but maybe that's my unwarranted
> >assumption :-).]
> 
> I think you're suggesting the use of a distinct key for each possible
> "signature intent" here (although the example deals with R vs. NR, there
> are more than just two flavors of signature intent).  Quite apart from
> requiring a signer to maintain a large number of distinct keys, I think
> it's a bit much to expect every "legitimate user" to be well-enough versed
> in the nuances of certificates to always request the same certificate
> extensions in every certificate for a given key.
> 
> >>The only way that using anything in the certificate could work is if the
> >>specific certificate that I intend a relying party to use to verify the
> >>signature is somehow bound into the signature.  Binding a particular
> >>certificate to a signature has all sorts of other problems (e.g. do all
> my
> >>signatures become unverifiable when my certificate is renewed?), and
> would
> >>require a signature format change anyway, so why not simply assert the
> >>intent explicitly as part of the signature?
> >
> >Based on my comments above, I'm not sure we need to perform this
> >binding, but I agree with Denis's comments here, i.e., it's not
> >infeasible and the persistence of the signature is divorced from the
> >certificate lifetime by other mechanisms.
> 
> What other mechanisms would cover that case of my issuing CA going out of
> business?  If a CA's assets (including its keys) are sold as part of a
> bankruptcy process, I would think that trust in those keys would be fairly
> quickly revoked by other CAs that might have cross-certified it.  In this
> case, invalidityDate on those revocations would probably be set so that no
> certificate that had been issued by the former CA's key would be trusted
> (to prevent the keys' new owners from issuing new backdated certificates).
> However, as a subscriber to the former CA, I don't see why my signatures
> should suddenly become less trustworthy, if my key can be verified via
> another path.
> 
> >By the way, I'm not saying that a new format for signatures which are
> >designed precisely for NR purposes with general purpose documents is
> >a bad idea.  I just commented on what appeared to be a lack of good
> >arguments for such a construct.  I agree that the ability to have a
> >small token be able to understand such constructs could be valuable,
> >even though we still face a lot of problems with regard to secure
> >display of the contents of what is being signed.
> 
> The most persuasive argument I can come up with is an architectural one,
> and assumes that there are more flavors of "signature intent" than just
> repudiable vs non-repudiable.  There are three places I can see that one
> might try to encode the intent behind a signature: The particular key used,
> the particular certificate used, or explicitly as part of the signature
> structure.  The intent behind a signature is fairly dynamic, possibly
> varying with each signature.  On occasion I might want to sign a nonce
> simply to prove I possess a key; at other times I might want to sign a
> piece of e-mail to indicate that I have read it, i.e. to generate a
> return-receipt;  at other times my signature might assert my agreement to
> the contents of a document;  at other times it might be intended as an
> approval of some business process (i.e. "If the expenses listed in the
> document are as described, then they may be reimbursed").  However, both
> the certification hierarchy and the availability of keys are fairly static
> things - I either need to get my key re-certified for each possible
> signature intent I might want to assert, or I need to generate and certify
> a distinct key for each possible signature intent.  Encoding the intent
> explicitly as part of the signature allows me to choose at the time I
> generate the signature what intent I wish to associate with the signature,
> rather than having to have previously set up certification chains for all
> intents I might wish to asserts.  I would also claim that it's less
> error-prone and probably of greated legal validity to explicitly encode the
> intent along with the signature than to try to infer the certified intent
> from the contents of certificates issued by third-party CAs.
> 
> John


Received: from krdl.org.sg (IDENT:[e-mail] [192.122.139.27]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id XAA28832 for <[e-mail]>; Wed, 19 Jul 2000 23:02:15 -0700 (PDT)
Received: from mailhost.krdl.org.sg (mailhost [192.122.134.30]) by krdl.org.sg (8.9.3/8.9.3) with ESMTP id OAA08316 for <[e-mail]>; Thu, 20 Jul 2000 14:13:38 +0800
Received: from vivekpc1 (9Y3811S.krdl.org.sg [192.168.133.104]) by mailhost.krdl.org.sg (8.9.3/8.9.3) with SMTP id OAA14258 for <[e-mail]>; Thu, 20 Jul 2000 14:03:49 +0800 (SGT)
Message-ID: <000f01bff211$047b0480$[e-mail]>
From: "vivek singh" <[e-mail]>
To: <[e-mail]>
Subject: 
Date: Thu, 20 Jul 2000 14:09:09 +0800
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.50.4133.2400
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400

subscribe



Received: from mail.arabtrust.com (mail.arabtrust.com [216.247.149.19]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id WAA26897 for <[e-mail]>; Wed, 19 Jul 2000 22:40:45 -0700 (PDT)
Received: from jean [195.39.160.57] by mail.arabtrust.com (SMTPD32-6.00) id A1FD308C0042; Thu, 20 Jul 2000 01:45:33 -0400
From: "Jean Abraham" <[e-mail]>
To: "Ben Laurie" <[e-mail]>
Cc: "Paul Koning" <[e-mail]>, <[e-mail]>
Subject: RE: Signing what you don't understand
Date: Thu, 20 Jul 2000 08:41:51 +0300
Message-ID: <[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0)
In-Reply-To: <[e-mail]>
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6600

Yes, CA's dont create private keys except their own
I meant to say that a CA signs a end-user certificate.

When you apply for a certificate to sign and encrypt an email through a
browser then the private key is embeded in the browser and a entry is made
in the registry.

Jean

-----Original Message-----
From: Ben Laurie [mailto:[e-mail]]
Sent: Wednesday, July 19, 2000 8:57 PM
To: Jean Abraham
Cc: Paul Koning; [e-mail]
Subject: Re: Signing what you don't understand


Jean Abraham wrote:
>
> Paul,
>
> Private keys are also embeded in the browser as well as on a Luna Token.
>
> MD5 or hash.... are algorithms that generate the public key and private
key
> and also used for encryption purposes.

Errr ... no they aren't.

>  Now if a application has to be
> subverted it can only be done with the operators knowledge or the creator
of
> the application.  Regarding the virus,  a virus cannot attack a private
key.
> The virus creator needs to know the algorithm of the private key or the
> public key which will enable the virus to act.

Which is public knowledge.

>  Which is why any CA that
> generates end-user certificates are generated or created with utmost
> security in mind.

CAs do not generate private keys, except their own.

Cheers,

Ben.

--
http://www.apache-ssl.org/ben.html

Coming to ApacheCon Europe 2000? http://apachecon.com/



Received: from slack.lne.com (gw.lne.com [209.157.136.81]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id UAA20894 for <[e-mail]>; Wed, 19 Jul 2000 20:23:17 -0700 (PDT)
Received: (from ericm@localhost) by slack.lne.com (8.9.3/8.9.3) id UAA20847; Wed, 19 Jul 2000 20:25:12 -0700
Date: Wed, 19 Jul 2000 20:25:12 -0700
From: Eric Murray <[e-mail]>
To: Ben Laurie <[e-mail]>
Cc: [e-mail]
Subject: Re: Signing what you don't understand
Message-ID: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Mailer: Mutt 1.0pre3us
In-Reply-To: <[e-mail]>

On Wed, Jul 19, 2000 at 06:53:00PM +0100, Ben Laurie wrote:
> Paul Koning wrote:
> > 
> > First of all, the private key is "always with the owner" *only* if you
> > have a smartcard with embedded PKI engine.  Those exist but there
> > certainly are plenty of PK signing scenarios where they are not used.
> 
> Woah! Smartcard salesman detected... what about, say, a Palm, or a
> Psion? These have an advantage over smartcards, too, in that they have
> UIs.

The UI on a Palm is really useful from a security standpoint.  However,
the OS with no memory protection negates any use that requires security.
The slow crypto performance doesn't help either.

The ideal token for carrying private keys and digitally signing
documents would be something with a display (like a Palm) and an OS like
a smartcard's that protects the different applications and their keys
from each other.

Unfortunately that display costs a lot.  The CPU power to render anything
interesting on it the display, and to do crypto in reasonable speed adds
to the price.  With a readable display (but not pressure-sensitive
like a Palm), probably 5-10x a high-end smartcard.

> Smartcards are a technology whose time never really arrived, and is
> rapidly passing. IMO.

The problem isn't that they're not being used, it's that they've
never come close to matching the hype, and they probably won't ever.

-- 
 Eric Murray www.lne.com/ericm  ericm at the site lne.com  PGP keyid:E03F65E5
Security consulting: secure protocols, security reviews, standards, smartcards. 


Received: from cam-mailer1.bbn.com (cam-mailer1.bbn.com [171.78.68.5]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id TAA15870 for <[e-mail]>; Wed, 19 Jul 2000 19:06:52 -0700 (PDT)
Received: from [171.78.60.33] (dc033.bbn.com [171.78.60.33]) by cam-mailer1.bbn.com (8.8.8+Sun/8.8.8) with ESMTP id WAA10175; Wed, 19 Jul 2000 22:05:23 -0400 (EDT)
Mime-Version: 1.0
X-Sender: [e-mail] (Unverified)
Message-Id: <v04220804b59ba131c71a@[128.33.238.44]>
In-Reply-To:  <[e-mail]>
References: <[e-mail]>
Date: Wed, 19 Jul 2000 14:29:55 -0400
To: Adrian McCullagh <[e-mail]>
From: Stephen Kent <[e-mail]>
Subject: RE: Signing what you don't understand
Cc: [e-mail]
Content-Type: text/plain; charset="us-ascii" ; format="flowed"

Adrian,

>Your example is well put but is this really a digital signature or is it a
>set of bits (a mark) that has been affixed using the same technology known
>as digital signature technology.

This mailing list is the discussion forum for the PKIX WG, a 
technical WG of the IETF.  Thus we tend to employ (at least try to 
employ) technical terminology in our discussions. In that context, 
what I described is very definitely a digital signature.

>You mention the difference between the 2 intents.  I would be surprised, if
>anyone (other than the technically minded) even knows that a challenge
>response is even being "signed".  There is no intent at all in this case. It
>is the technology as designed that is effecting the response to the
>challenge.  I am surprised that "you" sign authentication challenges, just
>for authentication purposes.  Is it really a signature?  Are you really
>signing the authentication challenge or is it the software on your machine
>effecting the response to the challenge?

Again, from a technical perspective yes, I am signing the challenge, 
and I intended to sign it, but I also want to assert that this 
digital signature does not imply anything more than my participation 
in an authentication exchange. We have a means of doing that today, 
via the key usage extension.

>To me this is not a signature.  It may use digital signature technology but
>it is not a signature.  This is probably the problem.  It is the use of the
>word "signature" which is a technical term but has been used by the PKI
>community to cover a myriad of uses.  Some uses of the term by the PKI
>community are confusing.

Every profession has its own terminology with nuanced meanings.  In 
this context, i.e., on this discussion list, the technical 
terminology takes precedence, declared the WG Co-Chair :-).

>I also do not agree with your position that the NR bit can signal any intent
>either way.  With respect, intent is ascertained at the time of signing.  A
>certificate has nothing what so ever to do with signing.  Its primary
>purpose is to identify a public key that corresponds to a private key that
>may be held by some previously identified person or entity.  The public key
>is used to verify a digital signature that has supposedly been created using
>the corresponding private key.  That is it as far as I understand it unless
>there is some other primary purpose that I do not know.  I do not see the
>relationship between digitally signing a document and the contents of a
>certificate. Verification of the signature at some later time is a different
>issue which may involve the use of a certificate but this may not be so.

There are lots of relationships between a signature and certificate 
contents. Specifically, policy information can be conveyed in the 
certificate that binds the public key for signature verification. 
One might argue that a certificate is not directly involved in the 
act of signing, but it is essential to the signature validation 
process, in our context.  A public key divorced from a certificate 
can be used to verify a signature, but it does not tell me who 
created the signature.  This WG addresses signature topics ONLY in 
the context of public keys bound into certificates.

Steve



Received: from cam-mailer1.bbn.com (cam-mailer1.bbn.com [171.78.68.5]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id TAA15316 for <[e-mail]>; Wed, 19 Jul 2000 19:03:31 -0700 (PDT)
Received: from [171.78.60.33] (dc033.bbn.com [171.78.60.33]) by cam-mailer1.bbn.com (8.8.8+Sun/8.8.8) with ESMTP id WAA10230; Wed, 19 Jul 2000 22:06:02 -0400 (EDT)
Mime-Version: 1.0
X-Sender: [e-mail] (Unverified)
Message-Id: <v04220807b59baae71151@[128.33.238.44]>
In-Reply-To:  <[e-mail]>
References:  <[e-mail]>
Date: Wed, 19 Jul 2000 15:03:13 -0400
To: Sharon Boeyen <[e-mail]>
From: Stephen Kent <[e-mail]>
Subject: RE: Reverse paths
Cc: [e-mail]
Content-Type: text/plain; charset="us-ascii" ; format="flowed"

Sharon,

<snip>


>I would like to support Sean's request that for the LDAPv3 schema we
>consider making the reverse element mandatory along with the forward
>element.
>This would be a great step forward in supporting interoperability among PKI
>products and services and, since it does not impact existing LDAPv2 systems,
>
>doesn't cause those previously deployed systems to be non-conformant.
>
>With both elements mandatory, regardless of the direction the path is
>being built, the certificate using system will be able to locate the
>information
>it seeks.
>

I am uncomfortable with the proposal that we mandate both elements, 
as this would seem to imply that every CA would have to engage in 
reverse path certificate generation in all contexts.  Did I 
misunderstand the implication?
I know that Entrust has always encouraged (required?) this type of 
cross certification among CAs, but it doesn't seem that other CA 
vendors or most users have. I would not think it appropriate to 
impose this sort of requirement, given the vendor-specific 
implications of such a change.

Steve



Received: from cam-mailer1.bbn.com (cam-mailer1.bbn.com [171.78.68.5]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id TAA15292 for <[e-mail]>; Wed, 19 Jul 2000 19:03:29 -0700 (PDT)
Received: from [171.78.60.33] (dc033.bbn.com [171.78.60.33]) by cam-mailer1.bbn.com (8.8.8+Sun/8.8.8) with ESMTP id WAA10221; Wed, 19 Jul 2000 22:05:59 -0400 (EDT)
Mime-Version: 1.0
X-Sender: [e-mail] (Unverified)
Message-Id: <v04220806b59ba5dfe2a7@[128.33.238.44]>
In-Reply-To: <[e-mail]>
References: <[e-mail]>
Date: Wed, 19 Jul 2000 14:58:29 -0400
To: [e-mail]
From: Stephen Kent <[e-mail]>
Subject: Re: Signing what you don't understand
Cc: [e-mail], <[e-mail]>
Content-Type: text/plain; charset="us-ascii" ; format="flowed"

John,

<snip>


>I think you're suggesting the use of a distinct key for each possible
>"signature intent" here (although the example deals with R vs. NR, there
>are more than just two flavors of signature intent).  Quite apart from
>requiring a signer to maintain a large number of distinct keys, I think
>it's a bit much to expect every "legitimate user" to be well-enough versed
>in the nuances of certificates to always request the same certificate
>extensions in every certificate for a given key.

I am a firm believer in users holding multiple certs and multiple 
keys. Appropriate interface/management software should make this 
tolerable.  I also believe that it is rarely appropriate to put the 
same key into multiple certs, hence my general lack of concern over 
the other issue you cite.  But, if one needs to push the granularity 
of signature intent very far, then I agree that what I proposed could 
become infeasible to manage.

>  >>The only way that using anything in the certificate could work is if the
>  >>specific certificate that I intend a relying party to use to verify the
>  >>signature is somehow bound into the signature.  Binding a particular
>  >>certificate to a signature has all sorts of other problems (e.g. do all
>my
>  >>signatures become unverifiable when my certificate is renewed?), and
>would
>  >>require a signature format change anyway, so why not simply assert the
>  >>intent explicitly as part of the signature?
>  >
>  >Based on my comments above, I'm not sure we need to perform this
>  >binding, but I agree with Denis's comments here, i.e., it's not
>  >infeasible and the persistence of the signature is divorced from the
>  >certificate lifetime by other mechanisms.



>What other mechanisms would cover that case of my issuing CA going out of
>business?  If a CA's assets (including its keys) are sold as part of a
>bankruptcy process, I would think that trust in those keys would be fairly
>quickly revoked by other CAs that might have cross-certified it.  In this
>case, invalidityDate on those revocations would probably be set so that no
>certificate that had been issued by the former CA's key would be trusted
>(to prevent the keys' new owners from issuing new backdated certificates).
>However, as a subscriber to the former CA, I don't see why my signatures
>should suddenly become less trustworthy, if my key can be verified via
>another path.

A RP can be responsible for acquiring all the requisite evidence for 
later support of signed document validity, including time stamping 
this evidence. I think this addresses the scenario you described 
above.

>  >By the way, I'm not saying that a new format for signatures which are
>  >designed precisely for NR purposes with general purpose documents is
>  >a bad idea.  I just commented on what appeared to be a lack of good
>  >arguments for such a construct.  I agree that the ability to have a
>  >small token be able to understand such constructs could be valuable,
>  >even though we still face a lot of problems with regard to secure
>  >display of the contents of what is being signed.
>
>The most persuasive argument I can come up with is an architectural one,
>and assumes that there are more flavors of "signature intent" than just
>repudiable vs non-repudiable.  There are three places I can see that one
>might try to encode the intent behind a signature: The particular key used,
>the particular certificate used, or explicitly as part of the signature
>structure.  The intent behind a signature is fairly dynamic, possibly
>varying with each signature.  On occasion I might want to sign a nonce
>simply to prove I possess a key; at other times I might want to sign a
>piece of e-mail to indicate that I have read it, i.e. to generate a
>return-receipt;  at other times my signature might assert my agreement to
>the contents of a document;  at other times it might be intended as an
>approval of some business process (i.e. "If the expenses listed in the
>document are as described, then they may be reimbursed").  However, both
>the certification hierarchy and the availability of keys are fairly static
>things - I either need to get my key re-certified for each possible
>signature intent I might want to assert, or I need to generate and certify
>a distinct key for each possible signature intent.  Encoding the intent
>explicitly as part of the signature allows me to choose at the time I
>generate the signature what intent I wish to associate with the signature,
>rather than having to have previously set up certification chains for all
>intents I might wish to asserts.  I would also claim that it's less
>error-prone and probably of greated legal validity to explicitly encode the
>intent along with the signature than to try to infer the certified intent
>from the contents of certificates issued by third-party CAs.

Those are good arguments.  One can choose to represent this info in 
the document being signed, analogous to what we do in the physical 
world, or can try to codify the various intents in a newly defined 
signature format.  The latter approach will entail considerable 
haggling over what the requisite info types will be, how to encode 
them, etc.  The same problems would arise if we try to do this fine 
granularity intent expression in a standard fashion in signed 
documents.  We already have this sort of facility in the policy 
qualifier aspect of cert policies, and many of us question the 
ability of folks to manage this in the more static context in which 
it might be used.  So, another aspect of this debate is whether the 
"average" user is capable of managing this sort of facility, on a per 
signature basis, as suggested, irrespective of how we support the 
capability.

Steve



Received: from cam-mailer1.bbn.com (cam-mailer1.bbn.com [171.78.68.5]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id TAA15266 for <[e-mail]>; Wed, 19 Jul 2000 19:03:25 -0700 (PDT)
Received: from [171.78.60.33] (dc033.bbn.com [171.78.60.33]) by cam-mailer1.bbn.com (8.8.8+Sun/8.8.8) with ESMTP id WAA10214; Wed, 19 Jul 2000 22:05:57 -0400 (EDT)
Mime-Version: 1.0
X-Sender: [e-mail] (Unverified)
Message-Id: <v04220805b59ba46288fc@[128.33.238.44]>
In-Reply-To:  <[e-mail]>
References: <[e-mail]>
Date: Wed, 19 Jul 2000 14:32:12 -0400
To: "Golkin, Ken (CAP, CMC)" <[e-mail]>
From: Stephen Kent <[e-mail]>
Subject: RE: Signing what you don't understand
Cc: [e-mail]
Content-Type: text/plain; charset="us-ascii" ; format="flowed"

Ken,

>This discussion seems to be confusing two different uses for certificates
>1) Authentication (I am who I say I am)
>2) Signature (I signed a legally binding document)
>
>In the first case I showed my company issue picture ID (certificate) 
>to the guard at the door and he let me in the building this morning.

Or, maybe you "signed in" as part of entering your workplace, ....

<snip>

Steve



Received: from poptop.llnl.gov (poptop.llnl.gov [128.115.41.70]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id QAA01976 for <[e-mail]>; Wed, 19 Jul 2000 16:52:48 -0700 (PDT)
Received: from catalyst (catalyst.llnl.gov [128.115.222.68]) by poptop.llnl.gov (8.8.8/LLNL-3.0.2/pop.llnl.gov-5.1) with ESMTP id QAA08901 for <[e-mail]>; Wed, 19 Jul 2000 16:54:51 -0700 (PDT)
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.2 
Date: Wed, 19 Jul 2000 17:02:40 -0700
To: [e-mail]
From: Tony Bartoletti <[e-mail]>
Subject: A Real Rationale for Dedicated Keys
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed

The common rationale given for maintaining distinct keys
for distinct usages is to distinguish the "legal binding
signature" from "no intent but saw it" authentication or
message tamperproofing.  As I've argued in the "Signing
what you don't understand" thread, I see no way to prevent
the key-owner from having a key "multiply certified" as
a ploy to escape the "clutches" of NR in legal signature.
(Hence, legal or NR usage should invoke a more involved
protocol.)

My point being, the key-owner is the primary point of
control in enforcing a "one-key, one-cert" personal regime.

However, there is a strong rationale where the key-owner
is self-motivated in maintaining a strict separation of
keys and usages (even as it applies to the legal vs
authentication usage.) This is the Privacy Motivation.

If I "multiply-certify" a "legal signature" key (with its
implication of linkages to detailed personal identifying
information) as either a lightweight "someone@address"
key, or worse, as a blinded voting key, then I risk the
very real possibility that my certificates can become
aggregated according to the public key value, and used
to violate the anonymity expected of the latter uses.

___tony___



Tony Bartoletti 925-422-3881 <[e-mail]>
Information Operations, Warfare and Assurance Center
Lawrence Livermore National Laboratory
Livermore, CA 94551-9900



Received: from poptop.llnl.gov (poptop.llnl.gov [128.115.41.70]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id QAA01030 for <[e-mail]>; Wed, 19 Jul 2000 16:08:12 -0700 (PDT)
Received: from catalyst (catalyst.llnl.gov [128.115.222.68]) by poptop.llnl.gov (8.8.8/LLNL-3.0.2/pop.llnl.gov-5.1) with ESMTP id QAA16829; Wed, 19 Jul 2000 16:08:23 -0700 (PDT)
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.2 
Date: Wed, 19 Jul 2000 16:16:13 -0700
To: "P.J. Ponder" <[e-mail]>, Ben Laurie <[e-mail]>
From: Tony Bartoletti <[e-mail]>
Subject: Re: Signing what you don't understand
Cc: Eric Murray <[e-mail]>, [e-mail]
In-Reply-To: <[e-mail] .us>
References: <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed

At 06:32 PM 7/19/00 -0400, P.J. Ponder wrote:
>The Internet Security Glossary (RFC2828)
>
>ftp://ftp.isi.edu/in-notes/rfc2828.txt
>
>does a pretty good job distinguishing between 'digital signature' and
>'electronic signature'.  Maybe those definitions are adequate for this
>discussion.  (I was also under the impression that the Glossary itself was
>a product of this workgroup...)
>
>On Wed, 19 Jul 2000, Ben Laurie wrote:
>
> > Eric Murray wrote:
> > >
> > > Since "digital signing" is used all the time in the crypto sense, I'd
> > > like to propose that when talking about the second kind of digital
> > > signatures, they be called "digital signature of documents".
> >
> > How about "legally binding digital signature". That certainly says what
> > people want it to mean unambiguously.

Since most "digital" signatures are "electronic" in implementation,
I find the term "electronic signature" equally confusing, in that it
does not (automatically) imply the burden of legal binding in the
minds of most people.  "Legal" or "Legally Binding" is far clearer.

In any case, while it is facile to establish an agreed terminology,
it serves only to sharpen the discussion of the issue at hand.  Given
that (electronic, legal) signatures will likely be founded upon the
cryptographic "digital signature" operation, how best to distinguish
the "DigSig" intent, to the protection of all parties concerned?

So far, I have heard:

   1.  Dedicated Key

         (implies one-key <--> one cert, and use NR-bit disambiguation)

   2.  Common Key + "signature over intended certificate"

         (implies one-key <--> many certs, and use NR-bit disambiguation)

   3.  Common Key + "look at the content"

         (implies "who needs the NR-bit")

Given that a public key must be assumed "public", I don't see any way
to enforce the one-to-one condition in the "Dedicated Key" option (1).

I think (2) is a minimum.  If something is digitally signed, and
the "signed content" does not include a certificate indicating the
the "level of intensity" with which "someone" (the CA) attested to
the strength of the DN/truePerson association, I would argue that a
relying party will (should) be disadvantaged in court.

Such a key should be safe for "non-binding" authentication usage,
since additional "weaker certification" of the key does not in
itself weaken the stronger DN/truePerson binding.

(NOTE: such non-binding authentication usage can be argued to
encourage deployment of the secret key in relatively unsecured
environments, and this IS a problem.  However, (to my knowledge)
the CA generally is not certifying the manner in which the
subscriber protects the key, so I cannot see how it becomes
an issue for them.)

___tony___


Tony Bartoletti 925-422-3881 <[e-mail]>
Information Operations, Warfare and Assurance Center
Lawrence Livermore National Laboratory
Livermore, CA 94551-9900



Received: from fn3.freenet.tlh.fl.us (fn3.tfn.net [150.176.31.250]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id PAA23612 for <[e-mail]>; Wed, 19 Jul 2000 15:07:18 -0700 (PDT)
Received: from localhost (ponder@localhost) by fn3.freenet.tlh.fl.us (8.8.8/8.6.9) with ESMTP id SAA03701; Wed, 19 Jul 2000 18:32:34 -0400 (EDT)
Date: Wed, 19 Jul 2000 18:32:34 -0400 (EDT)
From: "P.J. Ponder" <[e-mail]>
To: Ben Laurie <[e-mail]>
cc: Eric Murray <[e-mail]>, [e-mail]
Subject: Re: Signing what you don't understand
In-Reply-To: <[e-mail]>
Message-ID: <[e-mail]>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII

The Internet Security Glossary (RFC2828)

ftp://ftp.isi.edu/in-notes/rfc2828.txt

does a pretty good job distinguishing between 'digital signature' and
'electronic signature'.  Maybe those definitions are adequate for this
discussion.  (I was also under the impression that the Glossary itself was
a product of this workgroup...)



On Wed, 19 Jul 2000, Ben Laurie wrote:

> Eric Murray wrote:
> > Digital signing in the human/legal means signing something different.
> > It always means "signing" something that makes sense to a human.  It might
> > mean using the crypto definition of "digital signing" to do it, or (under
> > the new US "digital signing" bill) it might mean clicking on a OK button
> > somewhere near the document.  This kind of digital signature
> > makes sense in a non-repudiation context- it's whole purpose is about NR.
> > 
> > Since "digital signing" is used all the time in the crypto sense, I'd
> > like to propose that when talking about the second kind of digital
> > signatures, they be called "digital signature of documents".
> 
> How about "legally binding digital signature". That certainly says what
> people want it to mean unambiguously.
> 
> Cheers,
> 
> Ben.
> 
> --
> http://www.apache-ssl.org/ben.html
> 
> Coming to ApacheCon Europe 2000? http://apachecon.com/
> 



Received: from d1o69.telia.com ([e-mail] [62.20.144.241]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id NAA21901 for <[e-mail]>; Wed, 19 Jul 2000 13:22:10 -0700 (PDT)
Received: from mega (t1o69p42.telia.com [62.20.144.42]) by d1o69.telia.com (8.8.8/8.8.8) with SMTP id WAA01551; Wed, 19 Jul 2000 22:24:38 +0200 (CEST)
Message-ID: <003901bff1c7$9e2e3ec0$[e-mail]>
From: "Anders Rundgren" <[e-mail]>
To: "Stefan Kelm" <[e-mail]>, "Ben Laurie" <[e-mail]>
Cc: <[e-mail]>
Subject: Value of smart cards. Re: Signing what you don't understand
Date: Wed, 19 Jul 2000 23:23:40 +0200
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 4.72.3110.5
X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by ns.secondary.com id NAA21902

Ben+Stefan


> Woah! Smartcard salesman detected... what about, say, a Palm, or a
> Psion? These have an advantage over smartcards, too, in that they have
> UIs. Smartcards are a technology whose time never really arrived, and is
> rapidly passing. IMO.

The discrete credit-sized smart card is probably not going to take over the world
as you say.  But the SIM/WIM card will. Actually 300 million *existing* customers can't be wrong!
It provides a cheap tamper-resistant storage and crypto-processor that *will* also be a
part of PDAs when they are "connected".  It is the ability to insert a subscription into
a mobile phone and PDA that is the driving factor now.  Later it will be PKI.

http://www.mobilephones-tng.com/papers/thenewswissarmyknife.html

But Ericsson apparently believe in smart credit-cards as they have introduced this
100% loser-product:

http://www.ericsson.se/wirelesswallet/How.htm

>Regarding PDAs I recommend the following research paper and the
>web site mentioned on the following URL:

>"Hand-Held Computers Can Be Better Smart Cards"
>Dirk Balfanz, Ed Felten. Proceedings of USENIX Security '99, August, 1999.
>http://www.cs.princeton.edu/sip/pub/pilotkey.php3

Nice article. See comment regarding PDAs

Anders




Received: from rom.antech.de (dns.antech.de [194.45.12.2]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id LAA20142 for <[e-mail]>; Wed, 19 Jul 2000 11:55:26 -0700 (PDT)
Received: from scherbius.secorvo.de (scherbius.secorvo.de [194.45.12.219]) by rom.antech.de (8.9.3/8.9.3) with ESMTP id UAA21622; Wed, 19 Jul 2000 20:40:42 +0200
Message-Id: <[e-mail]>
From: "Stefan Kelm" <[e-mail]>
Organization: Secorvo Security Consulting GmbH
To: Ben Laurie <[e-mail]>
Date: Wed, 19 Jul 2000 20:56:17 +0200
MIME-Version: 1.0
Content-type: text/plain; charset=US-ASCII
Content-transfer-encoding: 7BIT
Subject: Re: Signing what you don't understand
CC: [e-mail]
Priority: normal
In-reply-to: <[e-mail]>
X-mailer: Pegasus Mail for Win32 (v3.12b)

> Woah! Smartcard salesman detected... what about, say, a Palm, or a
> Psion? These have an advantage over smartcards, too, in that they have
> UIs. Smartcards are a technology whose time never really arrived, and is
> rapidly passing. IMO.

Regarding PDAs I recommend the following research paper and the
web site mentioned on the following URL:

"Hand-Held Computers Can Be Better Smart Cards"
Dirk Balfanz, Ed Felten. Proceedings of USENIX Security '99, August, 1999.
http://www.cs.princeton.edu/sip/pub/pilotkey.php3

Cheers,

	Stefan.


--------------------------------------------------------
PKI-Symposium, 10.-11.Oktober 2000, www.pki-symposium.de
--------------------------------------------------------
Dipl.-Inform. Stefan Kelm
Security Consultant

Secorvo Security Consulting GmbH
Albert-Nestler-Strasse 9, D-76131 Karlsruhe

Tel. [phone], Fax [phone]
E-Mail [e-mail], http://www.secorvo.de
-------------------------------------------------------
PGP Fingerprint 87AE E858 CCBC C3A2 E633 D139 B0D9 212B


Received: from nxs_vyr_dns.sie.cl ([206.48.156.90]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id LAA19862 for <[e-mail]>; Wed, 19 Jul 2000 11:50:18 -0700 (PDT)
Received: from acepta.com ([192.168.4.178]) by nxs_vyr_dns.sie.cl (8.9.3/8.9.3) with ESMTP id KAA06950; Wed, 19 Jul 2000 10:57:50 -0400
Message-ID: <[e-mail]>
Date: Wed, 19 Jul 2000 14:50:18 -0400
From: "Juan Carlos Perez A." <[e-mail]>
Organization: Acepta.com
X-Mailer: Mozilla 4.73 [en] (Windows NT 5.0; I)
X-Accept-Language: en
MIME-Version: 1.0
To: Jean Abraham <[e-mail]>
CC: [e-mail]
Subject: Re: 
References: <[e-mail]>
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 8bit

I think that is  ASN.1

Juan Carlos Pérez A.
Acepta.com
CHILE

Jean Abraham wrote:

> Hello,
>
> Can anyone tell me what language is the below written in?
>
> CBCParameter ::= IV
>
>     FBParameter ::= SEQUENCE {
>         iv IV,
>         numberOfBits NumberO
> ...........
> .........
> Thanks
>
> Best Regards
>
> Jean Abraham
> Key Manager
> Arabtrust
> Tel: +965 - 5629645/721/827 Ext: 408
> Fax: +965 - 5662164
> [e-mail]



Received: from freeby.ben.algroup.co.uk (sockittome.aldigital.co.uk [194.128.162.252]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id LAA18991 for <[e-mail]>; Wed, 19 Jul 2000 11:09:53 -0700 (PDT)
Received: from algroup.co.uk (naughty.ben.algroup.co.uk [193.133.15.107]) by freeby.ben.algroup.co.uk (8.6.12/8.6.12) with ESMTP id TAA11336; Wed, 19 Jul 2000 19:11:14 +0100
Message-ID: <[e-mail]>
Date: Wed, 19 Jul 2000 18:56:32 +0100
From: Ben Laurie <[e-mail]>
Organization: A.L. Group plc
X-Mailer: Mozilla 4.7 [en] (WinNT; I)
MIME-Version: 1.0
To: Jean Abraham <[e-mail]>
CC: Paul Koning <[e-mail]>, [e-mail]
Subject: Re: Signing what you don't understand
References: <[e-mail]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Jean Abraham wrote:
> 
> Paul,
> 
> Private keys are also embeded in the browser as well as on a Luna Token.
> 
> MD5 or hash.... are algorithms that generate the public key and private key
> and also used for encryption purposes.

Errr ... no they aren't.

>  Now if a application has to be
> subverted it can only be done with the operators knowledge or the creator of
> the application.  Regarding the virus,  a virus cannot attack a private key.
> The virus creator needs to know the algorithm of the private key or the
> public key which will enable the virus to act.

Which is public knowledge.

>  Which is why any CA that
> generates end-user certificates are generated or created with utmost
> security in mind.

CAs do not generate private keys, except their own.

Cheers,

Ben.

--
http://www.apache-ssl.org/ben.html

Coming to ApacheCon Europe 2000? http://apachecon.com/


Received: from freeby.ben.algroup.co.uk (sockittome.aldigital.co.uk [194.128.162.252]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id LAA18699 for <[e-mail]>; Wed, 19 Jul 2000 11:04:00 -0700 (PDT)
Received: from algroup.co.uk (naughty.ben.algroup.co.uk [193.133.15.107]) by freeby.ben.algroup.co.uk (8.6.12/8.6.12) with ESMTP id TAA11316; Wed, 19 Jul 2000 19:09:18 +0100
Message-ID: <[e-mail]>
Date: Wed, 19 Jul 2000 18:54:36 +0100
From: Ben Laurie <[e-mail]>
Organization: A.L. Group plc
X-Mailer: Mozilla 4.7 [en] (WinNT; I)
MIME-Version: 1.0
To: "Heimberg, Jim" <[e-mail]>
CC: "'Tony Bartoletti'" <[e-mail]>, Mitchell Arnone <[e-mail]>, "Golkin Ken (CAP CMC)" <[e-mail]>, "'Adrian McCullagh'" <[e-mail]>, "'Stephen Kent'" <[e-mail]>, [e-mail]
Subject: Re: Signing what you don't understand
References: <[e-mail]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

"Heimberg, Jim" wrote:
> 
> A convincing argument for hardware tokens and biometrics if ever I heard
> one.

A convincing argument against biometrics is that they can't be revoked
and they encourage people to steal parts of my body, which I'd really
rather they didn't.

Cheers,

Ben.

--
http://www.apache-ssl.org/ben.html

Coming to ApacheCon Europe 2000? http://apachecon.com/


Received: from freeby.ben.algroup.co.uk (sockittome.aldigital.co.uk [194.128.162.252]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id KAA18307 for <[e-mail]>; Wed, 19 Jul 2000 10:50:43 -0700 (PDT)
Received: from algroup.co.uk (naughty.ben.algroup.co.uk [193.133.15.107]) by freeby.ben.algroup.co.uk (8.6.12/8.6.12) with ESMTP id TAA11312; Wed, 19 Jul 2000 19:07:42 +0100
Message-ID: <[e-mail]>
Date: Wed, 19 Jul 2000 18:53:00 +0100
From: Ben Laurie <[e-mail]>
Organization: A.L. Group plc
X-Mailer: Mozilla 4.7 [en] (WinNT; I)
MIME-Version: 1.0
To: Paul Koning <[e-mail]>
CC: [e-mail], [e-mail]
Subject: Re: Signing what you don't understand
References: <[e-mail]> <[e-mail]> <[e-mail]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Paul Koning wrote:
> 
> >>>>> "Jean" == Jean Abraham <[e-mail]> writes:
> 
>  Jean> Digital signatures generation or creation is not based on the
>  Jean> O/S of a particular PC but on the software that is used to
>  Jean> generate it.  The most important apsect in a digital
>  Jean> certificate(which is used to create a digital signature - end
>  Jean> user) is that the private key is always with the owner and
>  Jean> never in transist.
> 
> You're entirely missing the issue that started this long string of
> notes.
> 
> First of all, the private key is "always with the owner" *only* if you
> have a smartcard with embedded PKI engine.  Those exist but there
> certainly are plenty of PK signing scenarios where they are not used.

Woah! Smartcard salesman detected... what about, say, a Palm, or a
Psion? These have an advantage over smartcards, too, in that they have
UIs. Smartcards are a technology whose time never really arrived, and is
rapidly passing. IMO.

Cheers,

Ben.

--
http://www.apache-ssl.org/ben.html

Coming to ApacheCon Europe 2000? http://apachecon.com/


Received: from btw.plaintalk.bellevue.wa.us (btw-xl1.plaintalk.bellevue.wa.us [206.129.5.130]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id JAA14889 for <[e-mail]>; Wed, 19 Jul 2000 09:24:08 -0700 (PDT)
Received: from software-munitions.com (fwiw.plaintalk.bellevue.wa.us [206.129.5.157]) by btw.plaintalk.bellevue.wa.us (8.10.2/8.10.2) with ESMTP id e6JGQ0C39092; Wed, 19 Jul 2000 09:26:00 -0700 (PDT)
Message-ID: <[e-mail]>
Date: Wed, 19 Jul 2000 09:26:00 -0700
From: Dennis Glatting <[e-mail]>
X-Mailer: Mozilla 4.73 [en] (WinNT; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Jean Abraham <[e-mail]>
CC: Paul Koning <[e-mail]>, [e-mail]
Subject: Re: Signing what you don't understand
References: <[e-mail]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Jean Abraham wrote:
> 
> Paul,
> 
> Private keys are also embeded in the browser as well as on a Luna Token.
> 
> MD5 or hash.... are algorithms that generate the public key and private key
> and also used for encryption purposes.  Now if a application has to be
> subverted it can only be done with the operators knowledge or the creator of
> the application.  Regarding the virus,  a virus cannot attack a private key.
> The virus creator needs to know the algorithm of the private key or the
> public key which will enable the virus to act.  Which is why any CA that
> generates end-user certificates are generated or created with utmost
> security in mind.
> 

This is not true. 

Public and private keys are often stored in well known places. All a
virus needs to do is copy those files and send them to a remote
source. There are plenty of examples of viruses doing this. On
Microsoft OS platforms unauthenticated ActiveX controls can be
executed and a virus can execute simply by being received
(http://www.sans.org/newlook/resources/win_flaw.htm). If one is stupid
enough to publicly share on the Internet part of drive where the keys
are located then the keys can be remotly copied (e.g.,
http://www.latimes.com/business/updates/lat_scour000714.htm),
attacked, and exploited.

Regarding my previous message about PKI risks, the paper by Schneier
and Ellison is reasonably current and forceful; however, there are
others. I remember seeing a paper by Don Davis dated 1996 (I believe)
saying similar things (sorry, my memory is foggy and I lost the URL).



> I hope that clears everything
> 
> Jean
> 
> -----Original Message-----
> From: Paul Koning [mailto:[e-mail]]
> Sent: Wednesday, July 19, 2000 4:53 PM
> To: [e-mail]
> Cc: [e-mail]
> Subject: RE: Signing what you don't understand
> 
> >>>>> "Jean" == Jean Abraham <[e-mail]> writes:
> 
>  Jean> Digital signatures generation or creation is not based on the
>  Jean> O/S of a particular PC but on the software that is used to
>  Jean> generate it.  The most important apsect in a digital
>  Jean> certificate(which is used to create a digital signature - end
>  Jean> user) is that the private key is always with the owner and
>  Jean> never in transist.
> 
> You're entirely missing the issue that started this long string of
> notes.
> 
> First of all, the private key is "always with the owner" *only* if you
> have a smartcard with embedded PKI engine.  Those exist but there
> certainly are plenty of PK signing scenarios where they are not used.
> 
> Second, and this is what started things, the data being signed (hash
> or whatever) are supplied to the signing engine by application
> software.  If the application is subverted (easy to do with a number
> of very popular applications) OR the underlying OS is subverted, an
> attacker can supply different data to be signed from what you thought
> you were signing.
> 
> So the OS is absolutely part of the puzzle; it is not sufficient to
> consider only "the software that is used to generate [the
> signature]".  The application may well be the weakest link, of course;
> certainly in a number of well-known cases the application is indeed
> the open barn door through which the viruses enter.  But it is by no
> means the only possible barn door.
> 
>        paul


-- 
Dennis Glatting
Copyright (c) 2000 Software Munitions


Received: from btw.plaintalk.bellevue.wa.us (btw-xl1.plaintalk.bellevue.wa.us [206.129.5.130]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id IAA14068 for <[e-mail]>; Wed, 19 Jul 2000 08:56:06 -0700 (PDT)
Received: from software-munitions.com (fwiw.plaintalk.bellevue.wa.us [206.129.5.157]) by btw.plaintalk.bellevue.wa.us (8.10.2/8.10.2) with ESMTP id e6JFvtC38795; Wed, 19 Jul 2000 08:57:55 -0700 (PDT)
Message-ID: <[e-mail]>
Date: Wed, 19 Jul 2000 08:57:55 -0700
From: Dennis Glatting <[e-mail]>
X-Mailer: Mozilla 4.73 [en] (WinNT; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Paul Koning <[e-mail]>
CC: [e-mail], [e-mail]
Subject: Re: Signing what you don't understand
References: <[e-mail]> <[e-mail]> <[e-mail]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Paul Koning wrote:
> 
> >>>>> "Jean" == Jean Abraham <[e-mail]> writes:
> 
>  Jean> Digital signatures generation or creation is not based on the
>  Jean> O/S of a particular PC but on the software that is used to
>  Jean> generate it.  The most important apsect in a digital
>  Jean> certificate(which is used to create a digital signature - end
>  Jean> user) is that the private key is always with the owner and
>  Jean> never in transist.
> 

I came into this conversation late so I apologize if this has been
mentioned before. The following URL is an interesting read on this
topic, in particular Risk #2.
	http://www.counterpane.com/pki-risks.html


Received: from btw.plaintalk.bellevue.wa.us (btw-xl1.plaintalk.bellevue.wa.us [206.129.5.130]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id IAA13679 for <[e-mail]>; Wed, 19 Jul 2000 08:47:23 -0700 (PDT)
Received: from software-munitions.com (fwiw.plaintalk.bellevue.wa.us [206.129.5.157]) by btw.plaintalk.bellevue.wa.us (8.10.2/8.10.2) with ESMTP id e6JFnCC38699; Wed, 19 Jul 2000 08:49:13 -0700 (PDT)
Message-ID: <[e-mail]>
Date: Wed, 19 Jul 2000 08:49:12 -0700
From: Dennis Glatting <[e-mail]>
X-Mailer: Mozilla 4.73 [en] (WinNT; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Paul Koning <[e-mail]>
CC: [e-mail], [e-mail]
Subject: Re: Signing what you don't understand
References: <[e-mail]> <[e-mail]> <[e-mail]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Paul Koning wrote:
> 
	[snip]
> So long as security remains a non-goal of such operating systems,
> digital signatures produduced by such systems will not offer any
> meaningful guarantees of any kind.
> 

And anything derived from biometrics on said operating system.


Received: from sothmxs01.entrust.com (gatekeeper.entrust.com [204.101.128.170]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id HAA07330 for <[e-mail]>; Wed, 19 Jul 2000 07:45:32 -0700 (PDT)
Received: by sothmxs01.entrust.com with Internet Mail Service (5.5.2650.21) id <PHL2GNKA>; Wed, 19 Jul 2000 10:47:32 -0400
Message-ID: <[e-mail]>
From: Carlisle Adams <[e-mail]>
To: "'[e-mail]'" <[e-mail]>
Cc: [e-mail], [e-mail]
Subject: RE: Re: CRMF encValue Field
Date: Wed, 19 Jul 2000 10:45:56 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain

Hi Francois,

> ----------
> From:
> [e-mail][SMTP:[e-mail]]
> Sent: 	Tuesday, July 18, 2000 9:37 AM
> To: 	[e-mail]
> Cc: 	[e-mail]; [e-mail]
> Subject: 	RE: Re: CRMF encValue Field
> 
> Hi Carlisle, 
> 
> I accept your responses, but I have an extra comment. According to ANSI
> X9.42, the Diffie-Hellman algorithm OID listed in an Appendix B2 of
> RFC2510bis represents the algorithm OID for a Diffie-Hellman public key,
> however the algorithm OID in the PrivateKeyInfo as mentioned in PKCS#11
> identifies the "private key" algorithm OID. Note that Appendix A3 of ANSI
> X9.42 indicates that: 
> 
> "the syntax and encoding of private keys is considered to be
> implementation dependent and beyond the scope of this standard. It may,
> however, be useful for specific implementations or derivative standards to
> define a number type identified by dh-private-key to encode private keys".
> 
> Shouldn't the algorithm OID for an ANSI X9.42 Diffie-Hellman private key
> be added to Appendix B2 for this case? 
 
Technically, you are correct and this is a valid observation.  However, my
feeling is that we do not need to go to the trouble of getting another OID
for this.

If the protocol message included a generic blob then, by all means, we would
need some sort of indicator (i.e., an OID) to say whether the blob contained
a wrapped D-H public key or a wrapped D-H private key.  This is not the
situation here.  We've got a container whose explicit purpose is to carry a
wrapped private key; all we need to do is indicate whether it is a private
key for the RSA algorithm, the D-H algorithm, the DSA algorithm, etc..
Therefore, in this context, the AlgId specifies a particular public-key
*algorithm* (as opposed to a particular public key), and it is clear from
the syntax that what is wrapped is a private key that pertains to this
algorithm.

Perhaps this stretches the exact wording of PKCS #11 and X9.42 slightly, but
I really think there's no possibility of any confusion here, so a new OID is
unnecessary.  Let me know if you disagree.

By the way, thank you, as always, for your careful reading.  You continue to
be very helpful in making sure that various specifications are as clear and
precise as possible.

Carlisle.



Received: from mail.arabtrust.com (mail.arabtrust.com [216.247.149.19]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id HAA06009 for <[e-mail]>; Wed, 19 Jul 2000 07:02:09 -0700 (PDT)
Received: from jean [195.39.153.104] by mail.arabtrust.com (SMTPD32-6.00) id A5F7274500A6; Wed, 19 Jul 2000 10:06:47 -0400
From: "Jean Abraham" <[e-mail]>
To: "Paul Koning" <[e-mail]>
Cc: <[e-mail]>
Subject: RE: Signing what you don't understand
Date: Wed, 19 Jul 2000 17:03:06 +0300
Message-ID: <[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0)
In-Reply-To: <[e-mail]>
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6600

Paul,

Private keys are also embeded in the browser as well as on a Luna Token.

MD5 or hash.... are algorithms that generate the public key and private key
and also used for encryption purposes.  Now if a application has to be
subverted it can only be done with the operators knowledge or the creator of
the application.  Regarding the virus,  a virus cannot attack a private key.
The virus creator needs to know the algorithm of the private key or the
public key which will enable the virus to act.  Which is why any CA that
generates end-user certificates are generated or created with utmost
security in mind.

I hope that clears everything

Jean

-----Original Message-----
From: Paul Koning [mailto:[e-mail]]
Sent: Wednesday, July 19, 2000 4:53 PM
To: [e-mail]
Cc: [e-mail]
Subject: RE: Signing what you don't understand


>>>>> "Jean" == Jean Abraham <[e-mail]> writes:

 Jean> Digital signatures generation or creation is not based on the
 Jean> O/S of a particular PC but on the software that is used to
 Jean> generate it.  The most important apsect in a digital
 Jean> certificate(which is used to create a digital signature - end
 Jean> user) is that the private key is always with the owner and
 Jean> never in transist.

You're entirely missing the issue that started this long string of
notes.

First of all, the private key is "always with the owner" *only* if you
have a smartcard with embedded PKI engine.  Those exist but there
certainly are plenty of PK signing scenarios where they are not used.

Second, and this is what started things, the data being signed (hash
or whatever) are supplied to the signing engine by application
software.  If the application is subverted (easy to do with a number
of very popular applications) OR the underlying OS is subverted, an
attacker can supply different data to be signed from what you thought
you were signing.

So the OS is absolutely part of the puzzle; it is not sufficient to
consider only "the software that is used to generate [the
signature]".  The application may well be the weakest link, of course;
certainly in a number of well-known cases the application is indeed
the open barn door through which the viruses enter.  But it is by no
means the only possible barn door.

       paul




Received: from dfw7-1.relay.mail.uu.net (dfw7-1.relay.mail.uu.net [199.171.54.106]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id GAA05090 for <[e-mail]>; Wed, 19 Jul 2000 06:50:41 -0700 (PDT)
Received: from xedia.com by dfw7sosrv11.alter.net with SMTP  (peer crosschecked as: madway.xedia.com [198.202.232.199]) id QQiynf00686; Wed, 19 Jul 2000 13:53:11 GMT
Received: from tonga.xedia.com by xedia.com (4.1/SMI-4.1) id AA02752; Wed, 19 Jul 00 09:49:17 EDT
Received: by tonga.xedia.com (SMI-8.6/SMI-SVR4) id JAA14678; Wed, 19 Jul 2000 09:53:10 -0400
From: Paul Koning <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-Id: <[e-mail]>
Date: Wed, 19 Jul 2000 09:53:10 -0400 (EDT)
To: [e-mail]
Cc: [e-mail]
Subject: RE: Signing what you don't understand
References: <[e-mail]> <[e-mail]>
X-Mailer: VM 6.72 under 21.1 (patch 9) "Canyonlands" XEmacs Lucid

>>>>> "Jean" == Jean Abraham <[e-mail]> writes:

 Jean> Digital signatures generation or creation is not based on the
 Jean> O/S of a particular PC but on the software that is used to
 Jean> generate it.  The most important apsect in a digital
 Jean> certificate(which is used to create a digital signature - end
 Jean> user) is that the private key is always with the owner and
 Jean> never in transist. 

You're entirely missing the issue that started this long string of
notes. 

First of all, the private key is "always with the owner" *only* if you
have a smartcard with embedded PKI engine.  Those exist but there
certainly are plenty of PK signing scenarios where they are not used.

Second, and this is what started things, the data being signed (hash
or whatever) are supplied to the signing engine by application
software.  If the application is subverted (easy to do with a number
of very popular applications) OR the underlying OS is subverted, an
attacker can supply different data to be signed from what you thought
you were signing.

So the OS is absolutely part of the puzzle; it is not sufficient to
consider only "the software that is used to generate [the
signature]".  The application may well be the weakest link, of course;
certainly in a number of well-known cases the application is indeed
the open barn door through which the viruses enter.  But it is by no
means the only possible barn door.

       paul



Received: from mail.arabtrust.com (mail.arabtrust.com [216.247.149.19]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id GAA04433 for <[e-mail]>; Wed, 19 Jul 2000 06:31:31 -0700 (PDT)
Received: from jean [195.39.153.104] by mail.arabtrust.com (SMTPD32-6.00) id AEC12C18003E; Wed, 19 Jul 2000 09:36:01 -0400
From: "Jean Abraham" <[e-mail]>
To: "Paul Koning" <[e-mail]>
Cc: <[e-mail]>
Subject: RE: Signing what you don't understand
Date: Wed, 19 Jul 2000 16:32:20 +0300
Message-ID: <[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0)
In-Reply-To: <[e-mail]>
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6600

Digital signatures generation or creation is not based on the O/S of a
particular PC but on the software that is used to generate it.  The most
important apsect in a digital certificate(which is used to create a digital
signature - end user) is that the private key is always with the owner and
never in transist.  And the private key of the CA that signs the end-user
certs are NEVER in transist, therefore the authenticity of the certificate
is good and compromise of the end-user certificate ia void only from the PC
it would be installed on.

Jean

-----Original Message-----
From: Paul Koning [mailto:[e-mail]]
Sent: Wednesday, July 19, 2000 4:27 PM
To: [e-mail]
Cc: [e-mail]
Subject: RE: Signing what you don't understand


>>>>> "Jean" == Jean Abraham <[e-mail]> writes:

 Jean> Hi, There is a difference actually,

 Jean> When you sign the fedex package the person taking your
 Jean> signature doesnot know if its who you say you are. But in the
 Jean> case of a digital certificate only you can sign a email and
 Jean> from YOUR OWN computer which YOU ONLY have access for.

If the computer is a PC running the most popular PC operating systems,
that statement is extremely optimistic at best.

So long as security remains a non-goal of such operating systems,
digital signatures produduced by such systems will not offer any
meaningful guarantees of any kind.

	   paul




Received: from dfw7-1.relay.mail.uu.net (dfw7-1.relay.mail.uu.net [199.171.54.106]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id GAA03860 for <[e-mail]>; Wed, 19 Jul 2000 06:24:22 -0700 (PDT)
Received: from xedia.com by dfw7sosrv11.alter.net with SMTP  (peer crosschecked as: madway.xedia.com [198.202.232.199]) id QQiynd29706; Wed, 19 Jul 2000 13:26:52 GMT
Received: from tonga.xedia.com by xedia.com (4.1/SMI-4.1) id AA02385; Wed, 19 Jul 00 09:22:57 EDT
Received: by tonga.xedia.com (SMI-8.6/SMI-SVR4) id JAA14657; Wed, 19 Jul 2000 09:26:50 -0400
From: Paul Koning <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-Id: <[e-mail]>
Date: Wed, 19 Jul 2000 09:26:50 -0400 (EDT)
To: [e-mail]
Cc: [e-mail]
Subject: RE: Signing what you don't understand
References: <[e-mail]> <[e-mail]>
X-Mailer: VM 6.72 under 21.1 (patch 9) "Canyonlands" XEmacs Lucid

>>>>> "Jean" == Jean Abraham <[e-mail]> writes:

 Jean> Hi, There is a difference actually,

 Jean> When you sign the fedex package the person taking your
 Jean> signature doesnot know if its who you say you are. But in the
 Jean> case of a digital certificate only you can sign a email and
 Jean> from YOUR OWN computer which YOU ONLY have access for.

If the computer is a PC running the most popular PC operating systems,
that statement is extremely optimistic at best.

So long as security remains a non-goal of such operating systems,
digital signatures produduced by such systems will not offer any
meaningful guarantees of any kind.

	   paul



Received: from isis.wu-wien.ac.at (isis.wu-wien.ac.at [137.208.3.42]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id FAA00274 for <[e-mail]>; Wed, 19 Jul 2000 05:07:52 -0700 (PDT)
Received: from gourmet.wu-wien.ac.at ([e-mail] [137.208.224.124]) by isis.wu-wien.ac.at (8.8.7/8.8.7) with SMTP id OAA24978emf [e-mail]; Wed, 19 Jul 2000 14:09:57 +0200
From: Michael Fritscher <[e-mail]>
Reply-To: [e-mail]
Organization: WU Wien
To: Ben Laurie <[e-mail]>, Eric Murray <[e-mail]>
Subject: Re: Signing what you don't understand
Date: Wed, 19 Jul 2000 13:42:04 +0200
X-Mailer: KMail [version 1.0.28]
Content-Type: text/plain
Cc: [e-mail]
References: <[e-mail]> <[e-mail]> <[e-mail]>
In-Reply-To: <[e-mail]>
MIME-Version: 1.0
Message-Id: <[e-mail]>
Content-Transfer-Encoding: 8bit

On Wed, 19 Jul 2000, Ben Laurie wrote:
> Eric Murray wrote:
> > Digital signing in the human/legal means signing something different.
> > It always means "signing" something that makes sense to a human.  It might
> > mean using the crypto definition of "digital signing" to do it, or (under
> > the new US "digital signing" bill) it might mean clicking on a OK button
> > somewhere near the document.  This kind of digital signature
> > makes sense in a non-repudiation context- it's whole purpose is about NR.
> > 
> > Since "digital signing" is used all the time in the crypto sense, I'd
> > like to propose that when talking about the second kind of digital
> > signatures, they be called "digital signature of documents".
> 
> How about "legally binding digital signature". That certainly says what
> people want it to mean unambiguously.
> 

An other way of distinguishing between those two meanings of "digital
signature" seems to me the use of the terms "electronic signature" and
"digital signature" ETSI uses in its standard on Electronic Signature
Formats (ETSI ES 201 733) and some others, too.

As far as I understood, 

* "digital signature" is used for the "data appended to, or a
cryptographic transformation of, a data unit that allows a recipient of
the data unit to prove the source and integrity of the data unit and
protect against forgery (taken from ISO 7498-2)" -> i.e. the technical
part

* whereas "electronic signature" is used for the electronic analogy to
"real-life" signatures with the adequate legal consequences including the
signature policy, the signed user data, the digital signature and "other
signed attributes provided by the signer" (see ch. 4.2 of ETSI ES 201 733
V1.1.3) -> the legal/human mean

Cheers,
Michael Fritscher

-- 
------------------------------------------------------------
| Michael Fritscher	[e-mail]
| Department of Information Systems, New Media
| Vienna University of Economics and Business Administration
| http://wwwi.wu-wien.ac.at/people/Fritscher.html
| "A computer without windows NT is like a fish without a 
|  bicycle."
------------------------------------------------------------ 


Received: from freeby.ben.algroup.co.uk (sockittome.aldigital.co.uk [194.128.162.252]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id CAA13432 for <[e-mail]>; Wed, 19 Jul 2000 02:19:27 -0700 (PDT)
Received: from algroup.co.uk (naughty.ben.algroup.co.uk [193.133.15.107]) by freeby.ben.algroup.co.uk (8.6.12/8.6.12) with ESMTP id KAA07180; Wed, 19 Jul 2000 10:36:09 +0100
Message-ID: <[e-mail]>
Date: Wed, 19 Jul 2000 10:21:34 +0100
From: Ben Laurie <[e-mail]>
Organization: A.L. Group plc
X-Mailer: Mozilla 4.7 [en] (WinNT; I)
MIME-Version: 1.0
To: Eric Murray <[e-mail]>
CC: [e-mail]
Subject: Re: Signing what you don't understand
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Eric Murray wrote:
> Digital signing in the human/legal means signing something different.
> It always means "signing" something that makes sense to a human.  It might
> mean using the crypto definition of "digital signing" to do it, or (under
> the new US "digital signing" bill) it might mean clicking on a OK button
> somewhere near the document.  This kind of digital signature
> makes sense in a non-repudiation context- it's whole purpose is about NR.
> 
> Since "digital signing" is used all the time in the crypto sense, I'd
> like to propose that when talking about the second kind of digital
> signatures, they be called "digital signature of documents".

How about "legally binding digital signature". That certainly says what
people want it to mean unambiguously.

Cheers,

Ben.

--
http://www.apache-ssl.org/ben.html

Coming to ApacheCon Europe 2000? http://apachecon.com/


Received: from freeby.ben.algroup.co.uk (sockittome.aldigital.co.uk [194.128.162.252]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id XAA07679 for <[e-mail]>; Tue, 18 Jul 2000 23:38:20 -0700 (PDT)
Received: from algroup.co.uk (naughty.ben.algroup.co.uk [193.133.15.107]) by freeby.ben.algroup.co.uk (8.6.12/8.6.12) with ESMTP id XAA02725; Tue, 18 Jul 2000 23:47:33 +0100
Message-ID: <[e-mail]>
Date: Tue, 18 Jul 2000 23:33:07 +0100
From: Ben Laurie <[e-mail]>
Organization: A.L. Group plc
X-Mailer: Mozilla 4.7 [en] (WinNT; I)
MIME-Version: 1.0
To: Terry Hayes <[e-mail]>
CC: Adrian McCullagh <[e-mail]>, "'Stephen Kent'" <[e-mail]>, [e-mail]
Subject: Re: Signing what you don't understand
References: <[e-mail]> <[e-mail]> <[e-mail]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Terry Hayes wrote:
> 
> Ben Laurie wrote:
> 
> > > I also do not agree with your position that the NR bit can signal any intent
> > > either way.  With respect, intent is ascertained at the time of signing.  A
> > > certificate has nothing what so ever to do with signing.  Its primary
> > > purpose is to identify a public key that corresponds to a private key that
> > > may be held by some previously identified person or entity.  The public key
> > > is used to verify a digital signature that has supposedly been created using
> > > the corresponding private key.  That is it as far as I understand it unless
> > > there is some other primary purpose that I do not know.  I do not see the
> > > relationship between digitally signing a document and the contents of a
> > > certificate. Verification of the signature at some later time is a different
> > > issue which may involve the use of a certificate but this may not be so.
> >
> > The relationship is that the creator of the certificate has stated what
> > he intends the use of the signature to be. So, if the NR bit is not set,
> > the owner of the private key has effectively stated that they do not
> > expect the key to be used for NR!
> 
> This is the root of the problem (in my opinion).  While you say that the owner of
> the private key has stated what they want the key to be used for, in fact the
> "creator" of the certificate is the CA, not the end entity.  This level of
> indirection is very troubling for some.  It allows additional certificates to be
> created (possibly by untrustworthy CA) that cloud the meaning of the signature.

Since a certificate is comprised of public information signed by a CA,
clearly a CA can create a certificate saying more-or-less what they
want. I suppose this is an argument for having certificates that are
dual-signed (by the CA and the public key the contain).

> In my opinion, it is best to put a clear statement of the intended purpose of the
> signature in the signature itself.  A simple policy (or application) OID included
> in the authenticated attributes would do the trick.  Failing that, the fingerprint
> of the certificate itself should be included (as is proposed elsewhere), and the
> application should check that the proper extensions are included in that
> certificate prior to signing.

Or the relying application could check. Keep heading in this direction
and you'll get SPKI (which would be no bad thing, IMO).

Cheers,

Ben.

--
http://www.apache-ssl.org/ben.html

Coming to ApacheCon Europe 2000? http://apachecon.com/


Received: from mail.arabtrust.com (mail.arabtrust.com [216.247.149.19]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id WAA04593 for <[e-mail]>; Tue, 18 Jul 2000 22:42:39 -0700 (PDT)
Received: from jean [195.39.160.111] by mail.arabtrust.com (SMTPD32-6.00) id A0E159A9011A; Wed, 19 Jul 2000 01:47:13 -0400
From: "Jean Abraham" <[e-mail]>
To: "Heimberg, Jim" <[e-mail]>
Cc: <[e-mail]>
Subject: RE: Signing what you don't understand
Date: Wed, 19 Jul 2000 08:43:29 +0300
Message-ID: <[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0)
In-Reply-To: <[e-mail]>
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6600
Importance: Normal

Hi,

There is a difference actually,

When you sign the fedex package the person taking your signature doesnot
know if its who you say you are. But in the case of a digital certificate
only you can sign a email and from YOUR OWN computer which YOU ONLY have
access for.

Regarding the fooling of the CA, when a CA is created it is a trusted third
party that creates it (trusted by the world).  And if it is not a trusted
third party then you have the option to accept or decline opening the email
or trusting the email.

Jean

Key Manager
Arabtrust
Kuwait

[e-mail]


-----Original Message-----
From: Heimberg, Jim [mailto:[e-mail]]
Sent: Tuesday, July 18, 2000 9:44 PM
To: 'Tony Bartoletti'; Mitchell Arnone; Golkin Ken (CAP CMC)
Cc: 'Adrian McCullagh'; 'Stephen Kent'; [e-mail]
Subject: RE: Signing what you don't understand


Are we moving in the direction of the Twilight Zone.  If you could fool the
CA with a false driver's licence, why don't you just get the false ID, forge
his checks, and raid his bank account?  The signature is a mark that is
either accepted as being valid or is forged.  There is no difference with
the digital signature.  Your digital signature is not any better or any
worse than your pen-and-ink signature.  You decide when to use it.  If you
receive a FEDEX, you sign for receipt, right?  If you receive an e-mail,
what is different than signing to signify receipt?  That signature does not
do the same thing as if you were signing the $10M contract contained in the
FEDEX package or the one contained in the e-mail.  Where is the issue?
Jim

-----Original Message-----
From: Tony Bartoletti [mailto:[e-mail]]
Sent: Tuesday, July 18, 2000 2:00 PM
To: Mitchell Arnone; Golkin Ken (CAP CMC)
Cc: 'Adrian McCullagh'; 'Stephen Kent'; [e-mail]
Subject: Re: Signing what you don't understand


Ah, that life were really so simple ... :)

At 12:00 PM 7/18/00 -0400, Mitchell Arnone wrote:
>I have a hard time imagining use of digital signatures for anything
>that does not require Non-repudiation.

On one level, I can agree with this statement.  One wants to say
"What other purpose for applying an (assumably unforgeable) mark
other than to have it be unforgeable?"  And as I have argued long
previously, the "math of it" gets you this much, regardless of the
setting of key-usage bits or other implied intent.

But that is really not saying very much.

What (other than certification, to start with) attaches this
disembodied signing-key to an "actor"?

>As for authentication, digital signatures (which requires access to the
>private key, Not a Digital Certificate) demonstrates proof positive that
>"a person is who they say they are" and provides a means by which
>unquestionable proof can be established that the owner of a given
>certificate responded to a challenge and subsequently gained access to
>some secure resource.

This assertion WAY overstates the strength of the situation:

If I can fool a CA (with fake driver's license, etc) into certifying
my key-pair as "belongs to Mitchell Arnone of b2bcommunications.com",
does my use of this key provide "proof positive" that I am who I say
I am?  Or equivalently, proof that the real Mitchell took action?

And would it matter that, when invoking a signature, that I must use my
personal passcode to unlock MY (presumably, your) signature key?

To clear one's head, begin with the understanding that the application of
(and verification of) a (mechanical) digital signature serves (effectively)
as proof positive of three central facts:

a.  The "wielder of the signature" (person or process) indeed possessed
     the secret-key corresponding to the public key used in verification.

b.  Some "process" had access to both the secret-key, and the document
     (or the hash of the document.)

c.  The document (or hash) verified is exactly the document (or hash)
     that was mechanically signed. (No tampering took place.)

Now, we would like "wielder of the signature" to have a more substantial
form of identity.  We attempt to create this "sense of substance" by the
use of certificates.  But there are clearly wide variances by which this
certification may proceed, and from which assertions can flow.

>In my mind, authentication and digital signatures are inseparable and we
>would be better served to refrain from focusing on the granular
differences.

"Agree in Principle" ... however ...

Contrast "signing important legal contract" with "signing receipt of email".

The former should (likely) require an active and duly witnessed
"live person", and a trusted display device that guarantees that
what is signed is precisely no more and no less than what is being
displayed, and further displays the particulars of the key-ownership
certificate, to help ensure that the "witnesses" are not being fooled
into attesting to my signing with your key.  Expensive technology.

The latter is a useful application of "digital signature mechanics"
that I might employ to let people know that "their mail was delivered
to the right address".  I might configure my mailer to create such
return receipts automatically, even while I am away.  In such a case,
is it True or False that the application is "signing without the
knowledge of the owner of the certificate?"  Depends upon perspective.
Was there a sufficient "challenge"?  Was it enough to effect that
challenge (only) during my act of configuring my email-robot to
employ the key?  Should the act of configuring my email-robot require
witnesses and the expensive secured display device described above?

If such strong measures are unneeded for this application, how
can one ensure the code or process is not subverted to effect
signatures for contracts (or arguably so, to repudiate a former
signature made with a stronger technology.)

Alternatively, do you argue that "email return receipts" should
remain "unsigned" by a technology so "strong"?

___tony___

>Mitchell Arnone
>PKI Engineer
>
>"Golkin, Ken (CAP, CMC)" wrote:
>>
>>
>>This discussion seems to be confusing two different uses for certificates
>>1) Authentication (I am who I say I am)
>>2) Signature (I signed a legally binding document)
>>
>>In the first case I showed my company issue picture ID (certificate) to
>>the guard at the door and he let me in the building this morning.
>>
>>In the second case I stopped at the hardware store on the way home last
>>night to buy a box of nails and some other things.  At the check out I
>>showed them my charge card (certificate) then signed the sales
>>slip.  Which legally obligated me to pay $24.86.
>>
>>The certificate policy (defined as: A named set of rules that indicates
the
>>        applicability of a public key certificate to a particular
>>        community or class of application with common security
>>        requirements. For example, a particular certificate policy might
>>        indicate applicability of a type of public key certificate to the
>>        authentication of electronic data interchange transactions for
>>        the trading of goods within a given price range.) in X.509 PKiX
>> roadmap makes it clear that all certificates are not created equal.
>>
>>The Canadian Government and United States Government PKI initiatives have
>>defined multiple levels of assurance, and as far as I can tell, most
>>business applications of PKI are following the government lead.
>>
>>If I'm loaning someone $250,000 to buy a house I obviously need a greater
>>level of assurance that they are who they are (and their bank is who they
>>say they are) then was required by the checkout at the hardware store or
>>the guard at the entrance.
>>
>>-----Original Message-----
>>From: Adrian McCullagh
>>[<mailto:[e-mail]>mailto:[e-mail]

>>ns.com.au]
>>Sent: Monday, July 17, 2000 11:08 PM
>>To: 'Stephen Kent'
>>Cc: [e-mail]
>>Subject: RE: Signing what you don't understand
>>
>>Stephen,
>>
>>I do not want to get into an argument with you.  Yes I am a lawyer but I
>>also have a technical background so your suggestion otherwise, I thought
was
>>not moving the discussion forward. Admittedly, I do not possess the
>>technical knowledge that you have.
>>
>>Your example is well put but is this really a digital signature or is it a
>>set of bits (a mark) that has been affixed using the same technology known
>>as digital signature technology.
>>
>>You mention the difference between the 2 intents.  I would be surprised,
if
>>anyone (other than the technically minded) even knows that a challenge
>>response is even being "signed".  There is no intent at all in this case.
It
>>is the technology as designed that is effecting the response to the
>>challenge.  I am surprised that "you" sign authentication challenges, just
>>for authentication purposes.  Is it really a signature?  Are you really
>>signing the authentication challenge or is it the software on your machine
>>effecting the response to the challenge?
>>
>>To me this is not a signature.  It may use digital signature technology
but
>>it is not a signature.  This is probably the problem.  It is the use of
the
>>word "signature" which is a technical term but has been used by the PKI
>>community to cover a myriad of uses.  Some uses of the term by the PKI
>>community are confusing.
>>
>>I also do not agree with your position that the NR bit can signal any
intent
>>either way.  With respect, intent is ascertained at the time of signing.
A
>>certificate has nothing what so ever to do with signing.  Its primary
>>purpose is to identify a public key that corresponds to a private key that
>>may be held by some previously identified person or entity.  The public
key
>>is used to verify a digital signature that has supposedly been created
using
>>the corresponding private key.  That is it as far as I understand it
unless
>>there is some other primary purpose that I do not know.  I do not see the
>>relationship between digitally signing a document and the contents of a
>>certificate. Verification of the signature at some later time is a
different
>>issue which may involve the use of a certificate but this may not be so.
>>
>>Adrian McCullagh
>>Director of Electronic Commerce         Tel: [phone]
>>Gadens Lawyers                                  Fax: [phone]
>>level 39
>>Central Plaza 1
>>345 Queen Street
>>Brisbane Australia 4000
>>
>>Ph. D. Candidate
>>Thesis "The Incorporation of Trust Strategies in Digital Signature
>>Regimes for Elec. Comm."
>>Information Security Research Centre
>>Queensland University of Technology
>>
>>
>>-----Original Message-----
>>From: Stephen Kent [<mailto:[e-mail]>mailto:[e-mail]]
>>Sent: Tuesday, July 18, 2000 10:00 AM
>>To: Adrian McCullagh
>>Cc: [e-mail]
>>Subject: RE: Signing what you don't understand
>>
>>At 12:50 PM +1000 7/15/00, Adrian McCullagh wrote:
>> >Stephen
>> >
>> >I really do not understand your response.  Why would anyone sign a
>> document
>> >that they do not understand.  It does not make sense.  If I sent you a
>> >document written in Chinese and assume you can not read Chinese and at
the
>> >same time I said just sign this - Why would you sign it.  Now if you
>>trusted
>> >me then you may sign it based upon the information about the document
that
>>I
>> >tell you.  A classic case for Non-est-factum.  But all the cases that I
>>have
>> >read clearly rely upon some information provided by an Alleged trusted
>>third
>> >party.  Usually some relative.  So without some external information
being
>> >provided by a third party it is not as far as I can determine possible
to
>> >rely upon non est factum.
>>
>>Because we sign authentication challenges, just for authentication
>>purposes, but not for NR purposes, it is prudent to distinguish
>>between the two intents.  Your comments seem to ignore this use of
>>digital signature technology. One way of signalling intent is via the
>>NR bit. Although it has been argued that having this bit set to True
>>does not necessarily signal intent to sign for NR purposes, having it
>>set to False certainly signals an intent to not be bound re NR.
>>
>>(Your use of Latin and your e-mail "signature" suggests a legal, but
>>perhaps not a technical background. We've also decided, after much
>>debate, that PKIX deals with technical aspects of NR, not legal
>>details that may vary based upon jurisdiction.)
>>
>> >Also what does a "bit" in a certificate got to do with non-repudiation.
>>The
>> >commercial world and the law does not in my opinion support this
position
>>of
>> >yours.  You appear to be on a path to re-engineering the entire
commercial
>> >legal fabric and as such I with the greatest respect I do not  believe
>> that
>> >society and the law will buy into it.  With out the commercial
involvement
>> >PKI will not survive.
>>
>>The position is not just mine.  Sorry of you don't understand, or
>>merely don't agree with the use of the NR bit, or its name, but we
>>had this debate a while ago and we're not having it again.
>>
>> >
>> >I do not understand how - "what you are proposing" - will work in
>> practical
>> >terms.
>>
>>I'm not "proposing," but I am citing existing Internet and ITU
>>standards and the applicability to the question at hand.
>>
>>Steve

Tony Bartoletti 925-422-3881 <[e-mail]>
Information Operations, Warfare and Assurance Center
Lawrence Livermore National Laboratory
Livermore, CA 94551-9900



Received: from slack.lne.com ([209.157.136.81]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id SAA18596 for <[e-mail]>; Tue, 18 Jul 2000 18:45:22 -0700 (PDT)
Received: (from ericm@localhost) by slack.lne.com (8.9.3/8.9.3) id SAA17850 for [e-mail]; Tue, 18 Jul 2000 18:47:20 -0700
Date: Tue, 18 Jul 2000 18:47:19 -0700
From: Eric Murray <[e-mail]>
To: [e-mail]
Subject: Re: Signing what you don't understand
Message-ID: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Mailer: Mutt 1.0pre3us
In-Reply-To: <[e-mail]>

On Tue, Jul 18, 2000 at 09:37:31AM -0700, Eric Rescorla wrote:
> "Mitchell Arnone" <[e-mail]> writes:
> 
> > [1  <text/plain; us-ascii (7bit)>]
> > I am sure I don't have the background in PKI as most of those
> > contributing to this list but I would like to share some ideas:
> > 
> > I have a hard time imagining use of digital signatures for anything that
> > does not require Non-repudiation. 
> Then you're not imagining very hard. As previously noted,
> digital signatures are used all the time in non non-repudiation
> contexts. For instance, for verifying the authenticity of
> keying material in IKE handshakes.


Just to make it really clear (because it's obviously not clear to
some people), there's "digital signing" in the human/legal
sense, and "digital signing" in the crypto sense.

Digital signing in crypto sense means applying an encryption function to
a number and a private key, such that any holder of the public key that
corresponds to the private key can decrypt the number.  If that number
is a hash of a document, then the party doing the verification can do
their own hash and compare the values.  (yea, I know there's other ways
to do a signature, but this is the most common).  You can also sign a
nonce or keying material as part of a protocol to prove identity or to
set up a secure channel.  Repudiation of those things, especially the
exchange of keying material, doesn't make sense.

Digital signing in the human/legal means signing something different.
It always means "signing" something that makes sense to a human.  It might
mean using the crypto definition of "digital signing" to do it, or (under
the new US "digital signing" bill) it might mean clicking on a OK button
somewhere near the document.  This kind of digital signature 
makes sense in a non-repudiation context- it's whole purpose is about NR.

Since "digital signing" is used all the time in the crypto sense, I'd
like to propose that when talking about the second kind of digital
signatures, they be called "digital signature of documents".

I know this is obvious to a lot of people, but now having stated
the obvious, there's no excuse for anyone here to mistake one kind of
digital signature for the other.... you'll have to find something
else to split hairs about now. :-)

-- 
 Eric Murray www.lne.com/ericm  ericm at the site lne.com  PGP keyid:E03F65E5
Security consulting: secure protocols, security reviews, standards, smartcards. 


Received: from aspams52.cai.com (aspams52.cai.com [155.35.248.76]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id SAA15869 for <[e-mail]>; Tue, 18 Jul 2000 18:21:30 -0700 (PDT)
Received: by aspams52.cai.com with Internet Mail Service (5.5.2650.21) id <3X7A07BB>; Wed, 19 Jul 2000 11:23:32 +1000
Message-ID: <[e-mail]>
From: "Ramsay, Ron" <[e-mail]>
To: Mitchell Arnone <[e-mail]>
Cc: "'Adrian McCullagh'" <[e-mail]>, [e-mail]
Subject: RE: Signing what you don't understand
Date: Wed, 19 Jul 2000 11:23:35 +1000
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain; charset="iso-8859-1"

Hi,
 
I disagree. In fact, I believe that Adrian made a very clear point. He
referred to the act of 'signing', which he took to be an act that took place
in the world of people, not computers. It seems that, in the world of
computers, this relates to the explicit placing of a digital signature on a
document. It also invokes non-repudiation procedures which, while being
strongly debated, still are reasonably well understood.
 
Against this is the digital process that has been characterised as
authentication. In this process, I simply prove that I am 'me' or,
digitally, that I hold a particular private key. Perhaps the true difference
here is that the signature is applied to a challenge where, regarding
'signing', the signature is applied to a document.
 
I am happy with this distinction.
 
Some argue that it should be possible to apply a 'repudiable' signature to a
document. I think that this becomes a legal issue. Is it rather like, what
liability attaches to me when I sign for delivery. The usual answer is none,
really, it is simply a proof of delivery. In fact, someone else at that
address may have signed for it on your behalf. It is  probably true that
there is no such thing as a repudiable signature (in the sense of
'signing'), but one can reasonably expect that the legal situation will be
similar to the case now for bio-signatures. Technical uses of public key
algorithms for other purposes (authentication) should not be considered
'signing', as understood by non-technical people.
 
Ron.

-----Original Message-----
From: Mitchell Arnone [mailto:[e-mail]]
Sent: Wednesday, 19 July 2000 2:00
To: Golkin Ken (CAP CMC)
Cc: 'Adrian McCullagh'; 'Stephen Kent'; [e-mail]
Subject: Re: Signing what you don't understand


I am sure I don't have the background in PKI as most of those contributing
to this list but I would like to share some ideas: 

I have a hard time imagining use of digital signatures for anything that
does not require Non-repudiation.   There are a number of NR issues
addressed with digital signatures including NR related to the creation of an
object as well as Non-repudiation of activities such as delivery/receipt of
messages, knowledge (proof that a message was read), and much more.
Sometimes I feel that the term "signature" creates a paradigm that can
become difficult to transcend but I cannot come up with a better descriptor
of the intent behind the process. 


As for authentication, digital signatures (which requires access to the
private key, Not a Digital Certificate) demonstrates proof positive that "a
person is who they say they are" and provides a means by which
unquestionable proof can be established that the owner of a given
certificate responded to a challenge and subsequently gained access to some
secure resource.  It it important to remember that a digital certificate is
public in nature and without the corresponding private key, it is
meaningless.  When a challenge is issued in the authentication process, the
act of signing that challenge must manifest itself by requiring the user to
submit his or her passcode to unlock the private key.  If there is no
challenge (i.e. the process of signing without the knowledge of the owner of
the certificate) then the authentication process is completely invalidated.



The following is a quote from FIPS 196: 


"To acceptably implement this standard, an implementation must meet the
following criteria: 


1) Each entity in an authentication exchange must use a FIPS approved
digital signature algorithm to generate and/or verify digital signatures; 


2) Each entity must generate (pseudo)random numbers using a FIPS approved
(pseudo)random number generator; 


3) Each entity acting as a claimant must be bound to a public/private key
pair; the private key should remain in the sole control of the claimant who
uses that key to sign a random challenge. The key binding requires a unique
authentication identifier for each claimant, so that a verifier can
distinguish between multiple claimants; and 


4) One or both of the authentication protocols in this standard must be
implemented. For each protocol, steps and token fields marked as [OPTIONAL]
do not need to be implemented, except where indicated otherwise. However,
all other steps and token fields must be implemented." 


In my mind, authentication and digital signatures are inseparable and we
would be better served to refrain from focusing on the granular differences.



Mitchell Arnone 
PKI Engineer 


"Golkin, Ken (CAP, CMC)" wrote: 


  

This discussion seems to be confusing two different uses for certificates 
1) Authentication (I am who I say I am) 
2) Signature (I signed a legally binding document) 


In the first case I showed my company issue picture ID (certificate) to the
guard at the door and he let me in the building this morning. 


In the second case I stopped at the hardware store on the way home last
night to buy a box of nails and some other things.  At the check out I
showed them my charge card (certificate) then signed the sales slip.  Which
legally obligated me to pay $24.86. 


The certificate policy (defined as: A named set of rules that indicates the 
       applicability of a public key certificate to a particular 
       community or class of application with common security 
       requirements. For example, a particular certificate policy might 
       indicate applicability of a type of public key certificate to the 
       authentication of electronic data interchange transactions for 
       the trading of goods within a given price range.) in X.509 PKiX
roadmap makes it clear that all certificates are not created equal. 


The Canadian Government and United States Government PKI initiatives have
defined multiple levels of assurance, and as far as I can tell, most
business applications of PKI are following the government lead. 


If I'm loaning someone $250,000 to buy a house I obviously need a greater
level of assurance that they are who they are (and their bank is who they
say they are) then was required by the checkout at the hardware store or the
guard at the entrance. 


-----Original Message----- 
From: Adrian McCullagh [ mailto:[e-mail]
<mailto:[e-mail]> ] 
Sent: Monday, July 17, 2000 11:08 PM 
To: 'Stephen Kent' 
Cc: [e-mail] 
Subject: RE: Signing what you don't understand 


Stephen, 


I do not want to get into an argument with you.  Yes I am a lawyer but I 
also have a technical background so your suggestion otherwise, I thought was

not moving the discussion forward. Admittedly, I do not possess the 
technical knowledge that you have. 


Your example is well put but is this really a digital signature or is it a 
set of bits (a mark) that has been affixed using the same technology known 
as digital signature technology. 


You mention the difference between the 2 intents.  I would be surprised, if 
anyone (other than the technically minded) even knows that a challenge 
response is even being "signed".  There is no intent at all in this case. It

is the technology as designed that is effecting the response to the 
challenge.  I am surprised that "you" sign authentication challenges, just 
for authentication purposes.  Is it really a signature?  Are you really 
signing the authentication challenge or is it the software on your machine 
effecting the response to the challenge? 


To me this is not a signature.  It may use digital signature technology but 
it is not a signature.  This is probably the problem.  It is the use of the 
word "signature" which is a technical term but has been used by the PKI 
community to cover a myriad of uses.  Some uses of the term by the PKI 
community are confusing. 


I also do not agree with your position that the NR bit can signal any intent

either way.  With respect, intent is ascertained at the time of signing.  A 
certificate has nothing what so ever to do with signing.  Its primary 
purpose is to identify a public key that corresponds to a private key that 
may be held by some previously identified person or entity.  The public key 
is used to verify a digital signature that has supposedly been created using

the corresponding private key.  That is it as far as I understand it unless 
there is some other primary purpose that I do not know.  I do not see the 
relationship between digitally signing a document and the contents of a 
certificate. Verification of the signature at some later time is a different

issue which may involve the use of a certificate but this may not be so. 


Adrian McCullagh 
Director of Electronic Commerce         Tel: [phone] 
Gadens Lawyers                                  Fax: [phone] 
level 39 
Central Plaza 1 
345 Queen Street 
Brisbane Australia 4000 


Ph. D. Candidate 
Thesis "The Incorporation of Trust Strategies in Digital Signature 
Regimes for Elec. Comm." 
Information Security Research Centre 
Queensland University of Technology 
  


-----Original Message----- 
From: Stephen Kent [ mailto:[e-mail] <mailto:[e-mail]> ] 
Sent: Tuesday, July 18, 2000 10:00 AM 
To: Adrian McCullagh 
Cc: [e-mail] 
Subject: RE: Signing what you don't understand 


At 12:50 PM +1000 7/15/00, Adrian McCullagh wrote: 
>Stephen 
> 
>I really do not understand your response.  Why would anyone sign a document

>that they do not understand.  It does not make sense.  If I sent you a 
>document written in Chinese and assume you can not read Chinese and at the 
>same time I said just sign this - Why would you sign it.  Now if you 
trusted 
>me then you may sign it based upon the information about the document that 
I 
>tell you.  A classic case for Non-est-factum.  But all the cases that I 
have 
>read clearly rely upon some information provided by an Alleged trusted 
third 
>party.  Usually some relative.  So without some external information being 
>provided by a third party it is not as far as I can determine possible to 
>rely upon non est factum. 


Because we sign authentication challenges, just for authentication 
purposes, but not for NR purposes, it is prudent to distinguish 
between the two intents.  Your comments seem to ignore this use of 
digital signature technology. One way of signalling intent is via the 
NR bit. Although it has been argued that having this bit set to True 
does not necessarily signal intent to sign for NR purposes, having it 
set to False certainly signals an intent to not be bound re NR. 


(Your use of Latin and your e-mail "signature" suggests a legal, but 
perhaps not a technical background. We've also decided, after much 
debate, that PKIX deals with technical aspects of NR, not legal 
details that may vary based upon jurisdiction.) 


>Also what does a "bit" in a certificate got to do with non-repudiation. 
The 
>commercial world and the law does not in my opinion support this position 
of 
>yours.  You appear to be on a path to re-engineering the entire commercial 
>legal fabric and as such I with the greatest respect I do not  believe that

>society and the law will buy into it.  With out the commercial involvement 
>PKI will not survive. 


The position is not just mine.  Sorry of you don't understand, or 
merely don't agree with the use of the NR bit, or its name, but we 
had this debate a while ago and we're not having it again. 


> 
>I do not understand how - "what you are proposing" - will work in practical

>terms. 


I'm not "proposing," but I am citing existing Internet and ITU 
standards and the applicability to the question at hand. 


Steve



Received: from maynard.mail.mindspring.net (maynard.mail.mindspring.net [207.69.200.243]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id QAA10969 for <[e-mail]>; Tue, 18 Jul 2000 16:23:01 -0700 (PDT)
Received: from romeo.rtfm.com (user-33qti51.dialup.mindspring.com [199.174.200.161]) by maynard.mail.mindspring.net (8.9.3/8.8.5) with ESMTP id TAA30144; Tue, 18 Jul 2000 19:24:05 -0400 (EDT)
Received: (ekr@localhost) by romeo.rtfm.com (8.9.3/8.6.4) id JAA10881; Tue, 18 Jul 2000 09:37:32 -0700 (PDT)
Sender: [e-mail]
To: "Mitchell Arnone" <[e-mail]>
Cc: "Golkin Ken (CAP CMC)" <[e-mail]>, "'Adrian McCullagh'" <[e-mail]>, "'Stephen Kent'" <[e-mail]>, [e-mail]
Subject: Re: Signing what you don't understand
References: <[e-mail]> <[e-mail]>
Reply-to: EKR <[e-mail]>
Mime-Version: 1.0 (generated by tm-edit 7.108)
Content-Type: text/plain; charset=US-ASCII
From: Eric Rescorla <[e-mail]>
Date: 18 Jul 2000 09:37:31 -0700
In-Reply-To: "Mitchell Arnone"'s message of "Tue, 18 Jul 2000 12:00:14 -0400"
Message-ID: <[e-mail]>
Lines: 17
X-Mailer: Gnus v5.6.45/XEmacs 20.4 - "Emerald"

"Mitchell Arnone" <[e-mail]> writes:

> [1  <text/plain; us-ascii (7bit)>]
> I am sure I don't have the background in PKI as most of those
> contributing to this list but I would like to share some ideas:
> 
> I have a hard time imagining use of digital signatures for anything that
> does not require Non-repudiation. 
Then you're not imagining very hard. As previously noted,
digital signatures are used all the time in non non-repudiation
contexts. For instance, for verifying the authenticity of
keying material in IKE handshakes.

-Ekr

[Eric Rescorla                                   [e-mail]]



Received: from poptop.llnl.gov (poptop.llnl.gov [128.115.41.70]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id MAA05788 for <[e-mail]>; Tue, 18 Jul 2000 12:22:09 -0700 (PDT)
Received: from catalyst (catalyst.llnl.gov [128.115.222.68]) by poptop.llnl.gov (8.8.8/LLNL-3.0.2/pop.llnl.gov-5.1) with ESMTP id MAA12604; Tue, 18 Jul 2000 12:19:19 -0700 (PDT)
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.2 
Date: Tue, 18 Jul 2000 12:26:38 -0700
To: "Heimberg, Jim" <[e-mail]>, Mitchell Arnone <[e-mail]>, "Golkin Ken (CAP CMC)" <[e-mail]>
From: Tony Bartoletti <[e-mail]>
Subject: RE: Signing what you don't understand
Cc: "'Adrian McCullagh'" <[e-mail]>, "'Stephen Kent'" <[e-mail]>, [e-mail]
In-Reply-To: <[e-mail] .gte.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed

At 02:43 PM 7/18/00 -0400, Heimberg, Jim wrote:
>If you receive an e-mail, what is different than signing to signify receipt?
>That signature does not do the same thing as if you were signing the $10M
>contract contained in the FEDEX package or the one contained in the e-mail.
>Where is the issue?
>Jim

(I neglected this point)

Granted, no court of law will likely hold me to some forged $10M contract
based upon a simple digital signature.  But there is always an exploitable
grey area, even if only between $5, $50, $500, where it will be commonplace
to rely upon lightweight (digital) signature activity.

In such a case, how can you be sure that your browser, configured
to automatically sign (harmless) email receipts, does not become
subverted by a trojan plug-in to sign other things you may be
unaware of?  Especially so, if the "evidence" only demonstrates
"it was the same key, owned by you."

___tony___
Tony Bartoletti 925-422-3881 <[e-mail]>
Information Operations, Warfare and Assurance Center
Lawrence Livermore National Laboratory
Livermore, CA 94551-9900



Received: from Newman.GSC.GTE.Com ([e-mail] [192.160.62.66]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id MAA05591 for <[e-mail]>; Tue, 18 Jul 2000 12:19:14 -0700 (PDT)
Received: from gscex01.gsc.gte.com ("port 1343"@gscex01.ndhm.gsc.gte.com [155.95.162.170]) by Newman.GSC.GTE.Com (PMDF V5.2-30 #38015) with ESMTP id <[e-mail]> for [e-mail]; Tue, 18 Jul 2000 15:21:40 -0400 (EDT)
Received: by GSCEX01.gsc.gte.com with Internet Mail Service (5.5.2448.0) id <3L3TJJK5>; Tue, 18 Jul 2000 15:21:39 -0400
Content-return: allowed
Date: Tue, 18 Jul 2000 15:21:39 -0400
From: "Heimberg, Jim" <[e-mail]>
Subject: RE: Signing what you don't understand
To: "'Tony Bartoletti'" <[e-mail]>, Mitchell Arnone <[e-mail]>, "Golkin Ken (CAP CMC)" <[e-mail]>
Cc: "'Adrian McCullagh'" <[e-mail]>, "'Stephen Kent'" <[e-mail]>, [e-mail]
Message-id: <[e-mail]>
MIME-version: 1.0
X-Mailer: Internet Mail Service (5.5.2448.0)
Content-type: text/plain;	charset="iso-8859-1"

A convincing argument for hardware tokens and biometrics if ever I heard
one.

-----Original Message-----
From: Tony Bartoletti [mailto:[e-mail]]
Sent: Tuesday, July 18, 2000 3:27 PM
To: Heimberg, Jim; Mitchell Arnone; Golkin Ken (CAP CMC)
Cc: 'Adrian McCullagh'; 'Stephen Kent'; [e-mail]
Subject: RE: Signing what you don't understand


At 02:43 PM 7/18/00 -0400, Heimberg, Jim wrote:
>If you receive an e-mail, what is different than signing to signify
receipt?
>That signature does not do the same thing as if you were signing the $10M
>contract contained in the FEDEX package or the one contained in the e-mail.
>Where is the issue?
>Jim

(I neglected this point)

Granted, no court of law will likely hold me to some forged $10M contract
based upon a simple digital signature.  But there is always an exploitable
grey area, even if only between $5, $50, $500, where it will be commonplace
to rely upon lightweight (digital) signature activity.

In such a case, how can you be sure that your browser, configured
to automatically sign (harmless) email receipts, does not become
subverted by a trojan plug-in to sign other things you may be
unaware of?  Especially so, if the "evidence" only demonstrates
"it was the same key, owned by you."

___tony___
Tony Bartoletti 925-422-3881 <[e-mail]>
Information Operations, Warfare and Assurance Center
Lawrence Livermore National Laboratory
Livermore, CA 94551-9900


Received: from poptop.llnl.gov (poptop.llnl.gov [128.115.41.70]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id MAA05539 for <[e-mail]>; Tue, 18 Jul 2000 12:18:08 -0700 (PDT)
Received: from catalyst (catalyst.llnl.gov [128.115.222.68]) by poptop.llnl.gov (8.8.8/LLNL-3.0.2/pop.llnl.gov-5.1) with ESMTP id MAA07386; Tue, 18 Jul 2000 12:08:37 -0700 (PDT)
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.2 
Date: Tue, 18 Jul 2000 12:15:56 -0700
To: "Heimberg, Jim" <[e-mail]>, Mitchell Arnone <[e-mail]>, "Golkin Ken (CAP CMC)" <[e-mail]>
From: Tony Bartoletti <[e-mail]>
Subject: RE: Signing what you don't understand
Cc: "'Adrian McCullagh'" <[e-mail]>, "'Stephen Kent'" <[e-mail]>, [e-mail]
In-Reply-To: <[e-mail] .gte.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed

At 02:43 PM 7/18/00 -0400, Heimberg, Jim wrote:
>Are we moving in the direction of the Twilight Zone.  If you could fool the
>CA with a false driver's licence, why don't you just get the false ID, forge
>his checks, and raid his bank account?  The signature is a mark that is
>either accepted as being valid or is forged.  There is no difference with
>the digital signature.  Your digital signature is not any better or any
>worse than your pen-and-ink signature.  You decide when to use it.  If you
>receive a FEDEX, you sign for receipt, right?  If you receive an e-mail,
>what is different than signing to signify receipt?  That signature does not
>do the same thing as if you were signing the $10M contract contained in the
>FEDEX package or the one contained in the e-mail.  Where is the issue?
>Jim

The issues are really:

1.  How hard is it to obtain a false digital certification of a key,
     compared to other false credentials?

     If it is easy, we are indeed in the "Twilight Zone", and building
     rock-solid castles on a quick-sand foundation.

2.  If it is "variably hard" to obtain false digital credentials,
     depending upon chosen CA and "level" of certificate purchased,
     then one cannot "ignore the certificate" when assessing the
     "binding-ness" of a signature to a (presumably) intended act.

3.  If it is "variably hard" to assert the key is safely stored,
     or was expected to be safely applied by the "signing-device"
     then this simple result of "verification mathematics" buys you
     little with respect to assertions about the intent of a given
     signature, or the strength with which it was "intentionally
     bound" to a signed object.  More so, if one wants to hold all
     certificates as "equally strong" with respect to usage.

___tony___


Tony Bartoletti 925-422-3881 <[e-mail]>
Information Operations, Warfare and Assurance Center
Lawrence Livermore National Laboratory
Livermore, CA 94551-9900



Received: from Newman.GSC.GTE.Com ([e-mail] [192.160.62.66]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id LAA04426 for <[e-mail]>; Tue, 18 Jul 2000 11:45:53 -0700 (PDT)
Received: from gscex01.gsc.gte.com ("port 2992"@gscex01.ndhm.gsc.gte.com [155.95.162.170]) by Newman.GSC.GTE.Com (PMDF V5.2-30 #38015) with ESMTP id <[e-mail]> for [e-mail]; Tue, 18 Jul 2000 14:48:02 -0400 (EDT)
Received: by GSCEX01.gsc.gte.com with Internet Mail Service (5.5.2448.0) id <3L3TJ2SH>; Tue, 18 Jul 2000 14:43:52 -0400
Content-return: allowed
Date: Tue, 18 Jul 2000 14:43:51 -0400
From: "Heimberg, Jim" <[e-mail]>
Subject: RE: Signing what you don't understand
To: "'Tony Bartoletti'" <[e-mail]>, Mitchell Arnone <[e-mail]>, "Golkin Ken (CAP CMC)" <[e-mail]>
Cc: "'Adrian McCullagh'" <[e-mail]>, "'Stephen Kent'" <[e-mail]>, [e-mail]
Message-id: <[e-mail]>
MIME-version: 1.0
X-Mailer: Internet Mail Service (5.5.2448.0)
Content-type: text/plain;	charset="iso-8859-1"

Are we moving in the direction of the Twilight Zone.  If you could fool the
CA with a false driver's licence, why don't you just get the false ID, forge
his checks, and raid his bank account?  The signature is a mark that is
either accepted as being valid or is forged.  There is no difference with
the digital signature.  Your digital signature is not any better or any
worse than your pen-and-ink signature.  You decide when to use it.  If you
receive a FEDEX, you sign for receipt, right?  If you receive an e-mail,
what is different than signing to signify receipt?  That signature does not
do the same thing as if you were signing the $10M contract contained in the
FEDEX package or the one contained in the e-mail.  Where is the issue?
Jim

-----Original Message-----
From: Tony Bartoletti [mailto:[e-mail]]
Sent: Tuesday, July 18, 2000 2:00 PM
To: Mitchell Arnone; Golkin Ken (CAP CMC)
Cc: 'Adrian McCullagh'; 'Stephen Kent'; [e-mail]
Subject: Re: Signing what you don't understand


Ah, that life were really so simple ... :)

At 12:00 PM 7/18/00 -0400, Mitchell Arnone wrote:
>I have a hard time imagining use of digital signatures for anything
>that does not require Non-repudiation.

On one level, I can agree with this statement.  One wants to say
"What other purpose for applying an (assumably unforgeable) mark
other than to have it be unforgeable?"  And as I have argued long
previously, the "math of it" gets you this much, regardless of the
setting of key-usage bits or other implied intent.

But that is really not saying very much.

What (other than certification, to start with) attaches this
disembodied signing-key to an "actor"?

>As for authentication, digital signatures (which requires access to the 
>private key, Not a Digital Certificate) demonstrates proof positive that 
>"a person is who they say they are" and provides a means by which 
>unquestionable proof can be established that the owner of a given 
>certificate responded to a challenge and subsequently gained access to 
>some secure resource.

This assertion WAY overstates the strength of the situation:

If I can fool a CA (with fake driver's license, etc) into certifying
my key-pair as "belongs to Mitchell Arnone of b2bcommunications.com",
does my use of this key provide "proof positive" that I am who I say
I am?  Or equivalently, proof that the real Mitchell took action?

And would it matter that, when invoking a signature, that I must use my
personal passcode to unlock MY (presumably, your) signature key?

To clear one's head, begin with the understanding that the application of
(and verification of) a (mechanical) digital signature serves (effectively)
as proof positive of three central facts:

a.  The "wielder of the signature" (person or process) indeed possessed
     the secret-key corresponding to the public key used in verification.

b.  Some "process" had access to both the secret-key, and the document
     (or the hash of the document.)

c.  The document (or hash) verified is exactly the document (or hash)
     that was mechanically signed. (No tampering took place.)

Now, we would like "wielder of the signature" to have a more substantial
form of identity.  We attempt to create this "sense of substance" by the
use of certificates.  But there are clearly wide variances by which this
certification may proceed, and from which assertions can flow.

>In my mind, authentication and digital signatures are inseparable and we
>would be better served to refrain from focusing on the granular
differences.

"Agree in Principle" ... however ...

Contrast "signing important legal contract" with "signing receipt of email".

The former should (likely) require an active and duly witnessed
"live person", and a trusted display device that guarantees that
what is signed is precisely no more and no less than what is being
displayed, and further displays the particulars of the key-ownership
certificate, to help ensure that the "witnesses" are not being fooled
into attesting to my signing with your key.  Expensive technology.

The latter is a useful application of "digital signature mechanics"
that I might employ to let people know that "their mail was delivered
to the right address".  I might configure my mailer to create such
return receipts automatically, even while I am away.  In such a case,
is it True or False that the application is "signing without the
knowledge of the owner of the certificate?"  Depends upon perspective.
Was there a sufficient "challenge"?  Was it enough to effect that
challenge (only) during my act of configuring my email-robot to
employ the key?  Should the act of configuring my email-robot require
witnesses and the expensive secured display device described above?

If such strong measures are unneeded for this application, how
can one ensure the code or process is not subverted to effect
signatures for contracts (or arguably so, to repudiate a former
signature made with a stronger technology.)

Alternatively, do you argue that "email return receipts" should
remain "unsigned" by a technology so "strong"?

___tony___

>Mitchell Arnone
>PKI Engineer
>
>"Golkin, Ken (CAP, CMC)" wrote:
>>
>>
>>This discussion seems to be confusing two different uses for certificates
>>1) Authentication (I am who I say I am)
>>2) Signature (I signed a legally binding document)
>>
>>In the first case I showed my company issue picture ID (certificate) to 
>>the guard at the door and he let me in the building this morning.
>>
>>In the second case I stopped at the hardware store on the way home last 
>>night to buy a box of nails and some other things.  At the check out I 
>>showed them my charge card (certificate) then signed the sales 
>>slip.  Which legally obligated me to pay $24.86.
>>
>>The certificate policy (defined as: A named set of rules that indicates
the
>>        applicability of a public key certificate to a particular
>>        community or class of application with common security
>>        requirements. For example, a particular certificate policy might
>>        indicate applicability of a type of public key certificate to the
>>        authentication of electronic data interchange transactions for
>>        the trading of goods within a given price range.) in X.509 PKiX 
>> roadmap makes it clear that all certificates are not created equal.
>>
>>The Canadian Government and United States Government PKI initiatives have 
>>defined multiple levels of assurance, and as far as I can tell, most 
>>business applications of PKI are following the government lead.
>>
>>If I'm loaning someone $250,000 to buy a house I obviously need a greater 
>>level of assurance that they are who they are (and their bank is who they 
>>say they are) then was required by the checkout at the hardware store or 
>>the guard at the entrance.
>>
>>-----Original Message-----
>>From: Adrian McCullagh 
>>[<mailto:[e-mail]>mailto:[e-mail]

>>ns.com.au]
>>Sent: Monday, July 17, 2000 11:08 PM
>>To: 'Stephen Kent'
>>Cc: [e-mail]
>>Subject: RE: Signing what you don't understand
>>
>>Stephen,
>>
>>I do not want to get into an argument with you.  Yes I am a lawyer but I
>>also have a technical background so your suggestion otherwise, I thought
was
>>not moving the discussion forward. Admittedly, I do not possess the
>>technical knowledge that you have.
>>
>>Your example is well put but is this really a digital signature or is it a
>>set of bits (a mark) that has been affixed using the same technology known
>>as digital signature technology.
>>
>>You mention the difference between the 2 intents.  I would be surprised,
if
>>anyone (other than the technically minded) even knows that a challenge
>>response is even being "signed".  There is no intent at all in this case.
It
>>is the technology as designed that is effecting the response to the
>>challenge.  I am surprised that "you" sign authentication challenges, just
>>for authentication purposes.  Is it really a signature?  Are you really
>>signing the authentication challenge or is it the software on your machine
>>effecting the response to the challenge?
>>
>>To me this is not a signature.  It may use digital signature technology
but
>>it is not a signature.  This is probably the problem.  It is the use of
the
>>word "signature" which is a technical term but has been used by the PKI
>>community to cover a myriad of uses.  Some uses of the term by the PKI
>>community are confusing.
>>
>>I also do not agree with your position that the NR bit can signal any
intent
>>either way.  With respect, intent is ascertained at the time of signing.
A
>>certificate has nothing what so ever to do with signing.  Its primary
>>purpose is to identify a public key that corresponds to a private key that
>>may be held by some previously identified person or entity.  The public
key
>>is used to verify a digital signature that has supposedly been created
using
>>the corresponding private key.  That is it as far as I understand it
unless
>>there is some other primary purpose that I do not know.  I do not see the
>>relationship between digitally signing a document and the contents of a
>>certificate. Verification of the signature at some later time is a
different
>>issue which may involve the use of a certificate but this may not be so.
>>
>>Adrian McCullagh
>>Director of Electronic Commerce         Tel: [phone]
>>Gadens Lawyers                                  Fax: [phone]
>>level 39
>>Central Plaza 1
>>345 Queen Street
>>Brisbane Australia 4000
>>
>>Ph. D. Candidate
>>Thesis "The Incorporation of Trust Strategies in Digital Signature
>>Regimes for Elec. Comm."
>>Information Security Research Centre
>>Queensland University of Technology
>>
>>
>>-----Original Message-----
>>From: Stephen Kent [<mailto:[e-mail]>mailto:[e-mail]]
>>Sent: Tuesday, July 18, 2000 10:00 AM
>>To: Adrian McCullagh
>>Cc: [e-mail]
>>Subject: RE: Signing what you don't understand
>>
>>At 12:50 PM +1000 7/15/00, Adrian McCullagh wrote:
>> >Stephen
>> >
>> >I really do not understand your response.  Why would anyone sign a 
>> document
>> >that they do not understand.  It does not make sense.  If I sent you a
>> >document written in Chinese and assume you can not read Chinese and at
the
>> >same time I said just sign this - Why would you sign it.  Now if you
>>trusted
>> >me then you may sign it based upon the information about the document
that
>>I
>> >tell you.  A classic case for Non-est-factum.  But all the cases that I
>>have
>> >read clearly rely upon some information provided by an Alleged trusted
>>third
>> >party.  Usually some relative.  So without some external information
being
>> >provided by a third party it is not as far as I can determine possible
to
>> >rely upon non est factum.
>>
>>Because we sign authentication challenges, just for authentication
>>purposes, but not for NR purposes, it is prudent to distinguish
>>between the two intents.  Your comments seem to ignore this use of
>>digital signature technology. One way of signalling intent is via the
>>NR bit. Although it has been argued that having this bit set to True
>>does not necessarily signal intent to sign for NR purposes, having it
>>set to False certainly signals an intent to not be bound re NR.
>>
>>(Your use of Latin and your e-mail "signature" suggests a legal, but
>>perhaps not a technical background. We've also decided, after much
>>debate, that PKIX deals with technical aspects of NR, not legal
>>details that may vary based upon jurisdiction.)
>>
>> >Also what does a "bit" in a certificate got to do with non-repudiation.
>>The
>> >commercial world and the law does not in my opinion support this
position
>>of
>> >yours.  You appear to be on a path to re-engineering the entire
commercial
>> >legal fabric and as such I with the greatest respect I do not  believe 
>> that
>> >society and the law will buy into it.  With out the commercial
involvement
>> >PKI will not survive.
>>
>>The position is not just mine.  Sorry of you don't understand, or
>>merely don't agree with the use of the NR bit, or its name, but we
>>had this debate a while ago and we're not having it again.
>>
>> >
>> >I do not understand how - "what you are proposing" - will work in 
>> practical
>> >terms.
>>
>>I'm not "proposing," but I am citing existing Internet and ITU
>>standards and the applicability to the question at hand.
>>
>>Steve

Tony Bartoletti 925-422-3881 <[e-mail]>
Information Operations, Warfare and Assurance Center
Lawrence Livermore National Laboratory
Livermore, CA 94551-9900


Received: from alemail1.firewall.lucent.com (alemail1.lucent.com [192.11.221.161]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id LAA04352 for <[e-mail]>; Tue, 18 Jul 2000 11:44:13 -0700 (PDT)
Received: from alemail1.firewall.lucent.com (localhost [127.0.0.1]) by alemail1.firewall.lucent.com (Pro-8.9.3/8.9.3) with ESMTP id OAA07239 for <[e-mail]>; Tue, 18 Jul 2000 14:46:40 -0400 (EDT)
Received: from anuxc.mv.lucent.com (h135-13-160-12.lucent.com [135.13.160.12]) by alemail1.firewall.lucent.com (Pro-8.9.3/8.9.3) with ESMTP id OAA07185; Tue, 18 Jul 2000 14:46:38 -0400 (EDT)
Received: from irene by anuxc.mv.lucent.com (8.8.8+Sun/EMS-1.5 sol2) id OAA02787; Tue, 18 Jul 2000 14:44:02 -0400 (EDT)
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1 
Date: Tue, 18 Jul 2000 14:46:54 -0400
To: "Simon McMahon" <[e-mail]>
From: Irene Gassko <[e-mail]>
Subject: Re: Current signature formats insufficient
Cc: <[e-mail]>, <[e-mail]>
In-Reply-To: <013901bfeba8$419218f0$[e-mail]>
References: <000901bfeb64$38642f50$0201010a@intergalactic>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"

Hello,

Blind signatures provide another viewpoint. Here a signer does not
know what it is signing but the key used indicates the value of a
monetary unit. 

If keys have very limited usages it will be more difficult to misuse
them. Even the most technically unsophisticated consumer will be
suspicious if a librarian will ask for his credit card instead of his
library card. On the other hand, a contract to sell one's home
signed with an e-mail signature key instead of "high value transaction"
signature key will be much easier to repudiate if those keys are
explicitly defined. I think all of this is achievable with currently available
PKIX tools.

Cheers,

Irene


At 12:23 PM 07/12/2000 +1000, Simon McMahon wrote:
>Hi all,
>
>My 2c worth.
>
>You should look to the analog-signature as an analogy. It's the content of
>what you sign that includes the terms and therefore the extent to which the
>signer is bound. Carelessly given signatures should be legally binding,
>otherwise ignorance will be used as a defense for repudiation, and only
>fraudulently or forcefully obtained signatues should be able to be
>sucessfully repudiated by recourse to the law and courts.
>
>You never modify the nature of a handwritten signature to indicate your
>intention, e.g different coloured pens or pressing harder, writing bigger /
>smaller than normal makes no difference if the handwritten signature can be
>shown to be yours or you say it is yours. Its what you sign that binds you.
>Having a signature witnessed by a competent authority (a JP) is the only way
>I know of to boost non-repudiation of a standard signature. A non-witnessed
>signature is presumably easier, but by no means trival to repudiate.
>
>Just because its easier (relatively) to mess with digital signature formats
>than handwritten ones dosen't mean that you should since laws for
>handwritten signatures will migrate easier to digital ones if the analogy is
>kept closer.
>
>I dont agree with either digital alternative for indicating the signers
>intention in a legally binding way, i.e. boosting or removing
>non-repudiation. Firstly that the certificate's usage attributes should
>dictate anything about the private key since they may not both be stored on
>the same device and the association is not trivial to check, or, secondly,
>that the signature format should indicate my intention when I signed. All of
>my intentions should be indicated in the content of what I signed.
>
>Any "intention" indicator added to the signature encoding could just as
>easily be encoded into the content before signing. It is effectively
>modifying the contract before signing it. For "ephemeral" signatures you
>effectively stamp the content "void", then sign it.
>
>Frank's suggestions :
>> In the case of an authentication protocol, you could include an OBJECT
>> IDENTIFIER or string in the data to be signed to constrain the use of the
>> signature. For example:
>>
>> AuthenticationInfo ::= SEQUENCE {
>>    disclaimer UTF8String,
>>    nonce      OCTET STRING
>> }
>>
>> Another technique would be to use PKCS #7 authenticated attributes.
>
>These look like good mechanisms for this purpose and use current practise
>and encodings. No need for yet-another-encoding :-).
>
>I dont believe that private keys for non-repudiation signatures should ever
>be used for ephemeral signatures. It just seems like a dangerous and
>unecessary overloading of an important object - the private key. The private
>key should be stored with its own usage attributes to avoid looking up the
>certificate to see if it is such a key. The device doing the signing should
>do whatever the law requires it to do with these keys, regarding
>authentication and secure containment, to make non-repudiation enforcable.
>
>Simon McMahon
>ERACOM Pty. Ltd.
>

----------------------------------------------------------------------------
-------------------------------------------------------
Irene Gassko			 Bell Laboratories		http://www.lucent.com
Lucent Technologies		Secure Technologies Dept.
1600 Osgood Street			 phone:	[phone]
Room 30-2-A31			 e-mail: 	[e-mail]
N. Andover, MA 01845		 fax: 	[phone]


Received: from poptop.llnl.gov (poptop.llnl.gov [128.115.41.70]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id KAA03114 for <[e-mail]>; Tue, 18 Jul 2000 10:55:40 -0700 (PDT)
Received: from catalyst (catalyst.llnl.gov [128.115.222.68]) by poptop.llnl.gov (8.8.8/LLNL-3.0.2/pop.llnl.gov-5.1) with ESMTP id KAA19252; Tue, 18 Jul 2000 10:52:29 -0700 (PDT)
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.2 
Date: Tue, 18 Jul 2000 10:59:48 -0700
To: "Mitchell Arnone" <[e-mail]>, "Golkin Ken (CAP CMC)" <[e-mail]>
From: Tony Bartoletti <[e-mail]>
Subject: Re: Signing what you don't understand
Cc: "'Adrian McCullagh'" <[e-mail]>, "'Stephen Kent'" <[e-mail]>, [e-mail]
In-Reply-To: <[e-mail]>
References: <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed

Ah, that life were really so simple ... :)

At 12:00 PM 7/18/00 -0400, Mitchell Arnone wrote:
>I have a hard time imagining use of digital signatures for anything
>that does not require Non-repudiation.

On one level, I can agree with this statement.  One wants to say
"What other purpose for applying an (assumably unforgeable) mark
other than to have it be unforgeable?"  And as I have argued long
previously, the "math of it" gets you this much, regardless of the
setting of key-usage bits or other implied intent.

But that is really not saying very much.

What (other than certification, to start with) attaches this
disembodied signing-key to an "actor"?

>As for authentication, digital signatures (which requires access to the 
>private key, Not a Digital Certificate) demonstrates proof positive that 
>"a person is who they say they are" and provides a means by which 
>unquestionable proof can be established that the owner of a given 
>certificate responded to a challenge and subsequently gained access to 
>some secure resource.

This assertion WAY overstates the strength of the situation:

If I can fool a CA (with fake driver's license, etc) into certifying
my key-pair as "belongs to Mitchell Arnone of b2bcommunications.com",
does my use of this key provide "proof positive" that I am who I say
I am?  Or equivalently, proof that the real Mitchell took action?

And would it matter that, when invoking a signature, that I must use my
personal passcode to unlock MY (presumably, your) signature key?

To clear one's head, begin with the understanding that the application of
(and verification of) a (mechanical) digital signature serves (effectively)
as proof positive of three central facts:

a.  The "wielder of the signature" (person or process) indeed possessed
     the secret-key corresponding to the public key used in verification.

b.  Some "process" had access to both the secret-key, and the document
     (or the hash of the document.)

c.  The document (or hash) verified is exactly the document (or hash)
     that was mechanically signed. (No tampering took place.)

Now, we would like "wielder of the signature" to have a more substantial
form of identity.  We attempt to create this "sense of substance" by the
use of certificates.  But there are clearly wide variances by which this
certification may proceed, and from which assertions can flow.

>In my mind, authentication and digital signatures are inseparable and we
>would be better served to refrain from focusing on the granular differences.

"Agree in Principle" ... however ...

Contrast "signing important legal contract" with "signing receipt of email".

The former should (likely) require an active and duly witnessed
"live person", and a trusted display device that guarantees that
what is signed is precisely no more and no less than what is being
displayed, and further displays the particulars of the key-ownership
certificate, to help ensure that the "witnesses" are not being fooled
into attesting to my signing with your key.  Expensive technology.

The latter is a useful application of "digital signature mechanics"
that I might employ to let people know that "their mail was delivered
to the right address".  I might configure my mailer to create such
return receipts automatically, even while I am away.  In such a case,
is it True or False that the application is "signing without the
knowledge of the owner of the certificate?"  Depends upon perspective.
Was there a sufficient "challenge"?  Was it enough to effect that
challenge (only) during my act of configuring my email-robot to
employ the key?  Should the act of configuring my email-robot require
witnesses and the expensive secured display device described above?

If such strong measures are unneeded for this application, how
can one ensure the code or process is not subverted to effect
signatures for contracts (or arguably so, to repudiate a former
signature made with a stronger technology.)

Alternatively, do you argue that "email return receipts" should
remain "unsigned" by a technology so "strong"?

___tony___

>Mitchell Arnone
>PKI Engineer
>
>"Golkin, Ken (CAP, CMC)" wrote:
>>
>>
>>This discussion seems to be confusing two different uses for certificates
>>1) Authentication (I am who I say I am)
>>2) Signature (I signed a legally binding document)
>>
>>In the first case I showed my company issue picture ID (certificate) to 
>>the guard at the door and he let me in the building this morning.
>>
>>In the second case I stopped at the hardware store on the way home last 
>>night to buy a box of nails and some other things.  At the check out I 
>>showed them my charge card (certificate) then signed the sales 
>>slip.  Which legally obligated me to pay $24.86.
>>
>>The certificate policy (defined as: A named set of rules that indicates the
>>        applicability of a public key certificate to a particular
>>        community or class of application with common security
>>        requirements. For example, a particular certificate policy might
>>        indicate applicability of a type of public key certificate to the
>>        authentication of electronic data interchange transactions for
>>        the trading of goods within a given price range.) in X.509 PKiX 
>> roadmap makes it clear that all certificates are not created equal.
>>
>>The Canadian Government and United States Government PKI initiatives have 
>>defined multiple levels of assurance, and as far as I can tell, most 
>>business applications of PKI are following the government lead.
>>
>>If I'm loaning someone $250,000 to buy a house I obviously need a greater 
>>level of assurance that they are who they are (and their bank is who they 
>>say they are) then was required by the checkout at the hardware store or 
>>the guard at the entrance.
>>
>>-----Original Message-----
>>From: Adrian McCullagh 
>>[<mailto:[e-mail]>mailto:[e-mail] 
>>ns.com.au]
>>Sent: Monday, July 17, 2000 11:08 PM
>>To: 'Stephen Kent'
>>Cc: [e-mail]
>>Subject: RE: Signing what you don't understand
>>
>>Stephen,
>>
>>I do not want to get into an argument with you.  Yes I am a lawyer but I
>>also have a technical background so your suggestion otherwise, I thought was
>>not moving the discussion forward. Admittedly, I do not possess the
>>technical knowledge that you have.
>>
>>Your example is well put but is this really a digital signature or is it a
>>set of bits (a mark) that has been affixed using the same technology known
>>as digital signature technology.
>>
>>You mention the difference between the 2 intents.  I would be surprised, if
>>anyone (other than the technically minded) even knows that a challenge
>>response is even being "signed".  There is no intent at all in this case. It
>>is the technology as designed that is effecting the response to the
>>challenge.  I am surprised that "you" sign authentication challenges, just
>>for authentication purposes.  Is it really a signature?  Are you really
>>signing the authentication challenge or is it the software on your machine
>>effecting the response to the challenge?
>>
>>To me this is not a signature.  It may use digital signature technology but
>>it is not a signature.  This is probably the problem.  It is the use of the
>>word "signature" which is a technical term but has been used by the PKI
>>community to cover a myriad of uses.  Some uses of the term by the PKI
>>community are confusing.
>>
>>I also do not agree with your position that the NR bit can signal any intent
>>either way.  With respect, intent is ascertained at the time of signing.  A
>>certificate has nothing what so ever to do with signing.  Its primary
>>purpose is to identify a public key that corresponds to a private key that
>>may be held by some previously identified person or entity.  The public key
>>is used to verify a digital signature that has supposedly been created using
>>the corresponding private key.  That is it as far as I understand it unless
>>there is some other primary purpose that I do not know.  I do not see the
>>relationship between digitally signing a document and the contents of a
>>certificate. Verification of the signature at some later time is a different
>>issue which may involve the use of a certificate but this may not be so.
>>
>>Adrian McCullagh
>>Director of Electronic Commerce         Tel: [phone]
>>Gadens Lawyers                                  Fax: [phone]
>>level 39
>>Central Plaza 1
>>345 Queen Street
>>Brisbane Australia 4000
>>
>>Ph. D. Candidate
>>Thesis "The Incorporation of Trust Strategies in Digital Signature
>>Regimes for Elec. Comm."
>>Information Security Research Centre
>>Queensland University of Technology
>>
>>
>>-----Original Message-----
>>From: Stephen Kent [<mailto:[e-mail]>mailto:[e-mail]]
>>Sent: Tuesday, July 18, 2000 10:00 AM
>>To: Adrian McCullagh
>>Cc: [e-mail]
>>Subject: RE: Signing what you don't understand
>>
>>At 12:50 PM +1000 7/15/00, Adrian McCullagh wrote:
>> >Stephen
>> >
>> >I really do not understand your response.  Why would anyone sign a 
>> document
>> >that they do not understand.  It does not make sense.  If I sent you a
>> >document written in Chinese and assume you can not read Chinese and at the
>> >same time I said just sign this - Why would you sign it.  Now if you
>>trusted
>> >me then you may sign it based upon the information about the document that
>>I
>> >tell you.  A classic case for Non-est-factum.  But all the cases that I
>>have
>> >read clearly rely upon some information provided by an Alleged trusted
>>third
>> >party.  Usually some relative.  So without some external information being
>> >provided by a third party it is not as far as I can determine possible to
>> >rely upon non est factum.
>>
>>Because we sign authentication challenges, just for authentication
>>purposes, but not for NR purposes, it is prudent to distinguish
>>between the two intents.  Your comments seem to ignore this use of
>>digital signature technology. One way of signalling intent is via the
>>NR bit. Although it has been argued that having this bit set to True
>>does not necessarily signal intent to sign for NR purposes, having it
>>set to False certainly signals an intent to not be bound re NR.
>>
>>(Your use of Latin and your e-mail "signature" suggests a legal, but
>>perhaps not a technical background. We've also decided, after much
>>debate, that PKIX deals with technical aspects of NR, not legal
>>details that may vary based upon jurisdiction.)
>>
>> >Also what does a "bit" in a certificate got to do with non-repudiation.
>>The
>> >commercial world and the law does not in my opinion support this position
>>of
>> >yours.  You appear to be on a path to re-engineering the entire commercial
>> >legal fabric and as such I with the greatest respect I do not  believe 
>> that
>> >society and the law will buy into it.  With out the commercial involvement
>> >PKI will not survive.
>>
>>The position is not just mine.  Sorry of you don't understand, or
>>merely don't agree with the use of the NR bit, or its name, but we
>>had this debate a while ago and we're not having it again.
>>
>> >
>> >I do not understand how - "what you are proposing" - will work in 
>> practical
>> >terms.
>>
>>I'm not "proposing," but I am citing existing Internet and ITU
>>standards and the applicability to the question at hand.
>>
>>Steve

Tony Bartoletti 925-422-3881 <[e-mail]>
Information Operations, Warfare and Assurance Center
Lawrence Livermore National Laboratory
Livermore, CA 94551-9900



Received: from netscape.com (h-205-217-237-46.netscape.com [205.217.237.46]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id JAA01979 for <[e-mail]>; Tue, 18 Jul 2000 09:55:41 -0700 (PDT)
Received: from judge.mcom.com (judge.mcom.com [205.217.237.53]) by netscape.com (8.10.0/8.10.0) with ESMTP id e6IGn2R08680 for <[e-mail]>; Tue, 18 Jul 2000 09:49:02 -0700 (PDT)
Received: from netscape.com ([205.217.229.47]) by judge.mcom.com (Netscape Messaging Server 4.15) with ESMTP id FXWKG001.R7Q; Tue, 18 Jul 2000 09:57:36 -0700 
Message-ID: <[e-mail]>
Date: Tue, 18 Jul 2000 09:57:33 -0700
From: [e-mail] (Terry Hayes)
X-Mailer: Mozilla 4.73 [en] (WinNT; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Ben Laurie <[e-mail]>
CC: Adrian McCullagh <[e-mail]>, "'Stephen Kent'" <[e-mail]>, [e-mail]
Subject: Re: Signing what you don't understand
References: <[e-mail]> <[e-mail]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Ben Laurie wrote:

> > I also do not agree with your position that the NR bit can signal any intent
> > either way.  With respect, intent is ascertained at the time of signing.  A
> > certificate has nothing what so ever to do with signing.  Its primary
> > purpose is to identify a public key that corresponds to a private key that
> > may be held by some previously identified person or entity.  The public key
> > is used to verify a digital signature that has supposedly been created using
> > the corresponding private key.  That is it as far as I understand it unless
> > there is some other primary purpose that I do not know.  I do not see the
> > relationship between digitally signing a document and the contents of a
> > certificate. Verification of the signature at some later time is a different
> > issue which may involve the use of a certificate but this may not be so.
>
> The relationship is that the creator of the certificate has stated what
> he intends the use of the signature to be. So, if the NR bit is not set,
> the owner of the private key has effectively stated that they do not
> expect the key to be used for NR!

This is the root of the problem (in my opinion).  While you say that the owner of
the private key has stated what they want the key to be used for, in fact the
"creator" of the certificate is the CA, not the end entity.  This level of
indirection is very troubling for some.  It allows additional certificates to be
created (possibly by untrustworthy CA) that cloud the meaning of the signature.

In my opinion, it is best to put a clear statement of the intended purpose of the
signature in the signature itself.  A simple policy (or application) OID included
in the authenticated attributes would do the trick.  Failing that, the fingerprint
of the certificate itself should be included (as is proposed elsewhere), and the
application should check that the proper extensions are included in that
certificate prior to signing.

Terry Hayes
[e-mail]



Received: from thalia.fm.intel.com (thalia.fm.intel.com [132.233.247.11]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id JAA01443 for <[e-mail]>; Tue, 18 Jul 2000 09:36:08 -0700 (PDT)
Received: from SMTP (fmsmsxvs01-1.fm.intel.com [132.233.42.201]) by thalia.fm.intel.com (8.9.1a+p1/8.9.1/d: relay.m4,v 1.30 2000/06/08 18:25:35 dmccart Exp $) with SMTP id QAA14983 for <[e-mail]>; Tue, 18 Jul 2000 16:39:30 GMT
Received: from fmsmsx27.FM.INTEL.COM ([132.233.48.27]) by 132.233.48.201 (Norton AntiVirus for Internet Email Gateways 1.0) ; Tue, 18 Jul 2000 16:38:34 0000 (GMT)
Received: by fmsmsx27.fm.intel.com with Internet Mail Service (5.5.2650.21) id <PAZXMMB0>; Tue, 18 Jul 2000 09:38:33 -0700
Message-ID: <[e-mail]>
From: "Eissa, Mohamed" <[e-mail]>
To: [e-mail]
Subject: Certificate Request Message Format (RFC 2511) 
Date: Tue, 18 Jul 2000 09:38:18 -0700
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain; charset="windows-1252"

Hi,

What is the relation/difference between Certificate Request Message Format
(RFC 2511) and the RSA PKCS standards?

Mohamed



Received: from mail-fwd.verio-web.com ([161.58.16.59]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id JAA01130 for <[e-mail]>; Tue, 18 Jul 2000 09:31:29 -0700 (PDT)
Received: from 161.58.117.181 (161.58.117.181) by mail11b.verio-web.com (RS ver 1.0.57s) with SMTP id 0612873; Tue, 18 Jul 2000 12:33:42 -0400 (EDT)
Sender: rsalz
Message-ID: <[e-mail]>
Date: Tue, 18 Jul 2000 12:32:53 -0400
From: Rich Salz <[e-mail]>
X-Mailer: Mozilla 4.72 [en] (X11; U; Linux 2.2.14-5.0 i686)
X-Accept-Language: en
MIME-Version: 1.0
To: Ambarish Malpani <[e-mail]>
CC: [e-mail], [e-mail]
Subject: Re: Need for an XML based cert check protocol with RPP capability	.
References: <[e-mail]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
X-Loop-Detect: 1

If the protocol says "you can ask this server" then code must be written
to put "this server" into the request packet. If the rules say "ask the
bank" then you must open your connect to "the bank."  Either way, there
is no savings.  Please post a worked example.

> By having a merchant application
> just ask the bank whether a certificate can be used for a particular
> purpose, you significantly reduce the deployment problems
> somebody like Identrus will have with new certificate types and
> different policy rules.

Exactly.  Just ask the bank.

It's a business/programming rule, not a protocol issue.
	/r$


Received: from freeby.ben.algroup.co.uk (sockittome.aldigital.co.uk [194.128.162.252]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id JAA00620 for <[e-mail]>; Tue, 18 Jul 2000 09:24:42 -0700 (PDT)
Received: from algroup.co.uk (naughty.ben.algroup.co.uk [193.133.15.107]) by freeby.ben.algroup.co.uk (8.6.12/8.6.12) with ESMTP id RAA01172; Tue, 18 Jul 2000 17:36:54 +0100
Message-ID: <[e-mail]>
Date: Tue, 18 Jul 2000 17:22:34 +0100
From: Ben Laurie <[e-mail]>
Organization: A.L. Group plc
X-Mailer: Mozilla 4.7 [en] (WinNT; I)
MIME-Version: 1.0
To: Adrian McCullagh <[e-mail]>
CC: "'Stephen Kent'" <[e-mail]>, [e-mail]
Subject: Re: Signing what you don't understand
References: <[e-mail]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Adrian McCullagh wrote:
> 
> Stephen,
> 
> I do not want to get into an argument with you.  Yes I am a lawyer but I
> also have a technical background so your suggestion otherwise, I thought was
> not moving the discussion forward. Admittedly, I do not possess the
> technical knowledge that you have.
> 
> Your example is well put but is this really a digital signature or is it a
> set of bits (a mark) that has been affixed using the same technology known
> as digital signature technology.
> 
> You mention the difference between the 2 intents.  I would be surprised, if
> anyone (other than the technically minded) even knows that a challenge
> response is even being "signed".  There is no intent at all in this case. It
> is the technology as designed that is effecting the response to the
> challenge.  I am surprised that "you" sign authentication challenges, just
> for authentication purposes.  Is it really a signature?  Are you really
> signing the authentication challenge or is it the software on your machine
> effecting the response to the challenge?
> 
> To me this is not a signature.  It may use digital signature technology but
> it is not a signature.  This is probably the problem.  It is the use of the
> word "signature" which is a technical term but has been used by the PKI
> community to cover a myriad of uses.  Some uses of the term by the PKI
> community are confusing.

If it is not a signature to you, then surely no digital signature is a
signature to you, since they are _always_ done by the machine.

As far as I'm concerned (and, I suspect, most other people on this
list), a digital signature is a technical term that describes a way to
bind some data to a (private) key.

You can then assign some significance to the intent of that "signature",
or, at least, people want to. A real issue with that assignment is that
the signature has always been done by software on behalf of the user.
Demonstrating that the user had intent is troublesome.

> I also do not agree with your position that the NR bit can signal any intent
> either way.  With respect, intent is ascertained at the time of signing.  A
> certificate has nothing what so ever to do with signing.  Its primary
> purpose is to identify a public key that corresponds to a private key that
> may be held by some previously identified person or entity.  The public key
> is used to verify a digital signature that has supposedly been created using
> the corresponding private key.  That is it as far as I understand it unless
> there is some other primary purpose that I do not know.  I do not see the
> relationship between digitally signing a document and the contents of a
> certificate. Verification of the signature at some later time is a different
> issue which may involve the use of a certificate but this may not be so.

The relationship is that the creator of the certificate has stated what
he intends the use of the signature to be. So, if the NR bit is not set,
the owner of the private key has effectively stated that they do not
expect the key to be used for NR!

Cheers,

Ben.

--
http://www.apache-ssl.org/ben.html

Coming to ApacheCon Europe 2000? http://apachecon.com/


Received: from ext-mail.valicert.com (ns1.valicert.com [63.65.221.10]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id JAA00577 for <[e-mail]>; Tue, 18 Jul 2000 09:24:33 -0700 (PDT)
Received: from CONVERSION-DAEMON.ext-mail.valicert.com by ext-mail.valicert.com (PMDF V6.0-24 #46243) id <[e-mail]> for [e-mail]; Tue, 18 Jul 2000 09:26:59 -0700 (PDT)
Received: from seine.valicert.com ([192.168.2.23]) by ext-mail.valicert.com (PMDF V6.0-24 #46243) with ESMTP id <[e-mail]>; Tue, 18 Jul 2000 09:26:59 -0700 (PDT)
Received: by seine.valicert.com with Internet Mail Service (5.5.2650.21) id <360062YV>; Tue, 18 Jul 2000 09:18:56 -0700
Content-return: allowed
Date: Tue, 18 Jul 2000 09:18:54 -0700
From: Ambarish Malpani <[e-mail]>
Subject: RE: Need for an XML based cert check protocol with RPP capability	.
To: "'[e-mail]'" <[e-mail]>, [e-mail]
Cc: [e-mail]
Message-id: <[e-mail]>
MIME-version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-type: text/plain; charset=iso-8859-1

Hi Rich,
    Let me try and provide part of the justification:

> If your rules say "ask the bank" then there is no need to encode
> this in a protocol.  Encode it in your code. :)
>

Identrus is trying to provide an infrastructure that will be
used across a whole slew of products - e-mail, web, databases,
etc. Sure, they could come up with their own "standards" for
how validation would be done. Then, they would have to convince
all relevant vendors to implement that standard. Tomorrow, if there
is another similar body that comes up with their own "standard",
they will need to do the same thing and software vendors will
end up choosing which of the n different standards they should
follow.

The whole point of trying to use work that comes out of the IETF
is that you avoid this segmentation of how different groups
choose to do the same thing.


> Second, Identrus is a closed PKI without cross-certification.
> Identrus certs are only to be used among Identrus participants who
> agree to follow Identrus rules.  That's a linch-pin for making the
> whole risk-management aspect fly.
>

[My personal opinions here]: Identrus members are banks. These
banks will want to issue certs to their members that are useful
in both Identrus and non-Identrus environments. I would fully
expect, over time, that banks will use the same CA for both
purposes and have the CA certified by both Identrus and
non-Identrus roots. As long as they follow the Identrus rules,
it is unclear to me that Identrus would object to their doing so.
Some certs might also be issued with policies that map adequately
to Identrus policies.
So, over time, I would fully expect Identrus path processing to
become pretty complicated.

Thirdly: Identrus has a set of rules and types of certificates it
issues today. Again, I would expect these rules to evolve over
time with new and different types of certificates, issued for
different applications, under different policies. It would be
pretty hard to imagine client applications that were smart
enough to understand these new certificates types, when they
haven't even been defined today. By having a merchant application
just ask the bank whether a certificate can be used for a particular
purpose, you significantly reduce the deployment problems
somebody like Identrus will have with new certificate types and
different policy rules.

Hope this helps clarify the need for remote path processing and
SCVP.

Regards,
Ambarish


---------------------------------------------------------------------
Ambarish Malpani
Architect                                                650.567.5457
ValiCert, Inc.                                  [e-mail]
339 N. Bernardo Ave.                          http://www.valicert.com
Mountain View, CA 94043


> -----Original Message-----
> From: [e-mail] [mailto:[e-mail]]
> Sent: Monday, July 17, 2000 7:16 PM
> To: [e-mail]; [e-mail]
> Cc: [e-mail]
> Subject: RE: Need for an XML based cert check protocol with RPP
> capability .
> 
> 
> >Regardless of the structure of the PKI, path validation has 
> to be done
> >somewhere by someone the relying party trusts.  This is 
> normally done by the
> >relying party itself.  It can however be done by a party the 
> Relying part
> >trusts - Their bank for example.
> 
> In the general case, yes.
> 
> As I last understood it, the Identrus business rules said that the
> relying party always asks its bank.  And all the background 
> processing the
> bank did was completely hidden by the bank.  Bank A never exposed
> the *presence* of any other bank to its customers.
> 
> If your rules say "ask the bank" then there is no need to encode
> this in a protocol.  Encode it in your code. :)
> 
> Second, Identrus is a closed PKI without cross-certification.
> Identrus certs are only to be used among Identrus participants who
> agree to follow Identrus rules.  That's a linch-pin for making the
> whole risk-management aspect fly.
> 
> Have those rules changed?
> 
> If not, then I'm still stumped.  Could you provide a worked example?
> (This might be falling outside the general interest of the list...)
> 	/r$
> 


Received: from mailhost.b2bcommunications.com ([63.146.0.238]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id IAA29730 for <[e-mail]>; Tue, 18 Jul 2000 08:57:53 -0700 (PDT)
Received: from b2bcommunications.com ([192.168.10.52]) by mailhost.b2bcommunications.com (Netscape Messaging Server 4.15) with ESMTP id FXWHRV00.K2H; Tue, 18 Jul 2000 11:59:55 -0400 
Message-ID: <[e-mail]>
Date: Tue, 18 Jul 2000 12:00:14 -0400
From: "Mitchell Arnone" <[e-mail]>
X-Mailer: Mozilla 4.73 [en] (Win98; I)
X-Accept-Language: en
MIME-Version: 1.0
To: "Golkin Ken (CAP CMC)" <[e-mail]>
CC: "'Adrian McCullagh'" <[e-mail]>, "'Stephen Kent'" <[e-mail]>, [e-mail]
Subject: Re: Signing what you don't understand
References: <[e-mail]>
Content-Type: multipart/alternative; boundary="------------E6FC777E9720998E5E8F0539"

--------------E6FC777E9720998E5E8F0539
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

I am sure I don't have the background in PKI as most of those
contributing to this list but I would like to share some ideas:

I have a hard time imagining use of digital signatures for anything that
does not require Non-repudiation.   There are a number of NR issues
addressed with digital signatures including NR related to the creation
of an object as well as Non-repudiation of activities such as
delivery/receipt of messages, knowledge (proof that a message was read),
and much more.  Sometimes I feel that the term "signature" creates a
paradigm that can become difficult to transcend but I cannot come up
with a better descriptor of the intent behind the process.

As for authentication, digital signatures (which requires access to the
private key, Not a Digital Certificate) demonstrates proof positive that
"a person is who they say they are" and provides a means by which
unquestionable proof can be established that the owner of a given
certificate responded to a challenge and subsequently gained access to
some secure resource.  It it important to remember that a digital
certificate is public in nature and without the corresponding private
key, it is meaningless.  When a challenge is issued in the
authentication process, the act of signing that challenge must manifest
itself by requiring the user to submit his or her passcode to unlock the
private key.  If there is no challenge (i.e. the process of signing
without the knowledge of the owner of the certificate) then the
authentication process is completely invalidated.

The following is a quote from FIPS 196:

"To acceptably implement this standard, an implementation must meet the
following criteria:

1) Each entity in an authentication exchange must use a FIPS approved
digital signature algorithm to generate and/or verify digital
signatures;

2) Each entity must generate (pseudo)random numbers using a FIPS
approved (pseudo)random number generator;

3) Each entity acting as a claimant must be bound to a public/private
key pair; the private key should remain in the sole control of the
claimant who uses that key to sign a random challenge. The key binding
requires a unique authentication identifier for each claimant, so that a
verifier can distinguish between multiple claimants; and

4) One or both of the authentication protocols in this standard must be
implemented. For each protocol, steps and token fields marked as
[OPTIONAL] do not need to be implemented, except where indicated
otherwise. However, all other steps and token fields must be
implemented."

In my mind, authentication and digital signatures are inseparable and we
would be better served to refrain from focusing on the granular
differences.

Mitchell Arnone
PKI Engineer

"Golkin, Ken (CAP, CMC)" wrote:

>
>
> This discussion seems to be confusing two different uses for
> certificates
> 1) Authentication (I am who I say I am)
> 2) Signature (I signed a legally binding document)
>
> In the first case I showed my company issue picture ID (certificate)
> to the guard at the door and he let me in the building this morning.
>
> In the second case I stopped at the hardware store on the way home
> last night to buy a box of nails and some other things.  At the check
> out I showed them my charge card (certificate) then signed the sales
> slip.  Which legally obligated me to pay $24.86.
>
> The certificate policy (defined as: A named set of rules that
> indicates the
>        applicability of a public key certificate to a particular
>        community or class of application with common security
>        requirements. For example, a particular certificate policy
> might
>        indicate applicability of a type of public key certificate to
> the
>        authentication of electronic data interchange transactions for
>        the trading of goods within a given price range.) in X.509 PKiX
> roadmap makes it clear that all certificates are not created equal.
>
> The Canadian Government and United States Government PKI initiatives
> have defined multiple levels of assurance, and as far as I can tell,
> most business applications of PKI are following the government lead.
>
> If I'm loaning someone $250,000 to buy a house I obviously need a
> greater level of assurance that they are who they are (and their bank
> is who they say they are) then was required by the checkout at the
> hardware store or the guard at the entrance.
>
> -----Original Message-----
> From: Adrian McCullagh [mailto:[e-mail]]
> Sent: Monday, July 17, 2000 11:08 PM
> To: 'Stephen Kent'
> Cc: [e-mail]
> Subject: RE: Signing what you don't understand
>
> Stephen,
>
> I do not want to get into an argument with you.  Yes I am a lawyer but
> I
> also have a technical background so your suggestion otherwise, I
> thought was
> not moving the discussion forward. Admittedly, I do not possess the
> technical knowledge that you have.
>
> Your example is well put but is this really a digital signature or is
> it a
> set of bits (a mark) that has been affixed using the same technology
> known
> as digital signature technology.
>
> You mention the difference between the 2 intents.  I would be
> surprised, if
> anyone (other than the technically minded) even knows that a challenge
>
> response is even being "signed".  There is no intent at all in this
> case. It
> is the technology as designed that is effecting the response to the
> challenge.  I am surprised that "you" sign authentication challenges,
> just
> for authentication purposes.  Is it really a signature?  Are you
> really
> signing the authentication challenge or is it the software on your
> machine
> effecting the response to the challenge?
>
> To me this is not a signature.  It may use digital signature
> technology but
> it is not a signature.  This is probably the problem.  It is the use
> of the
> word "signature" which is a technical term but has been used by the
> PKI
> community to cover a myriad of uses.  Some uses of the term by the PKI
>
> community are confusing.
>
> I also do not agree with your position that the NR bit can signal any
> intent
> either way.  With respect, intent is ascertained at the time of
> signing.  A
> certificate has nothing what so ever to do with signing.  Its primary
> purpose is to identify a public key that corresponds to a private key
> that
> may be held by some previously identified person or entity.  The
> public key
> is used to verify a digital signature that has supposedly been created
> using
> the corresponding private key.  That is it as far as I understand it
> unless
> there is some other primary purpose that I do not know.  I do not see
> the
> relationship between digitally signing a document and the contents of
> a
> certificate. Verification of the signature at some later time is a
> different
> issue which may involve the use of a certificate but this may not be
> so.
>
> Adrian McCullagh
> Director of Electronic Commerce         Tel: [phone]
> Gadens Lawyers                                  Fax: [phone]
> level 39
> Central Plaza 1
> 345 Queen Street
> Brisbane Australia 4000
>
> Ph. D. Candidate
> Thesis "The Incorporation of Trust Strategies in Digital Signature
> Regimes for Elec. Comm."
> Information Security Research Centre
> Queensland University of Technology
>
>
> -----Original Message-----
> From: Stephen Kent [mailto:[e-mail]]
> Sent: Tuesday, July 18, 2000 10:00 AM
> To: Adrian McCullagh
> Cc: [e-mail]
> Subject: RE: Signing what you don't understand
>
> At 12:50 PM +1000 7/15/00, Adrian McCullagh wrote:
> >Stephen
> >
> >I really do not understand your response.  Why would anyone sign a
> document
> >that they do not understand.  It does not make sense.  If I sent you
> a
> >document written in Chinese and assume you can not read Chinese and
> at the
> >same time I said just sign this - Why would you sign it.  Now if you
> trusted
> >me then you may sign it based upon the information about the document
> that
> I
> >tell you.  A classic case for Non-est-factum.  But all the cases that
> I
> have
> >read clearly rely upon some information provided by an Alleged
> trusted
> third
> >party.  Usually some relative.  So without some external information
> being
> >provided by a third party it is not as far as I can determine
> possible to
> >rely upon non est factum.
>
> Because we sign authentication challenges, just for authentication
> purposes, but not for NR purposes, it is prudent to distinguish
> between the two intents.  Your comments seem to ignore this use of
> digital signature technology. One way of signalling intent is via the
> NR bit. Although it has been argued that having this bit set to True
> does not necessarily signal intent to sign for NR purposes, having it
> set to False certainly signals an intent to not be bound re NR.
>
> (Your use of Latin and your e-mail "signature" suggests a legal, but
> perhaps not a technical background. We've also decided, after much
> debate, that PKIX deals with technical aspects of NR, not legal
> details that may vary based upon jurisdiction.)
>
> >Also what does a "bit" in a certificate got to do with
> non-repudiation.
> The
> >commercial world and the law does not in my opinion support this
> position
> of
> >yours.  You appear to be on a path to re-engineering the entire
> commercial
> >legal fabric and as such I with the greatest respect I do not
> believe that
> >society and the law will buy into it.  With out the commercial
> involvement
> >PKI will not survive.
>
> The position is not just mine.  Sorry of you don't understand, or
> merely don't agree with the use of the NR bit, or its name, but we
> had this debate a while ago and we're not having it again.
>
> >
> >I do not understand how - "what you are proposing" - will work in
> practical
> >terms.
>
> I'm not "proposing," but I am citing existing Internet and ITU
> standards and the applicability to the question at hand.
>
> Steve

--------------E6FC777E9720998E5E8F0539
Content-Type: text/html; charset=us-ascii
Content-Transfer-Encoding: 7bit

<!doctype html public "-//w3c//dtd html 4.0 transitional//en">
<html>
I am sure I don't have the background in PKI as most of those contributing
to this list but I would like to share some ideas:
<p>I have a hard time imagining use of digital signatures for anything
that does not require Non-repudiation.&nbsp;&nbsp; There are a number of
NR issues addressed with digital signatures including NR related to the
creation of an object as well as Non-repudiation of activities such as
delivery/receipt of messages, knowledge (proof that a message was read),
and much more.&nbsp; Sometimes I feel that the term "signature" creates
a paradigm that can become difficult to transcend but I cannot come up
with a better descriptor of the intent behind the process.
<p>As for authentication, digital signatures (which requires access to
the private key, Not a Digital Certificate) demonstrates proof positive
that "a person is who they say they are" and provides a means by which
unquestionable proof can be established that the owner of a given certificate
responded to a challenge and subsequently gained access to some secure
resource.&nbsp; It it important to remember that a digital certificate
is public in nature and without the corresponding private key, it is meaningless.&nbsp;
When a challenge is issued in the authentication process, the act of signing
that challenge must manifest itself by requiring the user to submit his
or her passcode to unlock the private key.&nbsp; If there is no challenge
(i.e. the process of signing without the knowledge of the owner of the
certificate) then the authentication process is completely invalidated.&nbsp;
<p>The following is a quote from FIPS 196:
<p>"To acceptably implement this standard, an implementation must meet
the following criteria:
<p>1) Each entity in an authentication exchange must use a FIPS approved
digital signature algorithm to generate and/or verify digital signatures;
<p>2) Each entity must generate (pseudo)random numbers using a FIPS approved
(pseudo)random number generator;
<p>3) Each entity acting as a claimant must be bound to a public/private
key pair; the private key should remain in the sole control of the claimant
who uses that key to sign a random challenge. The key binding requires
a unique authentication identifier for each claimant, so that a verifier
can distinguish between multiple claimants; and
<p>4) One or both of the authentication protocols in this standard must
be implemented. For each protocol, steps and token fields marked as [OPTIONAL]
do not need to be implemented, except where indicated otherwise. However,
all other steps and token fields must be implemented."
<p>In my mind, authentication and digital signatures are inseparable and
we would be better served to refrain from focusing on the granular differences.
<p>Mitchell Arnone
<br>PKI Engineer
<p>"Golkin, Ken (CAP, CMC)" wrote:
<blockquote TYPE=CITE>&nbsp;
<p><font size=-1>This discussion seems to be confusing two different uses
for certificates</font>
<br><font size=-1>1) Authentication (I am who I say I am)</font>
<br><font size=-1>2) Signature (I signed a legally binding document)</font>
<p><font size=-1>In the first case I showed my company issue picture ID
(certificate) to the guard at the door and he let me in the building this
morning.</font>
<p><font size=-1>In the second case I stopped at the hardware store on
the way home last night to buy a box of nails and some other things.&nbsp;
At the check out I showed them my charge card (certificate) then signed
the sales slip.&nbsp; Which legally obligated me to pay $24.86.</font>
<p><font size=-1>The certificate policy (defined as: A named set of rules
that indicates the</font>
<br><font size=-1>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; applicability of
a public key certificate to a particular</font>
<br><font size=-1>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; community or class
of application with common security</font>
<br><font size=-1>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; requirements. For
example, a particular certificate policy might</font>
<br><font size=-1>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; indicate applicability
of a type of public key certificate to the</font>
<br><font size=-1>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; authentication of
electronic data interchange transactions for</font>
<br><font size=-1>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; the trading of goods
within a given price range.) in X.509 PKiX roadmap makes it clear that
all certificates are not created equal.</font>
<p><font size=-1>The Canadian Government and United States Government PKI
initiatives have defined multiple levels of assurance, and as far as I
can tell, most business applications of PKI are following the government
lead.</font>
<p><font size=-1>If I'm loaning someone $250,000 to buy a house I obviously
need a greater level of assurance that they are who they are (and their
bank is who they say they are) then was required by the checkout at the
hardware store or the guard at the entrance.</font>
<p><font size=-1>-----Original Message-----</font>
<br><font size=-1>From: Adrian McCullagh [<a href="mailto:[e-mail]">mailto:[e-mail]</a>]</font>
<br><font size=-1>Sent: Monday, July 17, 2000 11:08 PM</font>
<br><font size=-1>To: 'Stephen Kent'</font>
<br><font size=-1>Cc: [e-mail]</font>
<br><font size=-1>Subject: RE: Signing what you don't understand</font>
<p><font size=-1>Stephen,</font>
<p><font size=-1>I do not want to get into an argument with you.&nbsp;
Yes I am a lawyer but I</font>
<br><font size=-1>also have a technical background so your suggestion otherwise,
I thought was</font>
<br><font size=-1>not moving the discussion forward. Admittedly, I do not
possess the</font>
<br><font size=-1>technical knowledge that you have.</font>
<p><font size=-1>Your example is well put but is this really a digital
signature or is it a</font>
<br><font size=-1>set of bits (a mark) that has been affixed using the
same technology known</font>
<br><font size=-1>as digital signature technology.</font>
<p><font size=-1>You mention the difference between the 2 intents.&nbsp;
I would be surprised, if</font>
<br><font size=-1>anyone (other than the technically minded) even knows
that a challenge</font>
<br><font size=-1>response is even being "signed".&nbsp; There is no intent
at all in this case. It</font>
<br><font size=-1>is the technology as designed that is effecting the response
to the</font>
<br><font size=-1>challenge.&nbsp; I am surprised that "you" sign authentication
challenges, just</font>
<br><font size=-1>for authentication purposes.&nbsp; Is it really a signature?&nbsp;
Are you really</font>
<br><font size=-1>signing the authentication challenge or is it the software
on your machine</font>
<br><font size=-1>effecting the response to the challenge?</font>
<p><font size=-1>To me this is not a signature.&nbsp; It may use digital
signature technology but</font>
<br><font size=-1>it is not a signature.&nbsp; This is probably the problem.&nbsp;
It is the use of the</font>
<br><font size=-1>word "signature" which is a technical term but has been
used by the PKI</font>
<br><font size=-1>community to cover a myriad of uses.&nbsp; Some uses
of the term by the PKI</font>
<br><font size=-1>community are confusing.</font>
<p><font size=-1>I also do not agree with your position that the NR bit
can signal any intent</font>
<br><font size=-1>either way.&nbsp; With respect, intent is ascertained
at the time of signing.&nbsp; A</font>
<br><font size=-1>certificate has nothing what so ever to do with signing.&nbsp;
Its primary</font>
<br><font size=-1>purpose is to identify a public key that corresponds
to a private key that</font>
<br><font size=-1>may be held by some previously identified person or entity.&nbsp;
The public key</font>
<br><font size=-1>is used to verify a digital signature that has supposedly
been created using</font>
<br><font size=-1>the corresponding private key.&nbsp; That is it as far
as I understand it unless</font>
<br><font size=-1>there is some other primary purpose that I do not know.&nbsp;
I do not see the</font>
<br><font size=-1>relationship between digitally signing a document and
the contents of a</font>
<br><font size=-1>certificate. Verification of the signature at some later
time is a different</font>
<br><font size=-1>issue which may involve the use of a certificate but
this may not be so.</font>
<p><font size=-1>Adrian McCullagh</font>
<br><font size=-1>Director of Electronic Commerce&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Tel: [phone]</font>
<br><font size=-1>Gadens Lawyers&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Fax: [phone]</font>
<br><font size=-1>level 39</font>
<br><font size=-1>Central Plaza 1</font>
<br><font size=-1>345 Queen Street</font>
<br><font size=-1>Brisbane Australia 4000</font>
<p><font size=-1>Ph. D. Candidate</font>
<br><font size=-1>Thesis "The Incorporation of Trust Strategies in Digital
Signature</font>
<br><font size=-1>Regimes for Elec. Comm."</font>
<br><font size=-1>Information Security Research Centre</font>
<br><font size=-1>Queensland University of Technology</font>
<br>&nbsp;
<p><font size=-1>-----Original Message-----</font>
<br><font size=-1>From: Stephen Kent [<a href="mailto:[e-mail]">mailto:[e-mail]</a>]</font>
<br><font size=-1>Sent: Tuesday, July 18, 2000 10:00 AM</font>
<br><font size=-1>To: Adrian McCullagh</font>
<br><font size=-1>Cc: [e-mail]</font>
<br><font size=-1>Subject: RE: Signing what you don't understand</font>
<p><font size=-1>At 12:50 PM +1000 7/15/00, Adrian McCullagh wrote:</font>
<br><font size=-1>>Stephen</font>
<br><font size=-1>></font>
<br><font size=-1>>I really do not understand your response.&nbsp; Why
would anyone sign a document</font>
<br><font size=-1>>that they do not understand.&nbsp; It does not make
sense.&nbsp; If I sent you a</font>
<br><font size=-1>>document written in Chinese and assume you can not read
Chinese and at the</font>
<br><font size=-1>>same time I said just sign this - Why would you sign
it.&nbsp; Now if you</font>
<br><font size=-1>trusted</font>
<br><font size=-1>>me then you may sign it based upon the information about
the document that</font>
<br><font size=-1>I</font>
<br><font size=-1>>tell you.&nbsp; A classic case for Non-est-factum.&nbsp;
But all the cases that I</font>
<br><font size=-1>have</font>
<br><font size=-1>>read clearly rely upon some information provided by
an Alleged trusted</font>
<br><font size=-1>third</font>
<br><font size=-1>>party.&nbsp; Usually some relative.&nbsp; So without
some external information being</font>
<br><font size=-1>>provided by a third party it is not as far as I can
determine possible to</font>
<br><font size=-1>>rely upon non est factum.</font>
<p><font size=-1>Because we sign authentication challenges, just for authentication</font>
<br><font size=-1>purposes, but not for NR purposes, it is prudent to distinguish</font>
<br><font size=-1>between the two intents.&nbsp; Your comments seem to
ignore this use of</font>
<br><font size=-1>digital signature technology. One way of signalling intent
is via the</font>
<br><font size=-1>NR bit. Although it has been argued that having this
bit set to True</font>
<br><font size=-1>does not necessarily signal intent to sign for NR purposes,
having it</font>
<br><font size=-1>set to False certainly signals an intent to not be bound
re NR.</font>
<p><font size=-1>(Your use of Latin and your e-mail "signature" suggests
a legal, but</font>
<br><font size=-1>perhaps not a technical background. We've also decided,
after much</font>
<br><font size=-1>debate, that PKIX deals with technical aspects of NR,
not legal</font>
<br><font size=-1>details that may vary based upon jurisdiction.)</font>
<p><font size=-1>>Also what does a "bit" in a certificate got to do with
non-repudiation.</font>
<br><font size=-1>The</font>
<br><font size=-1>>commercial world and the law does not in my opinion
support this position</font>
<br><font size=-1>of</font>
<br><font size=-1>>yours.&nbsp; You appear to be on a path to re-engineering
the entire commercial</font>
<br><font size=-1>>legal fabric and as such I with the greatest respect
I do not&nbsp; believe that</font>
<br><font size=-1>>society and the law will buy into it.&nbsp; With out
the commercial involvement</font>
<br><font size=-1>>PKI will not survive.</font>
<p><font size=-1>The position is not just mine.&nbsp; Sorry of you don't
understand, or</font>
<br><font size=-1>merely don't agree with the use of the NR bit, or its
name, but we</font>
<br><font size=-1>had this debate a while ago and we're not having it again.</font>
<p><font size=-1>></font>
<br><font size=-1>>I do not understand how - "what you are proposing" -
will work in practical</font>
<br><font size=-1>>terms.</font>
<p><font size=-1>I'm not "proposing," but I am citing existing Internet
and ITU</font>
<br><font size=-1>standards and the applicability to the question at hand.</font>
<p><font size=-1>Steve</font></blockquote>
</html>

--------------E6FC777E9720998E5E8F0539--



Received: from certplus.com ([195.101.88.81]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id IAA23557 for <[e-mail]>; Tue, 18 Jul 2000 08:03:52 -0700 (PDT)
Received: from certplus.com (nt4_jmd.certplus.com [192.168.1.17]) by certplus.com (8.8.7/8.8.7) with ESMTP id PAA14178 for <[e-mail]>; Tue, 18 Jul 2000 15:34:49 +0200
Message-ID: <[e-mail]>
Date: Tue, 18 Jul 2000 17:05:16 +0200
From: Jean-Marc Desperrier <[e-mail]>
Organization: Certplus
X-Mailer: Mozilla 4.72 [en] (WinNT; I)
X-Accept-Language: en
MIME-Version: 1.0
To: [e-mail]
Subject: Re: Signing what you don't understand
References: <[e-mail]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

[e-mail] wrote:

> Quite apart from
> requiring a signer to maintain a large number of distinct keys, I think
> it's a bit much to expect every "legitimate user" to be well-enough versed
> in the nuances of certificates to always request the same certificate
> extensions in every certificate for a given key.

Right. This kind of details has to be hidden to the average user.

> Encoding the intent
> explicitly as part of the signature allows me to choose at the time I
> generate the signature what intent I wish to associate with the signature,
> rather than having to have previously set up certification chains for all
> intents I might wish to asserts.

Maybe this can simply be done through the signed extensions that are available
with PKCS#7 ?

It sounds quite feasible and would not require any format change, just defining
some new extensions and their role.



Received: from prv-mail20.provo.novell.com (prv-mail20.provo.novell.com [137.65.81.122]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id HAA23170 for <[e-mail]>; Tue, 18 Jul 2000 07:57:59 -0700 (PDT)
Received: from INET-PRV-Message_Server by prv-mail20.provo.novell.com with Novell_GroupWise; Tue, 18 Jul 2000 08:59:49 -0600
Message-Id: <[e-mail]>
X-Mailer: Novell GroupWise Internet Agent 5.5.3.1
Date: Tue, 18 Jul 2000 08:59:49 -0600
From: "Bob Jueneman" <[e-mail]>
To: <[e-mail]>
Subject: RE: Current signature formats insufficient
Mime-Version: 1.0
Content-Type: multipart/alternative; boundary="=_A0F8E0F5.22432D3E"

This is a MIME message. If you are reading this text, you may want to 
consider changing to a mail reader or gateway that understands how to 
properly handle MIME multipart messages.

--=_A0F8E0F5.22432D3E
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: quoted-printable

I've been perhaps uncharacteristically quiet on this issue so far, having =
gone though these discussions many, many times in the past.  But let me =
offer some observations..

First, I believe that it is important to differentiate between "authenticat=
ion" and a "signature". =20

Although people could certainly quibble about wording (neither the =
technical nor the legal community have been exemplary with respect to =
clarity on these points), to my mind "authentication" has to do primarily =
with the origin of a _session_, i.e., a sequence of data interchanges.  =
The authentication might very well involve a digital signature technical =
mechanism during the session startup, e.g., during SSL, but it might also =
involve the typical user name and password.

The authentication may substantiate my right to do certain things, receive =
certain information, update my bank account, sell shares of stock, etc.  =
So the legal and/or financial consequences of my actions may be quite =
significant -- certainly hundreds of thousands and potentially millions of =
dollars. (If only my E-trade account were really worth that much!:-)

Whether or not an order transmitted over such an authenticated connection =
is legally binding or not is normally established by virtual of a =
pre-existing relationship, normally a contract, between the two participant=
s.  Whether I deposit money in the bank, or stock in my brokerage account, =
or bales of cotton in a warehouse in Memphis; if the responsible institutio=
n and I agree to certain security procedures by which an order may be =
placed, then such an order would generally be viewed as legally binding, =
even though there might be nothing that would even approximate a "signature=
" per se on the transaction.

I can for example place a telephone call to my broker, identify myself by =
name, account number, PIN number, my current address, etc., and cause =
whatever assets I have in that account to be sold, and the money wired to =
a specific account, all with no written record at all -- certainly not at =
my end.  Could such a transaction be repudiated? Maybe, at least to the =
extent of filing a claim against the person who received the money if it =
was sent to a bogus account somewhere.  But could I undo the transaction, =
perhaps because I could get a better price today, vs. yesterday?  Highly =
unlikely.

(Am I rather uncomfortable with the notion of having my assets so exposed =
to possible manipulation?  You bet!  But that's beside the point.)

Now let's talk about a signature, which is of course another form of =
authentication.

The essential difference is that a signature is (more or less) bound to =
the transaction itself  -- not to the pipe over which the transaction =
flows.  We sign the document, not the envelope, in other words.

An authenticated session is essentially ephemeral -- the authentication =
only persists for the duration of the session.  Granted, the parties at =
either end might capture the contents of that session, and might try to =
match up the session authentication mechanism with the contents of the =
session itself, but such a match-up would fall into the category of =
business records.  They may be exempt from the hearsay rule, and thereby =
be admitted into evidence, but in and of themselves they do not provide =
the type of (more or less) incontrovertible evidence to a neutral third =
party that a signature does.

This, of course, is why the Statute of Frauds over the last several =
hundred years, at least in English-speaking countries, has required a =
signed contract for the transference of real property and certain other =
goods -- it doesn't depend on an ephemeral connection between an authentica=
ted origin and the transaction itself, and the signed document is capable =
of being validated by an independent third party, without recourse to =
records maintained exclusively by the (alleged) parties to the transaction.=


(Typically, such transactions are also required to be witnessed by an =
independent observer, and perhaps even notarized.  The function of that =
observer is to provide corroborative evidence that the signature is not a =
forgery, and presumably that the contract was a conscious, willing, and =
volitional act by the parties -- there was no coercion, the parties =
appeared to be "compos mentis," etc.)

Unfortunately, there are some gray areas that don't fit neatly into these =
two categories.  One example which comes up frequently is that of a =
receipt.  S/MIME V3, as part of the Enhanced Security Services, provides =
for the issuance of a receipt for certain types of e-mail by the e-mail =
agent itself, i.e., an automaton.

So here is a case where the user has delegated certain powers and =
responsibilities to an agent -- in this case a computer program.  This is =
not particularly unusual -- a spouse, roommate, or other person living at =
a particular address can also sign for the receipt of a package or =
document.  By itself, this signature does not prove that the person =
actually received or read the document that was received, much less agreed =
with it.  It does, however, provide the basis for a reasonable (rebuttable)=
 presumption of delivery.  It may, therefore, be deemed to constitute =
effective legal notice to such an individual. =20

(Exactly what constitutes legal notice will probably be hotly debated by =
consumer advocates, especially as a result of the new electronic signature =
law recently signed by President Clinton.  Since an electronic signature =
under that all too sweeping and badly drafted bill can apparently be the =
result of a simple mouse click or other procedural action, even one that =
is not under the informed control of the user, all sorts of things may end =
up being treated as legally binding signatures - it's probably too early =
to tell.)

But I would submit that an automatically generated digitally signed =
receipt, even if it makes use of the subscriber's private key and =
corresponding certificate, and even if the process by which the signature =
was generated took place with at least the user's approval, if not =
specific, conscious knowledge, is much closer to being a form of authentica=
tion than it is a transactional signature.

Although despite many, many rounds of argument we have so far failed to =
adequately define the semantics of what a (technically) nonrepudiable =
signature is, most of us would probably be capable of providing examples =
of what it is not -- e.g., an automatically generated receipt for =
something.

For that reason, I might not be unwilling to use for this purpose a =
private key that was held only in software, and which was unlocked when I =
started up my workstation, even if I was not physically in attendance at =
all times.  Such a e-mail receipt capability could be signed by my user =
agent without my having to enter a password or other unlocking mechanism =
every time the private key was needed.

But such a key and certificate should certainly NOT have the NR bit =
asserted in it, regardless of what the CA's policy says or doesn't say, =
unless I am a complete idiot.  Obviously, a key that is maintained in =
software and capable of being used without human intervention is also =
capable of being misused or compromised by rogue software such as a Trojan =
horse.

So far, I've tried to illustrate what does NOT constitute a technically =
norepudiable digital signature.  I would claim that this includes the =
following cases:

1.  Where the thing that is signed is an authentication challenge prior to =
the establishment of a session.  Although the information that flows over =
the pipe or session may very well have legal consequences and be binding =
in the sense that the transaction cannot be undone, the legally binding =
nature of the series of the transaction had little or nothing to do with =
the digitally signed authentication challenge.  The fact that a digital =
signature was used for authentication was neither necessary nor sufficient =
for the transactions (which were authenticate as having come from the =
originator, but were individually NOT signed per se) to be legally =
binding.

2.  Automatically generated signatures for such actions as acknowledgments =
or receipts may be binding in the sense of having constituted legal notice =
of delivery, but again the use of a digital signature mechanism may =
provide a heightened presumption of validity, but is not in itself either =
strictly necessary, nor always completely sufficient, even to prove =
delivery, any more than a human signature in such a case would necessarily =
be iron-clad evidence.

The criteria for what SHOULD constitute a technically nonrepudiable =
signature, and the semantic and technical constraints that should probably =
be imposed are much more difficult to state, and this note is already far =
too long, so I'll save that discussion for another time.

Bob

--=_A0F8E0F5.22432D3E
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META content=3D"text/html; charset=3Diso-8859-1" http-equiv=3DContent-Type=
>
<META content=3D"MSHTML 5.00.2614.3401" name=3DGENERATOR></HEAD>
<BODY style=3D"FONT: 8pt MS Sans Serif; MARGIN-LEFT: 2px; MARGIN-TOP: =
2px">
<DIV><FONT size=3D1>I've been perhaps uncharacteristically quiet on this =
issue so=20
far, having gone though these discussions many, many times in the =
past.&nbsp;=20
But let me offer some observations..</FONT></DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT size=3D1>First, I believe that it is important to differentiate =
between=20
"authentication" and a "signature".&nbsp; </FONT></DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT size=3D1>Although people could certainly quibble about wording =
(neither=20
the technical nor the legal community have been exemplary with respect =
to=20
clarity on these points), to my mind "authentication" has to do primarily =
with=20
the origin of a _session_, i.e., a sequence of data interchanges.&nbsp; =
The=20
authentication might very well involve a digital signature technical =
mechanism=20
during the session startup, e.g., during SSL, but it might also involve =
the=20
typical user name and password.</FONT></DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT size=3D1>The authentication may substantiate my&nbsp;right to =
do=20
certain things, receive certain information, update my bank account, sell =
shares=20
of stock, etc.&nbsp; So the legal and/or financial consequences of my =
actions=20
may be quite significant -- certainly hundreds of thousands and potentially=
=20
millions of dollars. (If only my E-trade account were really worth that=20
much!:-)</FONT></DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT size=3D1>Whether or not an order transmitted over such an =
authenticated=20
connection is legally binding or not is normally established by virtual of =
a=20
pre-existing relationship, normally a contract, between the two=20
participants.&nbsp; Whether I deposit money in the bank, or stock in my=20
brokerage account, or bales of cotton in a warehouse in Memphis; if the=20
responsible institution and I agree to certain security procedures by =
which an=20
order may be placed, then such an order would generally be viewed as =
legally=20
binding, even though there might be nothing that would even approximate =
a=20
"signature" per se on the transaction.</FONT></DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT size=3D1>I can for example place a telephone call to my =
broker,=20
identify myself by name, account number, PIN number, my current address, =
etc.,=20
and cause whatever assets I have in that account to be sold, and the money =
wired=20
to a specific account, all with no written record at all -- certainly not =
at my=20
end.&nbsp; Could such a transaction be repudiated? Maybe, at least to the =
extent=20
of filing a claim against the person who received the money if it was sent =
to a=20
bogus account somewhere.&nbsp; But could I undo the transaction, perhaps =
because=20
I could get a better price today, vs. yesterday?&nbsp; Highly=20
unlikely.</FONT></DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT size=3D1>(Am I rather uncomfortable with the notion of having =
my assets=20
so exposed to possible manipulation?&nbsp; You bet!&nbsp; But that's =
beside the=20
point.)</FONT></DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT size=3D1>Now let's talk about a signature, which is of course =
another=20
form of authentication.</FONT></DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT size=3D1>The essential difference is that a signature is (more =
or less)=20
bound to the transaction itself&nbsp; -- not to the pipe over which the=20
transaction flows.&nbsp; We sign the document, not the envelope, in =
other=20
words.</FONT></DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT size=3D1>An authenticated session is essentially ephemeral -- =
the=20
authentication only persists for the duration of the session.&nbsp; =
Granted, the=20
parties at either end might capture the contents of that session, and =
might try=20
to match up the session authentication mechanism with the contents of =
the=20
session itself, but such a match-up would fall into the category of =
business=20
records.&nbsp; They may be exempt from the hearsay rule, and thereby be =
admitted=20
into evidence, but in and of themselves they do not provide the type of =
(more or=20
less) incontrovertible evidence to a neutral third party that a =
signature=20
does.</FONT></DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT size=3D1>This, of course, is why the Statute of Frauds over the =
last=20
several hundred years, at least in English-speaking countries, has =
required a=20
signed contract for the transference of real property and certain other =
goods --=20
it doesn't depend on an ephemeral connection between an authenticated =
origin and=20
the transaction itself, and the signed document is capable of being =
validated by=20
an independent third party, without recourse to records maintained =
exclusively=20
by the (alleged) parties to the transaction.</FONT></DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT size=3D1>(Typically, such transactions are also required to =
be=20
witnessed by an independent observer, and perhaps even notarized.&nbsp; =
The=20
function of that observer is to provide corroborative evidence that the=20
signature is not a forgery, and&nbsp;presumably that the contract was a=20
conscious, willing, and volitional act by the parties -- there was no =
coercion,=20
the parties appeared to be "compos mentis," etc.)</FONT></DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT size=3D1>Unfortunately, there are some gray areas that don't =
fit neatly=20
into these two categories.&nbsp; One example which comes up frequently is =
that=20
of a receipt.&nbsp; S/MIME V3, as part of the Enhanced Security =
Services,=20
provides for the issuance of a receipt for certain types of e-mail by the =
e-mail=20
agent itself, i.e., an automaton.</FONT></DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT size=3D1>So here is a case where the user has delegated certain =
powers=20
and responsibilities to an agent -- in this case a computer program.&nbsp; =
This=20
is not particularly unusual -- a spouse, roommate, or other person living =
at a=20
particular address can also sign for the receipt of a package or document.&=
nbsp;=20
By itself, this signature does not prove that the person actually received =
or=20
read the document that was received, much less agreed with it.&nbsp; It =
does,=20
however, provide the basis for a reasonable (rebuttable) presumption of=20
delivery.&nbsp; It may, therefore, be deemed to constitute effective =
legal=20
notice to such an individual.&nbsp; </FONT></DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT size=3D1>(Exactly what constitutes legal notice will probably =
be hotly=20
debated by consumer advocates, especially as a result of the new electronic=
=20
signature law recently signed by President Clinton.&nbsp; Since an =
electronic=20
signature under that all too sweeping and badly drafted bill can apparently=
 be=20
the result of a simple mouse click or other procedural action, even one =
that is=20
not under the informed control of the user, all sorts of things may end up =
being=20
treated as legally binding signatures - it's probably too early to=20
tell.)</FONT></DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT size=3D1>But I would submit that an automatically generated =
digitally=20
signed receipt, even if it makes use of the subscriber's private key =
and=20
corresponding certificate, and even if the process by which the signature =
was=20
generated took place with at least the user's approval, if not specific,=20=

conscious knowledge, is much closer to being a form of authentication than =
it is=20
a transactional signature.</FONT></DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT size=3D1>Although despite many, many rounds of argument we have =
so far=20
failed to adequately define the semantics of what a (technically) =
nonrepudiable=20
signature is, most of us would probably be capable of providing examples =
of what=20
it is not -- e.g., an automatically generated receipt for=20
something.</FONT></DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT size=3D1>For that reason, I might not be unwilling to use for =
this=20
purpose a private key that was held only in software, and which was =
unlocked=20
when I started up my workstation, even if I was not physically in =
attendance at=20
all times.&nbsp; Such a e-mail receipt capability could be signed by my =
user=20
agent without my having to enter a password or other unlocking mechanism =
every=20
time the private key was needed.</FONT></DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT size=3D1>But such a key and certificate should certainly NOT =
have the=20
NR bit asserted in it, regardless of what the CA's policy says or doesn't =
say,=20
unless I am a complete idiot.&nbsp; Obviously, a key that is maintained =
in=20
software and capable of being used without human intervention is also =
capable of=20
being misused or compromised by rogue software such as a Trojan=20
horse.</FONT></DIV>
<DIV>&nbsp;</DIV>
<DIV>So far, I've tried to illustrate what does NOT constitute a technicall=
y=20
norepudiable digital signature.&nbsp; I would claim that this includes =
the=20
following cases:</DIV>
<DIV>&nbsp;</DIV>
<DIV>1.&nbsp; Where the thing that is signed is an authentication =
challenge=20
prior to the establishment of a session.&nbsp; Although the information =
that=20
flows over the pipe or session may very well have legal consequences and =
be=20
binding in the sense that the transaction cannot be undone, the legally =
binding=20
nature of the series of the transaction had little or nothing to do with =
the=20
digitally signed authentication challenge.&nbsp; The fact that a digital=20=

signature was used for authentication was neither necessary nor sufficient =
for=20
the transactions (which were authenticate as having come from the =
originator,=20
but were individually NOT signed per se) to be legally binding.</DIV>
<DIV>&nbsp;</DIV>
<DIV>2.&nbsp; Automatically generated signatures for such actions as=20
acknowledgments or receipts may be binding in the sense of having =
constituted=20
legal notice of delivery, but again the use of a digital signature =
mechanism may=20
provide a heightened presumption of validity, but is not in itself =
either=20
strictly necessary, nor always completely sufficient, even to prove =
delivery,=20
any more than a human signature in such a case would necessarily be =
iron-clad=20
evidence.</DIV>
<DIV>&nbsp;</DIV>
<DIV>The criteria for what SHOULD constitute a technically nonrepudiable=20=

signature, and the semantic and technical constraints that should probably =
be=20
imposed are much more difficult to state, and this note is already far too =
long,=20
so I'll save that discussion for another time.</DIV>
<DIV>&nbsp;</DIV>
<DIV>Bob</DIV>
<DIV>&nbsp;</DIV>
<DIV>&nbsp;</DIV></BODY></HTML>

--=_A0F8E0F5.22432D3E--


Received: from arista.iris.com (arista.iris.com [198.112.211.42]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id HAA22519 for <[e-mail]>; Tue, 18 Jul 2000 07:44:30 -0700 (PDT)
From: [e-mail]
Subject: Re: Signing what you don't understand
To: Stephen Kent <[e-mail]>
Cc: [e-mail], <[e-mail]>
X-Mailer: Lotus Notes Release 5.0.2c  February 2, 2000
Message-ID: <[e-mail]>
Date: Tue, 18 Jul 2000 10:47:05 -0400
X-MIMETrack: Serialize by Router on Arista/Iris(Build V505_07112000 |July 11, 2000) at 07/18/2000 10:47:02 AM
MIME-Version: 1.0
Content-type: text/plain; charset=us-ascii

Steve,

>>Anything in the certificate that's used to imply something about the
intent
>>behind a signature is asking for trouble, unless the specific certificate
>>that a relying party should use is bound to the signature.  What's to
>>prevent me from obtaining certificates from two different CAs, certifying
>>the same key, but with different settings of the NR bit in the two
>>certificates, and then using the certificate with the NR bit clear to
>>repudiate a signature I originally represented as being non-repudiable
>>using the other certificate?
>
>Not necessarily. You seem to assume that a signer could escape
>responsibility for signing in an NR context by producing a
>certificate with the same public key but without the NR bit asserted.
>I don't subscribe to that assumption.  if I, as an RP, collect a cert
>associated with the user and it has the right public key and NR
>asserted, then why is my assertion of which cert was used in the
>transaction untenable?  A legitimate user should never put the same
>public key into two certs that differ in terms of this key usage bit
>(and probably not if they differ in other, significant ways).  If
>push came to shove and the user asserted that the NR-enabled cert was
>not really issued at his request, a check of CA records for POP could
>resolve the problem. [I assume that any CA issuing a cert with an NR
>bit enabled ought to insist on POP, but maybe that's my unwarranted
>assumption :-).]

I think you're suggesting the use of a distinct key for each possible
"signature intent" here (although the example deals with R vs. NR, there
are more than just two flavors of signature intent).  Quite apart from
requiring a signer to maintain a large number of distinct keys, I think
it's a bit much to expect every "legitimate user" to be well-enough versed
in the nuances of certificates to always request the same certificate
extensions in every certificate for a given key.


>>The only way that using anything in the certificate could work is if the
>>specific certificate that I intend a relying party to use to verify the
>>signature is somehow bound into the signature.  Binding a particular
>>certificate to a signature has all sorts of other problems (e.g. do all
my
>>signatures become unverifiable when my certificate is renewed?), and
would
>>require a signature format change anyway, so why not simply assert the
>>intent explicitly as part of the signature?
>
>Based on my comments above, I'm not sure we need to perform this
>binding, but I agree with Denis's comments here, i.e., it's not
>infeasible and the persistence of the signature is divorced from the
>certificate lifetime by other mechanisms.

What other mechanisms would cover that case of my issuing CA going out of
business?  If a CA's assets (including its keys) are sold as part of a
bankruptcy process, I would think that trust in those keys would be fairly
quickly revoked by other CAs that might have cross-certified it.  In this
case, invalidityDate on those revocations would probably be set so that no
certificate that had been issued by the former CA's key would be trusted
(to prevent the keys' new owners from issuing new backdated certificates).
However, as a subscriber to the former CA, I don't see why my signatures
should suddenly become less trustworthy, if my key can be verified via
another path.


>By the way, I'm not saying that a new format for signatures which are
>designed precisely for NR purposes with general purpose documents is
>a bad idea.  I just commented on what appeared to be a lack of good
>arguments for such a construct.  I agree that the ability to have a
>small token be able to understand such constructs could be valuable,
>even though we still face a lot of problems with regard to secure
>display of the contents of what is being signed.

The most persuasive argument I can come up with is an architectural one,
and assumes that there are more flavors of "signature intent" than just
repudiable vs non-repudiable.  There are three places I can see that one
might try to encode the intent behind a signature: The particular key used,
the particular certificate used, or explicitly as part of the signature
structure.  The intent behind a signature is fairly dynamic, possibly
varying with each signature.  On occasion I might want to sign a nonce
simply to prove I possess a key; at other times I might want to sign a
piece of e-mail to indicate that I have read it, i.e. to generate a
return-receipt;  at other times my signature might assert my agreement to
the contents of a document;  at other times it might be intended as an
approval of some business process (i.e. "If the expenses listed in the
document are as described, then they may be reimbursed").  However, both
the certification hierarchy and the availability of keys are fairly static
things - I either need to get my key re-certified for each possible
signature intent I might want to assert, or I need to generate and certify
a distinct key for each possible signature intent.  Encoding the intent
explicitly as part of the signature allows me to choose at the time I
generate the signature what intent I wish to associate with the signature,
rather than having to have previously set up certification chains for all
intents I might wish to asserts.  I would also claim that it's less
error-prone and probably of greated legal validity to explicitly encode the
intent along with the signature than to try to infer the certified intent
from the contents of certificates issued by third-party CAs.

John



Received: from ntserver2.chrysalis-its.com ([209.47.245.163]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id GAA19868 for <[e-mail]>; Tue, 18 Jul 2000 06:34:09 -0700 (PDT)
From: [e-mail]
Received: by NTSERVER2 with Internet Mail Service (5.5.2650.21) id <P1AM8X7D>; Tue, 18 Jul 2000 09:37:11 -0400
Message-ID: <[e-mail]>
To: [e-mail]
Cc: [e-mail], [e-mail]
Subject: RE: Re: CRMF encValue Field
Date: Tue, 18 Jul 2000 09:37:03 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01BFF0BD.463510D2"

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01BFF0BD.463510D2
Content-Type: text/plain;
	charset="iso-8859-1"

Hi Carlisle,

I accept your responses, but I have an extra comment. According to ANSI
X9.42, the Diffie-Hellman algorithm OID listed in an Appendix B2 of
RFC2510bis represents the algorithm OID for a Diffie-Hellman public key,
however the algorithm OID in the PrivateKeyInfo as mentioned in PKCS#11
identifies the "private key" algorithm OID. Note that Appendix A3 of ANSI
X9.42 indicates that: 

"the syntax and encoding of private keys is considered to be implementation
dependent and beyond the scope of this standard. It may, however, be useful
for specific implementations or derivative standards to define a number type
identified by dh-private-key to encode private keys".

Shouldn't the algorithm OID for an ANSI X9.42 Diffie-Hellman private key be
added to Appendix B2 for this case?

Regards,

Francois

-----Original Message-----
From: Carlisle Adams [mailto:[e-mail]]
Sent: Monday, July 17, 2000 2:54 PM
To: '[e-mail]'
Cc: [e-mail]; [e-mail]
Subject: RE: Re: CRMF encValue Field


Hi Francois,

> ----------
> From:
> [e-mail][SMTP:[e-mail]]
> Sent: 	Monday, July 17, 2000 11:55 AM
> To: 	[e-mail]
> Cc: 	[e-mail]
> Subject: 	RE: Re: CRMF encValue Field
> 
> Hi Stephen, 
> 
> I have noted that the recently published July version of RFC2510bis now
> contains a note in Appendix D on "RFC 2511 Clarifications" about this
> particular issue, however an exception was added for the Diffie-Hellman
> algorithm OID and parameters whereas those defined in Appendix B2 of this
> specification (i.e. RFC2510bis) MUST be used instead of the OID and
> parameters defined in PKCS#11. Although I understand that this exception
> was necessary since PKCS#11 currently only supports the PKCS#3 flavour of
> Diffie-Hellman whereas Appendix B2 of RFC2510bis is about the ANSI X9.42
> flavour of Diffie-Hellman, this should have been mentioned in this
> clarification.
 
I suppose this could have been mentioned, but it seemed pretty unnecessary.
Wouldn't people naturally expect the OIDs in this field to be consistent
with the OIDs defined in Appendix B2?  I doubt that there's much potential
for confusion here, so extra wording for clarification seems redundant.

> In addition, this same clarification indicates that in this case, the
> intendedAlg field is unnecessary (since this information is included in
> PrivateKeyInfo) and MUST be omitted. However, the algorithm identifier
> field within the PrivateKeyInfo is encrypted, which means that the
> "EncryptedValue" type would not contain any information in the clear about
> the OID of the private key that it is carrying. Was this your intend,
> please clarify? I also understand that including the intendedAlg field
> would duplicate the occurrence of the parameters field, since the syntax
> of the "AlgorithmIdentifier" type also contains a "parameters" field,
> however by still indicating the algorithm OID, but forcing the
> "parameters" field within the intendedAlg field to be NULL would allow the
> "EncryptedValue" type to indicate what is the OID of the private key that
> it is carrying, but not duplicate the parameters field. Wouldn't this
> approach be better?
 
No, this approach doesn't strike me as particularly better.  It seems like a
real kludge to include an AlgId for the same thing twice, but to specify (in
commentary) that the parameters should be NULL for one of these and non-NULL
(i.e., present) for the other.  This reduces clarity for the
reader/implementer and may run in to trouble with some compilers that are
expecting actual parameter values.

As for fact that the AlgId in PrivateKeyInfo is encrypted, why is this a
concern?  Does the receiver need to know this prior to decryption?

Carlisle.

------_=_NextPart_001_01BFF0BD.463510D2
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Diso-8859-1">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
5.5.2650.12">
<TITLE>RE: Re: CRMF encValue Field</TITLE>
</HEAD>
<BODY>

<P><FONT SIZE=3D2>Hi Carlisle,</FONT>
</P>

<P><FONT SIZE=3D2>I accept your responses, but I have an extra comment. =
According to ANSI X9.42, the Diffie-Hellman algorithm OID listed in an =
Appendix B2 of RFC2510bis represents the algorithm OID for a =
Diffie-Hellman public key, however the algorithm OID in the =
PrivateKeyInfo as mentioned in PKCS#11 identifies the &quot;private =
key&quot; algorithm OID. Note that Appendix A3 of ANSI X9.42 indicates =
that: </FONT></P>

<P><FONT SIZE=3D2>&quot;the syntax and encoding of private keys is =
considered to be implementation dependent and beyond the scope of this =
standard. It may, however, be useful for specific implementations or =
derivative standards to define a number type identified by =
dh-private-key to encode private keys&quot;.</FONT></P>

<P><FONT SIZE=3D2>Shouldn't the algorithm OID for an ANSI X9.42 =
Diffie-Hellman private key be added to Appendix B2 for this =
case?</FONT>
</P>

<P><FONT SIZE=3D2>Regards,</FONT>
</P>

<P><FONT SIZE=3D2>Francois</FONT>
</P>

<P><FONT SIZE=3D2>-----Original Message-----</FONT>
<BR><FONT SIZE=3D2>From: Carlisle Adams [<A =
HREF=3D"mailto:[e-mail]">mailto:carlisle.adams@entrust=
.com</A>]</FONT>
<BR><FONT SIZE=3D2>Sent: Monday, July 17, 2000 2:54 PM</FONT>
<BR><FONT SIZE=3D2>To: '[e-mail]'</FONT>
<BR><FONT SIZE=3D2>Cc: [e-mail]; =
[e-mail]</FONT>
<BR><FONT SIZE=3D2>Subject: RE: Re: CRMF encValue Field</FONT>
</P>
<BR>

<P><FONT SIZE=3D2>Hi Francois,</FONT>
</P>

<P><FONT SIZE=3D2>&gt; ----------</FONT>
<BR><FONT SIZE=3D2>&gt; From:</FONT>
<BR><FONT SIZE=3D2>&gt; =
[e-mail][SMTP:[e-mail]]</FONT>
<BR><FONT SIZE=3D2>&gt; Sent: =
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Monday, July 17, 2000 11:55 =
AM</FONT>
<BR><FONT SIZE=3D2>&gt; To: &nbsp; [e-mail]</FONT>
<BR><FONT SIZE=3D2>&gt; Cc: &nbsp; [e-mail]</FONT>
<BR><FONT SIZE=3D2>&gt; Subject: &nbsp;&nbsp;&nbsp;&nbsp; RE: Re: CRMF =
encValue Field</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; Hi Stephen, </FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; I have noted that the recently published July =
version of RFC2510bis now</FONT>
<BR><FONT SIZE=3D2>&gt; contains a note in Appendix D on &quot;RFC 2511 =
Clarifications&quot; about this</FONT>
<BR><FONT SIZE=3D2>&gt; particular issue, however an exception was =
added for the Diffie-Hellman</FONT>
<BR><FONT SIZE=3D2>&gt; algorithm OID and parameters whereas those =
defined in Appendix B2 of this</FONT>
<BR><FONT SIZE=3D2>&gt; specification (i.e. RFC2510bis) MUST be used =
instead of the OID and</FONT>
<BR><FONT SIZE=3D2>&gt; parameters defined in PKCS#11. Although I =
understand that this exception</FONT>
<BR><FONT SIZE=3D2>&gt; was necessary since PKCS#11 currently only =
supports the PKCS#3 flavour of</FONT>
<BR><FONT SIZE=3D2>&gt; Diffie-Hellman whereas Appendix B2 of =
RFC2510bis is about the ANSI X9.42</FONT>
<BR><FONT SIZE=3D2>&gt; flavour of Diffie-Hellman, this should have =
been mentioned in this</FONT>
<BR><FONT SIZE=3D2>&gt; clarification.</FONT>
<BR><FONT SIZE=3D2>&nbsp;</FONT>
<BR><FONT SIZE=3D2>I suppose this could have been mentioned, but it =
seemed pretty unnecessary.</FONT>
<BR><FONT SIZE=3D2>Wouldn't people naturally expect the OIDs in this =
field to be consistent</FONT>
<BR><FONT SIZE=3D2>with the OIDs defined in Appendix B2?&nbsp; I doubt =
that there's much potential</FONT>
<BR><FONT SIZE=3D2>for confusion here, so extra wording for =
clarification seems redundant.</FONT>
</P>

<P><FONT SIZE=3D2>&gt; In addition, this same clarification indicates =
that in this case, the</FONT>
<BR><FONT SIZE=3D2>&gt; intendedAlg field is unnecessary (since this =
information is included in</FONT>
<BR><FONT SIZE=3D2>&gt; PrivateKeyInfo) and MUST be omitted. However, =
the algorithm identifier</FONT>
<BR><FONT SIZE=3D2>&gt; field within the PrivateKeyInfo is encrypted, =
which means that the</FONT>
<BR><FONT SIZE=3D2>&gt; &quot;EncryptedValue&quot; type would not =
contain any information in the clear about</FONT>
<BR><FONT SIZE=3D2>&gt; the OID of the private key that it is carrying. =
Was this your intend,</FONT>
<BR><FONT SIZE=3D2>&gt; please clarify? I also understand that =
including the intendedAlg field</FONT>
<BR><FONT SIZE=3D2>&gt; would duplicate the occurrence of the =
parameters field, since the syntax</FONT>
<BR><FONT SIZE=3D2>&gt; of the &quot;AlgorithmIdentifier&quot; type =
also contains a &quot;parameters&quot; field,</FONT>
<BR><FONT SIZE=3D2>&gt; however by still indicating the algorithm OID, =
but forcing the</FONT>
<BR><FONT SIZE=3D2>&gt; &quot;parameters&quot; field within the =
intendedAlg field to be NULL would allow the</FONT>
<BR><FONT SIZE=3D2>&gt; &quot;EncryptedValue&quot; type to indicate =
what is the OID of the private key that</FONT>
<BR><FONT SIZE=3D2>&gt; it is carrying, but not duplicate the =
parameters field. Wouldn't this</FONT>
<BR><FONT SIZE=3D2>&gt; approach be better?</FONT>
<BR><FONT SIZE=3D2>&nbsp;</FONT>
<BR><FONT SIZE=3D2>No, this approach doesn't strike me as particularly =
better.&nbsp; It seems like a</FONT>
<BR><FONT SIZE=3D2>real kludge to include an AlgId for the same thing =
twice, but to specify (in</FONT>
<BR><FONT SIZE=3D2>commentary) that the parameters should be NULL for =
one of these and non-NULL</FONT>
<BR><FONT SIZE=3D2>(i.e., present) for the other.&nbsp; This reduces =
clarity for the</FONT>
<BR><FONT SIZE=3D2>reader/implementer and may run in to trouble with =
some compilers that are</FONT>
<BR><FONT SIZE=3D2>expecting actual parameter values.</FONT>
</P>

<P><FONT SIZE=3D2>As for fact that the AlgId in PrivateKeyInfo is =
encrypted, why is this a</FONT>
<BR><FONT SIZE=3D2>concern?&nbsp; Does the receiver need to know this =
prior to decryption?</FONT>
</P>

<P><FONT SIZE=3D2>Carlisle.</FONT>
</P>

</BODY>
</HTML>
------_=_NextPart_001_01BFF0BD.463510D2--


Received: from unknown-147.101.pilot.net (unknown-147-101.pilot.net [198.232.147.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id FAA15730 for <[e-mail]>; Tue, 18 Jul 2000 05:42:25 -0700 (PDT)
Received: from unknown-24-15.pilot.net (unknown-24-15.pilot.net [206.189.24.15]) by unknown-147.101.pilot.net with ESMTP id FAA27773; Tue, 18 Jul 2000 05:44:43 -0700 (PDT)
Received: from ralsimcout.gecmc.ge.com (localhost [127.0.0.1]) by unknown-24-15.pilot.net with ESMTP id FAA17532; Tue, 18 Jul 2000 05:44:42 -0700 (PDT)
Received: by ralsimcout.gecmc.ge.COM with Internet Mail Service (5.5.2651.58) id <3W64WGBY>; Tue, 18 Jul 2000 08:44:29 -0400
Message-ID: <[e-mail]>
From: "Golkin, Ken (CAP, CMC)" <[e-mail]>
To: "'Adrian McCullagh'" <[e-mail]>, "'Stephen Kent'" <[e-mail]>
Cc: [e-mail]
Subject: RE: Signing what you don't understand
Date: Tue, 18 Jul 2000 08:44:40 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2651.58)
Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01BFF0B5.F0B5DB20"

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01BFF0B5.F0B5DB20
Content-Type: text/plain;
	charset="iso-8859-1"

This discussion seems to be confusing two different uses for certificates
1) Authentication (I am who I say I am)
2) Signature (I signed a legally binding document)

In the first case I showed my company issue picture ID (certificate) to the
guard at the door and he let me in the building this morning.  
In the second case I stopped at the hardware store on the way home last
night to buy a box of nails and some other things.  At the check out I
showed them my charge card (certificate) then signed the sales slip.  Which
legally obligated me to pay $24.86.  

The certificate policy (defined as: A named set of rules that indicates the
       applicability of a public key certificate to a particular
       community or class of application with common security
       requirements. For example, a particular certificate policy might
       indicate applicability of a type of public key certificate to the
       authentication of electronic data interchange transactions for
       the trading of goods within a given price range.) in X.509 PKiX
roadmap makes it clear that all certificates are not created equal.

The Canadian Government and United States Government PKI initiatives have
defined multiple levels of assurance, and as far as I can tell, most
business applications of PKI are following the government lead.

If I'm loaning someone $250,000 to buy a house I obviously need a greater
level of assurance that they are who they are (and their bank is who they
say they are) then was required by the checkout at the hardware store or the
guard at the entrance.

-----Original Message-----
From: Adrian McCullagh [mailto:[e-mail]]
Sent: Monday, July 17, 2000 11:08 PM
To: 'Stephen Kent'
Cc: [e-mail]
Subject: RE: Signing what you don't understand


Stephen,

I do not want to get into an argument with you.  Yes I am a lawyer but I
also have a technical background so your suggestion otherwise, I thought was
not moving the discussion forward. Admittedly, I do not possess the
technical knowledge that you have.

Your example is well put but is this really a digital signature or is it a
set of bits (a mark) that has been affixed using the same technology known
as digital signature technology.

You mention the difference between the 2 intents.  I would be surprised, if
anyone (other than the technically minded) even knows that a challenge
response is even being "signed".  There is no intent at all in this case. It
is the technology as designed that is effecting the response to the
challenge.  I am surprised that "you" sign authentication challenges, just
for authentication purposes.  Is it really a signature?  Are you really
signing the authentication challenge or is it the software on your machine
effecting the response to the challenge? 

To me this is not a signature.  It may use digital signature technology but
it is not a signature.  This is probably the problem.  It is the use of the
word "signature" which is a technical term but has been used by the PKI
community to cover a myriad of uses.  Some uses of the term by the PKI
community are confusing. 

I also do not agree with your position that the NR bit can signal any intent
either way.  With respect, intent is ascertained at the time of signing.  A
certificate has nothing what so ever to do with signing.  Its primary
purpose is to identify a public key that corresponds to a private key that
may be held by some previously identified person or entity.  The public key
is used to verify a digital signature that has supposedly been created using
the corresponding private key.  That is it as far as I understand it unless
there is some other primary purpose that I do not know.  I do not see the
relationship between digitally signing a document and the contents of a
certificate. Verification of the signature at some later time is a different
issue which may involve the use of a certificate but this may not be so.

Adrian McCullagh
Director of Electronic Commerce		Tel: [phone]
Gadens Lawyers					Fax: [phone]	
level 39
Central Plaza 1
345 Queen Street
Brisbane Australia 4000

Ph. D. Candidate 
Thesis "The Incorporation of Trust Strategies in Digital Signature
Regimes for Elec. Comm."
Information Security Research Centre
Queensland University of Technology



-----Original Message-----
From: Stephen Kent [mailto:[e-mail]]
Sent: Tuesday, July 18, 2000 10:00 AM
To: Adrian McCullagh
Cc: [e-mail]
Subject: RE: Signing what you don't understand


At 12:50 PM +1000 7/15/00, Adrian McCullagh wrote:
>Stephen
>
>I really do not understand your response.  Why would anyone sign a document
>that they do not understand.  It does not make sense.  If I sent you a
>document written in Chinese and assume you can not read Chinese and at the
>same time I said just sign this - Why would you sign it.  Now if you
trusted
>me then you may sign it based upon the information about the document that
I
>tell you.  A classic case for Non-est-factum.  But all the cases that I
have
>read clearly rely upon some information provided by an Alleged trusted
third
>party.  Usually some relative.  So without some external information being
>provided by a third party it is not as far as I can determine possible to
>rely upon non est factum.

Because we sign authentication challenges, just for authentication 
purposes, but not for NR purposes, it is prudent to distinguish 
between the two intents.  Your comments seem to ignore this use of 
digital signature technology. One way of signalling intent is via the 
NR bit. Although it has been argued that having this bit set to True 
does not necessarily signal intent to sign for NR purposes, having it 
set to False certainly signals an intent to not be bound re NR.

(Your use of Latin and your e-mail "signature" suggests a legal, but 
perhaps not a technical background. We've also decided, after much 
debate, that PKIX deals with technical aspects of NR, not legal 
details that may vary based upon jurisdiction.)

>Also what does a "bit" in a certificate got to do with non-repudiation.
The
>commercial world and the law does not in my opinion support this position
of
>yours.  You appear to be on a path to re-engineering the entire commercial
>legal fabric and as such I with the greatest respect I do not  believe that
>society and the law will buy into it.  With out the commercial involvement
>PKI will not survive.

The position is not just mine.  Sorry of you don't understand, or 
merely don't agree with the use of the NR bit, or its name, but we 
had this debate a while ago and we're not having it again.

>
>I do not understand how - "what you are proposing" - will work in practical
>terms.

I'm not "proposing," but I am citing existing Internet and ITU 
standards and the applicability to the question at hand.

Steve

------_=_NextPart_001_01BFF0B5.F0B5DB20
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Diso-8859-1">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
5.5.2651.75">
<TITLE>RE: Signing what you don't understand</TITLE>
</HEAD>
<BODY>

<P><FONT SIZE=3D2>This discussion seems to be confusing two different =
uses for certificates</FONT>
<BR><FONT SIZE=3D2>1) Authentication (I am who I say I am)</FONT>
<BR><FONT SIZE=3D2>2) Signature (I signed a legally binding =
document)</FONT>
</P>

<P><FONT SIZE=3D2>In the first case I showed my company issue picture =
ID (certificate) to the guard at the door and he let me in the building =
this morning.&nbsp; </FONT></P>

<P><FONT SIZE=3D2>In the second case I stopped at the hardware store on =
the way home last night to buy a box of nails and some other =
things.&nbsp; At the check out I showed them my charge card =
(certificate) then signed the sales slip.&nbsp; Which legally obligated =
me to pay $24.86.&nbsp; </FONT></P>

<P><FONT SIZE=3D2>The certificate policy (defined as: A named set of =
rules that indicates the</FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; applicability =
of a public key certificate to a particular</FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; community or =
class of application with common security</FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; requirements. =
For example, a particular certificate policy might</FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; indicate =
applicability of a type of public key certificate to the</FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; authentication =
of electronic data interchange transactions for</FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; the trading of =
goods within a given price range.) in X.509 PKiX roadmap makes it clear =
that all certificates are not created equal.</FONT></P>

<P><FONT SIZE=3D2>The Canadian Government and United States Government =
PKI initiatives have defined multiple levels of assurance, and as far =
as I can tell, most business applications of PKI are following the =
government lead.</FONT></P>

<P><FONT SIZE=3D2>If I'm loaning someone $250,000 to buy a house I =
obviously need a greater level of assurance that they are who they are =
(and their bank is who they say they are) then was required by the =
checkout at the hardware store or the guard at the entrance.</FONT></P>

<P><FONT SIZE=3D2>-----Original Message-----</FONT>
<BR><FONT SIZE=3D2>From: Adrian McCullagh [<A =
HREF=3D"mailto:[e-mail]">mailto:AMcCullagh@exch=
ange.gadens.com.au</A>]</FONT>
<BR><FONT SIZE=3D2>Sent: Monday, July 17, 2000 11:08 PM</FONT>
<BR><FONT SIZE=3D2>To: 'Stephen Kent'</FONT>
<BR><FONT SIZE=3D2>Cc: [e-mail]</FONT>
<BR><FONT SIZE=3D2>Subject: RE: Signing what you don't =
understand</FONT>
</P>
<BR>

<P><FONT SIZE=3D2>Stephen,</FONT>
</P>

<P><FONT SIZE=3D2>I do not want to get into an argument with you.&nbsp; =
Yes I am a lawyer but I</FONT>
<BR><FONT SIZE=3D2>also have a technical background so your suggestion =
otherwise, I thought was</FONT>
<BR><FONT SIZE=3D2>not moving the discussion forward. Admittedly, I do =
not possess the</FONT>
<BR><FONT SIZE=3D2>technical knowledge that you have.</FONT>
</P>

<P><FONT SIZE=3D2>Your example is well put but is this really a digital =
signature or is it a</FONT>
<BR><FONT SIZE=3D2>set of bits (a mark) that has been affixed using the =
same technology known</FONT>
<BR><FONT SIZE=3D2>as digital signature technology.</FONT>
</P>

<P><FONT SIZE=3D2>You mention the difference between the 2 =
intents.&nbsp; I would be surprised, if</FONT>
<BR><FONT SIZE=3D2>anyone (other than the technically minded) even =
knows that a challenge</FONT>
<BR><FONT SIZE=3D2>response is even being &quot;signed&quot;.&nbsp; =
There is no intent at all in this case. It</FONT>
<BR><FONT SIZE=3D2>is the technology as designed that is effecting the =
response to the</FONT>
<BR><FONT SIZE=3D2>challenge.&nbsp; I am surprised that &quot;you&quot; =
sign authentication challenges, just</FONT>
<BR><FONT SIZE=3D2>for authentication purposes.&nbsp; Is it really a =
signature?&nbsp; Are you really</FONT>
<BR><FONT SIZE=3D2>signing the authentication challenge or is it the =
software on your machine</FONT>
<BR><FONT SIZE=3D2>effecting the response to the challenge? </FONT>
</P>

<P><FONT SIZE=3D2>To me this is not a signature.&nbsp; It may use =
digital signature technology but</FONT>
<BR><FONT SIZE=3D2>it is not a signature.&nbsp; This is probably the =
problem.&nbsp; It is the use of the</FONT>
<BR><FONT SIZE=3D2>word &quot;signature&quot; which is a technical term =
but has been used by the PKI</FONT>
<BR><FONT SIZE=3D2>community to cover a myriad of uses.&nbsp; Some uses =
of the term by the PKI</FONT>
<BR><FONT SIZE=3D2>community are confusing. </FONT>
</P>

<P><FONT SIZE=3D2>I also do not agree with your position that the NR =
bit can signal any intent</FONT>
<BR><FONT SIZE=3D2>either way.&nbsp; With respect, intent is =
ascertained at the time of signing.&nbsp; A</FONT>
<BR><FONT SIZE=3D2>certificate has nothing what so ever to do with =
signing.&nbsp; Its primary</FONT>
<BR><FONT SIZE=3D2>purpose is to identify a public key that corresponds =
to a private key that</FONT>
<BR><FONT SIZE=3D2>may be held by some previously identified person or =
entity.&nbsp; The public key</FONT>
<BR><FONT SIZE=3D2>is used to verify a digital signature that has =
supposedly been created using</FONT>
<BR><FONT SIZE=3D2>the corresponding private key.&nbsp; That is it as =
far as I understand it unless</FONT>
<BR><FONT SIZE=3D2>there is some other primary purpose that I do not =
know.&nbsp; I do not see the</FONT>
<BR><FONT SIZE=3D2>relationship between digitally signing a document =
and the contents of a</FONT>
<BR><FONT SIZE=3D2>certificate. Verification of the signature at some =
later time is a different</FONT>
<BR><FONT SIZE=3D2>issue which may involve the use of a certificate but =
this may not be so.</FONT>
</P>

<P><FONT SIZE=3D2>Adrian McCullagh</FONT>
<BR><FONT SIZE=3D2>Director of Electronic Commerce =
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Tel: [phone]</FONT>
<BR><FONT SIZE=3D2>Gadens Lawyers&nbsp; =
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Fax: [phone] =
5850&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; </FONT>
<BR><FONT SIZE=3D2>level 39</FONT>
<BR><FONT SIZE=3D2>Central Plaza 1</FONT>
<BR><FONT SIZE=3D2>345 Queen Street</FONT>
<BR><FONT SIZE=3D2>Brisbane Australia 4000</FONT>
</P>

<P><FONT SIZE=3D2>Ph. D. Candidate </FONT>
<BR><FONT SIZE=3D2>Thesis &quot;The Incorporation of Trust Strategies =
in Digital Signature</FONT>
<BR><FONT SIZE=3D2>Regimes for Elec. Comm.&quot;</FONT>
<BR><FONT SIZE=3D2>Information Security Research Centre</FONT>
<BR><FONT SIZE=3D2>Queensland University of Technology</FONT>
</P>
<BR>
<BR>

<P><FONT SIZE=3D2>-----Original Message-----</FONT>
<BR><FONT SIZE=3D2>From: Stephen Kent [<A =
HREF=3D"mailto:[e-mail]">mailto:[e-mail]</A>]</FONT>
<BR><FONT SIZE=3D2>Sent: Tuesday, July 18, 2000 10:00 AM</FONT>
<BR><FONT SIZE=3D2>To: Adrian McCullagh</FONT>
<BR><FONT SIZE=3D2>Cc: [e-mail]</FONT>
<BR><FONT SIZE=3D2>Subject: RE: Signing what you don't =
understand</FONT>
</P>
<BR>

<P><FONT SIZE=3D2>At 12:50 PM +1000 7/15/00, Adrian McCullagh =
wrote:</FONT>
<BR><FONT SIZE=3D2>&gt;Stephen</FONT>
<BR><FONT SIZE=3D2>&gt;</FONT>
<BR><FONT SIZE=3D2>&gt;I really do not understand your response.&nbsp; =
Why would anyone sign a document</FONT>
<BR><FONT SIZE=3D2>&gt;that they do not understand.&nbsp; It does not =
make sense.&nbsp; If I sent you a</FONT>
<BR><FONT SIZE=3D2>&gt;document written in Chinese and assume you can =
not read Chinese and at the</FONT>
<BR><FONT SIZE=3D2>&gt;same time I said just sign this - Why would you =
sign it.&nbsp; Now if you</FONT>
<BR><FONT SIZE=3D2>trusted</FONT>
<BR><FONT SIZE=3D2>&gt;me then you may sign it based upon the =
information about the document that</FONT>
<BR><FONT SIZE=3D2>I</FONT>
<BR><FONT SIZE=3D2>&gt;tell you.&nbsp; A classic case for =
Non-est-factum.&nbsp; But all the cases that I</FONT>
<BR><FONT SIZE=3D2>have</FONT>
<BR><FONT SIZE=3D2>&gt;read clearly rely upon some information provided =
by an Alleged trusted</FONT>
<BR><FONT SIZE=3D2>third</FONT>
<BR><FONT SIZE=3D2>&gt;party.&nbsp; Usually some relative.&nbsp; So =
without some external information being</FONT>
<BR><FONT SIZE=3D2>&gt;provided by a third party it is not as far as I =
can determine possible to</FONT>
<BR><FONT SIZE=3D2>&gt;rely upon non est factum.</FONT>
</P>

<P><FONT SIZE=3D2>Because we sign authentication challenges, just for =
authentication </FONT>
<BR><FONT SIZE=3D2>purposes, but not for NR purposes, it is prudent to =
distinguish </FONT>
<BR><FONT SIZE=3D2>between the two intents.&nbsp; Your comments seem to =
ignore this use of </FONT>
<BR><FONT SIZE=3D2>digital signature technology. One way of signalling =
intent is via the </FONT>
<BR><FONT SIZE=3D2>NR bit. Although it has been argued that having this =
bit set to True </FONT>
<BR><FONT SIZE=3D2>does not necessarily signal intent to sign for NR =
purposes, having it </FONT>
<BR><FONT SIZE=3D2>set to False certainly signals an intent to not be =
bound re NR.</FONT>
</P>

<P><FONT SIZE=3D2>(Your use of Latin and your e-mail =
&quot;signature&quot; suggests a legal, but </FONT>
<BR><FONT SIZE=3D2>perhaps not a technical background. We've also =
decided, after much </FONT>
<BR><FONT SIZE=3D2>debate, that PKIX deals with technical aspects of =
NR, not legal </FONT>
<BR><FONT SIZE=3D2>details that may vary based upon =
jurisdiction.)</FONT>
</P>

<P><FONT SIZE=3D2>&gt;Also what does a &quot;bit&quot; in a certificate =
got to do with non-repudiation.</FONT>
<BR><FONT SIZE=3D2>The</FONT>
<BR><FONT SIZE=3D2>&gt;commercial world and the law does not in my =
opinion support this position</FONT>
<BR><FONT SIZE=3D2>of</FONT>
<BR><FONT SIZE=3D2>&gt;yours.&nbsp; You appear to be on a path to =
re-engineering the entire commercial</FONT>
<BR><FONT SIZE=3D2>&gt;legal fabric and as such I with the greatest =
respect I do not&nbsp; believe that</FONT>
<BR><FONT SIZE=3D2>&gt;society and the law will buy into it.&nbsp; With =
out the commercial involvement</FONT>
<BR><FONT SIZE=3D2>&gt;PKI will not survive.</FONT>
</P>

<P><FONT SIZE=3D2>The position is not just mine.&nbsp; Sorry of you =
don't understand, or </FONT>
<BR><FONT SIZE=3D2>merely don't agree with the use of the NR bit, or =
its name, but we </FONT>
<BR><FONT SIZE=3D2>had this debate a while ago and we're not having it =
again.</FONT>
</P>

<P><FONT SIZE=3D2>&gt;</FONT>
<BR><FONT SIZE=3D2>&gt;I do not understand how - &quot;what you are =
proposing&quot; - will work in practical</FONT>
<BR><FONT SIZE=3D2>&gt;terms.</FONT>
</P>

<P><FONT SIZE=3D2>I'm not &quot;proposing,&quot; but I am citing =
existing Internet and ITU </FONT>
<BR><FONT SIZE=3D2>standards and the applicability to the question at =
hand.</FONT>
</P>

<P><FONT SIZE=3D2>Steve</FONT>
</P>

</BODY>
</HTML>
------_=_NextPart_001_01BFF0B5.F0B5DB20--


Received: from ietf.org (odin.ietf.org [132.151.1.176]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id DAA08508 for <[e-mail]>; Tue, 18 Jul 2000 03:33:30 -0700 (PDT)
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA13910; Tue, 18 Jul 2000 06:35:55 -0400 (EDT)
Message-Id: <[e-mail]>
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
Cc: [e-mail]
From: [e-mail]
Reply-to: [e-mail]
Subject: I-D ACTION:draft-ietf-pkix-laap-01.txt
Date: Tue, 18 Jul 2000 06:35:55 -0400
Sender: [e-mail]

--NextPart

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Public-Key Infrastructure (X.509) Working Group of the IETF.

	Title		: Limited AttributeCertificate Acquisition Protocol
	Author(s)	: S. Farrell, D. Chadwick
	Filename	: draft-ietf-pkix-laap-01.txt
	Pages		: 13
	Date		: 17-Jul-00
	
The PKIX working group is profiling the use of X.509 attribute
certificates. This document specifies a deliberately limited
protocol for requesting an attribute certificate from a server. It
is intended to be complementary to the use of LDAP for AC retrieval,
covering, for example, those cases where use of an LDAP server is
not suitable due to the type of authorization model being employed.
For many other cases, the use of LDAP is preferred.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-pkix-laap-01.txt

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-ietf-pkix-laap-01.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt


Internet-Drafts can also be obtained by e-mail.

Send a message to:
	[e-mail].
In the body type:
	"FILE /internet-drafts/draft-ietf-pkix-laap-01.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.
		
		
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"

--OtherAccess
Content-Type: Message/External-body;
	access-type="mail-server";
	server="[e-mail]"

Content-Type: text/plain
Content-ID:	<[e-mail]>

ENCODING mime
FILE /internet-drafts/draft-ietf-pkix-laap-01.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-pkix-laap-01.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID:	<[e-mail]>

--OtherAccess--

--NextPart--




Received: from ietf.org (odin.ietf.org [132.151.1.176]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id DAA08480 for <[e-mail]>; Tue, 18 Jul 2000 03:33:25 -0700 (PDT)
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA13862; Tue, 18 Jul 2000 06:35:50 -0400 (EDT)
Message-Id: <[e-mail]>
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
Cc: [e-mail]
From: [e-mail]
Reply-to: [e-mail]
Subject: I-D ACTION:draft-ietf-pkix-ac509prof-04.txt
Date: Tue, 18 Jul 2000 06:35:50 -0400
Sender: [e-mail]

--NextPart

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Public-Key Infrastructure (X.509) Working Group of the IETF.

	Title		: An Internet AttributeCertificate Profile for 
                          Authorization
	Author(s)	: S. Farrell, R. Housley
	Filename	: draft-ietf-pkix-ac509prof-04.txt
	Pages		: 37
	Date		: 17-Jul-00
	
This specification defines a profile for the use of X.509 Attribute
Certificates in Internet Protocols. Attribute certificates may be
used in a wide range of applications and environments covering a
broad spectrum of interoperability goals and a broader spectrum of
operational and assurance requirements. The goal of this document is
to establish a common baseline for generic applications requiring
broad interoperability as well as limited special purpose
requirements.  The profile places emphasis on attribute certificate
support for Internet electronic mail, IPSec, and WWW security
applications.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-pkix-ac509prof-04.txt

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-ietf-pkix-ac509prof-04.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt


Internet-Drafts can also be obtained by e-mail.

Send a message to:
	[e-mail].
In the body type:
	"FILE /internet-drafts/draft-ietf-pkix-ac509prof-04.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.
		
		
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"

--OtherAccess
Content-Type: Message/External-body;
	access-type="mail-server";
	server="[e-mail]"

Content-Type: text/plain
Content-ID:	<[e-mail]>

ENCODING mime
FILE /internet-drafts/draft-ietf-pkix-ac509prof-04.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-pkix-ac509prof-04.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID:	<[e-mail]>

--OtherAccess--

--NextPart--




Received: from mail.arabtrust.com (mail.arabtrust.com [216.247.149.19]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id BAA00677 for <[e-mail]>; Tue, 18 Jul 2000 01:20:36 -0700 (PDT)
Received: from jean [195.39.160.115] by mail.arabtrust.com (SMTPD32-6.00) id A47B344A00C0; Tue, 18 Jul 2000 04:25:31 -0400
From: "Jean Abraham" <[e-mail]>
To: <[e-mail]>
Subject: 
Date: Tue, 18 Jul 2000 11:21:54 +0300
Message-ID: <[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset="Windows-1252"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0)
X-MIMEOLE: Produced By Microsoft MimeOLE V5.00.2919.6600
Importance: Normal

Hello,

Can anyone tell me what language is the below written in?



CBCParameter ::= IV

    FBParameter ::= SEQUENCE {
        iv IV,
        numberOfBits NumberO
...........
.........
Thanks

Best Regards

Jean Abraham
Key Manager
Arabtrust
Tel: +965 - 5629645/721/827 Ext: 408
Fax: +965 - 5662164
[e-mail]


Received: from mail.arabtrust.com (mail.arabtrust.com [216.247.149.19]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id AAA28930 for <[e-mail]>; Tue, 18 Jul 2000 00:54:36 -0700 (PDT)
Received: from jean [195.39.160.115] by mail.arabtrust.com (SMTPD32-6.00) id AE5F443000EC; Tue, 18 Jul 2000 03:59:27 -0400
From: "Jean Abraham" <[e-mail]>
To: <[e-mail]>
Subject: 
Date: Tue, 18 Jul 2000 10:55:47 +0300
Message-ID: <[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset="Windows-1252"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0)
X-MIMEOLE: Produced By Microsoft MimeOLE V5.00.2919.6600
Importance: Normal

Hi,

Can anyone help me in finding out or anyone in sending me error codes of
luna tokens. (Luna CA and Luna 2)

Thanks

Best Regards

Jean Abraham
Key Manager
Arabtrust
Tel: +965 - 4849957 Ext: 12
Fax: +965 - 4838394
[e-mail]



Received: from hamster.gadens.com.au ([e-mail] [203.32.220.10]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id UAA10364 for <[e-mail]>; Mon, 17 Jul 2000 20:03:27 -0700 (PDT)
Received: from exchange.gadens.com.au ([10.1.8.3]) by hamster.gadens.com.au (8.9.3/8.9.3) with ESMTP id NAA99268; Tue, 18 Jul 2000 13:05:06 +1000 (EST) (envelope-from [e-mail])
Received: by exchange.gadens.com.au with Internet Mail Service (5.5.2650.21) id <3YWS62VJ>; Tue, 18 Jul 2000 13:08:28 +1000
Message-ID: <[e-mail]>
From: Adrian McCullagh <[e-mail]>
To: "'Stephen Kent'" <[e-mail]>
Cc: [e-mail]
Subject: RE: Signing what you don't understand
Date: Tue, 18 Jul 2000 13:08:27 +1000
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain; charset="iso-8859-1"

Stephen,

I do not want to get into an argument with you.  Yes I am a lawyer but I
also have a technical background so your suggestion otherwise, I thought was
not moving the discussion forward. Admittedly, I do not possess the
technical knowledge that you have.

Your example is well put but is this really a digital signature or is it a
set of bits (a mark) that has been affixed using the same technology known
as digital signature technology.

You mention the difference between the 2 intents.  I would be surprised, if
anyone (other than the technically minded) even knows that a challenge
response is even being "signed".  There is no intent at all in this case. It
is the technology as designed that is effecting the response to the
challenge.  I am surprised that "you" sign authentication challenges, just
for authentication purposes.  Is it really a signature?  Are you really
signing the authentication challenge or is it the software on your machine
effecting the response to the challenge? 

To me this is not a signature.  It may use digital signature technology but
it is not a signature.  This is probably the problem.  It is the use of the
word "signature" which is a technical term but has been used by the PKI
community to cover a myriad of uses.  Some uses of the term by the PKI
community are confusing. 

I also do not agree with your position that the NR bit can signal any intent
either way.  With respect, intent is ascertained at the time of signing.  A
certificate has nothing what so ever to do with signing.  Its primary
purpose is to identify a public key that corresponds to a private key that
may be held by some previously identified person or entity.  The public key
is used to verify a digital signature that has supposedly been created using
the corresponding private key.  That is it as far as I understand it unless
there is some other primary purpose that I do not know.  I do not see the
relationship between digitally signing a document and the contents of a
certificate. Verification of the signature at some later time is a different
issue which may involve the use of a certificate but this may not be so.

Adrian McCullagh
Director of Electronic Commerce		Tel: [phone]
Gadens Lawyers					Fax: [phone]	
level 39
Central Plaza 1
345 Queen Street
Brisbane Australia 4000

Ph. D. Candidate 
Thesis "The Incorporation of Trust Strategies in Digital Signature
Regimes for Elec. Comm."
Information Security Research Centre
Queensland University of Technology



-----Original Message-----
From: Stephen Kent [mailto:[e-mail]]
Sent: Tuesday, July 18, 2000 10:00 AM
To: Adrian McCullagh
Cc: [e-mail]
Subject: RE: Signing what you don't understand


At 12:50 PM +1000 7/15/00, Adrian McCullagh wrote:
>Stephen
>
>I really do not understand your response.  Why would anyone sign a document
>that they do not understand.  It does not make sense.  If I sent you a
>document written in Chinese and assume you can not read Chinese and at the
>same time I said just sign this - Why would you sign it.  Now if you
trusted
>me then you may sign it based upon the information about the document that
I
>tell you.  A classic case for Non-est-factum.  But all the cases that I
have
>read clearly rely upon some information provided by an Alleged trusted
third
>party.  Usually some relative.  So without some external information being
>provided by a third party it is not as far as I can determine possible to
>rely upon non est factum.

Because we sign authentication challenges, just for authentication 
purposes, but not for NR purposes, it is prudent to distinguish 
between the two intents.  Your comments seem to ignore this use of 
digital signature technology. One way of signalling intent is via the 
NR bit. Although it has been argued that having this bit set to True 
does not necessarily signal intent to sign for NR purposes, having it 
set to False certainly signals an intent to not be bound re NR.

(Your use of Latin and your e-mail "signature" suggests a legal, but 
perhaps not a technical background. We've also decided, after much 
debate, that PKIX deals with technical aspects of NR, not legal 
details that may vary based upon jurisdiction.)

>Also what does a "bit" in a certificate got to do with non-repudiation.
The
>commercial world and the law does not in my opinion support this position
of
>yours.  You appear to be on a path to re-engineering the entire commercial
>legal fabric and as such I with the greatest respect I do not  believe that
>society and the law will buy into it.  With out the commercial involvement
>PKI will not survive.

The position is not just mine.  Sorry of you don't understand, or 
merely don't agree with the use of the NR bit, or its name, but we 
had this debate a while ago and we're not having it again.

>
>I do not understand how - "what you are proposing" - will work in practical
>terms.

I'm not "proposing," but I am citing existing Internet and ITU 
standards and the applicability to the question at hand.

Steve


Received: from mail-fwd.verio-web.com ([161.58.16.59]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id TAA06887 for <[e-mail]>; Mon, 17 Jul 2000 19:14:55 -0700 (PDT)
From: [e-mail]
Received: from 161.58.117.181 (161.58.117.181) by mail11b.verio-web.com (RS ver 1.0.57s) with SMTP id 0519720; Mon, 17 Jul 2000 22:16:55 -0400 (EDT)
Received: (from rsalz@localhost) by os390.caveosystems.com (8.9.3/8.9.3) id WAA25184; Mon, 17 Jul 2000 22:16:00 -0400
Date: Mon, 17 Jul 2000 22:16:00 -0400
Message-Id: <[e-mail]>
To: [e-mail], [e-mail]
Subject: RE: Need for an XML based cert check protocol with RPP capability .
Cc: [e-mail]
X-Loop-Detect: 1

>Regardless of the structure of the PKI, path validation has to be done
>somewhere by someone the relying party trusts.  This is normally done by the
>relying party itself.  It can however be done by a party the Relying part
>trusts - Their bank for example.

In the general case, yes.

As I last understood it, the Identrus business rules said that the
relying party always asks its bank.  And all the background processing the
bank did was completely hidden by the bank.  Bank A never exposed
the *presence* of any other bank to its customers.

If your rules say "ask the bank" then there is no need to encode
this in a protocol.  Encode it in your code. :)

Second, Identrus is a closed PKI without cross-certification.
Identrus certs are only to be used among Identrus participants who
agree to follow Identrus rules.  That's a linch-pin for making the
whole risk-management aspect fly.

Have those rules changed?

If not, then I'm still stumped.  Could you provide a worked example?
(This might be falling outside the general interest of the list...)
	/r$


Received: from cam-mailer1.bbn.com (cam-mailer1.bbn.com [171.78.68.5]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id RAA27408 for <[e-mail]>; Mon, 17 Jul 2000 17:15:21 -0700 (PDT)
Received: from [128.33.238.30] (TC030.BBN.COM [128.33.238.30]) by cam-mailer1.bbn.com (8.8.8+Sun/8.8.8) with ESMTP id UAA07507; Mon, 17 Jul 2000 20:13:54 -0400 (EDT)
Mime-Version: 1.0
X-Sender: [e-mail] (Unverified)
Message-Id: <v04220803b5994d14f71c@[171.78.30.108]>
In-Reply-To:  <[e-mail]>
References: <[e-mail]>
Date: Mon, 17 Jul 2000 20:00:21 -0400
To: Adrian McCullagh <[e-mail]>
From: Stephen Kent <[e-mail]>
Subject: RE: Signing what you don't understand
Cc: [e-mail]
Content-Type: text/plain; charset="us-ascii" ; format="flowed"

At 12:50 PM +1000 7/15/00, Adrian McCullagh wrote:
>Stephen
>
>I really do not understand your response.  Why would anyone sign a document
>that they do not understand.  It does not make sense.  If I sent you a
>document written in Chinese and assume you can not read Chinese and at the
>same time I said just sign this - Why would you sign it.  Now if you trusted
>me then you may sign it based upon the information about the document that I
>tell you.  A classic case for Non-est-factum.  But all the cases that I have
>read clearly rely upon some information provided by an Alleged trusted third
>party.  Usually some relative.  So without some external information being
>provided by a third party it is not as far as I can determine possible to
>rely upon non est factum.

Because we sign authentication challenges, just for authentication 
purposes, but not for NR purposes, it is prudent to distinguish 
between the two intents.  Your comments seem to ignore this use of 
digital signature technology. One way of signalling intent is via the 
NR bit. Although it has been argued that having this bit set to True 
does not necessarily signal intent to sign for NR purposes, having it 
set to False certainly signals an intent to not be bound re NR.

(Your use of Latin and your e-mail "signature" suggests a legal, but 
perhaps not a technical background. We've also decided, after much 
debate, that PKIX deals with technical aspects of NR, not legal 
details that may vary based upon jurisdiction.)

>Also what does a "bit" in a certificate got to do with non-repudiation.  The
>commercial world and the law does not in my opinion support this position of
>yours.  You appear to be on a path to re-engineering the entire commercial
>legal fabric and as such I with the greatest respect I do not  believe that
>society and the law will buy into it.  With out the commercial involvement
>PKI will not survive.

The position is not just mine.  Sorry of you don't understand, or 
merely don't agree with the use of the NR bit, or its name, but we 
had this debate a while ago and we're not having it again.

>
>I do not understand how - "what you are proposing" - will work in practical
>terms.

I'm not "proposing," but I am citing existing Internet and ITU 
standards and the applicability to the question at hand.

Steve



Received: from cam-mailer1.bbn.com (cam-mailer1.bbn.com [171.78.68.5]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id RAA27159 for <[e-mail]>; Mon, 17 Jul 2000 17:11:46 -0700 (PDT)
Received: from [128.33.238.30] (TC030.BBN.COM [128.33.238.30]) by cam-mailer1.bbn.com (8.8.8+Sun/8.8.8) with ESMTP id UAA07522; Mon, 17 Jul 2000 20:14:07 -0400 (EDT)
Mime-Version: 1.0
X-Sender: [e-mail] (Unverified)
Message-Id: <v04220804b5994ed7610a@[171.78.30.108]>
In-Reply-To: <[e-mail]>
References: <[e-mail]>
Date: Mon, 17 Jul 2000 20:11:11 -0400
To: [e-mail]
From: Stephen Kent <[e-mail]>
Subject: Re: Signing what you don't understand
Cc: <[e-mail]>
Content-Type: text/plain; charset="us-ascii" ; format="flowed"

John,

>Anything in the certificate that's used to imply something about the intent
>behind a signature is asking for trouble, unless the specific certificate
>that a relying party should use is bound to the signature.  What's to
>prevent me from obtaining certificates from two different CAs, certifying
>the same key, but with different settings of the NR bit in the two
>certificates, and then using the certificate with the NR bit clear to
>repudiate a signature I originally represented as being non-repudiable
>using the other certificate?

Not necessarily. You seem to assume that a signer could escape 
responsibility for signing in an NR context by producing a 
certificate with the same public key but without the NR bit asserted. 
I don't subscribe to that assumption.  if I, as an RP, collect a cert 
associated with the user and it has the right public key and NR 
asserted, then why is my assertion of which cert was used in the 
transaction untenable?  A legitimate user should never put the same 
public key into two certs that differ in terms of this key usage bit 
(and probably not if they differ in other, significant ways).  If 
push came to shove and the user asserted that the NR-enabled cert was 
not really issued at his request, a check of CA records for POP could 
resolve the problem. [I assume that any CA issuing a cert with an NR 
bit enabled ought to insist on POP, but maybe that's my unwarranted 
assumption :-).]

>The only way that using anything in the certificate could work is if the
>specific certificate that I intend a relying party to use to verify the
>signature is somehow bound into the signature.  Binding a particular
>certificate to a signature has all sorts of other problems (e.g. do all my
>signatures become unverifiable when my certificate is renewed?), and would
>require a signature format change anyway, so why not simply assert the
>intent explicitly as part of the signature?

Based on my comments above, I'm not sure we need to perform this 
binding, but I agree with Denis's comments here, i.e., it's not 
infeasible and the persistence of the signature is divorced from the 
certificate lifetime by other mechanisms.

By the way, I'm not saying that a new format for signatures which are 
designed precisely for NR purposes with general purpose documents is 
a bad idea.  I just commented on what appeared to be a lack of good 
arguments for such a construct.  I agree that the ability to have a 
small token be able to understand such constructs could be valuable, 
even though we still face a lot of problems with regard to secure 
display of the contents of what is being signed.

Steve



Received: from blue.identrus.com ([216.213.93.121]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id QAA26408 for <[e-mail]>; Mon, 17 Jul 2000 16:40:35 -0700 (PDT)
Received: by blue.identrus.com with Internet Mail Service (5.5.2650.21) id <N9QAN1K5>; Mon, 17 Jul 2000 19:42:56 -0400
Message-ID: <[e-mail]>
From: Khaja Ahmed <[e-mail]>
To: "'Rich Salz '" <[e-mail]>
Cc: "'''[e-mail] ' ' '" <[e-mail]>
Subject: RE: Need for an XML based cert check protocol with RPP capability .
Date: Mon, 17 Jul 2000 19:42:54 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
List-Unsubscribe: mailto:[e-mail]?body=unsubscribe
Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01BFF048.BA8E6580"

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01BFF048.BA8E6580
Content-Type: text/plain;
	charset="iso-8859-1"

Regardless of the structure of the PKI, path validation has to be done
somewhere by someone the relying party trusts.  This is normally done by the
relying party itself.  It can however be done by a party the Relying part
trusts - Their bank for example.

The benefit of having path validation done at the bank is to off load the
relying party.  Two substantial and obvious benefits are:

1.) Decrease the computation burden on the relying party application -
possibly a web server.  Of course, one could argue just as easily
"distributed processing" is more efficient but when the dust settled the
decision was in favor of putting the burden on the bank.

2.) It was felt that by taking the burden of PKIX compliant path processing
off the shoulders of those developing applications for relying paries, we
would speed up adoption of the Identrus system.

Khaja

-----Original Message-----
From: Rich Salz
To: Khaja Ahmed
Cc: ''[e-mail] ' '
Sent: 7/17/00 2:26 PM
Subject: Re: Need for an XML based cert check protocol with RPP capability.

I'm still confused.  Identrus is a closed PKI, each customer speaks only
to its bank and banks speak to each other. There is no
cross-certification.
There is a single root, and a single path from between any two Identrus
participants.  Taking those things together, I still don't see how/why
RPP is necessary.

------_=_NextPart_001_01BFF048.BA8E6580
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Diso-8859-1">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
5.5.2650.12">
<TITLE>RE: Need for an XML based cert check protocol with RPP =
capability.</TITLE>
</HEAD>
<BODY>

<P><FONT SIZE=3D2>Regardless of the structure of the PKI, path =
validation has to be done somewhere by someone the relying party =
trusts.&nbsp; This is normally done by the relying party itself.&nbsp; =
It can however be done by a party the Relying part trusts - Their bank =
for example.</FONT></P>

<P><FONT SIZE=3D2>The benefit of having path validation done at the =
bank is to off load the relying party.&nbsp; Two substantial and =
obvious benefits are:</FONT></P>

<P><FONT SIZE=3D2>1.) Decrease the computation burden on the relying =
party application - possibly a web server.&nbsp; Of course, one could =
argue just as easily &quot;distributed processing&quot; is more =
efficient but when the dust settled the decision was in favor of =
putting the burden on the bank.</FONT></P>

<P><FONT SIZE=3D2>2.) It was felt that by taking the burden of PKIX =
compliant path processing off the shoulders of those developing =
applications for relying paries, we would speed up adoption of the =
Identrus system.</FONT></P>

<P><FONT SIZE=3D2>Khaja</FONT>
</P>

<P><FONT SIZE=3D2>-----Original Message-----</FONT>
<BR><FONT SIZE=3D2>From: Rich Salz</FONT>
<BR><FONT SIZE=3D2>To: Khaja Ahmed</FONT>
<BR><FONT SIZE=3D2>Cc: ''[e-mail] ' '</FONT>
<BR><FONT SIZE=3D2>Sent: 7/17/00 2:26 PM</FONT>
<BR><FONT SIZE=3D2>Subject: Re: Need for an XML based cert check =
protocol with RPP capability.</FONT>
</P>

<P><FONT SIZE=3D2>I'm still confused.&nbsp; Identrus is a closed PKI, =
each customer speaks only</FONT>
<BR><FONT SIZE=3D2>to its bank and banks speak to each other. There is =
no</FONT>
<BR><FONT SIZE=3D2>cross-certification.</FONT>
<BR><FONT SIZE=3D2>There is a single root, and a single path from =
between any two Identrus</FONT>
<BR><FONT SIZE=3D2>participants.&nbsp; Taking those things together, I =
still don't see how/why</FONT>
<BR><FONT SIZE=3D2>RPP is necessary.</FONT>
</P>

</BODY>
</HTML>
------_=_NextPart_001_01BFF048.BA8E6580--


Received: from blue.identrus.com ([216.213.93.121]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id QAA25840 for <[e-mail]>; Mon, 17 Jul 2000 16:16:49 -0700 (PDT)
Received: by blue.identrus.com with Internet Mail Service (5.5.2650.21) id <N9QAN1KV>; Mon, 17 Jul 2000 19:19:11 -0400
Message-ID: <[e-mail]>
From: Khaja Ahmed <[e-mail]>
To: "'Denis '" <[e-mail]>, Khaja Ahmed <[e-mail]>
Cc: "'''[e-mail] ' ' '" <[e-mail]>
Subject: RE: Need for an XML based cert check protocol with RPP capability .
Date: Mon, 17 Jul 2000 19:19:08 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
List-Unsubscribe: mailto:[e-mail]?body=unsubscribe
Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01BFF045.69078A20"

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01BFF045.69078A20
Content-Type: text/plain;
	charset="iso-8859-1"

Denis,

You certainly have thought through the scenario and are quite right in all
your observations.  Additional infomation below:


-----Original Message-----
From: Denis
>> 2.) Allows the banks to provide value add services beyond
>> certificate validation.  i.e. validation of the transaction
>> itself.  The thinking is that the relying party (in some
>> transactions) the seller doesn't simply want to know whether or
>> not the buyer's certificate is good.  He may want to know if she
>> is good for money, has the required funds/credit rating etc.

> ... but in that case some details of the transaction would need to
>be passed along on that protocol (this is not the case today).
>However, as soon as this is done, there are deep implications.

>Let us take an example: Let us assume that the request is for funds
>up to 100.000 $. Is the bank going to count down a credit line ?

For "transaction validation" as distinct from just certificate validation,
this is precisely the kind of hook(s) into financial systems that would be
needed.  Clearly banks have the ability to provide such services.  This is
really the sort of processing done with credit card and ATM card
transactions.  This is the true value of the Identrus system.

>If no, then 8 relying parties might be fooled because everything was
>nice for 2 such transactions, but not 10.

>If yes, then there is some count down, but then the requesters had
>better to be authenticated otherwise there would be some easy denial
>of service attacks.


Requestors are indeed authenticated.  All requests are to be signed.  We
have adopted xmldsig for such signatures.


>So what are your views on that topic ?

Regards,

Denis


------_=_NextPart_001_01BFF045.69078A20
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Diso-8859-1">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
5.5.2650.12">
<TITLE>RE: Need for an XML based cert check protocol with RPP =
capability.</TITLE>
</HEAD>
<BODY>

<P><FONT SIZE=3D2>Denis,</FONT>
</P>

<P><FONT SIZE=3D2>You certainly have thought through the scenario and =
are quite right in all your observations.&nbsp; Additional infomation =
below:</FONT></P>
<BR>

<P><FONT SIZE=3D2>-----Original Message-----</FONT>
<BR><FONT SIZE=3D2>From: Denis</FONT>
<BR><FONT SIZE=3D2>&gt;&gt; 2.) Allows the banks to provide value add =
services beyond</FONT>
<BR><FONT SIZE=3D2>&gt;&gt; certificate validation.&nbsp; i.e. =
validation of the transaction</FONT>
<BR><FONT SIZE=3D2>&gt;&gt; itself.&nbsp; The thinking is that the =
relying party (in some</FONT>
<BR><FONT SIZE=3D2>&gt;&gt; transactions) the seller doesn't simply =
want to know whether or</FONT>
<BR><FONT SIZE=3D2>&gt;&gt; not the buyer's certificate is good.&nbsp; =
He may want to know if she</FONT>
<BR><FONT SIZE=3D2>&gt;&gt; is good for money, has the required =
funds/credit rating etc.</FONT>
</P>

<P><FONT SIZE=3D2>&gt; ... but in that case some details of the =
transaction would need to</FONT>
<BR><FONT SIZE=3D2>&gt;be passed along on that protocol (this is not =
the case today).</FONT>
<BR><FONT SIZE=3D2>&gt;However, as soon as this is done, there are deep =
implications.</FONT>
</P>

<P><FONT SIZE=3D2>&gt;Let us take an example: Let us assume that the =
request is for funds</FONT>
<BR><FONT SIZE=3D2>&gt;up to 100.000 $. Is the bank going to count down =
a credit line ?</FONT>
</P>

<P><FONT SIZE=3D2>For &quot;transaction validation&quot; as distinct =
from just certificate validation, this is precisely the kind of hook(s) =
into financial systems that would be needed.&nbsp; Clearly banks have =
the ability to provide such services.&nbsp; This is really the sort of =
processing done with credit card and ATM card transactions.&nbsp; This =
is the true value of the Identrus system.</FONT></P>

<P><FONT SIZE=3D2>&gt;If no, then 8 relying parties might be fooled =
because everything was</FONT>
<BR><FONT SIZE=3D2>&gt;nice for 2 such transactions, but not 10.</FONT>
</P>

<P><FONT SIZE=3D2>&gt;If yes, then there is some count down, but then =
the requesters had</FONT>
<BR><FONT SIZE=3D2>&gt;better to be authenticated otherwise there would =
be some easy denial</FONT>
<BR><FONT SIZE=3D2>&gt;of service attacks.</FONT>
</P>
<BR>

<P><FONT SIZE=3D2>Requestors are indeed authenticated.&nbsp; All =
requests are to be signed.&nbsp; We have adopted xmldsig for such =
signatures.</FONT>
</P>
<BR>

<P><FONT SIZE=3D2>&gt;So what are your views on that topic ?</FONT>
</P>

<P><FONT SIZE=3D2>Regards,</FONT>
</P>

<P><FONT SIZE=3D2>Denis</FONT>
</P>

</BODY>
</HTML>
------_=_NextPart_001_01BFF045.69078A20--


Received: from sothmxs01.entrust.com (gatekeeper.entrust.com [204.101.128.170]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id NAA23581 for <[e-mail]>; Mon, 17 Jul 2000 13:59:39 -0700 (PDT)
Received: by sothmxs01.entrust.com with Internet Mail Service (5.5.2650.21) id <34W52P54>; Mon, 17 Jul 2000 17:01:31 -0400
Message-ID: <[e-mail]>
From: Carlisle Adams <[e-mail]>
To: [e-mail]
Subject: RE: I-D ACTION:draft-ietf-pkix-rfc2510bis-01.txt
Date: Mon, 17 Jul 2000 17:00:01 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain

Hi all,

> ----------
> From: 	[e-mail][SMTP:[e-mail]]
> Reply To: 	[e-mail]
> Sent: 	Monday, July 17, 2000 6:42 AM
> Cc: 	[e-mail]
> Subject: 	I-D ACTION:draft-ietf-pkix-rfc2510bis-01.txt
> 
> A New Internet-Draft is available from the on-line Internet-Drafts
> directories.
> This draft is a work item of the Public-Key Infrastructure (X.509) Working
> Group of the IETF.
> 
> 	Title		: Internet X.509 Public Key Infrastructure
> Certificate 
>                           Management Protocols
> 	Author(s)	: C. Adams, S. Farrell
> 	Filename	: draft-ietf-pkix-rfc2510bis-01.txt
> 	Pages		: 87
> 	Date		: 14-Jul-00
> 	
> A URL for this Internet-Draft is:
> http://www.ietf.org/internet-drafts/draft-ietf-pkix-rfc2510bis-01.txt
 

The following changes were made in going from the 00.txt version to the
01.txt version:

p.20:  defined PKIMessages as a SEQUENCE OF PKIMessage (also in ASN.1
module, p.73);

p.22:  changed SHOULD to MAY in PKIFreeText comment (also in ASN.1 module,
p.74) -- request from Paul Hoffman;

p.27:  changed NestedMessageContent to be PKIMessages, rather than
PKIMessage, and added text explaining why (i.e., to allow for batching
requests at an RA) (also in ASN.1 module, p.75, and see also p.81);

p.30:  added error code 23 -- notAuthorized (forgot to change this in the
ASN.1 module, but this can be done later...);

p.32:  added explanatory text regarding inclusion of a private key in POP --
requested on caTalk list;

p.33:  added explanatory sentence regarding CertHash -- requested on caTalk
list;

p.37:  added pointer to Appendix D for comment on privateKey encoding (also
on p.69 and p.79);

p.42:  added pointer to CertHash discussion in Section 3.2.8;

p.53:  added reference to a more recent version of PKCS #11;

p.72:  changed id-mod-cmp2000 from 14 to 16 (the correct value according to
Russ' official list of PKIX OIDs);

p.83:  added discussion of encoding for privateKey -- requested by Francois
Rousseau.


A relatively small set of quite minor changes.  Quite encouraging given all
the interop testing that has occurred (even as recently as last week)...!
Thanks to all of you who gave me input.

Carlisle.



Received: from edelweb.fr (edelweb.fr [193.51.12.16]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id NAA22850 for <[e-mail]>; Mon, 17 Jul 2000 13:14:25 -0700 (PDT)
Received: from champagne.edelweb.fr (localhost.edelweb.fr [127.0.0.1]) by edelweb.fr with ESMTP id WAA06381; Mon, 17 Jul 2000 22:16:42 +0200 (MET DST)
Received: from champagne.edelweb.fr (champagne.edelweb.fr [193.51.14.161]) by edelweb.fr (nospam/1.3); Mon, 17 Jul 2000 22:16:42 +0200 (MET DST)
Received: from emeriau.edelweb.fr (emeriau.edelweb.fr [193.51.14.5]) by champagne.edelweb.fr (8.7.6/8.6.6) with ESMTP id WAA12182; Mon, 17 Jul 2000 22:16:41 +0200 (MET DST)
From: Peter Sylvester <[e-mail]>
Received: (sylvest@localhost) by emeriau.edelweb.fr (8.7.6/8.6.6) id WAA24924; Mon, 17 Jul 2000 22:16:41 +0200 (MET DST)
Date: Mon, 17 Jul 2000 22:16:41 +0200 (MET DST)
Message-Id: <[e-mail]>
To: [e-mail], [e-mail]
Subject: RE: Need for an XML based cert check protocol with RPP capability .
Cc: [e-mail]

> 
> >I don't understand why RPP is necessary in the Identrus model.
> >You only need to set up peering relationships among banks, as long as
> >each cert has a service locator of some type.
> 
> 
> The reasoning behind this is that it makes it:
> 
> 1.) Easier to build relying party applications because you dont burden them
> with RFC.2459 section 6.1 compliant path processing.
> 
> and
> 
> 2.) Allows the banks to provide value add services beyond certificate
> validation.  i.e. validation of the transaction itself.  The thinking is
> that the relying party (in some transactions) the seller doesn't simply want
> to know whether or not the buyer's certificate is good.  He may want to know
> if she is good for money, has the required funds/credit rating etc.
> 

If I look at the models that are visible in the identrus web server:

One type of transactions seems to be something like:

Customer A  creates a 'money transfer statement' and presents it
to merchant B. The statement is 'secured' by the customer in a way
that can be verified by customer A's bank, e.g. by a signature, and
the statement contains sufficient information to allow an identrus
participating bank to find customer A's bank (at least to identrus);

Merchant B presents the statement (the whole one) to its bank Bbank
in order to get an assertion. 

Merchant B asks knows how to extract the identification data from the
statement and asks identrus about where is Abank.

Bbank then asks Abank to validate the statement. 

Abank answers with an assertion. Bbank adds its own signature and
returns assertion to merchant. 

If this is one of the models, then I do not see whether B should
be required to know much more than the ability of validating the
signature of its own banking server, or better, the ability of 
validating the assertion of Bbank.

Peter Sylvester




Received: from sothmxs01.entrust.com (gatekeeper.entrust.com [204.101.128.170]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id LAA21472 for <[e-mail]>; Mon, 17 Jul 2000 11:53:26 -0700 (PDT)
Received: by sothmxs01.entrust.com with Internet Mail Service (5.5.2650.21) id <34W52N6X>; Mon, 17 Jul 2000 14:55:18 -0400
Message-ID: <[e-mail]>
From: Carlisle Adams <[e-mail]>
To: "'[e-mail]'" <[e-mail]>
Cc: [e-mail], [e-mail]
Subject: RE: Re: CRMF encValue Field
Date: Mon, 17 Jul 2000 14:53:48 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain

Hi Francois,

> ----------
> From:
> [e-mail][SMTP:[e-mail]]
> Sent: 	Monday, July 17, 2000 11:55 AM
> To: 	[e-mail]
> Cc: 	[e-mail]
> Subject: 	RE: Re: CRMF encValue Field
> 
> Hi Stephen, 
> 
> I have noted that the recently published July version of RFC2510bis now
> contains a note in Appendix D on "RFC 2511 Clarifications" about this
> particular issue, however an exception was added for the Diffie-Hellman
> algorithm OID and parameters whereas those defined in Appendix B2 of this
> specification (i.e. RFC2510bis) MUST be used instead of the OID and
> parameters defined in PKCS#11. Although I understand that this exception
> was necessary since PKCS#11 currently only supports the PKCS#3 flavour of
> Diffie-Hellman whereas Appendix B2 of RFC2510bis is about the ANSI X9.42
> flavour of Diffie-Hellman, this should have been mentioned in this
> clarification.
 
I suppose this could have been mentioned, but it seemed pretty unnecessary.
Wouldn't people naturally expect the OIDs in this field to be consistent
with the OIDs defined in Appendix B2?  I doubt that there's much potential
for confusion here, so extra wording for clarification seems redundant.

> In addition, this same clarification indicates that in this case, the
> intendedAlg field is unnecessary (since this information is included in
> PrivateKeyInfo) and MUST be omitted. However, the algorithm identifier
> field within the PrivateKeyInfo is encrypted, which means that the
> "EncryptedValue" type would not contain any information in the clear about
> the OID of the private key that it is carrying. Was this your intend,
> please clarify? I also understand that including the intendedAlg field
> would duplicate the occurrence of the parameters field, since the syntax
> of the "AlgorithmIdentifier" type also contains a "parameters" field,
> however by still indicating the algorithm OID, but forcing the
> "parameters" field within the intendedAlg field to be NULL would allow the
> "EncryptedValue" type to indicate what is the OID of the private key that
> it is carrying, but not duplicate the parameters field. Wouldn't this
> approach be better?
 
No, this approach doesn't strike me as particularly better.  It seems like a
real kludge to include an AlgId for the same thing twice, but to specify (in
commentary) that the parameters should be NULL for one of these and non-NULL
(i.e., present) for the other.  This reduces clarity for the
reader/implementer and may run in to trouble with some compilers that are
expecting actual parameter values.

As for fact that the AlgId in PrivateKeyInfo is encrypted, why is this a
concern?  Does the receiver need to know this prior to decryption?

Carlisle.



Received: from odin2.bull.net (odin2.bull.net [192.90.70.84]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id LAA20945 for <[e-mail]>; Mon, 17 Jul 2000 11:38:58 -0700 (PDT)
Received: from lvt-mail.frlv.bull.fr (lvt-mail.frlv.bull.fr [129.184.62.223]) by odin2.bull.net (8.9.2/8.9.1) with ESMTP id UAA10672; Mon, 17 Jul 2000 20:40:33 +0200
Received: from bull.net (fradint10.bull.fr [129.181.85.10]) by lvt-mail.frlv.bull.fr (8.9.2/8.9.1) with ESMTP id UAA28900; Mon, 17 Jul 2000 20:40:36 +0200
Message-ID: <[e-mail]>
Date: Mon, 17 Jul 2000 20:38:09 +0200
From: Denis <[e-mail]>
X-Mailer: Mozilla 4.5 [fr] (Win98; I)
X-Accept-Language: fr
MIME-Version: 1.0
To: [e-mail]
CC: Stephen Kent <[e-mail]>, [e-mail], [e-mail]
Subject: Re: Signing what you don't understand
References: <[e-mail]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

John,

See my response  below.

> Anything in the certificate that's used to imply something about the intent
> behind a signature is asking for trouble, unless the specific certificate
> that a relying party should use is bound to the signature.  What's to
> prevent me from obtaining certificates from two different CAs, certifying
> the same key, but with different settings of the NR bit in the two
> certificates, and then using the certificate with the NR bit clear to
> repudiate a signature I originally represented as being non-repudiable
> using the other certificate?

Nothing can *prevent* someone to do this, but that someone should be
warned about the precautions to be used if this is done.


> The only way that using anything in the certificate could work is if the
> specific certificate that I intend a relying party to use to verify the
> signature is somehow bound into the signature.  Binding a particular
> certificate to a signature has all sorts of other problems

I do not think so. It has major benefits.

> (e.g. do all my
> signatures become unverifiable when my certificate is renewed?),

Very, *very* briefly, time-stamped signatures may be proven to be
valid long after the end of the validity period of the signer
certificate.

> and would
> require a signature format change anyway, so why not simply assert the
> intent explicitly as part of the signature?

It is not a "change". It has to do with the right use of a signature
format, that binds the identifier of the certificate to the digital
signature. S/MIME has provisions for this. The recently posted draft
to the S/MIME working on "Electronic Signature Formats" uses the
same feature.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-smime-esformats-01.txt

Denis

> John
>
> Stephen Kent <[e-mail]> on 07/13/2000 09:48:56 AM
>
> To:   <[e-mail]>
> cc:   <[e-mail]>
> Subject:  Re: Signing what you don't understand
>
> Denis,
>
> >The most important point of my previous message was buried under a pile of
> >other stuff, so I am repeating it here:
> >
> >
> >It is my proposal that a signature format is designed which will allow an
> >entity to say: "I signed this data, but I didn't understand what I signed.
> >You are free to use this signature as proof that I possess a certain
> private
> >key, but this is also the only purpose for which this signature can be
> >used."
>
> We have had an analogous debate on this list last year.  This is one
> motivation for the use of the non-repudiation bit in certificates,
> i.e., if this bit is NOT asserted, one can reasonably interpret the
> signature as not binding.  This does not require a change to the
> signing format, but rather appropriate use of key usage bits in
> certificates. As others have pointed out, the preferred way to
> represent the distinction between binding and non-binding signatures
> is via flags in certificates, e.g., key usage, cert policy, etc.
>
> Steve



Received: from odin2.bull.net (odin2.bull.net [192.90.70.84]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id LAA20929 for <[e-mail]>; Mon, 17 Jul 2000 11:38:49 -0700 (PDT)
Received: from lvt-mail.frlv.bull.fr (lvt-mail.frlv.bull.fr [129.184.62.223]) by odin2.bull.net (8.9.2/8.9.1) with ESMTP id UAA31386; Mon, 17 Jul 2000 20:40:29 +0200
Received: from bull.net (fradint10.bull.fr [129.181.85.10]) by lvt-mail.frlv.bull.fr (8.9.2/8.9.1) with ESMTP id UAA28898; Mon, 17 Jul 2000 20:40:33 +0200
Message-ID: <[e-mail]>
Date: Mon, 17 Jul 2000 20:37:48 +0200
From: Denis <[e-mail]>
X-Mailer: Mozilla 4.5 [fr] (Win98; I)
X-Accept-Language: fr
MIME-Version: 1.0
To: Khaja Ahmed <[e-mail]>
CC: "''[e-mail] ' '" <[e-mail]>
Subject: Re: Need for an XML based cert check protocol with RPP capability.
References: <[e-mail]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Khaja,

See my comments below.

> > I don't understand why RPP is necessary in the Identrus model.
> > You only need to set up peering relationships among banks, as
> > long as each cert has a service locator of some type.

> The reasoning behind this is that it makes it:

> 1.) Easier to build relying party applications because you dont
> burden them with RFC.2459 section 6.1 compliant path processing.

True.

> and
>
> 2.) Allows the banks to provide value add services beyond
> certificate validation.  i.e. validation of the transaction
> itself.  The thinking is that the relying party (in some
> transactions) the seller doesn't simply want to know whether or
> not the buyer's certificate is good.  He may want to know if she
> is good for money, has the required funds/credit rating etc.

 ... but in that case some details of the transaction would need to
be passed along on that protocol (this is not the case today).
However, as soon as this is done, there are deep implications.

Let us take an example: Let us assume that the request is for funds
up to 100.000 $. Is the bank going to count down a credit line ?

If no, then 8 relying parties might be fooled because everything was
nice for 2 such transactions, but not 10.

If yes, then there is some count down, but then the requesters had
better to be authenticated otherwise there would be some easy denial
of service attacks.

So what are your views on that topic ?

Regards,

Denis




Received: from mail-fwd.verio-web.com (mail11a.verio-web.com [161.58.16.57]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id LAA20583 for <[e-mail]>; Mon, 17 Jul 2000 11:24:52 -0700 (PDT)
Received: from 161.58.117.181 (161.58.117.181) by mail11a.verio-web.com (RS ver 1.0.57s) with SMTP id 0594954; Mon, 17 Jul 2000 14:27:04 -0400 (EDT)
Sender: rsalz
Message-ID: <[e-mail]>
Date: Mon, 17 Jul 2000 14:26:06 -0400
From: Rich Salz <[e-mail]>
X-Mailer: Mozilla 4.72 [en] (X11; U; Linux 2.2.14-5.0 i686)
X-Accept-Language: en
MIME-Version: 1.0
To: Khaja Ahmed <[e-mail]>
CC: "''[e-mail] ' '" <[e-mail]>
Subject: Re: Need for an XML based cert check protocol with RPP capability.
References: <[e-mail]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
X-Loop-Detect: 1

I'm still confused.  Identrus is a closed PKI, each customer speaks only
to its bank and banks speak to each other. There is no
cross-certification.
There is a single root, and a single path from between any two Identrus
participants.  Taking those things together, I still don't see how/why
RPP is necessary.


Received: from balinese.baltimore.ie ([e-mail] [194.125.215.8]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id LAA20135 for <[e-mail]>; Mon, 17 Jul 2000 11:03:09 -0700 (PDT)
Received: by balinese.baltimore.ie; id TAA27679; Mon, 17 Jul 2000 19:05:31 +0100 (GMT/IST)
Received: from bobcat.baltimore.ie(192.168.20.10) by balinese.baltimore.ie via smap (V4.2) id xma027626; Mon, 17 Jul 00 19:05:00 +0100
Received: from baltimore.ie (lease216-21.baltimore.ie [192.168.21.216]) by bobcat.baltimore.ie (8.9.3/8.9.3) with ESMTP id TAA05161; Mon, 17 Jul 2000 19:05:00 +0100
Message-ID: <[e-mail]>
Date: Mon, 17 Jul 2000 19:05:22 +0100
From: Stephen Farrell <[e-mail]>
Reply-To: [e-mail]
Organization: Baltimore Technologies Ltd.
X-Mailer: Mozilla 4.72 [en] (WinNT; U)
X-Accept-Language: en
MIME-Version: 1.0
To: [e-mail]
CC: [e-mail], xme <[e-mail]>
Subject: Re: CRMF encValue Field
References: <[e-mail]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Hi Francois,

Why don't you propose some changes to the text if you think additional
clarficiation is needed?

Stephen.

(BTW: Your mail broke my brain's long-sentence-parser:-)


-- 
____________________________________________________________
Stephen Farrell         				   
Baltimore Technologies,   tel: (direct line) [phone]
61 Fitzwilliam Lane,                    fax: [phone]
Dublin 2.                mailto:[e-mail]
Ireland                             http://www.baltimore.com


Received: from balinese.baltimore.ie ([e-mail] [194.125.215.8]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id KAA19632 for <[e-mail]>; Mon, 17 Jul 2000 10:41:09 -0700 (PDT)
Received: by balinese.baltimore.ie; id SAA25234; Mon, 17 Jul 2000 18:43:31 +0100 (GMT/IST)
Received: from bobcat.baltimore.ie(192.168.20.10) by balinese.baltimore.ie via smap (V4.2) id xma025169; Mon, 17 Jul 00 18:42:43 +0100
Received: from baltimore.ie (lease216-21.baltimore.ie [192.168.21.216]) by bobcat.baltimore.ie (8.9.3/8.9.3) with ESMTP id SAA04699; Mon, 17 Jul 2000 18:42:42 +0100
Message-ID: <[e-mail]>
Date: Mon, 17 Jul 2000 18:43:05 +0100
From: Stephen Farrell <[e-mail]>
Reply-To: [e-mail]
Organization: Baltimore Technologies Ltd.
X-Mailer: Mozilla 4.72 [en] (WinNT; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Khaja Ahmed <[e-mail]>
CC: "''[e-mail] ' '" <[e-mail]>, xme <[e-mail]>
Subject: Re: Need for an XML based cert check protocol with RPP capability.
References: <[e-mail]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Khaja,

> 2.) Allows the banks to provide value add services beyond certificate 
> validation.  i.e. validation of the transaction itself.  The thinking 
> is that the relying party (in some transactions) the seller doesn't simply 
> want to know whether or not the buyer's certificate is good.  He may want 
> to know if she is good for money, has the required funds/credit rating 
> etc.

This is the where I think you get outside PKIX's scope (in fact, 
I'd argue, outside PKI's scope). I don't believe that either OCSP-X or 
SCVP is, or should be, a suitable protocol for carrying this application 
specific stuff. Sounds to me a bit like "if all you've got is a hammer, 
the whole world's a nail...", which I wouldn't consider a good basis
for designing protocols. (Even though, in Baltimore's case, one of the 
things we do have is a thumping big PKI hammer:-) Of course, pragmatism 
may dictate otherwise for what I'd think will be a relatively short-ish 
period.

Having said that, some types of RPP are in scope of PKIX, and do 
overlap with your #2 above. That is, I think that it is a real 
requirement in lots of environments, (including yours), to be able 
to carry RPP requests/responses inside other protocols, like the 
XML one you posit.

So, my personal answer to your original question would be that 
SCVP is not the protocol you're looking for (and neither is OCSP-X,
before someone asks!).

Stephen.

-- 
____________________________________________________________
Stephen Farrell         				   
Baltimore Technologies,   tel: (direct line) [phone]
61 Fitzwilliam Lane,                    fax: [phone]
Dublin 2.                mailto:[e-mail]
Ireland                             http://www.baltimore.com


Received: from ntserver2.chrysalis-its.com ([209.47.245.163]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id KAA19390 for <[e-mail]>; Mon, 17 Jul 2000 10:36:45 -0700 (PDT)
From: [e-mail]
Received: by NTSERVER2 with Internet Mail Service (5.5.2650.21) id <36RJCYNM>; Mon, 17 Jul 2000 13:39:48 -0400
Message-ID: <[e-mail]>
To: [e-mail]
Cc: [e-mail]
Subject: RE: Signing what you don't understand
Date: Mon, 17 Jul 2000 13:39:41 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01BFF016.00C24D46"

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01BFF016.00C24D46
Content-Type: text/plain;
	charset="iso-8859-1"

John,

This why the Internet-Draft at
http://www.ietf.org/internet-drafts/draft-ietf-smime-esformats-00.txt
mandates the use of the "ESS signing certificate" attribute from RFC2634 to
bind the certificate and public key that a relying party MUST use to verify
a digital signature.

Francois

-----Original Message-----
From: [e-mail] [mailto:[e-mail]]
Sent: Monday, July 17, 2000 10:21 AM
To: Stephen Kent
Cc: [e-mail]; [e-mail]
Subject: Re: Signing what you don't understand

Anything in the certificate that's used to imply something about the intent
behind a signature is asking for trouble, unless the specific certificate
that a relying party should use is bound to the signature.  What's to
prevent me from obtaining certificates from two different CAs, certifying
the same key, but with different settings of the NR bit in the two
certificates, and then using the certificate with the NR bit clear to
repudiate a signature I originally represented as being non-repudiable
using the other certificate?

The only way that using anything in the certificate could work is if the
specific certificate that I intend a relying party to use to verify the
signature is somehow bound into the signature.  Binding a particular
certificate to a signature has all sorts of other problems (e.g. do all my
signatures become unverifiable when my certificate is renewed?), and would
require a signature format change anyway, so why not simply assert the
intent explicitly as part of the signature?

John





Stephen Kent <[e-mail]> on 07/13/2000 09:48:56 AM

To:   <[e-mail]>
cc:   <[e-mail]>
Subject:  Re: Signing what you don't understand


Denis,

>The most important point of my previous message was buried under a pile of
>other stuff, so I am repeating it here:
>
>
>It is my proposal that a signature format is designed which will allow an
>entity to say: "I signed this data, but I didn't understand what I signed.
>You are free to use this signature as proof that I possess a certain
private
>key, but this is also the only purpose for which this signature can be
>used."

We have had an analogous debate on this list last year.  This is one
motivation for the use of the non-repudiation bit in certificates,
i.e., if this bit is NOT asserted, one can reasonably interpret the
signature as not binding.  This does not require a change to the
signing format, but rather appropriate use of key usage bits in
certificates. As others have pointed out, the preferred way to
represent the distinction between binding and non-binding signatures
is via flags in certificates, e.g., key usage, cert policy, etc.

Steve





------_=_NextPart_001_01BFF016.00C24D46
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Diso-8859-1">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
5.5.2650.12">
<TITLE>RE: Signing what you don't understand</TITLE>
</HEAD>
<BODY>

<P><FONT SIZE=3D2>John,</FONT>
</P>

<P><FONT SIZE=3D2>This why the Internet-Draft at</FONT>
<BR><FONT SIZE=3D2><A =
HREF=3D"http://www.ietf.org/internet-drafts/draft-ietf-smime-esformats-0=
0.txt" =
TARGET=3D"_blank">http://www.ietf.org/internet-drafts/draft-ietf-smime-e=
sformats-00.txt</A> mandates the use of the &quot;ESS signing =
certificate&quot; attribute from RFC2634 to bind the certificate and =
public key that a relying party MUST use to verify a digital =
signature.</FONT></P>

<P><FONT SIZE=3D2>Francois</FONT>
</P>

<P><FONT SIZE=3D2>-----Original Message-----</FONT>
<BR><FONT SIZE=3D2>From: [e-mail] [<A =
HREF=3D"mailto:[e-mail]">mailto:[e-mail]</A>]</FONT>=

<BR><FONT SIZE=3D2>Sent: Monday, July 17, 2000 10:21 AM</FONT>
<BR><FONT SIZE=3D2>To: Stephen Kent</FONT>
<BR><FONT SIZE=3D2>Cc: [e-mail]; =
[e-mail]</FONT>
<BR><FONT SIZE=3D2>Subject: Re: Signing what you don't =
understand</FONT>
</P>

<P><FONT SIZE=3D2>Anything in the certificate that's used to imply =
something about the intent</FONT>
<BR><FONT SIZE=3D2>behind a signature is asking for trouble, unless the =
specific certificate</FONT>
<BR><FONT SIZE=3D2>that a relying party should use is bound to the =
signature.&nbsp; What's to</FONT>
<BR><FONT SIZE=3D2>prevent me from obtaining certificates from two =
different CAs, certifying</FONT>
<BR><FONT SIZE=3D2>the same key, but with different settings of the NR =
bit in the two</FONT>
<BR><FONT SIZE=3D2>certificates, and then using the certificate with =
the NR bit clear to</FONT>
<BR><FONT SIZE=3D2>repudiate a signature I originally represented as =
being non-repudiable</FONT>
<BR><FONT SIZE=3D2>using the other certificate?</FONT>
</P>

<P><FONT SIZE=3D2>The only way that using anything in the certificate =
could work is if the</FONT>
<BR><FONT SIZE=3D2>specific certificate that I intend a relying party =
to use to verify the</FONT>
<BR><FONT SIZE=3D2>signature is somehow bound into the signature.&nbsp; =
Binding a particular</FONT>
<BR><FONT SIZE=3D2>certificate to a signature has all sorts of other =
problems (e.g. do all my</FONT>
<BR><FONT SIZE=3D2>signatures become unverifiable when my certificate =
is renewed?), and would</FONT>
<BR><FONT SIZE=3D2>require a signature format change anyway, so why not =
simply assert the</FONT>
<BR><FONT SIZE=3D2>intent explicitly as part of the signature?</FONT>
</P>

<P><FONT SIZE=3D2>John</FONT>
</P>
<BR>
<BR>
<BR>
<BR>

<P><FONT SIZE=3D2>Stephen Kent &lt;[e-mail]&gt; on 07/13/2000 =
09:48:56 AM</FONT>
</P>

<P><FONT SIZE=3D2>To:&nbsp;&nbsp; =
&lt;[e-mail]&gt;</FONT>
<BR><FONT SIZE=3D2>cc:&nbsp;&nbsp; &lt;[e-mail]&gt;</FONT>
<BR><FONT SIZE=3D2>Subject:&nbsp; Re: Signing what you don't =
understand</FONT>
</P>
<BR>

<P><FONT SIZE=3D2>Denis,</FONT>
</P>

<P><FONT SIZE=3D2>&gt;The most important point of my previous message =
was buried under a pile of</FONT>
<BR><FONT SIZE=3D2>&gt;other stuff, so I am repeating it here:</FONT>
<BR><FONT SIZE=3D2>&gt;</FONT>
<BR><FONT SIZE=3D2>&gt;</FONT>
<BR><FONT SIZE=3D2>&gt;It is my proposal that a signature format is =
designed which will allow an</FONT>
<BR><FONT SIZE=3D2>&gt;entity to say: &quot;I signed this data, but I =
didn't understand what I signed.</FONT>
<BR><FONT SIZE=3D2>&gt;You are free to use this signature as proof that =
I possess a certain</FONT>
<BR><FONT SIZE=3D2>private</FONT>
<BR><FONT SIZE=3D2>&gt;key, but this is also the only purpose for which =
this signature can be</FONT>
<BR><FONT SIZE=3D2>&gt;used.&quot;</FONT>
</P>

<P><FONT SIZE=3D2>We have had an analogous debate on this list last =
year.&nbsp; This is one</FONT>
<BR><FONT SIZE=3D2>motivation for the use of the non-repudiation bit in =
certificates,</FONT>
<BR><FONT SIZE=3D2>i.e., if this bit is NOT asserted, one can =
reasonably interpret the</FONT>
<BR><FONT SIZE=3D2>signature as not binding.&nbsp; This does not =
require a change to the</FONT>
<BR><FONT SIZE=3D2>signing format, but rather appropriate use of key =
usage bits in</FONT>
<BR><FONT SIZE=3D2>certificates. As others have pointed out, the =
preferred way to</FONT>
<BR><FONT SIZE=3D2>represent the distinction between binding and =
non-binding signatures</FONT>
<BR><FONT SIZE=3D2>is via flags in certificates, e.g., key usage, cert =
policy, etc.</FONT>
</P>

<P><FONT SIZE=3D2>Steve</FONT>
</P>
<BR>
<BR>
<BR>

</BODY>
</HTML>
------_=_NextPart_001_01BFF016.00C24D46--


Received: from blue.identrus.com ([216.213.93.121]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id JAA18733 for <[e-mail]>; Mon, 17 Jul 2000 09:59:22 -0700 (PDT)
Received: by blue.identrus.com with Internet Mail Service (5.5.2650.21) id <N9QAN1B5>; Mon, 17 Jul 2000 13:01:42 -0400
Message-ID: <[e-mail]>
From: Khaja Ahmed <[e-mail]>
To: "'Rich Salz '" <[e-mail]>, Khaja Ahmed <[e-mail]>
Cc: "''[e-mail] ' '" <[e-mail]>
Subject: RE: Need for an XML based cert check protocol with RPP capability .
Date: Mon, 17 Jul 2000 13:01:42 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
List-Unsubscribe: mailto:[e-mail]?body=unsubscribe
Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01BFF010.AE5B5230"

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01BFF010.AE5B5230
Content-Type: text/plain;
	charset="iso-8859-1"

 

-----Original Message-----
From: Rich Salz

>I don't understand why RPP is necessary in the Identrus model.
>You only need to set up peering relationships among banks, as long as
>each cert has a service locator of some type.


The reasoning behind this is that it makes it:

1.) Easier to build relying party applications because you dont burden them
with RFC.2459 section 6.1 compliant path processing.

and

2.) Allows the banks to provide value add services beyond certificate
validation.  i.e. validation of the transaction itself.  The thinking is
that the relying party (in some transactions) the seller doesn't simply want
to know whether or not the buyer's certificate is good.  He may want to know
if she is good for money, has the required funds/credit rating etc.


------_=_NextPart_001_01BFF010.AE5B5230
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Diso-8859-1">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
5.5.2650.12">
<TITLE>RE: Need for an XML based cert check protocol with RPP =
capability.</TITLE>
</HEAD>
<BODY>

<P><FONT SIZE=3D2>&nbsp;</FONT>
</P>

<P><FONT SIZE=3D2>-----Original Message-----</FONT>
<BR><FONT SIZE=3D2>From: Rich Salz</FONT>
</P>

<P><FONT SIZE=3D2>&gt;I don't understand why RPP is necessary in the =
Identrus model.</FONT>
<BR><FONT SIZE=3D2>&gt;You only need to set up peering relationships =
among banks, as long as</FONT>
<BR><FONT SIZE=3D2>&gt;each cert has a service locator of some =
type.</FONT>
</P>
<BR>

<P><FONT SIZE=3D2>The reasoning behind this is that it makes it:</FONT>
</P>

<P><FONT SIZE=3D2>1.) Easier to build relying party applications =
because you dont burden them with RFC.2459 section 6.1 compliant path =
processing.</FONT></P>

<P><FONT SIZE=3D2>and</FONT>
</P>

<P><FONT SIZE=3D2>2.) Allows the banks to provide value add services =
beyond certificate validation.&nbsp; i.e. validation of the transaction =
itself.&nbsp; The thinking is that the relying party (in some =
transactions) the seller doesn't simply want to know whether or not the =
buyer's certificate is good.&nbsp; He may want to know if she is good =
for money, has the required funds/credit rating etc.</FONT></P>

</BODY>
</HTML>
------_=_NextPart_001_01BFF010.AE5B5230--


Received: from blue.identrus.com ([216.213.93.121]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id JAA18410 for <[e-mail]>; Mon, 17 Jul 2000 09:50:25 -0700 (PDT)
Received: by blue.identrus.com with Internet Mail Service (5.5.2650.21) id <N9QAN1BS>; Mon, 17 Jul 2000 12:52:46 -0400
Message-ID: <[e-mail]>
From: Khaja Ahmed <[e-mail]>
To: "'[e-mail] '" <[e-mail]>, "'Stephen Kent '" <[e-mail]>
Cc: "'[e-mail] '" <[e-mail]>, "'[e-mail] '" <[e-mail]>
Subject: RE: Signing what you don't understand
Date: Mon, 17 Jul 2000 12:52:45 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
List-Unsubscribe: mailto:[e-mail]?body=unsubscribe
Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01BFF00F.6E645370"

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01BFF00F.6E645370
Content-Type: text/plain;
	charset="iso-8859-1"

>Anything in the certificate that's used to imply something about the
>intent
>behind a signature is asking for trouble, unless the specific
>certificate
>that a relying party should use is bound to the signature.  What's to
>prevent me from obtaining certificates from two different CAs,
>certifying
>the same key, but with different settings of the NR bit in the two
>certificates, and then using the certificate with the NR bit clear to
>repudiate a signature I originally represented as being non-repudiable
>using the other certificate?

Does this make a case for keys generated in hardware that prevents cloning
and backup?  That would in turn imply that legally defensible NR comes at a
fairly steep price.


>The only way that using anything in the certificate could work is if the
>specific certificate that I intend a relying party to use to verify the
>signature is somehow bound into the signature.  Binding a particular
>certificate to a signature has all sorts of other problems (e.g. do all
>my
>signatures become unverifiable when my certificate is renewed?), and
>would
>require a signature format change anyway, so why not simply assert the
>intent explicitly as part of the signature?

Are there any proposals to do this?  Are there revisions being contemplated
to signature formats that include the certs?  I find this very interesting
and would like to know if any work is being done in this area.

Thanks.

Khaja





Stephen Kent <[e-mail]> on 07/13/2000 09:48:56 AM

To:   <[e-mail]>
cc:   <[e-mail]>
Subject:  Re: Signing what you don't understand


Denis,

>The most important point of my previous message was buried under a pile
of
>other stuff, so I am repeating it here:
>
>
>It is my proposal that a signature format is designed which will allow
an
>entity to say: "I signed this data, but I didn't understand what I
signed.
>You are free to use this signature as proof that I possess a certain
private
>key, but this is also the only purpose for which this signature can be
>used."

We have had an analogous debate on this list last year.  This is one
motivation for the use of the non-repudiation bit in certificates,
i.e., if this bit is NOT asserted, one can reasonably interpret the
signature as not binding.  This does not require a change to the
signing format, but rather appropriate use of key usage bits in
certificates. As others have pointed out, the preferred way to
represent the distinction between binding and non-binding signatures
is via flags in certificates, e.g., key usage, cert policy, etc.

Steve





------_=_NextPart_001_01BFF00F.6E645370
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Diso-8859-1">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
5.5.2650.12">
<TITLE>RE: Signing what you don't understand</TITLE>
</HEAD>
<BODY>

<P><FONT SIZE=3D2>&gt;Anything in the certificate that's used to imply =
something about the</FONT>
<BR><FONT SIZE=3D2>&gt;intent</FONT>
<BR><FONT SIZE=3D2>&gt;behind a signature is asking for trouble, unless =
the specific</FONT>
<BR><FONT SIZE=3D2>&gt;certificate</FONT>
<BR><FONT SIZE=3D2>&gt;that a relying party should use is bound to the =
signature.&nbsp; What's to</FONT>
<BR><FONT SIZE=3D2>&gt;prevent me from obtaining certificates from two =
different CAs,</FONT>
<BR><FONT SIZE=3D2>&gt;certifying</FONT>
<BR><FONT SIZE=3D2>&gt;the same key, but with different settings of the =
NR bit in the two</FONT>
<BR><FONT SIZE=3D2>&gt;certificates, and then using the certificate =
with the NR bit clear to</FONT>
<BR><FONT SIZE=3D2>&gt;repudiate a signature I originally represented =
as being non-repudiable</FONT>
<BR><FONT SIZE=3D2>&gt;using the other certificate?</FONT>
</P>

<P><FONT SIZE=3D2>Does this make a case for keys generated in hardware =
that prevents cloning and backup?&nbsp; That would in turn imply that =
legally defensible NR comes at a fairly steep price.</FONT></P>
<BR>

<P><FONT SIZE=3D2>&gt;The only way that using anything in the =
certificate could work is if the</FONT>
<BR><FONT SIZE=3D2>&gt;specific certificate that I intend a relying =
party to use to verify the</FONT>
<BR><FONT SIZE=3D2>&gt;signature is somehow bound into the =
signature.&nbsp; Binding a particular</FONT>
<BR><FONT SIZE=3D2>&gt;certificate to a signature has all sorts of =
other problems (e.g. do all</FONT>
<BR><FONT SIZE=3D2>&gt;my</FONT>
<BR><FONT SIZE=3D2>&gt;signatures become unverifiable when my =
certificate is renewed?), and</FONT>
<BR><FONT SIZE=3D2>&gt;would</FONT>
<BR><FONT SIZE=3D2>&gt;require a signature format change anyway, so why =
not simply assert the</FONT>
<BR><FONT SIZE=3D2>&gt;intent explicitly as part of the =
signature?</FONT>
</P>

<P><FONT SIZE=3D2>Are there any proposals to do this?&nbsp; Are there =
revisions being contemplated to signature formats that include the =
certs?&nbsp; I find this very interesting and would like to know if any =
work is being done in this area.</FONT></P>

<P><FONT SIZE=3D2>Thanks.</FONT>
</P>

<P><FONT SIZE=3D2>Khaja</FONT>
</P>
<BR>
<BR>
<BR>
<BR>

<P><FONT SIZE=3D2>Stephen Kent &lt;[e-mail]&gt; on 07/13/2000 =
09:48:56 AM</FONT>
</P>

<P><FONT SIZE=3D2>To:&nbsp;&nbsp; =
&lt;[e-mail]&gt;</FONT>
<BR><FONT SIZE=3D2>cc:&nbsp;&nbsp; &lt;[e-mail]&gt;</FONT>
<BR><FONT SIZE=3D2>Subject:&nbsp; Re: Signing what you don't =
understand</FONT>
</P>
<BR>

<P><FONT SIZE=3D2>Denis,</FONT>
</P>

<P><FONT SIZE=3D2>&gt;The most important point of my previous message =
was buried under a pile</FONT>
<BR><FONT SIZE=3D2>of</FONT>
<BR><FONT SIZE=3D2>&gt;other stuff, so I am repeating it here:</FONT>
<BR><FONT SIZE=3D2>&gt;</FONT>
<BR><FONT SIZE=3D2>&gt;</FONT>
<BR><FONT SIZE=3D2>&gt;It is my proposal that a signature format is =
designed which will allow</FONT>
<BR><FONT SIZE=3D2>an</FONT>
<BR><FONT SIZE=3D2>&gt;entity to say: &quot;I signed this data, but I =
didn't understand what I</FONT>
<BR><FONT SIZE=3D2>signed.</FONT>
<BR><FONT SIZE=3D2>&gt;You are free to use this signature as proof that =
I possess a certain</FONT>
<BR><FONT SIZE=3D2>private</FONT>
<BR><FONT SIZE=3D2>&gt;key, but this is also the only purpose for which =
this signature can be</FONT>
<BR><FONT SIZE=3D2>&gt;used.&quot;</FONT>
</P>

<P><FONT SIZE=3D2>We have had an analogous debate on this list last =
year.&nbsp; This is one</FONT>
<BR><FONT SIZE=3D2>motivation for the use of the non-repudiation bit in =
certificates,</FONT>
<BR><FONT SIZE=3D2>i.e., if this bit is NOT asserted, one can =
reasonably interpret the</FONT>
<BR><FONT SIZE=3D2>signature as not binding.&nbsp; This does not =
require a change to the</FONT>
<BR><FONT SIZE=3D2>signing format, but rather appropriate use of key =
usage bits in</FONT>
<BR><FONT SIZE=3D2>certificates. As others have pointed out, the =
preferred way to</FONT>
<BR><FONT SIZE=3D2>represent the distinction between binding and =
non-binding signatures</FONT>
<BR><FONT SIZE=3D2>is via flags in certificates, e.g., key usage, cert =
policy, etc.</FONT>
</P>

<P><FONT SIZE=3D2>Steve</FONT>
</P>
<BR>
<BR>
<BR>

</BODY>
</HTML>
------_=_NextPart_001_01BFF00F.6E645370--


Received: from ntserver2.chrysalis-its.com ([209.47.245.163]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id IAA17318 for <[e-mail]>; Mon, 17 Jul 2000 08:52:58 -0700 (PDT)
From: [e-mail]
Received: by NTSERVER2 with Internet Mail Service (5.5.2650.21) id <36RJCYF1>; Mon, 17 Jul 2000 11:56:01 -0400
Message-ID: <[e-mail]>
To: [e-mail]
Cc: [e-mail]
Subject: RE: Re: CRMF encValue Field
Date: Mon, 17 Jul 2000 11:55:53 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01BFF007.808B61DE"

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01BFF007.808B61DE
Content-Type: text/plain;
	charset="iso-8859-1"

Hi Stephen,

I have noted that the recently published July version of RFC2510bis now
contains a note in Appendix D on "RFC 2511 Clarifications" about this
particular issue, however an exception was added for the Diffie-Hellman
algorithm OID and parameters whereas those defined in Appendix B2 of this
specification (i.e. RFC2510bis) MUST be used instead of the OID and
parameters defined in PKCS#11. Although I understand that this exception was
necessary since PKCS#11 currently only supports the PKCS#3 flavour of
Diffie-Hellman whereas Appendix B2 of RFC2510bis is about the ANSI X9.42
flavour of Diffie-Hellman, this should have been mentioned in this
clarification.

In addition, this same clarification indicates that in this case, the
intendedAlg field is unnecessary (since this information is included in
PrivateKeyInfo) and MUST be omitted. However, the algorithm identifier field
within the PrivateKeyInfo is encrypted, which means that the
"EncryptedValue" type would not contain any information in the clear about
the OID of the private key that it is carrying. Was this your intend, please
clarify? I also understand that including the intendedAlg field would
duplicate the occurrence of the parameters field, since the syntax of the
"AlgorithmIdentifier" type also contains a "parameters" field, however by
still indicating the algorithm OID, but forcing the "parameters" field
within the intendedAlg field to be NULL would allow the "EncryptedValue"
type to indicate what is the OID of the private key that it is carrying, but
not duplicate the parameters field. Wouldn't this approach be better?

Regards,

Francois
___________________________________
Francois Rousseau
Director of Standards and Conformance
Chrysalis-ITS
1688 Woodward Drive
Ottawa, Ontario, CANADA, K2C 3R7
[e-mail]      Tel. [phone] ext. 419
http://www.chrysalis-its.com     Fax. [phone]


-----Original Message-----
From: Stephen Farrell [mailto:[e-mail]]
Sent: Friday, June 30, 2000 7:34 AM
To: [e-mail]
Cc: [e-mail]
Subject: Re: CRMF encValue Field

Hi Francois,

As I said yesterday, I'll check what the folks on Bob's ca-talk list
have implemented. I do agree that handling pkcs#11 tokens is desirable,
but I would guess is lower priority than not breaking current
implementations. So pkcs#11 support (if different from what's 
implemented already), could either be added to 2510bis as an
implenmentation note, or, if it gets complicated, in a separate 
"pkcs#11 key wrapping in CMP" draft.

Let's wait & see what the developers have done.

Regards,
Stephen.

> [e-mail] wrote:
> 
> Steve,
> 
> As agreed yesterday at the PKI Forum meeting in Dublin, could you please
check and add some
> clarification in the next version of RFC2510bis about what exactly must be
encoded in the
> "encValue" field of the EncryptedValue structure, which is described in
Section 6.4 of CRMF
> [RFC2511]. This clarification will become necessary in order to ensure
interoperability between
> components using hardware or software from different vendors (i.e.
clients, RAs and CAs) that
> might use this CRMF "encValue" field.
> 
> As discussed, please note that hardware cryptographic module vendors that
implement PKCS#11 would
> normally use the Cryptoki wrapping mechanism to encrypt any private key
that has to be extracted
> from their module to go in this "encValue" field. Since Section 11.9 of
PKCS#11 v2.01 mandates for
> wrapping a private key that:
> 
> "Cryptoki Version 2.01 allows the use of secret keys for wrapping and
unwrapping RSA private keys,
> Diffie-Hellman private keys, and DSA private keys. For wrapping, a private
key is BER-encoded
> according to PKCS #8's PrivateKeyInfo ASN.1 type."
> 
> I hope that the type "PrivateKeyInfo" from Section 6 of PKCS#8 is what is
currently being
> encrypted within this CRMF "encValue" field of the EncryptedValue
structure for today CMP
> implementations.
> 
> Regards,
> 
> Francois
> ___________________________________
> Francois Rousseau
> Director of Standards and Conformance
> Chrysalis-ITS
> 1688 Woodward Drive
> Ottawa, Ontario, CANADA, K2C 3R7
> [e-mail]      Tel. [phone] ext. 419
> http://www.chrysalis-its.com     Fax. [phone]
> 
> -----Original Message-----
> From: Francois Rousseau
> Sent: Thursday, May 25, 2000 3:42 PM
> To: 'Carlisle Adams'
> Cc: [e-mail]
> Subject: Encryption of Private Keys in CRMF and CMP
> 
> Carlisle,
> 
> In Section 6.4 of RFC 2511 on CRMF, it is indicated that the
EncryptedValue field "encValue" is a
> BIT STRING, however I could not find any further detail in RFC 2511 nor in
RFC 2510bis, which also
> use this syntax, about how to create this encrypted value (restricted, in
RFC 2510bis, to be
> either private keys or certificates).
> 
> Am I missing something?
> 
> I understand that RFC 2511 EncryptedValue field "symmAlg" tells me the
symmetric algorithm that
> was used to encrypt a private key value and that Appendix B2 of RFC
2510bis mandates that
> conforming implementations MUST support 3-DES (3-key-EDE, CBC mode) for
this. However, this does
> not tell me what exactly is being encrypted.
> 
> Is it a type "PrivateKeyInfo" from Section 6 of PKCS#8 or a type
"RSAPrivateKey" from Section
> 11.1.2 of PKCS#1 for a RSA private key since RFC 2511 EncryptedValue field
"intendedAlg" already
> tell me the intended algorithm for which the private key will be used for?
> 
> Thanks in advance for any help.
> 
> Francois
> ___________________________________
> Francois Rousseau
> Director of Standards and Conformance
> Chrysalis-ITS
> 1688 Woodward Drive
> Ottawa, Ontario, CANADA, K2C 3R7
> [e-mail]      Tel. [phone] ext. 419
> http://www.chrysalis-its.com     Fax. [phone]

-- 
____________________________________________________________
Stephen Farrell         				   
Baltimore Technologies,   tel: (direct line) [phone]
61 Fitzwilliam Lane,                    fax: [phone]
Dublin 2.                mailto:[e-mail]
Ireland                             http://www.baltimore.com

------_=_NextPart_001_01BFF007.808B61DE
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Diso-8859-1">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
5.5.2650.12">
<TITLE>RE: Re: CRMF encValue Field</TITLE>
</HEAD>
<BODY>

<P><FONT SIZE=3D2>Hi Stephen,</FONT>
</P>

<P><FONT SIZE=3D2>I have noted that the recently published July version =
of RFC2510bis now contains a note in Appendix D on &quot;RFC 2511 =
Clarifications&quot; about this particular issue, however an exception =
was added for the Diffie-Hellman algorithm OID and parameters whereas =
those defined in Appendix B2 of this specification (i.e. RFC2510bis) =
MUST be used instead of the OID and parameters defined in PKCS#11. =
Although I understand that this exception was necessary since PKCS#11 =
currently only supports the PKCS#3 flavour of Diffie-Hellman whereas =
Appendix B2 of RFC2510bis is about the ANSI X9.42 flavour of =
Diffie-Hellman, this should have been mentioned in this =
clarification.</FONT></P>

<P><FONT SIZE=3D2>In addition, this same clarification indicates that =
in this case, the intendedAlg field is unnecessary (since this =
information is included in PrivateKeyInfo) and MUST be omitted. =
However, the algorithm identifier field within the PrivateKeyInfo is =
encrypted, which means that the &quot;EncryptedValue&quot; type would =
not contain any information in the clear about the OID of the private =
key that it is carrying. Was this your intend, please clarify? I also =
understand that including the intendedAlg field would duplicate the =
occurrence of the parameters field, since the syntax of the =
&quot;AlgorithmIdentifier&quot; type also contains a =
&quot;parameters&quot; field, however by still indicating the algorithm =
OID, but forcing the &quot;parameters&quot; field within the =
intendedAlg field to be NULL would allow the &quot;EncryptedValue&quot; =
type to indicate what is the OID of the private key that it is =
carrying, but not duplicate the parameters field. Wouldn't this =
approach be better?</FONT></P>

<P><FONT SIZE=3D2>Regards,</FONT>
</P>

<P><FONT SIZE=3D2>Francois</FONT>
<BR><FONT SIZE=3D2>___________________________________</FONT>
<BR><FONT SIZE=3D2>Francois Rousseau</FONT>
<BR><FONT SIZE=3D2>Director of Standards and Conformance</FONT>
<BR><FONT SIZE=3D2>Chrysalis-ITS</FONT>
<BR><FONT SIZE=3D2>1688 Woodward Drive</FONT>
<BR><FONT SIZE=3D2>Ottawa, Ontario, CANADA, K2C 3R7</FONT>
<BR><FONT =
SIZE=3D2>[e-mail]&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Tel. =
[phone] ext. 419</FONT>
<BR><FONT SIZE=3D2><A HREF=3D"http://www.chrysalis-its.com" =
TARGET=3D"_blank">http://www.chrysalis-its.com</A>&nbsp;&nbsp;&nbsp;&nbs=
p; Fax. [phone]</FONT>
</P>
<BR>

<P><FONT SIZE=3D2>-----Original Message-----</FONT>
<BR><FONT SIZE=3D2>From: Stephen Farrell [<A =
HREF=3D"mailto:[e-mail]">mailto:stephen.farrell@balt=
imore.ie</A>]</FONT>
<BR><FONT SIZE=3D2>Sent: Friday, June 30, 2000 7:34 AM</FONT>
<BR><FONT SIZE=3D2>To: [e-mail]</FONT>
<BR><FONT SIZE=3D2>Cc: [e-mail]</FONT>
<BR><FONT SIZE=3D2>Subject: Re: CRMF encValue Field</FONT>
</P>

<P><FONT SIZE=3D2>Hi Francois,</FONT>
</P>

<P><FONT SIZE=3D2>As I said yesterday, I'll check what the folks on =
Bob's ca-talk list</FONT>
<BR><FONT SIZE=3D2>have implemented. I do agree that handling pkcs#11 =
tokens is desirable,</FONT>
<BR><FONT SIZE=3D2>but I would guess is lower priority than not =
breaking current</FONT>
<BR><FONT SIZE=3D2>implementations. So pkcs#11 support (if different =
from what's </FONT>
<BR><FONT SIZE=3D2>implemented already), could either be added to =
2510bis as an</FONT>
<BR><FONT SIZE=3D2>implenmentation note, or, if it gets complicated, in =
a separate </FONT>
<BR><FONT SIZE=3D2>&quot;pkcs#11 key wrapping in CMP&quot; =
draft.</FONT>
</P>

<P><FONT SIZE=3D2>Let's wait &amp; see what the developers have done.</F=
ONT>
</P>

<P><FONT SIZE=3D2>Regards,</FONT>
<BR><FONT SIZE=3D2>Stephen.</FONT>
</P>

<P><FONT SIZE=3D2>&gt; [e-mail] wrote:</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; Steve,</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; As agreed yesterday at the PKI Forum meeting in =
Dublin, could you please check and add some</FONT>
<BR><FONT SIZE=3D2>&gt; clarification in the next version of RFC2510bis =
about what exactly must be encoded in the</FONT>
<BR><FONT SIZE=3D2>&gt; &quot;encValue&quot; field of the =
EncryptedValue structure, which is described in Section 6.4 of =
CRMF</FONT>
<BR><FONT SIZE=3D2>&gt; [RFC2511]. This clarification will become =
necessary in order to ensure interoperability between</FONT>
<BR><FONT SIZE=3D2>&gt; components using hardware or software from =
different vendors (i.e. clients, RAs and CAs) that</FONT>
<BR><FONT SIZE=3D2>&gt; might use this CRMF &quot;encValue&quot; =
field.</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; As discussed, please note that hardware =
cryptographic module vendors that implement PKCS#11 would</FONT>
<BR><FONT SIZE=3D2>&gt; normally use the Cryptoki wrapping mechanism to =
encrypt any private key that has to be extracted</FONT>
<BR><FONT SIZE=3D2>&gt; from their module to go in this =
&quot;encValue&quot; field. Since Section 11.9 of PKCS#11 v2.01 =
mandates for</FONT>
<BR><FONT SIZE=3D2>&gt; wrapping a private key that:</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; &quot;Cryptoki Version 2.01 allows the use of =
secret keys for wrapping and unwrapping RSA private keys,</FONT>
<BR><FONT SIZE=3D2>&gt; Diffie-Hellman private keys, and DSA private =
keys. For wrapping, a private key is BER-encoded</FONT>
<BR><FONT SIZE=3D2>&gt; according to PKCS #8's PrivateKeyInfo ASN.1 =
type.&quot;</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; I hope that the type &quot;PrivateKeyInfo&quot; =
from Section 6 of PKCS#8 is what is currently being</FONT>
<BR><FONT SIZE=3D2>&gt; encrypted within this CRMF &quot;encValue&quot; =
field of the EncryptedValue structure for today CMP</FONT>
<BR><FONT SIZE=3D2>&gt; implementations.</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; Regards,</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; Francois</FONT>
<BR><FONT SIZE=3D2>&gt; ___________________________________</FONT>
<BR><FONT SIZE=3D2>&gt; Francois Rousseau</FONT>
<BR><FONT SIZE=3D2>&gt; Director of Standards and Conformance</FONT>
<BR><FONT SIZE=3D2>&gt; Chrysalis-ITS</FONT>
<BR><FONT SIZE=3D2>&gt; 1688 Woodward Drive</FONT>
<BR><FONT SIZE=3D2>&gt; Ottawa, Ontario, CANADA, K2C 3R7</FONT>
<BR><FONT SIZE=3D2>&gt; =
[e-mail]&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Tel. (613) =
723-5076 ext. 419</FONT>
<BR><FONT SIZE=3D2>&gt; <A HREF=3D"http://www.chrysalis-its.com" =
TARGET=3D"_blank">http://www.chrysalis-its.com</A>&nbsp;&nbsp;&nbsp;&nbs=
p; Fax. [phone]</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; -----Original Message-----</FONT>
<BR><FONT SIZE=3D2>&gt; From: Francois Rousseau</FONT>
<BR><FONT SIZE=3D2>&gt; Sent: Thursday, May 25, 2000 3:42 PM</FONT>
<BR><FONT SIZE=3D2>&gt; To: 'Carlisle Adams'</FONT>
<BR><FONT SIZE=3D2>&gt; Cc: [e-mail]</FONT>
<BR><FONT SIZE=3D2>&gt; Subject: Encryption of Private Keys in CRMF and =
CMP</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; Carlisle,</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; In Section 6.4 of RFC 2511 on CRMF, it is =
indicated that the EncryptedValue field &quot;encValue&quot; is =
a</FONT>
<BR><FONT SIZE=3D2>&gt; BIT STRING, however I could not find any =
further detail in RFC 2511 nor in RFC 2510bis, which also</FONT>
<BR><FONT SIZE=3D2>&gt; use this syntax, about how to create this =
encrypted value (restricted, in RFC 2510bis, to be</FONT>
<BR><FONT SIZE=3D2>&gt; either private keys or certificates).</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; Am I missing something?</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; I understand that RFC 2511 EncryptedValue field =
&quot;symmAlg&quot; tells me the symmetric algorithm that</FONT>
<BR><FONT SIZE=3D2>&gt; was used to encrypt a private key value and =
that Appendix B2 of RFC 2510bis mandates that</FONT>
<BR><FONT SIZE=3D2>&gt; conforming implementations MUST support 3-DES =
(3-key-EDE, CBC mode) for this. However, this does</FONT>
<BR><FONT SIZE=3D2>&gt; not tell me what exactly is being =
encrypted.</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; Is it a type &quot;PrivateKeyInfo&quot; from =
Section 6 of PKCS#8 or a type &quot;RSAPrivateKey&quot; from =
Section</FONT>
<BR><FONT SIZE=3D2>&gt; 11.1.2 of PKCS#1 for a RSA private key since =
RFC 2511 EncryptedValue field &quot;intendedAlg&quot; already</FONT>
<BR><FONT SIZE=3D2>&gt; tell me the intended algorithm for which the =
private key will be used for?</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; Thanks in advance for any help.</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; Francois</FONT>
<BR><FONT SIZE=3D2>&gt; ___________________________________</FONT>
<BR><FONT SIZE=3D2>&gt; Francois Rousseau</FONT>
<BR><FONT SIZE=3D2>&gt; Director of Standards and Conformance</FONT>
<BR><FONT SIZE=3D2>&gt; Chrysalis-ITS</FONT>
<BR><FONT SIZE=3D2>&gt; 1688 Woodward Drive</FONT>
<BR><FONT SIZE=3D2>&gt; Ottawa, Ontario, CANADA, K2C 3R7</FONT>
<BR><FONT SIZE=3D2>&gt; =
[e-mail]&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Tel. (613) =
723-5076 ext. 419</FONT>
<BR><FONT SIZE=3D2>&gt; <A HREF=3D"http://www.chrysalis-its.com" =
TARGET=3D"_blank">http://www.chrysalis-its.com</A>&nbsp;&nbsp;&nbsp;&nbs=
p; Fax. [phone]</FONT>
</P>

<P><FONT SIZE=3D2>-- </FONT>
<BR><FONT =
SIZE=3D2>____________________________________________________________</F=
ONT>
<BR><FONT SIZE=3D2>Stephen =
Farrell&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &nbsp;&nbsp; </FONT>
<BR><FONT SIZE=3D2>Baltimore Technologies,&nbsp;&nbsp; tel: (direct =
line) [phone]</FONT>
<BR><FONT SIZE=3D2>61 Fitzwilliam =
Lane,&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&=
nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; fax: [phone] =
7499</FONT>
<BR><FONT SIZE=3D2>Dublin =
2.&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp;&nbsp; <A =
HREF=3D"mailto:[e-mail]">mailto:stephen.farrell@balt=
imore.ie</A></FONT>
<BR><FONT =
SIZE=3D2>Ireland&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <A =
HREF=3D"http://www.baltimore.com" =
TARGET=3D"_blank">http://www.baltimore.com</A></FONT>
</P>

</BODY>
</HTML>
------_=_NextPart_001_01BFF007.808B61DE--


Received: from smtp.scotland.net (unixpark3.scotland.net [148.176.231.3]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id IAA16013 for <[e-mail]>; Mon, 17 Jul 2000 08:05:43 -0700 (PDT)
Received: from e2h2p107.scotland.net ([148.176.238.108] helo=npwork2) by smtp.scotland.net with smtp (Exim 3.13 #2) id 13ECV2-00055N-00 for [e-mail]; Mon, 17 Jul 2000 16:08:04 +0100
From: "Nick Pope" <[e-mail]>
To: <[e-mail]>
Subject: Policy Requirements for Certification Service Providers
Date: Mon, 17 Jul 2000 16:19:24 +0100
Message-ID: <001d01bff002$63c0e510$0500000a@npwork2>
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 8bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6600

A draft specification "Policy Requirements for Certification Service
Providers Issuing Qualified Certificates" is now avilable for public review
and comment on web page:
<http://www.etsi.org/sec/el-sign.htm>

This is being distributed with the following request for comment:


----------------------------------------------------------------------


Request for comments on draft standard
"Policy Requirements for Certification Service Providers
Issuing Qualified Certificates"
 and for contributions on requirements for other classes

The aim of this request is twofold.

1.  Comment on "Policy Requirements for CSPs Issuing Qualified Certificates

The major objective is to receive comments to and the draft identified
above.

The purpose of this standard is to specify policy requirements on the
operation and management of Certification Service Providers issuing
Qualified Certificates as laid down in the European Directive on electronic
signatures (1999/93/EC).   ESI WG plans to finalise the draft by
mid-November. After approval by ETSI SEC the document is due for publication
by the end of the year.

Comments are requested on this document by 15th September 2000.

2. Requirements for other classes

There are strong indications, that the current program should also address
requirements for other trust levels and corresponding classes of
certificates. In order to identify those needs and gather input for
consistent requirements receivers of the present request are asked to
consider contributing with concrete proposals to this area.

The current structure and requirements may serve as a reference and
comparison to define alternative requirements, e.g. for transactions of
lower financial or legal implications. Accuracy of identification of
certificate holders and assurance of trusted hardware and software
components are examples of areas with a need to offer cost-efficient
alternatives.

Comments are requested on this issue by 15th September 2000..

Background

The development of this standard policy document is one of the tasks the
ETSI Electronic Signature and Infrastructure Working Group is progressing
within the European Electronic Signature Standardisation Initiative (EESSI).
The ETSI El Sign Web-site (see below) provides further information about the
ETSI activities and the EESSI program.

Requested action.

Please send your comments and suggestions not later than 15 September to the
ETSI El Sign e-mail list [e-mail], with copy to
[e-mail].   Please put "QCP" at the front of the Subject field of
all submissions to the e-mail list on this topic.

To register with the EL-SIGN list and download the draft document see:

http://www.etsi.org/sec/el-sign.htm

The purpose of the open e-mail list is to stimulate discussion of the
published comments and contributions. Therefore, early submissions are
welcome. We expect that discussions will go on through the open e-mail list
under and after the comments period.


With regards

Nick Pope, Security & Standards
ETSI task leader - Policies for CSPs
[e-mail]

and

György Endersz, Telia Research AB
Chair ETSI ESI Working Group
[e-mail]







Received: from arista.iris.com (arista.iris.com [198.112.211.42]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id HAA15258 for <[e-mail]>; Mon, 17 Jul 2000 07:31:57 -0700 (PDT)
From: [e-mail]
Subject: Re: Signing what you don't understand
To: Stephen Kent <[e-mail]>
Cc: <[e-mail]>, <[e-mail]>
X-Mailer: Lotus Notes Release 5.0.2c  February 2, 2000
Message-ID: <[e-mail]>
Date: Mon, 17 Jul 2000 10:21:20 -0400
X-MIMETrack: Serialize by Router on Arista/Iris(Build V505_07112000 |July 11, 2000) at 07/17/2000 10:34:22 AM
MIME-Version: 1.0
Content-type: text/plain; charset=us-ascii

Anything in the certificate that's used to imply something about the intent
behind a signature is asking for trouble, unless the specific certificate
that a relying party should use is bound to the signature.  What's to
prevent me from obtaining certificates from two different CAs, certifying
the same key, but with different settings of the NR bit in the two
certificates, and then using the certificate with the NR bit clear to
repudiate a signature I originally represented as being non-repudiable
using the other certificate?

The only way that using anything in the certificate could work is if the
specific certificate that I intend a relying party to use to verify the
signature is somehow bound into the signature.  Binding a particular
certificate to a signature has all sorts of other problems (e.g. do all my
signatures become unverifiable when my certificate is renewed?), and would
require a signature format change anyway, so why not simply assert the
intent explicitly as part of the signature?

John





Stephen Kent <[e-mail]> on 07/13/2000 09:48:56 AM

To:   <[e-mail]>
cc:   <[e-mail]>
Subject:  Re: Signing what you don't understand


Denis,

>The most important point of my previous message was buried under a pile of
>other stuff, so I am repeating it here:
>
>
>It is my proposal that a signature format is designed which will allow an
>entity to say: "I signed this data, but I didn't understand what I signed.
>You are free to use this signature as proof that I possess a certain
private
>key, but this is also the only purpose for which this signature can be
>used."

We have had an analogous debate on this list last year.  This is one
motivation for the use of the non-repudiation bit in certificates,
i.e., if this bit is NOT asserted, one can reasonably interpret the
signature as not binding.  This does not require a change to the
signing format, but rather appropriate use of key usage bits in
certificates. As others have pointed out, the preferred way to
represent the distinction between binding and non-binding signatures
is via flags in certificates, e.g., key usage, cert policy, etc.

Steve







Received: from mail-fwd.verio-web.com (mail11a.verio-web.com [161.58.16.57]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id HAA14541 for <[e-mail]>; Mon, 17 Jul 2000 07:00:12 -0700 (PDT)
Received: from 161.58.117.181 (161.58.117.181) by mail11a.verio-web.com (RS ver 1.0.57s) with SMTP id 0543082; Mon, 17 Jul 2000 10:02:16 -0400 (EDT)
Sender: rsalz
Message-ID: <[e-mail]>
Date: Mon, 17 Jul 2000 10:01:17 -0400
From: Rich Salz <[e-mail]>
X-Mailer: Mozilla 4.72 [en] (X11; U; Linux 2.2.14-5.0 i686)
X-Accept-Language: en
MIME-Version: 1.0
To: Khaja Ahmed <[e-mail]>
CC: "'[e-mail] '" <[e-mail]>
Subject: Re: Need for an XML based cert check protocol with RPP capability.
References: <[e-mail]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
X-Loop-Detect: 1

I don't understand why RPP is necessary in the Identrus model.
You only need to set up peering relationships among banks, as long as
each cert has a service locator of some type.

	/r$


Received: from d12lmsgate-3.de.ibm.com (d12lmsgate-3.de.ibm.com [195.212.91.201]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id GAA13468 for <[e-mail]>; Mon, 17 Jul 2000 06:05:44 -0700 (PDT)
From: [e-mail]
Received: from d12relay02.de.ibm.com (d12relay02.de.ibm.com [9.165.215.23]) by d12lmsgate-3.de.ibm.com (1.0.0) with ESMTP id PAA298588 for <[e-mail]>; Mon, 17 Jul 2000 15:07:33 +0200
Received: from d12mta02.de.ibm.com (d12mta01_cs0 [9.165.222.237]) by d12relay02.de.ibm.com (8.8.8m3/NCO v2.07) with SMTP id PAA47358 for <[e-mail]>; Mon, 17 Jul 2000 15:07:31 +0200
Received: by d12mta02.de.ibm.com(Lotus SMTP MTA v4.6.5  (863.2 5-20-1999))  id C125691F.0048176B ; Mon, 17 Jul 2000 15:07:25 +0200
X-Lotus-FromDomain: IBMIL@IBMDE
To: [e-mail]
Message-ID: <[e-mail]>
Date: Mon, 17 Jul 2000 16:09:53 +0300
Subject: Course foils available: Introduction to Cryptography and Electronic Commerce
Mime-Version: 1.0
Content-type: text/plain; charset=us-ascii
Content-Disposition: inline

I've put the entire set of .pdf foils I've made for the course
`Introduction to Cryptography and Electronic Commerce` available from
http://www.hrl.il.ibm.com/mpay/course.html.

The material is presented `as-is` on a best effort basis, and may contain
inaccuracies and errors (reports welcome); I make no warranties of
precision and accuracy. I also list references to additional courses or
tutorials in these areas (I'll be happy to add / host more here). I gave
this course in the Inter-Disciplinary Center in Hertzelia, Israel, at 1999.
Reuse is encouraged, please retain reference to this page and to the
original title and author(s).

Notice: downloading is free, but... most documents require `paying` using
IBM Micro Payments demo money
(which you'll get in the site). Our design is for this to be
`non-obstrusive` for users who do not have the wallet
installed, so even in this case you should see the page well and follow all
 links.

Warning:  a (natural?) bias to `my` topics exists in this course; I will
attempt to improve this in the future
(using your contributions?).

Comments, suggestions and corrections (on both the course and on the IBM
Micro Payments demo)
will be appreciated.

Best Regards,
Amir Herzberg

IBM Research Lab in Haifa (Tel Aviv Office)
http://www.hrl.il.ibm.com






Received: from ietf.org (odin.ietf.org [132.151.1.176]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id DAA10869 for <[e-mail]>; Mon, 17 Jul 2000 03:40:10 -0700 (PDT)
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA26045; Mon, 17 Jul 2000 06:42:30 -0400 (EDT)
Message-Id: <[e-mail]>
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
Cc: [e-mail]
From: [e-mail]
Reply-to: [e-mail]
Subject: I-D ACTION:draft-ietf-pkix-dcs-05.txt
Date: Mon, 17 Jul 2000 06:42:29 -0400
Sender: [e-mail]

--NextPart

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Public-Key Infrastructure (X.509) Working Group of the IETF.

	Title		: Internet X.509 Public Key Infrastructure Data 
                          Validation and Certification Server Protocols
	Author(s)	: C. Adams, P. Sylvester, M. Zolotarev, R. Zuccherato
	Filename	: draft-ietf-pkix-dcs-05.txt
	Pages		: 47
	Date		: 14-Jul-00
	
This document describes a general data validation and certification
service and the protocols to be used when communicating with it.  The
Data Validation and Certification Server is a Trusted Third Party
(TTP) that can be used as one component in building reliable non-
repudiation services (see [ISONR]).
Useful Data Validation and Certification Server responsibilities in a
PKI are to validate signed documents and to assert the validity of
public key certificates at a given time.
We give examples of how to use the Data Certification Server to
extend the lifetime of a signature beyond key expiry or revocation
and to query the Data Certification Server regarding the status of a
public key certificate.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-pkix-dcs-05.txt

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-ietf-pkix-dcs-05.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt


Internet-Drafts can also be obtained by e-mail.

Send a message to:
	[e-mail].
In the body type:
	"FILE /internet-drafts/draft-ietf-pkix-dcs-05.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.
		
		
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"

--OtherAccess
Content-Type: Message/External-body;
	access-type="mail-server";
	server="[e-mail]"

Content-Type: text/plain
Content-ID:	<[e-mail]>

ENCODING mime
FILE /internet-drafts/draft-ietf-pkix-dcs-05.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-pkix-dcs-05.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID:	<[e-mail]>

--OtherAccess--

--NextPart--




Received: from ietf.org (odin.ietf.org [132.151.1.176]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id DAA10845 for <[e-mail]>; Mon, 17 Jul 2000 03:40:05 -0700 (PDT)
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA26015; Mon, 17 Jul 2000 06:42:25 -0400 (EDT)
Message-Id: <[e-mail]>
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
Cc: [e-mail]
From: [e-mail]
Reply-to: [e-mail]
Subject: I-D ACTION:draft-ietf-pkix-rfc2510bis-01.txt
Date: Mon, 17 Jul 2000 06:42:24 -0400
Sender: [e-mail]

--NextPart

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Public-Key Infrastructure (X.509) Working Group of the IETF.

	Title		: Internet X.509 Public Key Infrastructure Certificate 
                          Management Protocols
	Author(s)	: C. Adams, S. Farrell
	Filename	: draft-ietf-pkix-rfc2510bis-01.txt
	Pages		: 87
	Date		: 14-Jul-00
	
This document describes the Internet X.509 Public Key Infrastructure
(PKI) Certificate Management Protocols. Protocol messages are defined
for all relevant aspects of certificate creation and management.
Note that 'certificate' in this document refers to an X.509v3
Certificate as defined in [COR95, X509-AM].

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-pkix-rfc2510bis-01.txt

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-ietf-pkix-rfc2510bis-01.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt


Internet-Drafts can also be obtained by e-mail.

Send a message to:
	[e-mail].
In the body type:
	"FILE /internet-drafts/draft-ietf-pkix-rfc2510bis-01.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.
		
		
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"

--OtherAccess
Content-Type: Message/External-body;
	access-type="mail-server";
	server="[e-mail]"

Content-Type: text/plain
Content-ID:	<[e-mail]>

ENCODING mime
FILE /internet-drafts/draft-ietf-pkix-rfc2510bis-01.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-pkix-rfc2510bis-01.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID:	<[e-mail]>

--OtherAccess--

--NextPart--




Received: from stonewall.baltimore.com ([195.152.140.4]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id BAA06389 for <[e-mail]>; Mon, 17 Jul 2000 01:57:32 -0700 (PDT)
Message-ID: <[e-mail]>
From: Paul Halliden <[e-mail]>
To: "'Anders Rundgren'" <[e-mail]>, Denis Pinkas <[e-mail]>, Stefan Santesson <[e-mail]>, [e-mail], Paul Halliden <[e-mail]>
Cc: IETF-PXIX <[e-mail]>
Subject: RE: QC DN "qualities". Was: I-D ACTION:draft-ietf-pkix-qc-04.txt
Date: Mon, 17 Jul 2000 09:59:35 +0100
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain; charset="iso-8859-1"

Anders:

I said:
>>The contentious point is that this requirement has been 
>dropped.  the reason
>>is that, in some jurisdictions there is simply no support for the
>>"unmistakable" concept.  Thus the subject name can be unique 
>within the CA's name space. 
>>

You replied:
>This last line is actually the thing requested by Denis and by me!

I think you will find that Denis is arguing against the "unmistakable"
concept (see the first paragraph of his mail dated 13 July).  As I
understand it, he has requested (Comment 1 in the same mail) that a CA does
not re-allocate an expired DN to someone other than the original user of the
name for the lifetime of the CA.  By expired DN, I mean a DN allocated to a
subscriber who no longer has any certificates issued by that CA.

>
>But even that is said to be impossible to achieve for reasons so
>far not particularly well explained.

I have not been arguing against that one - Indeed I think it is good
practice especially if long life documents have been signed by the subject
of a certificate. It will be difficult for some countries to achieve this
especially where there is a gap of many years between one DN ceasing to be
used and a new registration request involving the same DN.  However, I don't
think that should stop us aiming for the objective.

Anders, are we now in agreement?

Regards
Paul Halliden


Received: from odin2.bull.net (odin2.bull.net [192.90.70.84]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id AAA04287 for <[e-mail]>; Mon, 17 Jul 2000 00:17:49 -0700 (PDT)
Received: from lvt-mail.frlv.bull.fr (lvt-mail.frlv.bull.fr [129.184.62.223]) by odin2.bull.net (8.9.2/8.9.1) with ESMTP id JAA38842; Mon, 17 Jul 2000 09:19:22 +0200
Received: from bull.net (fradint87.bull.fr [129.181.85.87]) by lvt-mail.frlv.bull.fr (8.9.2/8.9.1) with ESMTP id JAA37096; Mon, 17 Jul 2000 09:19:29 +0200
Message-ID: <[e-mail]>
Date: Sun, 16 Jul 2000 18:52:11 +0200
From: Denis <[e-mail]>
X-Mailer: Mozilla 4.5 [fr] (Win98; I)
X-Accept-Language: fr
MIME-Version: 1.0
To: "David P. Kemp" <[e-mail]>
CC: [e-mail]
Subject: Re: I-D ACTION:draft-ietf-pkix-qc-04.txt
References: <[e-mail]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Dave,

My response below.

> > From: Denis <[e-mail]>
>
> >
> > Full text proposal replacement for 3.1.1:
> >
> > 3.1.1  Issuer
> >
> > The issuer field SHALL identify the organization responsible for
> > issuing the certificate.
> >
> > The identity of the issuer SHALL be specified using an appropriate
> > subset of the following attributes:
> >
> >          domainComponent;
> >          countryName;
> >          stateOrProvinceName;
> >          organizationName;
> >          localityName; and
> >          serialNumber.
> >
> > Additional attributes MAY be present but they SHOULD NOT be necessary to
> identify the issuing
> > organization. The first element of the DN shall be the country where the CA is
> operating from.
> >
>
> The last sentence conflicts with the presence of domainComponent as
> one of the allowed attributes, as there is no well-defined method of
> constructing a DN containing a mixture of DC and other attributes.

Everything depends from the ordering. If the domainComponent comes in the second
position, then there is no problem. If people may think it is the first componet,
then it should be deleted.


> If it is necessary to identify the local laws under which the QC is
> interpreted, the jurisdiction should be identified using something other
> than the first element of the issuer DN.  An "organization responsible
> for issuing the certificate" may operate in multiple jurisdictions, so
> even where the DN begins with C=xx, interpreting "xx" as a jurisdiction
> may be misleading (and should be performed with care :-).  Did the
> Stockholm discussion consider the possibility of multi-country CAs?

The European Directive requires a supervision system where each (European) country
must supervise the CAs which are established on its territory. Hence why "CN" shall
come first.

Denis

>
> Dave





Received: from blue.identrus.com ([216.213.93.121]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id VAA01571 for <[e-mail]>; Sun, 16 Jul 2000 21:27:33 -0700 (PDT)
Received: by blue.identrus.com with Internet Mail Service (5.5.2650.21) id <N9QAND4V>; Mon, 17 Jul 2000 00:29:48 -0400
Message-ID: <[e-mail]>
From: Khaja Ahmed <[e-mail]>
To: "'[e-mail] '" <[e-mail]>
Subject: Need for an XML based cert check protocol with RPP capability.
Date: Mon, 17 Jul 2000 00:29:43 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
List-Unsubscribe: mailto:[e-mail]?body=unsubscribe
Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01BFEFA7.A25901B0"

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01BFEFA7.A25901B0
Content-Type: text/plain;
	charset="iso-8859-1"

There are many applications being built under the Identrus trust model,
which collectively will provide a global framework for e-commerce.  Identrus
has demonstrated that OCSP is a widely deployable standard that is not
limited by specific application context or PKI implementation. The
availability of OCSP from the IETF has been a key factor toward the
interoperability goal.

As a result of our work deploying OCSP and developing a global e-commerce
framework that uses it, we see the need for some enhancements in protocols
for certificate validation. 

The qualities we will need in a protocol for certificate checking in
applications now being developed include, along with some background, the
following:

1.) Remote Path Processing:  In this model, the relying party (corporation
or individual) has a relationship of trust with their banks. When there is a
business decision to be made regarding trust in an on-line transaction,
including certificate status, certificate path validation, and policy
application, the customer must be able to rely on a simple response from
their bank.  Hence we would like the protocol to support path validation by
the responder (Bank).

2.) XML encoding:  The applications being developed and deployed use XML to
encode messages.  Given this, we would like to have a protocol that uses XML
to encode the request.

3.) XML signatures: Identrus requires that all certificate checking requests
be signed.  We would like to use XML signatures for such requests.

4.) The Identrus model, shown at <http://www.identrus.com/solution.htm>, is
based on the standard banking four-corner model.  Hence a relying party will
always go to his bank to validate a certificate even if the certificate was
actually issued by some other bank.   The protocol must support this.

5.) The protocol must support use of cached responses.  As a corollary, it
must permit the relying party to request a freshly generated response rather
than one from it's cache.

6.) The protocol must permit checking of status on expired certificates.

Identrus has a task force that is examining a couple of protocols to see if
these capabilities.  One is a proprietary protocol and the other is SCVP.
For numerous and obvious (at least to this group) reasons we would prefer to
use SCVP rather than anything proprietary.  

Does SCVP meet the above needs?  Is it a matter of enhancing / modifying it
to some degree to bring it in line with these needs?  My limited
understanding of these things suggests that SCVP is not an unreasonable
candidate.  Is there something else that, more fully, meets the above
requirements?  Are there other issues we should be considering?  

A discussion on this subject will be of great help in developing and / or
selecting a suitable protocol.  If the tremendous brainpower of this group
could be brought to bear on this subject, it will undoubtedly yield the
necessary results.

Do let me know or contact me for further information / clarifications.
Thanks and Regards. 
Khaja 
=========================================== 
Khaja E. Ahmed 
Chief Technology Officer 
Identrus, LLC. 
16th Floor 
140 E 45th St. 
New York, NY 10017 USA 
Telephone: [phone] 
Fax: [phone] 
[e-mail] 
Office Direct: 01.925.989.6564 
Office Main: 01.212.622.1524 
============================================ 


------_=_NextPart_001_01BFEFA7.A25901B0
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Diso-8859-1">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
5.5.2650.12">
<TITLE>Need for an XML based cert check protocol with RPP =
capability.</TITLE>
</HEAD>
<BODY>

<P><FONT SIZE=3D2>There are many applications being built under the =
Identrus trust model, which collectively will provide a global =
framework for e-commerce.&nbsp; Identrus has demonstrated that OCSP is =
a widely deployable standard that is not limited by specific =
application context or PKI implementation. The availability of OCSP =
from the IETF has been a key factor toward the interoperability =
goal.</FONT></P>

<P><FONT SIZE=3D2>As a result of our work deploying OCSP and developing =
a global e-commerce framework that uses it, we see the need for some =
enhancements in protocols for certificate validation. </FONT></P>

<P><FONT SIZE=3D2>The qualities we will need in a protocol for =
certificate checking in applications now being developed include, along =
with some background, the following:</FONT></P>

<P><FONT SIZE=3D2>1.) Remote Path Processing:&nbsp; In this model, the =
relying party (corporation or individual) has a relationship of trust =
with their banks. When there is a business decision to be made =
regarding trust in an on-line transaction, including certificate =
status, certificate path validation, and policy application, the =
customer must be able to rely on a simple response from their =
bank.&nbsp; Hence we would like the protocol to support path validation =
by the responder (Bank).</FONT></P>

<P><FONT SIZE=3D2>2.) XML encoding:&nbsp; The applications being =
developed and deployed use XML to encode messages.&nbsp; Given this, we =
would like to have a protocol that uses XML to encode the =
request.</FONT></P>

<P><FONT SIZE=3D2>3.) XML signatures: Identrus requires that all =
certificate checking requests be signed.&nbsp; We would like to use XML =
signatures for such requests.</FONT></P>

<P><FONT SIZE=3D2>4.) The Identrus model, shown at &lt;<A =
HREF=3D"http://www.identrus.com/solution.htm" =
TARGET=3D"_blank">http://www.identrus.com/solution.htm</A>&gt;, is =
based on the standard banking four-corner model.&nbsp; Hence a relying =
party will always go to his bank to validate a certificate even if the =
certificate was actually issued by some other bank.&nbsp;&nbsp; The =
protocol must support this.</FONT></P>

<P><FONT SIZE=3D2>5.) The protocol must support use of cached =
responses.&nbsp; As a corollary, it must permit the relying party to =
request a freshly generated response rather than one from it's =
cache.</FONT></P>

<P><FONT SIZE=3D2>6.) The protocol must permit checking of status on =
expired certificates.</FONT>
</P>

<P><FONT SIZE=3D2>Identrus has a task force that is examining a couple =
of protocols to see if these capabilities.&nbsp; One is a proprietary =
protocol and the other is SCVP.&nbsp; For numerous and obvious (at =
least to this group) reasons we would prefer to use SCVP rather than =
anything proprietary.&nbsp; </FONT></P>

<P><FONT SIZE=3D2>Does SCVP meet the above needs?&nbsp; Is it a matter =
of enhancing / modifying it to some degree to bring it in line with =
these needs?&nbsp; My limited understanding of these things suggests =
that SCVP is not an unreasonable candidate.&nbsp; Is there something =
else that, more fully, meets the above requirements?&nbsp; Are there =
other issues we should be considering?&nbsp; </FONT></P>

<P><FONT SIZE=3D2>A discussion on this subject will be of great help in =
developing and / or selecting a suitable protocol.&nbsp; If the =
tremendous brainpower of this group could be brought to bear on this =
subject, it will undoubtedly yield the necessary results.</FONT></P>

<P><FONT SIZE=3D2>Do let me know or contact me for further information =
/ clarifications.</FONT>
<BR><FONT SIZE=3D2>Thanks and Regards. </FONT>
<BR><FONT SIZE=3D2>Khaja </FONT>
<BR><FONT =
SIZE=3D2>=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D =
</FONT>
<BR><FONT SIZE=3D2>Khaja E. Ahmed </FONT>
<BR><FONT SIZE=3D2>Chief Technology Officer </FONT>
<BR><FONT SIZE=3D2>Identrus, LLC. </FONT>
<BR><FONT SIZE=3D2>16th Floor </FONT>
<BR><FONT SIZE=3D2>140 E 45th St. </FONT>
<BR><FONT SIZE=3D2>New York, NY 10017 USA </FONT>
<BR><FONT SIZE=3D2>Telephone: [phone] </FONT>
<BR><FONT SIZE=3D2>Fax: [phone] </FONT>
<BR><FONT SIZE=3D2>[e-mail] </FONT>
<BR><FONT SIZE=3D2>Office Direct: 01.925.989.6564 </FONT>
<BR><FONT SIZE=3D2>Office Main: 01.212.622.1524 </FONT>
<BR><FONT =
SIZE=3D2>=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D =
</FONT>
</P>

</BODY>
</HTML>
------_=_NextPart_001_01BFEFA7.A25901B0--


Received: from blue.identrus.com ([216.213.93.121]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id NAA16132 for <[e-mail]>; Sun, 16 Jul 2000 13:18:52 -0700 (PDT)
Received: by blue.identrus.com with Internet Mail Service (5.5.2650.21) id <N9QANDTH>; Sun, 16 Jul 2000 16:20:59 -0400
Message-ID: <[e-mail]>
From: Khaja Ahmed <[e-mail]>
To: "'Eric Rescorla '" <[e-mail]>, "'Adrian McCullagh '" <[e-mail]>
Cc: "''Stephen Kent' '" <[e-mail]>, "'[e-mail] '" <[e-mail]>, "'[e-mail] '" <[e-mail]>
Subject: RE: Signing what you don't understand
Date: Sun, 16 Jul 2000 16:20:58 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
List-Unsubscribe: mailto:[e-mail]?body=unsubscribe
Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01BFEF63.5A55B4C0"

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01BFEF63.5A55B4C0
Content-Type: text/plain;
	charset="iso-8859-1"

Perhaps I have not followed this thread in its entirety and if this has
already been sorted out please ignore this but...

I am wondering if it is meaningful to discuss digital signatures without
considering things like:

1.) The applicable certificate policy.
2.) Was nonRepudiation enabled in KeyUsage
3.) The governing law under which the certificate has been issued and is
being used.  (Closed contractual community vs. local / regiona / national
law)

I am not sure what we will learn from this dicussion without these facets
added to it.

Do the above account for automatic signatures? Is it expected (indeed
required) that the signer have (demonstrably) full knowledge of what was
being signed?

Do people think it is worth our while (or even possible) to take a
hypothical certificate policy, add some assumptions about governing law  and
see where this discussion goes?

At Identrus we are examining this issue in the context of our own policies
and governing law and would like to see what the collective wisdom of this
group brings to light.

Thanks and Regards.

Khaja
=========================================== 
Khaja E. Ahmed 
Chief Technology Officer
Identrus, LLC. 
16th Floor 
140 E 45th St. 
New York, NY 10017 USA 
Telephone: [phone] 
Fax: [phone] 
[e-mail] 
Office Direct: 01.925.989.6564 
Office Main: 01.212.622.1524 
============================================ 

  

-----Original Message-----
From: Eric Rescorla
To: Adrian McCullagh
Cc: 'Stephen Kent'; [e-mail]; [e-mail]
Sent: 7/15/00 1:09 AM
Subject: Re: Signing what you don't understand

Adrian McCullagh <[e-mail]> writes:
> I really do not understand your response.  Why would anyone sign a
document
> that they do not understand.  It does not make sense.
People perform digital signatures of data they don't understand all the
time. One most common case is cryptographic protocols which use
digital signature for authentication of various kinds of keying
material. (SSL and IKE both do this). Note that these signatures
are often completely automatic.

Now, as a matter of cryptographic practice, one generally arranges
that neither party completely controls the input to the signature to
to prevent one party from forcing another to sign an arbitrary
document. However, as a matter of defense in depth, it's also nice
to have those keys tagged in such a way that even if the protocol
protections were broken, the signature still couldn't be used against
the signer.

Part of the issue here is that digital signature is a cryptographic
primitive that can be used for other purposes than those which
holographic signatures are currently used.

-Ekr

[Eric Rescorla                                   [e-mail]]


------_=_NextPart_001_01BFEF63.5A55B4C0
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Diso-8859-1">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
5.5.2650.12">
<TITLE>RE: Signing what you don't understand</TITLE>
</HEAD>
<BODY>

<P><FONT SIZE=3D2>Perhaps I have not followed this thread in its =
entirety and if this has already been sorted out please ignore this =
but...</FONT></P>

<P><FONT SIZE=3D2>I am wondering if it is meaningful to discuss digital =
signatures without considering things like:</FONT>
</P>

<P><FONT SIZE=3D2>1.) The applicable certificate policy.</FONT>
<BR><FONT SIZE=3D2>2.) Was nonRepudiation enabled in KeyUsage</FONT>
<BR><FONT SIZE=3D2>3.) The governing law under which the certificate =
has been issued and is being used.&nbsp; (Closed contractual community =
vs. local / regiona / national law)</FONT></P>

<P><FONT SIZE=3D2>I am not sure what we will learn from this dicussion =
without these facets added to it.</FONT>
</P>

<P><FONT SIZE=3D2>Do the above account for automatic signatures? Is it =
expected (indeed required) that the signer have (demonstrably) full =
knowledge of what was being signed?</FONT></P>

<P><FONT SIZE=3D2>Do people think it is worth our while (or even =
possible) to take a hypothical certificate policy, add some assumptions =
about governing law&nbsp; and see where this discussion =
goes?</FONT></P>

<P><FONT SIZE=3D2>At Identrus we are examining this issue in the =
context of our own policies and governing law and would like to see =
what the collective wisdom of this group brings to light.</FONT></P>

<P><FONT SIZE=3D2>Thanks and Regards.</FONT>
</P>

<P><FONT SIZE=3D2>Khaja</FONT>
<BR><FONT =
SIZE=3D2>=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D =
</FONT>
<BR><FONT SIZE=3D2>Khaja E. Ahmed </FONT>
<BR><FONT SIZE=3D2>Chief Technology Officer</FONT>
<BR><FONT SIZE=3D2>Identrus, LLC. </FONT>
<BR><FONT SIZE=3D2>16th Floor </FONT>
<BR><FONT SIZE=3D2>140 E 45th St. </FONT>
<BR><FONT SIZE=3D2>New York, NY 10017 USA </FONT>
<BR><FONT SIZE=3D2>Telephone: [phone] </FONT>
<BR><FONT SIZE=3D2>Fax: [phone] </FONT>
<BR><FONT SIZE=3D2>[e-mail] </FONT>
<BR><FONT SIZE=3D2>Office Direct: 01.925.989.6564 </FONT>
<BR><FONT SIZE=3D2>Office Main: 01.212.622.1524 </FONT>
<BR><FONT =
SIZE=3D2>=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D =
</FONT>
</P>

<P><FONT SIZE=3D2>&nbsp; </FONT>
</P>

<P><FONT SIZE=3D2>-----Original Message-----</FONT>
<BR><FONT SIZE=3D2>From: Eric Rescorla</FONT>
<BR><FONT SIZE=3D2>To: Adrian McCullagh</FONT>
<BR><FONT SIZE=3D2>Cc: 'Stephen Kent'; [e-mail]; =
[e-mail]</FONT>
<BR><FONT SIZE=3D2>Sent: 7/15/00 1:09 AM</FONT>
<BR><FONT SIZE=3D2>Subject: Re: Signing what you don't =
understand</FONT>
</P>

<P><FONT SIZE=3D2>Adrian McCullagh =
&lt;[e-mail]&gt; writes:</FONT>
<BR><FONT SIZE=3D2>&gt; I really do not understand your response.&nbsp; =
Why would anyone sign a</FONT>
<BR><FONT SIZE=3D2>document</FONT>
<BR><FONT SIZE=3D2>&gt; that they do not understand.&nbsp; It does not =
make sense.</FONT>
<BR><FONT SIZE=3D2>People perform digital signatures of data they don't =
understand all the</FONT>
<BR><FONT SIZE=3D2>time. One most common case is cryptographic =
protocols which use</FONT>
<BR><FONT SIZE=3D2>digital signature for authentication of various =
kinds of keying</FONT>
<BR><FONT SIZE=3D2>material. (SSL and IKE both do this). Note that =
these signatures</FONT>
<BR><FONT SIZE=3D2>are often completely automatic.</FONT>
</P>

<P><FONT SIZE=3D2>Now, as a matter of cryptographic practice, one =
generally arranges</FONT>
<BR><FONT SIZE=3D2>that neither party completely controls the input to =
the signature to</FONT>
<BR><FONT SIZE=3D2>to prevent one party from forcing another to sign an =
arbitrary</FONT>
<BR><FONT SIZE=3D2>document. However, as a matter of defense in depth, =
it's also nice</FONT>
<BR><FONT SIZE=3D2>to have those keys tagged in such a way that even if =
the protocol</FONT>
<BR><FONT SIZE=3D2>protections were broken, the signature still =
couldn't be used against</FONT>
<BR><FONT SIZE=3D2>the signer.</FONT>
</P>

<P><FONT SIZE=3D2>Part of the issue here is that digital signature is a =
cryptographic</FONT>
<BR><FONT SIZE=3D2>primitive that can be used for other purposes than =
those which</FONT>
<BR><FONT SIZE=3D2>holographic signatures are currently used.</FONT>
</P>

<P><FONT SIZE=3D2>-Ekr</FONT>
</P>

<P><FONT SIZE=3D2>[Eric =
Rescorla&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
[e-mail]]</FONT>
</P>

</BODY>
</HTML>
------_=_NextPart_001_01BFEF63.5A55B4C0--


Received: from blount.mail.mindspring.net (blount.mail.mindspring.net [207.69.200.226]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id WAA23697 for <[e-mail]>; Fri, 14 Jul 2000 22:32:38 -0700 (PDT)
Received: from romeo.rtfm.com (user-33qtiij.dialup.mindspring.com [199.174.202.83]) by blount.mail.mindspring.net (8.9.3/8.8.5) with ESMTP id BAA12592; Sat, 15 Jul 2000 01:33:47 -0400 (EDT)
Received: (ekr@localhost) by romeo.rtfm.com (8.9.3/8.6.4) id WAA03080; Fri, 14 Jul 2000 22:09:26 -0700 (PDT)
Sender: [e-mail]
To: Adrian McCullagh <[e-mail]>
Cc: "'Stephen Kent'" <[e-mail]>, [e-mail], [e-mail]
Subject: Re: Signing what you don't understand
References: <[e-mail]>
Reply-to: EKR <[e-mail]>
Mime-Version: 1.0 (generated by tm-edit 7.108)
Content-Type: text/plain; charset=US-ASCII
From: Eric Rescorla <[e-mail]>
Date: 14 Jul 2000 22:09:25 -0700
In-Reply-To: Adrian McCullagh's message of "Sat, 15 Jul 2000 12:50:52 +1000"
Message-ID: <[e-mail]>
Lines: 26
X-Mailer: Gnus v5.6.45/XEmacs 20.4 - "Emerald"

Adrian McCullagh <[e-mail]> writes:
> I really do not understand your response.  Why would anyone sign a document
> that they do not understand.  It does not make sense.
People perform digital signatures of data they don't understand all the
time. One most common case is cryptographic protocols which use
digital signature for authentication of various kinds of keying
material. (SSL and IKE both do this). Note that these signatures
are often completely automatic.

Now, as a matter of cryptographic practice, one generally arranges
that neither party completely controls the input to the signature to
to prevent one party from forcing another to sign an arbitrary
document. However, as a matter of defense in depth, it's also nice
to have those keys tagged in such a way that even if the protocol
protections were broken, the signature still couldn't be used against
the signer.

Part of the issue here is that digital signature is a cryptographic
primitive that can be used for other purposes than those which
holographic signatures are currently used.

-Ekr

[Eric Rescorla                                   [e-mail]]




Received: from ext-mail.valicert.com (ns1.valicert.com [63.65.221.10]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id UAA19796 for <[e-mail]>; Fri, 14 Jul 2000 20:44:01 -0700 (PDT)
Received: from CONVERSION-DAEMON.ext-mail.valicert.com by ext-mail.valicert.com (PMDF V6.0-24 #46243) id <[e-mail]> for [e-mail]; Fri, 14 Jul 2000 20:46:10 -0700 (PDT)
Received: from seine.valicert.com ([192.168.2.23]) by ext-mail.valicert.com (PMDF V6.0-24 #46243) with ESMTP id <[e-mail]>; Fri, 14 Jul 2000 20:46:10 -0700 (PDT)
Received: by seine.valicert.com with Internet Mail Service (5.5.2650.21) id <36006BV8>; Fri, 14 Jul 2000 20:38:18 -0700
Content-return: allowed
Date: Fri, 14 Jul 2000 20:38:18 -0700
From: Frank Balluffi <[e-mail]>
Subject: RE: Signing what you don't understand
To: "'Adrian McCullagh'" <[e-mail]>, "'Stephen Kent'" <[e-mail]>, [e-mail]
Cc: [e-mail]
Message-id: <[e-mail]>
MIME-version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-type: text/plain; charset=iso-8859-1

Adrian,

I do not think Steve is advocating anyone sign a document they do not
understand. I think he is saying a signature by itself is not binding to a
person or a device. A certificate binds a signature to a person or a device.

Frank

> -----Original Message-----
> From: Adrian McCullagh [mailto:[e-mail]]
> Sent: Friday, July 14, 2000 10:51 PM
> To: 'Stephen Kent'; [e-mail]
> Cc: [e-mail]
> Subject: RE: Signing what you don't understand
> 
> 
> Stephen
> 
> I really do not understand your response.  Why would anyone 
> sign a document
> that they do not understand.  It does not make sense.  If I sent you a
> document written in Chinese and assume you can not read 
> Chinese and at the
> same time I said just sign this - Why would you sign it.  Now 
> if you trusted
> me then you may sign it based upon the information about the 
> document that I
> tell you.  A classic case for Non-est-factum.  But all the 
> cases that I have
> read clearly rely upon some information provided by an 
> Alleged trusted third
> party.  Usually some relative.  So without some external 
> information being
> provided by a third party it is not as far as I can determine 
> possible to
> rely upon non est factum.   
> 
> Also what does a "bit" in a certificate got to do with 
> non-repudiation.  The
> commercial world and the law does not in my opinion support 
> this position of
> yours.  You appear to be on a path to re-engineering the 
> entire commercial
> legal fabric and as such I with the greatest respect I do not 
>  believe that
> society and the law will buy into it.  With out the 
> commercial involvement
> PKI will not survive.
> 
> I do not understand how - "what you are proposing" - will 
> work in practical
> terms.
> 
>  
> 
> Adrian McCullagh
> Director of Electronic Commerce		Tel: [phone]
> Gadens Lawyers					Fax: 
> 617 3229 5850	
> level 39
> Central Plaza 1
> 345 Queen Street
> Brisbane Australia 4000
> 
> Ph. D. Candidate 
> Thesis "The Incorporation of Trust Strategies in Digital Signature
> Regimes for Elec. Comm."
> Information Security Research Centre
> Queensland University of Technology
> 
> 
> 
> -----Original Message-----
> From: Stephen Kent [mailto:[e-mail]]
> Sent: Thursday, July 13, 2000 11:49 PM
> To: [e-mail]
> Cc: [e-mail]
> Subject: Re: Signing what you don't understand
> 
> 
> Denis,
> 
> >The most important point of my previous message was buried 
> under a pile of
> >other stuff, so I am repeating it here:
> >
> >
> >It is my proposal that a signature format is designed which 
> will allow an
> >entity to say: "I signed this data, but I didn't understand 
> what I signed.
> >You are free to use this signature as proof that I possess a certain
> private
> >key, but this is also the only purpose for which this 
> signature can be
> >used."
> 
> We have had an analogous debate on this list last year.  This is one 
> motivation for the use of the non-repudiation bit in certificates, 
> i.e., if this bit is NOT asserted, one can reasonably interpret the 
> signature as not binding.  This does not require a change to the 
> signing format, but rather appropriate use of key usage bits in 
> certificates. As others have pointed out, the preferred way to 
> represent the distinction between binding and non-binding signatures 
> is via flags in certificates, e.g., key usage, cert policy, etc.
> 
> Steve
> 


Received: from hamster.gadens.com.au ([e-mail] [203.32.220.10]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id TAA15225 for <[e-mail]>; Fri, 14 Jul 2000 19:46:02 -0700 (PDT)
Received: from exchange.gadens.com.au ([10.1.8.3]) by hamster.gadens.com.au (8.9.3/8.9.3) with ESMTP id MAA34277; Sat, 15 Jul 2000 12:47:28 +1000 (EST) (envelope-from [e-mail])
Received: by exchange.gadens.com.au with Internet Mail Service (5.5.2650.21) id <3YWS6GZB>; Sat, 15 Jul 2000 12:50:55 +1000
Message-ID: <[e-mail]>
From: Adrian McCullagh <[e-mail]>
To: "'Stephen Kent'" <[e-mail]>, [e-mail]
Cc: [e-mail]
Subject: RE: Signing what you don't understand
Date: Sat, 15 Jul 2000 12:50:52 +1000
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain; charset="iso-8859-1"

Stephen

I really do not understand your response.  Why would anyone sign a document
that they do not understand.  It does not make sense.  If I sent you a
document written in Chinese and assume you can not read Chinese and at the
same time I said just sign this - Why would you sign it.  Now if you trusted
me then you may sign it based upon the information about the document that I
tell you.  A classic case for Non-est-factum.  But all the cases that I have
read clearly rely upon some information provided by an Alleged trusted third
party.  Usually some relative.  So without some external information being
provided by a third party it is not as far as I can determine possible to
rely upon non est factum.   

Also what does a "bit" in a certificate got to do with non-repudiation.  The
commercial world and the law does not in my opinion support this position of
yours.  You appear to be on a path to re-engineering the entire commercial
legal fabric and as such I with the greatest respect I do not  believe that
society and the law will buy into it.  With out the commercial involvement
PKI will not survive.

I do not understand how - "what you are proposing" - will work in practical
terms.

 

Adrian McCullagh
Director of Electronic Commerce		Tel: [phone]
Gadens Lawyers					Fax: [phone]	
level 39
Central Plaza 1
345 Queen Street
Brisbane Australia 4000

Ph. D. Candidate 
Thesis "The Incorporation of Trust Strategies in Digital Signature
Regimes for Elec. Comm."
Information Security Research Centre
Queensland University of Technology



-----Original Message-----
From: Stephen Kent [mailto:[e-mail]]
Sent: Thursday, July 13, 2000 11:49 PM
To: [e-mail]
Cc: [e-mail]
Subject: Re: Signing what you don't understand


Denis,

>The most important point of my previous message was buried under a pile of
>other stuff, so I am repeating it here:
>
>
>It is my proposal that a signature format is designed which will allow an
>entity to say: "I signed this data, but I didn't understand what I signed.
>You are free to use this signature as proof that I possess a certain
private
>key, but this is also the only purpose for which this signature can be
>used."

We have had an analogous debate on this list last year.  This is one 
motivation for the use of the non-repudiation bit in certificates, 
i.e., if this bit is NOT asserted, one can reasonably interpret the 
signature as not binding.  This does not require a change to the 
signing format, but rather appropriate use of key usage bits in 
certificates. As others have pointed out, the preferred way to 
represent the distinction between binding and non-binding signatures 
is via flags in certificates, e.g., key usage, cert policy, etc.

Steve


Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id RAA26615 for <[e-mail]>; Fri, 14 Jul 2000 17:05:24 -0700 (PDT)
Received: from ISI.EDU (jet.isi.edu [128.9.160.87]) by boreas.isi.edu (8.9.3/8.9.3) with ESMTP id RAA04191; Fri, 14 Jul 2000 17:07:26 -0700 (PDT)
Message-Id: <[e-mail]>
To: IETF-Announce: ;
Subject: RFC 2875 on Diffie-Hellman Proof-of-Possession Algorithms
Cc: [e-mail], [e-mail]
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary=NextPart
Date: Fri, 14 Jul 2000 17:07:26 -0700
From: RFC Editor <[e-mail]>

--NextPart


A new Request for Comments is now available in online RFC libraries.


        RFC 2875

        Title:	    Diffie-Hellman Proof-of-Possession Algorithms
        Author(s):  H. Prafullchandra, J. Schaad
        Status:     Standards Track
	Date:       July 2000
        Mailbox:    [e-mail], [e-mail]
        Pages:      23
        Characters: 45231
        Updates/Obsoletes/SeeAlso:  None

        I-D Tag:    draft-ietf-pkix-dhpop-03.txt

        URL:        ftp://ftp.isi.edu/in-notes/rfc2875.txt


This document describes two methods for producing an integrity check
value from a Diffie-Hellman key pair.  This behavior is needed for
such operations as creating the signature of a PKCS #10
certification request.  These algorithms are designed to provide a
proof-of-possession rather than general purpose signing.

This document is a product of the Public-Key Infrastructure (X.509)
Working Group of the IETF.

This is now a Proposed Standard Protocol.

This document specifies an Internet standards track protocol for
the Internet community, and requests discussion and suggestions
for improvements.  Please refer to the current edition of the
"Internet Official Protocol Standards" (STD 1) for the
standardization state and status of this protocol.  Distribution
of this memo is unlimited.

This announcement is sent to the IETF list and the RFC-DIST list.
Requests to be added to or deleted from the IETF distribution list
should be sent to [e-mail].  Requests to be
added to or deleted from the RFC-DIST distribution list should
be sent to [e-mail].

Details on obtaining RFCs via FTP or EMAIL may be obtained by sending
an EMAIL message to [e-mail] with the message body 
help: ways_to_get_rfcs.  For example:

        To: [e-mail]
        Subject: getting rfcs

        help: ways_to_get_rfcs

Requests for special distribution should be addressed to either the
author of the RFC in question, or to [e-mail].  Unless
specifically noted otherwise on the RFC itself, all RFCs are for
unlimited distribution.echo 
Submissions for Requests for Comments should be sent to
[e-mail].  Please consult RFC 2223, Instructions to RFC
Authors, for further information.


Joyce K. Reynolds and Sandy Ginoza
USC/Information Sciences Institute

...

Below is the data which will enable a MIME compliant Mail Reader 
implementation to automatically retrieve the ASCII version
of the RFCs.

--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"

--OtherAccess
Content-Type:  Message/External-body;
        access-type="mail-server";
        server="[e-mail]"

Content-Type: text/plain
Content-ID: <[e-mail]>

RETRIEVE: rfc
DOC-ID: rfc2875

--OtherAccess
Content-Type:   Message/External-body;
        name="rfc2875.txt";
        site="ftp.isi.edu";
        access-type="anon-ftp";
        directory="in-notes"

Content-Type: text/plain
Content-ID: <[e-mail]>

--OtherAccess--
--NextPart--


Received: from mail.moh.hnet.bc.ca (mail.moh.hnet.bc.ca [142.36.56.10]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id QAA20357 for <[e-mail]>; Fri, 14 Jul 2000 16:14:28 -0700 (PDT)
Received: from moh.hnet.bc.ca ([142.36.11.183]) by mail.moh.hnet.bc.ca (Netscape Messaging Server 3.61)  with ESMTP id AAA5F7F; Fri, 14 Jul 2000 16:16:15 -0700
Message-ID: <[e-mail]>
Date: Fri, 14 Jul 2000 16:16:24 -0700
From: "Doug M Williscroft" <[e-mail]>
X-Mailer: Mozilla 4.51 [en] (WinNT; U)
X-Accept-Language: en
MIME-Version: 1.0
To: [e-mail]
CC: [e-mail]
Subject: Re: Trading Partner Web Certificates
References: <[e-mail]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

[e-mail] wrote:
> Doug, your design below requires distribution of the private key of the
> trading partner to each of its employees allowed to access your site. This
> clearly creates significant exposure to this key. 

Amir, 
You are correct that the primary risk is in the broad distribution of
the private key within an organization. Since the key is *intended* to
identify the organization this would not be a risk *at all* if it could
be 'guaranteed' that the private key could not be removed from the
machine on which it has been installed. 

IE5 offers exactly this function, though I understand that there is
reasonable doubt about the quality of the function. I understand that
there is the possibility of attacks against the design and
implementation of the MS base cryptoprovider. All documents I have seen
on this topic are in reference to older versions of IE, though some of
the criticisms were against core design choices made in the cryptoAPI.
Even so the avenues of attack are enormously reduced over simple SSL and
uid/pwd. 

To reduce/eliminate the risk you identify, it would be nice to see a
cryptoprovider that could truly "lock-down" the private key. 

As I see it, a equally important issue is ease of administration; it
would be helpful if there were a way for an organization to easily and
centrally install the trading partner certificate on all relevant
machines.


> What are the reasons for
> taking this risk, rather than having the trading partner (or you) issue
> certificates to each employee of the business partner allowed to access
> your site?


Why do we not issue individual certs to individual staff of external
trading partners:
 * Cost of issuance is unnecessarily high:
      requires tight integration with external trading partner hiring
practices. 
      Furthermore, organizational linkages are so loose, and lag times
so great, 
      that certificates cannot be certain to be revoked in a timely
manner. Individuals 
      would potentially retain access to our system long after they had
left the employ 
      of the trading partner. By using a locked down trading partner
cert, once the 
      ex-employee leaves the premises, they lose access.

* Cost of certificate administration very high for trading partners. 
      Several of our larger trading partners have staff that move from
workstation 
      to workstation. Individual certs introduce the need to manage the
details of 
      which workstations get which certificates. "Trading partner"
certificates 
      sidestep this issue entirely.

Why not have trading partner issue individual certs:
* Almost all (99% +) of our trading partners do not have the technical
or financial 
      ability to operate an internal CA. 
* Some smaller portion of them (80%?)do not have the financial
wherewithal to contract 
      CA services.
* Purchasing low assurance commercial certificates presents
administrative issues 
      (one year expiry increases effort required by both ourselves and
the trading partners).
* For many of our trading partners the cost of administering individual
certificates 
      is very high (shared workstations and roaming). 

-- 
Doug Williscroft
HealthNet/BC Architecture and Standards Branch
Ministry of Health Information Management Group

Telephone: [phone]
_______________________________________________


Received: from mail.spyrus.com (mail.spyrus.com [207.212.34.20]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id OAA16522 for <[e-mail]>; Fri, 14 Jul 2000 14:41:51 -0700 (PDT)
Received: from rhousley_laptop ([209.172.119.209]) by mail.spyrus.com (8.9.3/8.9.3) with ESMTP id OAA11257; Fri, 14 Jul 2000 14:43:24 -0700 (PDT)
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58 
Date: Fri, 14 Jul 2000 17:25:04 -0400
To: Renato Portela <[e-mail]>
From: Russ Housley <[e-mail]>
Subject: Re: ASN.1
Cc: <[e-mail]>
In-Reply-To: <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed

RFC 2459 uses the 1988 version of ASN.1.  X.509 uses the most current 
version.  Both result in the exact same bits on the wire.

Russ


At 02:51 PM 07/14/2000 +0100, Renato Portela wrote:
>Hi,
>
>The X.509 and the RFC2459 both define a certificate but the asn.1 used to
>define it is different.
>Why are they different?
>The encoding result of those Certificates is equal?
>
>The RFC2560 import Certificate from AuthenticationFramework.
>Should I use that definition or the definition of Certificate in RFC2459?
>
>Thanks in advance
>Renato Portela



Received: from wfhqex05.wangfed.com (netva01.wangfed.com [206.137.100.2]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id OAA14719; Fri, 14 Jul 2000 14:00:17 -0700 (PDT)
Received: by wfhqex05.wangfed.com with Internet Mail Service (5.5.2650.21) id <3GNFB4M2>; Fri, 14 Jul 2000 17:01:39 -0400
Message-ID: <[e-mail]>
From: "Pawling, John" <[e-mail]>
To: "Pawling, John" <[e-mail]>
Subject: v1.71 Certificate Management Library Now Available
Date: Fri, 14 Jul 2000 17:01:32 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain; charset="iso-8859-1"

All,

Wang Government Services, Inc. (WGSI), A Getronics Company, has delivered
the Version 1.71 Certificate Management Library (CML).  The v1.71 CML is
freely available to everyone from the Fortezza Developers CML Page
<http://www.armadillo.huntsville.al.us/software/certmgmt/index.html>.  

The v1.71 CML is described in the v1.7 CML Application Programming Interface
(API) document.  It implements the 1997 X.509 certification path processing
rules.  It meets the majority of RFC 2459 and SDN.706 requirements.  It
(optionally) provides local cache management functions and (optionally)
obtains data objects using LDAP.  It can (optionally) be used in conjunction
with the v1.31 Certificate Path Development Library (CPDL) developed by
CygnaCom Solutions, an Entrust Technologies company, to provide robust
certification path building capabilities such as using cross certificates.
The CML has been used to validate X.509 Certificates and Certificate
Revocation Lists (CRL) signed using the Digital Signature Algorithm (DSA)
and RSA.   Further enhancements, ports and testing of the CML are still in
process.  Further releases of the CML will be provided as significant
capabilities are added. 

The following v1.71 CML files are available:
CMLv171win.zip: MS Windows Dynamically Linked Libraries (DLL) 
CML171so.tar.Z: Sun Solaris Libraries 
CML171sr.tar.Z: Source, including Windows project files 

The aforementioned files and the v1.7 CML API document (CMv1_7api.doc,
CMv1_7api.pdf), test certs (cml171data.zip) and readme.txt files are stored
on the Fortezza Developers CML Page.

The v1.71 CML includes the following enhancements (compared with the v1.7
CML release):

1) Tested with the SNACC, Crypto Token Interface Libraries (CTIL) and
LibCert DLL delivered with the v1.7 S/MIME Freeware Library (SFL) available
from Fortezza Developer's S/MIME Page
<http://www.armadillo.huntsville.al.us/software/smime>.

2) Re-configured directory structure for CML source code files so that it is
consistent with the SFL and Access Control Library (ACL).  

3) Diffie-Hellman logic in CM_RetrieveKey and CM_DecodeCert cleaned up.

4) Corrected several bugs reported by customers.

5) Performed regression testing to ensure that aforementioned enhancements
did not break existing CML functionality.

WGSI welcomes all feedback regarding the CML software and documents.  If
bugs are reported, then we will investigate each reported bug and, if
required, will produce a patch or an updated release of the software to
repair the bug.

All source code for the CML is being provided at no cost and with no
financial limitations regarding its use and distribution. Organizations can
use the CML without paying any royalties or licensing fees.  The CML was
originally developed by the U.S. Government.  WGSI is enhancing and
supporting the CML under contract to the U.S. Government.  The U.S.
Government is furnishing the CML software at no cost to the vendor subject
to the conditions of the CML Public License provided with the CML software.
The CML software is not subject to U.S. Government encryption export
regulations, so it is freely available to everyone.

The v1.71 CML uses the WGSI v1.3 Enhanced SNACC ASN.1 Library to
encode/decode objects.  WGSI has successfully tested the v1.71 CML with the
SNACC and CTIL DLLs delivered in conjunction with the v1.7 SFL.  Source code
for the WGSI-developed CTILs is available from the Fortezza Developer's
S/MIME Page.  The actual crypto libraries are not provided with the CML or
SFL.  They must be independently obtained from the appropriate source.  

The v1.71 CML can be used in conjunction with the v1.31 CPDL to successfully
meet all of the requirements of the Bridge Certification Authority
Demonstration effort which includes cross-certified Entrust, Spyrus and
Motorola v3 certificate domains.  The CML171sr.tar.Z file includes the CPDL
source code and public license.  <http://www.cygnacom.com/cpl> provides more
information regarding the CPDL.

The Internet Mail Consortium (IMC) has established a CML web page
<http://www.imc.org/imc-cml>   
and a CML mail list which is used to: distribute information regarding CML
releases; discuss CML-related issues; and allow CML users to provide
feedback, comments, bug reports, etc.  Subscription information for the
imc-cml mailing list is at the IMC web site listed above.  

All comments regarding the CML source code and documents are welcome. This
CML release announcement was sent to several mail lists, but please send all
messages regarding the CML to the imc-cml mail list ONLY.  Please do not
send messages regarding the CML to any of the IETF mail lists.  We will
respond to all messages sent to the imc-cml mail list.

============================================
John Pawling, [e-mail]
Wang Government Services, Inc.,
A Getronics Company
============================================ 


Received: from ext-mail.valicert.com (ns1.valicert.com [63.65.221.10]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id NAA13357 for <[e-mail]>; Fri, 14 Jul 2000 13:24:22 -0700 (PDT)
Received: from CONVERSION-DAEMON.ext-mail.valicert.com by ext-mail.valicert.com (PMDF V6.0-24 #46243) id <[e-mail]> for [e-mail]; Fri, 14 Jul 2000 13:26:24 -0700 (PDT)
Received: from seine.valicert.com ([192.168.2.23]) by ext-mail.valicert.com (PMDF V6.0-24 #46243) with ESMTP id <[e-mail]>; Fri, 14 Jul 2000 13:26:24 -0700 (PDT)
Received: by seine.valicert.com with Internet Mail Service (5.5.2650.21) id <36006AMS>; Fri, 14 Jul 2000 13:18:34 -0700
Content-return: allowed
Date: Fri, 14 Jul 2000 13:18:33 -0700
From: Frank Balluffi <[e-mail]>
Subject: RE:
To: "'Renato Portela'" <[e-mail]>, "'[e-mail]'" <[e-mail]>
Message-id: <[e-mail]>
MIME-version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-type: text/plain; charset=iso-8859-1

Renato,

RFC 2459 contains two complete ASN.1 definitions:

one in 1988 syntax (beginning on page 69), and
one in 1993 syntax (beginning on page 90)

X.509 uses the 1993 syntax.

I BELIEVE that the IETF and X5 are committed to aligning both documents.

RFC 2459 has one obvious advantage over X.509. RFC 2459 is free.

Frank

> -----Original Message-----
> From: Renato Portela [mailto:[e-mail]]
> Sent: Friday, July 14, 2000 9:51 AM
> To: '[e-mail]'
> Subject: 
> 
> 
> Hi,
> 
> The X.509 and the RFC2459 both define a certificate but the 
> asn.1 used to
> define it is different. 
> Why are they different?
> The encoding result of those Certificates is equal?
> 
> The RFC2560 import Certificate from AuthenticationFramework.
> Should I use that definition or the definition of Certificate 
> in RFC2459?
> 
> Thanks in advance
> Renato Portela
> 


Received: from freeby.ben.algroup.co.uk (sockittome.aldigital.co.uk [194.128.162.252]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id NAA12492 for <[e-mail]>; Fri, 14 Jul 2000 13:11:05 -0700 (PDT)
Received: from algroup.co.uk (naughty.ben.algroup.co.uk [193.133.15.107]) by freeby.ben.algroup.co.uk (8.6.12/8.6.12) with ESMTP id VAA22255; Fri, 14 Jul 2000 21:24:21 +0100
Message-ID: <[e-mail]>
Date: Fri, 14 Jul 2000 21:11:56 +0100
From: Ben Laurie <[e-mail]>
Organization: A.L. Group plc
X-Mailer: Mozilla 4.7 [en] (WinNT; I)
MIME-Version: 1.0
To: "Heimberg, Jim" <[e-mail]>
CC: "'Paul Koning'" <[e-mail]>, [e-mail], [e-mail], [e-mail], [e-mail], [e-mail]
Subject: Re: QC DN "qualities".  Was: I-D ACTION:draft-ietf-pkix-qc-04.txt
References: <[e-mail]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

"Heimberg, Jim" wrote:
> 
> OK, maybe my meager mind is confused, this being Friday and all.  I can't
> refrain from asking the obvious question.  Is there confusion between what a
> distinguished name is and what a common name is.  Since the DN is a
> contatenation of the common name and the domain path to it in the common
> directory structure for that domain, I have trouble envisioning DNs that are
> not unique unless there is a plan afoot to create duplicate domains using
> the same domain names. ???

Will this never end? The problem is that there is no "domain path to it
in the common directory structure for that domain" coz that's the bit
that never happened (i.e. a global infrastructure for unique DN
allocation).

Cheers,

Ben.

--
http://www.apache-ssl.org/ben.html

Coming to ApacheCon Europe 2000? http://apachecon.com/


Received: from roadblock.missi.ncsc.mil (roadblock.missi.ncsc.mil [144.51.50.70]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id NAA11771 for <[e-mail]>; Fri, 14 Jul 2000 13:03:05 -0700 (PDT)
Received: from roadblock.missi.ncsc.mil (root@localhost) by roadblock.missi.ncsc.mil with ESMTP id PAA03102 for <[e-mail]>; Fri, 14 Jul 2000 15:54:24 -0400 (EDT)
Message-Id: <[e-mail]>
Date: Fri, 14 Jul 2000 16:01:37 -0400 (EDT)
From: "David P. Kemp" <[e-mail]>
Reply-To: "David P. Kemp" <[e-mail]>
Subject: Re: I-D ACTION:draft-ietf-pkix-qc-04.txt
To: [e-mail]
MIME-Version: 1.0
Content-Type: TEXT/plain; charset=us-ascii
Content-MD5: cxrt6dHql/sZR1qYMdw+uQ==
X-Mailer: dtmail 1.3.0 CDE Version 1.3 SunOS 5.7 sun4u sparc

> From: Denis <[e-mail]>

> 
> Full text proposal replacement for 3.1.1:
> 
> 3.1.1  Issuer
> 
> The issuer field SHALL identify the organization responsible for
> issuing the certificate.
> 
> The identity of the issuer SHALL be specified using an appropriate
> subset of the following attributes:
> 
>          domainComponent;
>          countryName;
>          stateOrProvinceName;
>          organizationName;
>          localityName; and
>          serialNumber.
> 
> Additional attributes MAY be present but they SHOULD NOT be necessary to 
identify the issuing
> organization. The first element of the DN shall be the country where the CA is 
operating from.
> 


The last sentence conflicts with the presence of domainComponent as
one of the allowed attributes, as there is no well-defined method of
constructing a DN containing a mixture of DC and other attributes.

If it is necessary to identify the local laws under which the QC is
interpreted, the jurisdiction should be identified using something other
than the first element of the issuer DN.  An "organization responsible
for issuing the certificate" may operate in multiple jurisdictions, so
even where the DN begins with C=xx, interpreting "xx" as a jurisdiction
may be misleading (and should be performed with care :-).  Did the
Stockholm discussion consider the possibility of multi-country CAs?

Dave



Received: from cam-mailer1.bbn.com (cam-mailer1.bbn.com [171.78.68.5]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id MAA09628 for <[e-mail]>; Fri, 14 Jul 2000 12:29:21 -0700 (PDT)
Received: from [128.33.238.40] (TC040.BBN.COM [128.33.238.40]) by cam-mailer1.bbn.com (8.8.8+Sun/8.8.8) with ESMTP id PAA13387; Fri, 14 Jul 2000 15:31:09 -0400 (EDT)
Mime-Version: 1.0
X-Sender: [e-mail] (Unverified)
Message-Id: <v04220801b593769c4f3b@[128.33.238.97]>
In-Reply-To: <000301bfeb5f$e6cf77c0$0201010a@intergalactic>
References: <000301bfeb5f$e6cf77c0$0201010a@intergalactic>
Date: Thu, 13 Jul 2000 09:48:56 -0400
To: <[e-mail]>
From: Stephen Kent <[e-mail]>
Subject: Re: Signing what you don't understand
Cc: <[e-mail]>
Content-Type: text/plain; charset="us-ascii" ; format="flowed"

Denis,

>The most important point of my previous message was buried under a pile of
>other stuff, so I am repeating it here:
>
>
>It is my proposal that a signature format is designed which will allow an
>entity to say: "I signed this data, but I didn't understand what I signed.
>You are free to use this signature as proof that I possess a certain private
>key, but this is also the only purpose for which this signature can be
>used."

We have had an analogous debate on this list last year.  This is one 
motivation for the use of the non-repudiation bit in certificates, 
i.e., if this bit is NOT asserted, one can reasonably interpret the 
signature as not binding.  This does not require a change to the 
signing format, but rather appropriate use of key usage bits in 
certificates. As others have pointed out, the preferred way to 
represent the distinction between binding and non-binding signatures 
is via flags in certificates, e.g., key usage, cert policy, etc.

Steve



Received: from cam-mailer1.bbn.com (cam-mailer1.bbn.com [171.78.68.5]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id MAA09590 for <[e-mail]>; Fri, 14 Jul 2000 12:29:13 -0700 (PDT)
Received: from [128.33.238.40] (TC040.BBN.COM [128.33.238.40]) by cam-mailer1.bbn.com (8.8.8+Sun/8.8.8) with ESMTP id PAA13396; Fri, 14 Jul 2000 15:31:11 -0400 (EDT)
Mime-Version: 1.0
X-Sender: [e-mail] (Unverified)
Message-Id: <v04220800b5911c78c3d2@[128.33.238.73]>
In-Reply-To: <[e-mail]>
References:  <[e-mail]> <v0422080bb58299d62029@[171.78.30.107]> <[e-mail]>
Date: Thu, 13 Jul 2000 09:53:37 -0400
To: Paul Koning <[e-mail]>
From: Stephen Kent <[e-mail]>
Subject: RE: I-D ACTION:draft-ietf-pkix-time-stamp-08.txt. HASH
Cc: [e-mail]
Content-Type: text/plain; charset="us-ascii" ; format="flowed"

><snip>



>The Internet protocol design rule is "be strict in what you send,
>tolerant in what you receive".  It has been known for decades that
>this is the correct rule.  (That doesn't keep some other standards
>bodies from ignoring it, unfortunately.  Then again, there are still
>standards bodies that use two-way connection setup handshakes...)

The quote you cite is based on advice from the late Jon Postel, 
someone I knew well for over 20 years, and with whom I served on the 
IAB for over 12 years.
As I acknowledged earlier, it is appropriate advice in general, but 
not necessarily appropriate for security protocols, and it certainly 
is not an "Internet protocol design rule." Felexibility in input 
acceptance in security protocols provides attackers with more options 
for attacks, hardly a desirable feature.  Our goal is to constrain 
interfaces so as to better understand them and the security 
implications of various combinations of input parameters. So, merely 
citing this general advice is not a basis for making such decisions 
in security protocols.

>Protocols should check those invariants that have to be valid for
>correct operation to result, or for interoperability to be possible.
>Checks beyond that are counterproductive.

If we can be confident that a failure to check certain inputs will 
not result in adverse effects under any circumstances, then we need 
not check them.  However, when a TTP such as a TSA is signing a token 
it is not clear that this is true.

>In particular, the more you check, the more often you have to ECO your
>specs and your implementation as new extensions are registered.  And
>the more often you have to release bugfixes.

Agreed.  But our primary focus is security, so the issue is what 
constitutes the right tradeoff.  New hash algorithms do not arise so 
quickly that a TSA can't anticipate them and the associated size of 
the hash value. Looking at the time it takes for a standards bodies 
to approve such things and assign OIDs, this does not seem hard. 
Also, we're not talking about changes to client software, but rather 
server software/hardware, which is much more amenable to such change 
management.

Steve



Received: from roadblock.missi.ncsc.mil (roadblock.missi.ncsc.mil [144.51.50.70]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id LAA05052 for <[e-mail]>; Fri, 14 Jul 2000 11:34:37 -0700 (PDT)
Received: from roadblock.missi.ncsc.mil (root@localhost) by roadblock.missi.ncsc.mil with ESMTP id OAA10768 for <[e-mail]>; Fri, 14 Jul 2000 14:25:56 -0400 (EDT)
Message-Id: <[e-mail]>
Date: Fri, 14 Jul 2000 14:33:09 -0400 (EDT)
From: "David P. Kemp" <[e-mail]>
Reply-To: "David P. Kemp" <[e-mail]>
Subject: Re: Current signature formats insufficient
To: [e-mail]
MIME-Version: 1.0
Content-Type: TEXT/plain; charset=us-ascii
Content-MD5: EXX+lHhq0omcjTkkP3ogsA==
X-Mailer: dtmail 1.3.0 CDE Version 1.3 SunOS 5.7 sun4u sparc

> From: "Simon McMahon" <[e-mail]>
> 
> I dont agree with either digital alternative for indicating the signers
> intention in a legally binding way, i.e. boosting or removing
> non-repudiation.

Agree!


> Firstly that the certificate's usage attributes should
> dictate anything about the private key since they may not both be stored on
> the same device and the association is not trivial to check,

I don't understand this. The association between private and public
keys is trivial to check, regardless of where the certificate is
stored.

If there is a device that generates keypairs and exports only the
public key for certification (i.e. no private key export), the CA could
certify public keys generated by such devices under physical control of
the CA or its agents.  The CA can then legitimately make a usage
statement that a particular private key may be or cannot be copied, and
such a statement is useful input into a non-repudiation process.
Even with cryptomodules of lesser assurance, a statement that the
private key has been copied or should not be copied is useful, though
to a lesser degree.


> or, secondly,
> that the signature format should indicate my intention when I signed. All of
> my intentions should be indicated in the content of what I signed.

Agree!



Received: from d1o69.telia.com ([e-mail] [62.20.144.241]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id KAA01768 for <[e-mail]>; Fri, 14 Jul 2000 10:55:09 -0700 (PDT)
Received: from mega (t1o69p83.telia.com [62.20.144.83]) by d1o69.telia.com (8.8.8/8.8.8) with SMTP id TAA02637; Fri, 14 Jul 2000 19:56:52 +0200 (CEST)
Message-ID: <001701bfedc5$26f65000$[e-mail]>
From: "Anders Rundgren" <[e-mail]>
To: "Denis Pinkas" <[e-mail]>, "Stefan Santesson" <[e-mail]>, <[e-mail]>, "Paul Halliden" <[e-mail]>
Cc: "IETF-PXIX" <[e-mail]>
Subject: Re: QC DN "qualities". Was: I-D ACTION:draft-ietf-pkix-qc-04.txt
Date: Fri, 14 Jul 2000 20:55:58 +0200
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 4.72.3110.5
X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by ns.secondary.com id KAA01769

Paul,

>Tom
>>
>In fact, X.509v3 section 11.2 has a note which
>>states "a certification authority shall not issue certificates for two
>>users with the same name", 
>>
>This is not the point at dispute. The QC text used to have an additional
>requirement that a QC contained "an unmistakable identity ... which ...
>relates to a specific entity."  It also contained the concept of "a
>corresponding officially registered identity".  
>
>The contentious point is that this requirement has been dropped.  the reason
>is that, in some jurisdictions there is simply no support for the
>"unmistakable" concept.  Thus the subject name can be unique within the CA's
>name space. 

This last line is actually the thing requested by Denis and by me!

But even that is said to be impossible to achieve for reasons so
far not particularly well explained.

I.e. this requirement is purely technical and has nothing to do with official
identities etc.  It simply requires CAs to keep track of its own subjects and
not issue ambigious DNs or resissue already used DNs.

Involves IMO no politics or magic, just plain engineering.

If resolved it affects things like cert compares.

Anders




Received: from sothmxs01.entrust.com (gatekeeper.entrust.com [204.101.128.170]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id KAA01620 for <[e-mail]>; Fri, 14 Jul 2000 10:52:19 -0700 (PDT)
Received: by sothmxs01.entrust.com with Internet Mail Service (5.5.2650.21) id <34W5H6P3>; Fri, 14 Jul 2000 13:53:56 -0400
Message-ID: <[e-mail]>
From: Sharon Boeyen <[e-mail]>
To: "'[e-mail]'" <[e-mail]>, [e-mail], Sean Mullan <[e-mail]>
Subject: RE: Reverse paths
Date: Fri, 14 Jul 2000 13:52:33 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain; charset="iso-8859-1"

The forward element would be populated in the CA entry of the subject
of the cross-certificate and the reverse element would be populated in 
the CA entry of the issuer of the cross-certificate. 

The only difference between what is specified in the LDAPv2 schema 
and this proposal is that issuer must populate the reverse element of 
its own entry. In the LDAPv2 schema, ONLY the subject CA's entry needed 
to contain the cross-certificate. 

I'm certainly not advocating requiring bilateral cross-certification, 
and I don't think Sean is either.

Cheers
Sharon
> -----Original Message-----
> From: David Chadwick [mailto:[e-mail]]
> Sent: Friday, July 14, 2000 11:32 AM
> To: [e-mail]; Sean Mullan; Sharon Boeyen
> Subject: RE: Reverse paths
> 
> 
> Sharon,
> 
> > I would like to support Sean's request that for the LDAPv3 schema we
> > consider making the reverse element mandatory along with the forward
> > element. This would be a great step forward in supporting
> > interoperability among PKI products and services and, since it does
> > not impact existing LDAPv2 systems,
> > 
> > doesn't cause those previously deployed systems to be 
> non-conformant.
> > 
> > With both elements mandatory, regardless of the direction 
> the path is
> > being built, the certificate using system will be able to locate the
> > information it seeks.
> 
> How do we handle one-way cross certification where CA A trusts 
> CA B but not vice versa. In this case either the forward or reverse 
> path might be missing (depending upon which side you are coming 
> from).
> 
> David
> 
> >
> ***************************************************
> 
> David Chadwick
> IS Institute, University of Salford, Salford M5 4WT
> Tel [phone]  Fax [phone]
> Mobile [phone]
> Email [e-mail]
> Home Page  http://www.salford.ac.uk/its024/chadwick.htm
> Understanding X.500  http://www.salford.ac.uk/its024/X500.htm
> X.500/LDAP Seminars http://www.salford.ac.uk/its024/seminars.htm
> Entrust key validation string MLJ9-DU5T-HV8J
> 
> ***************************************************
> 


Received: from e4.ny.us.ibm.com (e4.ny.us.ibm.com [32.97.182.104]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id KAA01329 for <[e-mail]>; Fri, 14 Jul 2000 10:42:12 -0700 (PDT)
From: [e-mail]
Received: from northrelay02.pok.ibm.com (northrelay02.pok.ibm.com [9.117.200.22]) by e4.ny.us.ibm.com (8.9.3/8.9.3) with ESMTP id NAA90616; Fri, 14 Jul 2000 13:44:21 -0400
Received: from D51MTA04.pok.ibm.com (d51mta04.pok.ibm.com [9.117.200.32]) by northrelay02.pok.ibm.com (8.8.8m3/NCO v4.92) with SMTP id NAA14792; Fri, 14 Jul 2000 13:44:17 -0400
Received: by D51MTA04.pok.ibm.com(Lotus SMTP MTA v4.6.5  (863.2 5-20-1999))  id 8525691C.00616FA5 ; Fri, 14 Jul 2000 13:44:15 -0400
X-Lotus-FromDomain: IBMUS
To: Paul Halliden <[e-mail]>
cc: Stefan Santesson <[e-mail]>, Anders Rundgren <[e-mail]>, IETF-PXIX <[e-mail]>
Message-ID: <[e-mail]>
Date: Fri, 14 Jul 2000 13:44:10 -0400
Subject: RE: QC DN "qualities". Was: I-D ACTION:draft-ietf-pkix-qc-04.txt
Mime-Version: 1.0
Content-type: text/plain; charset=us-ascii
Content-Disposition: inline

     Responses below.  I think you might want to read
draft-ietf-pkix-pi-00.txt.  I do understand, and I hope that most of the WG
does as well, that there is principled political resistance in the USA and
several other countries to the existence of a national ID number, and that
no such number is likely to come into existence in those countries.  The PI
draft is intended to give RP's what they need to identify or distinguish
subjects without trying to create such a number in countries where it is
not wanted.

          Tom Gindin

Paul Halliden <[e-mail]> on 07/14/2000 01:02:29 PM

To:   Tom Gindin/Watson/IBM@IBMUS, Stefan Santesson <[e-mail]>
cc:   Anders Rundgren <[e-mail]>, IETF-PXIX
      <[e-mail]>
Subject:  RE: QC DN "qualities". Was: I-D ACTION:draft-ietf-pkix-qc-04.txt



Tom
>
In fact, X.509v3 section 11.2 has a note which
>states "a certification authority shall not issue certificates for two
>users with the same name",
>
This is not the point at dispute. The QC text used to have an additional
requirement that a QC contained "an unmistakable identity ... which ...
relates to a specific entity."  It also contained the concept of "a
corresponding officially registered identity".

[Tom Gindin] There are several points at dispute.  Stefan explicitly
questioned the "requirement that 2 physical persons never can have the same
DN".

The contentious point is that this requirement has been dropped.  the
reason is that, in some jurisdictions there is simply no support for the
"unmistakable" concept.  Thus the subject name can be unique within the
CA's name space.  There is still a potential for mistaking that identity
with someone else not registered by the CA.  There is also ambiguity as to
whether two different names in the same space refer to the same physical
person - especially over time when a lot of the evidence supporting
identity (address, appearance, etc) can change.  In some countries, you can
address this issue by, e.g. referring to some unique national identity
number.  In others, such as the UK and USA there is no such thing.

[Tom Gindin] I actually do know something about this issue.  Have you read
the Permanent Identifier draft which Denis Pinkas and I wrote?  In it, an
individual may be identified by an ID issued by any assignment authority,
which does NOT have to be a government agency.

Regards
Paul Halliden




Received: from stonewall.baltimore.com ([195.152.140.4]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id KAA00614 for <[e-mail]>; Fri, 14 Jul 2000 10:00:39 -0700 (PDT)
Message-ID: <[e-mail]>
From: Paul Halliden <[e-mail]>
To: "'[e-mail]'" <[e-mail]>, Stefan Santesson <[e-mail]>
Cc: Anders Rundgren <[e-mail]>, IETF-PXIX <[e-mail]>
Subject: RE: QC DN "qualities". Was: I-D ACTION:draft-ietf-pkix-qc-04.txt
Date: Fri, 14 Jul 2000 18:02:29 +0100
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain; charset="iso-8859-1"

Tom
>
In fact, X.509v3 section 11.2 has a note which
>states "a certification authority shall not issue certificates for two
>users with the same name", 
>
This is not the point at dispute. The QC text used to have an additional
requirement that a QC contained "an unmistakable identity ... which ...
relates to a specific entity."  It also contained the concept of "a
corresponding officially registered identity".  

The contentious point is that this requirement has been dropped.  the reason
is that, in some jurisdictions there is simply no support for the
"unmistakable" concept.  Thus the subject name can be unique within the CA's
name space.  There is still a potential for mistaking that identity with
someone else not registered by the CA.  There is also ambiguity as to
whether two different names in the same space refer to the same physical
person - especially over time when a lot of the evidence supporting identity
(address, appearance, etc) can change.  In some countries, you can address
this issue by, e.g. referring to some unique national identity number.  In
others, such as the UK and USA there is no such thing.

Regards
Paul Halliden


Received: from e3.ny.us.ibm.com (e3.ny.us.ibm.com [32.97.182.103]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id JAA29914 for <[e-mail]>; Fri, 14 Jul 2000 09:33:12 -0700 (PDT)
From: [e-mail]
Received: from northrelay02.pok.ibm.com (northrelay02.pok.ibm.com [9.117.200.22]) by e3.ny.us.ibm.com (8.9.3/8.9.3) with ESMTP id MAA79470; Fri, 14 Jul 2000 12:35:20 -0400
Received: from D51MTA04.pok.ibm.com (d51mta04.pok.ibm.com [9.117.200.32]) by northrelay02.pok.ibm.com (8.8.8m3/NCO v4.92) with SMTP id MAA180236; Fri, 14 Jul 2000 12:35:17 -0400
Received: by D51MTA04.pok.ibm.com(Lotus SMTP MTA v4.6.5  (863.2 5-20-1999))  id 8525691C.005B1AD1 ; Fri, 14 Jul 2000 12:35:06 -0400
X-Lotus-FromDomain: IBMUS
To: Stefan Santesson <[e-mail]>
cc: Anders Rundgren <[e-mail]>, IETF-PXIX <[e-mail]>
Message-ID: <[e-mail]>
Date: Fri, 14 Jul 2000 12:34:54 -0400
Subject: Re: QC DN "qualities". Was: I-D ACTION:draft-ietf-pkix-qc-04.txt
Mime-Version: 1.0
Content-type: text/plain; charset=us-ascii
Content-Disposition: inline

     Is it not a technical requirement that the combination of the subject
name and the subject alternate name (at a minimum) be different if the
individuals are different?  In fact, X.509v3 section 11.2 has a note which
states "a certification authority shall not issue certificates for two
users with the same name", and this note is reproduced in X.509v4 section
7.2.  I don't think that QC's have a lesser requirement along these lines
than ordinary PKC's.
     My own view is that this requirement should be interpreted as
including a Subject Alternate Name extension as part of the name, at least
when the extension is critical.  However, this point is open to debate.

          Tom Gindin


Stefan Santesson <[e-mail]> on 07/14/2000 08:17:09 AM

To:   Anders Rundgren <[e-mail]>, IETF-PXIX
      <[e-mail]>
cc:
Subject:  Re: QC DN "qualities". Was: I-D ACTION:draft-ietf-pkix-qc-04.txt



Anders,

The "technical profile" specify what attributes to use, what type of
information to put in them and also states technical uniqueness
requirements. The technical uniqueness requirement from RFC 2459 stands.

The requirement that 2 physical persons never can have the same DN, is to
go beyond a technical uniqueness  concept.

I tried to have a "functional" requirement in there (the unmistakable
identity requirement), but got the whole European ETSI group against me
saying that such requirement, regardless how desirable it might be, can't
be 100% globally accomplished in a practical world (in all countries).

We must recognize that the real world have a context factor that we never
can capture in a technical standard.

Last IETF/PKIX meeting decided that Denis "Permanent Identifier" topic
should be advanced in a separate work item to be merged later, if
successful, with RFC 2459 or the QC profile.

That work has first to prove that you can make a useful "technical"
definition of the uniquness requirement in "permanent identifiers", which
still remains to be done.

/Stefan


At 12:49 2000-07-14 +0200, you wrote:
><snip>
>
>Denis wrote:
>
> >> >In order to make the text unambiguous it is important to say that:
"The
> >> DN MUST be unique  for
> >> >each subject entity certified by the one CA as defined by the issuer
> >> name field during the whole
> >> >life time of the CA, i.e. two different living human beings cannot
have
> >> the same DN."
>
>
>Stefan responded:
>
> >I agree that this is a good practice. There are however limitations on
how
> >far you can make requirements on practice in a technical profile.
>
>
>QC is not 2459.  QC is supposed to support legal systems and MARKET needs.
>For a CA that adhere to the word "Qualified" this is not a hard thing to
>require.
>It is anyway obliged to keep track of its subjects.  So what is the
>problem????
>
>Without restrictions on DNs QC is IMO redundant.  With the restriction
>requested by Denis
>you got a useful product (sorry - "techical profile" if that feels
better).
>
>May I kindly ask potential issuers of QCs to either stand by this
statement or
>not?
>
>Anders






Received: from d1o69.telia.com ([e-mail] [62.20.144.241]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id JAA27956 for <[e-mail]>; Fri, 14 Jul 2000 09:12:23 -0700 (PDT)
Received: from mega (t3o69p3.telia.com [62.20.145.3]) by d1o69.telia.com (8.8.8/8.8.8) with SMTP id SAA29670; Fri, 14 Jul 2000 18:14:20 +0200 (CEST)
Message-ID: <002b01bfedb6$d3fac100$[e-mail]>
From: "Anders Rundgren" <[e-mail]>
To: "Paul Koning" <[e-mail]>, <[e-mail]>, <[e-mail]>, <[e-mail]>, <[e-mail]>
Subject: Re: QC DN "qualities".  Was: I-D ACTION:draft-ietf-pkix-qc-04.txt
Date: Fri, 14 Jul 2000 19:13:26 +0200
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 4.72.3110.5
X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by ns.secondary.com id JAA27957

Paul K (not to be confused with Paul H :-)),

<snip>

> Anders> Pardon me but I don't get it.  If my statement about ETSI is
> Anders> correct the whole idea of certification is flawed but you say
> Anders> my statement is incorrect.  IMO that means that the
> Anders> adminstration DO know their subjects which you claim they
> Anders> don't for liberty reasons.
>
>Actually, no.  For one thing, in the USA there are no "subjects".  But
>even if you mean "citizens", the administration doesn't know them
>all. There are plenty of ways to become known to the various
>administrations (get a driver's license, register to vote, etc.) but
>those various registries aren't necessarily tied together, the names
>used aren't necessarily the same, and you aren't under legal
>compulsion to do any of these things if you can put up with the
>inconvenience of not doing so.


And for the very same reasons there will probably never be a single national US CA issuing QCs.

But there will be local, commercial, and private US QC CAs who will have RAs that in some way
make sure that the same identity (DN) is not given to two subjects/citizens!

A solution to the obvious non-consensus situation is that you make different QC policy IDs that
sets the "quality level" and then let the market decide and enable RP software to be automated.


Anders



Received: from Newman.GSC.GTE.Com ([e-mail] [192.160.62.66]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id IAA26222 for <[e-mail]>; Fri, 14 Jul 2000 08:52:30 -0700 (PDT)
Received: from gscex01.gsc.gte.com ("port 1894"@gscex01.ndhm.gsc.gte.com [155.95.162.170]) by Newman.GSC.GTE.Com (PMDF V5.2-30 #38015) with ESMTP id <[e-mail]> for [e-mail]; Fri, 14 Jul 2000 11:54:35 -0400 (EDT)
Received: by GSCEX01.gsc.gte.com with Internet Mail Service (5.5.2448.0) id <3L3TH0J9>; Fri, 14 Jul 2000 11:54:33 -0400
Content-return: allowed
Date: Fri, 14 Jul 2000 11:54:25 -0400
From: "Heimberg, Jim" <[e-mail]>
Subject: RE: QC DN "qualities".  Was: I-D ACTION:draft-ietf-pkix-qc-04.txt
To: "'Paul Koning'" <[e-mail]>, [e-mail]
Cc: [e-mail], [e-mail], [e-mail], [e-mail]
Message-id: <[e-mail]>
MIME-version: 1.0
X-Mailer: Internet Mail Service (5.5.2448.0)
Content-type: text/plain;	charset="iso-8859-1"

OK, maybe my meager mind is confused, this being Friday and all.  I can't
refrain from asking the obvious question.  Is there confusion between what a
distinguished name is and what a common name is.  Since the DN is a
contatenation of the common name and the domain path to it in the common
directory structure for that domain, I have trouble envisioning DNs that are
not unique unless there is a plan afoot to create duplicate domains using
the same domain names. ???

Jim

-----Original Message-----
From: Paul Koning [mailto:[e-mail]]
Sent: Friday, July 14, 2000 11:47 AM
To: [e-mail]
Cc: [e-mail]; [e-mail]; [e-mail];
[e-mail]
Subject: Re: QC DN "qualities". Was: I-D
ACTION:draft-ietf-pkix-qc-04.txt


>>>>> "Anders" == Anders Rundgren <[e-mail]> writes:

 Anders> Paul, <snip>

 >>> I assume that the ETSI group means that CA/RAs in some countries
 >>> can't keep track of the people they certify.
 >>> 
 >> No! In law and administration of some countries, there is no
 >> concept of "unmistakable identity". I was taught that this is
 >> deliberate policy in protection of civil liberties.  The principle
 >> is that, if an administration has control over an unmistakable
 >> identity

 Anders> Pardon me but I don't get it.  If my statement about ETSI is
 Anders> correct the whole idea of certification is flawed but you say
 Anders> my statement is incorrect.  IMO that means that the
 Anders> adminstration DO know their subjects which you claim they
 Anders> don't for liberty reasons.

Actually, no.  For one thing, in the USA there are no "subjects".  But
even if you mean "citizens", the administration doesn't know them
all. There are plenty of ways to become known to the various
administrations (get a driver's license, register to vote, etc.) but
those various registries aren't necessarily tied together, the names
used aren't necessarily the same, and you aren't under legal
compulsion to do any of these things if you can put up with the
inconvenience of not doing so.

In particular -- and we've been through this before in detail many
months ago -- the whole concept of unmistakable identity doesn't work
in the USA.  There isn't any central registry of identities, and names
aren't immutable.

       paul


Received: from dfw7-1.relay.mail.uu.net (dfw7-1.relay.mail.uu.net [199.171.54.106]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id IAA25532 for <[e-mail]>; Fri, 14 Jul 2000 08:44:44 -0700 (PDT)
Received: from xedia.com by dfw7sosrv11.alter.net with SMTP  (peer crosschecked as: madway.xedia.com [198.202.232.199]) id QQixvb11630; Fri, 14 Jul 2000 15:46:40 GMT
Received: from tonga.xedia.com by xedia.com (4.1/SMI-4.1) id AA24441; Fri, 14 Jul 00 11:42:46 EDT
Received: by tonga.xedia.com (SMI-8.6/SMI-SVR4) id LAA05898; Fri, 14 Jul 2000 11:46:37 -0400
From: Paul Koning <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-Id: <[e-mail]>
Date: Fri, 14 Jul 2000 11:46:37 -0400 (EDT)
To: [e-mail]
Cc: [e-mail], [e-mail], [e-mail], [e-mail]
Subject: Re: QC DN "qualities".  Was: I-D ACTION:draft-ietf-pkix-qc-04.txt
References: <003601bfedb0$3740bdc0$[e-mail]>
X-Mailer: VM 6.72 under 21.1 (patch 9) "Canyonlands" XEmacs Lucid

>>>>> "Anders" == Anders Rundgren <[e-mail]> writes:

 Anders> Paul, <snip>

 >>> I assume that the ETSI group means that CA/RAs in some countries
 >>> can't keep track of the people they certify.
 >>> 
 >> No! In law and administration of some countries, there is no
 >> concept of "unmistakable identity". I was taught that this is
 >> deliberate policy in protection of civil liberties.  The principle
 >> is that, if an administration has control over an unmistakable
 >> identity

 Anders> Pardon me but I don't get it.  If my statement about ETSI is
 Anders> correct the whole idea of certification is flawed but you say
 Anders> my statement is incorrect.  IMO that means that the
 Anders> adminstration DO know their subjects which you claim they
 Anders> don't for liberty reasons.

Actually, no.  For one thing, in the USA there are no "subjects".  But
even if you mean "citizens", the administration doesn't know them
all. There are plenty of ways to become known to the various
administrations (get a driver's license, register to vote, etc.) but
those various registries aren't necessarily tied together, the names
used aren't necessarily the same, and you aren't under legal
compulsion to do any of these things if you can put up with the
inconvenience of not doing so.

In particular -- and we've been through this before in detail many
months ago -- the whole concept of unmistakable identity doesn't work
in the USA.  There isn't any central registry of identities, and names
aren't immutable.

       paul



Received: from mta03-svc.ntlworld.com (mta03-svc.ntlworld.com [62.253.162.43]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id IAA24338 for <[e-mail]>; Fri, 14 Jul 2000 08:31:53 -0700 (PDT)
Received: from dwc-acer ([62.252.108.177]) by mta03-svc.ntlworld.com (InterMail vM.4.01.02.27 201-229-119-110) with ESMTP id <20000714153359.HAW16423.mta03-svc.ntlworld.com@dwc-acer>; Fri, 14 Jul 2000 16:33:59 +0100
From: "David Chadwick" <[e-mail]>
Organization: University of Salford
To: [e-mail], Sean Mullan <[e-mail]>, Sharon Boeyen <[e-mail]>
Date: Fri, 14 Jul 2000 16:32:23 +0100
MIME-Version: 1.0
Content-type: text/plain; charset=US-ASCII
Content-transfer-encoding: 7BIT
Subject: RE: Reverse paths
Reply-to: [e-mail]
Message-ID: <396F4097.21137.DDAC2CB@localhost>
Priority: normal
In-reply-to: <[e-mail]>
X-mailer: Pegasus Mail for Win32 (v3.12c)

Sharon,

> I would like to support Sean's request that for the LDAPv3 schema we
> consider making the reverse element mandatory along with the forward
> element. This would be a great step forward in supporting
> interoperability among PKI products and services and, since it does
> not impact existing LDAPv2 systems,
> 
> doesn't cause those previously deployed systems to be non-conformant.
> 
> With both elements mandatory, regardless of the direction the path is
> being built, the certificate using system will be able to locate the
> information it seeks.

How do we handle one-way cross certification where CA A trusts 
CA B but not vice versa. In this case either the forward or reverse 
path might be missing (depending upon which side you are coming 
from).

David

>
***************************************************

David Chadwick
IS Institute, University of Salford, Salford M5 4WT
Tel [phone]  Fax [phone]
Mobile [phone]
Email [e-mail]
Home Page  http://www.salford.ac.uk/its024/chadwick.htm
Understanding X.500  http://www.salford.ac.uk/its024/X500.htm
X.500/LDAP Seminars http://www.salford.ac.uk/its024/seminars.htm
Entrust key validation string MLJ9-DU5T-HV8J

***************************************************


Received: from d1o69.telia.com ([e-mail] [62.20.144.241]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id IAA23374 for <[e-mail]>; Fri, 14 Jul 2000 08:25:06 -0700 (PDT)
Received: from mega (t3o69p46.telia.com [62.20.145.46]) by d1o69.telia.com (8.8.8/8.8.8) with SMTP id RAA02170; Fri, 14 Jul 2000 17:26:59 +0200 (CEST)
Message-ID: <003601bfedb0$3740bdc0$[e-mail]>
From: "Anders Rundgren" <[e-mail]>
To: "Paul Halliden" <[e-mail]>, "Denis Pinkas" <[e-mail]>, "Stefan Santesson" <[e-mail]>, "IETF-PXIX" <[e-mail]>
Subject: Re: QC DN "qualities".  Was: I-D ACTION:draft-ietf-pkix-qc-04.txt
Date: Fri, 14 Jul 2000 18:26:06 +0200
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 4.72.3110.5
X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by ns.secondary.com id IAA23376

Paul,

<snip>

>>I assume that the ETSI group means that CA/RAs in some 
>>countries can't keep track of the people they certify. 
>>  
>No! In law and administration of some countries, there is no concept of
>"unmistakable identity". I was taught that this is deliberate policy in
>protection of civil liberties.  The principle is that, if an administration
>has control over an unmistakable identity

Pardon me but I don't get it.  If my statement about ETSI is correct
the whole idea of certification is flawed but you say my statement is
incorrect.  IMO that means that the adminstration DO know their subjects
which you claim they don't for liberty reasons.

Note: We are NOT talking about social security numbers.  That's another issue.

<snip>
>>How useful are legally binding signatures under such circumstances?

>We have managed to have legally effective signatures for over 1000 years
>under such circumstances - so quite useful I guess.


But in the older days you did not met millions of people on web and there
where no CAs issuing certificates either.  

And they did not possess powerful databases capable of storing data about
the entire terrestial population (which is in reach for a PC these days).

Even in limited naming-domain like a typical school-class, you refer to "Mary M" and
"Mary K" for very good reasons.



Paul, maybe you could name a potential QC CA that wants to issue ambigious DNs???


Anders



Received: from sothmxs01.entrust.com (gatekeeper.entrust.com [204.101.128.170]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id GAA21086 for <[e-mail]>; Fri, 14 Jul 2000 06:55:47 -0700 (PDT)
Received: by sothmxs01.entrust.com with Internet Mail Service (5.5.2650.21) id <34W5HY1L>; Fri, 14 Jul 2000 09:57:23 -0400
Message-ID: <[e-mail]>
From: Sharon Boeyen <[e-mail]>
To: "'[e-mail]'" <[e-mail]>, [e-mail], Sean Mullan <[e-mail]>
Subject: RE: Reverse paths
Date: Fri, 14 Jul 2000 09:56:00 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain; charset="iso-8859-1"

Hi David,

The LDAPv2 schema discussion on this topic was an VERY lengthy 
debate. If you're feeling particularly masochistic, check out the 
pkix mail list archive covering about June - Oct of 1998 (but 
allow yourself plenty of time because there are probably several 
hundreds of messages on this and related topics during that time).

The text that is in the PKIX LDAPv2 schema is the compromise that 
was agreed as a result of that disucssion. 

A couple of the major factors that I believe led to the decision 
to have reverse element optional were:
a) A large deployment within the US Gov did not populate the reverse
   element and did not use the reverse element to develop paths. If 
   we mandated population of the reverse element, we would have caused
   that deployment to be non-conformant.
b) Back then, hierarchies were dominant and in hierarchies it is generally
   much more efficient to build paths from the subscriber cert to the 
   root of the hierarchy, and in this trust model, the reverse element
   is not required.

However, since 98 I think we've seen much greater support for the 
distributed trust model as well as for mixed mode environments where
hierarchies are 
cross-certified through the distributed trust model. The US Federal Bridge
CA 
project is an example. While I agree that the forward element is required, 
especially for the hierarchical trust model, I think this is an appropriate
time to 
revisit the reverse element. While we need to maintain backward
compatibility 
with the LDAPv2 schema, we don't necessarily need to be bound by the same 
restrictions.

In a hierarchical trust model, there is no dispute that it is more efficient

to build a path from the subscriber cert to the root. In a distributed trust

model, I definitely agree with Sean that it is more efficient to build your 
path from the trust anchor toward the subscriber cert (pruning branches as
you 
proceed). In a mixed environment, it may be most efficient to build from a 
subscriber cert to a hierarchical root and then build from the trust anchor
toward
that root, pruning as you go. I don't think we need to get into a discussion

of what direction is most efficient though, because that would probably lead
to 
an endless debate again. Instead I would suggest that we just recognize that

some certificate using systems will, at times, build in one direction and
some
certificate using systems will, at times, build in the opposite direction. 

I would like to support Sean's request that for the LDAPv3 schema we 
consider making the reverse element mandatory along with the forward
element.
This would be a great step forward in supporting interoperability among PKI 
products and services and, since it does not impact existing LDAPv2 systems,

doesn't cause those previously deployed systems to be non-conformant.
 
With both elements mandatory, regardless of the direction the path is 
being built, the certificate using system will be able to locate the
information
it seeks.

Sharon
   

> -----Original Message-----
> From: David Chadwick [mailto:[e-mail]]
> Sent: Thursday, July 13, 2000 10:27 AM
> To: [e-mail]; Sean Mullan
> Subject: Reverse paths
> 
> 
> Date sent:      	Wed, 12 Jul 2000 19:40:47 +0100
> From:           	Sean Mullan <[e-mail]>
> To:             	[e-mail], 
> [e-mail], [e-mail]
> Subject:        	Re: I-D 
> ACTION:draft-ietf-pkix-ldap-schema-00.txt
> 
> Sean 
> this thread should be opened up to the whole PKIX list. I am happy 
> to put this into the LDAPv3 schema if that is what is wanted, but 
> there must have been some earlier discussion as to why it is 
> optional and not mandatory.
> David
> 
> 
> > Building certification paths in a 'reverse'
> > direction (from trust anchor to EE) is a valid way to build
> > certification paths. However, RFC 2587 (PKIX LDAPv2 schema) 
> specifies
> > that the storage of cross certificates in the reverse 
> component of the
> > crossCertificatePair is optional. It is not possible to efficiently
> > build a certification path in a 'reverse' direction unless the
> > certificates are populated in the reverse component of the
> > crossCertificatePair attribute. Specifying that this feature is
> > optional makes it difficult to build paths in a reverse 
> direction in a
> > trust model where lots of cross certificates and multiple 
> directories
> > are involved and you don't know if the CAs support the optional
> > storage.
> > 
> > I would like to suggest that RFC 2587 be amended/updated
> > to make storage of cross certificates in the reverse 
> component of the
> > crossCertificatePair attribute mandatory.
> > 
> > Thanks,
> > Sean
> >
> 
> ***************************************************
> 
> David Chadwick
> IS Institute, University of Salford, Salford M5 4WT
> Tel [phone]  Fax [phone]
> Mobile [phone]
> Email [e-mail]
> Home Page  http://www.salford.ac.uk/its024/chadwick.htm
> Understanding X.500  http://www.salford.ac.uk/its024/X500.htm
> X.500/LDAP Seminars http://www.salford.ac.uk/its024/seminars.htm
> Entrust key validation string MLJ9-DU5T-HV8J
> 
> ***************************************************
> 


Received: from mail0.sibs.pt (mail0.sibs.pt [195.138.0.101]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id GAA20692 for <[e-mail]>; Fri, 14 Jul 2000 06:48:12 -0700 (PDT)
Received: (qmail 23048 invoked from network); 14 Jul 2000 13:42:38 -0000
Received: from unknown (HELO mail.sibs.pt) (172.17.0.2) by 172.16.0.3 with SMTP; 14 Jul 2000 13:42:38 -0000
Received: from edi.van ([194.117.48.12]) by mail.sibs.pt (Netscape Mail Server v2.02) with ESMTP id AAA28256 for <[e-mail]>; Fri, 14 Jul 2000 14:49:19 +0100
Received: from SIBSEX.sibs ([192.168.250.26]) by edi.van (8.8.2/8.8.2) with ESMTP id OAA15770 for <[e-mail]>; Fri, 14 Jul 2000 14:47:20 +0100 (PST)
Received: by sibsex.sibs with Internet Mail Service (5.5.2448.0) id <3WPPFQ6H>; Fri, 14 Jul 2000 14:51:14 +0100
Message-ID: <[e-mail]>
From: Renato Portela <[e-mail]>
To: "'[e-mail]'" <[e-mail]>
Date: Fri, 14 Jul 2000 14:51:11 +0100
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2448.0)
Content-Type: text/plain; charset="iso-8859-1"

Hi,

The X.509 and the RFC2459 both define a certificate but the asn.1 used to
define it is different. 
Why are they different?
The encoding result of those Certificates is equal?

The RFC2560 import Certificate from AuthenticationFramework.
Should I use that definition or the definition of Certificate in RFC2459?

Thanks in advance
Renato Portela


Received: from stonewall.baltimore.com ([195.152.140.4]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id GAA20267 for <[e-mail]>; Fri, 14 Jul 2000 06:33:06 -0700 (PDT)
Message-ID: <[e-mail]>
From: Paul Halliden <[e-mail]>
To: "'Anders Rundgren'" <[e-mail]>, Denis Pinkas <[e-mail]>, Stefan Santesson <[e-mail]>, IETF-PXIX <[e-mail]>
Subject: RE: QC DN "qualities".  Was: I-D ACTION:draft-ietf-pkix-qc-04.txt
Date: Fri, 14 Jul 2000 14:35:02 +0100
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain; charset="iso-8859-1"

Anders

<snip>
>Could I maybe have the e-mail to one of those ETSI-morons?
>
Not very professional language  :-(

>I assume that the ETSI group means that CA/RAs in some 
>countries can't keep track of the people they certify. 
>  
No! In law and administration of some countries, there is no concept of
"unmistakable identity". I was taught that this is deliberate policy in
protection of civil liberties.  The principle is that, if an administration
has control over an unmistakable identity - they also have the undesirable
ability to deny such an identity and therefore create non-people. Whether,
in these days the threat is real or not, does not matter.  The fact is that
the concept of unmistakable identity does not exist and mandating it in a
technical specification will not change that.  There is, of course, nothing
to stop those countries that do have the concept, making use of it.

<snip>
>How useful are legally binding signatures under such circumstances?
>
We have managed to have legally effective signatures for over 1000 years
under such circumstances - so quite useful I guess.

Regards
Paul Halliden


Received: from d1o69.telia.com ([e-mail] [62.20.144.241]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id FAA19392 for <[e-mail]>; Fri, 14 Jul 2000 05:55:51 -0700 (PDT)
Received: from mega (t5o69p114.telia.com [213.64.110.114]) by d1o69.telia.com (8.8.8/8.8.8) with SMTP id OAA27031; Fri, 14 Jul 2000 14:57:54 +0200 (CEST)
Message-ID: <000a01bfed9b$633d78b0$[e-mail]>
From: "Anders Rundgren" <[e-mail]>
To: "Denis Pinkas" <[e-mail]>, "Stefan Santesson" <[e-mail]>, "IETF-PXIX" <[e-mail]>
Subject: Re: QC DN "qualities".  Was: I-D ACTION:draft-ietf-pkix-qc-04.txt
Date: Fri, 14 Jul 2000 15:57:02 +0200
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 4.72.3110.5
X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by ns.secondary.com id FAA19397

Stefan,

>The requirement that 2 physical persons never can have the same DN, is to 
>go beyond a technical uniqueness  concept.
>
>I tried to have a "functional" requirement in there (the unmistakable 
>identity requirement), but got the whole European ETSI group against me 

You did? Could I maybe have the e-mail to one of those ETSI-morons?

>saying that such requirement, regardless how desirable it might be, can't 
>be 100% globally accomplished in a practical world (in all countries).


I assume that the ETSI group means that CA/RAs in some countires can't keep track
of the people they certify.   How useful are legally binding signatures under such circumstances?
Because if a CA *can* keep track of people, the technical part is a no-issue as they
can always add a disambiguiting element such as serialNumber.  Note: w.o. turning
to social security numbers or other politically sensitive actions...

>Last IETF/PKIX meeting decided that Denis "Permanent Identifier" topic 
>should be advanced in a separate work item to be merged later, if 
>successful, with RFC 2459 or the QC profile.


This is an entirely other issue as Permant Identifiers is a step up from requiring DNs to not be reissued
as Permanent identifiers allows changing DNs while still linking to the same identity.


Anders





Received: from popmail.inbox.se (popmail.inbox.se [193.12.72.102]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id FAA17863 for <[e-mail]>; Fri, 14 Jul 2000 05:13:48 -0700 (PDT)
Received: from santesson.accurata.se ([212.28.208.198]) by popmail.inbox.se (8.9.3/8.9.3) with ESMTP id OAA25846; Fri, 14 Jul 2000 14:15:52 +0200
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Version 4.3.2
Date: Fri, 14 Jul 2000 14:17:09 +0200
To: Anders Rundgren <[e-mail]>, IETF-PXIX <[e-mail]>
From: Stefan Santesson <[e-mail]>
Subject: Re: QC DN "qualities".  Was: I-D ACTION:draft-ietf-pkix-qc-04.txt
In-Reply-To: <006f01bfed81$30883460$[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed

Anders,

The "technical profile" specify what attributes to use, what type of 
information to put in them and also states technical uniqueness 
requirements. The technical uniqueness requirement from RFC 2459 stands.

The requirement that 2 physical persons never can have the same DN, is to 
go beyond a technical uniqueness  concept.

I tried to have a "functional" requirement in there (the unmistakable 
identity requirement), but got the whole European ETSI group against me 
saying that such requirement, regardless how desirable it might be, can't 
be 100% globally accomplished in a practical world (in all countries).

We must recognize that the real world have a context factor that we never 
can capture in a technical standard.

Last IETF/PKIX meeting decided that Denis "Permanent Identifier" topic 
should be advanced in a separate work item to be merged later, if 
successful, with RFC 2459 or the QC profile.

That work has first to prove that you can make a useful "technical" 
definition of the uniquness requirement in "permanent identifiers", which 
still remains to be done.

/Stefan


At 12:49 2000-07-14 +0200, you wrote:
><snip>
>
>Denis wrote:
>
> >> >In order to make the text unambiguous it is important to say that: "The
> >> DN MUST be unique  for
> >> >each subject entity certified by the one CA as defined by the issuer
> >> name field during the whole
> >> >life time of the CA, i.e. two different living human beings cannot have
> >> the same DN."
>
>
>Stefan responded:
>
> >I agree that this is a good practice. There are however limitations on how
> >far you can make requirements on practice in a technical profile.
>
>
>QC is not 2459.  QC is supposed to support legal systems and MARKET needs.
>For a CA that adhere to the word "Qualified" this is not a hard thing to 
>require.
>It is anyway obliged to keep track of its subjects.  So what is the 
>problem????
>
>Without restrictions on DNs QC is IMO redundant.  With the restriction 
>requested by Denis
>you got a useful product (sorry - "techical profile" if that feels better).
>
>May I kindly ask potential issuers of QCs to either stand by this statement or
>not?
>
>Anders



Received: from ietf.org (odin.ietf.org [132.151.1.176]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id DAA16161 for <[e-mail]>; Fri, 14 Jul 2000 03:54:39 -0700 (PDT)
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA10813; Fri, 14 Jul 2000 06:56:45 -0400 (EDT)
Message-Id: <[e-mail]>
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
Cc: [e-mail]
From: [e-mail]
Reply-to: [e-mail]
Subject: I-D ACTION:draft-ietf-pkix-scvp-03.txt
Date: Fri, 14 Jul 2000 06:56:45 -0400
Sender: [e-mail]

--NextPart

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Public-Key Infrastructure (X.509) Working Group of the IETF.

	Title		: Simple Certificate Validation Protocol (SCVP)
	Author(s)	: A. Malpani, P. Hoffman
	Filename	: draft-ietf-pkix-scvp-03.txt
	Pages		: 
	Date		: 13-Jul-00
	
The SCVP protocol allows a client to offload certificate handling to a
server. The server can give a variety of valuable information about the
certificate, such as whether or not the certificate is valid, a chain
to a trusted root, and so on. SCVP has many purposes, including
simplifying client implementations and allowing companies to centralize
their trust and policy managment.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-pkix-scvp-03.txt

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-ietf-pkix-scvp-03.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt


Internet-Drafts can also be obtained by e-mail.

Send a message to:
	[e-mail].
In the body type:
	"FILE /internet-drafts/draft-ietf-pkix-scvp-03.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.
		
		
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"

--OtherAccess
Content-Type: Message/External-body;
	access-type="mail-server";
	server="[e-mail]"

Content-Type: text/plain
Content-ID:	<[e-mail]>

ENCODING mime
FILE /internet-drafts/draft-ietf-pkix-scvp-03.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-pkix-scvp-03.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID:	<[e-mail]>

--OtherAccess--

--NextPart--




Received: from sunheger1.nm.informatik.uni-muenchen.de (sunheger1.nm.informatik.uni-muenchen.de [129.187.214.1]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id DAA15678 for <[e-mail]>; Fri, 14 Jul 2000 03:26:58 -0700 (PDT)
Received: (from vogt@localhost) by sunheger1.nm.informatik.uni-muenchen.de (8.9.3+Sun/8.9.3) id MAA20947; Fri, 14 Jul 2000 12:26:45 +0200 (MET DST)
Date: Fri, 14 Jul 2000 12:26:45 +0200 (MET DST)
Message-Id: <[e-mail]>
From: USM 2000 Organization Committee <[e-mail]>
To: [e-mail]
Subject: USM 2000 Call for Participation

[Please accept our apologies if you receive this mail more than once...]

USM 2000 - Announcement and Call for Participation

It is just another two months until the USM 2000 will take place here
in Munich. Therefore, we want to invite you to join us and participate
at the conference. The discounted, early bird registration rates are
valid until August 1st. You can save 50 Euro! So don't wait - register
today.

Below you find more detailed information on the conference and the
preliminary program. You also find all this information on our web
server. In particular, you will find the registration forms there.

WWW: http://usm2000.informatik.uni-muenchen.de/
Registration: http://usm2000.informatik.uni-muenchen.de/registration.shtml

We are looking forward to seeing you!

Best regards,

Claudia Linnhoff-Popien and Heinz-Gerd Hegering

------------------------------------------
Prof. Dr. Claudia Linnhoff-Popien     
Institut fuer Informatik
Ludwig-Maximilians-Universitaet Muenchen
Oettingenstr. 67, D-80538 Muenchen    
 
Tel.: [phone] (FAX: -2147) 
http://www.informatik.uni-muenchen.de 
mailto:[e-mail]

-----------------------------------------------------------------------------

3rd IFIP/GI International Conference on Trends
towards a Universal Service Market

Munich, Germany
September 12-14, 2000

sponsored and supported by

International Federation for Information Processing (IFIP)
Gesellschaft für Informatik e.V. (GI)

Ludwig-Maximilians-Universität München (LMU)
Leibniz-Rechenzentrum München (LRZ)
BWM AG
DG Bank
Siemens AG
Munich Network Management Team (MNM-Team)
Redwood Technologies Ltd.
Software-Offensive Bayern

General Information

USM 2000 is the third event in a series of international IFIP conferences
on Trends in Distributed Systems. It continues TreDS'96, held in Aachen,
Germany and TrEC'98 with special focus on Electronic Commerce in Hamburg,
Germany.

The technological progress in the internet and telecommunication domains
as well as deregulation efforts of the telecommunication markets currently
under way in many countries enable an integration of data and
telecommunication. Distributed platforms get adapted to the needs of
telecommunication networks. This leads to a global distributed system with
millions of objects, running on top of middleware platforms and
interacting with each other to provide services. USM 2000 brings together
researchers, service vendors and users in the field of universal service
markets. USM 2000 takes place in Munich, Germany, the city of the famous
Oktoberfest, which will start two days after the conference on September
16, 2000.

Topics

The USM 2000 considers services of a universal market in relation to
middleware, distributed applications and management. Areas of special
interest include:

Component Based Systems, Service Creation 
Service Market Models, Accounting and Customer Care 
Quality of Service for Distributed Applications 
Trading, Brokering and Information Management 
Management of Virtual Networks 
Service and Application Management 
Ubiquitous Services and Nomadic Computing 
Distributed and Mobile Objects 
Agent Technology for Integrated Management 
Advances in Middleware Architectures, e.g. CORBA, DCOM, Jini 
Telecommunication Architectures related to Distributed Systems 

USM 2000 Preliminary Program

Tuesday 12 September 2000

09.30 - 10.00 
      Welcome

      Claudia Linnhoff-Popien / Heinz-Gerd Hegering
      Conference Chairs

      Prof. Dr. rer. nat. Axel Schenzle
      Prorector Ludwig-Maximilians-University (LMU) Munich 

10.00 - 11.00 
      Invited Talk

      "Beyond the TINA lesson: distributed processing for integrated fixed
      and mobile communications"

        Dr Sebastiano Trigila
        Telecommunications Network Department at Fondazione Ugo Bordoni,
        Rome, Italy 

11.00 - 11.30 
      Coffee Break 

11.30 - 13.00 
      Session Electronic Auctions and Trading
      Chair: Lea Kutvonen, University of Helsinki, Finland

      "Market-Skilled Agents for Automating the Bandwidth Commerce"

        Monique Calisti, Boi Faltings, EPFL Lausanne, Switzerland
        Sandro Mazziotta, Swisscom AG, Bern, Switzerland 

      "Integrating Trading and Load Balancing for Efficient Management of
      Services in Distributed Systems"

        Dirk Thißen, RWTH Aachen, Germany
        Helmut Neukirchen, Medical University of Lübeck, Germany 

      "Mapping Enterprise Roles to CORBA Objects using Trader"

        Alistair Barros, Keith Duddy, Michael Lawley, Zoran Milosevic, 
        Kerry Raymond, Andrew Wood, DSTC, Brisbane, Australia 

13.00 - 14.30 
      Lunch Break 

14.30 - 16.00 
      Session Internet-Based Service Markets
      Chair: Winfried Lamersdorf, University of Hamburg, Germany

      "A Scheme for Component Based Service Deployment"

        Steve Rudkin, Alan Smith, BT Laboratories, United Kingdom

      "Performance Modeling of a Service Provisioning Design"

        Mohamed El-Darieby, Jerome Rolia, Carleton University, Ottawa, 
        Canada 

      "Correlation DialTone - Building Internet-Based Distributed Event
      Correlation Services"

        Gabriel Jakobson, Girish Pathak, GTE Laboratories, Waltham, USA 

16.00 - 16.30 
      Coffee Break 

16.30 - 18.00 
      Poster Session Mobile Agents and Applications
      Chair: Otto Spaniol, RWTH Aachen, Germany

      "Towards Context-Aware User Modeling"

        Michael Samulowitz, Siemens AG, München, Germany

      "Context notification in mobile environment to find the right person
      in time"

        Cora Burger, University of Stuttgart, Germany

      "Automated Adaption for Mobile Computing Based on Mobile Agents"

        Thomas Springer, Alexander Schill, University of Technology, 
        Dresden, Germany 

      "How to Efficiently Deploy Mobile Agents for an Integrated 
      Management"

        Steffen Lipperts, RWTH Aachen, Germany 

      "A Scalable Location Aware Service Platform for Mobile Applications
      based on Java RMI"

        Olaf Droegehorn, Kirti Singh-Kurbel, Markus Franz, Roland Sorge,
        Rita Winkler, Klaus David, IHP GmbH, Frankfurt (Oder), Germany 


Wednesday 13 September 2000

09.00 - 10.00 
      Invited Talk

      "Quality of Service and Service Provisioning on a Competitive
      Market"

        Prof Dr Lambert J.M. Nieuwenhuis
        KPN Research/University Twente, Netherlands 

10.00 - 10.30 
      Coffee Break 

10.30 - 12.00 
      Session Quality of Service
      Chair: Gerd Schürmann, GMD FOKUS, Berlin, Germany

      "Programming Internet Quality of Service"

        John Vicente, Intel Corporation, USA
        Michael Kounavis, Daniel Villela, Columbia University, USA
        Michah Lerner, AT&T Labs, USA
        Andrew Campbell, Columbia University, USA

      "Monitoring Quality of Service across Organizational Boundaries"

        Rainer Hauck, Helmut Reiser, University of Munich, Germany

      "Automated Allocation of Multiprovider Service Demands"

        Monique Calisti, Boi Faltings, EPFL Lausanne, Switzerland 

12.00 - 13.30 
      Lunch Break 

13.30 - 15.00 
      Session Mobile and Distributed Services
      Chair: Axel Küpper, RWTH Aachen, Germany

        "A Vehicular Software Architecture Enabling Dynamic Alterability
        of Services Sets"

          Volker Feil, Ulrich Gemkow, University of Stuttgart, Germany
          Matthias Stümpfle, DaimlerChrysler AG, Stuttgart, Germany 

        "JBSA: An Infrastructure for Seamless Mobile Systems Integration"

          Stefan Müller-Wilken, Winfried Lamersdorf, University of 
          Hamburg, Germany 

        "Mobtel - A Mobile Distributed Telemedical System for Application
        in the Neuropsychological Therapy"

          Hendrik Schulze, Klaus Irmscher, University of Leipzig, Germany 

15.00 - 15.30 
      Coffee Break 

15.30 - 17.00 
      Poster session Trends in Data- and Telecommunications
      Chair: Sebastian Abeck, University of Karlsruhe, Germany

      "Design-Aspects for the integration of CORBA-based Value Added
      Services and Intelligent Networks"

        Frank Imhoff, Marcos dos Santos Rocha, RWTH Aachen, Germany 

      "Experiences Building a Service Execution Node for Distributed IN
      Systems"

        Menelaos K. Perdikeas, Fotis G. Chatzipapadopoulos, Iakovos 
        S. Venieris, Nation Technical University of Athens, Greece

      "Leasing in a Market for Computing Capacity"
         Spyros Lalis, Alexandros Karipidis, University of Crete, Greece 

      "Virtual Malls for Web Commerce: Observations and Case Study"
        Anton Nijholt University of Twente, Netherlands 

      "A QoS Meta Model to Define a Generic Environment for QoS
      Management"
        Jérôme Daniel, Bruno Traverson, EDF Division R&D, Clamart, France
        Sylvie Vignes, ENST, Paris, France 

17.00 - 17.30 
      Break 

17.30 - 
      Social Event 


Thursday 14 September 2000

09.00 - 10.00 
      Invited Talk

      "The TAO of Patterns - Understanding Middleware and Component 
      Architectures"

      Michael Stal
      Siemens AG, München, Germany 

10.00 - 10.30 
      Coffee Break 

10.30 - 12.00 
      Session Middleware Architectures
      Chair: John Vicente, Intel Corporation, USA

      "Trade-offs in a Secure Jini Service Architecture"
        Peer Hasselmeyer, Roger Kehr, Marco Voß, University of Technology,
        Darmstadt, Germany 

      "Loadable Smart Proxies and Native-Code Shipping for CORBA"
         Rainer Koster, Thorsten Kramp, University of Kaiserslautern, 
         Germany 

      "A Middleware Architecture for Scalable, QoS-Aware and 
      Self-Organizing Global Services"

        Franz J. Hauck, Erich Meier, Ulrich Becker, Martin Geier, Uwe 
        Rastofer, Martin Steckermeier, University of Erlangen-Nürnberg,
        Germany 

12.00 - 13.30 
      Lunch Break 

13.30 - 15.00 
      Session Service Management
      Chair: Bernhard Neumair, DeTeSystem, Munich, Germany

      "Fuzzy Modeling of Cooperative Service Management"
         Pradeep Ray, University of New South Wales, Sydney, Australia
         Seyed A. Shahrestani, University of Western Sydney, Australia 

      "Customer Service Management: An Information Model for Communication
      Services"
        Michael Langer, Michael Nerb, Leibniz Supercomputing Center, 
        Munich, Germany 

      "Specification of a Service Management Architecture to Run 
      Distributed and Networked Systems"
        Christian Mayerl, Zoltan Nochta, Markus Müller, Martin Schauer,
        Andreas Uremovic, Sebastian Abeck, University of Karlsruhe, Germany 

15.00 - 15.15 
      Conclusions 


Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id DAA15416 for <[e-mail]>; Fri, 14 Jul 2000 03:21:09 -0700 (PDT)
Received: from ireserver.Ireland.Sun.COM ([129.156.220.7]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id DAA10503; Fri, 14 Jul 2000 03:23:11 -0700 (PDT)
Received: from sun.com (boston [129.156.220.153]) by ireserver.Ireland.Sun.COM (8.8.8+Sun/8.8.8/ENSMAIL,v1.9) with ESMTP id LAA26570; Fri, 14 Jul 2000 11:23:10 +0100 (BST)
Sender: [e-mail]
Message-ID: <[e-mail]>
Date: Fri, 14 Jul 2000 11:23:10 +0100
From: Sean Mullan <[e-mail]>
X-Mailer: Mozilla 4.51 [en] (X11; U; SunOS 5.7 sun4u)
X-Accept-Language: en
MIME-Version: 1.0
To: [e-mail]
CC: [e-mail], [e-mail], [e-mail]
Subject: Re: I-D ACTION:draft-ietf-pkix-ldap-schema-00.txt
References: <396DDA12.874.862330B@localhost>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

David,

David Chadwick wrote:
> 
> Date sent:              Wed, 12 Jul 2000 19:31:31 +0100
> From:                   Sean Mullan <[e-mail]>
> To:                     [e-mail]
> Copies to:              [e-mail], [e-mail]
> Subject:                Re: I-D ACTION:draft-ietf-pkix-ldap-schema-00.txt
> 
> > Hi David,
> >
> > Some comments on the draft below.
> 
> Sean, replies intersperced below
> 
> > Section 3.2 Certificate Match
> >
> > I think the X.509 certificate matching rules are missing some
> > essential and important fields in the certificateAssertion structure
> > for filtering on certificates. We may want to consider defining a
> > superset. I submitted these comments to the X.509 editors but
> > apparently it was too late to integrate them into the 2000 update.
> >
> >   * you should be able to match on more than one pathToName and on
> >   non-X500
> >     name types. This is inconsistent with name constraints which allow
> >     you to constrain to more than one name and different name types.
> >
> 
> I agree that alternative name types should be allowed. But maybe it
> is not necessary to have multiple names, since you can do several
> Searches providing one name for each search (remember that the
> name presented should be allowed to have a cert path created to it)

Yes, but I think this is a bit more complex. I think ideally you should
be able to define in one matching rule all the selection criteria for
a certificate. So if a certificate contains more than one alt name, the matching rule
should allow you to match on more than one alt name. For ex, in one search I
would like to get all the certs issued by some DN that allow a path to be 
built to the subject altnames of "cn=mullan,o=sun,c=us" and "[e-mail]".
If I break this into 2 searches, I am likely to get duplicate certs or
certs that allows paths to be built to one of the names but not both.
Specifying 2 matching rules in one search would have similar problems.

> How do we want to handle this:
> i) issue a defect on X.509 (Sharon can you comment on this)
> ii) let the LDAP matching rule be a superset of the X.509 one?
> 
> I would favour the former route myself.

I agree - if it doesn't take too long.

> >   * you should be able to match on more than the subject alt name
> >   type.
> 
> Agreed. This is a lack of clarity in the ID. It is intended that the
> whole name can be presented along with the type. The text is
> ambiguous in this respect and I will fix it. It will also be clearer when
> version 1 is published that contains BNF for each of the fields.
> Steven Legg has been doing this for me.

The X.509 certificateAssertion only allows you to match on the alt name type -
that's the problem I was referring to - that should be fixed.

> > You
> >     should also be able to match on the subject alt name itself, and
> >     specify more than one subject alt name as certificates can contain
> >     more than one.
> >
> 
> Concerning multiple names, I think this can be solved by performing
> multiple searches with a single name in each search.

See comment above why I think this is more complex.

> >   * you should be able to match on the subject public key as well as
> >   the subject public
> >     key algorithm OID.
> >
> 
> you can match on the subject key identifier (3rd component)

but not the subject public key itself.

> >   * you should be able to match on the basic constraints extension,
> >   especially the
> >     maxPathLen value. This is useful for finding potential
> >     certificates when building certification paths from the target to
> >     the most-trusted CA. For ex, if a partial path has been built, any
> >     candidate certificate must have a maxPathLen value greater than or
> >     equal to the number of certificates in the partial path.
> >
> 
> Interestingly  this has been defined for attribute certificates and not
> pk certs. I actually think that the way matching for ACs has been
> handled is far superior than for PKcerts. ie. a separate matching
> rule for each extension, rather than one long complex rule for pk
> certs. However, there would be nothing to stop an implementation
> dynamically attaching the basicAttConstraintsMatch to public key certs. In
> fact this matching rule could be renamed the basicConstraintsMatch
> anyway as the syntax is the same for both ACs and PKCs. This is
> my preferred approach.

Sounds good but I think there might be an issue.

What happens if you want to define a matching rule to only retrieve certs
that contain a specific basic constraints value AND a certain issuer name? In
this case, you would define 2 matching rules and specify both of them in
the valuesReturnFilter control. But then you would get all certs with the
requested issuer name and any basic constraints value and all certs with
any issuer name and the requested basic constraints value. That's not
what you wanted. I think we may want to enhance the valuesReturnFilter
control (through a flag, perhaps) to allow the user to apply all of the 
elements of the filter to each attribute value. Let's discuss this more 
offline, if you like.
 
> > I think it is very important to include the Certificate pair matching
> > rules, as these are very useful when building certification paths and
> > trying to discover which of many cross certificates satisfy various
> > validation constraints, and eliminating those that do not.
> >
> 
> OK, this can be done. It is just time consuming and I wanted to
> know if there was a demand first.
> 
> > Other comments:
> >
> >   * What RFC format are you using for the encoding of DNs - 1779? This
> >   should be referenced.
> 
> It should be 2253 for LDAPv3.
> 
> >
> > Section 4.2 Certificate List Match
> >
> > There is an error in the CertificateListAssertion definition in X.509
> > 2000. The authorityKeyIdentifier component should be marked OPTIONAL.
> > This probably doesn't affect your definition, but I just wanted to
> > make you aware of it.
> 
> Agreed, Sharon, can you make a  note of this defect
> 
> David
> p.s. what do you think about Bruce's assertion that none of this is
> needed and instead we should have a bunch of simple attributes in
> the LDAP entry

I'll have to go back and read Bruce's draft but I agree with your responses
to Bruce in an earlier message. Comments later ...

Thanks,
Sean


Received: from d1o69.telia.com ([e-mail] [62.20.144.241]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id CAA11975 for <[e-mail]>; Fri, 14 Jul 2000 02:48:20 -0700 (PDT)
Received: from mega (t4o69p113.telia.com [62.20.145.233]) by d1o69.telia.com (8.8.8/8.8.8) with SMTP id LAA25157; Fri, 14 Jul 2000 11:50:22 +0200 (CEST)
Message-ID: <006f01bfed81$30883460$[e-mail]>
From: "Anders Rundgren" <[e-mail]>
To: "Magnus (RSA)" <[e-mail]>, "IETF-PXIX" <[e-mail]>, "Denis" <[e-mail]>, "Stefan Santesson" <[e-mail]>
Subject: Re: QC DN "qualities".  Was: I-D ACTION:draft-ietf-pkix-qc-04.txt
Date: Fri, 14 Jul 2000 12:49:29 +0200
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 4.72.3110.5
X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by ns.secondary.com id CAA11976

<snip>

Denis wrote:

>> >In order to make the text unambiguous it is important to say that: "The 
>> DN MUST be unique  for
>> >each subject entity certified by the one CA as defined by the issuer 
>> name field during the whole
>> >life time of the CA, i.e. two different living human beings cannot have 
>> the same DN."


Stefan responded:

>I agree that this is a good practice. There are however limitations on how 
>far you can make requirements on practice in a technical profile.


QC is not 2459.  QC is supposed to support legal systems and MARKET needs.
For a CA that adhere to the word "Qualified" this is not a hard thing to require.
It is anyway obliged to keep track of its subjects.  So what is the problem????

Without restrictions on DNs QC is IMO redundant.  With the restriction requested by Denis
you got a useful product (sorry - "techical profile" if that feels better).

May I kindly ask potential issuers of QCs to either stand by this statement or
not?

Anders



Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id CAA10879 for <[e-mail]>; Fri, 14 Jul 2000 02:19:52 -0700 (PDT)
Received: from ireserver.Ireland.Sun.COM ([129.156.220.7]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id CAA21115; Fri, 14 Jul 2000 02:21:56 -0700 (PDT)
Received: from sun.com (boston [129.156.220.153]) by ireserver.Ireland.Sun.COM (8.8.8+Sun/8.8.8/ENSMAIL,v1.9) with ESMTP id KAA10683; Fri, 14 Jul 2000 10:21:55 +0100 (BST)
Sender: [e-mail]
Message-ID: <[e-mail]>
Date: Fri, 14 Jul 2000 10:21:55 +0100
From: Sean Mullan <[e-mail]>
X-Mailer: Mozilla 4.51 [en] (X11; U; SunOS 5.7 sun4u)
X-Accept-Language: en
MIME-Version: 1.0
To: Sean Turner <[e-mail]>
CC: [e-mail], [e-mail]
Subject: Re: Reverse paths
References: <396DDFA7.1132.8780334@localhost> <[e-mail]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Sean Turner wrote:
> 
> Reverse path is building is a valid option, but I think the premise when we mandated the forward
> element was to build the path from the EE cert up because you'd at a minimum have the signer's
> certificate (or a pointer to it).  You'd then verify down the chain you built.
> 
> Sean - are you suggesting mandating the reverse element instead of the forward element or in
> addition to it?

In addition. Making it optional doesn't help much for those clients that need or want to
build paths in the reverse direction.

--Sean

> 
> spt
> 
> David Chadwick wrote:
> 
> > Date sent:              Wed, 12 Jul 2000 19:40:47 +0100
> > From:                   Sean Mullan <[e-mail]>
> > To:                     [e-mail], [e-mail], [e-mail]
> > Subject:                Re: I-D ACTION:draft-ietf-pkix-ldap-schema-00.txt
> >
> > Sean
> > this thread should be opened up to the whole PKIX list. I am happy
> > to put this into the LDAPv3 schema if that is what is wanted, but
> > there must have been some earlier discussion as to why it is
> > optional and not mandatory.
> > David
> >
> > > Building certification paths in a 'reverse'
> > > direction (from trust anchor to EE) is a valid way to build
> > > certification paths. However, RFC 2587 (PKIX LDAPv2 schema) specifies
> > > that the storage of cross certificates in the reverse component of the
> > > crossCertificatePair is optional. It is not possible to efficiently
> > > build a certification path in a 'reverse' direction unless the
> > > certificates are populated in the reverse component of the
> > > crossCertificatePair attribute. Specifying that this feature is
> > > optional makes it difficult to build paths in a reverse direction in a
> > > trust model where lots of cross certificates and multiple directories
> > > are involved and you don't know if the CAs support the optional
> > > storage.
> > >
> > > I would like to suggest that RFC 2587 be amended/updated
> > > to make storage of cross certificates in the reverse component of the
> > > crossCertificatePair attribute mandatory.
> > >
> > > Thanks,
> > > Sean
> > >
> >
> > ***************************************************
> >
> > David Chadwick
> > IS Institute, University of Salford, Salford M5 4WT
> > Tel [phone]  Fax [phone]
> > Mobile [phone]
> > Email [e-mail]
> > Home Page  http://www.salford.ac.uk/its024/chadwick.htm
> > Understanding X.500  http://www.salford.ac.uk/its024/X500.htm
> > X.500/LDAP Seminars http://www.salford.ac.uk/its024/seminars.htm
> > Entrust key validation string MLJ9-DU5T-HV8J
> >
> > ***************************************************

-- 
************************************************************
Sean Mullan			  
Java Security & Networking      http://java.sun.com/security
Sun Microsystems                        tel: [phone]
East Point Business Park                fax: [phone]
Dublin 3                          mailto:[e-mail]
Ireland
************************************************************


Received: from popmail.inbox.se (popmail.inbox.se [193.12.72.102]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id CAA10834 for <[e-mail]>; Fri, 14 Jul 2000 02:18:52 -0700 (PDT)
Received: from santesson.accurata.se ([212.28.208.198]) by popmail.inbox.se (8.9.3/8.9.3) with ESMTP id LAA24528; Fri, 14 Jul 2000 11:20:46 +0200
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Version 4.3.2
Date: Fri, 14 Jul 2000 11:22:03 +0200
To: "Anders Rundgren" <[e-mail]>, "Magnus (RSA)" <[e-mail]>, "IETF-PXIX" <[e-mail]>, "Denis" <[e-mail]>
From: Stefan Santesson <[e-mail]>
Subject: Re: QC DN "qualities".  Was: I-D ACTION:draft-ietf-pkix-qc-04.txt
In-Reply-To: <002f01bfed6f$5ab4bbd0$[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed

Anders,

At 10:41 2000-07-14 +0200, Anders Rundgren wrote:
>Denis,
>
><snip>
>
> >In section 4.1.2.6  Subject, RFC 2459 states: "The DN MUST be unique for 
> each subject entity
> >certified by the one CA as defined by the issuer name field."
> >
> >In order to make the text unambiguous it is important to say that: "The 
> DN MUST be unique  for
> >each subject entity certified by the one CA as defined by the issuer 
> name field during the whole
> >life time of the CA, i.e. two different living human beings cannot have 
> the same DN."
>
>
>That is definitely a Quality that QCs should have!  I have already asked 
>about that zillions
>of times with no comments so I guess the authors do not agree....

I agree that this is a good practice. There are however limitations on how 
far you can make requirements on practice in a technical profile.

I think your requirement is more suitable in the applicable policy and in 
the national legislation within the country under which a CA is eastblished.


><snip>
>
>
> >Section 4, Security considerations. The current text is as follows:
>
> >"Comparing two qualified certificates to determine if they represent
> >the same physical entity may provide misleading results and should be
> >performed with care."
>
>
> >This sentence does not help. Replace by:
> >
> >"Comparing two qualified certificates, that contain different DNs, to 
> determine if they represent
> >
> >the same physical entity cannot be made."

Well, this is not true. Comparison can certainly be made in many cases 
within a known context. What the current text implies is that you muste be 
careful and not compare names in contexts where comaprisons don't give the 
desired result.

The definition of context is outside the scope of the technical standards 
work, causing this maby "odd" wording.
If the wording is bad, then I suggest that you come up with some better 
wording. I'm sure that we can then uppgrade the process with this. At least 
on the way to draft standard.


>This is of course correct but the interesting case is when DNs are 
>equal.  But I assume
>that you mean that you can ALWAYS count on the equality case due to the 
>guarantee that
>a QC CA must never reissue a DN.

Again. There are som contexts where comparison is both possible and useful. 
You just have to be careful (at least when creating the application 
comparing certificates) that you compare withing a working context.


>Again, I really like this (and have myself requested this several times) 
>but this is also departs quite a bit from QC-4!
>
>IMO, the two issues mentioned are genuine MARKET REQUIREMENTS rather than 
>just "technicalities".
>
>Anders


/Stefan



Received: from d1o69.telia.com ([e-mail] [62.20.144.241]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id AAA07833 for <[e-mail]>; Fri, 14 Jul 2000 00:40:45 -0700 (PDT)
Received: from mega (t5o69p47.telia.com [213.64.110.47]) by d1o69.telia.com (8.8.8/8.8.8) with SMTP id JAA01592; Fri, 14 Jul 2000 09:42:38 +0200 (CEST)
Message-ID: <002f01bfed6f$5ab4bbd0$[e-mail]>
From: "Anders Rundgren" <[e-mail]>
To: "Magnus (RSA)" <[e-mail]>, "Stefan Santesson" <[e-mail]>, "IETF-PXIX" <[e-mail]>, "Denis" <[e-mail]>
Subject: QC DN "qualities".  Was: I-D ACTION:draft-ietf-pkix-qc-04.txt
Date: Fri, 14 Jul 2000 10:41:46 +0200
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 4.72.3110.5
X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by ns.secondary.com id AAA07834

Denis,

<snip>

>In section 4.1.2.6  Subject, RFC 2459 states: "The DN MUST be unique for each subject entity
>certified by the one CA as defined by the issuer name field."
>
>In order to make the text unambiguous it is important to say that: "The DN MUST be unique  for
>each subject entity certified by the one CA as defined by the issuer name field during the whole
>life time of the CA, i.e. two different living human beings cannot have the same DN."


That is definitely a Quality that QCs should have!  I have already asked about that zillions
of times with no comments so I guess the authors do not agree....

<snip>


>Section 4, Security considerations. The current text is as follows:

>"Comparing two qualified certificates to determine if they represent
>the same physical entity may provide misleading results and should be
>performed with care."


>This sentence does not help. Replace by:
>
>"Comparing two qualified certificates, that contain different DNs, to determine if they represent
>
>the same physical entity cannot be made."


This is of course correct but the interesting case is when DNs are equal.  But I assume
that you mean that you can ALWAYS count on the equality case due to the guarantee that
a QC CA must never reissue a DN.

Again, I really like this (and have myself requested this several times) but this is also departs quite a bit from QC-4!

IMO, the two issues mentioned are genuine MARKET REQUIREMENTS rather than just "technicalities".

Anders




Received: from janus.hosting4u.net (janus.hosting4u.net [209.15.2.37]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id AAA07219 for <[e-mail]>; Fri, 14 Jul 2000 00:16:36 -0700 (PDT)
Received: (qmail 11278 invoked from network); 14 Jul 2000 07:18:30 -0000
Received: from taurus.hosting4u.net (209.15.2.33) by mail-gate.hosting4u.net with SMTP; 14 Jul 2000 07:18:30 -0000
Received: from nma.com ([63.204.17.82]) by taurus.hosting4u.net ; Fri, 14 Jul 2000 02:18:15 -0500
Message-ID: <[e-mail]>
Date: Fri, 14 Jul 2000 00:18:17 -0700
From: Ed Gerck <[e-mail]>
X-Mailer: Mozilla 4.7 [en]C-CCK-MCD {Sony}  (Win98; I)
X-Accept-Language: en
MIME-Version: 1.0
To: [e-mail]
CC: [e-mail], Bob Jueneman <[e-mail]>
Subject: indeed, was  Re: Current signature formats insufficient
References: <000001bfeb13$d25fe870$0201010a@intergalactic>
Content-Type: multipart/alternative; boundary="------------7C245A30570FD376592A4B45"

--------------7C245A30570FD376592A4B45
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit



denis bider wrote:

> It is my opinion that the following efforts need to be made:
>  - The current signature formats need to be extended so as to include
> information about the extent to which the data being signed was verified by
> the signer - or simply whether the signature can be interpreted as binding
> or not.

Indeed.

Around September 1999 I made the same call in this WG, when PKIX was
discussing non-repudiation concepts.  To motivate a simple but already
useful scenario, I suggested a second-order model for validity in four
mutually-exclusive but mutually-neighboring levels.

I also pointed out that we don't need new things for this -- we just to
need to encode the already existing DS and NR bits in keyUsage somewhat
more cleverly.  This would easily provide space to encode four different
levels of validity, in the four possible states of the DS (digital
signature) and NR (nonrepudiation) bits in keyUsage.

Let me extend and exemplify this approach, now that the need to define
more signature attributtes begins to be felt more acutely. These four
levels can be so summarized for the benefit of discussions here, as I
posted to PKIX then (but now with the new two-letter acronyms UP/NP/RP/IP
instead of what I used then: SYN/DS/POA/NR) in terms of a 4-level encoding
using the DS and NR bits in keyUsage:

Application      DS NR      Result
-----------      -----   -----------------------------------------
signed object:    0  0    UP -- unknown presumption when signing
                  1  0    NP  -- no presumption when signing
                  0  1    RP -- rebuttable presumption when signing
                  1  1    IP  -- irrebuttable presumption when signing
authenticated
connection:       0  x    no presumption of authentication
                  1  x    rebuttable presumption of authentication


Based on conversations I've had on and off of this list, including the
DIGSIG list, it would be useful to examine these correspondences also
to *induce* four levels of liability (as Bob Jueneman suggested, for
example). And they can also be used to induce four levels of power, four
levels of rights and four levels of duties.

The cornerstone in this approach is the four levels of validity, as the
basic yardstick which organizes the other decision spaces of liability,
power, rights and duties.

The whole discussion becomes more interesting when the third-order theory
is used with 4^3 = 64 levels of validity, because then we can distinguish
between the validity of the tangible object (called entity), the validity
of the text (called reference) and the validity of the meaning (called
sense), each one with four levels.  But, for now, 4 levels suffice -- thus
describing the object's validity as a whole.  In this case, describing
the signature's validity.

It may be interesting to note also that these four levels are able to
explain the hypothesis predicated in the null-theory model used in
relational databases, which deals with *incomplete information* --
i.e., when the validity of information is not known with certainty
(a very real-world problem).  The idea followed in database theory was
to use special values called "null values" as placeholders for information
that is incomplete. And, lo and behold, they were found already in 1979
by E. F. Codd (the father of relational database theory) -- in three
different types of null values, with the complete information itself
being the fourth type in our classification of validity.  Thus, based
also on other examples from other areas, I consider these four validity
types (as identification types) to be basic types in our grading and
understanding of *information* -- and, therefore, a recurring theme
in our use of information and incomplete information.

The relationship between the four types considered in the null-theory
approach in database theory, the four types of identification considered
in the second-order theory (I-2) summarized here, the legal-based
description of signature validity, and the two-letter
certificate/signature validity label is:

I-2 identification  null-theory          legal validity        cert/sig

D- Distinguished     complete         irrebuttable presumption     IP
A- Ambiguous        one of many       rebuttable presumption       RP
O- Obscure         no specification      no presumption            NP
F- Formless        no-information      unknown presumption         UP

To exemplify, using a text-book database case:

1. the first line corresponds to the middle name of "Franklin Delano
Roosevelt", as he signed the Yalta Agreement -- it has 'complete
information', the middle name is "Delano". The validity is
Distinguished (i.e., unique and singular), there is 'irrebuttable
presumption' of the validity of that middle name, and the the
cert/sig label would be IP for that middle name in a signed message.

2. The second line corresponds to the middle name of "Winston
Churchill", as he signed the Yalta Agreement without his middle
name -- it has 'one of many' information because we know that
Churchill was from a titled English family, so he most probably had
a middle name.  We just do not know which, out of the many possible
and common in the UK.  The validity is Ambiguous, there is 'rebuttable
presumption' if we assume any middle name in a balance of probabilities,
and the cert/sign label would be RP if any particular middle name is
assumed in a signed message.

3. The third line corresponds to "Charles DeGaulle", as he
signed the Yalta Agreement -- it has 'no specification'
information because DeGaulle was French and would not use a
middle name.  So, we most probably expect DeGaulle not to have
a middle name, which means that there would not exist a specifiable
value for it. The validity is Obscure because the middle name is
not specified as non-existent with certainty, even though we
do not expect it to exist.  There is 'no presumption' in a balance
of probabilities if we assume any middle name, since a middle
name is supposed not to exist.  The cert/sign label would be NP
if any particular middle name is assumed in a signed message.

4. The fourth line corresponds to "Joseph Stalin", as he
signed the Yalta Agreement -- it has 'no-information'
because nothing can be inferred for that middle name. Stalin
was Georgian, so he probably had a patronymic as a middle
name but might have abandoned it together with his original
last name (Dzhugashvili). The validity is Formless because
we do not know if the middle name exists but we cannot see
it, or if it does not exist at all. There is 'unknown presumption'
because it is unknown in a balance of probabilities whether
a middle name exists or not. The cert/sign label would be
UP if any particular middle name is assumed in a signed
message.

Other examples can be built, illustrating the concept. The grade
of a student in a course, for example. If we know the grade, it
corresponds to the first line D; if we know that the student took the
exam but we do not know the grade yet, then we have the second line A;
if we know that the student recently registered at the course, then
we have the third line O; if we know that the course ended but we do
not know whether the student stayed in the course until the exam,
then we have the fourth line F.

BTW, if keyUsage is (0,0,0,0,0,0,0,0) then  this can be unambiguously
assigned to UP, as it seems natural.  Since UP is actually a neutral case
(neither affirmative nor denial), the case for CA or CRL bits in
keyUsage can be handled well with DS=NR=0 and can have the usual meanings.

So, there seems to be a practical way to encode four different levels of
validity for signatures, without breaking PKIX's current framework.  We
just need to break some new ground -- digital signatures are not simply
binding or not. There are degrees of binding as well.  And four seems to
be a convenient number to start.

Cheers,

Ed Gerck

--------------7C245A30570FD376592A4B45
Content-Type: text/html; charset=us-ascii
Content-Transfer-Encoding: 7bit

<!doctype html public "-//w3c//dtd html 4.0 transitional//en">
<html>
<tt></tt>&nbsp;<tt></tt>
<p><tt>denis bider wrote:</tt>
<blockquote TYPE=CITE><tt>It is my opinion that the following efforts need
to be made:</tt>
<br><tt>&nbsp;- The current signature formats need to be extended so as
to include</tt>
<br><tt>information about the extent to which the data being signed was
verified by</tt>
<br><tt>the signer - or simply whether the signature can be interpreted
as binding</tt>
<br><tt>or not.</tt></blockquote>
<tt>Indeed.</tt><tt></tt>
<p><tt>Around September 1999 I made the same call in this WG, when PKIX
was</tt>
<br><tt>discussing non-repudiation concepts.&nbsp; To motivate a simple
but already</tt>
<br><tt>useful scenario, I suggested a second-order model for validity
in four</tt>
<br><tt>mutually-exclusive but mutually-neighboring levels.</tt><tt></tt>
<p><tt>I also pointed out that we don't need new things for this -- we
just to</tt>
<br><tt>need to encode the already existing DS and NR bits in keyUsage
somewhat</tt>
<br><tt>more cleverly.&nbsp; This would easily provide space to encode
four different</tt>
<br><tt>levels of validity, in the four possible states of the DS (digital</tt>
<br><tt>signature) and NR (nonrepudiation) bits in keyUsage.</tt><tt></tt>
<p><tt>Let me extend and exemplify this approach, now that the need to
define</tt>
<br><tt>more signature attributtes begins to be felt more acutely. These
four</tt>
<br><tt>levels can be so summarized for the benefit of discussions here,
as I</tt>
<br><tt>posted to PKIX then (but now with the new two-letter acronyms UP/NP/RP/IP</tt>
<br><tt>instead of what I used then: SYN/DS/POA/NR) in terms of a 4-level
encoding</tt>
<br><tt>using the DS and NR bits in keyUsage:</tt><tt></tt>
<p><tt>Application&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; DS NR&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Result</tt>
<br><tt>-----------&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; -----&nbsp;&nbsp; -----------------------------------------</tt>
<br><tt>signed object:&nbsp;&nbsp;&nbsp; 0&nbsp; 0&nbsp;&nbsp;&nbsp; UP
-- unknown presumption when signing</tt>
<br><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
1&nbsp; 0&nbsp;&nbsp;&nbsp; NP&nbsp; -- no presumption when signing</tt>
<br><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
0&nbsp; 1&nbsp;&nbsp;&nbsp; RP -- rebuttable presumption when signing</tt>
<br><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
1&nbsp; 1&nbsp;&nbsp;&nbsp; IP&nbsp; -- irrebuttable presumption when signing</tt>
<br><tt>authenticated</tt>
<br><tt>connection:&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 0&nbsp; x&nbsp;&nbsp;&nbsp;
no presumption of authentication</tt>
<br><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
1&nbsp; x&nbsp;&nbsp;&nbsp; rebuttable presumption of authentication</tt>
<br><tt></tt>&nbsp;<tt></tt>
<p><tt>Based on conversations I've had on and off of this list, including
the</tt>
<br><tt>DIGSIG list, it would be useful to examine these correspondences
also</tt>
<br><tt>to *induce* four levels of liability (as Bob Jueneman suggested,
for</tt>
<br><tt>example). And they can also be used to induce four levels of power,
four</tt>
<br><tt>levels of rights and four levels of duties.</tt><tt></tt>
<p><tt>The cornerstone in this approach is the four levels of validity,
as the</tt>
<br><tt>basic yardstick which organizes the other decision spaces of liability,</tt>
<br><tt>power, rights and duties.</tt><tt></tt>
<p><tt>The whole discussion becomes more interesting when the third-order
theory</tt>
<br><tt>is used with 4^3 = 64 levels of validity, because then we can distinguish</tt>
<br><tt>between the validity of the tangible object (called entity), the
validity</tt>
<br><tt>of the text (called reference) and the validity of the meaning
(called</tt>
<br><tt>sense), each one with four levels.&nbsp; But, for now, 4 levels
suffice -- thus</tt>
<br><tt>describing the object's validity as a whole.&nbsp; In this case,
describing</tt>
<br><tt>the signature's validity.</tt><tt></tt>
<p><tt>It may be interesting to note also that these four levels are able
to</tt>
<br><tt>explain the hypothesis predicated in the null-theory model used
in</tt>
<br><tt>relational databases, which deals with *incomplete information*
--</tt>
<br><tt>i.e., when the validity of information is not known with certainty</tt>
<br><tt>(a very real-world problem).&nbsp; The idea followed in database
theory was</tt>
<br><tt>to use special values called "null values" as placeholders for
information</tt>
<br><tt>that is incomplete. And, lo and behold, they were found already
in 1979</tt>
<br><tt>by E. F. Codd (the father of relational database theory) -- in
three</tt>
<br><tt>different types of null values, with the complete information itself</tt>
<br><tt>being the fourth type in our classification of validity.&nbsp;
Thus, based</tt>
<br><tt>also on other examples from other areas, I consider these four
validity</tt>
<br><tt>types (as identification types) to be basic types in our grading
and</tt>
<br><tt>understanding of *information* -- and, therefore, a recurring theme</tt>
<br><tt>in our use of information and incomplete information.</tt><tt></tt>
<p><tt>The relationship between the four types considered in the null-theory</tt>
<br><tt>approach in database theory, the four types of identification considered</tt>
<br><tt>in the second-order theory (I-2) summarized here, the legal-based</tt>
<br><tt>description of signature validity, and the two-letter</tt>
<br><tt>certificate/signature validity label is:</tt><tt></tt>
<p><tt>I-2 identification&nbsp; null-theory&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
legal validity&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; cert/sig</tt><tt></tt>
<p><tt>D- Distinguished&nbsp;&nbsp;&nbsp;&nbsp; complete&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
irrebuttable presumption&nbsp;&nbsp;&nbsp;&nbsp; IP</tt>
<br><tt>A- Ambiguous&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; one of many&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
rebuttable presumption&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; RP</tt>
<br><tt>O- Obscure&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; no specification&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
no presumption&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
NP</tt>
<br><tt>F- Formless&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; no-information&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
unknown presumption&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; UP</tt><tt></tt>
<p><tt>To exemplify, using a text-book database case:</tt><tt></tt>
<p><tt>1. the first line corresponds to the middle name of "Franklin Delano</tt>
<br><tt>Roosevelt", as he signed the Yalta Agreement -- it has 'complete</tt>
<br><tt>information', the middle name is "Delano". The validity is</tt>
<br><tt>Distinguished (i.e., unique and singular), there is 'irrebuttable</tt>
<br><tt>presumption' of the validity of that middle name, and the the</tt>
<br><tt>cert/sig label would be IP for that middle name in a signed message.</tt><tt></tt>
<p><tt>2. The second line corresponds to the middle name of "Winston</tt>
<br><tt>Churchill", as he signed the Yalta Agreement without his middle</tt>
<br><tt>name -- it has 'one of many' information because we know that</tt>
<br><tt>Churchill was from a titled English family, so he most probably
had</tt>
<br><tt>a middle name.&nbsp; We just do not know which, out of the many
possible</tt>
<br><tt>and common in the UK.&nbsp; The validity is Ambiguous, there is
'rebuttable</tt>
<br><tt>presumption' if we assume any middle name in a balance of probabilities,</tt>
<br><tt>and the cert/sign label would be RP if any particular middle name
is</tt>
<br><tt>assumed in a signed message.</tt><tt></tt>
<p><tt>3. The third line corresponds to "Charles DeGaulle", as he</tt>
<br><tt>signed the Yalta Agreement -- it has 'no specification'</tt>
<br><tt>information because DeGaulle was French and would not use a</tt>
<br><tt>middle name.&nbsp; So, we most probably expect DeGaulle not to
have</tt>
<br><tt>a middle name, which means that there would not exist a specifiable</tt>
<br><tt>value for it. The validity is Obscure because the middle name is</tt>
<br><tt>not specified as non-existent with certainty, even though we</tt>
<br><tt>do not expect it to exist.&nbsp; There is 'no presumption' in a
balance</tt>
<br><tt>of probabilities if we assume any middle name, since a middle</tt>
<br><tt>name is supposed not to exist.&nbsp; The cert/sign label would
be NP</tt>
<br><tt>if any particular middle name is assumed in a signed message.</tt><tt></tt>
<p><tt>4. The fourth line corresponds to "Joseph Stalin", as he</tt>
<br><tt>signed the Yalta Agreement -- it has 'no-information'</tt>
<br><tt>because nothing can be inferred for that middle name. Stalin</tt>
<br><tt>was Georgian, so he probably had a patronymic as a middle</tt>
<br><tt>name but might have abandoned it together with his original</tt>
<br><tt>last name (Dzhugashvili). The validity is Formless because</tt>
<br><tt>we do not know if the middle name exists but we cannot see</tt>
<br><tt>it, or if it does not exist at all. There is 'unknown presumption'</tt>
<br><tt>because it is unknown in a balance of probabilities whether</tt>
<br><tt>a middle name exists or not. The cert/sign label would be</tt>
<br><tt>UP if any particular middle name is assumed in a signed</tt>
<br><tt>message.</tt><tt></tt>
<p><tt>Other examples can be built, illustrating the concept. The grade</tt>
<br><tt>of a student in a course, for example. If we know the grade, it</tt>
<br><tt>corresponds to the first line D; if we know that the student took
the</tt>
<br><tt>exam but we do not know the grade yet, then we have the second
line A;</tt>
<br><tt>if we know that the student recently registered at the course,
then</tt>
<br><tt>we have the third line O; if we know that the course ended but
we do</tt>
<br><tt>not know whether the student stayed in the course until the exam,</tt>
<br><tt>then we have the fourth line F.</tt><tt></tt>
<p><tt>BTW, if keyUsage is (0,0,0,0,0,0,0,0) then&nbsp; this can be unambiguously</tt>
<br><tt>assigned to UP, as it seems natural.&nbsp; Since UP is actually
a neutral case</tt>
<br><tt>(neither affirmative nor denial), the case for CA or CRL bits in</tt>
<br><tt>keyUsage can be handled well with DS=NR=0 and can have the usual
meanings.</tt><tt></tt>
<p><tt>So, there seems to be a practical way to encode four different levels
of</tt>
<br><tt>validity for signatures, without breaking PKIX's current framework.&nbsp;
We</tt>
<br><tt>just need to break some new ground -- digital signatures are not
simply</tt>
<br><tt>binding or not. There are degrees of binding as well.&nbsp; And
four seems to</tt>
<br><tt>be a convenient number to start.</tt><tt></tt>
<p><tt>Cheers,</tt><tt></tt>
<p><tt>Ed Gerck</tt></html>

--------------7C245A30570FD376592A4B45--



Received: from smtp-out1.bellatlantic.net (smtp-out1.bellatlantic.net [199.45.39.156]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id PAA10849 for <[e-mail]>; Thu, 13 Jul 2000 15:44:13 -0700 (PDT)
Received: from ieca.com (adsl-151-200-26-46.bellatlantic.net [151.200.26.46]) by smtp-out1.bellatlantic.net (8.9.1/8.9.1) with ESMTP id SAA11392; Thu, 13 Jul 2000 18:46:00 -0400 (EDT)
Message-ID: <[e-mail]>
Date: Thu, 13 Jul 2000 18:44:05 -0400
From: Sean Turner <[e-mail]>
Organization: IECA, Inc.
X-Mailer: Mozilla 4.73 [en] (Win98; U)
X-Accept-Language: en
MIME-Version: 1.0
To: [e-mail], Sean Mullan <[e-mail]>
CC: [e-mail]
Subject: Re: Reverse paths
References: <396DDFA7.1132.8780334@localhost>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Reverse path is building is a valid option, but I think the premise when we mandated the forward
element was to build the path from the EE cert up because you'd at a minimum have the signer's
certificate (or a pointer to it).  You'd then verify down the chain you built.

Sean - are you suggesting mandating the reverse element instead of the forward element or in
addition to it?

spt

David Chadwick wrote:

> Date sent:              Wed, 12 Jul 2000 19:40:47 +0100
> From:                   Sean Mullan <[e-mail]>
> To:                     [e-mail], [e-mail], [e-mail]
> Subject:                Re: I-D ACTION:draft-ietf-pkix-ldap-schema-00.txt
>
> Sean
> this thread should be opened up to the whole PKIX list. I am happy
> to put this into the LDAPv3 schema if that is what is wanted, but
> there must have been some earlier discussion as to why it is
> optional and not mandatory.
> David
>
> > Building certification paths in a 'reverse'
> > direction (from trust anchor to EE) is a valid way to build
> > certification paths. However, RFC 2587 (PKIX LDAPv2 schema) specifies
> > that the storage of cross certificates in the reverse component of the
> > crossCertificatePair is optional. It is not possible to efficiently
> > build a certification path in a 'reverse' direction unless the
> > certificates are populated in the reverse component of the
> > crossCertificatePair attribute. Specifying that this feature is
> > optional makes it difficult to build paths in a reverse direction in a
> > trust model where lots of cross certificates and multiple directories
> > are involved and you don't know if the CAs support the optional
> > storage.
> >
> > I would like to suggest that RFC 2587 be amended/updated
> > to make storage of cross certificates in the reverse component of the
> > crossCertificatePair attribute mandatory.
> >
> > Thanks,
> > Sean
> >
>
> ***************************************************
>
> David Chadwick
> IS Institute, University of Salford, Salford M5 4WT
> Tel [phone]  Fax [phone]
> Mobile [phone]
> Email [e-mail]
> Home Page  http://www.salford.ac.uk/its024/chadwick.htm
> Understanding X.500  http://www.salford.ac.uk/its024/X500.htm
> X.500/LDAP Seminars http://www.salford.ac.uk/its024/seminars.htm
> Entrust key validation string MLJ9-DU5T-HV8J
>
> ***************************************************



Received: from smtp03.mrf.mail.rcn.net (smtp03.mrf.mail.rcn.net [207.172.4.62]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id MAA06870 for <[e-mail]>; Thu, 13 Jul 2000 12:02:50 -0700 (PDT)
Received: from 208-58-194-27.s535.tnt9.lnhva.md.dialup.rcn.com ([208.58.194.27] helo=rankney) by smtp03.mrf.mail.rcn.net with smtp (Exim 3.15 #2) id 13CoHw-00061x-00; Thu, 13 Jul 2000 15:04:48 -0400
Message-ID: <001d01bfecff$fe9bc420$1bc23ad0@rankney>
From: "Rich Ankney" <[e-mail]>
To: <[e-mail]>, "Michael Zolotarev" <[e-mail]>
Cc: "Adrian McCullagh" <[e-mail]>, "'Simon McMahon'" <[e-mail]>, "Tony Bartoletti" <[e-mail]>, "P.J. Ponder" <[e-mail]>, "Paul Koning" <[e-mail]>, <[e-mail]>, <[e-mail]>
Subject: Re: Current signature formats insufficient
Date: Thu, 13 Jul 2000 15:24:38 -0400
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 4.72.3155.0
X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3155.0

I agree.  This is similar to the "commitment type" in the ETSI electronic
signature work, the "signature purpose" in ANSI X9.45 and ASTM
E-2084, and the "business purpose of assurance" in X12.

/ Rich

-----Original Message-----
From: [e-mail] <[e-mail]>
To: Michael Zolotarev <[e-mail]>
Cc: Adrian McCullagh <[e-mail]>; 'Simon McMahon'
<[e-mail]>; Tony Bartoletti <[e-mail]>; P.J. Ponder
<[e-mail]>; Paul Koning <[e-mail]>;
[e-mail] <[e-mail]>; [e-mail]
<[e-mail]>
Date: Thursday, July 13, 2000 11:30 AM
Subject: RE: Current signature formats insufficient


>     Qualification of a signature to say a) I saw this, but I am not
>agreeing with it; b) I agree with this; c) I promise to do this (or other
>similar qualifications) strikes me as a good use of PKCS #7 Authenticated
>Attributes, CMS Signed Attributes or XML Signature Properties.  I thought
>that Denis' original proposal was intended to allow a smart card itself to
>incorporate some very simple assertions about signature conditions into the
>signature.  If the smart card is restricted to a single format, it might be
>able to place such an assertion into that format.  If it's like one of
>today's smart cards, it's not very format aware which is why placing the
>assertion into the signature itself was attractive.
>
>          Tom Gindin
>
>Michael Zolotarev <[e-mail]> on 07/13/2000 12:45:09 AM
>
>To:   Adrian McCullagh <[e-mail]>, "'Simon
>      McMahon'" <[e-mail]>, Michael Zolotarev
>      <[e-mail]>, Tony Bartoletti <[e-mail]>, "P.J.
>      Ponder" <[e-mail]>
>cc:   Paul Koning <[e-mail]>, [e-mail],
>      [e-mail]
>Subject:  RE: Current signature formats insufficient
>
>
>
>Adrian,
>
>God, do you guys ever come to understand Russian sense of humor?
>
>I was just trying to show that introducing a special key usage bit is not
>going to solve the problem. Which is, of course, to indicate whether a
>signer agrees or not with the content of the message.
>
>I was saying that you can do it only by having a statement (AGREE or DO NOT
>AGREE) INSIDE the content, and signing that content with your key. Exactly
>as you do it on the paper: "Solemnly agree:_______".
>
>Following the 'key usage bit' approach you'd have to have two different
>keys
>- one for 'agree with the content', and another for 'do not agree with
>content'.
>
>My 'agree with doubts' list was an [unsuccessful] attempt to demonstrate
>what kind of absurd you can get into with using the key usage flags.
>
>Best regards
>Michael
>
>PS Are you in Sydney, BTW?
>
>
>
>> -----Original Message-----
>> From: Adrian McCullagh [mailto:[e-mail]]
>> Sent: Thursday, July 13, 2000 2:29 PM
>> To: 'Simon McMahon'; Michael Zolotarev; Tony Bartoletti; P.J. Ponder
>> Cc: Paul Koning; [e-mail]; [e-mail]
>> Subject: RE: Current signature formats insufficient
>>
>>
>> -----BEGIN PGP SIGNED MESSAGE-----
>> Hash: SHA1
>>
>> Michael & Simon;
>>
>> I do not agree with your position.
>>
>> You either agree or you do not agree.  The positions are mutually
>> exclusive.  The issue of qualification if put forward only complicates
>> the situation.  If you want to qualify then you must in my opinion
>> fall within the "do not agree" position.
>>
>> Why complicate the situation with:
>>
>> > 1. Strongly agree
>> > 2. Agree
>> > 3. Agree with reservations
>> > 4. Agree with a certain doubt
>>
>> What is the difference between agree and strongly agree.  It does not
>> add anything by qualifying the agreed position.  A certainly doubt
>> that a Court would take notice of varying positions of agreement.  You
>> either agree or do not agree.
>>
>>
>>
>> - -----Original Message-----
>> From: Simon McMahon [mailto:[e-mail]]
>> Sent: Thursday, July 13, 2000 2:09 PM
>> To: Michael Zolotarev; Tony Bartoletti; P.J. Ponder
>> Cc: Paul Koning; [e-mail]; [e-mail]
>> Subject: Re: Current signature formats insufficient
>>
>>
>> Michael wrote :
>> > Using a special key usage bit to specify your agreement is not very
>> > practical. Why? You'd have to define the following set:
>> >
>> > 1. Strongly agree
>> > 2. Agree
>> > 3. Agree with reservations
>> > 4. Agree with a certain doubt
>> >
>>
>> Thats right - the content contains all the details about what and how
>> much
>> committment is being made. The signature format is irrelevant accept
>> that it
>> has to be validatable.
>>
>> Simon.
>>
>>
>> -----BEGIN PGP SIGNATURE-----
>> Version: PGP Personal Edition 6.0.2
>>
>> iQA/AwUBOWy4RZWt1NGjt4vzEQL3iQCg6potAez5JhLSDtdGF26UaeG2ziUAoOmy
>> sdwXFWc2hVsvm4P00KfXJz21
>> =H1pM
>> -----END PGP SIGNATURE-----
>>
>
>
>



Received: from poptop.llnl.gov (poptop.llnl.gov [128.115.41.70]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id LAA05778 for <[e-mail]>; Thu, 13 Jul 2000 11:11:28 -0700 (PDT)
Received: from catalyst (catalyst.llnl.gov [128.115.222.68]) by poptop.llnl.gov (8.8.8/LLNL-3.0.2/pop.llnl.gov-5.1) with ESMTP id LAA14572; Thu, 13 Jul 2000 11:07:39 -0700 (PDT)
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.2 
Date: Thu, 13 Jul 2000 11:14:54 -0700
To: Adrian McCullagh <[e-mail]>, "'Simon McMahon'" <[e-mail]>, "'Ben Laurie'" <[e-mail]>, Frank Balluffi <[e-mail]>
From: Tony Bartoletti <[e-mail]>
Subject: RE: Current signature formats insufficient
Cc: [e-mail], [e-mail]
In-Reply-To: <[e-mail] .au>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed

At 03:03 PM 7/13/00 +1000, Adrian McCullagh wrote:

>The first paper provides an argument that the concept of witnessing is
>inappropriate for the electronic commerce environment.  A new position
>legally should be the concept of verifying.  At law a witness must have an
>uninterrupted view of the signer actually affixing the mark that will bind
>the signer to the contents of the document.  Now a witness can not actually
>see such an affixation in the digital environment.  All a witness can do is
>see the person pressing some keys.  The program could be doing anything.  So
>in my scenario the verifier will first verify that there does exist,
>attached to the document, a digital signature that has been affixed using
>the alleged signers private key.  Once verified the verifier will affix
>their digital signature that will clearly note the second signer as a
>verifier and not as the person who is to be bound by the contents of the
>document.  My paper expands this concept somewhat.

Not being a lawyer myself ...

In the paper tradition, I assume (based in part on the Almedio case
you described earlier) that the witness has at least some implied
obligation to reasonably ensure that the signer, beyond simply
affixing their signature, understands what is being signed.
(In the case you describe, is seemed plain that it should have
been obvious to the witnesses that the signers likely could not
understand the terms sufficiently.)

Does this quality of "witnessing" carry over into the digital realm?
(Another multiple-choice test protocol, perhaps? :)

____tony____

Tony Bartoletti 925-422-3881 <[e-mail]>
Information Operations, Warfare and Assurance Center
Lawrence Livermore National Laboratory
Livermore, CA 94551-9900



Received: from poptop.llnl.gov (poptop.llnl.gov [128.115.41.70]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id KAA05240 for <[e-mail]>; Thu, 13 Jul 2000 10:53:56 -0700 (PDT)
Received: from catalyst (catalyst.llnl.gov [128.115.222.68]) by poptop.llnl.gov (8.8.8/LLNL-3.0.2/pop.llnl.gov-5.1) with ESMTP id KAA03010; Thu, 13 Jul 2000 10:49:32 -0700 (PDT)
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.2 
Date: Thu, 13 Jul 2000 10:56:48 -0700
To: "Simon McMahon" <[e-mail]>, "Adrian McCullagh" <[e-mail]>, "'Ben Laurie'" <[e-mail]>, "Frank Balluffi" <[e-mail]>
From: Tony Bartoletti <[e-mail]>
Subject: Re: Current signature formats insufficient
Cc: <[e-mail]>, <[e-mail]>
In-Reply-To: <013a01bfec84$ae7ed890$[e-mail]>
References: <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed

At 02:41 PM 7/13/00 +1000, Simon McMahon wrote:
>My point is that witnessing is the right way to boost non-repudiation (that
>failed in this case) to a level where big dollars are involved. Non
>witnessed signatures, standard or digital, must therefore be more vulnerable
>to repudiation claims. A digital witness would need to assure that the
>witnessed signature was made with a trustworthy signing device and that the
>signer understood what was being signed.

I agree.

>I can concieve of a trustworthy signing device, not at home but at a bank
>branch or kiosk, that accepts a smart card with my private key on it.
>Authenticates me and makes me say 'Y' to "do you understand and wish to sign
>what you have read above ?" (wherever "above" happens to be) and then
>applies my signature. It then counter signs my signature with its private
>key which the RP can recognise as that of a trusted device. The RP may not
>know for sure that I actually understood what I was supposed to have read,
>only a human witness, in my opinion could do that, but the RP has high
>assurance that the signature is not the result of a hacked PC with an SC
>reader.

Now, I'm thinking of a protocol where (again from a trusted installation
such as a kiosk) once you supposedly have read the "terms of agreement",
the process walks you through several, randomly generated multiple choice
questions regarding these terms, presented in random order.  Failure to
get 100% on this "quiz" takes you back to the screens to review the terms.
Success on this quiz is digitally certified and accompanies the signed
agreement.

This (though a bit awkward) would make it considerably harder to claim
"I didn't understand what I was signing."

___tony___



>Simon McMahon
>
>

Tony Bartoletti 925-422-3881 <[e-mail]>
Information Operations, Warfare and Assurance Center
Lawrence Livermore National Laboratory
Livermore, CA 94551-9900



Received: from e4.ny.us.ibm.com (e4.ny.us.ibm.com [32.97.182.104]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id IAA27695 for <[e-mail]>; Thu, 13 Jul 2000 08:31:14 -0700 (PDT)
From: [e-mail]
Received: from northrelay02.pok.ibm.com (northrelay02.pok.ibm.com [9.117.200.22]) by e4.ny.us.ibm.com (8.9.3/8.9.3) with ESMTP id LAA136566; Thu, 13 Jul 2000 11:33:17 -0400
Received: from D51MTA04.pok.ibm.com (d51mta04.pok.ibm.com [9.117.200.32]) by northrelay02.pok.ibm.com (8.8.8m3/NCO v4.92) with SMTP id LAA35560; Thu, 13 Jul 2000 11:33:14 -0400
Received: by D51MTA04.pok.ibm.com(Lotus SMTP MTA v4.6.5  (863.2 5-20-1999))  id 8525691B.00556E52 ; Thu, 13 Jul 2000 11:33:08 -0400
X-Lotus-FromDomain: IBMUS
To: "Simon McMahon" <[e-mail]>
cc: "Adrian McCullagh" <[e-mail]>, "'Tony Bartoletti'" <[e-mail]>, "'Ben Laurie'" <[e-mail]>, "Frank Balluffi" <[e-mail]>, [e-mail], [e-mail]
Message-ID: <[e-mail]>
Date: Thu, 13 Jul 2000 11:33:02 -0400
Subject: Re: Current signature formats insufficient
Mime-Version: 1.0
Content-type: text/plain; charset=us-ascii
Content-Disposition: inline

     I think the witness is also usually witnessing the signer's identity,
that the signer is physically present and is not obviously being coerced.
In fact, he's a lot better at witnessing these things than that the signer
read the document in full, far less than that he understood it.  A
biometric device might be a valid witness to some of these things, but not
all, and the other devices involved are witnesses to much less.
     The smart card itself is witnessing only that certain procedures
involving it directly have (or have not) been carried out, and that it was
sent the data it is signing.

          Tom Gindin

"Simon McMahon" <[e-mail]> on 07/13/2000 02:26:48 AM

To:   "Adrian McCullagh" <[e-mail]>, "'Tony
      Bartoletti'" <[e-mail]>, "'Ben Laurie'" <[e-mail]>,
      "Frank Balluffi" <[e-mail]>
cc:   <[e-mail]>, <[e-mail]>
Subject:  Re: Current signature formats insufficient



Adrian,

> If you would like I have 2 academic papers that deal with the issues
raised
> here from a legal perspective.  Both papers have been published by
> universities but I am not sure whether they are on the internet.
>
I'm sure they will be tough reading but, yes, please post the URLs if they
exist or post binaries direct to me (I think mailing list policy is not to
post binary attachments).

I understand that a human withness to a digital signature is at a
disadvantage for the reason you stated, but couldn't the law recognise a
certified "device" operating under its normal operating conditions as a
witness to the affixation of a digital signature to some content ? It is
after all the device doing it. A human witness could still be involved but
would be witnessing something else, e.g. that the signer understood the
content.

German law obviously already recognises certified signing devices as
relevant to legally binding signatures.

It looks to me like the concept of a witness is overloaded because humans
are naturally pretty versatile. Breaking down what a witness does, or is,
might make it easier to digitize their functions. Maybe that is what your
paper's "verifier" is.

What happened to "Current signature formats insufficient" ? Better post me
those papers quick !

Thanks,

Simon McMahon





Received: from e3.ny.us.ibm.com (e3.ny.us.ibm.com [32.97.182.103]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id IAA27079 for <[e-mail]>; Thu, 13 Jul 2000 08:24:54 -0700 (PDT)
From: [e-mail]
Received: from northrelay02.pok.ibm.com (northrelay02.pok.ibm.com [9.117.200.22]) by e3.ny.us.ibm.com (8.9.3/8.9.3) with ESMTP id LAA95430; Thu, 13 Jul 2000 11:26:51 -0400
Received: from D51MTA04.pok.ibm.com (d51mta04.pok.ibm.com [9.117.200.32]) by northrelay02.pok.ibm.com (8.8.8m3/NCO v4.92) with SMTP id LAA180544; Thu, 13 Jul 2000 11:26:47 -0400
Received: by D51MTA04.pok.ibm.com(Lotus SMTP MTA v4.6.5  (863.2 5-20-1999))  id 8525691B.0054D824 ; Thu, 13 Jul 2000 11:26:43 -0400
X-Lotus-FromDomain: IBMUS
To: Michael Zolotarev <[e-mail]>
cc: Adrian McCullagh <[e-mail]>, "'Simon McMahon'" <[e-mail]>, Tony Bartoletti <[e-mail]>, "P.J. Ponder" <[e-mail]>, Paul Koning <[e-mail]>, [e-mail], [e-mail]
Message-ID: <[e-mail]>
Date: Thu, 13 Jul 2000 11:26:32 -0400
Subject: RE: Current signature formats insufficient
Mime-Version: 1.0
Content-type: text/plain; charset=us-ascii
Content-Disposition: inline

     Qualification of a signature to say a) I saw this, but I am not
agreeing with it; b) I agree with this; c) I promise to do this (or other
similar qualifications) strikes me as a good use of PKCS #7 Authenticated
Attributes, CMS Signed Attributes or XML Signature Properties.  I thought
that Denis' original proposal was intended to allow a smart card itself to
incorporate some very simple assertions about signature conditions into the
signature.  If the smart card is restricted to a single format, it might be
able to place such an assertion into that format.  If it's like one of
today's smart cards, it's not very format aware which is why placing the
assertion into the signature itself was attractive.

          Tom Gindin

Michael Zolotarev <[e-mail]> on 07/13/2000 12:45:09 AM

To:   Adrian McCullagh <[e-mail]>, "'Simon
      McMahon'" <[e-mail]>, Michael Zolotarev
      <[e-mail]>, Tony Bartoletti <[e-mail]>, "P.J.
      Ponder" <[e-mail]>
cc:   Paul Koning <[e-mail]>, [e-mail],
      [e-mail]
Subject:  RE: Current signature formats insufficient



Adrian,

God, do you guys ever come to understand Russian sense of humor?

I was just trying to show that introducing a special key usage bit is not
going to solve the problem. Which is, of course, to indicate whether a
signer agrees or not with the content of the message.

I was saying that you can do it only by having a statement (AGREE or DO NOT
AGREE) INSIDE the content, and signing that content with your key. Exactly
as you do it on the paper: "Solemnly agree:_______".

Following the 'key usage bit' approach you'd have to have two different
keys
- one for 'agree with the content', and another for 'do not agree with
content'.

My 'agree with doubts' list was an [unsuccessful] attempt to demonstrate
what kind of absurd you can get into with using the key usage flags.

Best regards
Michael

PS Are you in Sydney, BTW?



> -----Original Message-----
> From: Adrian McCullagh [mailto:[e-mail]]
> Sent: Thursday, July 13, 2000 2:29 PM
> To: 'Simon McMahon'; Michael Zolotarev; Tony Bartoletti; P.J. Ponder
> Cc: Paul Koning; [e-mail]; [e-mail]
> Subject: RE: Current signature formats insufficient
>
>
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Michael & Simon;
>
> I do not agree with your position.
>
> You either agree or you do not agree.  The positions are mutually
> exclusive.  The issue of qualification if put forward only complicates
> the situation.  If you want to qualify then you must in my opinion
> fall within the "do not agree" position.
>
> Why complicate the situation with:
>
> > 1. Strongly agree
> > 2. Agree
> > 3. Agree with reservations
> > 4. Agree with a certain doubt
>
> What is the difference between agree and strongly agree.  It does not
> add anything by qualifying the agreed position.  A certainly doubt
> that a Court would take notice of varying positions of agreement.  You
> either agree or do not agree.
>
>
>
> - -----Original Message-----
> From: Simon McMahon [mailto:[e-mail]]
> Sent: Thursday, July 13, 2000 2:09 PM
> To: Michael Zolotarev; Tony Bartoletti; P.J. Ponder
> Cc: Paul Koning; [e-mail]; [e-mail]
> Subject: Re: Current signature formats insufficient
>
>
> Michael wrote :
> > Using a special key usage bit to specify your agreement is not very
> > practical. Why? You'd have to define the following set:
> >
> > 1. Strongly agree
> > 2. Agree
> > 3. Agree with reservations
> > 4. Agree with a certain doubt
> >
>
> Thats right - the content contains all the details about what and how
> much
> committment is being made. The signature format is irrelevant accept
> that it
> has to be validatable.
>
> Simon.
>
>
> -----BEGIN PGP SIGNATURE-----
> Version: PGP Personal Edition 6.0.2
>
> iQA/AwUBOWy4RZWt1NGjt4vzEQL3iQCg6potAez5JhLSDtdGF26UaeG2ziUAoOmy
> sdwXFWc2hVsvm4P00KfXJz21
> =H1pM
> -----END PGP SIGNATURE-----
>





Received: from odin2.bull.net (odin2.bull.net [192.90.70.84]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id HAA25513 for <[e-mail]>; Thu, 13 Jul 2000 07:32:14 -0700 (PDT)
Received: from lvt-mail.frlv.bull.fr (lvt-mail.frlv.bull.fr [129.184.62.223]) by odin2.bull.net (8.9.2/8.9.1) with ESMTP id QAA19750 for <[e-mail]>; Thu, 13 Jul 2000 16:33:31 +0200
Received: from bull.net (fradint93.bull.fr [129.181.85.93]) by lvt-mail.frlv.bull.fr (8.9.2/8.9.1) with ESMTP id QAA23776 for <[e-mail]>; Thu, 13 Jul 2000 16:33:30 +0200
Message-ID: <[e-mail]>
Date: Thu, 13 Jul 2000 16:31:54 +0200
From: Denis <[e-mail]>
X-Mailer: Mozilla 4.5 [fr] (Win98; I)
X-Accept-Language: fr
MIME-Version: 1.0
To: IETF-PXIX <[e-mail]>
Subject: Re: I-D ACTION:draft-ietf-pkix-qc-04.txt
References: <[e-mail]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Comments on QC-04 (draft-ietf-pkix-qc-04.txt)

A major improvement has been done with the publication of QC-4, since the notion of "unmistakable
identity" has now disappeared . However, the new text still does not solve the issues that have
been raised on that topic.

COMMENT 1

The most important section is section 2.4. (Uniqueness of names) where the word "unique" is not
used anywhere, except in the title). This section says:

In section 4.1.2.6  Subject, RFC 2459 states: "The DN MUST be unique for each subject entity
certified by the one CA as defined by the issuer name field."

In order to make the text unambiguous it is important to say that: "The DN MUST be unique  for
each subject entity certified by the one CA as defined by the issuer name field during the whole
life time of the CA, i.e. two different living human beings cannot have the same DN."

The current text, copied below, does not bring anything really useful for the topic, and could
advantageously be deleted.

In the context of qualified certificates, a distinguished name denotes a set of attribute values
[X.501] which forms a name that is unambiguous within a certain domain that forms either a real
or a virtual DIT (Directory Information Tree)[X.501].  In the case of subject names the domain is
assumed to be at least the issuing domain of the CA.

COMMENT 2

Section 3.1.1. Issuer states:  "The issuer field SHALL identify the organization responsible
for    issuing the certificate, and SHALL include a registered name of the organization".

The basic question is what is the meaning of a "registered" name. Who should be the registration
authority ? Do we have such an authority for registered names in the IETF ? Is this authority
adequate for such a usage ? Instead of trying to answer the question, it makes more sense to omit
the second part of the sentence which leads to the following sentence: "The issuer field SHALL
identify the organization responsible for issuing the certificate".

COMMENT 3

Section 3.1.1. Issuer states:  "The legal jurisdiction for the issuing CA SHOULD be consistent
with the issuer name.". However the  abstract says: "   The goal of this document is to define a
general syntax independent of local legal requirements." and also " It is important to note that
the profile does not define any legal requirements for Qualified Certificates.". This is
contradictory. From the discussions that recently took place in Stockholm, the agreement was to
mandate the inclusion of the country where from the CA is operating. In this way, by indirection,
the country where the CA is established may implement a supervision scheme, if required.

The text should be modified to reflect this. It should be noticed that taking this into
consideration, the first element of a DN for an issuer must then be a country name. This should
be reflected in the text.

Full text proposal replacement for 3.1.1:

3.1.1  Issuer

The issuer field SHALL identify the organization responsible for
issuing the certificate.

The identity of the issuer SHALL be specified using an appropriate
subset of the following attributes:

         domainComponent;
         countryName;
         stateOrProvinceName;
         organizationName;
         localityName; and
         serialNumber.

Additional attributes MAY be present but they SHOULD NOT be necessary to identify the issuing
organization. The first element of the DN shall be the country where the CA is operating from.


COMMENT 4

The text is not consistent when talking about certificate policies and public statements.

In section 2.2. Statement of Purpose, the text says:

"For a certificate to serve the purpose of being a Qualified
Certificate, this profile assumes that the CA will have to include in
the certificate a public statement that explicitly defines this
intent."

In section 3.2.2.Certificate Policies, the text says:

" A statement by the issuer stating the purpose of the certificate as
discussed in Section 2.2 SHOULD be evident through indicated
policies."

The later statement is not that "evident" at all, in particular since from section 2.2. any
certificate policy may be used, provided that it is consistent with the policy for a QC.

The basic question is the following: How is it possible to know that a certificate is a QC ?
There are two possible answers:

a) use a QC statement to tell it (and this "costs" a new extension),
b) use some pre-defined Certificate Policy OID to tell it (and this costs no new extension).

The text from section 2.2. mandates the inclusion of a QC statement. However, all current
software is able to test for the presence of any Certificate Policy OID in a certificate and thus
the current software could easily check for the presence of pre-defined Certificate Policy OIDs
for QCs. The QC statement mandates the use of a new extension, that no one has yet implemented,
both for the construction of the certificate and the checking of a certification path.

Should we really mandate the presence of the QC statement (as being the only way to indicate that
a certificate is a QC) or should we also allow the use of pre-defined Certificate Policy OID
(making the QC statement non mandatory) ?

I think both options should be mentioned as possible

Note: I must recognise that the following text belonging to section 3.2.2 is not understandable
to me:
" In order to enhance path validation based on policy object identifiers any statement related
to  Qualified Certificates, as defined in 3.2.5, SHOULD also be defined by included certificate
policies."

COMMENT 5

Section 3.2.5. Qualified Certificate Statements, defines an extension for inclusion of defined
statements related to Qualified Certificates. However, there is a major problem with the way the
extension is built. It is constructed as:

 QCStatements ::= SEQUENCE OF QCStatement

Since nothing is said in the text about the criticality this extension is, by implication, non
critical. This means that any individual  QCStatement is not mandatory to understand. So unless
an application specifically looks for some pre-defined statement, it will miss the others and is
not required to "understand them. Also remember that only ONE such extension may be present.

In a profile of this document (not a PKIX document) this extension is being used to specify the
maximum amount of money which is permissible for one transaction, this is what is referred in
QC-04 as "a maximum reliance limit for the certificate indicating restrictions on CA's
liability".

The basic question is whether we should have a separate extension for a maximum reliance from a
CA.

If the maximum reliance limit statement is part of the new extension, there is no guarantee that
it will ever be seen or recognized. In principle any QCStatement in a non critical extension may
be ignored by the application.

If the maximum reliance limit statement is in a separate extension marked critical, no
application could miss it, if it is present.

The requirement comes from an annex of the European Directive. The definition of a maximum
reliance limit is optional and it makes sense to have a dedicated extension to support it.

I would thus propose to suppress the following sentence from 3.2.5: "As an example this MAY
include a maximum reliance limit for the certificate indicating restrictions on CA's liability."

Instead I would propose to define a separate extension to support a maximum reliance limit.

COMMENT 6

Section 4, Security considerations. This section has major problems. It uses some arguments to
provide wrong conclusions. The current text is as follows:

" Since the public keys are for public use with legal implications for
involved parties, certain conditions should exist before CAs issues
certificates as Qualified Certificates. The associated private keys
must be unique for the subject, and must be maintained under the
subject's sole control.  That is, a CA should not issue a qualified
certificate if the private key is shared among entities, or the means
to use the private key is not protected against unintended usage.
This implies that the CA must perform proof-of-possession of the
private key. In addition, it implies that the CA have some knowledge
about the subject's cryptographic module."

The text says that a "CA should not issue a qualified certificate if the private key is shared
among entities". This is fine, but the CA has no way to know whether the private key has been
given to someone else. Proof-of-possession of the private key does not solve the issue as well,
since everyone who has been given the private key could provide proof-of-possession.

What is transparent from the text, but not said correctly, is that if a physical device is used,
then it becomes "more difficult" to share the private key. Proposed text full replacement for the
text above:

"The private keys must be maintained under the subject's sole control.  That is, a CA should not
issue a qualified certificate if the means to use the private key is not protected against
unintended usage. It implies that the CA should have some knowledge about the subject's
cryptographic module."

It should be realized also that proof-of-possession is NOT needed at all what using good
cryptography practice. As soon as the identifier of the certificate being used is protected by
the digital signature, then proof-of-possession becomes unnecessary. Why not say it ?

COMMENT 7

Section 4, Security considerations. The current text is as follows:

"Comparing two qualified certificates to determine if they represent
the same physical entity may provide misleading results and should be
performed with care."

This sentence does not help. Replace by:

"Comparing two qualified certificates, that contain different DNs, to determine if they represent

the same physical entity cannot be made."

Denis






Received: from mta03-svc.ntlworld.com (mta03-svc.ntlworld.com [62.253.162.43]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id HAA25242 for <[e-mail]>; Thu, 13 Jul 2000 07:25:35 -0700 (PDT)
Received: from dwc-acer ([62.252.104.255]) by mta03-svc.ntlworld.com (InterMail vM.4.01.02.27 201-229-119-110) with ESMTP id <20000713142736.UOVS16423.mta03-svc.ntlworld.com@dwc-acer>; Thu, 13 Jul 2000 15:27:36 +0100
From: "David Chadwick" <[e-mail]>
Organization: University of Salford
To: [e-mail], Sean Mullan <[e-mail]>
Date: Thu, 13 Jul 2000 15:26:31 +0100
MIME-Version: 1.0
Content-type: text/plain; charset=US-ASCII
Content-transfer-encoding: 7BIT
Subject: Reverse paths
Reply-to: [e-mail]
Message-ID: <396DDFA7.1132.8780334@localhost>
Priority: normal
In-reply-to: <[e-mail]>
X-mailer: Pegasus Mail for Win32 (v3.12c)

Date sent:      	Wed, 12 Jul 2000 19:40:47 +0100
From:           	Sean Mullan <[e-mail]>
To:             	[e-mail], [e-mail], [e-mail]
Subject:        	Re: I-D ACTION:draft-ietf-pkix-ldap-schema-00.txt

Sean 
this thread should be opened up to the whole PKIX list. I am happy 
to put this into the LDAPv3 schema if that is what is wanted, but 
there must have been some earlier discussion as to why it is 
optional and not mandatory.
David


> Building certification paths in a 'reverse'
> direction (from trust anchor to EE) is a valid way to build
> certification paths. However, RFC 2587 (PKIX LDAPv2 schema) specifies
> that the storage of cross certificates in the reverse component of the
> crossCertificatePair is optional. It is not possible to efficiently
> build a certification path in a 'reverse' direction unless the
> certificates are populated in the reverse component of the
> crossCertificatePair attribute. Specifying that this feature is
> optional makes it difficult to build paths in a reverse direction in a
> trust model where lots of cross certificates and multiple directories
> are involved and you don't know if the CAs support the optional
> storage.
> 
> I would like to suggest that RFC 2587 be amended/updated
> to make storage of cross certificates in the reverse component of the
> crossCertificatePair attribute mandatory.
> 
> Thanks,
> Sean
>

***************************************************

David Chadwick
IS Institute, University of Salford, Salford M5 4WT
Tel [phone]  Fax [phone]
Mobile [phone]
Email [e-mail]
Home Page  http://www.salford.ac.uk/its024/chadwick.htm
Understanding X.500  http://www.salford.ac.uk/its024/X500.htm
X.500/LDAP Seminars http://www.salford.ac.uk/its024/seminars.htm
Entrust key validation string MLJ9-DU5T-HV8J

***************************************************


Received: from mta01-svc.ntlworld.com (mta01-svc.ntlworld.com [62.253.162.41]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id HAA24800 for <[e-mail]>; Thu, 13 Jul 2000 07:02:02 -0700 (PDT)
Received: from dwc-acer ([62.252.104.255]) by mta01-svc.ntlworld.com (InterMail vM.4.01.02.27 201-229-119-110) with ESMTP id <20000713140401.PWPE26680.mta01-svc.ntlworld.com@dwc-acer>; Thu, 13 Jul 2000 15:04:01 +0100
From: "David Chadwick" <[e-mail]>
Organization: University of Salford
To: Sean Mullan <[e-mail]>, [e-mail], [e-mail]
Date: Thu, 13 Jul 2000 15:02:42 +0100
MIME-Version: 1.0
Content-type: text/plain; charset=US-ASCII
Content-transfer-encoding: 7BIT
Subject: Re: I-D ACTION:draft-ietf-pkix-ldap-schema-00.txt
Reply-to: [e-mail]
CC: [e-mail]
Message-ID: <396DDA12.874.862330B@localhost>
Priority: normal
In-reply-to: <[e-mail]>
X-mailer: Pegasus Mail for Win32 (v3.12c)

Date sent:      	Wed, 12 Jul 2000 19:31:31 +0100
From:           	Sean Mullan <[e-mail]>
To:             	[e-mail]
Copies to:      	[e-mail], [e-mail]
Subject:        	Re: I-D ACTION:draft-ietf-pkix-ldap-schema-00.txt

> Hi David,
> 
> Some comments on the draft below.

Sean, replies intersperced below


> Section 3.2 Certificate Match
> 
> I think the X.509 certificate matching rules are missing some
> essential and important fields in the certificateAssertion structure
> for filtering on certificates. We may want to consider defining a
> superset. I submitted these comments to the X.509 editors but
> apparently it was too late to integrate them into the 2000 update.
> 
>   * you should be able to match on more than one pathToName and on
>   non-X500
>     name types. This is inconsistent with name constraints which allow
>     you to constrain to more than one name and different name types. 
> 

I agree that alternative name types should be allowed. But maybe it 
is not necessary to have multiple names, since you can do several 
Searches providing one name for each search (remember that the 
name presented should be allowed to have a cert path created to it)

How do we want to handle this:
i) issue a defect on X.509 (Sharon can you comment on this)
ii) let the LDAP matching rule be a superset of the X.509 one?

I would favour the former route myself.


>   * you should be able to match on more than the subject alt name
>   type.

Agreed. This is a lack of clarity in the ID. It is intended that the 
whole name can be presented along with the type. The text is 
ambiguous in this respect and I will fix it. It will also be clearer when 
version 1 is published that contains BNF for each of the fields. 
Steven Legg has been doing this for me.

> You
>     should also be able to match on the subject alt name itself, and
>     specify more than one subject alt name as certificates can contain
>     more than one.
> 

Concerning multiple names, I think this can be solved by performing 
multiple searches with a single name in each search.

>   * you should be able to match on the subject public key as well as
>   the subject public
>     key algorithm OID.
> 

you can match on the subject key identifier (3rd component)

>   * you should be able to match on the basic constraints extension,
>   especially the
>     maxPathLen value. This is useful for finding potential
>     certificates when building certification paths from the target to
>     the most-trusted CA. For ex, if a partial path has been built, any
>     candidate certificate must have a maxPathLen value greater than or
>     equal to the number of certificates in the partial path.
> 

Interestingly  this has been defined for attribute certificates and not 
pk certs. I actually think that the way matching for ACs has been 
handled is far superior than for PKcerts. ie. a separate matching 
rule for each extension, rather than one long complex rule for pk 
certs. However, there would be nothing to stop an implementation 
dynamically attaching the basicAttConstraintsMatch to public key certs. In 
fact this matching rule could be renamed the basicConstraintsMatch 
anyway as the syntax is the same for both ACs and PKCs. This is 
my preferred approach.

> I think it is very important to include the Certificate pair matching
> rules, as these are very useful when building certification paths and
> trying to discover which of many cross certificates satisfy various
> validation constraints, and eliminating those that do not.
> 

OK, this can be done. It is just time consuming and I wanted to 
know if there was a demand first.

> Other comments:
> 
>   * What RFC format are you using for the encoding of DNs - 1779? This
>   should be referenced.

It should be 2253 for LDAPv3.

> 
> Section 4.2 Certificate List Match
> 
> There is an error in the CertificateListAssertion definition in X.509
> 2000. The authorityKeyIdentifier component should be marked OPTIONAL.
> This probably doesn't affect your definition, but I just wanted to
> make you aware of it.

Agreed, Sharon, can you make a  note of this defect

David
p.s. what do you think about Bruce's assertion that none of this is 
needed and instead we should have a bunch of simple attributes in 
the LDAP entry

David

> 


***************************************************

David Chadwick
IS Institute, University of Salford, Salford M5 4WT
Tel [phone]  Fax [phone]
Mobile [phone]
Email [e-mail]
Home Page  http://www.salford.ac.uk/its024/chadwick.htm
Understanding X.500  http://www.salford.ac.uk/its024/X500.htm
X.500/LDAP Seminars http://www.salford.ac.uk/its024/seminars.htm
Entrust key validation string MLJ9-DU5T-HV8J

***************************************************


Received: from mail.inka.de ([e-mail] [212.227.14.2]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id AAA04628 for <[e-mail]>; Thu, 13 Jul 2000 00:07:23 -0700 (PDT)
Received: from localhost (ccciii.yapay.inka.de [212.227.15.177]) by mail.inka.de with esmtp  id 13Cd7V-0000xB-00; Thu, 13 Jul 2000 09:09:18 +0200
Received: from stroeder.com (localhost [127.0.0.1]) by localhost (Postfix) with ESMTP id 2821B2FC7A; Thu, 13 Jul 2000 09:09:17 +0200 (CEST)
Sender: [e-mail]
Message-ID: <[e-mail]>
Date: Thu, 13 Jul 2000 09:09:16 +0200
From: Michael =?iso-8859-1?Q?Str=F6der?= <[e-mail]>
Organization: stroeder.com
X-Mailer: Mozilla 4.73 [en] (X11; U; Linux 2.2.16 i686)
X-Accept-Language: de-DE, de, en
MIME-Version: 1.0
To: Simon McMahon <[e-mail]>
Cc: [e-mail]
Subject: Re: Current signature formats insufficient
References: <[e-mail]> <019e01bfec93$66dfe4c0$[e-mail]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Simon McMahon wrote:
> 
> German law obviously already recognises certified signing devices as
> relevant to legally binding signatures.

Maybe there's a misunderstanding here (or maybe it's because I came
into this discussion lately):

The german "Signaturgesetz" only describes how strong a
certification service has to be to be accepted for legally binding
signatures eventually being implemented in a law in the future. But
at the moment no electronic signature is accepted as a legally
binding signature at all.

Ciao, Michael.


Received: from diablo.OntheNet.com.au (diablo.OntheNet.com.au [203.10.89.2]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id XAA02603 for <[e-mail]>; Wed, 12 Jul 2000 23:18:38 -0700 (PDT)
Received: from msimon (pc3.eracom.com.au [203.144.16.147]) by diablo.OntheNet.com.au (8.9.3/8.9.3) with SMTP id QAA75679; Thu, 13 Jul 2000 16:18:30 +1000 (EST)
Message-ID: <019e01bfec93$66dfe4c0$[e-mail]>
From: "Simon McMahon" <[e-mail]>
To: "Adrian McCullagh" <[e-mail]>, "'Tony Bartoletti'" <[e-mail]>, "'Ben Laurie'" <[e-mail]>, "Frank Balluffi" <[e-mail]>
Cc: <[e-mail]>, <[e-mail]>
References: <[e-mail]>
Subject: Re: Current signature formats insufficient
Date: Thu, 13 Jul 2000 16:26:48 +1000
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.00.2314.1300
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300

Adrian,

> If you would like I have 2 academic papers that deal with the issues
raised
> here from a legal perspective.  Both papers have been published by
> universities but I am not sure whether they are on the internet.
>
I'm sure they will be tough reading but, yes, please post the URLs if they
exist or post binaries direct to me (I think mailing list policy is not to
post binary attachments).

I understand that a human withness to a digital signature is at a
disadvantage for the reason you stated, but couldn't the law recognise a
certified "device" operating under its normal operating conditions as a
witness to the affixation of a digital signature to some content ? It is
after all the device doing it. A human witness could still be involved but
would be witnessing something else, e.g. that the signer understood the
content.

German law obviously already recognises certified signing devices as
relevant to legally binding signatures.

It looks to me like the concept of a witness is overloaded because humans
are naturally pretty versatile. Breaking down what a witness does, or is,
might make it easier to digitize their functions. Maybe that is what your
paper's "verifier" is.

What happened to "Current signature formats insufficient" ? Better post me
those papers quick !

Thanks,

Simon McMahon




Received: from aspams52.cai.com (aspams52.cai.com [155.35.248.76]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id WAA00155 for <[e-mail]>; Wed, 12 Jul 2000 22:30:06 -0700 (PDT)
Received: by aspams52.cai.com with Internet Mail Service (5.5.2650.21) id <3X7A0F3R>; Thu, 13 Jul 2000 14:36:28 +1000
Message-ID: <[e-mail]>
From: "Ramsay, Ron" <[e-mail]>
To: Adrian McCullagh <[e-mail]>, "'Simon McMahon'" <[e-mail]>, Michael Zolotarev <[e-mail]>, Tony Bartoletti <[e-mail]>, "P.J. Ponder" <[e-mail]>
Cc: Paul Koning <[e-mail]>, [e-mail], [e-mail]
Subject: RE: Current signature formats insufficient
Date: Thu, 13 Jul 2000 14:36:29 +1000
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain; charset="iso-8859-1"

Adrian,

You appear to be agreeing with Michael, and I do, too.

The signature means "I signed this document (blob)". If I have to agree with
the contents of the document, the document (blob) should contain a place for
this.

Ron.
-----Original Message-----
From: Adrian McCullagh [mailto:[e-mail]]
Sent: Thursday, 13 July 2000 14:29
To: 'Simon McMahon'; Michael Zolotarev; Tony Bartoletti; P.J. Ponder
Cc: Paul Koning; [e-mail]; [e-mail]
Subject: RE: Current signature formats insufficient


-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Michael & Simon;

I do not agree with your position.

You either agree or you do not agree.  The positions are mutually
exclusive.  The issue of qualification if put forward only complicates
the situation.  If you want to qualify then you must in my opinion
fall within the "do not agree" position.  

Why complicate the situation with:

> 1. Strongly agree
> 2. Agree
> 3. Agree with reservations
> 4. Agree with a certain doubt

What is the difference between agree and strongly agree.  It does not
add anything by qualifying the agreed position.  A certainly doubt
that a Court would take notice of varying positions of agreement.  You
either agree or do not agree.



- -----Original Message-----
From: Simon McMahon [mailto:[e-mail]]
Sent: Thursday, July 13, 2000 2:09 PM
To: Michael Zolotarev; Tony Bartoletti; P.J. Ponder
Cc: Paul Koning; [e-mail]; [e-mail]
Subject: Re: Current signature formats insufficient


Michael wrote :
> Using a special key usage bit to specify your agreement is not very
> practical. Why? You'd have to define the following set:
>
> 1. Strongly agree
> 2. Agree
> 3. Agree with reservations
> 4. Agree with a certain doubt
>

Thats right - the content contains all the details about what and how
much
committment is being made. The signature format is irrelevant accept
that it
has to be validatable.

Simon.


-----BEGIN PGP SIGNATURE-----
Version: PGP Personal Edition 6.0.2

iQA/AwUBOWy4RZWt1NGjt4vzEQL3iQCg6potAez5JhLSDtdGF26UaeG2ziUAoOmy
sdwXFWc2hVsvm4P00KfXJz21
=H1pM
-----END PGP SIGNATURE-----


Received: from stargate.zergo.com.au (IDENT:[e-mail] [203.2.208.130]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id WAA28147 for <[e-mail]>; Wed, 12 Jul 2000 22:13:42 -0700 (PDT)
Received: from sydneymail1.baltimore.com.au (sydneymail1.jp.zergo.com.au [192.168.71.5]) by stargate.zergo.com.au (8.9.1/8.8.7) with ESMTP id OAA00607; Thu, 13 Jul 2000 14:53:07 +1000
Received: by sydneymail1.jp.zergo.com.au with Internet Mail Service (5.5.2650.21) id <35GGB22B>; Thu, 13 Jul 2000 14:46:10 +1000
Message-ID: <[e-mail]>
From: Michael Zolotarev <[e-mail]>
To: Adrian McCullagh <[e-mail]>, "'Simon McMahon'" <[e-mail]>, Michael Zolotarev <[e-mail]>, Tony Bartoletti <[e-mail]>, "P.J. Ponder" <[e-mail]>
Cc: Paul Koning <[e-mail]>, [e-mail], [e-mail]
Subject: RE: Current signature formats insufficient
Date: Thu, 13 Jul 2000 14:45:09 +1000
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain; charset="iso-8859-1"

Adrian,

God, do you guys ever come to understand Russian sense of humor?

I was just trying to show that introducing a special key usage bit is not
going to solve the problem. Which is, of course, to indicate whether a
signer agrees or not with the content of the message.

I was saying that you can do it only by having a statement (AGREE or DO NOT
AGREE) INSIDE the content, and signing that content with your key. Exactly
as you do it on the paper: "Solemnly agree:_______".

Following the 'key usage bit' approach you'd have to have two different keys
- one for 'agree with the content', and another for 'do not agree with
content'.

My 'agree with doubts' list was an [unsuccessful] attempt to demonstrate
what kind of absurd you can get into with using the key usage flags.

Best regards
Michael

PS Are you in Sydney, BTW?



> -----Original Message-----
> From: Adrian McCullagh [mailto:[e-mail]]
> Sent: Thursday, July 13, 2000 2:29 PM
> To: 'Simon McMahon'; Michael Zolotarev; Tony Bartoletti; P.J. Ponder
> Cc: Paul Koning; [e-mail]; [e-mail]
> Subject: RE: Current signature formats insufficient
> 
> 
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> Michael & Simon;
> 
> I do not agree with your position.
> 
> You either agree or you do not agree.  The positions are mutually
> exclusive.  The issue of qualification if put forward only complicates
> the situation.  If you want to qualify then you must in my opinion
> fall within the "do not agree" position.  
> 
> Why complicate the situation with:
> 
> > 1. Strongly agree
> > 2. Agree
> > 3. Agree with reservations
> > 4. Agree with a certain doubt
> 
> What is the difference between agree and strongly agree.  It does not
> add anything by qualifying the agreed position.  A certainly doubt
> that a Court would take notice of varying positions of agreement.  You
> either agree or do not agree.
> 
> 
> 
> - -----Original Message-----
> From: Simon McMahon [mailto:[e-mail]]
> Sent: Thursday, July 13, 2000 2:09 PM
> To: Michael Zolotarev; Tony Bartoletti; P.J. Ponder
> Cc: Paul Koning; [e-mail]; [e-mail]
> Subject: Re: Current signature formats insufficient
> 
> 
> Michael wrote :
> > Using a special key usage bit to specify your agreement is not very
> > practical. Why? You'd have to define the following set:
> >
> > 1. Strongly agree
> > 2. Agree
> > 3. Agree with reservations
> > 4. Agree with a certain doubt
> >
> 
> Thats right - the content contains all the details about what and how
> much
> committment is being made. The signature format is irrelevant accept
> that it
> has to be validatable.
> 
> Simon.
> 
> 
> -----BEGIN PGP SIGNATURE-----
> Version: PGP Personal Edition 6.0.2
> 
> iQA/AwUBOWy4RZWt1NGjt4vzEQL3iQCg6potAez5JhLSDtdGF26UaeG2ziUAoOmy
> sdwXFWc2hVsvm4P00KfXJz21
> =H1pM
> -----END PGP SIGNATURE-----
> 


Received: from hamster.gadens.com.au ([e-mail] [203.32.220.10]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id VAA27395 for <[e-mail]>; Wed, 12 Jul 2000 21:59:23 -0700 (PDT)
Received: from exchange.gadens.com.au ([10.1.8.3]) by hamster.gadens.com.au (8.9.3/8.9.3) with ESMTP id PAA82770; Thu, 13 Jul 2000 15:00:07 +1000 (EST) (envelope-from [e-mail])
Received: by exchange.gadens.com.au with Internet Mail Service (5.5.2650.21) id <3YWS61XM>; Thu, 13 Jul 2000 15:03:31 +1000
Message-ID: <[e-mail]>
From: Adrian McCullagh <[e-mail]>
To: "'Simon McMahon'" <[e-mail]>, "'Tony Bartoletti'" <[e-mail]>, "'Ben Laurie'" <[e-mail]>, Frank Balluffi <[e-mail]>
Cc: [e-mail], [e-mail]
Subject: RE: Current signature formats insufficient
Date: Thu, 13 Jul 2000 15:03:29 +1000
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain; charset="iso-8859-1"

Simon,

I agree that there is a cost involved but the cost of not taking this
approach will in my opinion be greater to society in the long run.  There
will be an increase in identity fraud cases, an increase in the cost of
collecting admissible evidence, and the increase of other crimes such as
unauthorised access that could otherwise be reduced (as opposed to
eliminated). 

If you would like I have 2 academic papers that deal with the issues raised
here from a legal perspective.  Both papers have been published by
universities but I am not sure whether they are on the internet.

The first paper is entitled "Electronic signatures : Understand the past to
develop the future"
The second paper is entitled "Non-repudiation in the Electronic Commerce
Environment"

The first paper provides an argument that the concept of witnessing is
inappropriate for the electronic commerce environment.  A new position
legally should be the concept of verifying.  At law a witness must have an
uninterrupted view of the signer actually affixing the mark that will bind
the signer to the contents of the document.  Now a witness can not actually
see such an affixation in the digital environment.  All a witness can do is
see the person pressing some keys.  The program could be doing anything.  So
in my scenario the verifier will first verify that there does exist,
attached to the document, a digital signature that has been affixed using
the alleged signers private key.  Once verified the verifier will affix
their digital signature that will clearly note the second signer as a
verifier and not as the person who is to be bound by the contents of the
document.  My paper expands this concept somewhat.


I am completing a paper the analyses trusted systems and digital signature
regimes and establishes that most jurisdictions have ignored the trusted
mechanism that was established for some 600 years in the paper based
environment and have misdirected there attention upon the verification
process.

Adrian McCullagh
Director of Electronic Commerce
Gadens Lawyers

Tel: [phone]
Fax: [phone]

level 39
Central Plaza 1
345 Queen Street
Brisbane Australia 4000



-----Original Message-----
From: Simon McMahon [mailto:[e-mail]]
Sent: Thursday, July 13, 2000 2:41 PM
To: Adrian McCullagh; 'Tony Bartoletti'; 'Ben Laurie'; Frank Balluffi
Cc: [e-mail]; [e-mail]
Subject: Re: Current signature formats insufficient


Adrian wrote :
[snip]
> The issue that I am raising in legal terms is called "Non Est Factum" -
"not
> my act".
[snip]

A great argument for certified signing devices but they cost a lot to
create, or at least now they do because volumes aren't high enough. There
will still be demand for low cost signing devices (hackable PCs with
uncertified software and SCs).

I dont see what this has to do with signature formats however, although I
agree its an interesting and important issue.

Surely in the case you cited the Alememdios' signatures would have been
witnessed by representatives of the bank and they should have made sure the
Alemedios understood what they signed by supplying their own translator. I
guess thats why the Alemedios won.

My point is that witnessing is the right way to boost non-repudiation (that
failed in this case) to a level where big dollars are involved. Non
witnessed signatures, standard or digital, must therefore be more vulnerable
to repudiation claims. A digital witness would need to assure that the
witnessed signature was made with a trustworthy signing device and that the
signer understood what was being signed.

I can concieve of a trustworthy signing device, not at home but at a bank
branch or kiosk, that accepts a smart card with my private key on it.
Authenticates me and makes me say 'Y' to "do you understand and wish to sign
what you have read above ?" (wherever "above" happens to be) and then
applies my signature. It then counter signs my signature with its private
key which the RP can recognise as that of a trusted device. The RP may not
know for sure that I actually understood what I was supposed to have read,
only a human witness, in my opinion could do that, but the RP has high
assurance that the signature is not the result of a hacked PC with an SC
reader.

Simon McMahon




Received: from diablo.OntheNet.com.au (diablo.OntheNet.com.au [203.10.89.2]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id VAA26984 for <[e-mail]>; Wed, 12 Jul 2000 21:38:57 -0700 (PDT)
Received: from msimon (pc3.eracom.com.au [203.144.16.147]) by diablo.OntheNet.com.au (8.9.3/8.9.3) with SMTP id OAA57051; Thu, 13 Jul 2000 14:38:31 +1000 (EST)
Message-ID: <014401bfec85$6e637300$[e-mail]>
From: "Simon McMahon" <[e-mail]>
To: "Adrian McCullagh" <[e-mail]>, "Michael Zolotarev" <[e-mail]>, "Tony Bartoletti" <[e-mail]>, "P.J. Ponder" <[e-mail]>
Cc: "Paul Koning" <[e-mail]>, <[e-mail]>, <[e-mail]>
References: <[e-mail]>
Subject: Re: Current signature formats insufficient
Date: Thu, 13 Jul 2000 14:46:49 +1000
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.00.2314.1300
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300

 > You either agree or you do not agree.  The positions are mutually
> exclusive.  The issue of qualification if put forward only complicates
> the situation.  If you want to qualify then you must in my opinion
> fall within the "do not agree" position.
>
I think that is the idea - to weaken the level of comittment regarding the
signed content to the point where I am not legally liable for it. So you are
right that there should only be "agree" and "not-agree" - 1 bit. But that
point should be made in the content or by using a non-NR key not in the
signature encoding.

Simon.




Received: from diablo.OntheNet.com.au (diablo.OntheNet.com.au [203.10.89.2]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id VAA26686 for <[e-mail]>; Wed, 12 Jul 2000 21:33:44 -0700 (PDT)
Received: from msimon (pc3.eracom.com.au [203.144.16.147]) by diablo.OntheNet.com.au (8.9.3/8.9.3) with SMTP id OAA56060; Thu, 13 Jul 2000 14:32:59 +1000 (EST)
Message-ID: <013a01bfec84$ae7ed890$[e-mail]>
From: "Simon McMahon" <[e-mail]>
To: "Adrian McCullagh" <[e-mail]>, "'Tony Bartoletti'" <[e-mail]>, "'Ben Laurie'" <[e-mail]>, "Frank Balluffi" <[e-mail]>
Cc: <[e-mail]>, <[e-mail]>
References: <[e-mail]>
Subject: Re: Current signature formats insufficient
Date: Thu, 13 Jul 2000 14:41:15 +1000
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.00.2314.1300
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300

Adrian wrote :
[snip]
> The issue that I am raising in legal terms is called "Non Est Factum" -
"not
> my act".
[snip]

A great argument for certified signing devices but they cost a lot to
create, or at least now they do because volumes aren't high enough. There
will still be demand for low cost signing devices (hackable PCs with
uncertified software and SCs).

I dont see what this has to do with signature formats however, although I
agree its an interesting and important issue.

Surely in the case you cited the Alememdios' signatures would have been
witnessed by representatives of the bank and they should have made sure the
Alemedios understood what they signed by supplying their own translator. I
guess thats why the Alemedios won.

My point is that witnessing is the right way to boost non-repudiation (that
failed in this case) to a level where big dollars are involved. Non
witnessed signatures, standard or digital, must therefore be more vulnerable
to repudiation claims. A digital witness would need to assure that the
witnessed signature was made with a trustworthy signing device and that the
signer understood what was being signed.

I can concieve of a trustworthy signing device, not at home but at a bank
branch or kiosk, that accepts a smart card with my private key on it.
Authenticates me and makes me say 'Y' to "do you understand and wish to sign
what you have read above ?" (wherever "above" happens to be) and then
applies my signature. It then counter signs my signature with its private
key which the RP can recognise as that of a trusted device. The RP may not
know for sure that I actually understood what I was supposed to have read,
only a human witness, in my opinion could do that, but the RP has high
assurance that the signature is not the result of a hacked PC with an SC
reader.

Simon McMahon





Received: from hamster.gadens.com.au ([e-mail] [203.32.220.10]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id VAA26140 for <[e-mail]>; Wed, 12 Jul 2000 21:26:35 -0700 (PDT)
Received: from exchange.gadens.com.au ([10.1.8.3]) by hamster.gadens.com.au (8.9.3/8.9.3) with ESMTP id OAA81186; Thu, 13 Jul 2000 14:25:50 +1000 (EST) (envelope-from [e-mail])
Received: by exchange.gadens.com.au with Internet Mail Service (5.5.2650.21) id <3YWS61S7>; Thu, 13 Jul 2000 14:29:13 +1000
Message-ID: <[e-mail]>
From: Adrian McCullagh <[e-mail]>
To: "'Simon McMahon'" <[e-mail]>, Michael Zolotarev <[e-mail]>, Tony Bartoletti <[e-mail]>, "P.J. Ponder" <[e-mail]>
Cc: Paul Koning <[e-mail]>, [e-mail], [e-mail]
Subject: RE: Current signature formats insufficient
Date: Thu, 13 Jul 2000 14:29:12 +1000
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain; charset="iso-8859-1"

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Michael & Simon;

I do not agree with your position.

You either agree or you do not agree.  The positions are mutually
exclusive.  The issue of qualification if put forward only complicates
the situation.  If you want to qualify then you must in my opinion
fall within the "do not agree" position.  

Why complicate the situation with:

> 1. Strongly agree
> 2. Agree
> 3. Agree with reservations
> 4. Agree with a certain doubt

What is the difference between agree and strongly agree.  It does not
add anything by qualifying the agreed position.  A certainly doubt
that a Court would take notice of varying positions of agreement.  You
either agree or do not agree.



- -----Original Message-----
From: Simon McMahon [mailto:[e-mail]]
Sent: Thursday, July 13, 2000 2:09 PM
To: Michael Zolotarev; Tony Bartoletti; P.J. Ponder
Cc: Paul Koning; [e-mail]; [e-mail]
Subject: Re: Current signature formats insufficient


Michael wrote :
> Using a special key usage bit to specify your agreement is not very
> practical. Why? You'd have to define the following set:
>
> 1. Strongly agree
> 2. Agree
> 3. Agree with reservations
> 4. Agree with a certain doubt
>

Thats right - the content contains all the details about what and how
much
committment is being made. The signature format is irrelevant accept
that it
has to be validatable.

Simon.


-----BEGIN PGP SIGNATURE-----
Version: PGP Personal Edition 6.0.2

iQA/AwUBOWy4RZWt1NGjt4vzEQL3iQCg6potAez5JhLSDtdGF26UaeG2ziUAoOmy
sdwXFWc2hVsvm4P00KfXJz21
=H1pM
-----END PGP SIGNATURE-----


Received: from diablo.OntheNet.com.au (diablo.OntheNet.com.au [203.10.89.2]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id VAA24956 for <[e-mail]>; Wed, 12 Jul 2000 21:00:02 -0700 (PDT)
Received: from msimon (pc3.eracom.com.au [203.144.16.147]) by diablo.OntheNet.com.au (8.9.3/8.9.3) with SMTP id OAA50347; Thu, 13 Jul 2000 14:00:53 +1000 (EST)
Message-ID: <012001bfec80$2bf94a30$[e-mail]>
From: "Simon McMahon" <[e-mail]>
To: "Michael Zolotarev" <[e-mail]>, "Tony Bartoletti" <[e-mail]>, "P.J. Ponder" <[e-mail]>
Cc: "Paul Koning" <[e-mail]>, <[e-mail]>, <[e-mail]>
References: <[e-mail]>
Subject: Re: Current signature formats insufficient
Date: Thu, 13 Jul 2000 14:09:11 +1000
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.00.2314.1300
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300

Michael wrote :
> Using a special key usage bit to specify your agreement is not very
> practical. Why? You'd have to define the following set:
>
> 1. Strongly agree
> 2. Agree
> 3. Agree with reservations
> 4. Agree with a certain doubt
>

Thats right - the content contains all the details about what and how much
committment is being made. The signature format is irrelevant accept that it
has to be validatable.

Simon.




Received: from stargate.zergo.com.au (IDENT:[e-mail] [203.2.208.130]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id UAA24285 for <[e-mail]>; Wed, 12 Jul 2000 20:53:25 -0700 (PDT)
Received: from sydneymail1.baltimore.com.au (sydneymail1.jp.zergo.com.au [192.168.71.5]) by stargate.zergo.com.au (8.9.1/8.8.7) with ESMTP id OAA00313; Thu, 13 Jul 2000 14:01:13 +1000
Received: by sydneymail1.jp.zergo.com.au with Internet Mail Service (5.5.2650.21) id <3Z6RSJ4Q>; Thu, 13 Jul 2000 13:53:26 +1000
Message-ID: <[e-mail]>
From: Michael Zolotarev <[e-mail]>
To: Simon McMahon <[e-mail]>
Cc: [e-mail]
Subject: RE: Current signature formats insufficient
Date: Thu, 13 Jul 2000 13:53:25 +1000
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain; charset="iso-8859-1"

> > So, what are we left with? Do I hear "Can we make a signature to
> communicate
> > extra attributes"?
> >
> > Yes, we can.
> 
> But should we ? I think signatures are fine the way they are.
> 
That's what I meant by saying 'we can'. I should've made myself clearer.


Received: from stargate.zergo.com.au (IDENT:[e-mail] [203.2.208.130]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id UAA22467 for <[e-mail]>; Wed, 12 Jul 2000 20:33:39 -0700 (PDT)
Received: from sydneymail1.baltimore.com.au (sydneymail1.jp.zergo.com.au [192.168.71.5]) by stargate.zergo.com.au (8.9.1/8.8.7) with ESMTP id NAA06045; Thu, 13 Jul 2000 13:40:37 +1000
Received: by sydneymail1.jp.zergo.com.au with Internet Mail Service (5.5.2650.21) id <3Z6RSJ4C>; Thu, 13 Jul 2000 13:33:45 +1000
Message-ID: <[e-mail]>
From: Michael Zolotarev <[e-mail]>
To: Tony Bartoletti <[e-mail]>, "P.J. Ponder" <[e-mail]>, Michael Zolotarev <[e-mail]>
Cc: Paul Koning <[e-mail]>, [e-mail], [e-mail], [e-mail]
Subject: RE: Current signature formats insufficient
Date: Thu, 13 Jul 2000 13:33:45 +1000
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain; charset="iso-8859-1"

Tony,

A signature on the message serves two purposes:

A. to ensure the origin and integrity of the message - that the message came
from me, and it was not modified en-route.
B. to indicate that a signer was AWARE (!) of the content of the message.

The critical point is that my AWARENESS(!) of the content does NOT imply
that I agree or disagree with the message. This is a common mistake people
do.

If I wanted to stress out that I agree with what the message says, I'd need
to do the following:

Put a claim into the message, like "I, Michael Zolotarev, strongly agree
with that statement". That'd be enough, provided that the origin and
integrity of the message is ensured by MY signature.

Using a special key usage bit to specify your agreement is not very
practical. Why? You'd have to define the following set:

1. Strongly agree
2. Agree
3. Agree with reservations
4. Agree with a certain doubt

And so on. It is less a joke that you might think, really.

regards
M





Received: from diablo.OntheNet.com.au (diablo.OntheNet.com.au [203.10.89.2]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id TAA16547 for <[e-mail]>; Wed, 12 Jul 2000 19:16:06 -0700 (PDT)
Received: from msimon (pc3.eracom.com.au [203.144.16.147]) by diablo.OntheNet.com.au (8.9.3/8.9.3) with SMTP id MAA31221; Thu, 13 Jul 2000 12:17:48 +1000 (EST)
Message-ID: <00df01bfec71$c566a000$[e-mail]>
From: "Simon McMahon" <[e-mail]>
To: "Michael Zolotarev" <[e-mail]>
Cc: <[e-mail]>
References: <[e-mail]>
Subject: Re: Current signature formats insufficient
Date: Thu, 13 Jul 2000 12:23:58 +1000
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.00.2314.1300
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300

Tom wrote :
>      Actually, the assurance indicator is put on by the smart card under
> conditions which the home PC cannot hack.  The more severe limitation
would
> naturally be on NR signatures without the indicator.
>
But the RP could only rely on the assurance indicator if the CA says so
which implies (to me) that the CA checked that signing equipment is
reliable. Only a CA can tell a RP what to trust and it does this with a
certificate.

P.S. Sorry but my last post didn't go to the list but Tom quoted it in his
reply.

Michael wrote :
> << Simon, in case you need somebody to say something nice to you :) - I'm
> fully agree with you. If you read my previous mail, you'll see that our
> opinions are identical.>>

Gee thanks ;)

> [snip]
> So, what are we left with? Do I hear "Can we make a signature to
communicate
> extra attributes"?
>
> Yes, we can.

But should we ? I think signatures are fine the way they are.

You know, this sounds alot like the TSA signing key debate where the TSA
private key was being overloaded to sign time stamps and self-signed certs.
Its all about to overload keys or not to overload them. I guess this might
make a nice precedent.

IMO to allow a key intended for NR signatures to make non-NR signatures
creates an ambiguity that undermines the NR-ness of the NR signatures. Thats
bad ! Use a differnent key for your non-NR signatures. Non repudiation is
critical to PKI and too easy to break, or at least undermine to the point
where its too hard to enforce legally.

Simon.




Received: from diablo.OntheNet.com.au (diablo.OntheNet.com.au [203.10.89.2]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id TAA16529 for <[e-mail]>; Wed, 12 Jul 2000 19:16:02 -0700 (PDT)
Received: from msimon (pc3.eracom.com.au [203.144.16.147]) by diablo.OntheNet.com.au (8.9.3/8.9.3) with SMTP id MAA31215; Thu, 13 Jul 2000 12:17:48 +1000 (EST)
Message-ID: <00de01bfec71$c4eae050$[e-mail]>
From: "Simon McMahon" <[e-mail]>
To: "Paul Koning" <[e-mail]>
Cc: <[e-mail]>
References: <000901bfeb64$38642f50$0201010a@intergalactic><013901bfeba8$419218f0$[e-mail]> <[e-mail]>
Subject: Re: Current signature formats insufficient
Date: Thu, 13 Jul 2000 12:23:05 +1000
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.00.2314.1300
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300

Paul wrote :
>
> With classic signatures, the norm is that you see what you sign.  (One
> exception is the standard story about the overworked executive who's
> handed a stack of 50 memos to sign, with little yellow tabs marking
> "here's the spot" and someone slips in a ringer.  Don't know how
> common that is outside novels.)
>
Thats right but people make classic signatures with less care when they take
into account their environment. If you are in a reputable establishment, or
your workplace, where accountablility for fraud is higher you are more
likely to forego the formality of reading every word of what you are
signing. The risk is their but people (reasonably) tend to limit their
effort with respect to their perception of that risk.

> With digital signatures, the norm is that you have no idea.  As Denis
> mentioned, current smartcards have no way of showing you what you're
> signing.  If you use an application that signs things (like a mailer)
> the binding is a little better.  There you still have to trust that
> the text you entered is in fact what's being signed -- in other words,
> that the program is trustworthy, correct, and unsubverted by trojan
> horses.  One good reason for using PGP, because you can check this,
> unlike closed source mailers.
>
The smart card is not "the signing device" the PC with all its software is.
It is, fortunately, able to show you everything before it uses your card to
sign what you saw. It is also, unfortunately, hackable if exposed to a
hostile environment. Most PCs hanging off the Internet or using uncertified
software fall into this category.

The fix is to make more secure (more expensive) signing devices or reduce
the liability resulting from a hack on a less secure (cheaper) one.

I dont see how any of this is an argument to change signature formats. Its
an argument to use NR keys in more secure devices and non-NR keys in PCs. I
still think there is a case for limited liability NR keys in hackable
(cheap) PCs because thats what people will want to do. Buy and sell stuff
(not their house) over the Internet from their home PC.

Simon.




Received: from hamster.gadens.com.au ([e-mail] [203.32.220.10]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id TAA15653 for <[e-mail]>; Wed, 12 Jul 2000 19:01:53 -0700 (PDT)
Received: from exchange.gadens.com.au ([10.1.8.3]) by hamster.gadens.com.au (8.9.3/8.9.3) with ESMTP id MAA74707; Thu, 13 Jul 2000 12:02:37 +1000 (EST) (envelope-from [e-mail])
Received: by exchange.gadens.com.au with Internet Mail Service (5.5.2650.21) id <3YWS6112>; Thu, 13 Jul 2000 12:06:00 +1000
Message-ID: <[e-mail]>
From: Adrian McCullagh <[e-mail]>
To: "'Tony Bartoletti'" <[e-mail]>, "'Ben Laurie'" <[e-mail]>, Frank Balluffi <[e-mail]>
Cc: "'[e-mail]'" <[e-mail]>, [e-mail]
Subject: RE: Current signature formats insufficient
Date: Thu, 13 Jul 2000 12:05:59 +1000
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain; charset="iso-8859-1"

Tony

I apologise to everyone for the length of this response.

The objective test that I mentioned is in fact the position of a reasonable
person.  That is what is reasonable in the circumstances.  Only the facts in
the case will determine this.

The real problem as I see it is that a person who has been attributed as
having digitally signing a digital document could claim that the digital
signature is theirs and was affixed by them but it was not their act.  This
is different to a forgery case as in such cases the digital signature may
have been generated by a key that corresponds to their private key but was
generated through the act of a third party.  That is, the third party has
acquired through some means a copy of the private key of the alleged signer.
Hence a forged digital signature. 

The issue that I am raising in legal terms is called "Non Est Factum" - "not
my act".  

The legal case books have numerous examples of cases involving the issue of
Non est Factum.

The best way to describe it is by drawing upon a real case that occurred in
Australia.  I understand that the law in this case corresponds to US,
Canadian and UK legal principles.

The Facts:
==========

Mr & Mrs Almedio were 2 elderly Italians that lived in Sydney.  Their son
was a business man whose business was having difficulties and as such his
Bank was pressing for more collateral security.  The son who grew up in
Australia was fluent in Italian and in English.  His parent could only speak
a little English and could not read English at all. (You wonder how they
survived for over 20 years in a predominately English speaking country).

Now the son was asked by the Bank to get his parents to guaranty an
extension to his current loan facility.  The son went to his parents and
presented to them the guaranty document.  The guaranty was to cover the full
amount of the loan and not just the extension.  His parents could not read
the document and were advised by the son that the document was to secure the
extension of $50,000.  The full extent of the loan facility was in excess of
$500,000.

In effect the parents were signing a document without understanding what
they were signing and had no way of understanding as they could not read the
document. They were relying on and trusting their son as regards to the
contents of the document.

Obviously, the son's business went into liquidation and the Bank tried to
rely on the guaranty that had been signed by the parents.  There was no
dispute as to the authenticity of the signatures.  The parents relied on the
lack of intention to sign the document as regards to it true effect. In
effect, they argued successfully that it was not their act. They lacked the
necessary intention.  Now the evidence to support such a case is extensive.
It is not an easy case to prove.

End Case
========

By analogy, this is what could happen when signing a digital document.  The
actual signing mechanism is a black box and hopefully what is actually being
signed in memory corresponds with the human readable display on the screen.


Now the next issue is what evidence will the signer need to successfully
support a claim of non est factum. I have not analysed this thoroughly but
it is an issue that needs to be addressed. The answer may be in the security
classification of software where there may exist a trusted path between the
memory where the document resides and the display screen and the key board.
This is highly unlikely to occur as it would, I think, require a
re-engineering of the current versions of the popular commercial Operating
Systems.  

Without a trusted path the signer will not be in a position to adequately
know what is being signed.  

I think what needs to be done is for the digital signing of document be
mapped out so that the necessary evidential issues are addressed.  This will
permit a court to have confidence in the technology and thus be in a better
position when it comes to a dispute.  Also the current digital signature
legislation apart from Germany totally ignores the trust required in the
signing mechanism.  In Germany the signing component must be classified to
at least ITSEC E4 (Common Criteria EAL 4) but ITSEC as has been identified
previously on this list does not address the crypto module.  So Fips 140-1
should be used.

The UTAH Dig Sig Act deals with trustworthy systems at the CA level.  Now
the CA has nothing to do with the signing of documents.  The CA at best will
store public keys that are used for the verification of signatures not the
affixing of signatures.  Really a post event analysis.

A further complication is that in many cases the onus of proof concerning
the authenticity of the digital signature will reside with the relying
party.  But that is another issue.

Adrian McCullagh
Director of Electronic Commerce		Tel: [phone]
Gadens Lawyers					Fax: [phone]	
level 39
Central Plaza 1
345 Queen Street
Brisbane Australia 4000

Ph. D. Candidate 
Thesis "The Incorporation of Trust Strategies in Digital Signature Regimes
for Elec. Comm."
Information Security Research Centre
Queensland University of Technology




---intentionally deleted material---

There are limits to the courts reliance on a purely objective view.
The courts tend to consider what must also be "reasonable."

If I were a pizza delivery person, and I'd crafted an ordinary-looking
receipt, whose fine print on the back reads "I hereby transfer title
to my house ...", I doubt that your signature on that receipt will
enable me to take your house from you.

Most of the "real" legal questions with digital signatures and our
new "cyber" environment will pivot upon the evolving problem of
deciding what are "reasonable expectations", given the technology
and other, less objective considerations.

___tony___

Tony Bartoletti 925-422-3881 <[e-mail]>
Information Operations, Warfare and Assurance Center
Lawrence Livermore National Laboratory
Livermore, CA 94551-9900


Received: from poptop.llnl.gov (poptop.llnl.gov [128.115.41.70]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id SAA15027 for <[e-mail]>; Wed, 12 Jul 2000 18:54:27 -0700 (PDT)
Received: from catalyst (catalyst.llnl.gov [128.115.222.68]) by poptop.llnl.gov (8.8.8/LLNL-3.0.2/pop.llnl.gov-5.1) with ESMTP id SAA26011; Wed, 12 Jul 2000 18:54:24 -0700 (PDT)
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.2 
Date: Wed, 12 Jul 2000 19:01:40 -0700
To: "P.J. Ponder" <[e-mail]>, Michael Zolotarev <[e-mail]>
From: Tony Bartoletti <[e-mail]>
Subject: RE: Current signature formats insufficient
Cc: Paul Koning <[e-mail]>, [e-mail], [e-mail], [e-mail]
In-Reply-To: <[e-mail].f l.us>
References: <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed

At 09:48 PM 7/12/00 -0400, P.J. Ponder wrote:
>The idea of a non-binding signature seems implausible to me - why sign,
>except to attest to something?  If you don't want to be bound, just don't
>sign.

When communicating over a channel, there may be cases where your "signature"
key is employed in serving to tamperproof, or authenticate the data 
transmitted.
Although, strictly speaking, you are "attesting" that "you indeed sent that
piece of data (authentication)" or at very least attesting "my key came into
contact with that data", you may well want it understood that you may not
agree with what the content might imply, when interpreted semantically.

You might write me, saying "What was that statement you disagreed with
so strongly", and so I send it to you, signed so that you know I was the
one who sent it.  Can you turn around and now claim I agree with that
statement?

How does one convey the "level of attestation" intended by a signature?

It would be one matter if signatures were restricted to whole-documents
formed of complete sentences.  One could qualify a submission with
"I don't agree with this part".  But in protocols, signatures are often
formed over oddly-constructed pieces of data that (some fear) might
easily be taken out of context.

The "key-usage" bits are/were intended to help manage this situation.
(Or so I thought.)

___tony___





Tony Bartoletti 925-422-3881 <[e-mail]>
Information Operations, Warfare and Assurance Center
Lawrence Livermore National Laboratory
Livermore, CA 94551-9900



Received: from fn3.freenet.tlh.fl.us (fn3.tfn.net [150.176.31.250]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id SAA11238 for <[e-mail]>; Wed, 12 Jul 2000 18:23:12 -0700 (PDT)
Received: from localhost (ponder@localhost) by fn3.freenet.tlh.fl.us (8.8.8/8.6.9) with ESMTP id VAA31034; Wed, 12 Jul 2000 21:48:13 -0400 (EDT)
Date: Wed, 12 Jul 2000 21:48:13 -0400 (EDT)
From: "P.J. Ponder" <[e-mail]>
To: Michael Zolotarev <[e-mail]>
cc: Paul Koning <[e-mail]>, [e-mail], [e-mail], [e-mail]
Subject: RE: Current signature formats insufficient
In-Reply-To: <[e-mail]>
Message-ID: <[e-mail]>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII

On Thu, 13 Jul 2000, Michael Zolotarev wrote:
< . . . . > 
> Issue 4:
> Existing legal framework, and its ability to accept a notion of
> 'non-binding' signature.
< . . . . > 
> Issue 4.
> It is more a legal problem, then PKIX. And I'd better shut up on this one.
> Hey, any lawyers out there? Tell us what you think, and please restrain
> yourself from using harsh language.

If you don't want to be bound, don't sign.  

If you can't see what you're signing, you're a fool to sign it.

I've eaten many a pizza delivered to the door, and never signed for one.

Signing for a package acknowledges that you have received the package, not
that the contents are what you ordered, or the right size or color or pin
configuration - just that the delivery person gave it to you and you
received it - sort of like a 'chain of custody' thing.  And that is
binding - you have attested to the fact that you received the package.

The idea of a non-binding signature seems implausible to me - why sign,
except to attest to something?  If you don't want to be bound, just don't
sign.





Received: from stargate.zergo.com.au (IDENT:[e-mail] [203.2.208.130]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id RAA07352 for <[e-mail]>; Wed, 12 Jul 2000 17:48:32 -0700 (PDT)
Received: from sydneymail1.baltimore.com.au (sydneymail1.jp.zergo.com.au [192.168.71.5]) by stargate.zergo.com.au (8.9.1/8.8.7) with ESMTP id KAA04190; Thu, 13 Jul 2000 10:56:11 +1000
Received: by sydneymail1.jp.zergo.com.au with Internet Mail Service (5.5.2650.21) id <3YQ0JPT2>; Thu, 13 Jul 2000 10:49:10 +1000
Message-ID: <[e-mail]>
From: Michael Zolotarev <[e-mail]>
To: Paul Koning <[e-mail]>, [e-mail]
Cc: [e-mail], [e-mail]
Subject: RE: Current signature formats insufficient
Date: Thu, 13 Jul 2000 10:49:08 +1000
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain; charset="iso-8859-1"

<< Simon, in case you need somebody to say something nice to you :) - I'm
fully agree with you. If you read my previous mail, you'll see that our
opinions are identical.>>

Now, back to the subject:

The discussion is trying to address a lot of  different issues at the same
time, and it's becoming a mess. Let me filter it out a bit.

Issue 1:
Existing 'typical' signing environment (i.e. OS, communication h/w, etc) and
its vulnerability in case of a hacker attack.

Issue 2:
A concern that a user does not always see what he/she signs.

Issue 3:
Potential use of biometrics to make signing more convenient and secure for
the end user.

Issue 4:
Existing legal framework, and its ability to accept a notion of
'non-binding' signature.

Issue 5:
Existing signature-associated structure and protocols, with regards to the
ability to express different attributes of signing environment.

Now, if you look at it calmly, you'll see that:
Issue 1 has got nothing to do with PKIX. We can talk about how easy it is to
hack WinNT, and for how much - but why on this list?

Issue 2 Has nothing to do with PKIX. The user does not always see what he
signs? - fine, come up with a device that shows (do not forget to implement
'do not show' tick box, ticked by default).

Issue 3 has very little to do with PKIX. It is of common interest, I
believe, but it is rather technological, then anything else. We had a
discussion about biometrics already, in lengths, in the qualified certs
thread.

Issue 4.
It is more a legal problem, then PKIX. And I'd better shut up on this one.
Hey, any lawyers out there? Tell us what you think, and please restrain
yourself from using harsh language.

Issue 5. The formats of the signature, algorithms, and protocols must be
considered with NO RELATIONS at all to the environment. We MUST abstract
aspects of signing from the details of platforms, UI and whatever else. We
should assume that the environment is solid, and that the only thing that we
have to protect is the signature itself. 


So, what are we left with? Do I hear "Can we make a signature to communicate
extra attributes"?

Yes, we can.


M

> -----Original Message-----
> From: Paul Koning [mailto:[e-mail]]
> Sent: Thursday, July 13, 2000 12:38 AM
> To: [e-mail]
> Cc: [e-mail]; [e-mail]
> Subject: Re: Current signature formats insufficient
> 
> 
> >>>>> "Simon" == Simon McMahon <[e-mail]> writes:
> 
>  Simon> Hi all, My 2c worth.
> 
>  Simon> You should look to the analog-signature as an analogy. It's
>  Simon> the content of what you sign that includes the terms and
>  Simon> therefore the extent to which the signer is bound. Carelessly
>  Simon> given signatures should be legally binding, otherwise
>  Simon> ignorance will be used as a defense for repudiation, and only
>  Simon> fraudulently or forcefully obtained signatues should be able
>  Simon> to be sucessfully repudiated by recourse to the law and
>  Simon> courts.
> 
> I think that's a fine analogy, and it also serves to illustrate the
> issue that Denis is concerned about.
> 
> With classic signatures, the norm is that you see what you sign.  (One
> exception is the standard story about the overworked executive who's
> handed a stack of 50 memos to sign, with little yellow tabs marking
> "here's the spot" and someone slips in a ringer.  Don't know how
> common that is outside novels.)
> 
> With digital signatures, the norm is that you have no idea.  As Denis
> mentioned, current smartcards have no way of showing you what you're
> signing.  If you use an application that signs things (like a mailer)
> the binding is a little better.  There you still have to trust that
> the text you entered is in fact what's being signed -- in other words,
> that the program is trustworthy, correct, and unsubverted by trojan
> horses.  One good reason for using PGP, because you can check this,
> unlike closed source mailers.
> 
> The new (USA) digital signature law scares me, because it makes no
> sense so long as digital signature mechanisms continue to provide no
> meaningful way for the user to know what is being signed.  
> 
> 	   paul
> 


Received: from e2.ny.us.ibm.com (e2.ny.us.ibm.com [32.97.182.102]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id PAA05307 for <[e-mail]>; Wed, 12 Jul 2000 15:25:50 -0700 (PDT)
From: [e-mail]
Received: from northrelay02.pok.ibm.com (northrelay02.pok.ibm.com [9.117.200.22]) by e2.ny.us.ibm.com (8.9.3/8.9.3) with ESMTP id SAA79246; Wed, 12 Jul 2000 18:27:20 -0400
Received: from D51MTA04.pok.ibm.com (d51mta04.pok.ibm.com [9.117.200.32]) by northrelay02.pok.ibm.com (8.8.8m3/NCO v4.92) with SMTP id SAA16394; Wed, 12 Jul 2000 18:27:16 -0400
Received: by D51MTA04.pok.ibm.com(Lotus SMTP MTA v4.6.5  (863.2 5-20-1999))  id 8525691A.007B581D ; Wed, 12 Jul 2000 18:27:14 -0400
X-Lotus-FromDomain: IBMUS
To: Aram Perez <[e-mail]>
cc: PKIX <[e-mail]>
Message-ID: <[e-mail]>
Date: Wed, 12 Jul 2000 18:27:07 -0400
Subject: Re: Signing what you don't understand: a practical example
Mime-Version: 1.0
Content-type: text/plain; charset=us-ascii
Content-Disposition: inline

     Responses below.  Do we need a standard abbreviation similar to AFAIK
for wording which contains an escape clause (like one of my answers below),
and if so, what should it be?

          Tom Gindin


Aram Perez <[e-mail]> on 07/12/2000 12:28:44 PM

To:   PKIX <[e-mail]>
cc:
Subject:  Re: Signing what you don't understand: a practical example



Hi Tom,

> [Tom Gindin] The same problem exists with current smart cards, but some
> people are putting indicators that a key is on a smart card into their
> certificates already.  Either the CA generates the key on and delivers
the
> smart card, or the user shows up with card in hand.  Hopefully, a BCSC
> would not allow signature key backup.

When you say "some people are putting indicators that a key is on a smart
card into their certificates already", does the CA check that fact? Who's
liable if the indicator is positive when in fact I have no smart card? If
the CA generates the key, how do I know the CA doesn't keep a copy?

[Tom Gindin] 1) The CA is certainly supposed to check that a key is on a
smart card before including a CertificatePolicy or ExtendedKeyUsage which
implies that the key is on one; 2) The CA is approximately as liable
(warning: weasel wording ahead!) for certifying this fact properly as for
certifying the contents of SubjectAltName properly; 3) As far as key
generation goes, this is just a higher value smart card - if the CA can be
trusted for generation today he can probably be trusted for it on these.

Regards,
Aram Perez




Received: from slack.lne.com (gw.lne.com [209.157.136.81]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id NAA03203 for <[e-mail]>; Wed, 12 Jul 2000 13:17:26 -0700 (PDT)
Received: (from ericm@localhost) by slack.lne.com (8.9.3/8.9.3) id NAA26748; Wed, 12 Jul 2000 13:19:03 -0700
Date: Wed, 12 Jul 2000 13:19:03 -0700
From: Eric Murray <[e-mail]>
To: Jean-Marc Desperrier <[e-mail]>
Cc: [e-mail]
Subject: Re: Current signature formats insufficient
Message-ID: <[e-mail]>
References: <000001bfeb13$d25fe870$0201010a@intergalactic> <[e-mail]> <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Mailer: Mutt 1.0pre3us
In-Reply-To: <[e-mail]>

On Wed, Jul 12, 2000 at 07:35:13PM +0200, Jean-Marc Desperrier wrote:
> Jan Holger Schmidt wrote:
> 
> > Hopefully there will be soon secure/trustworthy devices, where you can use your
> > 'binding' key with a lower risk of signing something you couldn't see. However,
> > to build them for many document formats will be a challange.
> 
> The best for now is to recommend to insert the smart card just before signing a
> legally binding document, and remove it just after.
> Which does not prove the document you sign is the one you read, but still lowers the
> risks a lot.


I'll agree that leaving a smartcard in the slot (and unlocked)
wil soon be Really Dumb..  but only inserting it when it's
needed doesn't add much to your security.

PC/SC, the most common host-side smart-card-reader API, can wake up
a process that's waiting for a smartcard insertion event.

That process could be the one that's signing your document or
it could be rogue code that's going to have your smartcard sign
something bad, and/or start a keyboard sniffer that'll capture
the smartcard PIN.

So I don't think that it lowers the risk very much.


-- 
 Eric Murray www.lne.com/~ericm  ericm at the site lne.com  PGP keyid:E03F65E5
    Security consulting: security models, reviews, protocols, crypto.


Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id LAA01544 for <[e-mail]>; Wed, 12 Jul 2000 11:38:54 -0700 (PDT)
Received: from ireserver.Ireland.Sun.COM ([129.156.220.7]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id LAA25686; Wed, 12 Jul 2000 11:40:49 -0700 (PDT)
Received: from sun.com (boston [129.156.220.153]) by ireserver.Ireland.Sun.COM (8.8.8+Sun/8.8.8/ENSMAIL,v1.9) with ESMTP id TAA16963; Wed, 12 Jul 2000 19:40:47 +0100 (BST)
Sender: [e-mail]
Message-ID: <[e-mail]>
Date: Wed, 12 Jul 2000 19:40:47 +0100
From: Sean Mullan <[e-mail]>
X-Mailer: Mozilla 4.51 [en] (X11; U; SunOS 5.7 sun4u)
X-Accept-Language: en
MIME-Version: 1.0
To: [e-mail], [e-mail], [e-mail]
Subject: Re: I-D ACTION:draft-ietf-pkix-ldap-schema-00.txt
References: <[e-mail]> <[e-mail]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

One other comment - I have mentioned this previously when
commenting on RFC 2587, but as of yet no changes have
been made. 

Building certification paths in a 'reverse'
direction (from trust anchor to EE) is a valid way to build
certification paths. However, RFC 2587 (PKIX LDAPv2 schema) specifies
that the storage of cross certificates in the reverse component of
the crossCertificatePair is optional. It is not possible to efficiently
build a certification path in a 'reverse' direction unless the 
certificates are populated in the reverse component of the crossCertificatePair
attribute. Specifying that this feature is optional makes it
difficult to build paths in a reverse direction in a trust model
where lots of cross certificates and multiple directories
are involved and you don't know if the CAs support
the optional storage.

I would like to suggest that RFC 2587 be amended/updated
to make storage of cross certificates in the reverse component of the
crossCertificatePair attribute mandatory.

Thanks,
Sean


Sean Mullan wrote:
> 
> Hi David,
> 
> Some comments on the draft below.
> 
> [e-mail] wrote:
> >
> > A New Internet-Draft is available from the on-line Internet-Drafts directories.
> > This draft is a work item of the Public-Key Infrastructure (X.509) Working Group of the IETF.
> >
> >         Title           : Internet X.509 Public Key Infrastructure Additional
> >                           LDAP Schema for PKIs and PMIs
> >         Author(s)       : D. Chadwick
> >         Filename        : draft-ietf-pkix-ldap-schema-00.txt
> >         Pages           : 11
> >         Date            : 11-Jul-00
> 
> Section 3.2 Certificate Match
> 
> I think the X.509 certificate matching rules are missing some essential and
> important fields in the certificateAssertion structure for filtering on
> certificates. We may want to consider defining a superset. I submitted these
> comments to the X.509 editors but apparently it was too late to integrate them
> into the 2000 update.
> 
>   * you should be able to match on more than one pathToName and on non-X500
>     name types. This is inconsistent with name constraints which allow you
>     to constrain to more than one name and different name types.
> 
>   * you should be able to match on more than the subject alt name type. You
>     should also be able to match on the subject alt name itself, and specify more than
>     one subject alt name as certificates can contain more than one.
> 
>   * you should be able to match on the subject public key as well as the subject public
>     key algorithm OID.
> 
>   * you should be able to match on the basic constraints extension, especially the
>     maxPathLen value. This is useful for finding potential certificates when
>     building certification paths from the target to the most-trusted CA. For ex,
>     if a partial path has been built, any candidate certificate must have a
>     maxPathLen value greater than or equal to the number of certificates in the
>     partial path.
> 
> I think it is very important to include the Certificate pair matching rules, as
> these are very useful when building certification paths and trying to discover
> which of many cross certificates satisfy various validation constraints, and eliminating
> those that do not.
> 
> Other comments:
> 
>   * What RFC format are you using for the encoding of DNs - 1779? This should be referenced.
> 
> Section 4.2 Certificate List Match
> 
> There is an error in the CertificateListAssertion definition in X.509 2000. The
> authorityKeyIdentifier component should be marked OPTIONAL. This probably doesn't
> affect your definition, but I just wanted to make you aware of it.
> 
> --Sean


Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id LAA01220 for <[e-mail]>; Wed, 12 Jul 2000 11:29:40 -0700 (PDT)
Received: from ireserver.Ireland.Sun.COM ([129.156.220.7]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id LAA20798; Wed, 12 Jul 2000 11:31:33 -0700 (PDT)
Received: from sun.com (boston [129.156.220.153]) by ireserver.Ireland.Sun.COM (8.8.8+Sun/8.8.8/ENSMAIL,v1.9) with ESMTP id TAA15831; Wed, 12 Jul 2000 19:31:31 +0100 (BST)
Sender: [e-mail]
Message-ID: <[e-mail]>
Date: Wed, 12 Jul 2000 19:31:31 +0100
From: Sean Mullan <[e-mail]>
X-Mailer: Mozilla 4.51 [en] (X11; U; SunOS 5.7 sun4u)
X-Accept-Language: en
MIME-Version: 1.0
To: [e-mail]
CC: [e-mail], [e-mail]
Subject: Re: I-D ACTION:draft-ietf-pkix-ldap-schema-00.txt
References: <[e-mail]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Hi David,

Some comments on the draft below.

[e-mail] wrote:
> 
> A New Internet-Draft is available from the on-line Internet-Drafts directories.
> This draft is a work item of the Public-Key Infrastructure (X.509) Working Group of the IETF.
> 
>         Title           : Internet X.509 Public Key Infrastructure Additional
>                           LDAP Schema for PKIs and PMIs
>         Author(s)       : D. Chadwick
>         Filename        : draft-ietf-pkix-ldap-schema-00.txt
>         Pages           : 11
>         Date            : 11-Jul-00

Section 3.2 Certificate Match

I think the X.509 certificate matching rules are missing some essential and
important fields in the certificateAssertion structure for filtering on
certificates. We may want to consider defining a superset. I submitted these
comments to the X.509 editors but apparently it was too late to integrate them
into the 2000 update.

  * you should be able to match on more than one pathToName and on non-X500
    name types. This is inconsistent with name constraints which allow you 
    to constrain to more than one name and different name types. 

  * you should be able to match on more than the subject alt name type. You
    should also be able to match on the subject alt name itself, and specify more than
    one subject alt name as certificates can contain more than one.

  * you should be able to match on the subject public key as well as the subject public
    key algorithm OID.

  * you should be able to match on the basic constraints extension, especially the
    maxPathLen value. This is useful for finding potential certificates when
    building certification paths from the target to the most-trusted CA. For ex,
    if a partial path has been built, any candidate certificate must have a 
    maxPathLen value greater than or equal to the number of certificates in the 
    partial path.

I think it is very important to include the Certificate pair matching rules, as
these are very useful when building certification paths and trying to discover 
which of many cross certificates satisfy various validation constraints, and eliminating
those that do not.

Other comments:

  * What RFC format are you using for the encoding of DNs - 1779? This should be referenced.

Section 4.2 Certificate List Match

There is an error in the CertificateListAssertion definition in X.509 2000. The
authorityKeyIdentifier component should be marked OPTIONAL. This probably doesn't
affect your definition, but I just wanted to make you aware of it.

--Sean


Received: from poptop.llnl.gov (poptop.llnl.gov [128.115.41.70]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id LAA00865 for <[e-mail]>; Wed, 12 Jul 2000 11:19:47 -0700 (PDT)
Received: from catalyst (catalyst.llnl.gov [128.115.222.68]) by poptop.llnl.gov (8.8.8/LLNL-3.0.2/pop.llnl.gov-5.1) with ESMTP id LAA11796; Wed, 12 Jul 2000 11:21:04 -0700 (PDT)
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.2 
Date: Wed, 12 Jul 2000 11:28:21 -0700
To: Aram Perez <[e-mail]>, [e-mail]
From: Tony Bartoletti <[e-mail]>
Subject: Re: Current signature formats insufficient
In-Reply-To: <[e-mail]>
References: <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed

At 11:06 AM 7/12/00 -0700, Aram Perez wrote:
>Jean-Marc Desperrier wrote:
>
>[snip]
> >
> > And use a software key, with authentification only key usage, for ssl
> > authenfication
> > and the like.
>
>If by "authentication only key usage" you mean the DS bit, what happens when
>a key has both the DS and NR bits set?

Use the CA's CP/CPS for guidance?  ;)

___tony___


Tony Bartoletti 925-422-3881 <[e-mail]>
Information Operations, Warfare and Assurance Center
Lawrence Livermore National Laboratory
Livermore, CA 94551-9900



Received: from mta5.snfc21.pbi.net (mta5.snfc21.pbi.net [206.13.28.241]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id LAA00524 for <[e-mail]>; Wed, 12 Jul 2000 11:07:35 -0700 (PDT)
Received: from [192.168.1.57] ([208.233.228.110]) by mta5.snfc21.pbi.net (Sun Internet Mail Server sims.3.5.2000.01.05.12.18.p9) with ESMTP id <[e-mail]> for [e-mail]; Wed, 12 Jul 2000 11:06:10 -0700 (PDT)
Date: Wed, 12 Jul 2000 11:06:45 -0700
From: Aram Perez <[e-mail]>
Subject: Re: Current signature formats insufficient
In-reply-to: <[e-mail]>
To: [e-mail]
Message-id: <[e-mail]>
MIME-version: 1.0
Content-type: text/plain; charset="US-ASCII"
Content-transfer-encoding: 7bit
User-Agent: Microsoft-Outlook-Express-Macintosh-Edition/5.02.2022

Jean-Marc Desperrier wrote:

[snip]
> 
> And use a software key, with authentification only key usage, for ssl
> authenfication
> and the like.

If by "authentication only key usage" you mean the DS bit, what happens when
a key has both the DS and NR bits set?

Regards,
Aram Perez



Received: from poptop.llnl.gov (poptop.llnl.gov [128.115.41.70]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id KAA00101 for <[e-mail]>; Wed, 12 Jul 2000 10:52:31 -0700 (PDT)
Received: from catalyst (catalyst.llnl.gov [128.115.222.68]) by poptop.llnl.gov (8.8.8/LLNL-3.0.2/pop.llnl.gov-5.1) with ESMTP id KAA17010; Wed, 12 Jul 2000 10:45:20 -0700 (PDT)
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.2 
Date: Wed, 12 Jul 2000 10:52:37 -0700
To: Adrian McCullagh <[e-mail]>, "'Ben Laurie'" <[e-mail]>, Frank Balluffi <[e-mail]>
From: Tony Bartoletti <[e-mail]>
Subject: RE: Current signature formats insufficient
Cc: "'[e-mail]'" <[e-mail]>, [e-mail]
In-Reply-To: <[e-mail] .au>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed

At 06:16 AM 7/12/00 +1000, Adrian McCullagh wrote:
>Ben;
>
>The law does not see it that way.  In the UK if you sign a document as
>a receipt and there are terms on the receipt then you are deemed to
>have read the terms and agreed to be bound by them.  (see the case of
>L'Strange v. Graucob).  The law will not take your subjective view
>into account.  The law will look upon the action from an objective
>view.  This is only a simplified version and yes there are exceptions
>but the general rule is that if a man comes to your door with a
>package and asks you to sign the acknowledgement of receipt you will
>be bound by the terms on the back of the document.  The same position
>also applies in the USA and in Australia.

There are limits to the courts reliance on a purely objective view.
The courts tend to consider what must also be "reasonable."

If I were a pizza delivery person, and I'd crafted an ordinary-looking
receipt, whose fine print on the back reads "I hereby transfer title
to my house ...", I doubt that your signature on that receipt will
enable me to take your house from you.

Most of the "real" legal questions with digital signatures and our
new "cyber" environment will pivot upon the evolving problem of
deciding what are "reasonable expectations", given the technology
and other, less objective considerations.

___tony___

Tony Bartoletti 925-422-3881 <[e-mail]>
Information Operations, Warfare and Assurance Center
Lawrence Livermore National Laboratory
Livermore, CA 94551-9900



Received: from certplus.com ([195.101.88.81]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id KAA29486 for <[e-mail]>; Wed, 12 Jul 2000 10:34:04 -0700 (PDT)
Received: from certplus.com (nt4_jmd.certplus.com [192.168.1.17]) by certplus.com (8.8.7/8.8.7) with ESMTP id SAA32065 for <[e-mail]>; Wed, 12 Jul 2000 18:05:11 +0200
Message-ID: <[e-mail]>
Date: Wed, 12 Jul 2000 19:35:13 +0200
From: Jean-Marc Desperrier <[e-mail]>
Organization: Certplus
X-Mailer: Mozilla 4.72 [en] (WinNT; I)
X-Accept-Language: en
MIME-Version: 1.0
To: [e-mail]
Subject: Re: Current signature formats insufficient
References: <000001bfeb13$d25fe870$0201010a@intergalactic> <[e-mail]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Jan Holger Schmidt wrote:

> Hopefully there will be soon secure/trustworthy devices, where you can use your
> 'binding' key with a lower risk of signing something you couldn't see. However,
> to build them for many document formats will be a challange.

The best for now is to recommend to insert the smart card just before signing a
legally binding document, and remove it just after.
Which does not prove the document you sign is the one you read, but still lowers the
risks a lot.

And use a software key, with authentification only key usage, for ssl authenfication
and the like.




Received: from smtp.scotland.net (unixpark3.scotland.net [148.176.231.3]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id JAA28305 for <[e-mail]>; Wed, 12 Jul 2000 09:42:15 -0700 (PDT)
Received: from e1h3p178.scotland.net ([148.176.235.179] helo=jrwork) by smtp.scotland.net with smtp (Exim 3.13 #2) id 13CPc2-0004Gs-00; Wed, 12 Jul 2000 17:43:54 +0100
Message-ID: <004c01bfec20$0e8af6c0$0400000a@jrwork>
From: "John Ross" <[e-mail]>
To: <[e-mail]>, <[e-mail]>
Cc: <[e-mail]>
Subject: Re: Signing what you don't understand: a practical example
Date: Wed, 12 Jul 2000 17:41:39 +0100
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 4.72.3110.5
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6600

Please have a look at the following internet draft:
"Electronic Signature Formats for long term electronic signature"

at
http://www.ietf.org/html.charters/smime-charter.html

I believe it proposes solutions to the problems being raised here.

Regards

John Ross

-----Original Message-----
From: "denis bider" <[e-mail]>
To: <[e-mail]>
Cc: <[e-mail]>
Date: 12 July 2000 16:10
Subject: RE: Signing what you don't understand: a practical example


>Hello Tom,
>
>I don't quite understand why such an indicator within a certificate would
be
>needed for this technique to have any real use.
>
>The current possible outcomes of a standard signature verification process
>are:
>- valid, and
>- invalid.
>
>What I am proposing is, essentially, that the possible range of returns be
>widened to at least:
>- valid (== technically and semantically valid)
>- valid but not binding (== technically valid, semantically invalid)
>- invalid (== technically and semantically invalid)
>
>The security device I was mentioning was only intended to show a practical
>situation where the widened range of possible returns, as outlined above,
>WILL be needed sooner or later. Ie, it is just *a* usage scenario; it is
not
>an attempt to encompass all possible usage scenarios.
>
>Regards,
>
>denis
>
>
>-----Original Message-----
>From: [e-mail] [mailto:[e-mail]]
>Sent: 12. julij 2000 03:11
>To: Aram Perez
>Cc: [e-mail]
>Subject: Re: Signing what you don't understand: a practical example
>
>
>     For Denis' technique to have any real use, there would also need to be
>an indicator somewhere in the certificate that "the private key of this
>pair is held in a Bider-compliant smart card".  Doing that (and it could go
>into any of several extensions, or a new one could be defined), is
>considerably easier than changing the signature format.
>     For PKCS 1.5, of course, he could change that format just by defining
>a hash function parameter value (if PKCS #1 would agree), or a new OID for
>SHA-1 (SHA1OnBiderCard ??).  Getting verifiers to understand either of
>these might be interesting, though.
>
>          Tom Gindin
>
>Aram Perez <[e-mail]> on 07/11/2000 08:44:48 PM
>
>To:   [e-mail]
>cc:
>Subject:  Re: Signing what you don't understand: a practical example
>
>
>
>Hi Denis,
>
>[snip]
>> 2. Encode the algorithm ID for the hash function and the hash value into
>an
>> ASN.1 value of type DigestInfo (see Section 11) with the Distinguished
>> Encoding Rules (DER), where the type DigestInfo has the syntax
>>
>> DigestInfo ::= SEQUENCE {
>> digestAlgorithm AlgorithmIdentifier,
>> digest OCTET STRING,
>> flags BIT STRING OPTIONAL
>> }
>>
>> Meaning of 'flags' bits:
>> first bit: content-not-understood
>> subsequent bits: not defined at this time
>>
>> In case the value of the first bit of 'flags' is 0, the 'flags' field may
>> be omitted for purposes of backward compatibility. However, this is not
>> recommended. If omitted, the interpretation of the 'flags' field is
>> application-dependent.
>>
>> The first field identifies the hash function and the second contains the
>> hash value. Let T be the DER encoding.
>>
>> 3. If emLen is less than ||T|| + 10 then output "intended encoded message
>> length too short".
>>
>> 4. Generate an octet string PS consisting of emLen-||T||-2 octets with
>value
>> FF (hexadecimal). The length of PS will be at least 8 octets.
>>
>> 5. Concatenate PS, the DER encoding T, and other padding to form the
>encoded
>> message EM as
>>
>> EM = 01 || PS || 00 || T
>>
>> 6. Output EM.
>
>[Warning: Long sentence ahead.] If you received a signed message from me,
>formatted per your instructions and with the flags parameter, how would you
>know that I was using the security device you have described, that the
>message was displayed on that device and that I really understood what I
>signed? I can easily create an identical message on my insecure PC with
>today's smartcards or just with the right software.
>
>Regards,
>Aram Perez
>
>
>



Received: from mta5.snfc21.pbi.net (mta5.snfc21.pbi.net [206.13.28.241]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id JAA27649 for <[e-mail]>; Wed, 12 Jul 2000 09:33:50 -0700 (PDT)
Received: from [192.168.1.57] ([208.233.228.110]) by mta5.snfc21.pbi.net (Sun Internet Mail Server sims.3.5.2000.01.05.12.18.p9) with ESMTP id <[e-mail]> for [e-mail]; Wed, 12 Jul 2000 09:28:14 -0700 (PDT)
Date: Wed, 12 Jul 2000 09:28:44 -0700
From: Aram Perez <[e-mail]>
Subject: Re: Signing what you don't understand: a practical example
In-reply-to: <[e-mail]>
To: PKIX <[e-mail]>
Message-id: <[e-mail]>
MIME-version: 1.0
Content-type: text/plain; charset="US-ASCII"
Content-transfer-encoding: 7bit
User-Agent: Microsoft-Outlook-Express-Macintosh-Edition/5.02.2022

Hi Tom,

> [Tom Gindin] The same problem exists with current smart cards, but some
> people are putting indicators that a key is on a smart card into their
> certificates already.  Either the CA generates the key on and delivers the
> smart card, or the user shows up with card in hand.  Hopefully, a BCSC
> would not allow signature key backup.

When you say "some people are putting indicators that a key is on a smart
card into their certificates already", does the CA check that fact? Who's
liable if the indicator is positive when in fact I have no smart card? If
the CA generates the key, how do I know the CA doesn't keep a copy?

Regards,
Aram Perez



Received: from e4.ny.us.ibm.com (e4.ny.us.ibm.com [32.97.182.104]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id JAA24228 for <[e-mail]>; Wed, 12 Jul 2000 09:06:01 -0700 (PDT)
From: [e-mail]
Received: from northrelay02.pok.ibm.com (northrelay02.pok.ibm.com [9.117.200.22]) by e4.ny.us.ibm.com (8.9.3/8.9.3) with ESMTP id MAA101274; Wed, 12 Jul 2000 12:07:59 -0400
Received: from D51MTA04.pok.ibm.com (d51mta04.pok.ibm.com [9.117.200.32]) by northrelay02.pok.ibm.com (8.8.8m3/NCO v4.92) with SMTP id MAA138446; Wed, 12 Jul 2000 12:07:55 -0400
Received: by D51MTA04.pok.ibm.com(Lotus SMTP MTA v4.6.5  (863.2 5-20-1999))  id 8525691A.00589A8B ; Wed, 12 Jul 2000 12:07:47 -0400
X-Lotus-FromDomain: IBMUS
To: Aram Perez <[e-mail]>
cc: PKIX <[e-mail]>
Message-ID: <[e-mail]>
Date: Wed, 12 Jul 2000 12:07:39 -0400
Subject: Re: Signing what you don't understand: a practical example
Mime-Version: 1.0
Content-type: text/plain; charset=us-ascii
Content-Disposition: inline

     Hi Aram:

     Response below.

          Tom

Aram Perez <[e-mail]> on 07/11/2000 09:35:54 PM

To:   PKIX <[e-mail]>
cc:
Subject:  Re: Signing what you don't understand: a practical example



Hi Tom,

> For Denis' technique to have any real use, there would also need to be
> an indicator somewhere in the certificate that "the private key of this
> pair is held in a Bider-compliant smart card".  Doing that (and it could
go
> into any of several extensions, or a new one could be defined), is
> considerably easier than changing the signature format.

But how does the CA know that I'm using a "Bider-compliant smart card"
(BCSC)? Do I have to physically show up somewhere with my BCSC to prove
that I have one? Since the BCSC isn't fully specified, I don't know if it
allows me to keep a backup copy of my signature key. If it does, then I
might/probably could feed the backup into a software only system.


[Tom Gindin] The same problem exists with current smart cards, but some
people are putting indicators that a key is on a smart card into their
certificates already.  Either the CA generates the key on and delivers the
smart card, or the user shows up with card in hand.  Hopefully, a BCSC
would not allow signature key backup.

Regards,
Aram Perez

[snip]






Received: from ra.bpsi.net (ra.bpsi.net [199.199.134.1]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id IAA23456 for <[e-mail]>; Wed, 12 Jul 2000 08:55:31 -0700 (PDT)
Received: from bpsi.net (port402.bpsi.net [209.54.245.202]) by ra.bpsi.net (8.9.0/8.9.0) with ESMTP id KAA04606; Wed, 12 Jul 2000 10:57:17 -0500 (CDT)
Message-ID: <[e-mail]>
Date: Wed, 12 Jul 2000 10:55:42 -0500
From: Dale Gustafson <[e-mail]>
X-Mailer: Mozilla 4.73 [en]C-CCK-MCD NSCPCD47  (Win95; U)
X-Accept-Language: en,pdf
MIME-Version: 1.0
To: [e-mail]
CC: [e-mail]
Subject: Re: Current signature formats insufficient
References: <000201bfeb5f$79a796f0$0201010a@intergalactic>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Denis,

denis bider wrote:

[snip]

> However, I think that we have to admit that the solution you identified as
> "all singing / all dancing" is, in fact, the bare minimum that needs to be
> implemented before we can move into a true, paperless electronic era.

Did not intend to imply any limits on how sophisticated and elegant security
products might become -- just noting the ever present tradeoff between security
and useability/functionality.  There will no doubt be many significant
developments over the next few years.

Getting back to your main point.  Clearly, the signer must have authoritative
control over the electronic document signing process.  For example, if one signs
a (paper) legal document today, it is not unusual for the one or both parties to
"edit" the document via hand-written changes which are initialed by both
parties, etc. (prior to signing/dating) and become part of the written
agreement.  I'm not aware of a similar capability in the digital world yet.
Perhaps others could comment on whether this is a significant and immediate
requirement that is not being addressed today and, if yes, whether the PKIX can
help at this time.  Perhaps there are other presentation layer standardization
efforts that are also applicable.  Apparently there are -- messages from Antonio
and Malte arrive as I edit this (timing is everything :-)

A limitation of putting such control information in the signature block (or in
the x.509 certificate) is that much has to be anticipated well in advance of a
signing event.  Logically, additions and / or changes should be included in the
electronic document before it is signed and the format of those adds / modifies
likely need to be document-specific.

Best Regards,

Dale Gustafson





Received: from gatekeeper.itsec-debis.de (gatekeeper.itsec-debis.de [195.227.50.6]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id IAA23217 for <[e-mail]>; Wed, 12 Jul 2000 08:54:12 -0700 (PDT)
Received: from gatekeeper (gatekeeper [192.168.2.1] (may be forged)) by gatekeeper.itsec-debis.de (8.8.8+Sun/8.8.8) with SMTP id RAA14898; Wed, 12 Jul 2000 17:53:46 +0200 (MET DST)
Received: by itsec-debis.de id SAA02017; Wed, 12 Jul 2000 18:07:26 +0200
Message-ID: <[e-mail]>
Date: Wed, 12 Jul 2000 18:02:29 +0200
From: Jan Holger Schmidt <[e-mail]>
Reply-To: [e-mail]
Organization: Debis IT Security Services
X-Mailer: Mozilla 4.51 [en] (WinNT; I)
X-Accept-Language: en
MIME-Version: 1.0
To: [e-mail]
CC: [e-mail]
Subject: Re: Current signature formats insufficient
References: <000001bfeb13$d25fe870$0201010a@intergalactic>
Content-Type: multipart/mixed; boundary="------------565DA3E73CA116F553BF61C4"

This is a multi-part message in MIME format.
--------------565DA3E73CA116F553BF61C4
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Denis,

to change the signature format would not solve your problem. As you say, you can
not be aware of what you sign. So how do you know, that the signature is in the
right format and the bit for "non-binding" isn't set in the right way?

As already adressed by others you should do this with different keys having
different certificates (e.g. one for non repudiation ('binding') and one for
authentication ('non binding'). When you don't trust your PC to select the right
key from the card, you could either protect the different keys with different
PINs or you cold store the keys on different cards.

Hopefully there will be soon secure/trustworthy devices, where you can use your
'binding' key with a lower risk of signing something you couldn't see. However,
to build them for many document formats will be a challange.

Best regards

Jan

--------------565DA3E73CA116F553BF61C4
Content-Type: text/x-vcard; charset=us-ascii;
 name="jh-schmidt.vcf"
Content-Transfer-Encoding: 7bit
Content-Description: Card for Jan Holger Schmidt
Content-Disposition: attachment;
 filename="jh-schmidt.vcf"

begin:vcard 
n:Schmidt;Jan Holger
tel;fax:+49 - 228 - 9841-60
tel;work:+49 - 228 - 9841-520
x-mozilla-html:FALSE
org:debis IT Security Services
adr:;;Rabinstr. 8;Bonn;;;Germany
version:2.1
email;internet:[e-mail]
fn:Jan Holger Schmidt
end:vcard

--------------565DA3E73CA116F553BF61C4--



Received: from slack.lne.com ([209.157.136.81]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id IAA22809 for <[e-mail]>; Wed, 12 Jul 2000 08:51:47 -0700 (PDT)
Received: (from ericm@localhost) by slack.lne.com (8.9.3/8.9.3) id IAA25860; Wed, 12 Jul 2000 08:53:06 -0700
Date: Wed, 12 Jul 2000 08:53:06 -0700
From: Eric Murray <[e-mail]>
To: Paul Koning <[e-mail]>
Cc: [e-mail]
Subject: Re: Current signature formats insufficient
Message-ID: <[e-mail]>
References: <000901bfeb64$38642f50$0201010a@intergalactic> <013901bfeba8$419218f0$[e-mail]> <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Mailer: Mutt 1.0pre3us
In-Reply-To: <[e-mail]>

On Wed, Jul 12, 2000 at 10:38:24AM -0400, Paul Koning wrote:
> >>>>> "Simon" == Simon McMahon <[e-mail]> writes:
> 
>  Simon> Hi all, My 2c worth.
> 
>  Simon> You should look to the analog-signature as an analogy. It's
>  Simon> the content of what you sign that includes the terms and
>  Simon> therefore the extent to which the signer is bound. Carelessly
>  Simon> given signatures should be legally binding, otherwise
>  Simon> ignorance will be used as a defense for repudiation, and only
>  Simon> fraudulently or forcefully obtained signatues should be able
>  Simon> to be sucessfully repudiated by recourse to the law and
>  Simon> courts.
> 
> I think that's a fine analogy, and it also serves to illustrate the
> issue that Denis is concerned about.
> 
> With classic signatures, the norm is that you see what you sign.  (One
> exception is the standard story about the overworked executive who's
> handed a stack of 50 memos to sign, with little yellow tabs marking
> "here's the spot" and someone slips in a ringer.  Don't know how
> common that is outside novels.)

I don't know how often ringers are slipped in, but normal people
are expected/encouraged to sign things without reading them fully
all the time.  A good example is when buying a house.  I have
bought two houses (both in California), and at the final document
signing meeting for each, signed between 20 and 40 documents.  Both I
and my girlfriend who I bought the houses with read fast and
have negotiated many contracts so we're somewhat practiced in
reading contractese.  We split up the docs to read and skimmed them
rather than reading in depth.

It took us twice as long as the escrow agents had allotted to do the
signatures.  People who read slower and aren't familiar with contractese
would take all day to read every document carefully.  It's obvious that
they don't expect most people to read the documents, and certainly not
to read them carefully.


> With digital signatures, the norm is that you have no idea.  As Denis
> mentioned, current smartcards have no way of showing you what you're
> signing.  If you use an application that signs things (like a mailer)
> the binding is a little better.  There you still have to trust that
> the text you entered is in fact what's being signed -- in other words,
> that the program is trustworthy, correct, and unsubverted by trojan
> horses.  One good reason for using PGP, because you can check this,
> unlike closed source mailers.

With PGP you can check the source of the mailer/encryption program.
Being able to do so doesn't help your checking for trojans in the OS
and it's there that it's easy to attack the smartcard or mailer signing
program- just substitute the hash of the Bad Document for the hash
of the Good Document before it's signed.


> The new (USA) digital signature law scares me, because it makes no
> sense so long as digital signature mechanisms continue to provide no
> meaningful way for the user to know what is being signed.  

Everyone is pretending that the OS is secure because no one wants to
have to fix it.

-- 
 Eric Murray www.lne.com/~ericm  ericm at the site lne.com  PGP keyid:E03F65E5
    Security consulting: security models, reviews, protocols, crypto.


Received: from e4.ny.us.ibm.com (e4.ny.us.ibm.com [32.97.182.104]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id IAA22725 for <[e-mail]>; Wed, 12 Jul 2000 08:51:06 -0700 (PDT)
From: [e-mail]
Received: from northrelay02.pok.ibm.com (northrelay02.pok.ibm.com [9.117.200.22]) by e4.ny.us.ibm.com (8.9.3/8.9.3) with ESMTP id LAA46204; Wed, 12 Jul 2000 11:53:04 -0400
Received: from D51MTA04.pok.ibm.com (d51mta04.pok.ibm.com [9.117.200.32]) by northrelay02.pok.ibm.com (8.8.8m3/NCO v4.92) with SMTP id LAA178132; Wed, 12 Jul 2000 11:53:01 -0400
Received: by D51MTA04.pok.ibm.com(Lotus SMTP MTA v4.6.5  (863.2 5-20-1999))  id 8525691A.00573C21 ; Wed, 12 Jul 2000 11:52:50 -0400
X-Lotus-FromDomain: IBMUS
To: [e-mail]
cc: [e-mail]
Message-ID: <[e-mail]>
Date: Wed, 12 Jul 2000 11:52:42 -0400
Subject: RE: Signing what you don't understand: a practical example
Mime-Version: 1.0
Content-type: text/plain; charset=us-ascii
Content-Disposition: inline

     An RP will trust the presence of such a high-assurance indicator above
the value of an ordinary digital signature only if he is credibly assured
that the indicator's presence actually proves something.  The natural way
to do this is to indicate the presence of a high-assurance device in the
certificate.  If no such indication is present, the RP has no reason to
believe that the attack Aram describes is very difficult - so he won't
trust a signature with the indicator any more than one without it.

          Tom Gindin


"denis bider" <[e-mail]> on 07/12/2000 11:08:21 AM

Please respond to <[e-mail]>

To:   Tom Gindin/Watson/IBM@IBMUS
cc:   <[e-mail]>
Subject:  RE: Signing what you don't understand: a practical example



Hello Tom,

I don't quite understand why such an indicator within a certificate would
be
needed for this technique to have any real use.

The current possible outcomes of a standard signature verification process
are:
- valid, and
- invalid.

What I am proposing is, essentially, that the possible range of returns be
widened to at least:
- valid (== technically and semantically valid)
- valid but not binding (== technically valid, semantically invalid)
- invalid (== technically and semantically invalid)

The security device I was mentioning was only intended to show a practical
situation where the widened range of possible returns, as outlined above,
WILL be needed sooner or later. Ie, it is just *a* usage scenario; it is
not
an attempt to encompass all possible usage scenarios.


Regards,

denis


-----Original Message-----
From: [e-mail] [mailto:[e-mail]]
Sent: 12. julij 2000 03:11
To: Aram Perez
Cc: [e-mail]
Subject: Re: Signing what you don't understand: a practical example


     For Denis' technique to have any real use, there would also need to be
an indicator somewhere in the certificate that "the private key of this
pair is held in a Bider-compliant smart card".  Doing that (and it could go
into any of several extensions, or a new one could be defined), is
considerably easier than changing the signature format.
     For PKCS 1.5, of course, he could change that format just by defining
a hash function parameter value (if PKCS #1 would agree), or a new OID for
SHA-1 (SHA1OnBiderCard ??).  Getting verifiers to understand either of
these might be interesting, though.

          Tom Gindin

Aram Perez <[e-mail]> on 07/11/2000 08:44:48 PM

To:   [e-mail]
cc:
Subject:  Re: Signing what you don't understand: a practical example



Hi Denis,

[snip]
> 2. Encode the algorithm ID for the hash function and the hash value into
an
> ASN.1 value of type DigestInfo (see Section 11) with the Distinguished
> Encoding Rules (DER), where the type DigestInfo has the syntax
>
> DigestInfo ::= SEQUENCE {
> digestAlgorithm AlgorithmIdentifier,
> digest OCTET STRING,
> flags BIT STRING OPTIONAL
> }
>
> Meaning of 'flags' bits:
> first bit: content-not-understood
> subsequent bits: not defined at this time
>
> In case the value of the first bit of 'flags' is 0, the 'flags' field may
> be omitted for purposes of backward compatibility. However, this is not
> recommended. If omitted, the interpretation of the 'flags' field is
> application-dependent.
>
> The first field identifies the hash function and the second contains the
> hash value. Let T be the DER encoding.
>
> 3. If emLen is less than ||T|| + 10 then output "intended encoded message
> length too short".
>
> 4. Generate an octet string PS consisting of emLen-||T||-2 octets with
value
> FF (hexadecimal). The length of PS will be at least 8 octets.
>
> 5. Concatenate PS, the DER encoding T, and other padding to form the
encoded
> message EM as
>
> EM = 01 || PS || 00 || T
>
> 6. Output EM.

[Warning: Long sentence ahead.] If you received a signed message from me,
formatted per your instructions and with the flags parameter, how would you
know that I was using the security device you have described, that the
message was displayed on that device and that I really understood what I
signed? I can easily create an identical message on my insecure PC with
today's smartcards or just with the right software.

Regards,
Aram Perez




Received: from mail.brokat.de ([212.9.175.131]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id IAA21916 for <[e-mail]>; Wed, 12 Jul 2000 08:39:43 -0700 (PDT)
Received: by mail.brokat.de (Smail3.2.0.111/mail.brokat.de) via LF.net GmbH Internet Services via remoteip 172.17.6.61 via remotehost brokat.com with esmtp for mail.imc.org id m13COfM-005lMGC; Wed, 12 Jul 2000 17:43:16 +0200 (CEST)
Message-ID: <[e-mail]>
Date: Wed, 12 Jul 2000 17:42:23 +0200
From: Malte Borcherding <[e-mail]>
Organization: BROKAT Infosystems AG
X-Mailer: Mozilla 4.73 [en] (WinNT; U)
X-Accept-Language: en,de
MIME-Version: 1.0
To: [e-mail]
CC: [e-mail]
Subject: Re: Signing what you don't understand: a practical example
References: <000b01bfec13$0546e810$0201010a@intergalactic>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Denis,

as pointed out by others in previous mails, the key usage extension in a
certificate is currently the usual place to carry the information you require.
In case this is not enough (say, because you want to use the same key pair for
different purposes), you might want to include a signature policy into your
signature. Such a concept is described in the ETSI Standard ES 201733, available
at http://www.etsi.org/SEC/el-sign.htm , or as Internet-Draft at
http://www.ietf.org/internet-drafts/draft-ietf-smime-esformats-00.txt . Such a
policy can carry information about the commitment type and the signature
environment. Apart from that, it can also contain information on how the
signature has to be verified in order to be regarded as valid.  Furthermore,
this standard also binds the certificate cryptographically to the signature,
such that it is clear which certificate is meant to be used for verification.

As for the question of a secure signature apparatus including a secure viewer,
this has been (and still is) subject to heavy debate in the various standards
related to legally binding digital signatures. Bottom line: There is currently
no practical solution for a highly secure display component which at the same
time can be used for many different document formats and has any chance of
widespread use. Some mobile devices come close to the required security, as they
are generally less subject to malicious attacks. Lack of technical security has
to be met by processes, like educating users on how to keep theit PCs free of
viruses.

Malte


denis bider wrote:
> 
> Hello Tom,
> 
> I don't quite understand why such an indicator within a certificate would be
> needed for this technique to have any real use.
> 
> The current possible outcomes of a standard signature verification process
> are:
> - valid, and
> - invalid.
> 
> What I am proposing is, essentially, that the possible range of returns be
> widened to at least:
> - valid (== technically and semantically valid)
> - valid but not binding (== technically valid, semantically invalid)
> - invalid (== technically and semantically invalid)
> 
> The security device I was mentioning was only intended to show a practical
> situation where the widened range of possible returns, as outlined above,
> WILL be needed sooner or later. Ie, it is just *a* usage scenario; it is not
> an attempt to encompass all possible usage scenarios.
> 
> Regards,
> 
> denis
> 
> -----Original Message-----
> From: [e-mail] [mailto:[e-mail]]
> Sent: 12. julij 2000 03:11
> To: Aram Perez
> Cc: [e-mail]
> Subject: Re: Signing what you don't understand: a practical example
> 
>      For Denis' technique to have any real use, there would also need to be
> an indicator somewhere in the certificate that "the private key of this
> pair is held in a Bider-compliant smart card".  Doing that (and it could go
> into any of several extensions, or a new one could be defined), is
> considerably easier than changing the signature format.
>      For PKCS 1.5, of course, he could change that format just by defining
> a hash function parameter value (if PKCS #1 would agree), or a new OID for
> SHA-1 (SHA1OnBiderCard ??).  Getting verifiers to understand either of
> these might be interesting, though.
> 
>           Tom Gindin
> 
> Aram Perez <[e-mail]> on 07/11/2000 08:44:48 PM
> 
> To:   [e-mail]
> cc:
> Subject:  Re: Signing what you don't understand: a practical example
> 
> Hi Denis,
> 
> [snip]
> > 2. Encode the algorithm ID for the hash function and the hash value into
> an
> > ASN.1 value of type DigestInfo (see Section 11) with the Distinguished
> > Encoding Rules (DER), where the type DigestInfo has the syntax
> >
> > DigestInfo ::= SEQUENCE {
> > digestAlgorithm AlgorithmIdentifier,
> > digest OCTET STRING,
> > flags BIT STRING OPTIONAL
> > }
> >
> > Meaning of 'flags' bits:
> > first bit: content-not-understood
> > subsequent bits: not defined at this time
> >
> > In case the value of the first bit of 'flags' is 0, the 'flags' field may
> > be omitted for purposes of backward compatibility. However, this is not
> > recommended. If omitted, the interpretation of the 'flags' field is
> > application-dependent.
> >
> > The first field identifies the hash function and the second contains the
> > hash value. Let T be the DER encoding.
> >
> > 3. If emLen is less than ||T|| + 10 then output "intended encoded message
> > length too short".
> >
> > 4. Generate an octet string PS consisting of emLen-||T||-2 octets with
> value
> > FF (hexadecimal). The length of PS will be at least 8 octets.
> >
> > 5. Concatenate PS, the DER encoding T, and other padding to form the
> encoded
> > message EM as
> >
> > EM = 01 || PS || 00 || T
> >
> > 6. Output EM.
> 
> [Warning: Long sentence ahead.] If you received a signed message from me,
> formatted per your instructions and with the flags parameter, how would you
> know that I was using the security device you have described, that the
> message was displayed on that device and that I really understood what I
> signed? I can easily create an identical message on my insecure PC with
> today's smartcards or just with the right software.
> 
> Regards,
> Aram Perez


Received: from taurus.polito.it (taurus.polito.it [130.192.3.60]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id IAA21030 for <[e-mail]>; Wed, 12 Jul 2000 08:26:41 -0700 (PDT)
Received: (qmail 21257 invoked from network); 12 Jul 2000 15:25:35 -0000
Received: from lioy.polito.it (HELO polito.it) (130.192.3.33) by taurus.polito.it with SMTP; 12 Jul 2000 15:25:35 -0000
Message-ID: <[e-mail]>
Date: Wed, 12 Jul 2000 17:26:57 +0200
From: Antonio Lioy <[e-mail]>
Organization: Politecnico di Torino
X-Mailer: Mozilla 4.6 [en] (Win95; U)
X-Accept-Language: en
MIME-Version: 1.0
To: [e-mail]
Subject: Re: Signing what you don't understand: a practical example
References: <000b01bfec13$0546e810$0201010a@intergalactic>
Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------msDE0460E7166015EA2C8A0161"

This is a cryptographically signed message in MIME format.

--------------msDE0460E7166015EA2C8A0161
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

I think that what is being discussed in this thread is all
about the meaning (i.e. semantics) of a technically valid
digital signature. This could be easily achived by the
"signature policy" extension that is requested by the ETSI
draft for European electronic documents:

http://www.etsi.org/technicalactiv/ElectronicSignatures.htm

As e-documents will require much more extensions than just
the semantics of the signature (e.g. also the timestamping,
the role of the signer, the location) it is better to define
all of them in a general framework (such as the one above)
rather than to insert bit and pieces in various formats that
are then hard to mix up and reconcile. I would therefore
prefer to have a plain signature format (i.e. just the data
and its signature = public-key encrypted digest) and then
build on top of that to get more services (such as the
signature semantics that somebody is advocating here).

Just my 2c,

Antonio Lioy
--------------msDE0460E7166015EA2C8A0161
Content-Type: application/x-pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: S/MIME Cryptographic Signature

MIIP9gYJKoZIhvcNAQcCoIIP5zCCD+MCAQExCzAJBgUrDgMCGgUAMAsGCSqGSIb3DQEHAaCC
DjIwggT5MIID4aADAgECAgEBMA0GCSqGSIb3DQEBBAUAMGUxCzAJBgNVBAYTAklUMR4wHAYD
VQQKExVQb2xpdGVjbmljbyBkaSBUb3Jpbm8xNjA0BgNVBAMTLVBvbGl0ZWNuaWNvIGRpIFRv
cmlubyBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTAeFw0wMDAxMTgxMjAwMDBaFw0wMDEyMzEx
MjAwMDBaMHcxCzAJBgNVBAYTAklUMR4wHAYDVQQKExVQb2xpdGVjbmljbyBkaSBUb3Jpbm8x
MTAvBgNVBAsTKERpcGFydGltZW50byBkaSBBdXRvbWF0aWNhIGUgSW5mb3JtYXRpY2ExFTAT
BgNVBAMTDEFudG9uaW8gTGlveTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAyISyZRZK
mGqFfcdjcKJ7NegAKLDiLdlO9UK1pN4vJzGmrBtUqV6bKkfslCPCfRsULdpr4NgPwanqTxJn
WGS9TR/zV9fHv4cxDTLq/n49UnXI3nP0eTpHOi+y4D1VkTjI+1t6d0qggUIapxxXmfBpqP7R
/uxk2x4q07YxTBSjIoUCAwEAAaOCAiQwggIgMB8GA1UdIwQYMBaAFEbcLc3EM3GcgWtDoYzB
7HR2zgt7MB0GA1UdDgQWBBTHkFr7ivGI44U5A3zluh0EQ6nOLTAOBgNVHQ8BAf8EBAMCBPAw
gdoGA1UdIASB0jCBzzBDBgorBgEEAakHAQEBMDUwMwYIKwYBBQUHAgEWJ2h0dHA6Ly93d3cu
ZXVyb3BraS5vcmcvY2Evcm9vdC9jcHMvMS4xLzBBBgorBgEEAakHAgEBMDMwMQYIKwYBBQUH
AgEWJWh0dHA6Ly93d3cuZXVyb3BraS5vcmcvY2EvaXQvY3BzLzEuMS8wRQYKKwYBBAGVYgEC
ATA3MDUGCCsGAQUFBwIBFilodHRwOi8vd3d3LmV1cm9wa2kub3JnL2NhL3BvbGl0by9jcHMv
MS4xLzAZBgNVHREEEjAQgQ5saW95QHBvbGl0by5pdDAMBgNVHRMBAf8EAjAAMDAGA1UdHwQp
MCcwJaAjoCGGH2h0dHA6Ly9jYS5wb2xpdG8uaXQvY3JsL2NybC5kZXIwgZUGCWCGSAGG+EIB
DQSBhxaBhElzc3VlZCB1bmRlciBwb2xpY2llczoKIGh0dHA6Ly93d3cuZXVyb3BraS5vcmcv
Y2Evcm9vdC9jcHMvMS4xLwogaHR0cDovL3d3dy5ldXJvcGtpLm9yZy9jYS9pdC9jcHMvMS4x
LwogaHR0cDovL2NhLnBvbGl0by5pdC9jcHMvMi4xLzANBgkqhkiG9w0BAQQFAAOCAQEAGi5A
GJb2EoR6BpTSunNG/dPkEJ94RSzXiBXwomvdXtWZHQFeCUEsV07j+Imoqtrsm96Ub9Uhv+/A
2CBGvrsk2NhPXUQlcAvFs6KCYjXZK6B/2EyLKkm+6sW1sG2rmkQZmypQHodgwsY2/sHkLqPf
nDxokzsBj4uurnS26yEfQT+8EbcNOEyLeDdsQhgMFoTGFJON6zT6wBHflA7mOWzUQ1PJF8/Z
M2zDuq5AklIGcvF0gMaBJMQNSvQf9RMchxIoFVCGYqbmIOorADjXytE2qDtv9hPa/uq6IuU4
d/qcdPTgrGnzgnAlvE6uHnqo18EOA8koAKsrs5R23Jn7JGw4vDCCBN4wggPGoAMCAQICAQEw
DQYJKoZIhvcNAQEEBQAwUTELMAkGA1UEBhMCSVQxEDAOBgNVBAoTB0V1cm9QS0kxMDAuBgNV
BAMTJ0V1cm9QS0kgSXRhbGlhbiBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTAcFw0wMDAxMTUx
MzUzMzdaFwswMTEyMzEwMDAwWjBlMQswCQYDVQQGEwJJVDEeMBwGA1UEChMVUG9saXRlY25p
Y28gZGkgVG9yaW5vMTYwNAYDVQQDEy1Qb2xpdGVjbmljbyBkaSBUb3Jpbm8gQ2VydGlmaWNh
dGlvbiBBdXRob3JpdHkwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQD+kQn+Hxvh
SJQs/5y7IdbpVg6+1yXgJ4l6Nguz7InoYZEcG2KBGPhunjalAmQ/DX8xovdQ8lx6nv49M5Xm
toMPoYsqe9ZoJhKc3sBiOTFpSp4noP8uzc+muM/95i5VMRtRSjUQB1rhmJ91y4sDenlMhZmd
Yb9Qtg57ggseOU5vDK39bSY4VcMg4Ang8jsOZnApVdmPsuS78Up1PsT4dWvqaRDE+CKXCpyr
9lKIot0kw3Tjc0wrixAV0TGH4IeCKeeUp6kk7sTbLvjMN7NPufwZgJUqcGvjtY2A4nWXJ94v
F6cK8zs39wBBVesa8saaeCIlTbjCjYXF0fazakgWY92hAgMBAAGjggGtMIIBqTAfBgNVHSME
GDAWgBSSQLydgXtL7H3j5uZ042HNGjYHqTAdBgNVHQ4EFgQURtwtzcQzcZyBa0OhjMHsdHbO
C3swDgYDVR0PAQH/BAQDAgH+MIGTBgNVHSAEgYswgYgwQwYKKwYBBAGpBwEBATA1MDMGCCsG
AQUFBwIBFidodHRwOi8vd3d3LmV1cm9wa2kub3JnL2NhL3Jvb3QvY3BzLzEuMS8wQQYKKwYB
BAGpBwIBATAzMDEGCCsGAQUFBwIBFiVodHRwOi8vd3d3LmV1cm9wa2kub3JnL2NhL2l0L2Nw
cy8xLjEvMA8GA1UdEwEB/wQFMAMBAf8wOQYDVR0fBDIwMDAuoCygKoYoaHR0cDovL3d3dy5l
dXJvcGtpLm9yZy9jYS9pdC9jcmwvY3JsLmRlcjB1BglghkgBhvhCAQ0EaBZmSXNzdWVkIHVu
ZGVyIHBvbGljaWVzOgogaHR0cDovL3d3dy5ldXJvcGtpLm9yZy9jYS9yb290L2Nwcy8xLjEv
CiBodHRwOi8vd3d3LmV1cm9wa2kub3JnL2NhL2l0L2Nwcy8xLjEvMA0GCSqGSIb3DQEBBAUA
A4IBAQCdIU0f6e4lWV8FHDj9Cdv/7YUqSx0JgcGXR22lnDkC+ouJMJ1lAsouuqxawA6pf+M9
KEUwOC6oEaF0K9GTY+BIddZbBKMfsUy5IiV9DOC7qwTfhm30cXLGjdPqx9bSxRnx/oz4lo33
FRQQd7OpsAL94fK+M23g6RRF49DxFb5L9bX2ube9ss6jyCWTxj/nwnNaadZRZzTRPawA9bKZ
XkhzLTs/iC+Rvfy6sp5n4t1Gq5paD2j6GIIIKQK6Iwwy3FemaxLxzFmU3Xa3wBddwGEP6EUP
v6y7kceldQP9sqfaKHz8mpzOycBi1PGLUgJVjbU7ubNpg9ZFRLYGbHbc6GKrMIIETzCCAzeg
AwIBAgIBAzANBgkqhkiG9w0BAQQFADBBMRAwDgYDVQQKEwdFdXJvUEtJMS0wKwYDVQQDEyRF
dXJvUEtJIFJvb3QgQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkwHhcNMDAwMTExMTgzNjI5WhcN
MDExMjMxMTIwMDAwWjBRMQswCQYDVQQGEwJJVDEQMA4GA1UEChMHRXVyb1BLSTEwMC4GA1UE
AxMnRXVyb1BLSSBJdGFsaWFuIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MIIBIjANBgkqhkiG
9w0BAQEFAAOCAQ8AMIIBCgKCAQEA/7PzUFrMRRgJVYlUIyv7OfnEeq+arRzi/69G+6w8kuJz
e3/5LSuQ/OFdOYt5lagbv1f4neINDG2k2Mgt+h5UpEXLg1OXxgPP4JBo4iZYpi8KS7DEkd8n
428E3Pl7QjvVx/LeFi0zDlzUSuGRwzqOah/Hp9q6xjIdnG4xeCDcgmmEW1dzeUa56X8UNAy/
qNgBeN0+aJsD5LbLzsJEMNnIX4YZzv+7Fhb5mgNn/M3MKoNNAGY3la5eYy7P6Pedo/vCeyYd
pfhcEDlYBNdnEMKnsC7AayCjNaJLxaIQntRXbFEj3oSwH/a0X9yNzCE97KnlX+m+C5OamlvR
gkiRLBzLXwIDAQABo4IBQDCCATwwHwYDVR0jBBgwFoAUjNyLsaVKkOdOiHMYPJ3VXn7kss0w
HQYDVR0OBBYEFJJAvJ2Be0vsfePm5nTjYc0aNgepMA4GA1UdDwEB/wQEAwIBxjBOBgNVHSAE
RzBFMEMGCisGAQQBqQcBAQEwNTAzBggrBgEFBQcCARYnaHR0cDovL3d3dy5ldXJvcGtpLm9y
Zy9jYS9yb290L2Nwcy8xLjEvMA8GA1UdEwEB/wQFMAMBAf8wOwYDVR0fBDQwMjAwoC6gLIYq
aHR0cDovL3d3dy5ldXJvcGtpLm9yZy9jYS9yb290L2NybC9jcmwuZGVyMEwGCWCGSAGG+EIB
DQQ/Fj1Jc3N1ZWQgdW5kZXIgcG9saWN5OgogaHR0cDovL3d3dy5ldXJvcGtpLm9yZy9jYS9y
b290L2Nwcy8xLjEvMA0GCSqGSIb3DQEBBAUAA4IBAQBR6o4zIMOxhKXGFYxDTbu+Jxmh/i/p
EH25kahS5SfFDtclgm/6dfqH6UQEKH7V1yfrhNNGOogVHe3b5m8FsrEf8Oyzr1+vlUVzC0m8
VpEzvyN6PqbwMSsaMP77xlSRe+6zB3iD2h3szHe95ATbML3pz2BDatPVh5ubGUh0LTEwOQkp
2rTn4/K7lUvlMw61X8+lpUtd2tLTGLLEUgcLMrGgZwG+csZ58TdFGGD6pNXyE/lgpWdqFlqH
vqtXoRey1JIj1pZ4xzsqWlUTNFXncSOBJElotbo8aFd3hT8IjdSaiwCqiyQ33V8EMVsQXIpw
NcOFQY7B49bCxpaY7onrGacoMYIBjDCCAYgCAQEwajBlMQswCQYDVQQGEwJJVDEeMBwGA1UE
ChMVUG9saXRlY25pY28gZGkgVG9yaW5vMTYwNAYDVQQDEy1Qb2xpdGVjbmljbyBkaSBUb3Jp
bm8gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkCAQEwCQYFKw4DAhoFAKB6MBgGCSqGSIb3DQEJ
AzELBgkqhkiG9w0BBwEwGwYJKoZIhvcNAQkPMQ4wDDAKBggqhkiG9w0DBzAcBgkqhkiG9w0B
CQUxDxcNMDAwNzEyMTUyNjU3WjAjBgkqhkiG9w0BCQQxFgQUzc02Dq6iWjwfQhKZmpHnu32Z
mTcwDQYJKoZIhvcNAQEBBQAEgYBF1x1tjRzgqeG7H8nchHdaLcewo+x1D7d6KziQZqg9fFAc
KuWQsoJQB+BLmaLDuaAXwjWqJin2cmWsPtI6Q9tACjyvKWh6wa2HW0gZXxun2x3sQ9NE5KoL
ASnujrkUbs9hwkWnJN84Gto/+diAxAfZ6MoBoQdUtxQuFEFqJ/pxUw==
--------------msDE0460E7166015EA2C8A0161--



Received: from levitator.1div0.com ([213.250.43.61]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id IAA20308 for <[e-mail]>; Wed, 12 Jul 2000 08:06:19 -0700 (PDT)
Received: from intergalactic ([10.1.1.2]) by levitator.1div0.com (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with SMTP id QAA22860; Wed, 12 Jul 2000 16:54:22 +0200
Reply-To: <[e-mail]>
From: "denis bider" <[e-mail]>
To: <[e-mail]>
Cc: <[e-mail]>
Subject: RE: Signing what you don't understand: a practical example
Date: Wed, 12 Jul 2000 17:08:21 +0200
Message-ID: <000b01bfec13$0546e810$0201010a@intergalactic>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2910.0)
In-Reply-To: <[e-mail]>
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700

Hello Tom,

I don't quite understand why such an indicator within a certificate would be
needed for this technique to have any real use.

The current possible outcomes of a standard signature verification process
are:
- valid, and
- invalid.

What I am proposing is, essentially, that the possible range of returns be
widened to at least:
- valid (== technically and semantically valid)
- valid but not binding (== technically valid, semantically invalid)
- invalid (== technically and semantically invalid)

The security device I was mentioning was only intended to show a practical
situation where the widened range of possible returns, as outlined above,
WILL be needed sooner or later. Ie, it is just *a* usage scenario; it is not
an attempt to encompass all possible usage scenarios.

Regards,

denis


-----Original Message-----
From: [e-mail] [mailto:[e-mail]]
Sent: 12. julij 2000 03:11
To: Aram Perez
Cc: [e-mail]
Subject: Re: Signing what you don't understand: a practical example


     For Denis' technique to have any real use, there would also need to be
an indicator somewhere in the certificate that "the private key of this
pair is held in a Bider-compliant smart card".  Doing that (and it could go
into any of several extensions, or a new one could be defined), is
considerably easier than changing the signature format.
     For PKCS 1.5, of course, he could change that format just by defining
a hash function parameter value (if PKCS #1 would agree), or a new OID for
SHA-1 (SHA1OnBiderCard ??).  Getting verifiers to understand either of
these might be interesting, though.

          Tom Gindin

Aram Perez <[e-mail]> on 07/11/2000 08:44:48 PM

To:   [e-mail]
cc:
Subject:  Re: Signing what you don't understand: a practical example



Hi Denis,

[snip]
> 2. Encode the algorithm ID for the hash function and the hash value into
an
> ASN.1 value of type DigestInfo (see Section 11) with the Distinguished
> Encoding Rules (DER), where the type DigestInfo has the syntax
>
> DigestInfo ::= SEQUENCE {
> digestAlgorithm AlgorithmIdentifier,
> digest OCTET STRING,
> flags BIT STRING OPTIONAL
> }
>
> Meaning of 'flags' bits:
> first bit: content-not-understood
> subsequent bits: not defined at this time
>
> In case the value of the first bit of 'flags' is 0, the 'flags' field may
> be omitted for purposes of backward compatibility. However, this is not
> recommended. If omitted, the interpretation of the 'flags' field is
> application-dependent.
>
> The first field identifies the hash function and the second contains the
> hash value. Let T be the DER encoding.
>
> 3. If emLen is less than ||T|| + 10 then output "intended encoded message
> length too short".
>
> 4. Generate an octet string PS consisting of emLen-||T||-2 octets with
value
> FF (hexadecimal). The length of PS will be at least 8 octets.
>
> 5. Concatenate PS, the DER encoding T, and other padding to form the
encoded
> message EM as
>
> EM = 01 || PS || 00 || T
>
> 6. Output EM.

[Warning: Long sentence ahead.] If you received a signed message from me,
formatted per your instructions and with the flags parameter, how would you
know that I was using the security device you have described, that the
message was displayed on that device and that I really understood what I
signed? I can easily create an identical message on my insecure PC with
today's smartcards or just with the right software.

Regards,
Aram Perez




Received: from dfw7-1.relay.mail.uu.net (dfw7-1.relay.mail.uu.net [199.171.54.106]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id HAA19697 for <[e-mail]>; Wed, 12 Jul 2000 07:36:42 -0700 (PDT)
Received: from xedia.com by dfw7sosrv11.alter.net with SMTP  (peer crosschecked as: madway.xedia.com [198.202.232.199]) id QQixnm04800; Wed, 12 Jul 2000 14:38:27 GMT
Received: from tonga.xedia.com by xedia.com (4.1/SMI-4.1) id AA27555; Wed, 12 Jul 00 10:34:35 EDT
Received: by tonga.xedia.com (SMI-8.6/SMI-SVR4) id KAA01703; Wed, 12 Jul 2000 10:38:25 -0400
From: Paul Koning <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-Id: <[e-mail]>
Date: Wed, 12 Jul 2000 10:38:24 -0400 (EDT)
To: [e-mail]
Cc: [e-mail], [e-mail]
Subject: Re: Current signature formats insufficient
References: <000901bfeb64$38642f50$0201010a@intergalactic> <013901bfeba8$419218f0$[e-mail]>
X-Mailer: VM 6.72 under 21.1 (patch 9) "Canyonlands" XEmacs Lucid

>>>>> "Simon" == Simon McMahon <[e-mail]> writes:

 Simon> Hi all, My 2c worth.

 Simon> You should look to the analog-signature as an analogy. It's
 Simon> the content of what you sign that includes the terms and
 Simon> therefore the extent to which the signer is bound. Carelessly
 Simon> given signatures should be legally binding, otherwise
 Simon> ignorance will be used as a defense for repudiation, and only
 Simon> fraudulently or forcefully obtained signatues should be able
 Simon> to be sucessfully repudiated by recourse to the law and
 Simon> courts.

I think that's a fine analogy, and it also serves to illustrate the
issue that Denis is concerned about.

With classic signatures, the norm is that you see what you sign.  (One
exception is the standard story about the overworked executive who's
handed a stack of 50 memos to sign, with little yellow tabs marking
"here's the spot" and someone slips in a ringer.  Don't know how
common that is outside novels.)

With digital signatures, the norm is that you have no idea.  As Denis
mentioned, current smartcards have no way of showing you what you're
signing.  If you use an application that signs things (like a mailer)
the binding is a little better.  There you still have to trust that
the text you entered is in fact what's being signed -- in other words,
that the program is trustworthy, correct, and unsubverted by trojan
horses.  One good reason for using PGP, because you can check this,
unlike closed source mailers.

The new (USA) digital signature law scares me, because it makes no
sense so long as digital signature mechanisms continue to provide no
meaningful way for the user to know what is being signed.  

	   paul


Received: from hal9000.vguard.com (vguard.com [192.117.162.2]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id GAA18117 for <[e-mail]>; Wed, 12 Jul 2000 06:24:39 -0700 (PDT)
Message-Id: <[e-mail]>
Received: from MGM (DEMONA [192.117.162.76]) by hal9000.vguard.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21) id 3Y346R17; Wed, 12 Jul 2000 16:27:13 +0200
X-MG-RegisteredMail: ReturnReceipt
From: Raviv Karnieli<[e-mail]>
To: "'[e-mail]'"<[e-mail]>
Cc: [e-mail]
Subject: RE: Signing what you don't understand
Date: Wed, 12 JUL 2000 14:22:00 -0000 
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="<<-- MailGuardian RTF boundary -->>"

This is a multi-part message in MIME format.

--<<-- MailGuardian RTF boundary -->>
Content-Type: text/plain; charset="ISO-8859-8"
Content-Transfer-Encoding: base64

RGVuaXMsDQoNCkkgYWdyZWUgd2l0aCB3aGF0IHlvdSB3cm90ZSBhbmQgd2FudCB0byBhZGQg
YW5vdGhlciBhc3BlY3Qgb2YgdGhlIHNhbWUgaXNzdWUuDQpTaWduYXR1cmVzIG1heSBiZSBh
cHBsaWVkIGF1dG9tYXRpY2FsbHkgKGkuZS4gd2hlbiBJIHNpZ24gbXkgb3V0Z29pbmcgZS1t
YWlsLCB3aGVuIEkgbG9nIGludG8gYSB3ZWIgc2l0ZSBvciB3aGVuIG15IG1haWxlciBzZW5k
cyByZXR1cm4gcmVjZWlwdHMpLiBJIHN1cmUgd2FudCB0byBiZSBub3RpZmllZCBpbiBhZHZh
bmNlIChhbmQgcmVhZCB2ZXJ5IGNhcmVmdWxseSB3aGF0IEkgc2lnbikgd2hlbiBJIHNpZ24g
YSBjb250cmFjdCBvciBhIGJ1c2luZXNzIHRyYW5zYWN0aW9uLg0KVGh1cywgaXQgaXMgbm90
IGVub3VnaCBmb3IgdGhlIHNpZ25hdHVyZSB0byBpbmNsdWRlIHRoZSBiaW5kaW5nIGxldmVs
LCBpdCBzaG91bGQgYWxzbyBiZSBzdXBwb3J0ZWQgYnkgdGhlIHZhcmlvdXMgcHJvdG9jb2xz
LCB0byBub3RpZnkgbXkgYXBwbGljYXRpb25zIHdoYXQgbGV2ZWwgb2YgYmluZGluZyBteSBz
aWduYXR1cmUgY2F1c2UuDQoNClJhdml2IEthcm5pZWxpIC0gQ1RPDQpWYW5ndWFyZCBTZWN1
cml0eSBUZWNobm9sb2dpZXMgTHRkLg0KVGVsLiArOTcyLTQtOTg5LTEzMTEgICAgICAgRmF4
ICs5NzItNC05ODktMTMyMg0Kd3d3LnZndWFyZC5jb20gICAgICAgICAgICAgcmF2aXZAdmd1
YXJkLmNvbQ0KDQpUaGlzIG1lc3NhZ2UgbGVmdCBteSBjb21wdXRlciBzZWN1cmVkIHNpbmNl
IEmSbSB1c2luZyANCk1BSUxndWFyZGlhbiBFbnRlcnByaXNlIHRoZSBmaXJzdCB0cnVlIGVu
ZCB0byBlbmQgZW50ZXJwcmlzZSBlLW1haWwgc2VjdXJpdHkgc29sdXRpb24gdGhhdCBpcyBw
b2xpY3kgYmFzZWQsIGNlbnRyYWxseSBtYW5hZ2VkIGFuZCB0b3RhbGx5IHRyYW5zcGFyZW50
IHRvIHRoZSBlbmQgdXNlcnMuDQoNCllvdSBjYW4gZ2V0IHlvdXIgb3duIGZyZWUgZXZhbHVh
dGlvbiBjb3B5IG9mIE1BSUxndWFyZGlhbiANCmF0IGh0dHA6Ly93d3cudmd1YXJkLmNvbS9w
cm9kLmFzcA0KDQoNCg0KLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZyb206IGRlbmlz
IGJpZGVyIFttYWlsdG86ZGVuaXMuYmlkZXJAZ2xvYmVyYS5jb21dDQpTZW50OiBUdWVzZGF5
LCBKdWx5IDExLCAyMDAwIDc6NDYgUE0NClRvOiBpZXRmLXBraXhAaW1jLm9yZw0KU3ViamVj
dDogU2lnbmluZyB3aGF0IHlvdSBkb24ndCB1bmRlcnN0YW5kDQoNCg0KVGhlIG1vc3QgaW1w
b3J0YW50IHBvaW50IG9mIG15IHByZXZpb3VzIG1lc3NhZ2Ugd2FzIGJ1cmllZCB1bmRlciBh
IHBpbGUgb2YNCm90aGVyIHN0dWZmLCBzbyBJIGFtIHJlcGVhdGluZyBpdCBoZXJlOg0KDQoN
Ckl0IGlzIG15IHByb3Bvc2FsIHRoYXQgYSBzaWduYXR1cmUgZm9ybWF0IGlzIGRlc2lnbmVk
IHdoaWNoIHdpbGwgYWxsb3cgYW4NCmVudGl0eSB0byBzYXk6ICJJIHNpZ25lZCB0aGlzIGRh
dGEsIGJ1dCBJIGRpZG4ndCB1bmRlcnN0YW5kIHdoYXQgSSBzaW
duZWQuDQpZb3UgYXJlIGZy
ZWUgdG8gdXNlIHRoaXMgc2lnbmF0dXJlIGFzIHByb29mIHRoYXQgSSBwb3NzZXNzIGEgY2Vy
dGFpbiBwcml2YXRlDQprZXksIGJ1dCB0aGlzIGlzIGFsc28gdGhlIG9ubHkgcHVycG9zZSBm
b3Igd2hpY2ggdGhpcyBzaWduYXR1cmUgY2FuIGJlDQp1c2VkLiINCg0KQ3VycmVudGx5LCBJ
IGFtIG5vdCBhd2FyZSBvZiBhIHNpZ25hdHVyZSBmb3JtYXQgdGhhdCBhbGxvd3MgYW4gZW50
aXR5IHRvIGRvDQp0aGF0LiBBbmQgYmVjYXVzZSB0aGVyZSBpcyBubyBzdWNoIHNpZ25hdHVy
ZSBmb3JtYXQsIHBlb3BsZSBhcmUgY29uc3RhbnRseQ0KZ29pbmcgYWhlYWQgYW5kIHNpZ25p
bmcgZGF0YSB0aGV5IGRvbid0IHVuZGVyc3RhbmQgYW55d2F5ISBTbWFydCBjYXJkcywgYXMN
CmN1cnJlbnRseSB1c2VkLCBhcmUgYSBwZXJmZWN0IGV4YW1wbGUgb2YgdGhpcyBiZWhhdmlv
cigqKS4NCg0KSSBhbSBjb252aW5jZWQgdGhhdCBhIHNpZ25hdHVyZSBmb3JtYXQgaXMgbmVl
ZGVkIHRoYXQgd2lsbCBhbGxvdyBhbiBlbnRpdHkNCnRvIHNhZmVseSBzaWduIGluZm9ybWF0
aW9uIHRoYXQgaXQgZG9lcyBub3QgdW5kZXJzdGFuZC4gT3RoZXJ3aXNlLCBwZW9wbGUNCndp
bGwgY29udGludWUgdG8gc2lnbiBzdWNoIGluZm9ybWF0aW9uIHdpdGggYSBwcm90b2NvbCB0
aGF0IEJJTkRTIHRoZW0gdG8NCndoYXQgdGhleSBoYXZlIHNpZ25lZCwgcmVnYXJkbGVzcyBv
ZiB0aGUgZmFjdCB0aGF0IHRoZXkgYXJlIG5vdCBzdXJlIGFib3V0DQp3aGF0IHRoZXkgYXJl
IHNpZ25pbmcuDQoNCg0KKCopOiBZb3UgbWF5IHRoaW5rIHlvdSBrbm93IHdoYXQgeW91J3Jl
IHNpZ25pbmcsIGJ1dCB0cnVzdCBtZSwgeW91IGRvbid0LiBJdA0KaXMgcHJlcG9zdGVyb3Vz
bHkgZWFzeSB0byB3cml0ZSBhIHZpcnVzIHRoYXQgd2lsbCBjaXJjdW12ZW50IGFueSBzbWFy
dA0KY2FyZCdzIHNlY3VyaXR5IHdpdGhvdXQgYmVpbmcgbm90aWNlZC4gSSB3aWxsIGRvIGl0
IGZvciAkMjUsMDAwOyBhIGNvbGxlZ2UNCnN0dWRlbnQgbmV4dCBkb29yIHdpbGwgZG8gaXQg
Zm9yIGZyZWUu
--<<-- MailGuardian RTF boundary -->>
Content-Type: application/X-MAILguardian-rtf; charset="ISO-8859-8"
Content-Transfer-Encoding: base64

DQp7XHJ0ZjFcYW5zaVxhbnNpY3BnMTI1Mlxmcm9tdGV4dCBcZGVmZjB7XGZv
bnR0YmwNCntcZjBcZnN3aXNzXGZjaGFyc2V0MCBBcmlhbDt9DQp7XGYxXGZtb2Rlcm4gQ291
cmllciBOZXc7fQ0Ke1xmMlxmbmlsXGZjaGFyc2V0MiBTeW1ib2w7fQ0Ke1xmM1xmbW9kZXJu
XGZjaGFyc2V0MCBDb3VyaWVyIE5ldzt9fQ0Ke1xjb2xvcnRibFxyZWQwXGdyZWVuMFxibHVl
MDtccmVkMFxncmVlbjBcYmx1ZTI1NTt9DQpcdWMxXHBhcmRccGxhaW5cZGVmdGFiMzYwIFxm
MFxmczIwIERlbmlzLFxwYXINClxwYXINCkkgYWdyZWUgd2l0aCB3aGF0IHlvdSB3cm90ZSBh
bmQgd2FudCB0byBhZGQgYW5vdGhlciBhc3BlY3Qgb2YgdGhlIHNhbWUgaXNzdWUuXHBhcg0K
U2lnbmF0dXJlcyBtYXkgYmUgYXBwbGllZCBhdXRvbWF0aWNhbGx5IChpLmUuIHdoZW4gSSBz
aWduIG15IG91dGdvaW5nIGUtbWFpbCwgd2hlbiBJIGxvZyBpbnRvIGEgd2ViIHNpdGUgb3Ig
d2hlbiBteSBtYWlsZXIgc2VuZHMgcmV0dXJuIHJlY2VpcHRzKS4gSSBzdXJlIHdhbnQgdG8g
YmUgbm90aWZpZWQgaW4gYWR2YW5jZSAoYW5kIHJlYWQgdmVyeSBjYXJlZnVsbHkgd2hhdCBJ
IHNpZ24pIHdoZW4gSSBzaWduIGEgY29udHJhY3Qgb3IgYSBidXNpbmVzcyB0cmFuc2FjdGlv
bi5ccGFyDQpUaHVzLCBpdCBpcyBub3QgZW5vdWdoIGZvciB0aGUgc2lnbmF0dXJlIHRvIGlu
Y2x1ZGUgdGhlIGJpbmRpbmcgbGV2ZWwsIGl0IHNob3VsZCBhbHNvIGJlIHN1cHBvcnRlZCBi
eSB0aGUgdmFyaW91cyBwcm90b2NvbHMsIHRvIG5vdGlmeSBteSBhcHBsaWNhdGlvbnMgd2hh
dCBsZXZlbCBvZiBiaW5kaW5nIG15IHNpZ25hdHVyZSBjYXVzZS5ccGFyDQpccGFyDQpSYXZp
diBLYXJuaWVsaSAtIENUT1xwYXINClZhbmd1YXJkIFNlY3VyaXR5IFRlY2hub2xvZ2llcyBM
dGQuXHBhcg0KVGVsLiArOTcyLTQtOTg5LTEzMTEgICAgICAgRmF4ICs5NzItNC05ODktMTMy
MlxwYXINCnd3dy52Z3VhcmQuY29tICAgICAgICAgICAgIHJhdml2QHZndWFyZC5jb21ccGFy
DQpccGFyDQpUaGlzIG1lc3NhZ2UgbGVmdCBteSBjb21wdXRlciBzZWN1cmVkIHNpbmNlIElc
JzkybSB1c2luZyBccGFyDQpNQUlMZ3VhcmRpYW4gRW50ZXJwcmlzZSB0aGUgZmlyc3QgdHJ1
ZSBlbmQgdG8gZW5kIGVudGVycHJpc2UgZS1tYWlsIHNlY3VyaXR5IHNvbHV0aW9uIHRoYXQg
aXMgcG9saWN5IGJhc2VkLCBjZW50cmFsbHkgbWFuYWdlZCBhbmQgdG90YWxseSB0cmFuc3Bh
cmVudCB0byB0aGUgZW5kIHVzZXJzLlxwYXINClxwYXINCllvdSBjYW4gZ2V0IHlvdXIgb3du
IGZyZWUgZXZhbHVhdGlvbiBjb3B5IG9mIE1BSUxndWFyZGlhbiBccGFyDQphdCBodHRwOi8v
d3d3LnZndWFyZC5jb20vcHJvZC5hc3BccGFyDQpccGFyDQpccGFyDQpccGFyDQotLS0tLU9y
aWdpbmFsIE1lc3NhZ2UtLS0tLVxwYXINCkZyb206IGRlbmlzIGJpZGVyIFttYWlsdG86ZGVu
aXMuYmlkZXJAZ2xvYmVyYS5jb21dXHBhcg0KU2VudDogVHVlc2RheSwgSnVseSAxMSwgMjAw
MCA3OjQ2IFBNXHBhcg0KVG86IGlldGYtcGtpeEBpbWMub3JnXHBhcg0KU3ViamVjdDogU2ln
bmluZyB3aGF0IHlvdSBkb24ndCB1bmRlcnN0YW5kXHBhcg0KXHBhcg0KXHBhcg0KVGhlIG1v
c3QgaW1wb3J0YW50IHBvaW50IG9mIG15IHByZXZpb3VzIG1lc3NhZ2Ugd2FzIGJ1cmllZCB1
bmRlciBhIHBpbGUgb2ZccGFyDQpvdGhlciBzdHVmZiwgc28gSSBhbSByZXBlYXRpbmcgaXQg
aGVyZTpccGFyDQpccGFyDQpccGFyDQpJdCBpcyBteSBwcm9wb3NhbCB0aGF0IGEgc2lnbmF0
dXJlIGZvcm1hdCBpcyBkZXNpZ25lZCB3aGljaCB3aWxsIGFsbG93IGFuXHBhcg0KZW50aXR5
IHRvIHNheTogIkkgc2lnbmVkIHRoaXMgZGF0YSwgYnV0IEkgZGlkbid0IHVuZGVyc3RhbmQg
d2hhdCBJIHNpZ25lZC5ccGFyDQpZb3UgYXJlIGZyZWUgdG8gdXNlIHRoaXMgc2lnbmF0dXJl
IGFzIHByb29mIHRoYXQgSSBwb3NzZXNzIGEgY2VydGFpbiBwcml2YXRlXHBhcg0Ka2V5LCBi
dXQgdGhpcyBpcyBhbHNvIHRoZSBvbmx5IHB1cnBvc2UgZm9yIHdoaWNoIHRoaXMgc2lnbmF0
dXJlIGNhbiBiZVxwYXINCnVzZWQuIlxwYXINClxwYXINCkN1cnJlbnRseSwgSSBhbSBub3Qg
YXdhcmUgb2YgYSBzaWduYXR1cmUgZm9ybWF0IHRoYXQgYWxsb3dzIGFuIGVudGl0eSB0byBk
b1xwYXINCnRoYXQuIEFuZCBiZWNhdXNlIHRoZXJlIGlzIG5vIHN1Y2ggc2lnbmF0dXJlIGZv
cm1hdCwgcGVvcGxlIGFyZSBjb25zdGFudGx5XHBhcg0KZ29pbmcgYWhlYWQgYW5kIHNpZ25p
bmcgZGF0YSB0aGV5IGRvbid0IHVuZGVyc3RhbmQgYW55d2F5ISBTbWFydCBjYXJkcywgYXNc
cGFyDQpjdXJyZW50bHkgdXNlZCwgYXJlIGEgcGVyZmVjdCBleGFtcGxlIG9mIHRoaXMgYmVo
YXZpb3IoKikuXHBhcg0KXHBhcg0KSSBhbSBjb252aW5jZWQgdGhhdCBhIHNpZ25hdHVyZSBm
b3JtYXQgaXMgbmVlZGVkIHRoYXQgd2lsbCBhbGxvdyBhbiBlbnRpdHlccGFyDQp0byBzYWZl
bHkgc2lnbiBpbmZvcm1hdGlvbiB0aGF0IGl0IGRvZXMgbm90IHVuZGVyc3RhbmQuIE90aGVy
d2lzZSwgcGVvcGxlXHBhcg0Kd2lsbCBjb250aW51ZSB0byBzaWduIHN1Y2ggaW5mb3JtYXRp
b24gd2l0aCBhIHByb3RvY29sIHRoYXQgQklORFMgdGhlbSB0b1xwYXINCndoYXQgdGhleSBo
YXZlIHNpZ25lZCwgcmVnYXJkbGVzcyBvZiB0aGUgZmFjdCB0aGF0IHRoZXkgYXJlIG5vdCBz
dXJlIGFib3V0XHBhcg0Kd2hhdCB0aGV5IGFyZSBzaWduaW5nLlxwYXINClxwYXINClxwYXIN
CigqKTogWW91IG1heSB0aGluayB5b3Uga25vdyB3aGF0IHlvdSdyZSBzaWduaW5nLCBidXQg
dHJ1c3QgbWUsIHlvdSBkb24ndC4gSXRccGFyDQppcyBwcmVwb3N0ZXJvdXNseSBlYXN5IHRv
IHdyaXRlIGEgdmlydXMgdGhhdCB3aWxsIGNpcmN1bXZlbnQgYW55IHNtYXJ0XHBhcg0KY2Fy
ZCdzIHNlY3VyaXR5IHdpdGhvdXQgYmVpbmcgbm90aWNlZC4gSSB3aWxsIGRvIGl0IGZvciAk
MjUsMDAwOyBhIGNvbGxlZ2VccGFyDQpzdHVkZW50IG5leHQgZG9vciB3aWxsIGRvIGl0IGZv
ciBmcmVlLlxwYXINCn0N
--<<-- MailGuardian RTF boundary -->>--



Received: from mta02-svc.ntlworld.com (mta02-svc.ntlworld.com [62.253.162.42]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id FAA15541 for <[e-mail]>; Wed, 12 Jul 2000 05:42:41 -0700 (PDT)
Received: from darxstar ([62.252.197.94]) by mta02-svc.ntlworld.com (InterMail vM.4.01.02.27 201-229-119-110) with SMTP id <20000712134357.CBNE3760.mta02-svc.ntlworld.com@darxstar> for <[e-mail]>; Wed, 12 Jul 2000 13:43:57 +0000
Message-ID: <005001bfebff$27b64df0$cac8fc3e@darxstar>
From: "Christopher Williams" <[e-mail]>
To: <[e-mail]>
Subject: unsubscribe
Date: Wed, 12 Jul 2000 13:45:22 +0100
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.00.2314.1300
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300

unsubscribe



Received: from ietf.org (odin.ietf.org [132.151.1.176]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id DAA08870 for <[e-mail]>; Wed, 12 Jul 2000 03:30:17 -0700 (PDT)
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA15215; Wed, 12 Jul 2000 06:32:11 -0400 (EDT)
Message-Id: <[e-mail]>
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
Cc: [e-mail], [e-mail]
From: [e-mail]
Reply-to: [e-mail]
Subject: I-D ACTION:draft-ietf-pkix-ldap-schema-00.txt
Date: Wed, 12 Jul 2000 06:32:11 -0400
Sender: [e-mail]

--NextPart

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Public-Key Infrastructure (X.509) Working Group of the IETF.

	Title		: Internet X.509 Public Key Infrastructure Additional 
                          LDAP Schema for PKIs and PMIs
	Author(s)	: D. Chadwick
	Filename	: draft-ietf-pkix-ldap-schema-00.txt
	Pages		: 11
	Date		: 11-Jul-00
	
This document describes LDAP schema features in addition to RFC 2587 
that are needed to support a Privilege Management Infrastructure and 
a Public Key Infrastructure.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-pkix-ldap-schema-00.txt

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-ietf-pkix-ldap-schema-00.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt


Internet-Drafts can also be obtained by e-mail.

Send a message to:
	[e-mail].
In the body type:
	"FILE /internet-drafts/draft-ietf-pkix-ldap-schema-00.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.
		
		
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"

--OtherAccess
Content-Type: Message/External-body;
	access-type="mail-server";
	server="[e-mail]"

Content-Type: text/plain
Content-ID:	<[e-mail]>

ENCODING mime
FILE /internet-drafts/draft-ietf-pkix-ldap-schema-00.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-pkix-ldap-schema-00.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID:	<[e-mail]>

--OtherAccess--

--NextPart--




Received: from mail.mtgnet.de (www.mtgnet.de [62.144.85.193]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id AAA28009 for <[e-mail]>; Wed, 12 Jul 2000 00:25:37 -0700 (PDT)
Received: from mtgultra.mtgnet.de (mtgultra [199.99.99.3]) by mail.mtgnet.de (8.9.3/8.9.3) with ESMTP id JAA02711 for <[e-mail]>; Wed, 12 Jul 2000 09:31:09 +0200
Received: from punisher (punisher [199.99.99.27]) by mtgultra.mtgnet.de (8.9.3/8.9.3) with SMTP id JAA18893 for <[e-mail]>; Wed, 12 Jul 2000 09:27:00 +0200 (MET DST)
Message-ID: <000a01bfebd2$b28e6840$[e-mail]>
From: "Thomas Hermann" <[e-mail]>
To: <[e-mail]>
Subject: subscribe
Date: Wed, 12 Jul 2000 09:27:55 +0200
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.00.2014.211
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2014.211


Received: from diablo.OntheNet.com.au (diablo.OntheNet.com.au [203.10.89.2]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id WAA24418 for <[e-mail]>; Tue, 11 Jul 2000 22:37:15 -0700 (PDT)
Received: from msimon (pc3.eracom.com.au [203.144.16.147]) by diablo.OntheNet.com.au (8.9.3/8.9.3) with SMTP id PAA74171; Wed, 12 Jul 2000 15:38:58 +1000 (EST)
Message-ID: <003c01bfebc4$b8fc67d0$[e-mail]>
From: "Simon McMahon" <[e-mail]>
To: <[e-mail]>
Cc: <[e-mail]>
References: <000201bfeb5f$79a796f0$0201010a@intergalactic>
Subject: Re: Current signature formats insufficient
Date: Wed, 12 Jul 2000 15:47:17 +1000
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.00.2314.1300
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300

Hi all,

My 2c worth -

You should look to handwritten (analog ?) signatures as an analogy for what
you are trying to solve here with digital signatures. The technology makes
it easy to mess with the format of signature encodings but laws for
handwritten signatures will migrate easier to digital signatures if the
differences between them are minimised.

Hand written signatures do not vary (colour / size etc.) to imply more or
less intention regarding the content of what was signed. The only way I know
of to boost the non-repudiation value of a signature is to have it witnessed
by some competent authority (a JP). The content of what is signed is what
binds the signer to whatever the contract is about.

Carelessly given signatures, digital or otherwise, should still be binding
otherwise ignorance becomes a defense for repudiating a signature. Only
fraudulently or forcefully obtained signatures should be able to be
repudiated by recourse to the law and the courts.

In my opinion there is no difference between adding some signing intention
indicator into the signature encoding or to the content before it is signed.
Effectively you are marking the content as "void" before signing it so that
its contents become irrelevant. The way content should be marked as legally
"void" may vary according to local laws so there may not be much point
trying to standardise it (yet).

Frank Ballufi's suggestion -
> In the case of an authentication protocol, you could include an OBJECT
> IDENTIFIER or string in the data to be signed to constrain the use of the
> signature. For example:
>
> AuthenticationInfo ::= SEQUENCE {
>    disclaimer UTF8String,
>    nonce      OCTET STRING
> }
>
> Another technique would be to use PKCS #7 authenticated attributes.

This seems to be a good enough way to get the effect you want using current
practise and encodings. I.e no new signature formats are needed.

Dennis wrote :
> Assuming that I have proven sufficiently that such a device is needed and
> that its widespread availability is required, because otherwise we will
> never be able to rid ourselves of the acute need for paper, I now put
forth
> the following theory:
> - Sometimes the device will be used to sign data for authentication; at
> other times, it will be used to sign documents which the user has to
> understand thoroughly before signing.

I'm sure there is no doubt that such a device is required however I dont
think you should be trying to find ways to use private keys that are
intended for non-repudiation for ephemeral signatures anyway. It seems like
a dangerous and unnecessary overloading of these type of keys. You are
trying to solve two problems, non-repudiation and authentication, with one
private key.

Any ambiguity in the use of this device will undermine its non-repudiation
value. Another device or at least another key should be used for the
ephemeral type signatures.

I also think private keys should have their own usage attributes and
implementations shouldn't look for usage attributes for the private key in a
public key certificate since the certifcate and private key do not need to
be stored on the same device and the association between them is not trivial
to check. Usage attributes on private keys can be implementation dependant
since private keys typically stay where they were generated.

Simon McMahon
ERACOM Pty. Ltd.




Received: from prithvi.psi.soft.net (prithvi.psi.soft.net [164.164.48.3]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id VAA20622 for <[e-mail]>; Tue, 11 Jul 2000 21:11:26 -0700 (PDT)
Received: from psi.soft.net ([164.164.48.70]) by prithvi.psi.soft.net (8.9.0/8.9.0) with ESMTP id JAA55510; Wed, 12 Jul 2000 09:36:11 +0500
Message-ID: <[e-mail]>
Date: Wed, 12 Jul 2000 09:44:35 +0530
From: Venkateshwara Reddy A <[e-mail]>
X-Mailer: Mozilla 4.7 [en] (WinNT; I)
X-Accept-Language: en
MIME-Version: 1.0
To: [e-mail], [e-mail]
Subject: Re: Current signature formats insufficient
References: <000d01bfeb3d$113b3ad0$0201010a@intergalactic>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

denis bider wrote:

> If you sign a cryptographic challenge intended for authentication, that is a
> non-binding signature.

That is called `commitment`

Regards
Venkateswara Reddy

Security Consultant,
PSI, India




Received: from diablo.OntheNet.com.au (diablo.OntheNet.com.au [203.10.89.2]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id TAA12123 for <[e-mail]>; Tue, 11 Jul 2000 19:13:35 -0700 (PDT)
Received: from msimon (pc3.eracom.com.au [203.144.16.147]) by diablo.OntheNet.com.au (8.9.3/8.9.3) with SMTP id MAA35001; Wed, 12 Jul 2000 12:15:15 +1000 (EST)
Message-ID: <013901bfeba8$419218f0$[e-mail]>
From: "Simon McMahon" <[e-mail]>
To: <[e-mail]>
Cc: <[e-mail]>
References: <000901bfeb64$38642f50$0201010a@intergalactic>
Subject: Re: Current signature formats insufficient
Date: Wed, 12 Jul 2000 12:23:27 +1000
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.00.2314.1300
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300

Hi all,

My 2c worth.

You should look to the analog-signature as an analogy. It's the content of
what you sign that includes the terms and therefore the extent to which the
signer is bound. Carelessly given signatures should be legally binding,
otherwise ignorance will be used as a defense for repudiation, and only
fraudulently or forcefully obtained signatues should be able to be
sucessfully repudiated by recourse to the law and courts.

You never modify the nature of a handwritten signature to indicate your
intention, e.g different coloured pens or pressing harder, writing bigger /
smaller than normal makes no difference if the handwritten signature can be
shown to be yours or you say it is yours. Its what you sign that binds you.
Having a signature witnessed by a competent authority (a JP) is the only way
I know of to boost non-repudiation of a standard signature. A non-witnessed
signature is presumably easier, but by no means trival to repudiate.

Just because its easier (relatively) to mess with digital signature formats
than handwritten ones dosen't mean that you should since laws for
handwritten signatures will migrate easier to digital ones if the analogy is
kept closer.

I dont agree with either digital alternative for indicating the signers
intention in a legally binding way, i.e. boosting or removing
non-repudiation. Firstly that the certificate's usage attributes should
dictate anything about the private key since they may not both be stored on
the same device and the association is not trivial to check, or, secondly,
that the signature format should indicate my intention when I signed. All of
my intentions should be indicated in the content of what I signed.

Any "intention" indicator added to the signature encoding could just as
easily be encoded into the content before signing. It is effectively
modifying the contract before signing it. For "ephemeral" signatures you
effectively stamp the content "void", then sign it.

Frank's suggestions :
> In the case of an authentication protocol, you could include an OBJECT
> IDENTIFIER or string in the data to be signed to constrain the use of the
> signature. For example:
>
> AuthenticationInfo ::= SEQUENCE {
>    disclaimer UTF8String,
>    nonce      OCTET STRING
> }
>
> Another technique would be to use PKCS #7 authenticated attributes.

These look like good mechanisms for this purpose and use current practise
and encodings. No need for yet-another-encoding :-).

I dont believe that private keys for non-repudiation signatures should ever
be used for ephemeral signatures. It just seems like a dangerous and
unecessary overloading of an important object - the private key. The private
key should be stored with its own usage attributes to avoid looking up the
certificate to see if it is such a key. The device doing the signing should
do whatever the law requires it to do with these keys, regarding
authentication and secure containment, to make non-repudiation enforcable.

Simon McMahon
ERACOM Pty. Ltd.




Received: from mta6.snfc21.pbi.net (mta6.snfc21.pbi.net [206.13.28.240]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id SAA08740 for <[e-mail]>; Tue, 11 Jul 2000 18:37:49 -0700 (PDT)
Received: from [192.168.1.57] ([208.233.228.110]) by mta6.snfc21.pbi.net (Sun Internet Mail Server sims.3.5.2000.01.05.12.18.p9) with ESMTP id <[e-mail]> for [e-mail]; Tue, 11 Jul 2000 18:36:08 -0700 (PDT)
Date: Tue, 11 Jul 2000 18:35:54 -0700
From: Aram Perez <[e-mail]>
Subject: Re: Signing what you don't understand: a practical example
In-reply-to: <[e-mail]>
To: PKIX <[e-mail]>
Message-id: <[e-mail]>
MIME-version: 1.0
Content-type: text/plain; charset="US-ASCII"
Content-transfer-encoding: 7bit
User-Agent: Microsoft-Outlook-Express-Macintosh-Edition/5.02.2022

Hi Tom,

> For Denis' technique to have any real use, there would also need to be
> an indicator somewhere in the certificate that "the private key of this
> pair is held in a Bider-compliant smart card".  Doing that (and it could go
> into any of several extensions, or a new one could be defined), is
> considerably easier than changing the signature format.

But how does the CA know that I'm using a "Bider-compliant smart card"
(BCSC)? Do I have to physically show up somewhere with my BCSC to prove that
I have one? Since the BCSC isn't fully specified, I don't know if it allows
me to keep a backup copy of my signature key. If it does, then I
might/probably could feed the backup into a software only system.

Regards,
Aram Perez

[snip]



Received: from e4.ny.us.ibm.com (e4.ny.us.ibm.com [32.97.182.104]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id SAA05300 for <[e-mail]>; Tue, 11 Jul 2000 18:09:09 -0700 (PDT)
From: [e-mail]
Received: from northrelay02.pok.ibm.com (northrelay02.pok.ibm.com [9.117.200.22]) by e4.ny.us.ibm.com (8.9.3/8.9.3) with ESMTP id VAA39250; Tue, 11 Jul 2000 21:11:04 -0400
Received: from D51MTA04.pok.ibm.com (d51mta04.pok.ibm.com [9.117.200.32]) by northrelay02.pok.ibm.com (8.8.8m3/NCO v4.92) with SMTP id VAA91202; Tue, 11 Jul 2000 21:10:59 -0400
Received: by D51MTA04.pok.ibm.com(Lotus SMTP MTA v4.6.5  (863.2 5-20-1999))  id 8525691A.00067C28 ; Tue, 11 Jul 2000 21:10:50 -0400
X-Lotus-FromDomain: IBMUS
To: Aram Perez <[e-mail]>
cc: [e-mail]
Message-ID: <[e-mail]>
Date: Tue, 11 Jul 2000 21:10:45 -0400
Subject: Re: Signing what you don't understand: a practical example
Mime-Version: 1.0
Content-type: text/plain; charset=us-ascii
Content-Disposition: inline

     For Denis' technique to have any real use, there would also need to be
an indicator somewhere in the certificate that "the private key of this
pair is held in a Bider-compliant smart card".  Doing that (and it could go
into any of several extensions, or a new one could be defined), is
considerably easier than changing the signature format.
     For PKCS 1.5, of course, he could change that format just by defining
a hash function parameter value (if PKCS #1 would agree), or a new OID for
SHA-1 (SHA1OnBiderCard ??).  Getting verifiers to understand either of
these might be interesting, though.

          Tom Gindin

Aram Perez <[e-mail]> on 07/11/2000 08:44:48 PM

To:   [e-mail]
cc:
Subject:  Re: Signing what you don't understand: a practical example



Hi Denis,

[snip]
> 2. Encode the algorithm ID for the hash function and the hash value into
an
> ASN.1 value of type DigestInfo (see Section 11) with the Distinguished
> Encoding Rules (DER), where the type DigestInfo has the syntax
>
> DigestInfo ::= SEQUENCE {
> digestAlgorithm AlgorithmIdentifier,
> digest OCTET STRING,
> flags BIT STRING OPTIONAL
> }
>
> Meaning of 'flags' bits:
> first bit: content-not-understood
> subsequent bits: not defined at this time
>
> In case the value of the first bit of 'flags' is 0, the 'flags' field may
> be omitted for purposes of backward compatibility. However, this is not
> recommended. If omitted, the interpretation of the 'flags' field is
> application-dependent.
>
> The first field identifies the hash function and the second contains the
> hash value. Let T be the DER encoding.
>
> 3. If emLen is less than ||T|| + 10 then output "intended encoded message
> length too short".
>
> 4. Generate an octet string PS consisting of emLen-||T||-2 octets with
value
> FF (hexadecimal). The length of PS will be at least 8 octets.
>
> 5. Concatenate PS, the DER encoding T, and other padding to form the
encoded
> message EM as
>
> EM = 01 || PS || 00 || T
>
> 6. Output EM.

[Warning: Long sentence ahead.] If you received a signed message from me,
formatted per your instructions and with the flags parameter, how would you
know that I was using the security device you have described, that the
message was displayed on that device and that I really understood what I
signed? I can easily create an identical message on my insecure PC with
today's smartcards or just with the right software.

Regards,
Aram Perez




Received: from mta6.snfc21.pbi.net (mta6.snfc21.pbi.net [206.13.28.240]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id RAA03515 for <[e-mail]>; Tue, 11 Jul 2000 17:45:08 -0700 (PDT)
Received: from [192.168.1.57] ([208.233.228.110]) by mta6.snfc21.pbi.net (Sun Internet Mail Server sims.3.5.2000.01.05.12.18.p9) with ESMTP id <[e-mail]> for [e-mail]; Tue, 11 Jul 2000 17:44:53 -0700 (PDT)
Date: Tue, 11 Jul 2000 17:44:48 -0700
From: Aram Perez <[e-mail]>
Subject: Re: Signing what you don't understand: a practical example
In-reply-to: <000d01bfeb6b$d2e75ff0$0201010a@intergalactic>
To: [e-mail]
Message-id: <[e-mail]>
MIME-version: 1.0
Content-type: text/plain; charset="US-ASCII"
Content-transfer-encoding: 7bit
User-Agent: Microsoft-Outlook-Express-Macintosh-Edition/5.02.2022

Hi Denis,

[snip]
> 2. Encode the algorithm ID for the hash function and the hash value into an
> ASN.1 value of type DigestInfo (see Section 11) with the Distinguished
> Encoding Rules (DER), where the type DigestInfo has the syntax
> 
> DigestInfo ::= SEQUENCE {
> digestAlgorithm AlgorithmIdentifier,
> digest OCTET STRING,
> flags BIT STRING OPTIONAL
> }
> 
> Meaning of 'flags' bits:
> first bit: content-not-understood
> subsequent bits: not defined at this time
> 
> In case the value of the first bit of 'flags' is 0, the 'flags' field may
> be omitted for purposes of backward compatibility. However, this is not
> recommended. If omitted, the interpretation of the 'flags' field is
> application-dependent.
> 
> The first field identifies the hash function and the second contains the
> hash value. Let T be the DER encoding.
> 
> 3. If emLen is less than ||T|| + 10 then output "intended encoded message
> length too short".
> 
> 4. Generate an octet string PS consisting of emLen-||T||-2 octets with value
> FF (hexadecimal). The length of PS will be at least 8 octets.
> 
> 5. Concatenate PS, the DER encoding T, and other padding to form the encoded
> message EM as
> 
> EM = 01 || PS || 00 || T
> 
> 6. Output EM.

[Warning: Long sentence ahead.] If you received a signed message from me,
formatted per your instructions and with the flags parameter, how would you
know that I was using the security device you have described, that the
message was displayed on that device and that I really understood what I
signed? I can easily create an identical message on my insecure PC with
today's smartcards or just with the right software.

Regards,
Aram Perez



Received: from stargate.zergo.com.au (IDENT:[e-mail] [203.2.208.130]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id RAA03023 for <[e-mail]>; Tue, 11 Jul 2000 17:31:48 -0700 (PDT)
Received: from sydneymail1.baltimore.com.au (sydneymail1.jp.zergo.com.au [192.168.71.5]) by stargate.zergo.com.au (8.9.1/8.8.7) with ESMTP id KAA02487; Wed, 12 Jul 2000 10:39:41 +1000
Received: by sydneymail1.jp.zergo.com.au with Internet Mail Service (5.5.2448.0) id <34DM0MPH>; Wed, 12 Jul 2000 10:32:48 +1000
Message-ID: <[e-mail]>
From: Michael Zolotarev <[e-mail]>
To: [e-mail], [e-mail]
Subject: RE: Signing what you don't understand
Date: Wed, 12 Jul 2000 10:32:47 +1000
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2448.0)
Content-Type: text/plain; charset="iso-8859-1"

Denis,

> 
> It is my proposal that a signature format is designed which 
> will allow an
> entity to say: "I signed this data, but I didn't understand 
> what I signed.
> You are free to use this signature as proof that I possess a 
> certain private
> key, but this is also the only purpose for which this signature can be
> used."
> 
> Currently, I am not aware of a signature format that allows 
> an entity to do
> that. And because there is no such signature format, people 
> are constantly
> going ahead and signing data they don't understand anyway! 
> Smart cards, as
> currently used, are a perfect example of this behavior(*).
> 


I really fail to see how a potential security vulnerability of signing
environment is linked to a person's ability to say 'I sign it blindly, and
my signature bears no legal obligations'.

Those are completely different and unrelated things, IMHO.

Are you trying to say that because a system can be easily compromised for
25.000 (is it USD?), a person will be better off by using 'non-binding'
signature? This does not make much sense to me. Why not to simply say "Do
not sign anything at all, unless you are 100% sure that this world is free
of hackers"?

Forget about the technology for a moment. Think about legal implications of
it. Not a single court on earth would buy your argument about 'non-binding'
signatures. If you sign something, you are legally bound. When you are drunk
and sign a slip produced by a pizza-delivery boy - that's it, mate. You are
legally bound. Try telling to the court that your 'inner-security' could've
been compromised (not by a virus, but by alcohol), and therefore your
signature is 'non-binding'. 

Following this logic, we'd better start from global revision of the legal
system.

Regards
Michael


Received: from stargate.zergo.com.au (IDENT:[e-mail] [203.2.208.130]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id QAA01816 for <[e-mail]>; Tue, 11 Jul 2000 16:39:55 -0700 (PDT)
Received: from sydneymail1.baltimore.com.au (sydneymail1.jp.zergo.com.au [192.168.71.5]) by stargate.zergo.com.au (8.9.1/8.8.7) with ESMTP id JAA02195; Wed, 12 Jul 2000 09:47:45 +1000
Received: by sydneymail1.jp.zergo.com.au with Internet Mail Service (5.5.2448.0) id <34DM0MN8>; Wed, 12 Jul 2000 09:40:52 +1000
Message-ID: <[e-mail]>
From: Michael Zolotarev <[e-mail]>
To: [e-mail]
Cc: [e-mail]
Subject: RE: Current signature formats insufficient
Date: Wed, 12 Jul 2000 09:40:51 +1000
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2448.0)
Content-Type: text/plain; charset="iso-8859-1"

Denis,

It was a joke, really. Probably a bad one. In Australia we have a phrase
'give me a finger' - similar to what they do in Italy when driving around
like crazy and sticking a hand with one finger up from the car's window.

So I was reading through your message (it was over 10pm, I was still at
work, tired, etc) and I was imagining how you'd be dealing with that
wonder-box. A message on its screen like 'stick your finger', or something
like that.

I was just bitching, really.

Sorry for confusion and possible misunderstanding.

Best regards
Michael

> -----Original Message-----
> From: denis bider [mailto:[e-mail]]
> Sent: Tuesday, July 11, 2000 11:20 PM
> To: 'Michael Zolotarev'; [e-mail]
> Subject: RE: Current signature formats insufficient
> 
> 
> Hello Michael,
> 
> I'm not sure I understand you correctly.
> 
> To attempt an explanation: I used the 'fingerprint' example 
> because I like
> this particular technology, because I believe it to be more 
> practical than,
> say, a retina scan, and because it is my perception that it is readily
> accessible for widespread use.
> 
> I am not, however, involved with the production of any secure 
> device such as
> the one I described in the original message. There is no commercial
> background to my proposal - at least none that I am aware of 
> at this time.
> 
> Regards,
> 
> denis
> 
> 
> -----Original Message-----
> From: Michael Zolotarev [mailto:[e-mail]]
> Sent: 11. julij 2000 13:39
> To: [e-mail]; [e-mail]
> Subject: RE: Current signature formats insufficient
> 
> 
> Don't you find that there is a little bit too much of a 
> 'finger' stuff in
> there... What would be a name for the box?
> 
> :)
> 
> 
> > -----Original Message-----
> > From: denis bider [mailto:[e-mail]]
> > Sent: Tuesday, July 11, 2000 6:42 PM
> > To: [e-mail]
> > Subject: Current signature formats insufficient
> >
> >
> > Hello folks,
> >
> > we probably agree that smart cards, as well as a variety of
> > other similar
> > cryptographic tokens, are insecure. Their primary insecurity
> > lies not within
> > the tokens themselves, but rather in the way they are most
> > commonly used.
> > Most frequently, a cryptographic token is attached to a PC,
> > and it does
> > whatever cryptographic operation the PC tells it to do.
> >
> > This concept is obviously insecure, since:
> >  - PCs are insecure. Every average hacker down the street can
> > break into
> > anyone's Windoze PC, and it is trivial to write an exploit
> > that will capture
> > a smart card's PIN, wait for the smart card to be inserted
> > and then perform
> > a signature operation.
> >  - Even if the user is as security conscious as to use a
> > secure PIN entry
> > device, or a fingerprint scanner for that matter, it is still
> > the PC that
> > decides exactly what information the smart card is going to
> > sign. It is
> > again trivial to write an exploit that will make the smart card sign
> > something that the owner did not mean to sign.
> >
> > With the advent of digital signature laws which make digital signing
> > commonplace, it is time to remove these security holes before
> > hackers and
> > newspaper articles start popping up. (How would any of you 
> smart card
> > manufacturers like to see your company's name placed
> > conveniently next to
> > "FRAUD!!" in TIME Magazine?)
> >
> > The ultimate solution, of course, would be for everyone to
> > have a secure
> > device, containing the private key, with the following
> > characteristics:
> >  - In order to sign anything, the user must put their finger on the
> > fingerprint scanner. (Or other biometrics...)
> >  - In case the signature is binding (ie, contract as opposed to
> > authentication), the user must check the contents being
> > signed on the screen
> > of the secure device.
> >  - In case the signature is binding, the user must enter a signature
> > passphrase (PIN) as well.
> >
> > Now, since users do not want to enter passphrases every time
> > something needs
> > to be signed, and since that would be dangerous in the first place
> > (increased risk of passphrase exposure), there is a practical
> > need for the
> > secure device to be able to distinguish between a binding
> > signature and a
> > non-binding signature.
> >
> > In the case of a non-binding signature (eg, proof of
> > identity), the behavior
> > of the secure device could simply match the behavior of all the
> > cryptographic tokens currently out there. Ie, the device
> > would sign anything
> > that it receives - most commonly a hash of something -
> > provided that the
> > user confirms the signature operation by putting their finger on the
> > fingerpring scanner. However, in contrast to the 
> cryptographic tokens
> > currently being used, any such signature would be explicitly
> > marked that it
> > cannot be considered binding.
> >
> > In the case of a binding signature (eg, a contract), the
> > secure device would
> > insist on receiving the entire content that is being signed,
> > formatted in a
> > well-known and secure format, so that the content can be
> > shown to the user
> > before anything can be signed. The user would also need to
> > authenticate
> > themselves in a more secure manner before a binding signature
> > is made; and
> > when it is made, the signature would be explicitly marked
> > that it CAN be
> > considered binding.
> >
> > It is my opinion that the following efforts need to be made:
> >  - The current signature formats need to be extended so as 
> to include
> > information about the extent to which the data being signed
> > was verified by
> > the signer - or simply whether the signature can be
> > interpreted as binding
> > or not.
> >  - A format for binding content needs to be selected or
> > defined. (RTF, ASCII
> > text, anything?) - this is the format in which any binding
> > content is sent
> > to the secure device so that it can be shown to the user, 
> who in turn
> > decides whether to sign it or not.
> >  - The current APIs for communication with cryptographic
> > tokens need to be
> > modified to support this. Eg, in PKCS#11, the following modes
> > of signature
> > could be introduced:
> >         - sign this hash and mark the signature as non-binding
> >         - here is the 34kB file containing the binding
> > content to be signed,
> > show it to the signer, sign it and mark it as binding
> >         - here is a hash of the binding content to be signed,
> > sign it and
> > mark it as binding (deprecated, but must be included since it
> > is not yet
> > possible to transmit 34kB of data to every kind of
> > cryptographic token)
> >
> > I feel that the above issues are important and that somebody
> > needs to take
> > them on. I cannot decide whether or not this workgroup should
> > do it; but
> > somebody has to. (Or else...)
> >
> > Comments are welcome. Also, does anyone have information 
> whether these
> > issues have been addressed by the xmldsig workgroup, or is
> > their format as
> > clueless as the ASN.1 signature format?
> >
> > Regards,
> >
> > denis bider
> >
> > //
> > //  denis bider, [e-mail]
> > // [alternative: [e-mail]]
> > //  globera d.o.o., Ljubljana, Slovenia
> >     http://www.globera.com
> >     [phone]
> >
> >
> >
> 


Received: from ns.celocom.se ([e-mail] [212.209.40.66]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id NAA28839 for <[e-mail]>; Tue, 11 Jul 2000 13:58:00 -0700 (PDT)
Received: by ns.celocom.se; id WAA23897; Tue, 11 Jul 2000 22:59:52 +0200 (CEST)
Received: from zap.celocom.se(10.10.10.1) by ns.celocom.se via smap (4.1) id xma023891; Tue, 11 Jul 00 22:59:28 +0200
Received: from celocom.com (root@localhost [127.0.0.1]) by zap.celocom.se (8.8.7/8.8.7) with ESMTP id WAA14873; Tue, 11 Jul 2000 22:59:24 +0200
Message-ID: <[e-mail]>
Date: Tue, 11 Jul 2000 23:03:56 +0200
From: Oscar Jacobsson <[e-mail]>
Organization: Celo Communications
X-Mailer: Mozilla 4.72 [en] (Win98; U)
X-Accept-Language: en
MIME-Version: 1.0
To: "Luo, Feng (Exchange)" <[e-mail]>
CC: "'Richard Levitte'" <[e-mail]>, "'[e-mail]'" <[e-mail]>
Subject: Re: p12 and cer, der,crt
References: <[e-mail]>
Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms85A48475EB5BCF0BF9B1F0F2"

This is a cryptographically signed message in MIME format.

--------------ms85A48475EB5BCF0BF9B1F0F2
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

"Luo, Feng (Exchange)" wrote:
> What I like to do is, when you  export the certificate from netscape, it's
> with P12 extension, I want to convert it to der, cer or crt extension, which
> allows the user to excute it and install certificate on the webpage.

OK, fair enough.

Then you would need a two-step process:

1. Extract the Certificate from the PFX, which is easily done using the
OpenSSL command line tools as Richard mentioned, and save it to disk
using -outform DER.

2. Associate whatever extension you gave to the file containing your
Certificate with the appropriate MIME-type for the "installation" you
want in your webserver configuration:

application/x-x509-user-cert: meaning that the cert is meant for the
user of the browser, who should have the corresponding private key.

application/x-x509-ca-cert: meaning that the cert is meant to be added
as a trusted certification authority.

application/x-x509-email-cert: meaning that the cert belongs to another
user and is to be used to encrypt e-mail to them.

More info on the MIME types is available from
http://www.netscape.com/eng/security/comm4-cert-download.html

Cheers!

//oscar
--------------ms85A48475EB5BCF0BF9B1F0F2
Content-Type: application/x-pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: S/MIME Cryptographic Signature

MIIH/gYJKoZIhvcNAQcCoIIH7zCCB+sCAQExCzAJBgUrDgMCGgUAMAsGCSqGSIb3DQEHAaCC
Bc8wggKzMIICHKADAgECAgMCjYUwDQYJKoZIhvcNAQEEBQAwgZQxCzAJBgNVBAYTAlpBMRUw
EwYDVQQIEwxXZXN0ZXJuIENhcGUxFDASBgNVBAcTC0R1cmJhbnZpbGxlMQ8wDQYDVQQKEwZU
aGF3dGUxHTAbBgNVBAsTFENlcnRpZmljYXRlIFNlcnZpY2VzMSgwJgYDVQQDEx9QZXJzb25h
bCBGcmVlbWFpbCBSU0EgMTk5OS45LjE2MB4XDTAwMDUxMzAwMDEzOVoXDTAxMDUxMzAwMDEz
OVowTTEfMB0GA1UEAxMWVGhhd3RlIEZyZWVtYWlsIE1lbWJlcjEqMCgGCSqGSIb3DQEJARYb
b3NjYXIuamFjb2Jzc29uQGNlbG9jb20uY29tMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKB
gQCZB2URw+NGaMMV/cSk9JoOb4OGMunL44lk/ioXoBR5brSVUcVaB+s+8UmcqOmi9RAAc+Uy
wY69hjPn/LWS3HzN4N4KW6jTEiDm0jPE1aVyxMg7un4rjRSGe9htdPL0ut8QoKXLCjafLKIo
v/pyudWgC1PxSglWECgKyKVVMl13KwIDAQABo1kwVzAmBgNVHREEHzAdgRtvc2Nhci5qYWNv
YnNzb25AY2Vsb2NvbS5jb20wDAYDVR0TAQH/BAIwADAfBgNVHSMEGDAWgBSIq/Fgg2ZV9ORY
x0YdwGG9I9fDjDANBgkqhkiG9w0BAQQFAAOBgQB8NkKsoEJaIAfecEv+NJp6bBs3xM+ynX5F
qJ/ave0p7v2eBBO/fovRoMsmFjF0jHf4RFJqxm9NrpoZWlhehM5nOdS0AyPwFIMEWl7PdSxO
pKkxGS8wgEsVammWQc8MAwULu4qy8SdL9LnszsvEKtrsJFG+bILsOf1qBkC6UuSR4DCCAxQw
ggJ9oAMCAQICAQswDQYJKoZIhvcNAQEEBQAwgdExCzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxX
ZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEaMBgGA1UEChMRVGhhd3RlIENvbnN1
bHRpbmcxKDAmBgNVBAsTH0NlcnRpZmljYXRpb24gU2VydmljZXMgRGl2aXNpb24xJDAiBgNV
BAMTG1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBDQTErMCkGCSqGSIb3DQEJARYccGVyc29u
YWwtZnJlZW1haWxAdGhhd3RlLmNvbTAeFw05OTA5MTYxNDAxNDBaFw0wMTA5MTUxNDAxNDBa
MIGUMQswCQYDVQQGEwJaQTEVMBMGA1UECBMMV2VzdGVybiBDYXBlMRQwEgYDVQQHEwtEdXJi
YW52aWxsZTEPMA0GA1UEChMGVGhhd3RlMR0wGwYDVQQLExRDZXJ0aWZpY2F0ZSBTZXJ2aWNl
czEoMCYGA1UEAxMfUGVyc29uYWwgRnJlZW1haWwgUlNBIDE5OTkuOS4xNjCBnzANBgkqhkiG
9w0BAQEFAAOBjQAwgYkCgYEAs2lal9TQFgt6tcVd6SGcI3LNEkxL937Px/vKciT0QlKsV5Xj
e2F6F4Tn/XI5OJS06u1lp5IGXr3gZfYZu5R5dkw+uWhwdYQc9BF0ALwFLE8JAxcxzPRB1HLG
pl3iiESwiy7ETfHw1oU+bPOVlHiRfkDpnNGNFVeOwnPlMN5G9U8CAwEAAaM3MDUwEgYDVR0T
AQH/BAgwBgEB/wIBADAfBgNVHSMEGDAWgBRyScJzNMZV9At2coF+d/SH58ayDjANBgkqhkiG
9w0BAQQFAAOBgQBrxlnpMfrptuyxA9jfcnL+kWBI6sZV3XvwZ47GYXDnbcKlN9idtxcoVgWL
3Vx1b8aRkMZsZnET0BB8a5FvhuAhNi3B1+qyCa3PLW3Gg1Kb+7v+nIed/LfpdJLkXJeu/H6s
yg1vcnpnLGtz9Yb5nfUAbvQdB86dnoJjKe+TCX5V3jGCAfcwggHzAgEBMIGcMIGUMQswCQYD
VQQGEwJaQTEVMBMGA1UECBMMV2VzdGVybiBDYXBlMRQwEgYDVQQHEwtEdXJiYW52aWxsZTEP
MA0GA1UEChMGVGhhd3RlMR0wGwYDVQQLExRDZXJ0aWZpY2F0ZSBTZXJ2aWNlczEoMCYGA1UE
AxMfUGVyc29uYWwgRnJlZW1haWwgUlNBIDE5OTkuOS4xNgIDAo2FMAkGBSsOAwIaBQCggbEw
GAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMDAwNzExMjEwMzU3
WjAjBgkqhkiG9w0BCQQxFgQUZA2uBiqLgSo6Vq+A5QqJEfqHbwUwUgYJKoZIhvcNAQkPMUUw
QzAKBggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwBwYFKw4DAgcwDQYIKoZIhvcNAwICAUAw
DQYIKoZIhvcNAwICASgwDQYJKoZIhvcNAQEBBQAEgYAySeFJ2q3Wl1JhF6rNO99Hle8Ip+5z
+3gvv2Hu94H5NrlHEkWzE1kN6N/t7oYzcz7BBeLnZCJCjiHyLrMjyAMpGuxXYUxcowNvFrK2
vnkGpQ4ybw+YZWLMtoLy/TNOUuKn5dqunJzHBOZXLunnsziOpG3/qqekYyOAiJvSiw64UQ==
--------------ms85A48475EB5BCF0BF9B1F0F2--



Received: from hamster.gadens.com.au ([e-mail] [203.32.220.10]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id NAA28036 for <[e-mail]>; Tue, 11 Jul 2000 13:12:36 -0700 (PDT)
Received: from exchange.gadens.com.au ([10.1.8.3]) by hamster.gadens.com.au (8.9.3/8.9.3) with ESMTP id GAA30864; Wed, 12 Jul 2000 06:13:39 +1000 (EST) (envelope-from [e-mail])
Received: by exchange.gadens.com.au with Internet Mail Service (5.5.2650.21) id <3JMMK5RL>; Wed, 12 Jul 2000 06:16:59 +1000
Message-ID: <[e-mail]>
From: Adrian McCullagh <[e-mail]>
To: "'Ben Laurie'" <[e-mail]>, Frank Balluffi <[e-mail]>
Cc: "'[e-mail]'" <[e-mail]>, [e-mail]
Subject: RE: Current signature formats insufficient
Date: Wed, 12 Jul 2000 06:16:47 +1000
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain; charset="iso-8859-1"

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Ben;

The law does not see it that way.  In the UK if you sign a document as
a receipt and there are terms on the receipt then you are deemed to
have read the terms and agreed to be bound by them.  (see the case of 
L'Strange v. Graucob).  The law will not take your subjective view
into account.  The law will look upon the action from an objective
view.  This is only a simplified version and yes there are exceptions
but the general rule is that if a man comes to your door with a
package and asks you to sign the acknowledgement of receipt you will
be bound by the terms on the back of the document.  The same position
also applies in the USA and in Australia.

- -----Original Message-----
From: Ben Laurie [mailto:[e-mail]]
Sent: Wednesday, July 12, 2000 1:04 AM
To: Frank Balluffi
Cc: '[e-mail]'; [e-mail]
Subject: Re: Current signature formats insufficient


Frank Balluffi wrote:
> 
> Denis,
> 
> You refer to non-binding signatures. Why would I bother signing
something if
> it were non-binding?

When a man comes to the door with a package, I sign it because he asks
for a signature. I do not consider that signature to be binding in any
sense I understand the word.

Cheers,

Ben.

- --
http://www.apache-ssl.org/ben.html

Coming to ApacheCon Europe 2000? http://apachecon.com/

-----BEGIN PGP SIGNATURE-----
Version: PGP Personal Edition 6.0.2

iQA/AwUBOWrzQZWt1NGjt4vzEQIqmACgiMWxbIa1/oM3xxluKDhlItOs3RIAoO9X
htrjUpQWRUId9sa3BWxpns2p
=g/r1
-----END PGP SIGNATURE-----


Received: from smtp-out1.bellatlantic.net (smtp-out1.bellatlantic.net [199.45.39.156]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id MAA27437 for <[e-mail]>; Tue, 11 Jul 2000 12:45:05 -0700 (PDT)
Received: from ieca.com (adsl-151-200-26-46.bellatlantic.net [151.200.26.46]) by smtp-out1.bellatlantic.net (8.9.1/8.9.1) with ESMTP id PAA13046; Tue, 11 Jul 2000 15:46:40 -0400 (EDT)
Message-ID: <[e-mail]>
Date: Tue, 11 Jul 2000 15:44:52 -0400
From: Sean Turner <[e-mail]>
Organization: IECA, Inc.
X-Mailer: Mozilla 4.73 [en] (Win98; U)
X-Accept-Language: en
MIME-Version: 1.0
To: [e-mail]
CC: PKIX <[e-mail]>, [e-mail]
Subject: Re: Comments on draft-ietf-pkix-ldap-v3-01.txt
References: <3964DF22.9858.AF326B8@localhost>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

David,

Comments in line.

David Chadwick wrote:

> Date sent:              Sat, 30 Oct 1999 14:51:32 -0400
> From:                   Sean Turner <[e-mail]>
> Organization:           IECA, Inc.
> To:                     PKIX <[e-mail]>
> Subject:                Comments on draft-ietf-pkix-ldap-v3-01.txt
>
> >
> > After thinking about the draft a bit I'd like to suggest a few
> > modifications (mostly organizational).
> >
> > The draft includes both the protocol and schema issues to deal with
> > LDAPv3 servers.  I think we should split the two topics as the draft
> > is called "operational protocols".  I think the draft should just talk
> > about the protocol issues and not the schema.
>
> After some thought and discussion with other LDAP folk I agree
> with you. One of the reasons is that the LDAPExt group will be
> updating the base LDAPv3 docs in due course and the schema stuff
> should go in there. (But this will be over a longer time frame than is
> needed to publish the protocol part). I am currently doing the
> changes now in time for Pittsburg.
>

Great - I think this will make it a lot clearer.

>
> > My suggestion is to
> > update RFC 2587 (Internet X.509 Public Key Infrastructure LDAPv2
> > Schema) to include the attribute and object classes required to
> > support attribute certificate users.  Then the LDAPv2 schema could
> > support storing the attribute certificate related information.
> > Another draft should be spawned to include specific LDAPv3 schema
> > issues such support for matching rules, etc.
>
> I will talk to Sharon B about this, as to whether she wants to update
> the v2 schema doc or not, or put the whole lot in a new schema doc
> leaving the existing RFC as is. (After all, we are not aware of any
> defects in that doc, are we?). I would favour just one new schema
> doc, which preferrably should be published by the LDAPExt group
> as these are core schema requirments in my opinion. However, I
> will produce the first draft of this.
>
> >
> > There is support for the pmiUser but where are the attribute
> > authority's certificates stored?  Should we define an pmiAA (name to
> > be determined) object class to support storing of the attribute
> > certificate for the AA?
>
> this is now in X509
>

That's where I got the idea from ;)  I was just wondering if you were going
to put in some text to say use the attribute defined in X.509 to store the
AA's certs.  All I'm looking for is implementation guidance.

>
> >
> > Also, which revocation list includes the revoked attribute
> > certificates?  I assumed it would be stored in a separate attribute
> > certificate revocation list, but the draft is silent on the issue (so
> > is draft-ietf-pkix-ac509prof-01.txt).
>
> X.509 defines attributeCertificateRevocationList and
> attributeAuthorityRevocationList. I dont believe PKIX needs to do
> anything more.
>

Same as with the AA's certificate.  I was just hoping to see some text that
says use attributes X and Y to store the ACRL and AARCL objects.

Cheers,

spt

>
> David
>
> >
> > Thanks,
> >
> > spt
> >
> >
> >
> >
>
> ***************************************************
>
> David Chadwick
> IS Institute, University of Salford, Salford M5 4WT
> Tel [phone]  Fax [phone]
> Mobile [phone]
> Email [e-mail]
> Home Page  http://www.salford.ac.uk/its024/chadwick.htm
> Understanding X.500  http://www.salford.ac.uk/its024/X500.htm
> X.500/LDAP Seminars http://www.salford.ac.uk/its024/seminars.htm
> Entrust key validation string MLJ9-DU5T-HV8J
>
> ***************************************************



Received: from cadtt0470.ca.deloitte.com (dac.deloitte.ca [207.164.165.70]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id MAA26967 for <[e-mail]>; Tue, 11 Jul 2000 12:16:52 -0700 (PDT)
Received: by CADTT0470 with Internet Mail Service (5.5.2650.21) id <NL3KDNK1>; Tue, 11 Jul 2000 15:15:11 -0400
Message-ID: <[e-mail]>
From: "Dunnigan, Patrick (CA -Toronto)" <[e-mail]>
To: "'[e-mail]'" <[e-mail]>
Subject: unsubscribe
Date: Tue, 11 Jul 2000 15:15:10 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain; charset="iso-8859-1"


Received: from levitator.1div0.com ([213.250.43.61]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id MAA26596 for <[e-mail]>; Tue, 11 Jul 2000 12:09:05 -0700 (PDT)
Received: from intergalactic ([10.1.1.2]) by levitator.1div0.com (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with SMTP id UAA20649 for <[e-mail]>; Tue, 11 Jul 2000 20:57:32 +0200
Reply-To: <[e-mail]>
From: "denis bider" <[e-mail]>
To: <[e-mail]>
Subject: Signing what you don't understand: a practical example
Date: Tue, 11 Jul 2000 21:11:30 +0200
Message-ID: <000d01bfeb6b$d2e75ff0$0201010a@intergalactic>
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2910.0)
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700

Hello folks,

to make my idea clearer, this is how I imagine an improved signature format
would look like.

(The following is an excerpt from PKCS#1 v2. My proposed changes are marked
in blue.)


9.2.1	EMSA-PKCS1-v1_5

This encoding method only has an encoding operation.

EMSA-PKCS1-v1_5-ENCODE (M, emLen, content-not-understood)

Option:  Hash - hash function
                (hLen denotes the length in octets of
                the hash function output)
Input:   M - message to be encoded
         emLen - intended length in octets of the encoded
                 message, at least ||T|| + 10, where T is
                 the DER encoding of a certain value
                 computed during the encoding operation
         content-not-understood
               - boolean; false if the semantic meaning of
                 the content being signed is understood by
                 the logical entity which is performing
                 the signing operation, true otherwise
Output:  EM - encoded message, an octet string of length
              emLen; or "message too long" or "intended
              encoded message length too short"

Steps:

1. Apply the hash function to the message M to produce a hash value H:
      H = Hash(M).
   If the hash function outputs "message too long", then output "message too
long".

2. Encode the algorithm ID for the hash function and the hash value into an
ASN.1 value of type DigestInfo (see Section 11) with the Distinguished
Encoding Rules (DER), where the type DigestInfo has the syntax

   DigestInfo ::= SEQUENCE {
     digestAlgorithm AlgorithmIdentifier,
     digest OCTET STRING,
     flags BIT STRING OPTIONAL
   }

   Meaning of 'flags' bits:
     first bit: content-not-understood
     subsequent bits: not defined at this time

   In case the value of the first bit of 'flags' is 0, the 'flags' field may
be omitted for purposes of backward compatibility. However, this is not
recommended. If omitted, the interpretation of the 'flags' field is
application-dependent.

   The first field identifies the hash function and the second contains the
hash value. Let T be the DER encoding.

3. If emLen is less than ||T|| + 10 then output "intended encoded message
length too short".

4. Generate an octet string PS consisting of emLen-||T||-2 octets with value
FF (hexadecimal). The length of PS will be at least 8 octets.

5. Concatenate PS, the DER encoding T, and other padding to form the encoded
message EM as

   EM = 01 || PS || 00 || T

6. Output EM.


//
//  denis bider, [e-mail]
// [alternative: [e-mail]]
//  globera d.o.o., Ljubljana, Slovenia
    http://www.globera.com
    [phone]




Received: from levitator.1div0.com ([213.250.43.61]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id LAA25248 for <[e-mail]>; Tue, 11 Jul 2000 11:17:15 -0700 (PDT)
Received: from intergalactic ([10.1.1.2]) by levitator.1div0.com (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with SMTP id UAA20551 for <[e-mail]>; Tue, 11 Jul 2000 20:05:44 +0200
Reply-To: <[e-mail]>
From: "denis bider" <[e-mail]>
To: <[e-mail]>
Subject: RE: Current signature formats insufficient
Date: Tue, 11 Jul 2000 20:19:37 +0200
Message-ID: <000a01bfeb64$933f0120$0201010a@intergalactic>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2910.0)
In-reply-to: <[e-mail]>
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700

Hello Jean-Marc,

I'm not sure that using multiple certificates is the proper solution.
Rather, I think it is an attempt to patch the problem rather than to resolve
the issue at its roots.

The core problem is that there is no standardized signature format that
allows a person to say: "I am signing this, but I don't understand what I
have signed."

One example why using multiple certificates is a context-specific patch
rather than a general solution:

Suppose you have an e-banking service. The e-banking service uses private
key authentication to login, and it also uses digital signatures to confirm
payments.

With the "multiple certificates" solution, it is up to the designer AND the
administrator of the e-banking service to provide support for multiple
certificates - one for authentication, and one for confirming payments.
Thus, if the service designer and/or administrator are not
security-conscious enough to take care of this issue, the user has no way of
protecting themselves against trojan attack.

Keep in mind, again, that what we are trying to protect the user from is a
trojan attack, where the user's PC is compromised and the user is tricked
into allowing an authentication-only signature take place, where in fact the
authentication-only data has been replaced by a trojan horse with data that,
when signed, binds the user to an agreement or contract that they have never
seen.

If, in contrast, a signature format existed with which it was possible to
sign data safely without knowing its semantics, this danger would cease to
exist.

Btw - a real-world example: a few years ago, an old lady in Austria lost her
apartment to a very similar trick. Someone rang her bell and explained to
her that some simple formality needs to be signed so that something or other
will be taken care of. She couldn't read very well, so she signed the paper
without knowing what it said. However, the paper was actually an agreement
that she is giving the apartment to a third party she had never heard of.
The judge enforced the validity of the agreement and she lost the apartment.

Again, thousands of people with PCs and smart cards are unnecessarily
signing electronic documents like this every day - just because there is no
digital signature format which would allow a person to safely sign data
which they can't understand.


denis


-----Original Message-----
From: Jean-Marc Desperrier [mailto:[e-mail]]
Sent: 11. julij 2000 16:32
To: [e-mail]
Subject: Re: Current signature formats insufficient


denis bider wrote:

> Examples: if you sign a contract, that is a binding signature. If you sign
a
> purchase order, that is a binding signature. If you sign a cryptographic
> challenge intended for authentication, that is a non-binding signature.

This is what certificates are for.

To do that, you use several different private keys, each being associated
with a
certificate that has different usage extensions.

It is already a recommended usage to use a different key for SSL
authentification and to sign a document.

What you are saying is not linked to the format of certificates, but to the
way
they are used and the policies that should be enforced for legally binding
signatures.

Nothing in the RFC says, or will or even could say, how a private key has to
be
used to be legally binding.
Therefore this is quite out of suject here.

Could you shorten your quoting please ?



Received: from d1o69.telia.com ([e-mail] [62.20.144.241]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id LAA25163 for <[e-mail]>; Tue, 11 Jul 2000 11:16:50 -0700 (PDT)
Received: from mega (t5o69p50.telia.com [213.64.110.50]) by d1o69.telia.com (8.8.8/8.8.8) with SMTP id UAA26813; Tue, 11 Jul 2000 20:18:40 +0200 (CEST)
Message-ID: <001c01bfeb6c$b45ecbd0$[e-mail]>
From: "Anders Rundgren" <[e-mail]>
To: "PKIX-List" <[e-mail]>, "Stefan Santesson" <[e-mail]>, <[e-mail]>, "David P. Kemp" <[e-mail]>
Subject: Re: Cert compare. Was: I-D ACTION:draft-ietf-pkix-qc-04.txt
Date: Tue, 11 Jul 2000 21:17:48 +0200
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 4.72.3110.5
X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by ns.secondary.com id LAA25166

>What we say is that determination of whether the same name in two 
>certificates relates to the same entity is outside the scope of the standard.


Aha! There is a PKIX-equivalent to "outside the scope of the standard" called "handled with care"!

>May I also draw your attension to the fact that the term "unmistakable 
>identity" is no longer part of the document.


Uhum, a QC CA does not even have to create unmistakable identities anymore?

Anders





Received: from levitator.1div0.com ([213.250.43.61]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id LAA24961 for <[e-mail]>; Tue, 11 Jul 2000 11:14:50 -0700 (PDT)
Received: from intergalactic ([10.1.1.2]) by levitator.1div0.com (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with SMTP id UAA20547 for <[e-mail]>; Tue, 11 Jul 2000 20:03:06 +0200
Reply-To: <[e-mail]>
From: "denis bider" <[e-mail]>
To: <[e-mail]>
Subject: RE: Current signature formats insufficient
Date: Tue, 11 Jul 2000 20:17:05 +0200
Message-ID: <000901bfeb64$38642f50$0201010a@intergalactic>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2910.0)
In-reply-to: <[e-mail]>
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700

Paul,

you are right - the definition of a 'binding signature' depends very much on
the definition of what "binding" actually means.

The 'non-binding signature' that I referred to was, in fact, meant to be a
"signature of data that the signer does not understand" - hence, a signature
which implies no more than the subject's willingness to participate in a
third party's effort to validate the subject's identity. An 'ephemeral
signature' therefore, by Hal Lockhart's definition.

Regards,

denis


-----Original Message-----
From: Paul Koning [mailto:[e-mail]]
Sent: 11. julij 2000 17:16
To: [e-mail]
Cc: [e-mail]; [e-mail]; [e-mail]
Subject: Re: Current signature formats insufficient


>>>>> "Ben" == Ben Laurie <[e-mail]> writes:

 Ben> Frank Balluffi wrote:
 >>  Denis,
 >>
 >> You refer to non-binding signatures. Why would I bother signing
 >> something if it were non-binding?

 Ben> When a man comes to the door with a package, I sign it because
 Ben> he asks for a signature. I do not consider that signature to be
 Ben> binding in any sense I understand the word.

I don't understand the notion of a non-binding signature.  To put it
differently, the purpose of a signature is to bind your identity to
some assertion.  The only question is what that assertion is.

It could be "I (insert name) agree to buy 100k shares of FOO
Corporation".  That would be a "binding" signature in the sense it has
been discussed.

But in the example you give, the assertion is "I have received package
xyz (and consequently agree not to press insurance claims for
non-delivery of that package".  Is that any less "binding"?  The
amount of money at stake may be less, so there's a difference in
degree, but I don't see a difference in essence.

Similarly the example of authentication for a web banking
application.  Even if you're only looking at information, you're
making an assertion that you're authorized to do the looking (or in
other words, that accesses so authenticated will not later be
challenged as violations of privacy).  Again, the amount of money at
stake changes, but...

      paul



Received: from levitator.1div0.com ([213.250.43.61]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id LAA24631 for <[e-mail]>; Tue, 11 Jul 2000 11:07:12 -0700 (PDT)
Received: from intergalactic ([10.1.1.2]) by levitator.1div0.com (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with SMTP id TAA20520; Tue, 11 Jul 2000 19:55:25 +0200
Reply-To: <[e-mail]>
From: "denis bider" <[e-mail]>
To: "'Hal Lockhart'" <[e-mail]>, <[e-mail]>
Subject: RE: Current signature formats insufficient
Date: Tue, 11 Jul 2000 20:09:25 +0200
Message-ID: <000801bfeb63$2585d240$0201010a@intergalactic>
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2910.0)
In-reply-to: <[e-mail]>
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700

Hal,

thanks for this note. Will try to reuse this term when referring to this
kind of signature.

Does anyone have an idea for a shorthand term for "a digital signature which
allows someone to safely sign data which they do not understand"?

Regards,

denis


-----Original Message-----
From: Hal Lockhart [mailto:[e-mail]]
Sent: 11. julij 2000 17:10
To: '[e-mail]'; 'Frank Balluffi'; [e-mail]
Subject: RE: Current signature formats insufficient


> in the context of my original message, a "non-binding
> signature" would be a
> signature for the purposes of, say, authentication.

In past discussions (about the key usage field) on this mailing list, this
has been referred to as an "ephemeral signature".

Hal

=======================================================
Harold W. Lockhart            Entegrity Solutions
2 Mount Royal Avenue          Marlborough, MA 01752 USA
V: 1-508-624-9600 x 260       [e-mail]
F: 1-508-229-0338             www.entegrity.com
=======================================================



Received: from levitator.1div0.com ([213.250.43.61]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id KAA23544 for <[e-mail]>; Tue, 11 Jul 2000 10:43:45 -0700 (PDT)
Received: from intergalactic ([10.1.1.2]) by levitator.1div0.com (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with SMTP id TAA20480 for <[e-mail]>; Tue, 11 Jul 2000 19:32:12 +0200
Reply-To: <[e-mail]>
From: "denis bider" <[e-mail]>
To: <[e-mail]>
Subject: Signing what you don't understand
Date: Tue, 11 Jul 2000 19:46:10 +0200
Message-ID: <000301bfeb5f$e6cf77c0$0201010a@intergalactic>
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2910.0)
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700

The most important point of my previous message was buried under a pile of
other stuff, so I am repeating it here:


It is my proposal that a signature format is designed which will allow an
entity to say: "I signed this data, but I didn't understand what I signed.
You are free to use this signature as proof that I possess a certain private
key, but this is also the only purpose for which this signature can be
used."

Currently, I am not aware of a signature format that allows an entity to do
that. And because there is no such signature format, people are constantly
going ahead and signing data they don't understand anyway! Smart cards, as
currently used, are a perfect example of this behavior(*).

I am convinced that a signature format is needed that will allow an entity
to safely sign information that it does not understand. Otherwise, people
will continue to sign such information with a protocol that BINDS them to
what they have signed, regardless of the fact that they are not sure about
what they are signing.


(*): You may think you know what you're signing, but trust me, you don't. It
is preposterously easy to write a virus that will circumvent any smart
card's security without being noticed. I will do it for $25,000; a college
student next door will do it for free.



Received: from levitator.1div0.com ([213.250.43.61]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id KAA23109 for <[e-mail]>; Tue, 11 Jul 2000 10:41:04 -0700 (PDT)
Received: from intergalactic ([10.1.1.2]) by levitator.1div0.com (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with SMTP id TAA20455; Tue, 11 Jul 2000 19:29:09 +0200
Reply-To: <[e-mail]>
From: "denis bider" <[e-mail]>
To: "'Dale Gustafson'" <[e-mail]>, <[e-mail]>
Subject: RE: Current signature formats insufficient
Date: Tue, 11 Jul 2000 19:43:07 +0200
Message-ID: <000201bfeb5f$79a796f0$0201010a@intergalactic>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2910.0)
In-reply-to: <[e-mail]>
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700

Hello Dale,

yes, I agree - a proper security device would indeed be more complex than
smart cards currently are. In fact, I expect that either mobile phones or
PDAs will take on the role of security devices in place of smart cards. Both
types of devices already provide more than sufficient functionality to host,
eg, a secure document viewer that the consumer can use to view a document
before signing it.

However, I think that we have to admit that the solution you identified as
"all singing / all dancing" is, in fact, the bare minimum that needs to be
implemented before we can move into a true, paperless electronic era.

The fact I wanted to expose is that, without the kind of additional token
functionality that I described, the current system is much too flawed for
widespread use. A PC with a smart card is too easy to crack, and that's it.
It's too damn easy to crack.

Sooner or later, we will need a secure device which will be able to:
 - show the document being signed to the user so they can proof-read it;
 - before signing, verify the user's identity with, say, a fingerprint
scanner.

Assuming that I have proven sufficiently that such a device is needed and
that its widespread availability is required, because otherwise we will
never be able to rid ourselves of the acute need for paper, I now put forth
the following theory:

- Sometimes the device will be used to sign data for authentication; at
other times, it will be used to sign documents which the user has to
understand thoroughly before signing.
- The device will receive data that it is supposed to sign from untrusted
sources, such as from a PC (signing an email, or logging into a website); or
from a cash register in a supermarket (signing to pay for stuff); or from a
door (authentication to enter a house, or an apartment).
- This device will not always be able to influence the protocol in which its
cryptographic services are required. Hence, the device will not always be
able to control the format of data that needs to be signed. Only if the
format of data can be understood by the device, only then can the device
perform a signature on this data that somehow binds its user. Otherwise, if
the format of data is not understood by the device, we have two options:
    * The device must not perform any signature operation.
    * The device performs a signature operation where it explicitly states
"I do not understand this data, hence this signature cannot be considered
binding to my owner."

It is my proposal that a signature format is designed which will allow an
entity to say exactly this: "I signed this data, but I didn't understand
what I signed. You are free to use this signature as proof that I possess a
certain private key, but this is also the only purpose for which this
signature can be used."

Currently, I am not aware of a signature format that allows an entity to do
that. And because there is no such signature format, people are constantly
going ahead and signing data they don't understand anyway! Smart cards, as
currently used, are a perfect example of this behavior. (You may think you
know what you're signing, but trust me, you don't. It is preposterously easy
to write a virus that will circumvent any smart card's security without
being noticed. I will do it for $25,000; a college student next door will do
it for free.)

I am convinced that a signature format is needed that will allow an entity
to safely sign information that it does not understand. Otherwise, people
will continue to sign such information with a protocol that BINDS them to
what they have signed, regardless of the fact that they are not sure about
what they are signing.

This is dangerous.

Regards,

denis


-----Original Message-----
From: Dale Gustafson [mailto:[e-mail]]
Sent: 11. julij 2000 16:01
To: [e-mail]
Cc: [e-mail]
Subject: Re: Current signature formats insufficient


Denis,

Take a closer look at the "Signing Key with Secondary Authentication PIN"
capabilities added to PKCS#11 v2.10.  Works with optional Secure PINPad
readers
such that the PIN values are not known to PC software.  This feature can be
used
to provide the "user must enter a special PIN for each and every signature
created" functionality you describe.  An application could create a key that
is
used only for signing binding / contract documents, etc. thus providing one
clear indication that a "non-repudiation" service is being provided.  This
approach is different than adding bits to a signature block but provides a
similar effect.  I agree that the secure application should be specifically
requesting a distinct signature service (signalled to relying parties by use
of
a dedicated signing key and certificate).

Cryptographic tokens typically provide 2-factor authentication -- something
you
have (the physical card) and something you know (the User PIN / Passphrase).
This is clearly more secure and portable than storing your security
information
on your PC hard drive.  Nevertheless, any scenario that defeats both factors
eliminates the additional security provided by the token.  For example; if
someone threatens you, takes your token away, and makes you tell her your
PINs
then your smart token and any private keys stored within can no longer be
considered secure.

The problem with any all singing / all dancing technical solution is that in
order to make the smart token really nifty you have to provide much of the
functionality of your Windows PC (e.g. so you can see the web page or movie
clip
you're signing).  You can go to three-factor authentication (something you
have,
something you know, something you are) and beyond but there's invariably a
point
of diminishing returns for any real network, user community, and
applications.

Best Regards,

Dale Gustafson


denis bider wrote:

> Hello folks,
>
> we probably agree that smart cards, as well as a variety of other similar
> cryptographic tokens, are insecure. Their primary insecurity lies not
within
> the tokens themselves, but rather in the way they are most commonly used.
> Most frequently, a cryptographic token is attached to a PC, and it does
> whatever cryptographic operation the PC tells it to do.
>
> This concept is obviously insecure, since:
>  - PCs are insecure. Every average hacker down the street can break into
> anyone's Windoze PC, and it is trivial to write an exploit that will
capture
> a smart card's PIN, wait for the smart card to be inserted and then
perform
> a signature operation.
>  - Even if the user is as security conscious as to use a secure PIN entry
> device, or a fingerprint scanner for that matter, it is still the PC that
> decides exactly what information the smart card is going to sign. It is
> again trivial to write an exploit that will make the smart card sign
> something that the owner did not mean to sign.
>
> With the advent of digital signature laws which make digital signing
> commonplace, it is time to remove these security holes before hackers and
> newspaper articles start popping up. (How would any of you smart card
> manufacturers like to see your company's name placed conveniently next to
> "FRAUD!!" in TIME Magazine?)
>
> The ultimate solution, of course, would be for everyone to have a secure
> device, containing the private key, with the following characteristics:
>  - In order to sign anything, the user must put their finger on the
> fingerprint scanner. (Or other biometrics...)
>  - In case the signature is binding (ie, contract as opposed to
> authentication), the user must check the contents being signed on the
screen
> of the secure device.
>  - In case the signature is binding, the user must enter a signature
> passphrase (PIN) as well.
>
> Now, since users do not want to enter passphrases every time something
needs
> to be signed, and since that would be dangerous in the first place
> (increased risk of passphrase exposure), there is a practical need for the
> secure device to be able to distinguish between a binding signature and a
> non-binding signature.
>
> In the case of a non-binding signature (eg, proof of identity), the
behavior
> of the secure device could simply match the behavior of all the
> cryptographic tokens currently out there. Ie, the device would sign
anything
> that it receives - most commonly a hash of something - provided that the
> user confirms the signature operation by putting their finger on the
> fingerpring scanner. However, in contrast to the cryptographic tokens
> currently being used, any such signature would be explicitly marked that
it
> cannot be considered binding.
>
> In the case of a binding signature (eg, a contract), the secure device
would
> insist on receiving the entire content that is being signed, formatted in
a
> well-known and secure format, so that the content can be shown to the user
> before anything can be signed. The user would also need to authenticate
> themselves in a more secure manner before a binding signature is made; and
> when it is made, the signature would be explicitly marked that it CAN be
> considered binding.
>
> It is my opinion that the following efforts need to be made:
>  - The current signature formats need to be extended so as to include
> information about the extent to which the data being signed was verified
by
> the signer - or simply whether the signature can be interpreted as binding
> or not.
>  - A format for binding content needs to be selected or defined. (RTF,
ASCII
> text, anything?) - this is the format in which any binding content is sent
> to the secure device so that it can be shown to the user, who in turn
> decides whether to sign it or not.
>  - The current APIs for communication with cryptographic tokens need to be
> modified to support this. Eg, in PKCS#11, the following modes of signature
> could be introduced:
>         - sign this hash and mark the signature as non-binding
>         - here is the 34kB file containing the binding content to be
signed,
> show it to the signer, sign it and mark it as binding
>         - here is a hash of the binding content to be signed, sign it and
> mark it as binding (deprecated, but must be included since it is not yet
> possible to transmit 34kB of data to every kind of cryptographic token)
>
> I feel that the above issues are important and that somebody needs to take
> them on. I cannot decide whether or not this workgroup should do it; but
> somebody has to. (Or else...)
>
> Comments are welcome. Also, does anyone have information whether these
> issues have been addressed by the xmldsig workgroup, or is their format as
> clueless as the ASN.1 signature format?
>
> Regards,
>
> denis bider
>
> //
> //  denis bider, [e-mail]
> // [alternative: [e-mail]]
> //  globera d.o.o., Ljubljana, Slovenia
>     http://www.globera.com
>     [phone]



Received: from wafw.bear.com (wafw.bear.com [207.162.228.3]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id KAA23043 for <[e-mail]>; Tue, 11 Jul 2000 10:40:36 -0700 (PDT)
Received: from bear.com (localhost [127.0.0.1]) by wafw.bear.com (8.9.3/8.9.2) with SMTP id NAA29497; Tue, 11 Jul 2000 13:42:27 -0400 (EDT)
Received: from 147.107.87.19 by whmsxvs2.is.bear.com (InterScan E-Mail VirusWall NT); Tue, 11 Jul 2000 13:40:50 -0400 (Eastern Daylight Time)
Received: by whmsx2.is.bear.com with Internet Mail Service (5.5.2448.0) id <33MD3CTB>; Tue, 11 Jul 2000 13:42:26 -0400
Message-ID: <[e-mail]>
From: "Luo, Feng (Exchange)" <[e-mail]>
To: "'Richard Levitte'" <[e-mail]>
Cc: "'[e-mail]'" <[e-mail]>
Subject: RE: p12 and cer, der,crt
Date: Tue, 11 Jul 2000 13:42:24 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2448.0)
Content-Type: text/plain

What I like to do is, when you  export the certificate from netscape, it's
with P12 extension, I want to convert it to der, cer or crt extension, which
allows the user to excute it and install certificate on the webpage.

-feng

> -----Original Message-----
> From:	Richard Levitte [SMTP:[e-mail]]
> Sent:	Tuesday, July 11, 2000 1:33 PM
> To:	Luo, Feng (Exchange)
> Cc:	'[e-mail]'
> Subject:	Re: p12 and cer, der,crt
> 
>  << File: SMIME.txt >> 


***********************************************************************
Bear Stearns is not responsible for any recommendation, solicitation, 
offer or agreement or any information about any transaction, customer 
account or account activity contained in this communication.
***********************************************************************



Received: from ns.celocom.se ([e-mail] [212.209.40.66]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id KAA22646 for <[e-mail]>; Tue, 11 Jul 2000 10:32:04 -0700 (PDT)
Received: by ns.celocom.se; id TAA22450; Tue, 11 Jul 2000 19:33:51 +0200 (CEST)
Received: from zap.celocom.se(10.10.10.1) by ns.celocom.se via smap (4.1) id xma022446; Tue, 11 Jul 00 19:33:38 +0200
Received: from celocom.se (dhcp013.celocom.se [10.10.10.193]) by zap.celocom.se (8.8.7/8.8.7) with ESMTP id TAA13611; Tue, 11 Jul 2000 19:33:38 +0200
Message-ID: <[e-mail]>
Date: Tue, 11 Jul 2000 19:33:01 +0200
From: Richard Levitte <[e-mail]>
Organization: Celo Communications, Ltd.
X-Mailer: Mozilla 4.73 [en] (WinNT; I)
X-Accept-Language: en
MIME-Version: 1.0
To: "Luo, Feng (Exchange)" <[e-mail]>
CC: "'[e-mail]'" <[e-mail]>
Subject: Re: p12 and cer, der,crt
References: <[e-mail]>
Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------msCFD62E24BD356C92D0910154"

This is a cryptographically signed message in MIME format.

--------------msCFD62E24BD356C92D0910154
Content-Type: multipart/mixed;
 boundary="------------B3D6BB4109DFA66AA5CCD3BC"

This is a multi-part message in MIME format.
--------------B3D6BB4109DFA66AA5CCD3BC
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

"Luo, Feng (Exchange)" wrote:

> Is there a way to convert p12 to cer, der, crt? That a user can install a
> certificate himeself on the webpage.

Uhmm, a PKCS12-type file is most probably DER-coded already.  I assume that
what you really want is to extract certificates from a PKCS12-type file.  May
I suggest OpenSSL, found in  http://www.openssl.org/ ?

--
Richard Levitte   !!! New cell phone number !!!
[e-mail]

/* You might enjoy viewing the complete vCard */


--------------B3D6BB4109DFA66AA5CCD3BC
Content-Type: text/x-vcard; charset=us-ascii;
 name="richard.levitte.vcf"
Content-Transfer-Encoding: 7bit
Content-Description: Card for Richard Levitte
Content-Disposition: attachment;
 filename="richard.levitte.vcf"

begin:vcard 
n:Levitte;Richard
tel;cell:[phone]
tel;work:[phone]
x-mozilla-html:FALSE
org:<A HREF="http://www.celocom.com">Celo Communications</A>
version:2.1
email;internet:[e-mail]
title:Software Artist
adr;quoted-printable:;;Sveav=E4gen 145, 5tr=0D=0AStockholm;;;;SWEDEN
note;quoted-printable:<br>=0D=0A<table border=3D0>=0D=0A<tr>=0D=0A  <td bgcolor=3D"#00ffff">c=EAlo, =E2vi, =E2tum, (latin) 1,v.a.=0D=0A      to hide something from one, to keep secret, to conceal.=0D=0A  </td>=0D=0A</tr>=0D=0A</table>=0D=0A<br>=0D=0A<table border=3D3>=0D=0A<tr>=0D=0A <td>=0D=0A  <table>=0D=0A  <tr>=0D=0A   <td valign=3Dtop>o/~</td>=0D=0A   <td><font size=3D-1>Coding, coding, coding</font><br>=0D=0A          Keep'em hackers coding<br>=0D=0A          <font size=3D+1>And When They're Done Coding</font><br>=0D=0A          <font size=3D7>COMPIIIIIIILE!!</font></td>=0D=0A  </tr>=0D=0A  </table>=0D=0A </td>=0D=0A</tr>=0D=0A</table>
fn:Richard Levitte
end:vcard

--------------B3D6BB4109DFA66AA5CCD3BC--

--------------msCFD62E24BD356C92D0910154
Content-Type: application/x-pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: S/MIME Cryptographic Signature

MIIH+gYJKoZIhvcNAQcCoIIH6zCCB+cCAQExCzAJBgUrDgMCGgUAMAsGCSqGSIb3DQEHAaCC
BfYwggLaMIICQ6ADAgECAgMC0N4wDQYJKoZIhvcNAQEEBQAwgZQxCzAJBgNVBAYTAlpBMRUw
EwYDVQQIEwxXZXN0ZXJuIENhcGUxFDASBgNVBAcTC0R1cmJhbnZpbGxlMQ8wDQYDVQQKEwZU
aGF3dGUxHTAbBgNVBAsTFENlcnRpZmljYXRlIFNlcnZpY2VzMSgwJgYDVQQDEx9QZXJzb25h
bCBGcmVlbWFpbCBSU0EgMTk5OS45LjE2MB4XDTAwMDYyODA3NDUyNFoXDTAxMDYyODA3NDUy
NFowdTEQMA4GA1UEBBMHTGV2aXR0ZTEWMBQGA1UEKhMNVG9tbXkgUmljaGFyZDEeMBwGA1UE
AxMVVG9tbXkgUmljaGFyZCBMZXZpdHRlMSkwJwYJKoZIhvcNAQkBFhpyaWNoYXJkLmxldml0
dGVAY2Vsb2NvbS5zZTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAwXPKEM87WKqgc1sR
3htfC7RThgvQybuuoEnR3YJEHaO0Bq+GxA5cv19STwnTyts34msx8bnEOowDhXpFMK9SMLxm
KTbs7+Tr2MvcndEljhIJOXWhtR1j94Fct6T8TRjLrOrAf9AwXhTzONk+L7JRzqaWMomp80Jb
imnGFHF20TECAwEAAaNYMFYwJQYDVR0RBB4wHIEacmljaGFyZC5sZXZpdHRlQGNlbG9jb20u
c2UwDAYDVR0TAQH/BAIwADAfBgNVHSMEGDAWgBSIq/Fgg2ZV9ORYx0YdwGG9I9fDjDANBgkq
hkiG9w0BAQQFAAOBgQBlABJMb8zOd6a1Tuia5P/ba5Algr4ts9N5kNRxlrc6xed9B3VwRclE
g7U6R2d3Bn+4qD8mMKdjlsnWD305DEKUblO831AnuE1ZRgrt00difbOlBua8+UAyvPfdmrli
6KRDM/A62/ToBX4yYYDlwDMefPRsReNdHbJtlgqw0UN42DCCAxQwggJ9oAMCAQICAQswDQYJ
KoZIhvcNAQEEBQAwgdExCzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQ
BgNVBAcTCUNhcGUgVG93bjEaMBgGA1UEChMRVGhhd3RlIENvbnN1bHRpbmcxKDAmBgNVBAsT
H0NlcnRpZmljYXRpb24gU2VydmljZXMgRGl2aXNpb24xJDAiBgNVBAMTG1RoYXd0ZSBQZXJz
b25hbCBGcmVlbWFpbCBDQTErMCkGCSqGSIb3DQEJARYccGVyc29uYWwtZnJlZW1haWxAdGhh
d3RlLmNvbTAeFw05OTA5MTYxNDAxNDBaFw0wMTA5MTUxNDAxNDBaMIGUMQswCQYDVQQGEwJa
QTEVMBMGA1UECBMMV2VzdGVybiBDYXBlMRQwEgYDVQQHEwtEdXJiYW52aWxsZTEPMA0GA1UE
ChMGVGhhd3RlMR0wGwYDVQQLExRDZXJ0aWZpY2F0ZSBTZXJ2aWNlczEoMCYGA1UEAxMfUGVy
c29uYWwgRnJlZW1haWwgUlNBIDE5OTkuOS4xNjCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkC
gYEAs2lal9TQFgt6tcVd6SGcI3LNEkxL937Px/vKciT0QlKsV5Xje2F6F4Tn/XI5OJS06u1l
p5IGXr3gZfYZu5R5dkw+uWhwdYQc9BF0ALwFLE8JAxcxzPRB1HLGpl3iiESwiy7ETfHw1oU+
bPOVlHiRfkDpnNGNFVeOwnPlMN5G9U8CAwEAAaM3MDUwEgYDVR0TAQH/BAgwBgEB/wIBADAf
BgNVHSMEGDAWgBRyScJzNMZV9At2coF+d/SH58ayDjANBgkqhkiG9w0BAQQFAAOBgQBrxlnp
MfrptuyxA9jfcnL+kWBI6sZV3XvwZ47GYXDnbcKlN9idtxcoVgWL3Vx1b8aRkMZsZnET0BB8
a5FvhuAhNi3B1+qyCa3PLW3Gg1Kb+7v+nIed/LfpdJLkXJeu/H6syg1vcnpnLGtz9Yb5nfUA
bvQdB86dnoJjKe+TCX5V3jGCAcwwggHIAgEBMIGcMIGUMQswCQYDVQQGEwJaQTEVMBMGA1UE
CBMMV2VzdGVybiBDYXBlMRQwEgYDVQQHEwtEdXJiYW52aWxsZTEPMA0GA1UEChMGVGhhd3Rl
MR0wGwYDVQQLExRDZXJ0aWZpY2F0ZSBTZXJ2aWNlczEoMCYGA1UEAxMfUGVyc29uYWwgRnJl
ZW1haWwgUlNBIDE5OTkuOS4xNgIDAtDeMAkGBSsOAwIaBQCggYYwGAYJKoZIhvcNAQkDMQsG
CSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMDAwNzExMTczMzAzWjAjBgkqhkiG9w0BCQQx
FgQU2hGmdSsFFjyHgkx/4euKHuRzQiowJwYJKoZIhvcNAQkPMRowGDAHBgUrDgMCBzANBggq
hkiG9w0DAgIBKDANBgkqhkiG9w0BAQEFAASBgINRFYPuaU0jc1RHVNpc17y/pMspAx0+aWtO
ObPJE8+/jI40y4zpmaliONzAQbbqxplhL2Y85af53hy7rUJ8VOot73G6G30GHHJ4BUALxrsO
KFVD5jyrLATbE5qABibEMpEqbR7IDy9VbOXe2snUGiFGeX7ZUqsMuP6w78rmcUd/
--------------msCFD62E24BD356C92D0910154--



Received: from ext-mail.valicert.com (ns1.valicert.com [63.65.221.10]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id KAA22243 for <[e-mail]>; Tue, 11 Jul 2000 10:27:15 -0700 (PDT)
Received: from CONVERSION-DAEMON.ext-mail.valicert.com by ext-mail.valicert.com (PMDF V6.0-24 #46243) id <[e-mail]> for [e-mail]; Tue, 11 Jul 2000 10:29:07 -0700 (PDT)
Received: from seine.valicert.com ([192.168.2.23]) by ext-mail.valicert.com (PMDF V6.0-24 #46243) with ESMTP id <[e-mail]>; Tue, 11 Jul 2000 10:29:06 -0700 (PDT)
Received: by seine.valicert.com with Internet Mail Service (5.5.2650.21) id <3PTBZZ27>; Tue, 11 Jul 2000 10:21:27 -0700
Content-return: allowed
Date: Tue, 11 Jul 2000 10:21:19 -0700
From: Frank Balluffi <[e-mail]>
Subject: RE: Current signature formats insufficient
To: "'[e-mail]'" <[e-mail]>
Cc: [e-mail]
Message-id: <[e-mail]>
MIME-version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-type: text/plain; charset=iso-8859-1

Denis,

Good point!

I am not sure I would consider this a protocol problem. I think this goes
back to your original point (which I agree with) that computers used by
ordinary people do not boot securely and lack trusted paths to devices. My
guess is that over time computers used by ordinary people will gain these
features. But who knows?

Frank

> -----Original Message-----
> From: denis bider [mailto:[e-mail]]
> Sent: Tuesday, July 11, 2000 1:05 PM
> Cc: [e-mail]
> Subject: RE: Current signature formats insufficient
> 
> 
> [Frank Balluffi in response to Ben Laurie:]
> > For the life of me, I can't imagine a protocol that would expect
> > a device or person to sign a message that only states "...".
> 
> Oh, but there is such a protocol and it is used every day by 
> thousands of
> people. It's called 'a smart card reader'.
> 
> "..." is exactly what a smart card sees when it performs a signature
> operation. Anyone who manages to break the security of the PC 
> (which is
> trivial) can tell the smart card to sign virtually anything.
> 
> This is why I think that we need a more elaborate signature 
> format - one
> which will take the real world, not the ideal world, into account.
> 
> denis
> 


Received: from mail.ec.auckland.ac.nz (mail.student.auckland.ac.nz [130.216.35.201]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id KAA22193 for <[e-mail]>; Tue, 11 Jul 2000 10:27:00 -0700 (PDT)
Received: from kahu.cs.auckland.ac.nz ([e-mail] [130.216.36.13]) by mail.ec.auckland.ac.nz (8.9.3/8.8.6/cs-master) with SMTP id FAA22466; Wed, 12 Jul 2000 05:28:21 +1200 (NZST) (sender [e-mail])
Received: by kahu.cs.auckland.ac.nz (relaymail v0.9) id <96333650129572>; Wed, 12 Jul 2000 05:28:21 (NZST)
From: [e-mail] (Peter Gutmann)
To: [e-mail], [e-mail]
Subject: Re: Current signature formats insufficient
Cc: [e-mail], [e-mail], [e-mail]
Sender: [e-mail]
Reply-To: [e-mail]
X-Charge-To: pgut001
X-Authenticated: relaymail v0.9 on kahu.cs.auckland.ac.nz
Date: Wed, 12 Jul 2000 05:28:21 (NZST)
Message-ID: <[e-mail]>

Paul Koning <[e-mail]> writes:

>I don't understand the notion of a non-binding signature.  To put it
>differently, the purpose of a signature is to bind your identity to some
>assertion.  The only question is what that assertion is.

"I assert through the squiggle I have made on this page that I acknowledge that
without making the squiggle they won't give me a 'Visitor' badge and let me in
the door".

Peter.



Received: from wafw.bear.com (wafw.bear.com [207.162.228.3]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id KAA21908 for <[e-mail]>; Tue, 11 Jul 2000 10:22:16 -0700 (PDT)
Received: from bear.com (localhost [127.0.0.1]) by wafw.bear.com (8.9.3/8.9.2) with SMTP id NAA14991 for <[e-mail]>; Tue, 11 Jul 2000 13:24:07 -0400 (EDT)
Received: from 147.107.147.19 by whmsxvs1.is.bear.com (InterScan E-Mail VirusWall NT); Tue, 11 Jul 2000 13:19:22 -0400 (Eastern Daylight Time)
Received: by whmsx2.is.bear.com with Internet Mail Service (5.5.2448.0) id <33MD3A6Y>; Tue, 11 Jul 2000 13:22:49 -0400
Message-ID: <[e-mail]>
From: "Luo, Feng (Exchange)" <[e-mail]>
To: "'[e-mail]'" <[e-mail]>
Subject: p12 and cer, der,crt
Date: Tue, 11 Jul 2000 13:22:40 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2448.0)
Content-Type: text/plain

Is there a way to convert p12 to cer, der, crt? That a user can install a
certificate himeself on the webpage.

Feng Luo
Security Technologies
and Implementation



***********************************************************************
Bear Stearns is not responsible for any recommendation, solicitation, 
offer or agreement or any information about any transaction, customer 
account or account activity contained in this communication.
***********************************************************************



Received: from levitator.1div0.com ([213.250.43.61]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id KAA21232 for <[e-mail]>; Tue, 11 Jul 2000 10:02:33 -0700 (PDT)
Received: from intergalactic ([10.1.1.2]) by levitator.1div0.com (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with SMTP id SAA20398 for <[e-mail]>; Tue, 11 Jul 2000 18:50:55 +0200
Reply-To: <[e-mail]>
From: "denis bider" <[e-mail]>
Cc: <[e-mail]>
Subject: RE: Current signature formats insufficient
Date: Tue, 11 Jul 2000 19:04:53 +0200
Message-ID: <000101bfeb5a$229c8410$0201010a@intergalactic>
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2910.0)
In-reply-to: <[e-mail]>
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700

[Frank Balluffi in response to Ben Laurie:]
> For the life of me, I can't imagine a protocol that would expect
> a device or person to sign a message that only states "...".

Oh, but there is such a protocol and it is used every day by thousands of
people. It's called 'a smart card reader'.

"..." is exactly what a smart card sees when it performs a signature
operation. Anyone who manages to break the security of the PC (which is
trivial) can tell the smart card to sign virtually anything.

This is why I think that we need a more elaborate signature format - one
which will take the real world, not the ideal world, into account.

denis



Received: from freeby.ben.algroup.co.uk (sockittome.aldigital.co.uk [194.128.162.252]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id JAA16887 for <[e-mail]>; Tue, 11 Jul 2000 09:15:42 -0700 (PDT)
Received: from algroup.co.uk (naughty.ben.algroup.co.uk [193.133.15.107]) by freeby.ben.algroup.co.uk (8.6.12/8.6.12) with ESMTP id RAA16637; Tue, 11 Jul 2000 17:27:55 +0100
Message-ID: <[e-mail]>
Date: Tue, 11 Jul 2000 17:17:00 +0100
From: Ben Laurie <[e-mail]>
Organization: A.L. Group plc
X-Mailer: Mozilla 4.7 [en] (WinNT; I)
MIME-Version: 1.0
To: Paul Koning <[e-mail]>
CC: [e-mail], [e-mail], [e-mail]
Subject: Re: Current signature formats insufficient
References: <[e-mail]> <[e-mail]> <[e-mail]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Paul Koning wrote:
> 
> >>>>> "Ben" == Ben Laurie <[e-mail]> writes:
> 
>  Ben> Frank Balluffi wrote:
>  >>  Denis,
>  >>
>  >> You refer to non-binding signatures. Why would I bother signing
>  >> something if it were non-binding?
> 
>  Ben> When a man comes to the door with a package, I sign it because
>  Ben> he asks for a signature. I do not consider that signature to be
>  Ben> binding in any sense I understand the word.
> 
> I don't understand the notion of a non-binding signature.  To put it
> differently, the purpose of a signature is to bind your identity to
> some assertion.  The only question is what that assertion is.
> 
> It could be "I (insert name) agree to buy 100k shares of FOO
> Corporation".  That would be a "binding" signature in the sense it has
> been discussed.
> 
> But in the example you give, the assertion is "I have received package
> xyz (and consequently agree not to press insurance claims for
> non-delivery of that package".  Is that any less "binding"?  The
> amount of money at stake may be less, so there's a difference in
> degree, but I don't see a difference in essence.

This is really digressing from the point, but that is not the assertion
I am signing - in order for that to be the case, I'd have to see more
than a form with my name (or someone else's) and address on it with a
box saying "signature" on it. If you insist on there being an assertion
linked to the signature, it must be "I am signing in this box like the
man on my doorstep asked". What that might bind me to, I can't imagine.
Nothing, IMO.

Cheers,

Ben.

--
http://www.apache-ssl.org/ben.html

Coming to ApacheCon Europe 2000? http://apachecon.com/


Received: from relay3-gui.server.ntli.net (relay3-gui.server.ntli.net [194.168.4.200]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id JAA16846 for <[e-mail]>; Tue, 11 Jul 2000 09:15:37 -0700 (PDT)
Received: from m235-mp1-cvx1c.hud.ntl.com ([62.252.108.235] helo=dwc-acer) by relay3-gui.server.ntli.net with esmtp (Exim 3.03 #2) id 13C2ZU-0005mN-00; Tue, 11 Jul 2000 17:07:44 +0100
From: "David Chadwick" <[e-mail]>
Organization: University of Salford
To: "David P. Kemp" <[e-mail]>, [e-mail]
Date: Tue, 11 Jul 2000 17:14:37 +0100
MIME-Version: 1.0
Content-type: text/plain; charset=US-ASCII
Content-transfer-encoding: 7BIT
Subject: Re: Operational Protocols - LDAPv3
Reply-to: [e-mail]
Message-ID: <396B55FD.7884.107AAFC4@localhost>
Priority: normal
In-reply-to: <[e-mail]>
X-mailer: Pegasus Mail for Win32 (v3.12c)

> Put another way, clients can use nextUpdate (or not use it) however
> they see fit in fetching information from a repository.  But the only
> value that has any security relevance is thisUpdate -- the time after
> which revocation events will not be reflected in the CRL.

This is surely flawed, for example for e-commerce transactions. 
thisUpdate can only ever be in the past by definition (it can never be 
in the future). Thus a RP can never be sure that the current sender 
of the e-commerce transaction has not been revoked, so who takes 
the hit if he has been and a CRL has or has not been published that 
reflects this?

I think that nextUpdate is important from a liability perspective. If a 
client (RP) uses a CRL after nextUpate time has past, thus 
KNOWING that another one has been issued, and fails to get it, 
then the RP must take the loss if the current certificate has been 
revoked.


If the RP uses a CRL before nextUpdate, when another CRL has 
been issued but he did not get it, again he must take the loss as he 
could have checked if he wanted to. But this is perhaps in the area 
of worms that Marc referred to in his email, depending upon the 
exact meaning of nextUpdate (not before, or not after - the 
standard says not after, which I support. You seem to be saying 
not before).

Finally we have the case of using a CRL before nextUpdate, when 
no other CRL has been issued, but a certificate revocation notice 
has been sent to the CA but it is holding it until the next CRL is due 
to be published. Thus no RP can ever know that the certificate has 
been revoked (without OCSP that is). I would suggest that the CA 
takes the loss in this case. Otherwise if you are suggesting that this 
is still the RPs responsibility it would seem to me that few e-
commerce transactions will ever be instant (except in cases of low 
value transactions) because the RP will wait until it gets a CRL with 
thisUpdate AFTER the time of the transaction.

David


> 
> Regards,
> Dave
> 
> 
> 


***************************************************

David Chadwick
IS Institute, University of Salford, Salford M5 4WT
Tel [phone]  Fax [phone]
Mobile [phone]
Email [e-mail]
Home Page  http://www.salford.ac.uk/its024/chadwick.htm
Understanding X.500  http://www.salford.ac.uk/its024/X500.htm
X.500/LDAP Seminars http://www.salford.ac.uk/its024/seminars.htm
Entrust key validation string MLJ9-DU5T-HV8J

***************************************************


Received: from freeby.ben.algroup.co.uk (sockittome.aldigital.co.uk [194.128.162.252]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id JAA16274 for <[e-mail]>; Tue, 11 Jul 2000 09:08:05 -0700 (PDT)
Received: from algroup.co.uk (naughty.ben.algroup.co.uk [193.133.15.107]) by freeby.ben.algroup.co.uk (8.6.12/8.6.12) with ESMTP id RAA16595; Tue, 11 Jul 2000 17:20:14 +0100
Message-ID: <[e-mail]>
Date: Tue, 11 Jul 2000 17:09:20 +0100
From: Ben Laurie <[e-mail]>
Organization: A.L. Group plc
X-Mailer: Mozilla 4.7 [en] (WinNT; I)
MIME-Version: 1.0
To: Frank Balluffi <[e-mail]>
CC: "'[e-mail]'" <[e-mail]>, [e-mail]
Subject: Re: Current signature formats insufficient
References: <[e-mail]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Frank Balluffi wrote:
> 
> Ben,
> 
> You are signing something you understand or have the right to understand
> (before you sign it). I only hope that the man does not ask you sign a
> message stating, "I agree to pay the man ..."
> 
> I hope that I will never knowingly sign anything I do not understand.

I didn't say I didn't understand it.

Cheers,

Ben.

--
http://www.apache-ssl.org/ben.html

Coming to ApacheCon Europe 2000? http://apachecon.com/


Received: from dfw7-1.relay.mail.uu.net (dfw7-1.relay.mail.uu.net [199.171.54.106]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id IAA13217 for <[e-mail]>; Tue, 11 Jul 2000 08:14:24 -0700 (PDT)
Received: from xedia.com by dfw7sosrv11.alter.net with SMTP  (peer crosschecked as: madway.xedia.com [198.202.232.199]) id QQixjx09807; Tue, 11 Jul 2000 15:16:11 GMT
Received: from tonga.xedia.com by xedia.com (4.1/SMI-4.1) id AA14429; Tue, 11 Jul 00 11:12:21 EDT
Received: by tonga.xedia.com (SMI-8.6/SMI-SVR4) id LAA00137; Tue, 11 Jul 2000 11:16:10 -0400
From: Paul Koning <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-Id: <[e-mail]>
Date: Tue, 11 Jul 2000 11:16:10 -0400 (EDT)
To: [e-mail]
Cc: [e-mail], [e-mail], [e-mail]
Subject: Re: Current signature formats insufficient
References: <[e-mail]> <[e-mail]>
X-Mailer: VM 6.72 under 21.1 (patch 9) "Canyonlands" XEmacs Lucid

>>>>> "Ben" == Ben Laurie <[e-mail]> writes:

 Ben> Frank Balluffi wrote:
 >>  Denis,
 >> 
 >> You refer to non-binding signatures. Why would I bother signing
 >> something if it were non-binding?

 Ben> When a man comes to the door with a package, I sign it because
 Ben> he asks for a signature. I do not consider that signature to be
 Ben> binding in any sense I understand the word.

I don't understand the notion of a non-binding signature.  To put it
differently, the purpose of a signature is to bind your identity to
some assertion.  The only question is what that assertion is.

It could be "I (insert name) agree to buy 100k shares of FOO
Corporation".  That would be a "binding" signature in the sense it has
been discussed.

But in the example you give, the assertion is "I have received package
xyz (and consequently agree not to press insurance claims for
non-delivery of that package".  Is that any less "binding"?  The
amount of money at stake may be less, so there's a difference in
degree, but I don't see a difference in essence.

Similarly the example of authentication for a web banking
application.  Even if you're only looking at information, you're
making an assertion that you're authorized to do the looking (or in
other words, that accesses so authenticated will not later be
challenged as violations of privacy).  Again, the amount of money at
stake changes, but...

      paul


Received: from indy.gradient.com ([e-mail] [192.92.110.1]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id IAA13142 for <[e-mail]>; Tue, 11 Jul 2000 08:14:07 -0700 (PDT)
Received: from bigbird.gradient.com (bigbird.gradient.com [192.92.110.50]) by indy.gradient.com (8.9.1a/8.9.1) with ESMTP id LAA14845; Tue, 11 Jul 2000 11:15:51 -0400 (EDT)
Received: by bigbird.gradient.com with Internet Mail Service (5.5.2448.0) id <3VPQNBRA>; Tue, 11 Jul 2000 11:10:30 -0400
Message-ID: <[e-mail]>
From: Hal Lockhart <[e-mail]>
To: "'[e-mail]'" <[e-mail]>, "'Frank Balluffi'" <[e-mail]>, [e-mail]
Subject: RE: Current signature formats insufficient
Date: Tue, 11 Jul 2000 11:10:29 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2448.0)
Content-Type: text/plain; charset="iso-8859-1"

> in the context of my original message, a "non-binding 
> signature" would be a
> signature for the purposes of, say, authentication.

In past discussions (about the key usage field) on this mailing list, this
has been referred to as an "ephemeral signature".

Hal

=======================================================
Harold W. Lockhart            Entegrity Solutions
2 Mount Royal Avenue          Marlborough, MA 01752 USA
V: 1-508-624-9600 x 260       [e-mail]
F: 1-508-229-0338             www.entegrity.com
=======================================================



Received: from ext-mail.valicert.com (ns1.valicert.com [63.65.221.10]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id IAA12986 for <[e-mail]>; Tue, 11 Jul 2000 08:11:37 -0700 (PDT)
Received: from CONVERSION-DAEMON.ext-mail.valicert.com by ext-mail.valicert.com (PMDF V6.0-24 #46243) id <[e-mail]> for [e-mail]; Tue, 11 Jul 2000 08:13:29 -0700 (PDT)
Received: from seine.valicert.com ([192.168.2.23]) by ext-mail.valicert.com (PMDF V6.0-24 #46243) with ESMTP id <[e-mail]>; Tue, 11 Jul 2000 08:13:28 -0700 (PDT)
Received: by seine.valicert.com with Internet Mail Service (5.5.2650.21) id <3PTBZY4T>; Tue, 11 Jul 2000 08:05:49 -0700
Content-return: allowed
Date: Tue, 11 Jul 2000 08:05:44 -0700
From: Frank Balluffi <[e-mail]>
Subject: RE: Current signature formats insufficient
To: "'Ben Laurie'" <[e-mail]>, Frank Balluffi <[e-mail]>
Cc: "'[e-mail]'" <[e-mail]>, [e-mail]
Message-id: <[e-mail]>
MIME-version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-type: text/plain; charset=iso-8859-1

Ben,

You are signing something you understand or have the right to understand
(before you sign it). I only hope that the man does not ask you sign a
message stating, "I agree to pay the man ..."

I hope that I will never knowingly sign anything I do not understand.

For example, there is a tremendous difference between signing "..." and "I
received [or forwarded] a message whose SHA-1 digest is ...".

I would only sign something that is bound to one or more verbs that I
understand.

For the life of me, I can't imagine a protocol that would expect a device or
person to sign a message that only states "...".

Frank

> -----Original Message-----
> From: Ben Laurie [mailto:[e-mail]]
> Sent: Tuesday, July 11, 2000 11:04 AM
> To: Frank Balluffi
> Cc: '[e-mail]'; [e-mail]
> Subject: Re: Current signature formats insufficient
> 
> 
> Frank Balluffi wrote:
> > 
> > Denis,
> > 
> > You refer to non-binding signatures. Why would I bother 
> signing something if
> > it were non-binding?
> 
> When a man comes to the door with a package, I sign it because he asks
> for a signature. I do not consider that signature to be binding in any
> sense I understand the word.
> 
> Cheers,
> 
> Ben.
> 
> --
> http://www.apache-ssl.org/ben.html
> 
> Coming to ApacheCon Europe 2000? http://apachecon.com/
> 


Received: from freeby.ben.algroup.co.uk (sockittome.aldigital.co.uk [194.128.162.252]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id IAA12582 for <[e-mail]>; Tue, 11 Jul 2000 08:03:45 -0700 (PDT)
Received: from algroup.co.uk (naughty.ben.algroup.co.uk [193.133.15.107]) by freeby.ben.algroup.co.uk (8.6.12/8.6.12) with ESMTP id QAA15950; Tue, 11 Jul 2000 16:14:43 +0100
Message-ID: <[e-mail]>
Date: Tue, 11 Jul 2000 16:03:50 +0100
From: Ben Laurie <[e-mail]>
Organization: A.L. Group plc
X-Mailer: Mozilla 4.7 [en] (WinNT; I)
MIME-Version: 1.0
To: Frank Balluffi <[e-mail]>
CC: "'[e-mail]'" <[e-mail]>, [e-mail]
Subject: Re: Current signature formats insufficient
References: <[e-mail]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Frank Balluffi wrote:
> 
> Denis,
> 
> You refer to non-binding signatures. Why would I bother signing something if
> it were non-binding?

When a man comes to the door with a package, I sign it because he asks
for a signature. I do not consider that signature to be binding in any
sense I understand the word.

Cheers,

Ben.

--
http://www.apache-ssl.org/ben.html

Coming to ApacheCon Europe 2000? http://apachecon.com/


Received: from certplus.com (facteur.certplus.com [195.101.88.81]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id HAA11070 for <[e-mail]>; Tue, 11 Jul 2000 07:30:43 -0700 (PDT)
Received: from certplus.com (nt4_jmd.certplus.com [192.168.1.17]) by certplus.com (8.8.7/8.8.7) with ESMTP id PAA19630 for <[e-mail]>; Tue, 11 Jul 2000 15:02:06 +0200
Message-ID: <[e-mail]>
Date: Tue, 11 Jul 2000 16:32:03 +0200
From: Jean-Marc Desperrier <[e-mail]>
Organization: Certplus
X-Mailer: Mozilla 4.72 [en] (WinNT; I)
X-Accept-Language: en
MIME-Version: 1.0
To: [e-mail]
Subject: Re: Current signature formats insufficient
References: <000d01bfeb3d$113b3ad0$0201010a@intergalactic>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

denis bider wrote:

> Examples: if you sign a contract, that is a binding signature. If you sign a
> purchase order, that is a binding signature. If you sign a cryptographic
> challenge intended for authentication, that is a non-binding signature.

This is what certificates are for.

To do that, you use several different private keys, each being associated with a
certificate that has different usage extensions.

It is already a recommended usage to use a different key for SSL
authentification and to sign a document.

What you are saying is not linked to the format of certificates, but to the way
they are used and the policies that should be enforced for legally binding
signatures.

Nothing in the RFC says, or will or even could say, how a private key has to be
used to be legally binding.
Therefore this is quite out of suject here.

Could you shorten your quoting please ?



Received: from mail-fwd.verio-web.com ([161.58.16.59]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id HAA09693 for <[e-mail]>; Tue, 11 Jul 2000 07:12:26 -0700 (PDT)
Received: from 161.58.117.181 (161.58.117.181) by mail11b.verio-web.com (RS ver 1.0.57s) with SMTP id 02109397; Tue, 11 Jul 2000 10:14:09 -0400 (EDT)
Sender: rsalz
Message-ID: <[e-mail]>
Date: Tue, 11 Jul 2000 10:15:10 -0400
From: Rich Salz <[e-mail]>
X-Mailer: Mozilla 4.72 [en] (X11; U; Linux 2.2.14-5.0 i686)
X-Accept-Language: en
MIME-Version: 1.0
To: "David P. Kemp" <[e-mail]>
CC: [e-mail]
Subject: Re: Operational Protocols - LDAPv3
References: <[e-mail]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
X-Loop-Detect: 1

> Put another way, clients can use nextUpdate (or not use it) however
> they see fit in fetching information from a repository.  But the only
> value that has any security relevance is thisUpdate -- the time after
> which revocation events will not be reflected in the CRL.

I agree with this.

I also believe that, if the connection to the repository is
authenticated,
then a client can detect "old data" attacks.  It is worth noting this
in the RFC.


Received: from ext-mail.valicert.com (ns1.valicert.com [63.65.221.10]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id HAA08814 for <[e-mail]>; Tue, 11 Jul 2000 07:01:55 -0700 (PDT)
Received: from CONVERSION-DAEMON.ext-mail.valicert.com by ext-mail.valicert.com (PMDF V6.0-24 #46243) id <[e-mail]> for [e-mail]; Tue, 11 Jul 2000 07:03:46 -0700 (PDT)
Received: from seine.valicert.com ([192.168.2.23]) by ext-mail.valicert.com (PMDF V6.0-24 #46243) with ESMTP id <[e-mail]>; Tue, 11 Jul 2000 07:03:46 -0700 (PDT)
Received: by seine.valicert.com with Internet Mail Service (5.5.2650.21) id <3PTBZYNN>; Tue, 11 Jul 2000 06:56:07 -0700
Content-return: allowed
Date: Tue, 11 Jul 2000 06:56:03 -0700
From: Frank Balluffi <[e-mail]>
Subject: RE: Current signature formats insufficient
To: "'[e-mail]'" <[e-mail]>, Frank Balluffi <[e-mail]>, [e-mail]
Message-id: <[e-mail]>
MIME-version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-type: text/plain; charset=iso-8859-1

Denis,

By convention, many standards (e.g., protocols) represent a signature with a
SEQUENCE containing an AlgorithmIdentifier and a BIT STRING. If your use of
current signature formats refers to the above convention, I am not convinced
that the problem is with the signature format. Perhaps the problem is with
what you sign.

In the case of an authentication protocol, you could include an OBJECT
IDENTIFIER or string in the data to be signed to constrain the use of the
signature. For example:

AuthenticationInfo ::= SEQUENCE {
    disclaimer UTF8String,
    nonce      OCTET STRING
}

Another technique would be to use PKCS #7 authenticated attributes.

Could these be used to solve your problem?

I'm still a little confused about what problem you are trying to solve.

Frank

> -----Original Message-----
> From: denis bider [mailto:[e-mail]]
> Sent: Tuesday, July 11, 2000 9:37 AM
> To: 'Frank Balluffi'; [e-mail]
> Subject: RE: Current signature formats insufficient
> 
> 
> Hello Frank,
> 
> in the context of my original message, a "non-binding 
> signature" would be a
> signature for the purposes of, say, authentication.
> 
> Suppose you are connecting to a secure website - say, an e-banking
> application - that requires private key authentication. For 
> the purposes of
> authentication, your equipment will have to sign a challenge 
> that is sent to
> you from the server. Now, since this signing process is 
> intended only for
> authentication, you want the resulting signature to reflect 
> this fact. You
> don't want to find yourself in a situation where you signed 
> something that
> you thought was intended only for authentication, only to 
> find later that it
> was in fact the hash of a contract that you have never seen before.
> 
> To sum up: for the scope of this discussion, we could vaguely 
> define that a
> signature is "binding" if it can be used as a legal tool to 
> force the signer
> to do something or not to do something. Otherwise, a signature is
> "non-binding".
> 
> Examples: if you sign a contract, that is a binding 
> signature. If you sign a
> purchase order, that is a binding signature. If you sign a 
> cryptographic
> challenge intended for authentication, that is a non-binding 
> signature.
> 
> Regards,
> 
> denis
> 
> 
> -----Original Message-----
> From: Frank Balluffi [mailto:[e-mail]]
> Sent: 11. julij 2000 14:49
> To: '[e-mail]'; [e-mail]
> Subject: RE: Current signature formats insufficient
> 
> 
> Denis,
> 
> You refer to non-binding signatures. Why would I bother 
> signing something if
> it were non-binding?
> 
> Frank
> 
> > -----Original Message-----
> > From: denis bider [mailto:[e-mail]]
> > Sent: Tuesday, July 11, 2000 4:42 AM
> > To: [e-mail]
> > Subject: Current signature formats insufficient
> >
> >
> > Hello folks,
> >
> > we probably agree that smart cards, as well as a variety of
> > other similar
> > cryptographic tokens, are insecure. Their primary insecurity
> > lies not within
> > the tokens themselves, but rather in the way they are most
> > commonly used.
> > Most frequently, a cryptographic token is attached to a PC,
> > and it does
> > whatever cryptographic operation the PC tells it to do.
> >
> > This concept is obviously insecure, since:
> >  - PCs are insecure. Every average hacker down the street can
> > break into
> > anyone's Windoze PC, and it is trivial to write an exploit
> > that will capture
> > a smart card's PIN, wait for the smart card to be inserted
> > and then perform
> > a signature operation.
> >  - Even if the user is as security conscious as to use a
> > secure PIN entry
> > device, or a fingerprint scanner for that matter, it is still
> > the PC that
> > decides exactly what information the smart card is going to
> > sign. It is
> > again trivial to write an exploit that will make the smart card sign
> > something that the owner did not mean to sign.
> >
> > With the advent of digital signature laws which make digital signing
> > commonplace, it is time to remove these security holes before
> > hackers and
> > newspaper articles start popping up. (How would any of you 
> smart card
> > manufacturers like to see your company's name placed
> > conveniently next to
> > "FRAUD!!" in TIME Magazine?)
> >
> > The ultimate solution, of course, would be for everyone to
> > have a secure
> > device, containing the private key, with the following
> > characteristics:
> >  - In order to sign anything, the user must put their finger on the
> > fingerprint scanner. (Or other biometrics...)
> >  - In case the signature is binding (ie, contract as opposed to
> > authentication), the user must check the contents being
> > signed on the screen
> > of the secure device.
> >  - In case the signature is binding, the user must enter a signature
> > passphrase (PIN) as well.
> >
> > Now, since users do not want to enter passphrases every time
> > something needs
> > to be signed, and since that would be dangerous in the first place
> > (increased risk of passphrase exposure), there is a practical
> > need for the
> > secure device to be able to distinguish between a binding
> > signature and a
> > non-binding signature.
> >
> > In the case of a non-binding signature (eg, proof of
> > identity), the behavior
> > of the secure device could simply match the behavior of all the
> > cryptographic tokens currently out there. Ie, the device
> > would sign anything
> > that it receives - most commonly a hash of something -
> > provided that the
> > user confirms the signature operation by putting their finger on the
> > fingerpring scanner. However, in contrast to the 
> cryptographic tokens
> > currently being used, any such signature would be explicitly
> > marked that it
> > cannot be considered binding.
> >
> > In the case of a binding signature (eg, a contract), the
> > secure device would
> > insist on receiving the entire content that is being signed,
> > formatted in a
> > well-known and secure format, so that the content can be
> > shown to the user
> > before anything can be signed. The user would also need to
> > authenticate
> > themselves in a more secure manner before a binding signature
> > is made; and
> > when it is made, the signature would be explicitly marked
> > that it CAN be
> > considered binding.
> >
> > It is my opinion that the following efforts need to be made:
> >  - The current signature formats need to be extended so as 
> to include
> > information about the extent to which the data being signed
> > was verified by
> > the signer - or simply whether the signature can be
> > interpreted as binding
> > or not.
> >  - A format for binding content needs to be selected or
> > defined. (RTF, ASCII
> > text, anything?) - this is the format in which any binding
> > content is sent
> > to the secure device so that it can be shown to the user, 
> who in turn
> > decides whether to sign it or not.
> >  - The current APIs for communication with cryptographic
> > tokens need to be
> > modified to support this. Eg, in PKCS#11, the following modes
> > of signature
> > could be introduced:
> >         - sign this hash and mark the signature as non-binding
> >         - here is the 34kB file containing the binding
> > content to be signed,
> > show it to the signer, sign it and mark it as binding
> >         - here is a hash of the binding content to be signed,
> > sign it and
> > mark it as binding (deprecated, but must be included since it
> > is not yet
> > possible to transmit 34kB of data to every kind of
> > cryptographic token)
> >
> > I feel that the above issues are important and that somebody
> > needs to take
> > them on. I cannot decide whether or not this workgroup should
> > do it; but
> > somebody has to. (Or else...)
> >
> > Comments are welcome. Also, does anyone have information 
> whether these
> > issues have been addressed by the xmldsig workgroup, or is
> > their format as
> > clueless as the ASN.1 signature format?
> >
> > Regards,
> >
> > denis bider
> >
> > //
> > //  denis bider, [e-mail]
> > // [alternative: [e-mail]]
> > //  globera d.o.o., Ljubljana, Slovenia
> >     http://www.globera.com
> >     [phone]
> >
> >
> >
> 


Received: from ra.bpsi.net (ra.bpsi.net [199.199.134.1]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id HAA08736 for <[e-mail]>; Tue, 11 Jul 2000 07:00:53 -0700 (PDT)
Received: from bpsi.net (port422.bpsi.net [209.54.245.222]) by ra.bpsi.net (8.9.0/8.9.0) with ESMTP id JAA25646; Tue, 11 Jul 2000 09:02:38 -0500 (CDT)
Message-ID: <[e-mail]>
Date: Tue, 11 Jul 2000 09:01:01 -0500
From: Dale Gustafson <[e-mail]>
X-Mailer: Mozilla 4.73 [en]C-CCK-MCD NSCPCD47  (Win95; U)
X-Accept-Language: en,pdf
MIME-Version: 1.0
To: [e-mail]
CC: [e-mail]
Subject: Re: Current signature formats insufficient
References: <000001bfeb13$d25fe870$0201010a@intergalactic>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Denis,

Take a closer look at the "Signing Key with Secondary Authentication PIN"
capabilities added to PKCS#11 v2.10.  Works with optional Secure PINPad readers
such that the PIN values are not known to PC software.  This feature can be used
to provide the "user must enter a special PIN for each and every signature
created" functionality you describe.  An application could create a key that is
used only for signing binding / contract documents, etc. thus providing one
clear indication that a "non-repudiation" service is being provided.  This
approach is different than adding bits to a signature block but provides a
similar effect.  I agree that the secure application should be specifically
requesting a distinct signature service (signalled to relying parties by use of
a dedicated signing key and certificate).

Cryptographic tokens typically provide 2-factor authentication -- something you
have (the physical card) and something you know (the User PIN / Passphrase).
This is clearly more secure and portable than storing your security information
on your PC hard drive.  Nevertheless, any scenario that defeats both factors
eliminates the additional security provided by the token.  For example; if
someone threatens you, takes your token away, and makes you tell her your PINs
then your smart token and any private keys stored within can no longer be
considered secure.

The problem with any all singing / all dancing technical solution is that in
order to make the smart token really nifty you have to provide much of the
functionality of your Windows PC (e.g. so you can see the web page or movie clip
you're signing).  You can go to three-factor authentication (something you have,
something you know, something you are) and beyond but there's invariably a point
of diminishing returns for any real network, user community, and applications.

Best Regards,

Dale Gustafson


denis bider wrote:

> Hello folks,
>
> we probably agree that smart cards, as well as a variety of other similar
> cryptographic tokens, are insecure. Their primary insecurity lies not within
> the tokens themselves, but rather in the way they are most commonly used.
> Most frequently, a cryptographic token is attached to a PC, and it does
> whatever cryptographic operation the PC tells it to do.
>
> This concept is obviously insecure, since:
>  - PCs are insecure. Every average hacker down the street can break into
> anyone's Windoze PC, and it is trivial to write an exploit that will capture
> a smart card's PIN, wait for the smart card to be inserted and then perform
> a signature operation.
>  - Even if the user is as security conscious as to use a secure PIN entry
> device, or a fingerprint scanner for that matter, it is still the PC that
> decides exactly what information the smart card is going to sign. It is
> again trivial to write an exploit that will make the smart card sign
> something that the owner did not mean to sign.
>
> With the advent of digital signature laws which make digital signing
> commonplace, it is time to remove these security holes before hackers and
> newspaper articles start popping up. (How would any of you smart card
> manufacturers like to see your company's name placed conveniently next to
> "FRAUD!!" in TIME Magazine?)
>
> The ultimate solution, of course, would be for everyone to have a secure
> device, containing the private key, with the following characteristics:
>  - In order to sign anything, the user must put their finger on the
> fingerprint scanner. (Or other biometrics...)
>  - In case the signature is binding (ie, contract as opposed to
> authentication), the user must check the contents being signed on the screen
> of the secure device.
>  - In case the signature is binding, the user must enter a signature
> passphrase (PIN) as well.
>
> Now, since users do not want to enter passphrases every time something needs
> to be signed, and since that would be dangerous in the first place
> (increased risk of passphrase exposure), there is a practical need for the
> secure device to be able to distinguish between a binding signature and a
> non-binding signature.
>
> In the case of a non-binding signature (eg, proof of identity), the behavior
> of the secure device could simply match the behavior of all the
> cryptographic tokens currently out there. Ie, the device would sign anything
> that it receives - most commonly a hash of something - provided that the
> user confirms the signature operation by putting their finger on the
> fingerpring scanner. However, in contrast to the cryptographic tokens
> currently being used, any such signature would be explicitly marked that it
> cannot be considered binding.
>
> In the case of a binding signature (eg, a contract), the secure device would
> insist on receiving the entire content that is being signed, formatted in a
> well-known and secure format, so that the content can be shown to the user
> before anything can be signed. The user would also need to authenticate
> themselves in a more secure manner before a binding signature is made; and
> when it is made, the signature would be explicitly marked that it CAN be
> considered binding.
>
> It is my opinion that the following efforts need to be made:
>  - The current signature formats need to be extended so as to include
> information about the extent to which the data being signed was verified by
> the signer - or simply whether the signature can be interpreted as binding
> or not.
>  - A format for binding content needs to be selected or defined. (RTF, ASCII
> text, anything?) - this is the format in which any binding content is sent
> to the secure device so that it can be shown to the user, who in turn
> decides whether to sign it or not.
>  - The current APIs for communication with cryptographic tokens need to be
> modified to support this. Eg, in PKCS#11, the following modes of signature
> could be introduced:
>         - sign this hash and mark the signature as non-binding
>         - here is the 34kB file containing the binding content to be signed,
> show it to the signer, sign it and mark it as binding
>         - here is a hash of the binding content to be signed, sign it and
> mark it as binding (deprecated, but must be included since it is not yet
> possible to transmit 34kB of data to every kind of cryptographic token)
>
> I feel that the above issues are important and that somebody needs to take
> them on. I cannot decide whether or not this workgroup should do it; but
> somebody has to. (Or else...)
>
> Comments are welcome. Also, does anyone have information whether these
> issues have been addressed by the xmldsig workgroup, or is their format as
> clueless as the ASN.1 signature format?
>
> Regards,
>
> denis bider
>
> //
> //  denis bider, [e-mail]
> // [alternative: [e-mail]]
> //  globera d.o.o., Ljubljana, Slovenia
>     http://www.globera.com
>     [phone]



Received: from spdl139-tr0.dexia.be (mail.dexia.be [193.91.97.4]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id GAA08668 for <[e-mail]>; Tue, 11 Jul 2000 06:59:28 -0700 (PDT)
Date: 11 Jul 2000 15:57:44 +0200
From: Thierry Van Doninck <[e-mail]>
To: "denis.bider" <[e-mail]>
Subject: RE: Current signature formats insufficient
Message-Id: <056E4396B27D804B*/c=be/admd=publilink/prmd=gkbccb/o=notes/s=SY064/@MHS>

Hi,

Another example of a non-binding signature : the signature could just be used to assure the integrety of a message.

Thierry





denis.bider%globera.com@Internet
11/07/2000 15:34
To:	frankb%valicert.com@Internet, ietf-pkix%imc.org@Internet
cc:	 (bcc: Thierry Van Doninck/GKBCCB)

Subject:	RE: Current signature formats insufficient

Hello Frank,

in the context of my original message, a "non-binding signature" would be a
signature for the purposes of, say, authentication.

Suppose you are connecting to a secure website - say, an e-banking
application - that requires private key authentication. For the purposes of
authentication, your equipment will have to sign a challenge that is sent to
you from the server. Now, since this signing process is intended only for
authentication, you want the resulting signature to reflect this fact. You
don't want to find yourself in a situation where you signed something that
you thought was intended only for authentication, only to find later that it
was in fact the hash of a contract that you have never seen before.

To sum up: for the scope of this discussion, we could vaguely define that a
signature is "binding" if it can be used as a legal tool to force the signer
to do something or not to do something. Otherwise, a signature is
"non-binding".

Examples: if you sign a contract, that is a binding signature. If you sign a
purchase order, that is a binding signature. If you sign a cryptographic
challenge intended for authentication, that is a non-binding signature.

Regards,

denis


-----Original Message-----
From: Frank Balluffi [mailto:[e-mail]]
Sent: 11. julij 2000 14:49
To: '[e-mail]'; [e-mail]
Subject: RE: Current signature formats insufficient


Denis,

You refer to non-binding signatures. Why would I bother signing something if
it were non-binding?

Frank

> -----Original Message-----
> From: denis bider [mailto:[e-mail]]
> Sent: Tuesday, July 11, 2000 4:42 AM
> To: [e-mail]
> Subject: Current signature formats insufficient
>
>
> Hello folks,
>
> we probably agree that smart cards, as well as a variety of
> other similar
> cryptographic tokens, are insecure. Their primary insecurity
> lies not within
> the tokens themselves, but rather in the way they are most
> commonly used.
> Most frequently, a cryptographic token is attached to a PC,
> and it does
> whatever cryptographic operation the PC tells it to do.
>
> This concept is obviously insecure, since:
>  - PCs are insecure. Every average hacker down the street can
> break into
> anyone's Windoze PC, and it is trivial to write an exploit
> that will capture
> a smart card's PIN, wait for the smart card to be inserted
> and then perform
> a signature operation.
>  - Even if the user is as security conscious as to use a
> secure PIN entry
> device, or a fingerprint scanner for that matter, it is still
> the PC that
> decides exactly what information the smart card is going to
> sign. It is
> again trivial to write an exploit that will make the smart card sign
> something that the owner did not mean to sign.
>
> With the advent of digital signature laws which make digital signing
> commonplace, it is time to remove these security holes before
> hackers and
> newspaper articles start popping up. (How would any of you smart card
> manufacturers like to see your company's name placed
> conveniently next to
> "FRAUD!!" in TIME Magazine?)
>
> The ultimate solution, of course, would be for everyone to
> have a secure
> device, containing the private key, with the following
> characteristics:
>  - In order to sign anything, the user must put their finger on the
> fingerprint scanner. (Or other biometrics...)
>  - In case the signature is binding (ie, contract as opposed to
> authentication), the user must check the contents being
> signed on the screen
> of the secure device.
>  - In case the signature is binding, the user must enter a signature
> passphrase (PIN) as well.
>
> Now, since users do not want to enter passphrases every time
> something needs
> to be signed, and since that would be dangerous in the first place
> (increased risk of passphrase exposure), there is a practical
> need for the
> secure device to be able to distinguish between a binding
> signature and a
> non-binding signature.
>
> In the case of a non-binding signature (eg, proof of
> identity), the behavior
> of the secure device could simply match the behavior of all the
> cryptographic tokens currently out there. Ie, the device
> would sign anything
> that it receives - most commonly a hash of something -
> provided that the
> user confirms the signature operation by putting their finger on the
> fingerpring scanner. However, in contrast to the cryptographic tokens
> currently being used, any such signature would be explicitly
> marked that it
> cannot be considered binding.
>
> In the case of a binding signature (eg, a contract), the
> secure device would
> insist on receiving the entire content that is being signed,
> formatted in a
> well-known and secure format, so that the content can be
> shown to the user
> before anything can be signed. The user would also need to
> authenticate
> themselves in a more secure manner before a binding signature
> is made; and
> when it is made, the signature would be explicitly marked
> that it CAN be
> considered binding.
>
> It is my opinion that the following efforts need to be made:
>  - The current signature formats need to be extended so as to include
> information about the extent to which the data being signed
> was verified by
> the signer - or simply whether the signature can be
> interpreted as binding
> or not.
>  - A format for binding content needs to be selected or
> defined. (RTF, ASCII
> text, anything?) - this is the format in which any binding
> content is sent
> to the secure device so that it can be shown to the user, who in turn
> decides whether to sign it or not.
>  - The current APIs for communication with cryptographic
> tokens need to be
> modified to support this. Eg, in PKCS#11, the following modes
> of signature
> could be introduced:
>         - sign this hash and mark the signature as non-binding
>         - here is the 34kB file containing the binding
> content to be signed,
> show it to the signer, sign it and mark it as binding
>         - here is a hash of the binding content to be signed,
> sign it and
> mark it as binding (deprecated, but must be included since it
> is not yet
> possible to transmit 34kB of data to every kind of
> cryptographic token)
>
> I feel that the above issues are important and that somebody
> needs to take
> them on. I cannot decide whether or not this workgroup should
> do it; but
> somebody has to. (Or else...)
>
> Comments are welcome. Also, does anyone have information whether these
> issues have been addressed by the xmldsig workgroup, or is
> their format as
> clueless as the ASN.1 signature format?
>
> Regards,
>
> denis bider
>
> //
> //  denis bider, [e-mail]
> // [alternative: [e-mail]]
> //  globera d.o.o., Ljubljana, Slovenia
>     http://www.globera.com
>     [phone]
>
>
>





Received: from levitator.1div0.com ([213.250.43.61]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id GAA07561 for <[e-mail]>; Tue, 11 Jul 2000 06:34:33 -0700 (PDT)
Received: from intergalactic ([10.1.1.2]) by levitator.1div0.com (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with SMTP id PAA20004; Tue, 11 Jul 2000 15:22:52 +0200
Reply-To: <[e-mail]>
From: "denis bider" <[e-mail]>
To: "'Frank Balluffi'" <[e-mail]>, <[e-mail]>
Subject: RE: Current signature formats insufficient
Date: Tue, 11 Jul 2000 15:36:49 +0200
Message-ID: <000d01bfeb3d$113b3ad0$0201010a@intergalactic>
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2910.0)
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700
In-reply-to: <[e-mail]>

Hello Frank,

in the context of my original message, a "non-binding signature" would be a
signature for the purposes of, say, authentication.

Suppose you are connecting to a secure website - say, an e-banking
application - that requires private key authentication. For the purposes of
authentication, your equipment will have to sign a challenge that is sent to
you from the server. Now, since this signing process is intended only for
authentication, you want the resulting signature to reflect this fact. You
don't want to find yourself in a situation where you signed something that
you thought was intended only for authentication, only to find later that it
was in fact the hash of a contract that you have never seen before.

To sum up: for the scope of this discussion, we could vaguely define that a
signature is "binding" if it can be used as a legal tool to force the signer
to do something or not to do something. Otherwise, a signature is
"non-binding".

Examples: if you sign a contract, that is a binding signature. If you sign a
purchase order, that is a binding signature. If you sign a cryptographic
challenge intended for authentication, that is a non-binding signature.

Regards,

denis


-----Original Message-----
From: Frank Balluffi [mailto:[e-mail]]
Sent: 11. julij 2000 14:49
To: '[e-mail]'; [e-mail]
Subject: RE: Current signature formats insufficient


Denis,

You refer to non-binding signatures. Why would I bother signing something if
it were non-binding?

Frank

> -----Original Message-----
> From: denis bider [mailto:[e-mail]]
> Sent: Tuesday, July 11, 2000 4:42 AM
> To: [e-mail]
> Subject: Current signature formats insufficient
>
>
> Hello folks,
>
> we probably agree that smart cards, as well as a variety of
> other similar
> cryptographic tokens, are insecure. Their primary insecurity
> lies not within
> the tokens themselves, but rather in the way they are most
> commonly used.
> Most frequently, a cryptographic token is attached to a PC,
> and it does
> whatever cryptographic operation the PC tells it to do.
>
> This concept is obviously insecure, since:
>  - PCs are insecure. Every average hacker down the street can
> break into
> anyone's Windoze PC, and it is trivial to write an exploit
> that will capture
> a smart card's PIN, wait for the smart card to be inserted
> and then perform
> a signature operation.
>  - Even if the user is as security conscious as to use a
> secure PIN entry
> device, or a fingerprint scanner for that matter, it is still
> the PC that
> decides exactly what information the smart card is going to
> sign. It is
> again trivial to write an exploit that will make the smart card sign
> something that the owner did not mean to sign.
>
> With the advent of digital signature laws which make digital signing
> commonplace, it is time to remove these security holes before
> hackers and
> newspaper articles start popping up. (How would any of you smart card
> manufacturers like to see your company's name placed
> conveniently next to
> "FRAUD!!" in TIME Magazine?)
>
> The ultimate solution, of course, would be for everyone to
> have a secure
> device, containing the private key, with the following
> characteristics:
>  - In order to sign anything, the user must put their finger on the
> fingerprint scanner. (Or other biometrics...)
>  - In case the signature is binding (ie, contract as opposed to
> authentication), the user must check the contents being
> signed on the screen
> of the secure device.
>  - In case the signature is binding, the user must enter a signature
> passphrase (PIN) as well.
>
> Now, since users do not want to enter passphrases every time
> something needs
> to be signed, and since that would be dangerous in the first place
> (increased risk of passphrase exposure), there is a practical
> need for the
> secure device to be able to distinguish between a binding
> signature and a
> non-binding signature.
>
> In the case of a non-binding signature (eg, proof of
> identity), the behavior
> of the secure device could simply match the behavior of all the
> cryptographic tokens currently out there. Ie, the device
> would sign anything
> that it receives - most commonly a hash of something -
> provided that the
> user confirms the signature operation by putting their finger on the
> fingerpring scanner. However, in contrast to the cryptographic tokens
> currently being used, any such signature would be explicitly
> marked that it
> cannot be considered binding.
>
> In the case of a binding signature (eg, a contract), the
> secure device would
> insist on receiving the entire content that is being signed,
> formatted in a
> well-known and secure format, so that the content can be
> shown to the user
> before anything can be signed. The user would also need to
> authenticate
> themselves in a more secure manner before a binding signature
> is made; and
> when it is made, the signature would be explicitly marked
> that it CAN be
> considered binding.
>
> It is my opinion that the following efforts need to be made:
>  - The current signature formats need to be extended so as to include
> information about the extent to which the data being signed
> was verified by
> the signer - or simply whether the signature can be
> interpreted as binding
> or not.
>  - A format for binding content needs to be selected or
> defined. (RTF, ASCII
> text, anything?) - this is the format in which any binding
> content is sent
> to the secure device so that it can be shown to the user, who in turn
> decides whether to sign it or not.
>  - The current APIs for communication with cryptographic
> tokens need to be
> modified to support this. Eg, in PKCS#11, the following modes
> of signature
> could be introduced:
>         - sign this hash and mark the signature as non-binding
>         - here is the 34kB file containing the binding
> content to be signed,
> show it to the signer, sign it and mark it as binding
>         - here is a hash of the binding content to be signed,
> sign it and
> mark it as binding (deprecated, but must be included since it
> is not yet
> possible to transmit 34kB of data to every kind of
> cryptographic token)
>
> I feel that the above issues are important and that somebody
> needs to take
> them on. I cannot decide whether or not this workgroup should
> do it; but
> somebody has to. (Or else...)
>
> Comments are welcome. Also, does anyone have information whether these
> issues have been addressed by the xmldsig workgroup, or is
> their format as
> clueless as the ASN.1 signature format?
>
> Regards,
>
> denis bider
>
> //
> //  denis bider, [e-mail]
> // [alternative: [e-mail]]
> //  globera d.o.o., Ljubljana, Slovenia
>     http://www.globera.com
>     [phone]
>
>
>



Received: from levitator.1div0.com ([213.250.43.61]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id GAA06558 for <[e-mail]>; Tue, 11 Jul 2000 06:17:29 -0700 (PDT)
Received: from intergalactic ([10.1.1.2]) by levitator.1div0.com (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with SMTP id PAA19957; Tue, 11 Jul 2000 15:05:47 +0200
Reply-To: <[e-mail]>
From: "denis bider" <[e-mail]>
To: "'Michael Zolotarev'" <[e-mail]>, <[e-mail]>
Subject: RE: Current signature formats insufficient
Date: Tue, 11 Jul 2000 15:19:44 +0200
Message-ID: <000c01bfeb3a$ae4e2290$0201010a@intergalactic>
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2910.0)
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700
In-reply-to: <[e-mail]>

Hello Michael,

I'm not sure I understand you correctly.

To attempt an explanation: I used the 'fingerprint' example because I like
this particular technology, because I believe it to be more practical than,
say, a retina scan, and because it is my perception that it is readily
accessible for widespread use.

I am not, however, involved with the production of any secure device such as
the one I described in the original message. There is no commercial
background to my proposal - at least none that I am aware of at this time.

Regards,

denis


-----Original Message-----
From: Michael Zolotarev [mailto:[e-mail]]
Sent: 11. julij 2000 13:39
To: [e-mail]; [e-mail]
Subject: RE: Current signature formats insufficient


Don't you find that there is a little bit too much of a 'finger' stuff in
there... What would be a name for the box?

:)


> -----Original Message-----
> From: denis bider [mailto:[e-mail]]
> Sent: Tuesday, July 11, 2000 6:42 PM
> To: [e-mail]
> Subject: Current signature formats insufficient
>
>
> Hello folks,
>
> we probably agree that smart cards, as well as a variety of
> other similar
> cryptographic tokens, are insecure. Their primary insecurity
> lies not within
> the tokens themselves, but rather in the way they are most
> commonly used.
> Most frequently, a cryptographic token is attached to a PC,
> and it does
> whatever cryptographic operation the PC tells it to do.
>
> This concept is obviously insecure, since:
>  - PCs are insecure. Every average hacker down the street can
> break into
> anyone's Windoze PC, and it is trivial to write an exploit
> that will capture
> a smart card's PIN, wait for the smart card to be inserted
> and then perform
> a signature operation.
>  - Even if the user is as security conscious as to use a
> secure PIN entry
> device, or a fingerprint scanner for that matter, it is still
> the PC that
> decides exactly what information the smart card is going to
> sign. It is
> again trivial to write an exploit that will make the smart card sign
> something that the owner did not mean to sign.
>
> With the advent of digital signature laws which make digital signing
> commonplace, it is time to remove these security holes before
> hackers and
> newspaper articles start popping up. (How would any of you smart card
> manufacturers like to see your company's name placed
> conveniently next to
> "FRAUD!!" in TIME Magazine?)
>
> The ultimate solution, of course, would be for everyone to
> have a secure
> device, containing the private key, with the following
> characteristics:
>  - In order to sign anything, the user must put their finger on the
> fingerprint scanner. (Or other biometrics...)
>  - In case the signature is binding (ie, contract as opposed to
> authentication), the user must check the contents being
> signed on the screen
> of the secure device.
>  - In case the signature is binding, the user must enter a signature
> passphrase (PIN) as well.
>
> Now, since users do not want to enter passphrases every time
> something needs
> to be signed, and since that would be dangerous in the first place
> (increased risk of passphrase exposure), there is a practical
> need for the
> secure device to be able to distinguish between a binding
> signature and a
> non-binding signature.
>
> In the case of a non-binding signature (eg, proof of
> identity), the behavior
> of the secure device could simply match the behavior of all the
> cryptographic tokens currently out there. Ie, the device
> would sign anything
> that it receives - most commonly a hash of something -
> provided that the
> user confirms the signature operation by putting their finger on the
> fingerpring scanner. However, in contrast to the cryptographic tokens
> currently being used, any such signature would be explicitly
> marked that it
> cannot be considered binding.
>
> In the case of a binding signature (eg, a contract), the
> secure device would
> insist on receiving the entire content that is being signed,
> formatted in a
> well-known and secure format, so that the content can be
> shown to the user
> before anything can be signed. The user would also need to
> authenticate
> themselves in a more secure manner before a binding signature
> is made; and
> when it is made, the signature would be explicitly marked
> that it CAN be
> considered binding.
>
> It is my opinion that the following efforts need to be made:
>  - The current signature formats need to be extended so as to include
> information about the extent to which the data being signed
> was verified by
> the signer - or simply whether the signature can be
> interpreted as binding
> or not.
>  - A format for binding content needs to be selected or
> defined. (RTF, ASCII
> text, anything?) - this is the format in which any binding
> content is sent
> to the secure device so that it can be shown to the user, who in turn
> decides whether to sign it or not.
>  - The current APIs for communication with cryptographic
> tokens need to be
> modified to support this. Eg, in PKCS#11, the following modes
> of signature
> could be introduced:
>         - sign this hash and mark the signature as non-binding
>         - here is the 34kB file containing the binding
> content to be signed,
> show it to the signer, sign it and mark it as binding
>         - here is a hash of the binding content to be signed,
> sign it and
> mark it as binding (deprecated, but must be included since it
> is not yet
> possible to transmit 34kB of data to every kind of
> cryptographic token)
>
> I feel that the above issues are important and that somebody
> needs to take
> them on. I cannot decide whether or not this workgroup should
> do it; but
> somebody has to. (Or else...)
>
> Comments are welcome. Also, does anyone have information whether these
> issues have been addressed by the xmldsig workgroup, or is
> their format as
> clueless as the ASN.1 signature format?
>
> Regards,
>
> denis bider
>
> //
> //  denis bider, [e-mail]
> // [alternative: [e-mail]]
> //  globera d.o.o., Ljubljana, Slovenia
>     http://www.globera.com
>     [phone]
>
>
>



Received: from ext-mail.valicert.com (ns1.valicert.com [63.65.221.10]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id FAA05462 for <[e-mail]>; Tue, 11 Jul 2000 05:54:34 -0700 (PDT)
Received: from CONVERSION-DAEMON.ext-mail.valicert.com by ext-mail.valicert.com (PMDF V6.0-24 #46243) id <[e-mail]> for [e-mail]; Tue, 11 Jul 2000 05:56:20 -0700 (PDT)
Received: from seine.valicert.com ([192.168.2.23]) by ext-mail.valicert.com (PMDF V6.0-24 #46243) with ESMTP id <[e-mail]>; Tue, 11 Jul 2000 05:56:20 -0700 (PDT)
Received: by seine.valicert.com with Internet Mail Service (5.5.2650.21) id <3PTBZY22>; Tue, 11 Jul 2000 05:48:41 -0700
Content-return: allowed
Date: Tue, 11 Jul 2000 05:48:37 -0700
From: Frank Balluffi <[e-mail]>
Subject: RE: Current signature formats insufficient
To: "'[e-mail]'" <[e-mail]>, [e-mail]
Message-id: <[e-mail]>
MIME-version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-type: text/plain; charset=iso-8859-1

Denis,

You refer to non-binding signatures. Why would I bother signing something if
it were non-binding?

Frank

> -----Original Message-----
> From: denis bider [mailto:[e-mail]]
> Sent: Tuesday, July 11, 2000 4:42 AM
> To: [e-mail]
> Subject: Current signature formats insufficient
> 
> 
> Hello folks,
> 
> we probably agree that smart cards, as well as a variety of 
> other similar
> cryptographic tokens, are insecure. Their primary insecurity 
> lies not within
> the tokens themselves, but rather in the way they are most 
> commonly used.
> Most frequently, a cryptographic token is attached to a PC, 
> and it does
> whatever cryptographic operation the PC tells it to do.
> 
> This concept is obviously insecure, since:
>  - PCs are insecure. Every average hacker down the street can 
> break into
> anyone's Windoze PC, and it is trivial to write an exploit 
> that will capture
> a smart card's PIN, wait for the smart card to be inserted 
> and then perform
> a signature operation.
>  - Even if the user is as security conscious as to use a 
> secure PIN entry
> device, or a fingerprint scanner for that matter, it is still 
> the PC that
> decides exactly what information the smart card is going to 
> sign. It is
> again trivial to write an exploit that will make the smart card sign
> something that the owner did not mean to sign.
> 
> With the advent of digital signature laws which make digital signing
> commonplace, it is time to remove these security holes before 
> hackers and
> newspaper articles start popping up. (How would any of you smart card
> manufacturers like to see your company's name placed 
> conveniently next to
> "FRAUD!!" in TIME Magazine?)
> 
> The ultimate solution, of course, would be for everyone to 
> have a secure
> device, containing the private key, with the following 
> characteristics:
>  - In order to sign anything, the user must put their finger on the
> fingerprint scanner. (Or other biometrics...)
>  - In case the signature is binding (ie, contract as opposed to
> authentication), the user must check the contents being 
> signed on the screen
> of the secure device.
>  - In case the signature is binding, the user must enter a signature
> passphrase (PIN) as well.
> 
> Now, since users do not want to enter passphrases every time 
> something needs
> to be signed, and since that would be dangerous in the first place
> (increased risk of passphrase exposure), there is a practical 
> need for the
> secure device to be able to distinguish between a binding 
> signature and a
> non-binding signature.
> 
> In the case of a non-binding signature (eg, proof of 
> identity), the behavior
> of the secure device could simply match the behavior of all the
> cryptographic tokens currently out there. Ie, the device 
> would sign anything
> that it receives - most commonly a hash of something - 
> provided that the
> user confirms the signature operation by putting their finger on the
> fingerpring scanner. However, in contrast to the cryptographic tokens
> currently being used, any such signature would be explicitly 
> marked that it
> cannot be considered binding.
> 
> In the case of a binding signature (eg, a contract), the 
> secure device would
> insist on receiving the entire content that is being signed, 
> formatted in a
> well-known and secure format, so that the content can be 
> shown to the user
> before anything can be signed. The user would also need to 
> authenticate
> themselves in a more secure manner before a binding signature 
> is made; and
> when it is made, the signature would be explicitly marked 
> that it CAN be
> considered binding.
> 
> It is my opinion that the following efforts need to be made:
>  - The current signature formats need to be extended so as to include
> information about the extent to which the data being signed 
> was verified by
> the signer - or simply whether the signature can be 
> interpreted as binding
> or not.
>  - A format for binding content needs to be selected or 
> defined. (RTF, ASCII
> text, anything?) - this is the format in which any binding 
> content is sent
> to the secure device so that it can be shown to the user, who in turn
> decides whether to sign it or not.
>  - The current APIs for communication with cryptographic 
> tokens need to be
> modified to support this. Eg, in PKCS#11, the following modes 
> of signature
> could be introduced:
>         - sign this hash and mark the signature as non-binding
>         - here is the 34kB file containing the binding 
> content to be signed,
> show it to the signer, sign it and mark it as binding
>         - here is a hash of the binding content to be signed, 
> sign it and
> mark it as binding (deprecated, but must be included since it 
> is not yet
> possible to transmit 34kB of data to every kind of 
> cryptographic token)
> 
> I feel that the above issues are important and that somebody 
> needs to take
> them on. I cannot decide whether or not this workgroup should 
> do it; but
> somebody has to. (Or else...)
> 
> Comments are welcome. Also, does anyone have information whether these
> issues have been addressed by the xmldsig workgroup, or is 
> their format as
> clueless as the ASN.1 signature format?
> 
> Regards,
> 
> denis bider
> 
> //
> //  denis bider, [e-mail]
> // [alternative: [e-mail]]
> //  globera d.o.o., Ljubljana, Slovenia
>     http://www.globera.com
>     [phone]
> 
> 
> 


Received: from stargate.zergo.com.au (IDENT:[e-mail] [203.2.208.130]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id EAA01381 for <[e-mail]>; Tue, 11 Jul 2000 04:38:01 -0700 (PDT)
Received: from sydneymail1.baltimore.com.au (sydneymail1.jp.zergo.com.au [192.168.71.5]) by stargate.zergo.com.au (8.9.1/8.8.7) with ESMTP id VAA00786; Tue, 11 Jul 2000 21:45:27 +1000
Received: by sydneymail1.jp.zergo.com.au with Internet Mail Service (5.5.2448.0) id <34DM0MHB>; Tue, 11 Jul 2000 21:38:31 +1000
Message-ID: <[e-mail]>
From: Michael Zolotarev <[e-mail]>
To: [e-mail], [e-mail]
Subject: RE: Current signature formats insufficient
Date: Tue, 11 Jul 2000 21:38:31 +1000
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2448.0)
Content-Type: text/plain; charset="iso-8859-1"

Don't you find that there is a little bit too much of a 'finger' stuff in
there... What would be a name for the box?

:)


> -----Original Message-----
> From: denis bider [mailto:[e-mail]]
> Sent: Tuesday, July 11, 2000 6:42 PM
> To: [e-mail]
> Subject: Current signature formats insufficient
> 
> 
> Hello folks,
> 
> we probably agree that smart cards, as well as a variety of 
> other similar
> cryptographic tokens, are insecure. Their primary insecurity 
> lies not within
> the tokens themselves, but rather in the way they are most 
> commonly used.
> Most frequently, a cryptographic token is attached to a PC, 
> and it does
> whatever cryptographic operation the PC tells it to do.
> 
> This concept is obviously insecure, since:
>  - PCs are insecure. Every average hacker down the street can 
> break into
> anyone's Windoze PC, and it is trivial to write an exploit 
> that will capture
> a smart card's PIN, wait for the smart card to be inserted 
> and then perform
> a signature operation.
>  - Even if the user is as security conscious as to use a 
> secure PIN entry
> device, or a fingerprint scanner for that matter, it is still 
> the PC that
> decides exactly what information the smart card is going to 
> sign. It is
> again trivial to write an exploit that will make the smart card sign
> something that the owner did not mean to sign.
> 
> With the advent of digital signature laws which make digital signing
> commonplace, it is time to remove these security holes before 
> hackers and
> newspaper articles start popping up. (How would any of you smart card
> manufacturers like to see your company's name placed 
> conveniently next to
> "FRAUD!!" in TIME Magazine?)
> 
> The ultimate solution, of course, would be for everyone to 
> have a secure
> device, containing the private key, with the following 
> characteristics:
>  - In order to sign anything, the user must put their finger on the
> fingerprint scanner. (Or other biometrics...)
>  - In case the signature is binding (ie, contract as opposed to
> authentication), the user must check the contents being 
> signed on the screen
> of the secure device.
>  - In case the signature is binding, the user must enter a signature
> passphrase (PIN) as well.
> 
> Now, since users do not want to enter passphrases every time 
> something needs
> to be signed, and since that would be dangerous in the first place
> (increased risk of passphrase exposure), there is a practical 
> need for the
> secure device to be able to distinguish between a binding 
> signature and a
> non-binding signature.
> 
> In the case of a non-binding signature (eg, proof of 
> identity), the behavior
> of the secure device could simply match the behavior of all the
> cryptographic tokens currently out there. Ie, the device 
> would sign anything
> that it receives - most commonly a hash of something - 
> provided that the
> user confirms the signature operation by putting their finger on the
> fingerpring scanner. However, in contrast to the cryptographic tokens
> currently being used, any such signature would be explicitly 
> marked that it
> cannot be considered binding.
> 
> In the case of a binding signature (eg, a contract), the 
> secure device would
> insist on receiving the entire content that is being signed, 
> formatted in a
> well-known and secure format, so that the content can be 
> shown to the user
> before anything can be signed. The user would also need to 
> authenticate
> themselves in a more secure manner before a binding signature 
> is made; and
> when it is made, the signature would be explicitly marked 
> that it CAN be
> considered binding.
> 
> It is my opinion that the following efforts need to be made:
>  - The current signature formats need to be extended so as to include
> information about the extent to which the data being signed 
> was verified by
> the signer - or simply whether the signature can be 
> interpreted as binding
> or not.
>  - A format for binding content needs to be selected or 
> defined. (RTF, ASCII
> text, anything?) - this is the format in which any binding 
> content is sent
> to the secure device so that it can be shown to the user, who in turn
> decides whether to sign it or not.
>  - The current APIs for communication with cryptographic 
> tokens need to be
> modified to support this. Eg, in PKCS#11, the following modes 
> of signature
> could be introduced:
>         - sign this hash and mark the signature as non-binding
>         - here is the 34kB file containing the binding 
> content to be signed,
> show it to the signer, sign it and mark it as binding
>         - here is a hash of the binding content to be signed, 
> sign it and
> mark it as binding (deprecated, but must be included since it 
> is not yet
> possible to transmit 34kB of data to every kind of 
> cryptographic token)
> 
> I feel that the above issues are important and that somebody 
> needs to take
> them on. I cannot decide whether or not this workgroup should 
> do it; but
> somebody has to. (Or else...)
> 
> Comments are welcome. Also, does anyone have information whether these
> issues have been addressed by the xmldsig workgroup, or is 
> their format as
> clueless as the ASN.1 signature format?
> 
> Regards,
> 
> denis bider
> 
> //
> //  denis bider, [e-mail]
> // [alternative: [e-mail]]
> //  globera d.o.o., Ljubljana, Slovenia
>     http://www.globera.com
>     [phone]
> 
> 
> 


Received: from levitator.1div0.com ([213.250.43.61]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id BAA20749 for <[e-mail]>; Tue, 11 Jul 2000 01:39:16 -0700 (PDT)
Received: from intergalactic ([10.1.1.2]) by levitator.1div0.com (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with SMTP id KAA19442 for <[e-mail]>; Tue, 11 Jul 2000 10:27:38 +0200
Reply-To: <[e-mail]>
From: "denis bider" <[e-mail]>
To: <[e-mail]>
Subject: Current signature formats insufficient
Date: Tue, 11 Jul 2000 10:41:34 +0200
Message-ID: <000001bfeb13$d25fe870$0201010a@intergalactic>
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2910.0)
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700

Hello folks,

we probably agree that smart cards, as well as a variety of other similar
cryptographic tokens, are insecure. Their primary insecurity lies not within
the tokens themselves, but rather in the way they are most commonly used.
Most frequently, a cryptographic token is attached to a PC, and it does
whatever cryptographic operation the PC tells it to do.

This concept is obviously insecure, since:
 - PCs are insecure. Every average hacker down the street can break into
anyone's Windoze PC, and it is trivial to write an exploit that will capture
a smart card's PIN, wait for the smart card to be inserted and then perform
a signature operation.
 - Even if the user is as security conscious as to use a secure PIN entry
device, or a fingerprint scanner for that matter, it is still the PC that
decides exactly what information the smart card is going to sign. It is
again trivial to write an exploit that will make the smart card sign
something that the owner did not mean to sign.

With the advent of digital signature laws which make digital signing
commonplace, it is time to remove these security holes before hackers and
newspaper articles start popping up. (How would any of you smart card
manufacturers like to see your company's name placed conveniently next to
"FRAUD!!" in TIME Magazine?)

The ultimate solution, of course, would be for everyone to have a secure
device, containing the private key, with the following characteristics:
 - In order to sign anything, the user must put their finger on the
fingerprint scanner. (Or other biometrics...)
 - In case the signature is binding (ie, contract as opposed to
authentication), the user must check the contents being signed on the screen
of the secure device.
 - In case the signature is binding, the user must enter a signature
passphrase (PIN) as well.

Now, since users do not want to enter passphrases every time something needs
to be signed, and since that would be dangerous in the first place
(increased risk of passphrase exposure), there is a practical need for the
secure device to be able to distinguish between a binding signature and a
non-binding signature.

In the case of a non-binding signature (eg, proof of identity), the behavior
of the secure device could simply match the behavior of all the
cryptographic tokens currently out there. Ie, the device would sign anything
that it receives - most commonly a hash of something - provided that the
user confirms the signature operation by putting their finger on the
fingerpring scanner. However, in contrast to the cryptographic tokens
currently being used, any such signature would be explicitly marked that it
cannot be considered binding.

In the case of a binding signature (eg, a contract), the secure device would
insist on receiving the entire content that is being signed, formatted in a
well-known and secure format, so that the content can be shown to the user
before anything can be signed. The user would also need to authenticate
themselves in a more secure manner before a binding signature is made; and
when it is made, the signature would be explicitly marked that it CAN be
considered binding.

It is my opinion that the following efforts need to be made:
 - The current signature formats need to be extended so as to include
information about the extent to which the data being signed was verified by
the signer - or simply whether the signature can be interpreted as binding
or not.
 - A format for binding content needs to be selected or defined. (RTF, ASCII
text, anything?) - this is the format in which any binding content is sent
to the secure device so that it can be shown to the user, who in turn
decides whether to sign it or not.
 - The current APIs for communication with cryptographic tokens need to be
modified to support this. Eg, in PKCS#11, the following modes of signature
could be introduced:
        - sign this hash and mark the signature as non-binding
        - here is the 34kB file containing the binding content to be signed,
show it to the signer, sign it and mark it as binding
        - here is a hash of the binding content to be signed, sign it and
mark it as binding (deprecated, but must be included since it is not yet
possible to transmit 34kB of data to every kind of cryptographic token)

I feel that the above issues are important and that somebody needs to take
them on. I cannot decide whether or not this workgroup should do it; but
somebody has to. (Or else...)

Comments are welcome. Also, does anyone have information whether these
issues have been addressed by the xmldsig workgroup, or is their format as
clueless as the ASN.1 signature format?

Regards,

denis bider

//
//  denis bider, [e-mail]
// [alternative: [e-mail]]
//  globera d.o.o., Ljubljana, Slovenia
    http://www.globera.com
    [phone]





Received: from roadblock.missi.ncsc.mil (roadblock.missi.ncsc.mil [144.51.50.70]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id OAA11805 for <[e-mail]>; Mon, 10 Jul 2000 14:34:13 -0700 (PDT)
Received: from roadblock.missi.ncsc.mil (root@localhost) by roadblock.missi.ncsc.mil with ESMTP id RAA21720 for <[e-mail]>; Mon, 10 Jul 2000 17:25:40 -0400 (EDT)
Message-Id: <[e-mail]>
Date: Mon, 10 Jul 2000 17:32:32 -0400 (EDT)
From: "David P. Kemp" <[e-mail]>
Reply-To: "David P. Kemp" <[e-mail]>
Subject: Re: Operational Protocols - LDAPv3
To: [e-mail]
MIME-Version: 1.0
Content-Type: TEXT/plain; charset=us-ascii
Content-MD5: zFfNe2n+kDO29NOefYydlQ==
X-Mailer: dtmail 1.3.0 CDE Version 1.3 SunOS 5.7 sun4u sparc

> From: "David Chadwick" <[e-mail]>
> 
> > > Conclusion. The superceded CRL is valid if it contains the
> > > certificate we are checking, and is invalid otherwise.
> > 
> > This conclusion depends on some assumptions: all clients have the same
> > revocation freshness requirements, those requirements don't depend on
> > the value of the information being processed at the time, and the CA
> > is the controlling authority for how often clients must check CRLs.
> 
> Sorry David, I disagree with you on the above. They are irrelevant 
> in my opinion to the statement I made. However, they may be 
> relevant to the client (who is choosing to ignore the fact that a later 
> CRL is available, but that is its choice. The fact still stands that the 
> old CRL is not fully trustworthy (or valid) in an absolute sense. But it 
> might be good enough for the client.)



Assume CA "A" which issues scheduled CRLs every day, but will issue
an unscheduled CRL within 3 hours of receiving a
revocation-for-compromise request.  Assume CA "B" which issues
scheduled CRLs every hour and no unscheduled CRLs.

Assume a client which fetches a CRL every three hours, regardless
of nextUpdate.


                               client             client
                                gets     com-     validates
             CRL A     CRL B    CRL     promise   cert X
             -----     -----    ----    -------   --------
thisUpdate:  t         t        ***
nextUpdate:  t + 24h   t + 1h

thisUpdate:            t + 1h
nextUpdate:            t + 2h

thisUpdate:            t + 2h           t + 2h
nextUpdate:            t + 3h

thisUpdate:            t + 3h   ***
nextUpdate:            t + 4h

thisUpdate:            t + 4h
nextUpdate:            t + 5h                       t + 4h

thisUpdate:  t + 5h    t + 5h
nextUpdate:  t + 24h   t + 6h

thisUpdate:            t + 6h    ***
nextUpdate:            t + 7h
                        .
                        .
                        .
thisUpdate:  t + 24h   t + 24h   ***
nextUpdate:  t + 48h   t + 25h

 
What you are saying is that the client which fetches CRL A is always
using an up-to-date CRL which is fully trustworthy (valid) in an absolute
sense.  But the same client which fetches CRL B is two thirds of the
time using an old (superceded) CRL which is not fully trustworthy
(invalid if the cert it is looking for is not present).

I respectfully disagree.  CRLs are not "valid" in any absolute sense,
they are only "fresh" or "stale" in an absolute sense.  CRL B (issued at
t+3h) is, despite being superceded, fresher than CRL A at time t+4 hours.

Put another way, clients can use nextUpdate (or not use it) however
they see fit in fetching information from a repository.  But the only
value that has any security relevance is thisUpdate -- the time after
which revocation events will not be reflected in the CRL.

Regards,
Dave




Received: from rhea.salford.ac.uk (rhea.salford.ac.uk [146.87.255.99]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id MAA07659 for <[e-mail]>; Mon, 10 Jul 2000 12:10:31 -0700 (PDT)
Received: (qmail 51847 invoked by alias); 10 Jul 2000 19:12:18 -0000
Received: (qmail 51816 invoked from network); 10 Jul 2000 19:12:17 -0000
Received: from unknown (HELO dwc-acer) (146.87.80.54) by rhea.salford.ac.uk with SMTP; 10 Jul 2000 19:12:17 -0000
From: "David Chadwick" <[e-mail]>
Organization: University of Salford
To: [e-mail], "David P. Kemp" <[e-mail]>, [e-mail]
Date: Mon, 10 Jul 2000 20:07:48 +0100
MIME-Version: 1.0
Content-type: text/plain; charset=US-ASCII
Content-transfer-encoding: 7BIT
Subject: Re: Operational Protocols - LDAPv3
Reply-to: [e-mail]
CC: "David P. Kemp" <[e-mail]>, [e-mail]
Message-ID: <396A2D14.16548.BF2AF37@localhost>
Priority: normal
In-reply-to: <[e-mail]>
X-mailer: Pegasus Mail for Win32 (v3.12c)

> [Tom Gindin] My conclusion is only slightly different: the superseded
> CRL is trustworthy if it contains the certificate we are checking and
> that certificate does not have either reason "certificateHold" or
> reason "removeFromCRL", and is not fully trustworthy otherwise.  The
> term "valid" here gets into the semantic debate above.
> 

Fair point (but I was omitting the Hold case for simplification 
reasons)
David

***************************************************

David Chadwick
IS Institute, University of Salford, Salford M5 4WT
Tel [phone]  Fax [phone]
Mobile [phone]
Email [e-mail]
Home Page  http://www.salford.ac.uk/its024/chadwick.htm
Understanding X.500  http://www.salford.ac.uk/its024/X500.htm
X.500/LDAP Seminars http://www.salford.ac.uk/its024/seminars.htm
Entrust key validation string MLJ9-DU5T-HV8J

***************************************************


Received: from rhea.salford.ac.uk (rhea.salford.ac.uk [146.87.255.99]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id MAA07656 for <[e-mail]>; Mon, 10 Jul 2000 12:10:31 -0700 (PDT)
Received: (qmail 51861 invoked by alias); 10 Jul 2000 19:12:18 -0000
Received: (qmail 51819 invoked from network); 10 Jul 2000 19:12:17 -0000
Received: from unknown (HELO dwc-acer) (146.87.80.54) by rhea.salford.ac.uk with SMTP; 10 Jul 2000 19:12:17 -0000
From: "David Chadwick" <[e-mail]>
Organization: University of Salford
To: [e-mail], "David P. Kemp" <[e-mail]>
Date: Mon, 10 Jul 2000 20:07:49 +0100
MIME-Version: 1.0
Content-type: text/plain; charset=US-ASCII
Content-transfer-encoding: 7BIT
Subject: Re: Operational Protocols - LDAPv3
Reply-to: [e-mail]
Message-ID: <396A2D15.4758.BF2B0C4@localhost>
Priority: normal
In-reply-to: <[e-mail]>
X-mailer: Pegasus Mail for Win32 (v3.12c)

> > Conclusion. The superceded CRL is valid if it contains the
> > certificate we are checking, and is invalid otherwise.
> 
> 
> This conclusion depends on some assumptions: all clients have the same
> revocation freshness requirements, those requirements don't depend on
> the value of the information being processed at the time, and the CA
> is the controlling authority for how often clients must check CRLs.

Sorry David, I disagree with you on the above. They are irrelevant 
in my opinion to the statement I made. However, they may be 
relevant to the client (who is choosing to ignore the fact that a later 
CRL is available, but that is its choice. The fact still stands that the 
old CRL is not fully trustworthy (or valid) in an absolute sense. But it 
might be good enough for the client.)

David





> Putting the CA in control of CRL "validity" turns what would normally
> be a pull model into a push model - clients have to take the latest
> information that has been generated, or else.  In my view, that isn't
> the best way to improve security.
> 
> Regards,
> Dave
> 
> 
> 


***************************************************

David Chadwick
IS Institute, University of Salford, Salford M5 4WT
Tel [phone]  Fax [phone]
Mobile [phone]
Email [e-mail]
Home Page  http://www.salford.ac.uk/its024/chadwick.htm
Understanding X.500  http://www.salford.ac.uk/its024/X500.htm
X.500/LDAP Seminars http://www.salford.ac.uk/its024/seminars.htm
Entrust key validation string MLJ9-DU5T-HV8J

***************************************************


Received: from rhea.salford.ac.uk (rhea.salford.ac.uk [146.87.255.99]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id MAA07657 for <[e-mail]>; Mon, 10 Jul 2000 12:10:31 -0700 (PDT)
Received: (qmail 51835 invoked by alias); 10 Jul 2000 19:12:18 -0000
Received: (qmail 51816 invoked from network); 10 Jul 2000 19:12:17 -0000
Received: from unknown (HELO dwc-acer) (146.87.80.54) by rhea.salford.ac.uk with SMTP; 10 Jul 2000 19:12:17 -0000
From: "David Chadwick" <[e-mail]>
Organization: University of Salford
To: [e-mail], "David P. Kemp" <[e-mail]>, [e-mail]
Date: Mon, 10 Jul 2000 20:07:48 +0100
MIME-Version: 1.0
Content-type: text/plain; charset=US-ASCII
Content-transfer-encoding: 7BIT
Subject: Re: Operational Protocols - LDAPv3
Reply-to: [e-mail]
CC: "David P. Kemp" <[e-mail]>, [e-mail]
Message-ID: <396A2D14.16548.BF2AF37@localhost>
Priority: normal
In-reply-to: <[e-mail]>
X-mailer: Pegasus Mail for Win32 (v3.12c)

> [Tom Gindin] My conclusion is only slightly different: the superseded
> CRL is trustworthy if it contains the certificate we are checking and
> that certificate does not have either reason "certificateHold" or
> reason "removeFromCRL", and is not fully trustworthy otherwise.  The
> term "valid" here gets into the semantic debate above.
> 

Fair point (but I was omitting the Hold case for simplification 
reasons)
David

***************************************************

David Chadwick
IS Institute, University of Salford, Salford M5 4WT
Tel [phone]  Fax [phone]
Mobile [phone]
Email [e-mail]
Home Page  http://www.salford.ac.uk/its024/chadwick.htm
Understanding X.500  http://www.salford.ac.uk/its024/X500.htm
X.500/LDAP Seminars http://www.salford.ac.uk/its024/seminars.htm
Entrust key validation string MLJ9-DU5T-HV8J

***************************************************


Received: from rhea.salford.ac.uk (rhea.salford.ac.uk [146.87.255.99]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id MAA07655 for <[e-mail]>; Mon, 10 Jul 2000 12:10:31 -0700 (PDT)
Received: (qmail 51898 invoked by alias); 10 Jul 2000 19:12:18 -0000
Received: (qmail 51855 invoked from network); 10 Jul 2000 19:12:18 -0000
Received: from unknown (HELO dwc-acer) (146.87.80.54) by rhea.salford.ac.uk with SMTP; 10 Jul 2000 19:12:18 -0000
From: "David Chadwick" <[e-mail]>
Organization: University of Salford
To: "Miklos, Sue A." <[e-mail]>, "Kemp David P." <[e-mail]>, [e-mail]
Date: Mon, 10 Jul 2000 20:07:47 +0100
MIME-Version: 1.0
Content-type: text/plain; charset=US-ASCII
Content-transfer-encoding: 7BIT
Subject: RE: Operational Protocols - LDAPv3
Reply-to: [e-mail]
CC: "Kemp David P." <[e-mail]>, [e-mail]
Message-ID: <396A2D13.16967.BF2ABA4@localhost>
Priority: normal
In-reply-to: <[e-mail]>
X-mailer: Pegasus Mail for Win32 (v3.12c)

From:           	"Miklos, Sue A." <[e-mail]>
To:             	"'[e-mail]'" <[e-mail]>, [e-mail]
Copies to:      	"Kemp David P." <[e-mail]>, [e-mail]
Subject:        	RE: Operational Protocols - LDAPv3
Date sent:      	Mon, 10 Jul 2000 10:33:00 -0400

> Forgive what may be an ignorant question, but if the client 'verifies'
> the server, does that indicate some form of two-way strong
> authentication? 
> 
Sandi

You know it was not an ignorant question :-)

> we ran into issues when trying to require two way strong
> authentication. The client required a crl to complete the path
> processing on the signed bind response from the server. (this is my
> understanding of 'verifying' the server) 

Clearly there is a bootstrapping problem here. Although verify does 
not necessarily mean dig sigs, (though it could). It could be hashed 
passwords. If it is dig sigs, the client could hold off veryifying the 
bind until the crls had been retrieved, that would be one solution. 
But I would rather not get into the mire of saying how you verify the 
server if you dont mind. This note was merely meant as a 
cautionary one to alert the reader to the possibility of a rare and 
sophisticated attack that is possible. That's all.

> 
> Subsequently, it was easiest to allow unauthenticated reads to
> retrieve CRLs at start up.

Ease of use does often conflict with tight security as I mentioned in 
my previous message. It is always a balancing act

David

***************************************************

David Chadwick
IS Institute, University of Salford, Salford M5 4WT
Tel [phone]  Fax [phone]
Mobile [phone]
Email [e-mail]
Home Page  http://www.salford.ac.uk/its024/chadwick.htm
Understanding X.500  http://www.salford.ac.uk/its024/X500.htm
X.500/LDAP Seminars http://www.salford.ac.uk/its024/seminars.htm
Entrust key validation string MLJ9-DU5T-HV8J

***************************************************


Received: from rhea.salford.ac.uk (rhea.salford.ac.uk [146.87.255.99]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id MAA07658 for <[e-mail]>; Mon, 10 Jul 2000 12:10:31 -0700 (PDT)
Received: (qmail 51897 invoked by alias); 10 Jul 2000 19:12:18 -0000
Received: (qmail 51855 invoked from network); 10 Jul 2000 19:12:18 -0000
Received: from unknown (HELO dwc-acer) (146.87.80.54) by rhea.salford.ac.uk with SMTP; 10 Jul 2000 19:12:18 -0000
From: "David Chadwick" <[e-mail]>
Organization: University of Salford
To: "Miklos, Sue A." <[e-mail]>, "Kemp David P." <[e-mail]>, [e-mail]
Date: Mon, 10 Jul 2000 20:07:47 +0100
MIME-Version: 1.0
Content-type: text/plain; charset=US-ASCII
Content-transfer-encoding: 7BIT
Subject: RE: Operational Protocols - LDAPv3
Reply-to: [e-mail]
CC: "Kemp David P." <[e-mail]>, [e-mail]
Message-ID: <396A2D13.16967.BF2ABA4@localhost>
Priority: normal
In-reply-to: <[e-mail]>
X-mailer: Pegasus Mail for Win32 (v3.12c)

From:           	"Miklos, Sue A." <[e-mail]>
To:             	"'[e-mail]'" <[e-mail]>, [e-mail]
Copies to:      	"Kemp David P." <[e-mail]>, [e-mail]
Subject:        	RE: Operational Protocols - LDAPv3
Date sent:      	Mon, 10 Jul 2000 10:33:00 -0400

> Forgive what may be an ignorant question, but if the client 'verifies'
> the server, does that indicate some form of two-way strong
> authentication? 
> 
Sandi

You know it was not an ignorant question :-)

> we ran into issues when trying to require two way strong
> authentication. The client required a crl to complete the path
> processing on the signed bind response from the server. (this is my
> understanding of 'verifying' the server) 

Clearly there is a bootstrapping problem here. Although verify does 
not necessarily mean dig sigs, (though it could). It could be hashed 
passwords. If it is dig sigs, the client could hold off veryifying the 
bind until the crls had been retrieved, that would be one solution. 
But I would rather not get into the mire of saying how you verify the 
server if you dont mind. This note was merely meant as a 
cautionary one to alert the reader to the possibility of a rare and 
sophisticated attack that is possible. That's all.

> 
> Subsequently, it was easiest to allow unauthenticated reads to
> retrieve CRLs at start up.

Ease of use does often conflict with tight security as I mentioned in 
my previous message. It is always a balancing act

David

***************************************************

David Chadwick
IS Institute, University of Salford, Salford M5 4WT
Tel [phone]  Fax [phone]
Mobile [phone]
Email [e-mail]
Home Page  http://www.salford.ac.uk/its024/chadwick.htm
Understanding X.500  http://www.salford.ac.uk/its024/X500.htm
X.500/LDAP Seminars http://www.salford.ac.uk/its024/seminars.htm
Entrust key validation string MLJ9-DU5T-HV8J

***************************************************


Received: from crack.x509.com ([e-mail] [199.175.150.1]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id KAA04853 for <[e-mail]>; Mon, 10 Jul 2000 10:13:12 -0700 (PDT)
Received: from xcert.com (saxifrage.x509.com [199.175.148.75]) by crack.x509.com (8.10.0/XCERT) with ESMTP id e6AHEwI25323 for <[e-mail]>; Mon, 10 Jul 2000 10:14:58 -0700 (PDT)
Sender: [e-mail]
Message-ID: <[e-mail]>
Date: Mon, 10 Jul 2000 10:16:03 -0700
From: Marc Branchaud <[e-mail]>
Organization: Xcert International Inc.
X-Mailer: Mozilla 4.73 [en] (X11; U; Linux 2.2.10 i686)
X-Accept-Language: en, fr
MIME-Version: 1.0
To: [e-mail]
Subject: Re: Operational Protocols - LDAPv3
References: <[e-mail]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

"David P. Kemp" wrote:
> 
>    this "CRL Validity" interpretation eliminates the ability of the client
>    to decide, based on the value of information, how fresh its revocation
>    information needs to be.

An interesting perspective if you consider a couple of points:

 - The CA gets to decide when a revocation is important enough to issue a
pre-emptive CRL.

 - The relying party typically has no legal relationship with the issuing CA.

So the CA is under no obligation to care about the relying party's values. 
The relying party can demand the latest CRL every 10ms if he wants, but the
CA isn't necessarily going to cough up any newer revocation data.

Seems like the client never has the ability to decide freshness based on
their own values, regardless of how they interpret CRL validity.  Sure, the
client can decide "I need data fresher than the CRL issuance frequency of
this CA, so I'm not going to trust it."  Refusing to talk to other people
isn't a good way to use a network though.

Later, you do put a slightly different spin on things:

> I prefer an environment where the CA is
> incentivized to improve service - to advertise "status updates every hour",
> "every 15 minutes" or "every minute", and fastest would be unequivocably
> best.

For this to work sensibly, CAs should really ignore the provision of X.509
that says that CRLs can be issued before nextUpdate.  Although it may seem
wise to take the position that an "important" revocation warrants an early
CRL, doing so really throws RPs' trust assumptions out the window:

RP: "Gee, your honor, the CA only updates its revocation info every hour, so
I didn't see the need to check again since my CRL was only 20 minutes old..."

CA: "But your honor, this was an important revocation, so we issued an early
update to our revocation data.  We're just trying to provide the best
possible service, and since we already published the revocation, we can't be
held liable for the RP's damages."

Lovely can of big, fat wriggly worms that is.  More importantly, though, even
if the issue were resolved the client is still stuck with whatever regime the
CA chooses.  If there isn't a CA that meets the client's freshness
requirements, the client is SOL.

		Marc

+------------------------------------------------------------------------+
 Marc Branchaud                                  \/
 Chief PKI Architect                             /\CERT INTERNATIONAL INC.
 [e-mail]        PKI References page:              www.xcert.com
 604-640-6227          www.xcert.com/~marcnarc/PKI/
+------------------------------------------------------------------------+


Received: from dfw7-1.relay.mail.uu.net (dfw7-1.relay.mail.uu.net [199.171.54.106]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id JAA00908 for <[e-mail]>; Mon, 10 Jul 2000 09:09:07 -0700 (PDT)
Received: from xedia.com by dfw7sosrv11.alter.net with SMTP  (peer crosschecked as: madway.xedia.com [198.202.232.199]) id QQixgi13247; Mon, 10 Jul 2000 16:10:48 GMT
Received: from tonga.xedia.com by xedia.com (4.1/SMI-4.1) id AA03180; Mon, 10 Jul 00 12:06:58 EDT
Received: by tonga.xedia.com (SMI-8.6/SMI-SVR4) id MAA28622; Mon, 10 Jul 2000 12:10:47 -0400
From: Paul Koning <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-Id: <[e-mail]>
Date: Mon, 10 Jul 2000 12:10:47 -0400 (EDT)
To: [e-mail]
Cc: [e-mail], [e-mail]
Subject: RE: I-D ACTION:draft-ietf-pkix-time-stamp-08.txt. HASH
References: <[e-mail]> <v0422080bb58299d62029@[171.78.30.107]>
X-Mailer: VM 6.72 under 21.1 (patch 9) "Canyonlands" XEmacs Lucid

>>>>> "Stephen" == Stephen Kent <[e-mail]> writes:

 Stephen> Jim, I support Denis in his desire to have the TSA check
 Stephen> everything it can (syntactically) in a request.  Not
 Stephen> checking allows the TSA to sign tokens that are just broken.
 Stephen> We have seen many examples of broken certs signed by CAs, so
 Stephen> I think it worthwhile that we put language in RFCs to
 Stephen> require, where possible, that appropriate consistency checks
 Stephen> be performed.  RFC 2459 has a few statement about
 Stephen> relationships among extensions, which gets to the same
 Stephen> concerns.  We could put in more, or collect them in one
 Stephen> place, and make for a better document.

 Stephen> I may have lost track of the counter argument here.  Why
 Stephen> would one not want to have a TSA do the best possible job
 Stephen> when it comes to ensuring syntactic consistency re its
 Stephen> inputs?

The Internet protocol design rule is "be strict in what you send,
tolerant in what you receive".  It has been known for decades that
this is the correct rule.  (That doesn't keep some other standards
bodies from ignoring it, unfortunately.  Then again, there are still
standards bodies that use two-way connection setup handshakes...)

Protocols should check those invariants that have to be valid for
correct operation to result, or for interoperability to be possible.
Checks beyond that are counterproductive.

In particular, the more you check, the more often you have to ECO your
specs and your implementation as new extensions are registered.  And
the more often you have to release bugfixes.

    paul


Received: from roadblock.missi.ncsc.mil ([144.51.50.70]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id IAA28410 for <[e-mail]>; Mon, 10 Jul 2000 08:33:39 -0700 (PDT)
Received: from roadblock.missi.ncsc.mil (root@localhost) by roadblock.missi.ncsc.mil with ESMTP id LAA23997 for <[e-mail]>; Mon, 10 Jul 2000 11:25:06 -0400 (EDT)
Message-Id: <[e-mail]>
Date: Mon, 10 Jul 2000 11:31:58 -0400 (EDT)
From: "David P. Kemp" <[e-mail]>
Reply-To: "David P. Kemp" <[e-mail]>
Subject: Re: Operational Protocols - LDAPv3
To: [e-mail]
MIME-Version: 1.0
Content-Type: TEXT/plain; charset=us-ascii
Content-MD5: 4SPc+cQwXnDINk2z5pOlsA==
X-Mailer: dtmail 1.3.0 CDE Version 1.3 SunOS 5.7 sun4u sparc

> From: "David Chadwick" <[e-mail]>
> >
> >    [dpk] ... A CRL does not
> >    become invalid when the next CRL is issued, although some
> >    applications behave as though it does. 
> 
> We are playing with fine semantics here. Is a superceded CRL 
> invalid or not? No, its not technically invalid, as everything it contains 
> is good and true, but it is certainly incomplete (in the scenario we 
> are discussing). Is an incomplete CRL invalid or not? I would say 
> from a trust perspective yes, given that another CRL has been 
> issued and therefore one or more other certificates have been 
> revoked and I dont know which ones they are, therefore I cannot 
> rely on the superceded CRL, therefore it might as well be invalid. In 
> other words, for certificate X, where X is not in the list of revoked 
> certificates in the superceded CRL, using the superceded CRL or 
> using an invalid CRL give me exactly the same answer, viz: I dont 
> know if X has been revoked or not. The superceded CRL can only 
> be regarded as being valid, if X is in the list of revoked certificates. 
> 
> Conclusion. The superceded CRL is valid if it contains the certificate 
> we are checking, and is invalid otherwise.


This conclusion depends on some assumptions: all clients have the same
revocation freshness requirements, those requirements don't depend on
the value of the information being processed at the time, and the CA
is the controlling authority for how often clients must check CRLs.

In a world where communication is instantaneous, free, and 100%
reliable, there would be no reason for a client to ever use anything
but the most up-to-date revocation information from a CA, and your
conclusion would be correct.  But in a world where the cost of
communicating must be traded off against the cost of not communicating
(relying on a superceded CRL), I believe local administrators are in a
better position than a CA to make the tradeoff.

Putting the CA in control of CRL "validity" creates a perverse
incentive against improving service - the more frequently the CA issues
scheduled CRLs, the more the clients are going to complain about the
cost of retrieving them.  I prefer an environment where the CA is
incentivized to improve service - to advertise "status updates every hour",
"every 15 minutes" or "every minute", and fastest would be unequivocably
best.

Putting the CA in control of CRL "validity" turns what would normally
be a pull model into a push model - clients have to take the latest
information that has been generated, or else.  In my view, that isn't
the best way to improve security.

Regards,
Dave




Received: from roadblock.missi.ncsc.mil ([144.51.50.70]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id HAA26319 for <[e-mail]>; Mon, 10 Jul 2000 07:31:06 -0700 (PDT)
Received: from roadblock.missi.ncsc.mil (root@localhost) by roadblock.missi.ncsc.mil with ESMTP id KAA07565 for <[e-mail]>; Mon, 10 Jul 2000 10:22:32 -0400 (EDT)
Message-Id: <[e-mail]>
From: "Miklos, Sue A." <[e-mail]>
To: "'[e-mail]'" <[e-mail]>, [e-mail]
Cc: "Kemp David P." <[e-mail]>, [e-mail]
Subject: RE: Operational Protocols - LDAPv3
Date: Mon, 10 Jul 2000 10:33:00 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain; charset="ISO-8859-1"

Forgive what may be an ignorant question, but if the client 'verifies' the
server, does that indicate some form of two-way strong authentication? 

we ran into issues when trying to require two way strong authentication.
The client required a crl to complete the path processing on the signed bind
response from the server. (this is my understanding of 'verifying' the
server) 

Subsequently, it was easiest to allow unauthenticated reads to retrieve CRLs
at start up.

If there's a more effective way to achieve this, please advise.

Regards,
Sandi Miklos 

-----Original Message-----
From: [e-mail] [mailto:[e-mail]]
Sent: Sunday, July 09, 2000 11:31 PM
To: [e-mail]
Cc: Kemp David P.; [e-mail]
Subject: Re: Operational Protocols - LDAPv3


     Comments below:


"David Chadwick" <[e-mail]> on 07/08/2000 06:40:05 PM

Please respond to [e-mail]

To:   "David P. Kemp" <[e-mail]>, [e-mail]
cc:
Subject:  Re: Operational Protocols - LDAPv3




> Professor Chadwick,

David

thanks for the complement, but I am not a professor in the UK, just
a lecturer

[Tom Gindin] I'm sure you would be at least an assistant professor in the
USA.

>
> An observation and an opinion:
>
> 1. Clients that do verify the server still run the risk of being
>    sent a "still valid" but superseded CRL.  The attacker just
>    denies the server access to the latest CRL.
>

Agreed, this can happen, but the sender (particularly if its a CA or part
of the CA administration) will then be aware of a fault or an attack and
may be able to quickly counteract it. A user on the other hand will be less
likely to be aware of the attack. So the risk is greater.

> 2. Using the term "still-valid-but-superseded" implies that CRLs
>    have a validity period.  Certificates have a Validity period,
>    but CRLs have values for thisUpdate and nextUpdate.  A CRL does not
>    become invalid when the next CRL is issued, although some
>    applications behave as though it does.

We are playing with fine semantics here. Is a superseded CRL
invalid or not? No, its not technically invalid, as everything it contains
is good and true, but it is certainly incomplete (in the scenario we are
discussing). Is an incomplete CRL invalid or not? I would say from a trust
perspective yes, given that another CRL has been issued and therefore one
or more other certificates have been
revoked and I dont know which ones they are, therefore I cannot
rely on the superceded CRL, therefore it might as well be invalid. In other
words, for certificate X, where X is not in the list of revoked
certificates in the superseded CRL, using the superseded CRL or using an
invalid CRL give me exactly the same answer, viz: I don't know if X has
been revoked or not. The superseded CRL can only be regarded as being
valid, if X is in the list of revoked certificates.

[Tom Gindin] Actually, if X is in the list but its reason is
"certificateHold" its status is no more final than if it were not in the
list.  Of course, the RP will refuse to trust it when he possibly should,
which is less of a security flaw than the other way around.

Conclusion. The superseded CRL is valid if it contains the certificate we
are checking, and is invalid otherwise.

[Tom Gindin] My conclusion is only slightly different: the superseded CRL
is trustworthy if it contains the certificate we are checking and that
certificate does not have either reason "certificateHold" or reason
"removeFromCRL", and is not fully trustworthy otherwise.  The term "valid"
here gets into the semantic debate above.

(snip)




****************************************************************************
*
This confirms that this email message has been swept by
MIMEsweeper for the presence of computer viruses.
****************************************************************************
**


Received: from ietf.org (odin.ietf.org [132.151.1.176]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id DAA21274 for <[e-mail]>; Mon, 10 Jul 2000 03:31:58 -0700 (PDT)
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA02310; Mon, 10 Jul 2000 06:33:43 -0400 (EDT)
Message-Id: <[e-mail]>
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
Cc: [e-mail]
From: [e-mail]
Reply-to: [e-mail]
Subject: I-D ACTION:draft-ietf-pkix-ldap-v3-02.txt
Date: Mon, 10 Jul 2000 06:33:42 -0400
Sender: [e-mail]

--NextPart

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Public-Key Infrastructure (X.509) Working Group of the IETF.

	Title		: Internet X.509 Public Key Infrastructure Operational 
                          Protocols - LDAPv3
	Author(s)	: D. Chadwick
	Filename	: draft-ietf-pkix-ldap-v3-02.txt
	Pages		: 6
	Date		: 07-Jul-00
	
This document describes the features of the Lightweight Directory 
Access Protocol v3 that are needed in order to support a public key 
infrastructure based on X.509 certificates and CRLs.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-pkix-ldap-v3-02.txt

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-ietf-pkix-ldap-v3-02.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt


Internet-Drafts can also be obtained by e-mail.

Send a message to:
	[e-mail].
In the body type:
	"FILE /internet-drafts/draft-ietf-pkix-ldap-v3-02.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.
		
		
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"

--OtherAccess
Content-Type: Message/External-body;
	access-type="mail-server";
	server="[e-mail]"

Content-Type: text/plain
Content-ID:	<[e-mail]>

ENCODING mime
FILE /internet-drafts/draft-ietf-pkix-ldap-v3-02.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-pkix-ldap-v3-02.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID:	<[e-mail]>

--OtherAccess--

--NextPart--




Received: from e4.ny.us.ibm.com (e4.ny.us.ibm.com [32.97.182.104]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id UAA10641 for <[e-mail]>; Sun, 9 Jul 2000 20:29:55 -0700 (PDT)
From: [e-mail]
Received: from northrelay02.pok.ibm.com (northrelay02.pok.ibm.com [9.117.200.22]) by e4.ny.us.ibm.com (8.9.3/8.9.3) with ESMTP id XAA289648; Sun, 9 Jul 2000 23:29:40 -0400
Received: from D51MTA04.pok.ibm.com (d51mta04.pok.ibm.com [9.117.200.32]) by northrelay02.pok.ibm.com (8.8.8m3/NCO v4.9) with SMTP id XAA170560; Sun, 9 Jul 2000 23:31:37 -0400
Received: by D51MTA04.pok.ibm.com(Lotus SMTP MTA v4.6.5  (863.2 5-20-1999))  id 85256918.00135CDD ; Sun, 9 Jul 2000 23:31:29 -0400
X-Lotus-FromDomain: IBMUS
To: [e-mail]
cc: "David P. Kemp" <[e-mail]>, [e-mail]
Message-ID: <[e-mail]>
Date: Sun, 9 Jul 2000 23:31:24 -0400
Subject: Re: Operational Protocols - LDAPv3
Mime-Version: 1.0
Content-type: text/plain; charset=us-ascii
Content-Disposition: inline

     Comments below:


"David Chadwick" <[e-mail]> on 07/08/2000 06:40:05 PM

Please respond to [e-mail]

To:   "David P. Kemp" <[e-mail]>, [e-mail]
cc:
Subject:  Re: Operational Protocols - LDAPv3




> Professor Chadwick,

David

thanks for the complement, but I am not a professor in the UK, just
a lecturer

[Tom Gindin] I'm sure you would be at least an assistant professor in the
USA.

>
> An observation and an opinion:
>
> 1. Clients that do verify the server still run the risk of being
>    sent a "still valid" but superseded CRL.  The attacker just
>    denies the server access to the latest CRL.
>

Agreed, this can happen, but the sender (particularly if its a CA or part
of the CA administration) will then be aware of a fault or an attack and
may be able to quickly counteract it. A user on the other hand will be less
likely to be aware of the attack. So the risk is greater.

> 2. Using the term "still-valid-but-superseded" implies that CRLs
>    have a validity period.  Certificates have a Validity period,
>    but CRLs have values for thisUpdate and nextUpdate.  A CRL does not
>    become invalid when the next CRL is issued, although some
>    applications behave as though it does.

We are playing with fine semantics here. Is a superseded CRL
invalid or not? No, its not technically invalid, as everything it contains
is good and true, but it is certainly incomplete (in the scenario we are
discussing). Is an incomplete CRL invalid or not? I would say from a trust
perspective yes, given that another CRL has been issued and therefore one
or more other certificates have been
revoked and I dont know which ones they are, therefore I cannot
rely on the superceded CRL, therefore it might as well be invalid. In other
words, for certificate X, where X is not in the list of revoked
certificates in the superseded CRL, using the superseded CRL or using an
invalid CRL give me exactly the same answer, viz: I don't know if X has
been revoked or not. The superseded CRL can only be regarded as being
valid, if X is in the list of revoked certificates.

[Tom Gindin] Actually, if X is in the list but its reason is
"certificateHold" its status is no more final than if it were not in the
list.  Of course, the RP will refuse to trust it when he possibly should,
which is less of a security flaw than the other way around.

Conclusion. The superseded CRL is valid if it contains the certificate we
are checking, and is invalid otherwise.

[Tom Gindin] My conclusion is only slightly different: the superseded CRL
is trustworthy if it contains the certificate we are checking and that
certificate does not have either reason "certificateHold" or reason
"removeFromCRL", and is not fully trustworthy otherwise.  The term "valid"
here gets into the semantic debate above.

(snip)




Received: from relay3-gui.server.ntli.net (relay3-gui.server.ntli.net [194.168.4.200]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id PAA02894 for <[e-mail]>; Sat, 8 Jul 2000 15:39:19 -0700 (PDT)
Received: from m83-mp1-cvx1b.hud.ntl.com ([62.252.104.83] helo=dwc-acer) by relay3-gui.server.ntli.net with esmtp (Exim 3.03 #2) id 13B389-0007Cl-00; Sat, 08 Jul 2000 23:31:25 +0100
From: "David Chadwick" <[e-mail]>
Organization: University of Salford
To: "David P. Kemp" <[e-mail]>, [e-mail]
Date: Sat, 8 Jul 2000 23:40:05 +0100
MIME-Version: 1.0
Content-type: text/plain; charset=US-ASCII
Content-transfer-encoding: 7BIT
Subject: Re: Operational Protocols - LDAPv3
Reply-to: [e-mail]
Message-ID: <3967BBD5.27655.2684AE0@localhost>
Priority: normal
In-reply-to: <[e-mail]>
X-mailer: Pegasus Mail for Win32 (v3.12c)

> Professor Chadwick,

David

thanks for the complement, but I am not a professor in the UK, just 
a lecturer

> 
> An observation and an opinion:
> 
> 1. Clients that do verify the server still run the risk of being
>    sent a "still valid" but superceded CRL.  The attacker just
>    denies the server access to the latest CRL.
> 

Agreed, this can happen, but the sender (particularly if its a CA or 
part of the CA administration) will then be aware of a fault or an 
attack and may be able to quickly counteract it. A user on the other 
hand will be less likely to be aware of the attack. So the risk is 
greater.

> 2. Using the term "still-valid-but-superceded" implies that CRLs
>    have a validity period.  Certificates have a Validity period,
>    but CRLs have values for thisUpdate and nextUpdate.  A CRL does not
>    become invalid when the next CRL is issued, although some
>    applications behave as though it does. 

We are playing with fine semantics here. Is a superceded CRL 
invalid or not? No, its not technically invalid, as everything it contains 
is good and true, but it is certainly incomplete (in the scenario we 
are discussing). Is an incomplete CRL invalid or not? I would say 
from a trust perspective yes, given that another CRL has been 
issued and therefore one or more other certificates have been 
revoked and I dont know which ones they are, therefore I cannot 
rely on the superceded CRL, therefore it might as well be invalid. In 
other words, for certificate X, where X is not in the list of revoked 
certificates in the superceded CRL, using the superceded CRL or 
using an invalid CRL give me exactly the same answer, viz: I dont 
know if X has been revoked or not. The superceded CRL can only 
be regarded as being valid, if X is in the list of revoked certificates. 

Conclusion. The superceded CRL is valid if it contains the certificate 
we are checking, and is invalid otherwise.

I dont need to quote the following to you, but here is what X.509 
says about nextUpdate:

The next revocation list could be issued before the indicated date, 
but it will *not* be issued any later than the indicated time. 

Therefore after nextUpdate has passed I know that a later CRL 
definately exists, and I am open to attack if I dont have it. If I dont 
have the later one, I should treat the earlier as valid for certificates 
it contains, and invalid for all others.

> In addition to forcing CAs
>    to populate CRLs with deliberately incorrect values for nextUpdate,

By this I assume you mean overly long values. There is a difference 
between knowing that another CRL has been published and 
knowing that one has not. In the later case the current CRL is valid 
for all certificates, in the former case it is not. Thus a CA that has 
failed to publish before nextUpdate expires, forces the RPs to 
assume the former when the later is the truth (which is secure but 
inconvenient to the users) By having an overly long nextUpdate, and 
publishing before it expires, those users who dont have the latest 
CRL will believe the latter whilst the former is true (which is 
insecure for the users but convenient to them.) Thus security 
dictates a CA should have a shorter nextUpdate whilst user 
convenience dictates the opposite. This phenomenon often occurs 
i.e. that user convenience is opposite to security. (You have 
probably heard about Lotus having a configuration switch to say 
"use expired certificates" as it was inconvenient to users that they 
could not check signatures with expired certificates. This is another 
facet of the same phenomenon)


>    this "CRL Validity" interpretation eliminates the ability of the
>    client to decide, based on the value of information, how fresh its
>    revocation information needs to be.

I dont fully agree with you. I think rather that it is actually a user 
interface issue and an administration issue. If user interfaces had a 
"get latest CRL now" button, a client could decide before each 
signature verification, irrespective of update period and validity, 
whether to refresh now or not. But as we stand now without this 
button, with a long update period the client believes there is no need 
to decide, and everything is OK. With a short update period the 
client may have to make a decision if his current CRL has expired 
and he does not have the latest one. And this is the administration's 
decision of how long to make the update period. Do they want to 
inconvenience the users by having short times and force them to 
make decisions occasionally, or have long times so that they do not 
need to bother ever. If you are an administrator, then you are in the 
fortunate position of being able to make this choice. Enjoy

David

>  If CRLs are issued every hour,
>    I might demand a CRL less than 3 hours old to authenticate a
>    purchase. 

It depends upon the size of the purchase. For a large one you 
would want the latest. Risk vs Size of Loss is important. For a one 
dollar purchase you probably would not bother with a CRL at all.

> When reading PKIX mail on the road, however, I'd be
>    quite happy with whatever CRLs were available the last time I was
>    online, say yesterday or even the day before :-).  If a CA issues
>    CRLs every month, I'd rather be warned that, according to my
>    application preferences, that CA's certs shouldn't be used for
>    purchases.  I don't want the application to blindly treat them as
>    just as fresh as certs from CAs who issue CRLs daily or hourly.
> 
> Dave Kemp
> 
> 


***************************************************

David Chadwick
IS Institute, University of Salford, Salford M5 4WT
Tel [phone]  Fax [phone]
Mobile [phone]
Email [e-mail]
Home Page  http://www.salford.ac.uk/its024/chadwick.htm
Understanding X.500  http://www.salford.ac.uk/its024/X500.htm
X.500/LDAP Seminars http://www.salford.ac.uk/its024/seminars.htm
Entrust key validation string MLJ9-DU5T-HV8J

***************************************************


Received: from relay3-gui.server.ntli.net (relay3-gui.server.ntli.net [194.168.4.200]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id KAA23356 for <[e-mail]>; Sat, 8 Jul 2000 10:26:32 -0700 (PDT)
Received: from m184-mp1-cvx1c.hud.ntl.com ([62.252.108.184] helo=dwc-acer) by relay3-gui.server.ntli.net with esmtp (Exim 3.03 #2) id 13AyF4-0004hc-00; Sat, 08 Jul 2000 18:18:23 +0100
From: "David Chadwick" <[e-mail]>
Organization: University of Salford
To: [e-mail]
Date: Sat, 8 Jul 2000 18:26:54 +0100
MIME-Version: 1.0
Content-type: Multipart/Mixed; boundary=Message-Boundary-16738
Subject: PKIX ID on LDAPv3 Schema
Reply-to: [e-mail]
CC: [e-mail], [e-mail]
Message-ID: <3967726E.23329.1498525@localhost>
Priority: normal
X-mailer: Pegasus Mail for Win32 (v3.12c)

--Message-Boundary-16738
Content-type: text/plain; charset=US-ASCII
Content-transfer-encoding: 7BIT
Content-description: Mail message body

Dear ID editor

could you please publish the enclosed as an Internet Draft. It is 
work being done under the remit of the PKIX group, but I am 
copying it to the LDAPExt group as it is of interest to them as well

Thankyou
David

***************************************************

David Chadwick
IS Institute, University of Salford, Salford M5 4WT
Tel [phone]  Fax [phone]
Mobile [phone]
Email [e-mail]
Home Page  http://www.salford.ac.uk/its024/chadwick.htm
Understanding X.500  http://www.salford.ac.uk/its024/X500.htm
X.500/LDAP Seminars http://www.salford.ac.uk/its024/seminars.htm
Entrust key validation string MLJ9-DU5T-HV8J

***************************************************


--Message-Boundary-16738
Content-type: text/plain; charset=US-ASCII
Content-transfer-encoding: 7BIT
Content-description: Text from file 'PKIXSchema-00.txt'

Internet-Draft                                       D.W.Chadwick
PKIX WG                       		   University of Salford      
Intended Category: Standards Track             
Expires: 8 January 2001                            8 July 2000





	    Internet X.509 Public Key Infrastructure
	    Additional LDAP Schema for PKIs and PMIs
		<draft-pkix-ldap-schema-00.txt>


STATUS OF THIS MEMO

This document is an Internet-Draft and is in full conformance with 
all the provisions of Section 10 of RFC2026 [1].

Internet-Drafts are working documents of the Internet Engineering 
Task Force (IETF), its areas, and its working groups. Note that other
groups may also distribute working documents as Internet-Drafts.

Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference 
material or to cite them other than as "work in progress."

The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt.

The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.

This Internet-Draft expires on 6 January 2001. Comments and 
suggestions on this document are encouraged. Comments on this 
document should be sent to the PKIX working group discussion list:
                <[e-mail]>
or directly to the author.


ABSTRACT

This document describes LDAP schema features in addition to RFC 2587 
that are needed to support a Privilege Management Infrastructure and 
a Public Key Infrastructure.


1. Introduction

RFC2587 [8] describes some of the subschema applicable to LDAPv2 
servers [2], specifically the public key certificate related 
attribute types and object classes that MUST or MAY be supported. 
This [document/ID/standard] does not revoke any of the contents of 
RFC2587, but supplements them. 

RFC2587 is equally applicable to LDAPv3 [4] servers as to LDAPv2 
servers and MUST be supported by LDAPv3 servers.

Neither RFC2587 nor the user schema for LDAPv3 (RFC2256 [3]) nor the 
attribute syntax definitions for LDAPv3 (RFC2252 [7]) describe in 
detail the matching rules that should be supported by LDAP servers, 
nor do they describe how attribute value assertions for each matching 
rule should be encoded in filter items.

Finally none of these documents mention attributeCertificates or any 
schema to support privilege management, since these concepts 
superseded the publishing of the RFCs.

2. Subschema Publishing

LDAPv3 allows the subschema supported by a server to be published in 
a subschema subentry. Clients following this profile which support 
the Search operation containing an extensible matching rule SHOULD 
use the subschemaSubentry attribute in the root DSE to find the 
subschemaSubentry, and SHOULD use the matchingRule and 
matchingRuleUse operational attributes in the subschema subentry in 
order to determine whether the server supports the various matching 
rules described below. Servers which support extensible matching 
SHOULD publish the matching rules they support in the matchingRule 
and matchingRuleUse operational attributes.

3. Public Key Certificate Matching Rules

X.509 [9] supports both equality and flexible certificate matching 
rules by the server, via the certificateExactMatch and 
certificateMatch MATCHING-RULEs respectively. (For example, a client 
may flexibly search for certificates with a particular validity time, 
key usage, policy or other field.) LDAPv3 servers MUST support the 
certificateExactMatch matching rule. Clients MAY support 
certificateExactMatch values for equalityMatch filters. LDAPv3 
servers SHOULD support the certificateMatch matching rule. If the 
server does support flexible matching (either via certificateMatch or 
some other matching rule), then the extensibleMatch filter of the 
Search request MUST be supported. Clients MAY support the 
extensibleMatch filter and one or more of the optional elements of 
certificateMatch.

Neither of the above matching rules are mentioned in the LDAPv3 
standards [3 or 7], and only the equality matching rule is mentioned 
in [8], but nowhere is it defined for LDAP servers. It is expected 
that future revisions of the LDAPv3 documents will include these 
definitions, which are described below. 

3.1 Certificate Exact Match

Certificate exact match is defined in 11.3.1 of [9]. The string 
description of the certificateExactMatch matching rule is:

( 2.5.13.34 NAME 'certificateExactMatch'
    SYNTAX 1.3.6.1.4.1.1466.115.121.1.x )

Note. x is still to be allocated

The LDAP syntax definition is:

( 1.3.6.1.4.1.1466.115.121.1.x DESC 'Certificate Serial Number and 
Issuer' )

Values in this syntax are encoded as an integer, a dollar ($) 
separator and a string encoding of the distinguished name of the 
issuing CA.


3.2 Certificate Match

Certificate match is defined in 11.3.2 of [9]. The string description 
of the certificateMatch matching rule is:

( 2.5.13.35 NAME 'certificateMatch'
    SYNTAX 1.3.6.1.4.1.1466.115.121.1.y )

Note. y is still to be allocated

The syntax definition is:

( 1.3.6.1.4.1.1466.115.121.1.y DESC 'Certificate Assertion' )

The ASN.1 for certificateAssertion is defined in 11.3.2 of [9], as 
are the semantics of each of its component types. The LDAP string 
encoding of this is:
- an optional integer representing the certificate serial number,
- followed by a dollar separator ($), 
- followed by an optional string encoding of the distinguished name 
of the issuing CA, 
- followed by a dollar separator,
- followed by an optional string encoding of the subject key 
identifier octet string using hex character encoding, 
- followed by a dollar separator,
- followed by an optional string encoding of the authority key 
identifier octet string using hex character encoding,
(Editor's note. This is a subset of the X.509 allowed values for 
authority key identifier. Is this the best choice to make?) 
- followed by a dollar separator,
- followed by an optional string representation of the generalised 
time of the certificate validity (in the format yyyymmddhhmmssZ as 
specified in RFC 2252),
- followed by a dollar separator, 
- followed by an optional string representation of the generalised 
time for the private key validity, 
- followed by a dollar separator
- followed by an optional string encoding of the object identifier 
of the subject public key algorithm, 
- followed by a dollar separator,
- followed by an optional string encoding of the key usage bit 
string according to RFC 2252 e.g. '0101111101'B. The first (left 
most) bit represents key usage digital signature (bit 0). Note 
that if less bits are present than defined in the keyUsage field 
it is assumed that those right most bits that are not present have 
the value 0,
- followed by a dollar separator,
- followed by an optional string encoding of the subjectAltName type 
using the following keywords "rfc822", "dns", "x400", "ldapdn", 
"edi", "uri", "ip", "oid", or the string encoding of the object 
identifier the other name form type being sought if it is none of 
the above,
- followed by a dollar separator,
- followed by an optional string encoding of one or more object 
identifiers of certificate policies each separated by "+" 
character if there is more than one,
- followed by a dollar separator,
- followed by an optional string encoding of the distinguished name 
of the entity to which a certification path cannot be made
- followed by a dollar separator,
- followed by an optional string encoding of the distinguished name 
of the subject,
- followed by a dollar separator,
- followed by an optional string encoding of the name constraints as 
follows: the string "permitted" followed by a "+" followed by the 
type of name using one of the keywords "rfc822", "dns", "x400", 
"ldapdn", "edi", "uri", "ip", "oid", or the string encoding of the 
object identifier the name type, followed by a "+" followed by a 
string encoding of the name, followed by "excluded", a "+", the 
type of name, a "+" and the string encoding of the name of the 
excluded subtree,
Editor's note 1. With proper BNF for this we can miss out either the 
permitted or excluded components
Editor's note 2. This is a subset of the allowed values of name 
contstraints (minimum and maximum are missing). Do we want to add 
these?
- and finally ending with a dollar separator.

Where any optional field is missing this is indicated by the presence 
of two contiguous dollar separators (or if the certificate serial 
number is missing a certificate assertion that starts with a dollar 
separator).

Editors Notes.
1. We need to decide whether searching for cross certificates should 
be supported by this LDAPv3 profile or not. If we decide that this 
should be supported, then we will need to define the matching 
rules to be supported and the string encodings for the assertion 
syntaxes (in fact this is not too difficult since they are similar 
to certificate matching rules and AVAs).
2. We need to decide if userSMIMECertificates should also be 
supported as part of this profile or not.


4. Public Key Certificate Revocation List Matching Rules

X.509[9] defines both equality and flexible matching rules for CRLs, 
via the certificateListExactMatch and certificateListMatch MATCHING-
RULEs respectively. LDAPv3 servers MUST support the 
certificateListExactMatch matching rule. Clients MAY support 
certificateListExactMatch values for equalityMatch filters. LDAPv3 
servers MAY support the certificateListMatch matching rule. If the 
server does support flexible matching (either via 
certificateListMatch or some other matching rule), then the 
extensibleMatch filter of the Search request MUST be supported. 
Clients MAY support the extensibleMatch filter and one or more of the 
optional elements of certificateListMatch.

4.1 Certificate List Exact Match

Certificate List exact match is defined in 11.3.5 of [9]. The string 
description of the certificateListExactMatch matching rule is:

( 2.5.13.38 NAME 'certificateListExactMatch'
    SYNTAX 1.3.6.1.4.1.1466.115.121.1.z )

Note. z is still to be allocated

The syntax definition is:

( 1.3.6.1.4.1.1466.115.121.1.z DESC 'Issuer name, time and 
distribution point name' )

Values in this syntax are encoded as a string encoding of a 
distinguished name, a dollar ($) separator, a string representation 
of generalised time, a dollar separator and an optional string 
encoding of the distinguished name of the distribution point. 

(Editor's Note. The latter DN encoding for a distribution point name 
is a subset of the allowed variants, which can be a generalName or an 
RDN. Should this simplification be allowed?)


4.2 Certificate List Match

Certificate List match is defined in 11.3.6 of [9]. The string 
description of the certificateListMatch matching rule is:

( 2.5.13.39 NAME 'certificateListMatch'
    SYNTAX 1.3.6.1.4.1.1466.115.121.1.w )

Note. w is still to be allocated

The syntax definition is:

( 1.3.6.1.4.1.1466.115.121.1.w DESC 'Certificate List Assertion' )

The ASN.1 for certificateListAssertion is defined in 11.3.6 of [9]. 

Values in this syntax are encoded as:
- an optional string encoding of the distinguished name of the 
issuer, 
- followed by a dollar ($) separator,
- followed by an optional string encoding of an integer representing 
the minimum CRL number,
- followed by a dollar separator, 
- followed by an optional string encoding of an integer representing 
the maximum CRL number,
- followed by a dollar separator,
- followed by an optional string encoding of the reason flags bit 
string according to RFC 2252 e.g. '010111110'B. The first (left 
most) bit represents unused reason flag (bit 0). Note that if less 
bits are present than defined in the reason flags field it is 
assumed that those right most bits that are not present have the 
value 0,
- followed by a dollar separator, 
- followed by an optional string representation of the generalised 
time for the CRL validity, 
- followed by an optional string encoding of the authority key 
identifier octet string using hex character encoding,
(Editor's note. This is a subset of the X.509 allowed values for 
authority key identifier. Is this the best choice to make?) 
- and ending with a dollar separator.


5. Privilege Management Schema

LDAP servers MAY store any type of attribute with the 
AttributeCertificate syntax, and LDAP clients MAY request them to be 
returned by adding them to the Search Request 
AttributeDescriptionList (either explicitly or implicity via 
requesting all attributes). LDAP servers that do support the storage 
of attributes with the AttributeCertificate syntax MUST support 
searching for entries containing specific attribute certificates, via 
the attributeCertificateExactMatch matching rule. 

LDAPv3Servers MAY support flexible matching for any attributes with 
the AttributeCertificate syntax via the attributeCertificateMatch 
matching rule or any of the matching rules defined for the 
certificate extensions. LDAPv3 servers SHOULD publish the matching 
rules that they do support in the matchingRule and matchingRuleUse 
operational attributes of the subschema subentry. LDAPv3 clients MAY 
support the extensibleMatch filter of the Search operation, along one 
or more of the optional elements of attributeCertificateMatch or any 
of the certificate extension matching rules.

For the convenience of the reader, some of the subchema definitions 
to support attribute certificates are produced below, but it is 
anticipated that these will be moved to a subsequent revision of the 
LDAPv3 standard.

5.1 PMI Attributes

The attributeCertificateAttribute holds the privileges of a user.

attributeCertificateAttribute    ATTRIBUTE  ::=  {
     WITH SYNTAX   		AttributeCertificate
     EQUALITY MATCHING RULE   attributeCertificateExactMatch
     ID  joint-iso-ccitt(2) ds(5) attributeType(4) 
attributeCertificate(58) }


The aAcertificate holds the privileges of an attribute authority

aACertificate		ATTRIBUTE	::=	{
 	WITH SYNTAX			AttributeCertificate
	EQUALITY MATCHING RULE	attributeCertificateExactMatch
	ID joint-iso-ccitt(2) ds(5) attributeType(4) aACertificate(61}


The attributeDescriptorCertificate is self signed by a source of 
authority and holds a description of the privilege and its delegation 
rules.

attributeDescriptorCertificate  ATTRIBUTE  ::= {
  	WITH SYNTAX			AttributeCertificate
  	EQUALITY MATCHING RULE   attributeCertificateExactMatch
  	ID     joint-iso-ccitt(2) ds(5) attributeType(4) 
attributeDescriptorCertificate (62) }

The attributeCertificateRevocationList holds a list of attribute 
certificates that have been revoked.

attributeCertificateRevocationList 	ATTRIBUTE ::= {
	WITH SYNTAX			CertificateList
	EQUALITY MATCHING RULE	certificateListExactMatch
	ID	joint-iso-ccitt(2) ds(5) attributeType(4) aCRL(59) }


The attributeAuthorityList holds a list of AA certificates that have 
been revoked.

attributeAuthorityRevocationList	ATTRIBUTE	::= {
	WITH SYNTAX			CertificateList
	EQUALITY MATCHING RULE  	certificateListExactMatch
	ID	joint-iso-ccitt(2) ds(5) attributeType(4) aARL(63) }


5.2 PMI Object Classes

pmiUser OBJECT-CLASS ::= {
-- a privilege holder  
SUBCLASS OF  {top}
   	KIND         auxiliary
   	MAY CONTAIN  {attributeCertificateAttribute}
   	ID 	joint-iso-ccitt(2) ds(5) objectClass(6) pmiUser (24)}


pmiAA OBJECT-CLASS ::= { 
 -- an attribute authority
   	SUBCLASS OF  {top}
   	KIND         auxiliary
  	 MAY CONTAIN  	{aACertificate |           			
			attributeCertificateRevocationList |
                	attributeAuthorityRevocationList}
   	ID joint-iso-ccitt(2) ds(5) objectClass(6) pmiAA (25)}


pmiSOA OBJECT-CLASS ::= { 
 -- a PMI Source of Authority
   SUBCLASS OF  	{top}
   KIND         		auxiliary
   MAY CONTAIN  	{attributeCertificateRevocationList |
                		attributeAuthorityRevocationList |
 				attributeDescriptorCertificate}
   	ID         joint-iso-ccitt(2) ds(5) objectClass(6) pmiSOA (26)}


5.3 PMI Matching Rules

5.3.1 Attribute Certificate Exact Match

The equality matching rule for all types of attribute with 
AttributeCertificate syntax is the attributeCertificateExactMatch, 
This is defined in 17.3.1 of [9]. It is reproduced below for the 
convenience of the reader.

attributeCertificateExactMatch MATCHING-RULE  ::= {
SYNTAX	AttributeCertificateExactAssertion
ID	joint-iso-ccitt(2) ds(5) mr (13) 
attributeCertificateExactMatch (45) }

AttributeCertificateExactAssertion	::=	SEQUENCE {
serialNumber		CertificateSerialNumber,
issuer			IssuerSerial 	}

CertificateSerialNumber	::=	INTEGER

IssuerSerial  ::=  SEQUENCE {
	issuer		GeneralNames,
	serial		CertificateSerialNumber,
	issuerUID		UniqueIdentifier OPTIONAL }

UniqueIdentifier	::=	BIT STRING

The LDAP definition for the above matching rule is:

( 2.5.13.45 NAME 'attributeCertificateExactMatch'
    SYNTAX 1.3.6.1.4.1.1466.115.121.1.m )

Note that the value of m is still to be allocated.

The syntax definition is:

( 1.3.6.1.4.1.1466.115.121.1.m DESC 'Attribute certificate serial 
number and public key issuer and serial number' )

Values in this syntax are encoded as a string encoding of an integer 
(the serial number of the attribute certificate), a dollar ($) 
separator, a string representation of the distinguished name of the 
CA of the issuer, a dollar separator, a string encoding of an integer 
(the serial number of the issuer's public key certificate), a dollar 
separator and optionally a string encoding of the unique identifier 
bit string according to RFC 2252 e.g. '010111110'B. 

Editors note. Issuer DN is a subset of the allowed GeneralNames. Do 
we wish to allow any type?

5.3.2 Attribute Certificate Match

Attribute certificate matching rule is defined in section 17.3.2 of 
[9]. For the convenience of the reader it is reproduced below:

attributeCertificateMatch  MATCHING-RULE  ::=  {
	SYNTAX	AttributeCertificateAssertion
	ID		joint-iso-ccitt(2) ds(5) mr (13) 
attributeCertificateMatch (42) }


AttributeCertificateAssertion  ::=  SEQUENCE  {
subject		[0]	CHOICE {
			baseCertificateID	[0]  IssuerSerial,
			subjectName		[1]  GeneralNames} OPTIONAL,
	issuer		[1]	GeneralNames OPTIONAL,
	attCertValidity	[2]	GeneralizedTime OPTIONAL,
	attType		[3]	SET OF AttributeType OPTIONAL}
--At least one component of the sequence must be present

The LDAP definition of the attributeCertificateMatch matching rule 
is:

( 2.5.13.42 NAME 'attributeCertificateMatch'
    SYNTAX 1.3.6.1.4.1.1466.115.121.1.n )

Note that the value of n is still be assigned.

The syntax definition is:

( 1.3.6.1.4.1.1466.115.121.1.n 
DESC 'Attribute Certificate Assertion' )

The LDAP string encoding of this is:

- Optionally a string encoding of a distinguished name, optionally 
followed by a "+" and a string encoding of an integer,
Note. If the optional + and integer are missing the distinguished 
name is the name of the holder of the attribute certificate, whereas 
if they are present it is the name of the issuer of the certificate 
and the integer is the serial number of the holder's certificate.
Editors note. Distinguished names are a subset of the allowed types 
in General Name. Is this OK or too restrictive?
- followed by a dollar ($) separator,
- followed by an optional string encoding of the distinguished name 
of the issuer, 
Editor's Note. This is a subset of the allowed General Names. Is it 
sufficient?
- followed by a dollar separator,
- followed by an optional string representation of the generalised 
time of the certificate validity (in the format yyyymmddhhmmssZ as 
specified in RFC 2252),
- followed by a dollar separator,
- followed by an optional string encoding of one or more object 
identifiers of attribute types each separated by "+" character if 
there is more than one.


Editor's Note. X.509 defines the following matching rules for 
matching on various extensions within an attribute certificate. 
Before any of them is defined for LDAP, we need to decide how many of 
them are really useful.

5.3.3 Holder Issuer Match

5.3.4 Delegation Path Match

5.3.5 Authority Attribute Identifier Match

5.3.6 Role Specification Certificate Identifier Match

5.3.7 Basic Attribute Constraints Match

5.3.8 Delegated Name Constraints Match

5.3.9 Time Specification Match

5.3.10 Acceptable Certificate Policies Match

5.3.11 Attribute Descriptor Match

5.3.12 Source of Authority Match
Note. This rule has not been defined by X.509, but this is perhaps an 
omission that should be rectified. It is an easy matching rule to 
define since it has a null syntax i.e. we will be matching on present 
or not.


6. Security Considerations

This [Internet Draft/Standard] describes the schema for the storage 
and matching of attribute certificates and revocation lists in an 
LDAP directory server. It does not address the protocol for the 
retrieval of this information.

LDAP servers SHOULD use access control information to protect the 
information during its storage. In addition, clients MAY choose to 
encrypt the attributes in the attribute certificates before storing 
them in an LDAP server.


7 Copyright

Copyright (C) The Internet Society (date). All Rights Reserved.

This document and translations of it may be copied and furnished to 
others, and derivative works that comment on or otherwise explain it 
or assist in its implementation may be prepared, copied, published 
and distributed, in whole or in part, without restriction of any 
kind, provided that the above copyright notice and this paragraph are 
included on all such copies and derivative works.  However, this 
document itself may not be modified in any way, such as by removing 
the copyright notice or references to the Internet Society or other 
Internet organizations, except as needed for the purpose of 
developing Internet standards in which case the procedures for 
copyrights defined in the Internet Standards process must be 
followed, or as required to translate it into languages other than 
English.

The limited permissions granted above are perpetual and will not be 
revoked by the Internet Society or its successors or assigns.

This document and the information contained herein is provided on an 
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.


8. References

[1] Bradner, S. The Internet Standards Process -- Revision 3. RFC 
2026  October 1996.
[2] Yeong, W., Howes, T., and Kille, S. "Lightweight Directory Access 
Protocol", RFC 1777, March 1995.
[3] M.Wahl. "A Summary of the X.500(96) User Schema for use with 
LDAPv3" RFC 2256, Dec 1997
[4] M. Wahl, T. Howes, S. Kille, "Lightweight Directory Access  
Protocol (v3)", Dec. 1997, RFC 2251
[5] S.Bradner. "Key words for use in RFCs to Indicate Requirement 
Levels", RFC 2119, March 1997.
[6] M. Wahl, S. Kille, T. Howes. "Lightweight Directory Access 
Protocol (v3): UTF-8 String Representation of Distinguished Names", 
RFC2253, December 1997.
[7] M. Wahl, A. Coulbeck, T. Howes, S. Kille, "Lightweight Directory 
Access Protocol (v3): Attribute Syntax Definitions", RFC 2252, Dec 
1997
[8] S.Boeyen, T. Howes, P. Richard "Internet X.509 Public Key 
Infrastructure, LDAPv2 Schema", RFC 2587, June 1999
[9] ITU-T Rec. X.509(2000) The  Directory:  Authentication
Framework


9 Authors Address

David Chadwick
IS Institute
University of Salford
Salford
England
M5 4WT 

Email: [e-mail]




Internet-Draft   PKIX Operational Protocols - LDAP Schema   8 July 2000



--Message-Boundary-16738--


Received: from roadblock.missi.ncsc.mil ([144.51.50.70]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id NAA29163 for <[e-mail]>; Fri, 7 Jul 2000 13:42:25 -0700 (PDT)
Received: from roadblock.missi.ncsc.mil (root@localhost) by roadblock.missi.ncsc.mil with ESMTP id QAA17619 for <[e-mail]>; Fri, 7 Jul 2000 16:33:58 -0400 (EDT)
Message-Id: <[e-mail]>
Date: Fri, 7 Jul 2000 16:40:37 -0400 (EDT)
From: "David P. Kemp" <[e-mail]>
Reply-To: "David P. Kemp" <[e-mail]>
Subject: Re: Operational Protocols - LDAPv3
To: [e-mail]
MIME-Version: 1.0
Content-Type: TEXT/plain; charset=us-ascii
Content-MD5: G1dEu1Vi4nk6oevtaMMxHg==
X-Mailer: dtmail 1.3.0 CDE Version 1.3 SunOS 5.7 sun4u sparc

> From: "David Chadwick" <[e-mail]>
> To: Rich Salz <[e-mail]>, [e-mail]
> Date: Fri, 7 Jul 2000 20:22:42 +0100
> Subject: Re: Operational Protocols - LDAPv3
> 
> 
> > I think it's worth adding a warning that clients who retrieve CRLs
> > without some way of verifying the server run the risk of being sent an
> > obsolete CRL.
> >  /r$
> 
> Good point. Clearly an attacker cannot create a false CRL (without 
> compromising the CA), but an attacker does have a window of 
> opportunity to use a compromised key by denying access to the 
> latest CRL and providing access to a still-valid-but-superceded CRL.
> 
> How does this text sound
> 
> "However, clients that retrieve CRLs
> without some way of verifying the server run the risk of 
> being sent a still valid but superceded CRL."
> 
> David


Professor Chadwick,

An observation and an opinion:

1. Clients that do verify the server still run the risk of being
   sent a "still valid" but superceded CRL.  The attacker just
   denies the server access to the latest CRL.

2. Using the term "still-valid-but-superceded" implies that CRLs
   have a validity period.  Certificates have a Validity period,
   but CRLs have values for thisUpdate and nextUpdate.  A CRL does not
   become invalid when the next CRL is issued, although some
   applications behave as though it does.  In addition to forcing CAs
   to populate CRLs with deliberately incorrect values for nextUpdate,
   this "CRL Validity" interpretation eliminates the ability of the client
   to decide, based on the value of information, how fresh its revocation
   information needs to be.  If CRLs are issued every hour, I might
   demand a CRL less than 3 hours old to authenticate a purchase.  When
   reading PKIX mail on the road, however, I'd be quite happy with
   whatever CRLs were available the last time I was online, say yesterday
   or even the day before :-).  If a CA issues CRLs every month, I'd
   rather be warned that, according to my application preferences, that
   CA's certs shouldn't be used for purchases.  I don't want the
   application to blindly treat them as just as fresh as certs from CAs
   who issue CRLs daily or hourly.
   
Dave Kemp



Received: from rhea.salford.ac.uk (rhea.salford.ac.uk [146.87.255.99]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id MAA27181 for <[e-mail]>; Fri, 7 Jul 2000 12:22:10 -0700 (PDT)
Received: (qmail 51260 invoked by alias); 7 Jul 2000 19:23:41 -0000
Received: (qmail 51248 invoked from network); 7 Jul 2000 19:23:41 -0000
Received: from unknown (HELO dwc-acer) (146.87.80.54) by rhea.salford.ac.uk with SMTP; 7 Jul 2000 19:23:41 -0000
From: "David Chadwick" <[e-mail]>
Organization: University of Salford
To: Rich Salz <[e-mail]>, [e-mail]
Date: Fri, 7 Jul 2000 20:22:42 +0100
MIME-Version: 1.0
Content-type: text/plain; charset=US-ASCII
Content-transfer-encoding: 7BIT
Subject: Re: Operational Protocols - LDAPv3
Reply-to: [e-mail]
Message-ID: <39663C12.8000.49E0F1E@localhost>
Priority: normal
In-reply-to: <[e-mail]>
X-mailer: Pegasus Mail for Win32 (v3.12c)

> I think it's worth adding a warning that clients who retrieve CRLs
> without some way of verifying the server run the risk of being sent an
> obsolete CRL.
>  /r$

Good point. Clearly an attacker cannot create a false CRL (without 
compromising the CA), but an attacker does have a window of 
opportunity to use a compromised key by denying access to the 
latest CRL and providing access to a still-valid-but-superceded CRL.

How does this text sound

"However, clients that retrieve CRLs
without some way of verifying the server run the risk of 
being sent a still valid but superceded CRL."

David

> 


***************************************************

David Chadwick
IS Institute, University of Salford, Salford M5 4WT
Tel [phone]  Fax [phone]
Mobile [phone]
Email [e-mail]
Home Page  http://www.salford.ac.uk/its024/chadwick.htm
Understanding X.500  http://www.salford.ac.uk/its024/X500.htm
X.500/LDAP Seminars http://www.salford.ac.uk/its024/seminars.htm
Entrust key validation string MLJ9-DU5T-HV8J

***************************************************


Received: from sothmxs01.entrust.com (gatekeeper.entrust.com [204.101.128.170]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id MAA27161 for <[e-mail]>; Fri, 7 Jul 2000 12:22:06 -0700 (PDT)
Received: by sothmxs01.entrust.com with Internet Mail Service (5.5.2650.21) id <N7C9RVPY>; Fri, 7 Jul 2000 15:23:07 -0400
Message-ID: <[e-mail]>
From: Carlisle Adams <[e-mail]>
To: "'[e-mail]'" <[e-mail]>
Subject: FW: I-D ACTION:draft-adams-cmpaltcert-00.txt
Date: Fri, 7 Jul 2000 15:22:08 -0400 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: multipart/mixed; boundary="----_=_NextPart_000_01BFE848.A4AB6AD0"

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_000_01BFE848.A4AB6AD0
Content-Type: text/plain

Hi,

This may be of moderate interest/relevance to some of the people in PKIX.

I submitted it as an independent draft because its whole purpose is to deal
with non-X.509 public-key certificates, but it is nevertheless connected to
PKIX because it explains how to use CMP (rfc2510bis) for the management of
such certificates.  In any case, I'd be interested in comments on this
proposal (on the list or privately, but keep in mind that this is not
technically a PKIX work item).  We can, however, discuss on the list whether
or not this draft should be brought into the PKIX WG.

Carlisle.


> ----------
> From: 	[e-mail][SMTP:[e-mail]]
> Reply To: 	[e-mail]
> Sent: 	Friday, July 07, 2000 7:04 AM
> Subject: 	I-D ACTION:draft-adams-cmpaltcert-00.txt
> 
>  <<...>> 
> A New Internet-Draft is available from the on-line Internet-Drafts
> directories.
> 
> 
> 	Title		: Alternative Certificate Formats for PKIX-CMP
> 	Author(s)	: C. Adams
> 	Filename	: draft-adams-cmpaltcert-00.txt
> 	Pages		: 6
> 	Date		: 06-Jul-00
> 	
> The PKIX Certificate Management Protocols (PKIX-CMP) specification 
> [1], while primarily focused on X.509v3 public-key certificates, 
> allows the messages it defines to be used for the management of  
> alternative certificate formats as well.  This document specifies 
> precisely how such formats may be incorporated into PKIX-CMP and 
> provides the relevant syntax for some important certificate types.
> 
> A URL for this Internet-Draft is:
> http://www.ietf.org/internet-drafts/draft-adams-cmpaltcert-00.txt
> 
> Internet-Drafts are also available by anonymous FTP. Login with the
> username
> "anonymous" and a password of your e-mail address. After logging in,
> type "cd internet-drafts" and then
> 	"get draft-adams-cmpaltcert-00.txt".
> 
> A list of Internet-Drafts directories can be found in
> http://www.ietf.org/shadow.html 
> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt
> 
> 
> Internet-Drafts can also be obtained by e-mail.
> 
> Send a message to:
> 	[e-mail].
> In the body type:
> 	"FILE /internet-drafts/draft-adams-cmpaltcert-00.txt".
> 	
> NOTE:	The mail server at ietf.org can return the document in
> 	MIME-encoded form by using the "mpack" utility.  To use this
> 	feature, insert the command "ENCODING mime" before the "FILE"
> 	command.  To decode the response(s), you will need "munpack" or
> 	a MIME-compliant mail reader.  Different MIME-compliant mail readers
> 	exhibit different behavior, especially when dealing with
> 	"multipart" MIME messages (i.e. documents which have been split
> 	up into multiple messages), so check your local documentation on
> 	how to manipulate these messages.
> 		
> 		
> Below is the data which will enable a MIME compliant mail reader
> implementation to automatically retrieve the ASCII version of the
> Internet-Draft.
> 

------_=_NextPart_000_01BFE848.A4AB6AD0
Content-Type: message/rfc822

To: 
Subject: 
Date: Fri, 7 Jul 2000 15:23:08 -0400 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: multipart/mixed;
	boundary="----_=_NextPart_002_01BFE848.A4AB6AD0"


------_=_NextPart_002_01BFE848.A4AB6AD0
Content-Type: text/plain



------_=_NextPart_002_01BFE848.A4AB6AD0
Content-Type: application/octet-stream;
	name="ATT12571"
Content-Disposition: attachment;
	filename="ATT12571"

Content-type: message/external-body;
	access-type="mail-server";
	server="[e-mail]"

Content-Type: text/plain
Content-ID:	<[e-mail]>

ENCODING mime
FILE /internet-drafts/draft-adams-cmpaltcert-00.txt

------_=_NextPart_002_01BFE848.A4AB6AD0
Content-Type: message/external-body;
	site="internet-drafts";
	dir="draft-adams-cmpaltcert-00.txt";
	mode="ftp.ietf.org";
	access-type="anon-ftp"


------_=_NextPart_002_01BFE848.A4AB6AD0--

------_=_NextPart_000_01BFE848.A4AB6AD0--


Received: from mail-fwd.verio-web.com ([161.58.16.59]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id LAA25867 for <[e-mail]>; Fri, 7 Jul 2000 11:17:19 -0700 (PDT)
Received: from 161.58.117.181 (161.58.117.181) by mail11b.verio-web.com (RS ver 1.0.57s) with SMTP id 01567164; Fri,  7 Jul 2000 14:18:35 -0400 (EDT)
Sender: rsalz
Message-ID: <[e-mail]>
Date: Fri, 07 Jul 2000 14:19:00 -0400
From: Rich Salz <[e-mail]>
X-Mailer: Mozilla 4.72 [en] (X11; U; Linux 2.2.14-5.0 i686)
X-Accept-Language: en
MIME-Version: 1.0
To: "David P. Kemp" <[e-mail]>
CC: [e-mail]
Subject: Re: Operational Protocols - LDAPv3
References: <[e-mail]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
X-Loop-Detect: 1

>   "The same name, in at least one of its name forms, shall be present
>   in the distributionPoint field of the issuing distribution point
>   extension of the CRL."
> 
> Thus the signed certificate and the signed CRL are linked together by
> a common distribution point name.

And if the CRLDP has a name like "pkix-ldap.foo.com", then an adversary
need only spoof DNS to get the client to go somewhere else, get valid --
albeit STALE -- data, and will erroneously proceed, no?
	/r$


Received: from roadblock.missi.ncsc.mil ([144.51.50.70]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id KAA25132 for <[e-mail]>; Fri, 7 Jul 2000 10:57:24 -0700 (PDT)
Received: from roadblock.missi.ncsc.mil (root@localhost) by roadblock.missi.ncsc.mil with ESMTP id NAA06275 for <[e-mail]>; Fri, 7 Jul 2000 13:48:57 -0400 (EDT)
Message-Id: <[e-mail]>
Date: Fri, 7 Jul 2000 13:55:35 -0400 (EDT)
From: "David P. Kemp" <[e-mail]>
Reply-To: "David P. Kemp" <[e-mail]>
Subject: Re: Operational Protocols - LDAPv3
To: [e-mail]
MIME-Version: 1.0
Content-Type: TEXT/plain; charset=us-ascii
Content-MD5: z9lBK/73X4CwCPTqWI+ILQ==
X-Mailer: dtmail 1.3.0 CDE Version 1.3 SunOS 5.7 sun4u sparc

> From: Rich Salz <[e-mail]>
> 
> If a cert has a CRLDP that points to a repository, shouldn't the client
> policy be to verify that it's got the right repository?


Nope.  The CRLDP certificate extension says:

  "The same name, in at least one of its name forms, shall be present
  in the distributionPoint field of the issuing distribution point
  extension of the CRL."

Thus the signed certificate and the signed CRL are linked together by
a common distribution point name.  Whether the CRL came from the named
repository, a different repository, a cache entry, or a floppy disk
doesn't matter.

I agree that the fact that CRLDP is used for two unrelated purposes -
pointing to a repository and partitioning CRLs - is a subtle point.



Received: from mail-fwd.verio-web.com ([161.58.16.59]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id JAA23207 for <[e-mail]>; Fri, 7 Jul 2000 09:20:00 -0700 (PDT)
Received: from 161.58.117.181 (161.58.117.181) by mail11b.verio-web.com (RS ver 1.0.57s) with SMTP id 01549951; Fri,  7 Jul 2000 12:21:19 -0400 (EDT)
Sender: rsalz
Message-ID: <[e-mail]>
Date: Fri, 07 Jul 2000 12:21:44 -0400
From: Rich Salz <[e-mail]>
X-Mailer: Mozilla 4.72 [en] (X11; U; Linux 2.2.14-5.0 i686)
X-Accept-Language: en
MIME-Version: 1.0
To: "David P. Kemp" <[e-mail]>
CC: [e-mail]
Subject: Re: Operational Protocols - LDAPv3
References: <[e-mail]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
X-Loop-Detect: 1

> A CRL includes a nextUpdate field which allows a client to know whether
> a scheduled replacement has been issued.  What benefit is there to
> verifying the server?

The issue here would be unscheduled.

The fact that you wrote something indicates the need for the caveat. :)

>  That policy
> shouldn't have anything to do with the trustworthiness or reliability
> of any LDAP servers.

If a cert has a CRLDP that points to a repository, shouldn't the client
policy be to verify that it's got the right repository?

This seems to be a subtle point missed by many, hence my suggested
addition.
	/r$


Received: from indy.gradient.com (indy.gradient.com [192.92.110.1]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id IAA18139 for <[e-mail]>; Fri, 7 Jul 2000 08:33:57 -0700 (PDT)
Received: from bigbird.gradient.com (bigbird.gradient.com [192.92.110.50]) by indy.gradient.com (8.9.1a/8.9.1) with ESMTP id LAA15000; Fri, 7 Jul 2000 11:33:22 -0400 (EDT)
Received: by bigbird.gradient.com with Internet Mail Service (5.5.2448.0) id <K6XBN082>; Fri, 7 Jul 2000 11:28:07 -0400
Message-ID: <[e-mail]>
From: Hal Lockhart <[e-mail]>
To: "'[e-mail]'" <[e-mail]>, [e-mail], "'Russ Housley'" <[e-mail]>, "'Stephen Farrell'" <[e-mail]>
Subject: RE: Comments: An Intranet Attribute Certificate Profile for Autho rization
Date: Fri, 7 Jul 2000 11:26:10 -0400 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2448.0)
Content-Type: text/plain; charset="iso-8859-1"

Since the responses so far have been negative, let me put in a (partially)
supportive comment.

We are also implementing ACs in an environment where they are passed over a
secure channel. We also are supporting audit id.

> -----Original Message-----
> From: [e-mail] [mailto:[e-mail]]

...

> (1) The draft does not adequately support anonymous 
> operations with audit id.

...

>      The combination of these two requirements implies that 
> there MUST be an
> attribute other
>      than the audit id in an AC.  This makes fully anonymous 
> (but auditable)
> operations very difficult.

I don't really understand this. Anonymous to whom? ACs are no good unless
you bind them to an authenticated identity. Section 4.2.2 requires that if
the authentication is via PKI, they should be bound to the base certificate.
My understanding of RFC 2459 is that there has to be an identity either in
subject name or altname. I recall discussion of explicitly pseudonomous
identifiers, but this was not adopted. Similiarly, most non-PKI
authentication
systems use some kind of username or account to base authorization decisions
on.

It seems to me then that you are trusting the behavior of the process that
consumes the AC and generates the audit record to correctly use the audit id
rather than some traceable identifier. Given that, it seems harmless to have
other crufties (thanks, Peter G.) in the AC.

>      Making audit IDs extensions rather than attributes complicates
> implementation unecessarily
>      in any case, as (at least from the point of view of 
> encoding) they must be
> handled differently than
>      other kinds of IDs (access ids, accounting ids, etc...).

I don't see this. As far as syntax goes, that's what ASN.1 compilers are
for. As far as semantics, each of these is a special case anyway.

...

> Note that this mechanism also permits issuers to define audit 
> IDs without making
> their use mandatory, which
> we view as a  good thing.

I see this as harmless, but hardly benificial. In our environment we will
always use an audit id for auditing if it is present and not use it for
anything else. Authorization is based on subject and other attributes.

If the net of this proposed change is that it should be possible to issue an
AC with "nothing" but an audit id, I guess that seems reasonable, but it is
not part of our requirements.

> (2)  The draft does not support adequately performant pull-protocol
> implementations.

...

> The combination of these requirements implies that even in 
> pull-protocol
> configurations in which the certificate acceptor
> pulls the AC from a trusted repository over a secure, 
> authenticated link, the
> acceptor must do at least one public-key
> verify operation and a hash.  In high-volume cases, 
> especially those employing
> very short-lived ACs, this will impose
> substantial and perhaps unacceptable overhead.

It is worth pointing out that if the ACs are "very short-lived" that are
likely to be constructed by and retrieved from an AA, not a trusted
repository.

> We propose to add another algorithm to the set: 
> NoHashWithNoEncryption.

We have been considering exactly this optimization. However,I am willing to
concede Stephen's point that this may be out of scope for the IETF, given
there are no IETF defined standards defining a protocol with the specified
properties. (LDAP over TLS anyone?)

As for Russ's question about why use ACs in such an environment, there are
lots of reasons:

1) Well defined format usable with widely available tools
2) Desire to make info available over secure and insecure channels, using
standard and non-standard protocols in a single format
3) Intention to comply with future IETF standards as they are enhanced
4) Market value of "standards compliance" (no flames here, we all know this
matters whether we like it or not)
 
> Now the minor issue:
> 
> (3) We may be confused here, but when section 4.2.7 requires 
> that "AC users MUST
> be able to handle multiple values
> for all attribute types" we see trouble.  Do we really want 
> to REQUIRE support
> for multiple values of Access Identity and Charging Identity 
> attributes?

Given that PKIX is full of such undefined constructs, e.g. semantics of
multiple values in alt name, why pick on these two in particular?

Hal

=======================================================
Harold W. Lockhart            Entegrity Solutions
2 Mount Royal Avenue          Marlborough, MA 01752 USA
V: 1-508-624-9600 x 260       [e-mail]
F: 1-508-229-0338             www.entegrity.com
=======================================================

 


Received: from d1o69.telia.com ([e-mail] [62.20.144.241]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id IAA15933 for <[e-mail]>; Fri, 7 Jul 2000 08:00:07 -0700 (PDT)
Received: from mega (t6o69p76.telia.com [213.64.110.196]) by d1o69.telia.com (8.8.8/8.8.8) with SMTP id RAA06641; Fri, 7 Jul 2000 17:01:28 +0200 (CEST)
Message-ID: <002401bfe82c$7eee8870$[e-mail]>
From: "Anders Rundgren" <[e-mail]>
To: "Stephen Kent" <[e-mail]>
Cc: <[e-mail]>
Subject: Re: Cert compare. Was: I-D ACTION:draft-ietf-pkix-qc-04.txt
Date: Fri, 7 Jul 2000 18:00:32 +0200
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 4.72.3110.5
X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by ns.secondary.com id IAA15936

Steve,
<snip>
>At 4:49 PM +0200 7/7/00, Anders Rundgren wrote:
>>  >Comparing two qualified certificates to determine if they represent
>>  >the same physical entity may provide misleading results and should be
>>  >performed with care.
>>
>>Could we then have the Java code for performed with "care" :-)
>>
>>Sorry for wining but I [still] don't see the point of standards with such
>
>The correct spelling here is whining.  Wining is what you have not 
>done in this context.


Oooops! I did it again...  Maybe too much Wine really was the problem :-) :-)

On the more serious side:

   In my (twisted) ears "performed with care" indicates that there is an algorithm or method.  And it is???

   Implementation-defined OTOH denotes the absense of a described algorithm or method.

Maybe "performed with care" is a PKIX-equivalent to implementation-defined?

Anders



Received: from roadblock.missi.ncsc.mil ([144.51.50.70]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id HAA15863 for <[e-mail]>; Fri, 7 Jul 2000 07:59:00 -0700 (PDT)
Received: from roadblock.missi.ncsc.mil (root@localhost) by roadblock.missi.ncsc.mil with ESMTP id KAA00554 for <[e-mail]>; Fri, 7 Jul 2000 10:50:33 -0400 (EDT)
Message-Id: <[e-mail]>
Date: Fri, 7 Jul 2000 10:57:10 -0400 (EDT)
From: "David P. Kemp" <[e-mail]>
Reply-To: "David P. Kemp" <[e-mail]>
Subject: Re: Operational Protocols - LDAPv3
To: [e-mail]
MIME-Version: 1.0
Content-Type: TEXT/plain; charset=us-ascii
Content-MD5: rfZ+n+P6El8SFIUk15e/qQ==
X-Mailer: dtmail 1.3.0 CDE Version 1.3 SunOS 5.7 sun4u sparc

> From: Rich Salz <[e-mail]>
>
> > 6. Security Considerations
> > 
> > The PKI information to be retrieved from LDAPv3 servers (certificates
> > and CRLs) is digitally signed and therefore additional integrity
> > services are NOT REQUIRED.
> 
> I think it's worth adding a warning that clients who retrieve CRLs
> without some way of verifying the server run the risk of being sent
> an obsolete CRL.
> 	/r$


A CRL includes a nextUpdate field which allows a client to know whether
a scheduled replacement has been issued.  What benefit is there to
verifying the server?  Propogation delays will cause even a "good"
server to send out an "obsolete" CRL after a replacement (scheduled or
unscheduled) has been issued.

Clients should have a security policy that determines, possibly based
on transaction value and possibly though not necessarily based on
nextUpdate, how long after "thisUpdate" a CRL can be used.  That policy
shouldn't have anything to do with the trustworthiness or reliability
of any LDAP servers.

Dave



Received: from scrooge.parallelconsulting.com ([212.209.152.4]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id HAA15645 for <[e-mail]>; Fri, 7 Jul 2000 07:46:48 -0700 (PDT)
Received: from karon ([10.1.2.1]) by scrooge.parallelconsulting.com (Netscape Messaging Server 3.6)  with SMTP id AAA2C71 for <[e-mail]>; Fri, 7 Jul 2000 16:48:15 +0200
Message-ID: <[e-mail]>
Date: Fri, 07 Jul 2000 15:47:57 +0200
From: "magnus andersson" <[e-mail]>
X-Mailer: Mozilla 4.72 [en] (Windows NT 5.0; U)
X-Accept-Language: en
MIME-Version: 1.0
To: [e-mail]
Subject: (no subject)
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

subscribe



Received: from po1.bbn.com (PO1.BBN.COM [192.1.50.38]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id HAA15022 for <[e-mail]>; Fri, 7 Jul 2000 07:27:00 -0700 (PDT)
Received: from [171.78.30.107] (fixed030-107.bbn.com [171.78.30.107] (may be forged)) by po1.bbn.com (8.9.1/8.9.1) with ESMTP id KAA24836; Fri, 7 Jul 2000 10:28:22 -0400 (EDT)
Mime-Version: 1.0
X-Sender: [e-mail]
Message-Id: <v04220803b58b9844ff5c@[171.78.30.107]>
In-Reply-To: <001501bfe822$8da276b0$[e-mail]>
References: <001501bfe822$8da276b0$[e-mail]>
Date: Fri, 7 Jul 2000 10:23:48 -0400
To: "Anders Rundgren" <[e-mail]>
From: Stephen Kent <[e-mail]>
Subject: Re: Cert compare. Was: I-D ACTION:draft-ietf-pkix-qc-04.txt
Cc: <[e-mail]>
Content-Type: text/plain; charset="us-ascii" ; format="flowed"

At 4:49 PM +0200 7/7/00, Anders Rundgren wrote:
>  >Comparing two qualified certificates to determine if they represent
>  >the same physical entity may provide misleading results and should be
>  >performed with care.
>
>Could we then have the Java code for performed with "care" :-)
>
>Sorry for wining but I [still] don't see the point of standards with such

The correct spelling here is whining.  Wining is what you have not 
done in this context.

Steve



Received: from mail-fwd.verio-web.com ([161.58.16.59]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id HAA14370 for <[e-mail]>; Fri, 7 Jul 2000 07:08:03 -0700 (PDT)
Received: from 161.58.117.181 (161.58.117.181) by mail11b.verio-web.com (RS ver 1.0.57s) with SMTP id 01530899; Fri,  7 Jul 2000 10:09:19 -0400 (EDT)
Sender: rsalz
Message-ID: <[e-mail]>
Date: Fri, 07 Jul 2000 10:09:42 -0400
From: Rich Salz <[e-mail]>
X-Mailer: Mozilla 4.72 [en] (X11; U; Linux 2.2.14-5.0 i686)
X-Accept-Language: en
MIME-Version: 1.0
To: [e-mail], [e-mail]
Subject: Re: Operational Protocols - LDAPv3
References: <396526ED.28085.6373C7@localhost>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
X-Loop-Detect: 1

> 
> 6. Security Considerations
> 
> The PKI information to be retrieved from LDAPv3 servers (certificates
> and CRLs) is digitally signed and therefore additional integrity
> services are NOT REQUIRED.

I think it's worth adding a warning that clients who retrieve CRLs
without some way of verifying the server run the risk of being sent
an obsolete CRL.
	/r$


Received: from d1o69.telia.com ([e-mail] [62.20.144.241]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id GAA13751 for <[e-mail]>; Fri, 7 Jul 2000 06:48:53 -0700 (PDT)
Received: from mega (t4o69p73.telia.com [62.20.145.193]) by d1o69.telia.com (8.8.8/8.8.8) with SMTP id PAA20653 for <[e-mail]>; Fri, 7 Jul 2000 15:50:19 +0200 (CEST)
Message-ID: <001501bfe822$8da276b0$[e-mail]>
From: "Anders Rundgren" <[e-mail]>
To: <[e-mail]>
Subject: Cert compare. Was: I-D ACTION:draft-ietf-pkix-qc-04.txt
Date: Fri, 7 Jul 2000 16:49:27 +0200
MIME-Version: 1.0
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 4.72.3110.5
Content-Type: text/plain; boundary="NextPart"; charset="iso-8859-1"
X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by ns.secondary.com id GAA13752

>Comparing two qualified certificates to determine if they represent
>the same physical entity may provide misleading results and should be
>performed with care.

Could we then have the Java code for performed with "care" :-)

Sorry for wining but I [still] don't see the point of standards with such statements.
If the algorithms and methods can't be determined it should be stated so.

I.e. outside of the scope of standard.  Then even a third-class programmer understands
that this is implementation-dependent which is what you are really trying to say.

I think this is more than playing with words as this feature *will* be supported by the majority of QCs.

Anders



Received: from mailcity.com (fes-qout.whowhere.com [209.1.236.7]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id FAA11421 for <[e-mail]>; Fri, 7 Jul 2000 05:30:45 -0700 (PDT)
Received: from Unknown/Local ([?.?.?.?]) by mailcity.com; Fri Jul  7 05:31:32 2000
To: [e-mail]
Date: Fri, 07 Jul 2000 05:31:32 -0700
From: "chandrasekaran natarajan" <[e-mail]>
Message-ID: <[e-mail]>
Mime-Version: 1.0
Cc: [e-mail]
X-Sent-Mail: off
Reply-To: [e-mail]
X-Mailer: MailCity Service
Subject: ASN.1 BitString 
X-Sender-Ip: 202.144.10.93
Organization: MailCity  (http://www.mailcity.lycos.com:80)
Content-Type: text/plain; charset=us-ascii
Content-Language: en
Content-Transfer-Encoding: 7bit

hello all,

I have a doubt on the following text extracted from X.208 Standard
 

5.3 Example of a production 

    BitStringValue ::= bstring | hstring | {IdentifierList} 
    is a production which associates with the name BitStringValue
    the following sequences: 
           a) any bstring (an item); and 
           b) any hstring (an item); and 
           c) any sequence associated with IdentifierList,
              preceded by a { and followed by a } 
         Note   { and } are the names of items containing the single characters {
         and } (see ' 8). 
     
     In this example, IdentifierList would be defined by a further production,
     either before or after production defining BitStringValue.
     
     
 ** Can some one help me on knowing what part c) refers to
 
 Thanks,
 chandar



Send FREE Greetings for Father's Day--or any day!
Click here: http://www.whowhere.lycos.com/redirects/fathers_day.rdct


Received: from ietf.org (odin.ietf.org [132.151.1.176]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id EAA08167 for <[e-mail]>; Fri, 7 Jul 2000 04:19:22 -0700 (PDT)
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA20875; Fri, 7 Jul 2000 07:20:51 -0400 (EDT)
Message-Id: <[e-mail]>
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
Cc: [e-mail]
From: [e-mail]
Reply-to: [e-mail]
Subject: I-D ACTION:draft-ietf-pkix-qc-04.txt
Date: Fri, 07 Jul 2000 07:20:51 -0400
Sender: [e-mail]

--NextPart

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Public-Key Infrastructure (X.509) Working Group of the IETF.

	Title		: Internet X.509 Public Key Infrastructure Qualified    
                          Certificates Profile
	Author(s)	: S. Santesson, T. Polk, P. Barzin, M. Nystrom
	Filename	: draft-ietf-pkix-qc-04.txt
	Pages		: 33
	Date		: 06-Jul-00
	
This document forms a certificate profile for Qualified Certificates,
based on RFC 2459, for use in the Internet. The term Qualified
Certificate is used to describe a certificate with a certain
qualified status within applicable governing law. Further, Qualified
Certificates are issued exclusively to physical persons.
The goal of this document is to define a general syntax independent
of local legal requirements. The profile is however designed to allow
further profiling in order to meet specific local needs.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-pkix-qc-04.txt

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-ietf-pkix-qc-04.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt


Internet-Drafts can also be obtained by e-mail.

Send a message to:
	[e-mail].
In the body type:
	"FILE /internet-drafts/draft-ietf-pkix-qc-04.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.
		
		
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"

--OtherAccess
Content-Type: Message/External-body;
	access-type="mail-server";
	server="[e-mail]"

Content-Type: text/plain
Content-ID:	<[e-mail]>

ENCODING mime
FILE /internet-drafts/draft-ietf-pkix-qc-04.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-pkix-qc-04.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID:	<[e-mail]>

--OtherAccess--

--NextPart--




Received: from relay3-gui.server.ntli.net (relay3-gui.server.ntli.net [194.168.4.200]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id QAA03216 for <[e-mail]>; Thu, 6 Jul 2000 16:39:38 -0700 (PDT)
Received: from m53-mp1-cvx1c.hud.ntl.com ([62.252.108.53] helo=dwc-acer) by relay3-gui.server.ntli.net with esmtp (Exim 3.03 #2) id 13AL7I-0004w4-00; Fri, 07 Jul 2000 00:31:36 +0100
From: "David Chadwick" <[e-mail]>
Organization: University of Salford
To: [e-mail]
Date: Fri, 7 Jul 2000 00:40:13 +0100
MIME-Version: 1.0
Content-type: Multipart/Mixed; boundary=Message-Boundary-21031
Subject: Operational Protocols - LDAPv3
Reply-to: [e-mail]
CC: [e-mail]
Message-ID: <396526ED.28085.6373C7@localhost>
Priority: normal
X-mailer: Pegasus Mail for Win32 (v3.12c)

--Message-Boundary-21031
Content-type: text/plain; charset=US-ASCII
Content-transfer-encoding: 7BIT
Content-description: Mail message body

Dear Editor

Could you please publish the attached update to the Internet Draft 
Internet X.509 Public Key Infrastructure Operational Protocols - 
LDAPv3 <draft-pkix-ldap-v3-02.txt>

thankyou

David


***************************************************

David Chadwick
IS Institute, University of Salford, Salford M5 4WT
Tel [phone]  Fax [phone]
Mobile [phone]
Email [e-mail]
Home Page  http://www.salford.ac.uk/its024/chadwick.htm
Understanding X.500  http://www.salford.ac.uk/its024/X500.htm
X.500/LDAP Seminars http://www.salford.ac.uk/its024/seminars.htm
Entrust key validation string MLJ9-DU5T-HV8J

***************************************************


--Message-Boundary-21031
Content-type: text/plain; charset=ISO-8859-1
Content-transfer-encoding: Quoted-printable
Content-description: Text from file 'LDAPv3PKIXProfile02.txt'

Internet-Draft                                       D.W.Chadwick
PKIX WG                       		   University of Salford      
Intended Category: Standards Track             
Expires: 6 January 2001                            6 July, 2000




                 Internet X.509 Public Key Infrastructure
                      Operational Protocols - LDAPv3
                       <draft-pkix-ldap-v3-02.txt>


STATUS OF THIS MEMO

This document is an Internet-Draft and is in full conformance with 
all the provisions of Section 10 of RFC2026.

Internet-Drafts are working documents of the Internet Engineering 
Task Force (IETF), its areas, and its working groups. Note that other
groups may also distribute working documents as Internet-Drafts.

Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference 
material or to cite them other than as "work in progress."

The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt.

The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.

This Internet-Draft expires on 6 January 2001. Comments and 
suggestions on this document are encouraged. Comments on this 
document should be sent to the PKIX working group discussion list:
                <[e-mail]>
or directly to the author.


ABSTRACT

This document describes the features of the Lightweight Directory 
Access Protocol v3 that are needed in order to support a public key 
infrastructure based on X.509 certificates and CRLs.


1. Introduction

RFC 2559 [1] specifies the subset of LDAPv2 [2] that is necessary to 
retrieve X.509 [9] certificates and CRLs from LDAP servers. However 
LDAPv2 has a number of deficiencies that may limit its usefulness in 
certain circumstances. The most notable of these are:

      - LDAPv2 distinguished names must be composed from the IA5 
character set and cannot contain accented or non-latin characters,

      - LDAPv2 only has a limited number of supported authentication 
schemes for binding to the server, in particular the use of hashed 
passwords or TLS [3] are not supported,

       - LDAPv2 only supports a single directory server. It is the 
responsibility of the user to pre-configure his client with the 
required set of LDAP servers, and to choose the correct one for each 
certificate and CRL retrieval.

It is for these reasons (and others not listed here) that the IETF 
have stopped the standardisation of the LDAPv2 protocol and have 
replaced it with the LDAPv3 protocol [4]. However the LDAPv3 protocol 
is much more complex than the LDAPv2 protocol and many of its 
features are not essential for simple PKIX use. This document 
describes the features of LDAPv3 that are essential, or not required, 
or are optional for servers to support a PKI based on X.509.

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",  
"SHOULD", "SHOULD NOT", "RECOMMENDED",  "MAY", and "OPTIONAL" in this 
document are to be interpreted as described in RFC 2119 [5].


2. Features Of Ldapv3 That MUST Be Supported

Attribute descriptions are a superset of attribute type definitions. 
They allow attribute subtyping to be specified in the LDAPv3 
protocol. The ;binary option is an exception to this. This option 
allows certificates and CRLs to be asked for and returned as binary 
values encoded using the Basic Encoding Rules [11]. The mechanism 
described in RFC2559 (PKIX LDAPv2) [1] is fully compliant with the 
;binary option of LDAPv3. The ;binary option of attribute 
descriptions MUST be supported by all implementations. When a client 
adds, deletes, retrieves or modifies attribute values that are 
defined in RFC 2256 [13] to be stored and requested in the binary 
form, the attribute type name MUST always be specified with the 
;binary attribute option. When the server returns such an attribute 
in a search result, the attribute type name MUST include the ;binary 
option.  Other attribute description options SHOULD NOT be generated 
by clients. Servers MAY choose to support them at their discretion.

Other parameters of the Search operation for "read" or "search" type 
queries will usually be set as specified in RFC 2559.

UTF8 encoding [12] allows the full ISO 10646 character set to be used 
in the creation of distinguished names. UTF8 encoding of 
distinguished names MUST be supported as specified in RFC2253 [6].

Multiple attribute value assertions (AVAs) within RDN components of 
distinguished names MUST be supported and the ordering of the AVAs is 
non-deterministic. For example cn=3DJohn + serialNumber=3D123 is the same 
as serialNumber=3D123 + cn=3DJohn.

LDAPv3 has the concept of unsolicited notifications that can be sent 
from the server to the client. This is used to indicate when the 
server is going down, so that a client can distinguish between a 
server failure and a network failure. A client MUST be prepared to 
accept unsolicited notifications defined in RFC 2251 [4].

The altServer attribute is used by servers to point to alternative 
servers that may be contacted if this server is temporarily 
unavailable. This attribute MUST be stored in the root DSE of the 
server and MUST be available to clients for retrieval. (The access 
controls on this attribute MUST be the same or less than those on 
certificates and revocation lists.) If no alternative servers exist 
this attribute MUST point to the current server. Clients MAY make use 
of this feature but do not need to. Servers MAY store any other 
operational attributes in the root DSE, but do not need to, except 
where mandated in this or other profiles.

If the Certification Practice Statement (CPS) allows unauthenticated 
anonymous access to the server, then the server MUST allow a client 
to perform a Search operation (for a "read" or "search" type request) 
without issuing a prior Bind operation. The server MUST also allow 
the client to present a Bind request with the simple authentication 
choice and a zero-length OCTET STRING.

If the CPS allows weak password based authentication for "read" or 
"search" access to the server, the client and the server MUST support 
the DIGEST-MD5 mechanism [7] as specified in [8] and [10].

3. Features Of Ldapv3 That SHOULD Be Supported

In a distributed directory with multiple servers, LDAPv3 supports 
referrals as the mechanism to allow one server that cannot fulfil a 
client=92s request, to refer the client to another server that might be 
better able to fulfil the request. Servers SHOULD be able to return 
referrals to clients. Clients SHOULD be able to receive referrals and 
process them, although they are not required to automatically process 
them and support multiple asynchronous outgoing connections. 

Partial Search results are returned when a server only has a subset 
of the certificates requested by the client. Referrals to other 
servers are embedded in the SearchResultReference field. Clients and 
servers SHOULD be able to handle SearchResultReferences in the same 
way as they handle referrals.

However, the returned referrals SHOULD NOT specify new search 
filters, attributes to be returned or user credentials. Servers 
SHOULD only return the hostport, and DN components and MAY return the 
scope component.


4. Features Of Ldapv3 that are Not Used by this Profile

A client following this profile need not send the ModifyDN, Compare 
and Abandon operations. The server MAY choose to support these 
operations at its discretion. (Note that a client wishing to 
abnormally terminate a search request may, instead of issuing an 
Abandon operation, close the TCP/IP connection.)

The LDAPv3 protocol is infinitely extensible via two mechanisms: 
extended operations and controls on existing operations. The client 
does not need to generate any LDAPv3 protocol extensions (extended 
operations or controls), unless flexible searching for certificates 
is supported (see below).  The server SHOULD NOT return any LDAPv3 
protocol extensions (extended operations or controls) apart from 
supported controls which were marked as critical by the user.


5. Features Of Ldapv3 That MAY Be Supported

The default behaviour for LDAPv2 and LDAPv3 servers is that a user 
must retrieve all the attribute values from an attribute, or none of 
them (subject of course to having access rights to the values). If 
the user of the LDAPv3 server wishes to retrieve a limited number of 
userCertificates from a user=92s entry, specifically those that match 
certain filtering criteria, then this MAY be achieved by using the 
LDAPv3 valuesReturnFilter control [15] along with the 
certificateExactMatch or certificateMatch matching rules [17].

If the CPS allows weak password based authentication for "read" or 
"search" access to the server, the client and the server MAY support 
a simple password Bind sequence following the negotiation of a TLS 
ciphersuite to provide connection confidentiality, as specified in 
[10].

If the CPS requires strong authentication for access to the server 
then the client and the server SHOULD support certificate based 
authentication as specified in [10].


6. Security Considerations

The PKI information to be retrieved from LDAPv3 servers (certificates 
and CRLs) is digitally signed and therefore additional integrity 
services are NOT REQUIRED. The CPS will specify whether the 
information should be publicly available or not. If publicly 
available, privacy services will NOT be REQUIRED for retrieval 
requests. If not publicly available, privacy services MAY be REQUIRED 
and these can be provided by a TLS ciphersuite as specified in clause 
5.

For update of the information by CAs either strong authentication or 
weaker password based authentication MUST be supported as specified 
in clause 5. Additional access controls SHOULD be provided.

Organizations are NOT REQUIRED to provide external CAs or users with 
access to their directories.


7. Copyright

Copyright (C) The Internet Society (date). All Rights Reserved.

This document and translations of it may be copied and furnished to 
others, and derivative works that comment on or otherwise explain it 
or assist in its implementation may be prepared, copied, published 
and distributed, in whole or in part, without restriction of any 
kind, provided that the above copyright notice and this paragraph are 
included on all such copies and derivative works.  However, this 
document itself may not be modified in any way, such as by removing 
the copyright notice or references to the Internet Society or other 
Internet organizations, except as needed for the purpose of 
developing Internet standards in which case the procedures for 
copyrights defined in the Internet Standards process must be 
followed, or as required to translate it into languages other than 
English.

The limited permissions granted above are perpetual and will not be 
revoked by the Internet Society or its successors or assigns.

This document and the information contained herein is provided on an 
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.


8. References

[1] S.Boeyen, T. Howes, P. Richard "Internet X.509 Public Key 
Infrastructure Operational Protocols - LDAPv2", RFC 2559, April 1999
[2] Yeong, W., Howes, T., and Kille, S. "Lightweight Directory Access 
Protocol", RFC 1777, March 1995.
[3] T. Dierks, C. Allen. "The TLS Protocol Version 1.0", RFC 2246, 
January 1999.
[4] M. Wahl, T. Howes, S. Kille, "Lightweight Directory Access  
Protocol (v3)", Dec. 1997, RFC 2251
[5] S.Bradner. "Key words for use in RFCs to Indicate Requirement 
Levels", RFC 2119, March 1997.
[6] M. Wahl, S. Kille, T. Howes. "Lightweight Directory Access 
Protocol (v3): UTF-8 String Representation of Distinguished Names", 
RFC2253, December 1997.
[7] R. Rivest, "The MD5 Message-Digest Algorithm", RFC 1321, April 
1992
[8] P. Leach, C. Newman, "Using Digest Authentication as a SASL 
Mechanism", RFC 2831, May 2000.
[9] ITU-T Rec. X.509(97) The  Directory:  Authentication
Framework
[10] M. Wahl, H. Alvestrand, J. Hodges, R. Morgan. "Authentication 
Methods for LDAP", RFC 2829, May 2000
[11] ITU-T Rec. X.690, "Specification of ASN.1 encoding rules: Basic, 
Canonical, and Distinguished Encoding Rules", 1994.
[12] F. Yergeau. "UTF-8, a transformation format of ISO 10646", RFC 
2279, January 1998.
[13] M.Wahl. "A Summary of the X.500(96) User Schema for use with 
LDAPv3" RFC 2256, Dec 1997
[14] M. Wahl, A. Coulbeck, T. Howes, S. Kille, "Lightweight Directory 
Access Protocol (v3): Attribute Syntax Definitions", RFC 2252, Dec 
1997
[15] D.Chadwick, "Returning Matched Values with LDAPv3", Internet 
Draft <draft-ldapext-matchedval-02.txt>, July 2000
[16] S.Boeyen, T. Howes, P. Richard "Internet X.509 Public Key 
Infrastructure, LDAPv2 Schema", RFC 2587, June 1999
[17] D.Chadwick, "Internet X.509 Public Key Infrastructure, 
Additional LDAP Schema for PKIs and PMIs", <draft-pkix-ldap-schema-
00.txt>, July 2000 


9. Authors Address

David Chadwick
IS Institute
University of Salford
Salford
England
M5 4WT 

Email: [e-mail]

10. Changes Made to Version 01

i) Schema removed to a separate document
ii) Selecting individual attribute values updated to reflect new 
LDAP Internet Draft
iii) Re-wording of text surrounding the use of ;binary option.

11. Outstanding Issues

i) Should we make the Abandon operation optional for the client and 
mandatory for the server. Comments on this issue are requested.



Internet-Draft   PKIX Operational Protocols =96 LDAPv3   6 July 2000


5


--Message-Boundary-21031--


Received: from mail.spyrus.com (mail.spyrus.com [207.212.34.20]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id NAA29269 for <[e-mail]>; Thu, 6 Jul 2000 13:08:44 -0700 (PDT)
Received: from rhousley_laptop ([209.172.119.209]) by mail.spyrus.com (8.9.3/8.9.3) with ESMTP id NAA23674; Thu, 6 Jul 2000 13:09:02 -0700 (PDT)
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58 
Date: Thu, 06 Jul 2000 15:45:41 -0400
To: [e-mail]
From: Russ Housley <[e-mail]>
Subject: Re: Comments: An Intranet Attribute Certificate Profile for Authorization
Cc: [e-mail]
In-Reply-To: <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed

Paul:

1.  I am not very happy with your proposal.  I would be willing to make the 
audit identifier an attribute, but I see no utility in the extension that 
you propose.

2.  I see no value in unsigned attribute certificates.  If you have a 
secure means of pulling attributes about a subject from a server, why use 
attribute certificates at all?

Russ


At 04:23 PM 07/05/2000 -0500, [e-mail] wrote:
>All,
>
>We have some comments below related to "An Intranet Attribute Certificate
>Profile for Authorization"  <draft-ietf-pkix-ac509prof-03.txt>.
>
>Paul.
>
>--------------------------------------------------------------------------- 
>--------------------------------------------------------------------------- 
>--------------
>
>
>We have two major issues and one minor issue.  First, the major issues:
>(1) The draft does not adequately support anonymous operations with audit id.
>
>      Section 4.3.1 requires the audit id to be a critical extension 
> rather than
>an attribute
>
>      Section 4.2.7 requires the AC to have at least one attribute
>
>      The combination of these two requirements implies that there MUST be an
>attribute other
>      than the audit id in an AC.  This makes fully anonymous (but auditable)
>operations very difficult.
>
>      Making audit IDs extensions rather than attributes complicates
>implementation unecessarily
>      in any case, as (at least from the point of view of encoding) they 
> must be
>handled differently than
>      other kinds of IDs (access ids, accounting ids, etc...).
>
>We propose the following fix to the problem.  The rationale behind making 
>audit
>IDs critical extensions is that
>issuers want to constrain implementations which accept their ACs with 
>audit IDs
>in them to treat audit ids properly -- that
>is, they want to constrain acceptors of their ACs to put only audit IDs into
>audit records.
>
>Proposal:
>
>The goal can be accomplished by defining the audit id as an attribute, and
>defining a separate a "UseAuditID" extension.
>If the "UseAuditID" extension is present, the accepting implementation must
>never put any attribute other than the
>audit ID into an audit event.
>
>Note that this mechanism also permits issuers to define audit IDs without 
>making
>their use mandatory, which
>we view as a  good thing.
>
>We propose that 4.4 be updated to define audit ID as an attribute, and that
>4.3.1 be updated to define the UseAuditID extension
>instead of the current Audit Identity extension.
>
>(2)  The draft does not support adequately performant pull-protocol
>implementations.
>
>      Section 3 defines support for pull-protocol use of ACs as a requirement
>
>      Section 4.2.4 requires that the AC signature MUST be 
> md5WithRSAEncryption,
>id-dsa-with-sha1,
>      sha-1WithRSAEncryption, or ecdsa-with-SHA1.
>
>      Section 5 requires that the signature must verify (path and crypto) 
> or else
>be rejected.
>
>The combination of these requirements implies that even in pull-protocol
>configurations in which the certificate acceptor
>pulls the AC from a trusted repository over a secure, authenticated link, the
>acceptor must do at least one public-key
>verify operation and a hash.  In high-volume cases, especially those employing
>very short-lived ACs, this will impose
>substantial and perhaps unacceptable overhead.
>
>We propose to add another algorithm to the set: NoHashWithNoEncryption.
>
>Specifically, we propose that the text of the last two paragraphs of 4.2.4 be
>changed to read:
>
>      This MUST be one of the following algorithms: NoHashWithNoEncryption,
>md5WithRSAEncryption,
>      id-dsa-with-sha1, sha-1WithRSAEncryption, or 
> ecdsa-with-SHA1.  [PKIXPROF]
>section 7.2 defines
>      md5WithRSAEncryption, id-dsa-with-sha1, and sha-1WithRSAEncryption.
>[ECDSA] section 3.2
>      defines ecdsa-with-SHA1.  NoHashWithNoEncryption indicates that no
>signature has been applied
>      to the attribute certificate; if this signature algorithm is 
> specified, the
>certificate passes the signature
>      validity check with no processing required.
>
>      id-dsa-with-sha1 MUST be supported by all AC 
> users.  md5WithRSAEncryption,
>sha-1WithRSAEncryption,
>      and ecdsa-with-SHA1 SHOULD be supported.  NoHashWithNoEncryption MAY be
>supported.
>
>Now the minor issue:
>
>(3) We may be confused here, but when section 4.2.7 requires that "AC 
>users MUST
>be able to handle multiple values
>for all attribute types" we see trouble.  Do we really want to REQUIRE support
>for multiple values of Access Identity and Charging Identity attributes?
>
>
>Paul Ashley, PhD
>Senior Security Architect
>Tivoli Security Business Unit
>
>Bridgepoint III
>6300 BridgePoint Parkway
>Office A5022
>Austin, Tx 78731
>
>email: [e-mail]
>phone: [phone]
>fax: [phone]
>cell: [phone]
>
>Tivoli - an IBM division
>



Received: from relay3-gui.server.ntli.net (relay3-gui.server.ntli.net [194.168.4.200]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id LAA27352 for <[e-mail]>; Thu, 6 Jul 2000 11:34:27 -0700 (PDT)
Received: from m718-mp1-cvx1c.hud.ntl.com ([62.252.110.206] helo=dwc-acer) by relay3-gui.server.ntli.net with esmtp (Exim 3.03 #2) id 13AGLy-0006fE-00; Thu, 06 Jul 2000 19:26:27 +0100
From: "David Chadwick" <[e-mail]>
Organization: University of Salford
To: Sean Turner <[e-mail]>, PKIX <[e-mail]>
Date: Thu, 6 Jul 2000 19:33:54 +0100
MIME-Version: 1.0
Content-type: text/plain; charset=US-ASCII
Content-transfer-encoding: 7BIT
Subject: Re: Comments on draft-ietf-pkix-ldap-v3-01.txt
Reply-to: [e-mail]
CC: [e-mail]
Message-ID: <3964DF22.9858.AF326B8@localhost>
Priority: normal
In-reply-to: <[e-mail]>
X-mailer: Pegasus Mail for Win32 (v3.12c)

Date sent:      	Sat, 30 Oct 1999 14:51:32 -0400
From:           	Sean Turner <[e-mail]>
Organization:   	IECA, Inc.
To:             	PKIX <[e-mail]>
Subject:        	Comments on draft-ietf-pkix-ldap-v3-01.txt

> 
> After thinking about the draft a bit I'd like to suggest a few
> modifications (mostly organizational).
> 
> The draft includes both the protocol and schema issues to deal with
> LDAPv3 servers.  I think we should split the two topics as the draft
> is called "operational protocols".  I think the draft should just talk
> about the protocol issues and not the schema. 

After some thought and discussion with other LDAP folk I agree 
with you. One of the reasons is that the LDAPExt group will be 
updating the base LDAPv3 docs in due course and the schema stuff 
should go in there. (But this will be over a longer time frame than is 
needed to publish the protocol part). I am currently doing the 
changes now in time for Pittsburg.

> My suggestion is to
> update RFC 2587 (Internet X.509 Public Key Infrastructure LDAPv2
> Schema) to include the attribute and object classes required to
> support attribute certificate users.  Then the LDAPv2 schema could
> support storing the attribute certificate related information. 
> Another draft should be spawned to include specific LDAPv3 schema
> issues such support for matching rules, etc.

I will talk to Sharon B about this, as to whether she wants to update 
the v2 schema doc or not, or put the whole lot in a new schema doc 
leaving the existing RFC as is. (After all, we are not aware of any 
defects in that doc, are we?). I would favour just one new schema 
doc, which preferrably should be published by the LDAPExt group 
as these are core schema requirments in my opinion. However, I 
will produce the first draft of this.


> 
> There is support for the pmiUser but where are the attribute
> authority's certificates stored?  Should we define an pmiAA (name to
> be determined) object class to support storing of the attribute
> certificate for the AA?

this is now in X509

> 
> Also, which revocation list includes the revoked attribute
> certificates?  I assumed it would be stored in a separate attribute
> certificate revocation list, but the draft is silent on the issue (so
> is draft-ietf-pkix-ac509prof-01.txt).

X.509 defines attributeCertificateRevocationList and 
attributeAuthorityRevocationList. I dont believe PKIX needs to do 
anything more.

David

> 
> Thanks,
> 
> spt
> 
> 
> 
> 


***************************************************

David Chadwick
IS Institute, University of Salford, Salford M5 4WT
Tel [phone]  Fax [phone]
Mobile [phone]
Email [e-mail]
Home Page  http://www.salford.ac.uk/its024/chadwick.htm
Understanding X.500  http://www.salford.ac.uk/its024/X500.htm
X.500/LDAP Seminars http://www.salford.ac.uk/its024/seminars.htm
Entrust key validation string MLJ9-DU5T-HV8J

***************************************************


Received: from mail.spyrus.com (mail.spyrus.com [207.212.34.20]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id JAA25020; Thu, 6 Jul 2000 09:52:55 -0700 (PDT)
Received: from rhousley_laptop ([209.172.119.209]) by mail.spyrus.com (8.9.3/8.9.3) with ESMTP id JAA20746; Thu, 6 Jul 2000 09:53:50 -0700 (PDT)
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58 
Date: Thu, 06 Jul 2000 11:00:58 -0400
To: Paul Hoffman / IMC <[e-mail]>
From: Russ Housley <[e-mail]>
Subject: Re: RFC 2459 and internationalized domain names
Cc: [e-mail]
In-Reply-To: <p0432040db58915f36417@[165.227.249.13]>
References: <[e-mail]> <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed

Paul:

I agree.  A forward pointer that this issue needs to be addresses once the 
IDN WG finishes their work is fine.

Russ


At 09:44 AM 07/05/2000 -0700, Paul Hoffman / IMC wrote:
>At 12:31 PM -0400 7/5/00, Russ Housley wrote:
>>I agree that certificates should accommodate non-ASCII domain names once 
>>they are finalized.  I do not understand why anything should be done 
>>before IDN finishes their work.
>
>Because someone will be reading the PKIX RFC at some point after IDN is 
>done. They may say "gee, this is stupid that they said to use IA5String 
>for domain name, I'll just use UTF8String". Putting in an acknowledgement 
>that the PKIX WG knows of some of the formats that we have locked down 
>possibly changing might help promote future interoperability.
>
>--Paul Hoffman, Director
>--Internet Mail Consortium



Received: from balinese.baltimore.ie ([e-mail] [194.125.215.8]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id EAA16101 for <[e-mail]>; Thu, 6 Jul 2000 04:09:14 -0700 (PDT)
Received: by balinese.baltimore.ie; id MAA11219; Thu, 6 Jul 2000 12:10:34 +0100 (GMT/IST)
Received: from bobcat.baltimore.ie(192.168.20.10) by balinese.baltimore.ie via smap (V4.2) id xma010954; Thu, 6 Jul 00 12:09:50 +0100
Received: from baltimore.ie (lease212-21.baltimore.ie [192.168.21.212]) by bobcat.baltimore.ie (8.9.3/8.9.3) with ESMTP id MAA06072; Thu, 6 Jul 2000 12:09:49 +0100
Message-ID: <[e-mail]>
Date: Thu, 06 Jul 2000 12:09:52 +0100
From: Stephen Farrell <[e-mail]>
Reply-To: [e-mail]
Organization: Baltimore Technologies Ltd.
X-Mailer: Mozilla 4.72 [en] (WinNT; U)
X-Accept-Language: en
MIME-Version: 1.0
To: [e-mail]
CC: [e-mail], xme <[e-mail]>
Subject: Re: Comments: An Intranet Attribute Certificate Profile forAuthorization
References: <[e-mail]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Hi Paul,

I'm afraid I don't really agree with your proposals.

I don't see much difference between the audit id as is, and
your proposal, and I'm not sure I like an AC with an audit-id
attribute and no critical extensions being conformant. I'll 
think about it though - if lots of folks agreed, I'd be willing 
to take it (so far, you're the second, Bob Blakely was the 
first:-).

I really don't like your no-hash-no-sig suggestion and I don't
think it fits in this spec anyway. nHnS could only be used 
where there was also an interoperable secure AC transport
scheme defined (or else you're back in proprietary land), 
which is definitely out of scope for the profile. There'd 
also be some process issues - it is the PKIX WG after all, 
and folks have been beaten up for suggesting dummy algorithms
in the past. I'd suggest you write an I-D, based on the profile, 
defining the secure transport and adding nHnS as an 
algorithm (BTW: where's that defined?) 

For issue 3, yes we meant that everyone has to be able to
parse multivalued. I don't think we should get any more
restrictive in the profile.

Stephen.

-- 
____________________________________________________________
Stephen Farrell         				   
Baltimore Technologies,   tel: (direct line) [phone]
61 Fitzwilliam Lane,                    fax: [phone]
Dublin 2.                mailto:[e-mail]
Ireland                             http://www.baltimore.com


Received: from gandalf.trustpoint.com (gandalf.trustpoint.com [157.22.240.75]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id BAA08167 for <[e-mail]>; Thu, 6 Jul 2000 01:28:35 -0700 (PDT)
Received: from ronald.certicom.com (ronald [10.1.6.23]) by gandalf.trustpoint.com (8.8.7/8.8.7) with ESMTP id BAA02296; Thu, 6 Jul 2000 01:29:51 -0700
Received: (from ronald@localhost) by ronald.certicom.com (8.8.7/8.8.7) id BAA27105; Thu, 6 Jul 2000 01:29:57 -0700
Date: Thu, 6 Jul 2000 01:29:57 -0700
From: "Life is hard, and then you die" <[e-mail]>
To: =?iso-8859-1?Q?Martin_Lindstr=F6m?= <[e-mail]>
Cc: [e-mail], [e-mail]
Subject: Re: [ca-talk] CMP transport protocol - who should close the connection?
Message-ID: <[e-mail]>
Mail-Followup-To: =?iso-8859-1?Q?Martin_Lindstr=F6m?= <[e-mail]>, [e-mail], [e-mail]
References: <[e-mail]> <000d01bfe720$72d9f680$[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 8bit
X-Mailer: Mutt 1.0.1i
In-Reply-To: <000d01bfe720$72d9f680$[e-mail]>; from [e-mail] on Thu, Jul 06, 2000 at 10:01:52AM +0200

On Thu, Jul 06, 2000 at 10:01:52AM +0200, Martin Lindström wrote:
> 
[snip]
> >The client has two possibilities: it can either do a shutdown on
> >the client->server direction immediately, or then it has to wait
> >for the response from the server.
> >
> Martin> But this doesn't solve the question. If the client does a
> Martin> shutdown he will not receive the CA pkiConf (if any),

Of course he will - by shutdown I mean the standard shutdown()
socket call where you only close the client->server direction -
the server->client direction still stays open. This is *not* a
close(), which closes both directions.

> Martin> and if the client decides to wait for a response that never
> Martin> comes, he'll hang unless the server closes the connection.

See below.

> >That case never occurs. The protocol is a request/response protocol
> >and there is *always* a response.
> 
> Martin> Well, the case occurs during the PKIForum CMP testing anyway :-)

Not unless somebody had a bug...

> Martin> So what is the response to a certConf? RFC2510bis states that
> Martin> a confirmation ack is optional.
> Martin> Or, should the response from the server be a 'finRep' TCP
> Martin> message in cases where no CMP response is to be sent?

Exactly. I.e. there is always a response at the TCP level (and as
soon as certConf goes away then that is also true at the CMP level).

> Martin> In that case the transport draft need to be more clear.

Ok, will add some text.


  Cheers,

  Ronald



Received: from exchsvr1.entegrity.com (exchsvr1.entegrity.com [207.215.19.3]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id BAA07235 for <[e-mail]>; Thu, 6 Jul 2000 01:01:01 -0700 (PDT)
Received: from roger (dave.cost.se [195.100.88.62]) by exchsvr1.entegrity.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21) id 3KYLZMDD; Thu, 6 Jul 2000 01:09:25 -0700
From: "Martin Lindström" <[e-mail]>
To: <[e-mail]>
Cc: <[e-mail]>
Subject: RE: [ca-talk] CMP transport protocol - who should close the connection?
Date: Thu, 6 Jul 2000 10:01:52 +0200
Message-ID: <000d01bfe720$72d9f680$[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 8bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300
In-Reply-To: <[e-mail]>

Ronald,

See my comments inline.

>>
>> Regarding draft-ietf-pkix-cmp-transport-protocols-00.txt:
>[snip]
>> Suppose that a CR/CP is sent in one connection and when the
>> client is about to send its certConf it connects to the server
>> and sends the TCP message with the close bit set.
>> Should the client wait for the server to close the connection
>> or should it do it itself?
>> IMO the client cannot really do it itself since it must be prepared
>> to receive a pkiconf message from the CA (e.g. that the cert hash
>> comparison failed), and if the server does not close the
>> connection the client will either hang or timeout.
>
>The client has two possibilities: it can either do a shutdown on
>the client->server direction immediately, or then it has to wait
>for the response from the server.
>
Martin> But this doesn't solve the question. If the client does a
Martin> shutdown he will not receive the CA pkiConf (if any),
Martin> and if the client decides to wait for a response that never
Martin> comes, he'll hang unless the server closes the connection.

>As an aside, and a purely implementation problem, quite a few
>systems don't properly support shutdown(). Hence it is usally
>safer for the client to wait for the server response and then
>doing a close().
>
>> So what I want is that section 2.3 is extended with:
>> "If the connection close bit is set on a request, then the server
>>  MUST set the bit in the response and close the connection after
>>  sending the response. <add - begin> In the case the server does
>>  not intend to send any response to the client request, the server
>>  should close the connection directly. <add - end>"
>
>That case never occurs. The protocol is a request/response protocol
>and there is *always* a response.

Martin> Well, the case occurs during the PKIForum CMP testing anyway :-)
Martin> So what is the response to a certConf? RFC2510bis states that
Martin> a confirmation ack is optional.
Martin> Or, should the response from the server be a 'finRep' TCP
Martin> message in cases where no CMP response is to be sent?
Martin> In that case the transport draft need to be more clear.

/Martin

********* Entegrity Solutions *********
 Martin Lindström, Systems Designer
 Finlandsgatan 60
 S-166 74 Kista, Sweden
 Direct: [phone]
 Fax:    [phone]
 Cell:   [phone]
***************************************



Received: from levitator.1div0.com ([213.250.43.61]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id PAA02313 for <[e-mail]>; Wed, 5 Jul 2000 15:46:04 -0700 (PDT)
Received: from intergalactic ([10.1.1.2]) by levitator.1div0.com (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with SMTP id AAA04982; Thu, 6 Jul 2000 00:34:01 +0200
Reply-To: <[e-mail]>
From: <[e-mail]>
Sender: "denis bider" <[e-mail]>
To: "'Pedrabissi  Raffaele'" <[e-mail]>, <[e-mail]>
Subject: RE: Certificate creation and usage
Date: Thu, 6 Jul 2000 00:47:46 +0200
Message-ID: <000601bfe6d3$0a8130f0$0201010a@intergalactic>
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2910.0)
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700
Importance: Normal
In-Reply-To: <[e-mail]>

Hello Pedrabissi,

there is a C++ library called Certify which is intended for exactly this
kind of job. It currently includes support for RFC2459 certificates, RFC2511
certificate requests and PKCS#11 crypto tokens.

The address is: http://www.globera.com/certify.php3

The library is free for non-commercial use.

Regards,

denis


-----Original Message-----
From: Pedrabissi Raffaele [mailto:[e-mail]]
Sent: 5. julij 2000 09:44
To: [e-mail]
Subject:


Good morning, I`m Raffaele Pedrabissi, a student of Politecnico of Milano
(ITALY-EUROPE) and I`m doing a stage in Alcatel of Vimercate (Milano-ITALY).
I write You because I had read the RFC 2459 for the electronic certicates.
Now I have a little problem: I`m searching a program in C language that
creates an electronic certificate and one that notices the same certificate.
Thank You for Your time.
Pedrabissi Raffaele.


______________________________________________
FREE Personalized Email at Mail.com
Sign up at http://www.mail.com/?sr=signup




Received: from corp.tivoli.com (corp.tivoli.com [216.140.178.60]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id OAA19580 for <[e-mail]>; Wed, 5 Jul 2000 14:23:46 -0700 (PDT)
From: [e-mail]
Received: from tivmta4.tivoli.com (tivmta4.tivoli.com [146.84.104.47]) by corp.tivoli.com (8.9.3/8.9.0) with SMTP id QAA12624 for <[e-mail]>; Wed, 5 Jul 2000 16:25:05 -0500 (CDT)
Received: by tivmta4.tivoli.com(Lotus SMTP MTA v4.6.5  (863.2 5-20-1999))  id 86256913.0075C8AC ; Wed, 5 Jul 2000 16:26:30 -0500
X-Lotus-FromDomain: TIVOLI SYSTEMS
To: [e-mail]
Message-ID: <[e-mail]>
Date: Wed, 5 Jul 2000 16:23:00 -0500
Subject: Comments: An Intranet Attribute Certificate Profile for Authorization
Mime-Version: 1.0
Content-type: text/plain; charset=us-ascii
Content-Disposition: inline

All,

We have some comments below related to "An Intranet Attribute Certificate
Profile for Authorization"  <draft-ietf-pkix-ac509prof-03.txt>.

Paul.

--------------------------------------------------------------------------------------------------------------------------------------------------------------------


We have two major issues and one minor issue.  First, the major issues:
(1) The draft does not adequately support anonymous operations with audit id.

     Section 4.3.1 requires the audit id to be a critical extension rather than
an attribute

     Section 4.2.7 requires the AC to have at least one attribute

     The combination of these two requirements implies that there MUST be an
attribute other
     than the audit id in an AC.  This makes fully anonymous (but auditable)
operations very difficult.

     Making audit IDs extensions rather than attributes complicates
implementation unecessarily
     in any case, as (at least from the point of view of encoding) they must be
handled differently than
     other kinds of IDs (access ids, accounting ids, etc...).

We propose the following fix to the problem.  The rationale behind making audit
IDs critical extensions is that
issuers want to constrain implementations which accept their ACs with audit IDs
in them to treat audit ids properly -- that
is, they want to constrain acceptors of their ACs to put only audit IDs into
audit records.

Proposal:

The goal can be accomplished by defining the audit id as an attribute, and
defining a separate a "UseAuditID" extension.
If the "UseAuditID" extension is present, the accepting implementation must
never put any attribute other than the
audit ID into an audit event.

Note that this mechanism also permits issuers to define audit IDs without making
their use mandatory, which
we view as a  good thing.

We propose that 4.4 be updated to define audit ID as an attribute, and that
4.3.1 be updated to define the UseAuditID extension
instead of the current Audit Identity extension.

(2)  The draft does not support adequately performant pull-protocol
implementations.

     Section 3 defines support for pull-protocol use of ACs as a requirement

     Section 4.2.4 requires that the AC signature MUST be md5WithRSAEncryption,
id-dsa-with-sha1,
     sha-1WithRSAEncryption, or ecdsa-with-SHA1.

     Section 5 requires that the signature must verify (path and crypto) or else
be rejected.

The combination of these requirements implies that even in pull-protocol
configurations in which the certificate acceptor
pulls the AC from a trusted repository over a secure, authenticated link, the
acceptor must do at least one public-key
verify operation and a hash.  In high-volume cases, especially those employing
very short-lived ACs, this will impose
substantial and perhaps unacceptable overhead.

We propose to add another algorithm to the set: NoHashWithNoEncryption.

Specifically, we propose that the text of the last two paragraphs of 4.2.4 be
changed to read:

     This MUST be one of the following algorithms: NoHashWithNoEncryption,
md5WithRSAEncryption,
     id-dsa-with-sha1, sha-1WithRSAEncryption, or ecdsa-with-SHA1.  [PKIXPROF]
section 7.2 defines
     md5WithRSAEncryption, id-dsa-with-sha1, and sha-1WithRSAEncryption.
[ECDSA] section 3.2
     defines ecdsa-with-SHA1.  NoHashWithNoEncryption indicates that no
signature has been applied
     to the attribute certificate; if this signature algorithm is specified, the
certificate passes the signature
     validity check with no processing required.

     id-dsa-with-sha1 MUST be supported by all AC users.  md5WithRSAEncryption,
sha-1WithRSAEncryption,
     and ecdsa-with-SHA1 SHOULD be supported.  NoHashWithNoEncryption MAY be
supported.

Now the minor issue:

(3) We may be confused here, but when section 4.2.7 requires that "AC users MUST
be able to handle multiple values
for all attribute types" we see trouble.  Do we really want to REQUIRE support
for multiple values of Access Identity and Charging Identity attributes?


Paul Ashley, PhD
Senior Security Architect
Tivoli Security Business Unit

Bridgepoint III
6300 BridgePoint Parkway
Office A5022
Austin, Tx 78731

email: [e-mail]
phone: [phone]
fax: [phone]
cell: [phone]

Tivoli - an IBM division





Received: from freeby.ben.algroup.co.uk (sockittome.aldigital.co.uk [194.128.162.252]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id NAA11464 for <[e-mail]>; Wed, 5 Jul 2000 13:26:35 -0700 (PDT)
Received: from algroup.co.uk (naughty.ben.algroup.co.uk [193.133.15.107]) by freeby.ben.algroup.co.uk (8.6.12/8.6.12) with ESMTP id VAA20261; Wed, 5 Jul 2000 21:35:32 +0100
Message-ID: <[e-mail]>
Date: Wed, 05 Jul 2000 21:28:52 +0100
From: Ben Laurie <[e-mail]>
Organization: A.L. Group plc
X-Mailer: Mozilla 4.7 [en] (WinNT; I)
MIME-Version: 1.0
To: Pedrabissi Raffaele <[e-mail]>
CC: [e-mail]
Subject: Re: 
References: <[e-mail]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Pedrabissi Raffaele wrote:
> 
> Good morning, I`m Raffaele Pedrabissi, a student of Politecnico of Milano
> (ITALY-EUROPE) and I`m doing a stage in Alcatel of Vimercate (Milano-ITALY).
> I write You because I had read the RFC 2459 for the electronic certicates.
> Now I have a little problem: I`m searching a program in C language that
> creates an electronic certificate and one that notices the same certificate.
> Thank You for Your time.

http://www.openssl.org/

Cheers,

Ben.

--
http://www.apache-ssl.org/ben.html

Coming to ApacheCon Europe 2000? http://apachecon.com/


Received: from e1.ny.us.ibm.com (e1.ny.us.ibm.com [32.97.182.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id KAA21128 for <[e-mail]>; Wed, 5 Jul 2000 10:13:51 -0700 (PDT)
From: [e-mail]
Received: from northrelay02.pok.ibm.com (northrelay02.pok.ibm.com [9.117.200.22]) by e1.ny.us.ibm.com (8.9.3/8.9.3) with ESMTP id NAA354494; Wed, 5 Jul 2000 13:13:08 -0400
Received: from D51MTA04.pok.ibm.com (d51mta04.pok.ibm.com [9.117.200.32]) by northrelay02.pok.ibm.com (8.8.8m3/NCO v4.9) with SMTP id NAA80822; Wed, 5 Jul 2000 13:15:02 -0400
Received: by D51MTA04.pok.ibm.com(Lotus SMTP MTA v4.6.5  (863.2 5-20-1999))  id 85256913.005EBD3C ; Wed, 5 Jul 2000 13:14:48 -0400
X-Lotus-FromDomain: IBMUS
To: Jean-Marc Desperrier <[e-mail]>
cc: [e-mail], [e-mail], [e-mail]
Message-ID: <[e-mail]>
Date: Wed, 5 Jul 2000 13:14:41 -0400
Subject: Re: RFC 2459 and internationalized domain names
Mime-Version: 1.0
Content-type: text/plain; charset=us-ascii
Content-Disposition: inline

     This question may be premature, but we will need to ask it sometime -
if the Internet definitions of the three IA5String's in GeneralName get
extended for internationalization, should we: 1) Add OTHER-NAME's for the
internationalized string types, 2) Add extra CHOICE values to GeneralName;
3) Change the IMPLICIT type of each of these three strings to UTF8String on
the grounds that every legal IA5String is also a legal UTF8String with the
same meaning, although not vice versa?
     If we pick option 2 or option 3, will every certificate and CRL
extension currently including GeneralName get assigned a new OID for use
with the new GeneralName definition?  The answers to these questions are as
much under the control of X.509 as of PKIX.

          Tom Gindin


Jean-Marc Desperrier <[e-mail]> on 07/05/2000
12:17:49 PM

To:   [e-mail]
cc:
Subject:  Re: RFC 2459 and internationalized domain names



[e-mail] wrote:

> The format of GeneralName is :
> GeneralName ::= CHOICE {
>         otherName                   [0] INSTANCE OF OTHER-NAME,
>         rfc822Name                  [1] IA5String,
>         dNSName                     [2] IA5String,

> ...

>         uniformResourceIdentifier   [6] IA5String,
>
> It seems
> we need to create something like :
>         rfcSonOf822Name                  [9] UTF8strings,
>
> [Tom Gindin] I think it's rfc822I18N [9] UTF8String, but that's minor.

> The same applies to dNSName, and uniformResourceIdentifier.
>
> [Tom Gindin] I have one basic question here.  Does adding new members to
> this choice mean we have to change OID's for the extensions using it (not
> just SubjectAltName, but IssuerAltName, AuthorityKeyIdentifier,
> NameConstraints, CRLDistributionPoint, CertificateIssuer,
> IssuingDistributionPoint and AuthorityInfoAccess in RFC 2459 alone - and
I
> might have missed one)?  If it does, should we and X.509 bite that
> particular bullet or define OTHER-NAME's as DirectoryString's instead?

OK, OTHER-NAME is the way to go.

It is clearly a lot better to define a specific OID for rfc822I18N and then
insert that kind of thing as an otherName element, and *not* to change the
syntax of GeneralName.

      OtherName ::= SEQUENCE {
           type-id    OBJECT IDENTIFIER,
           value      [0] EXPLICIT ANY DEFINED BY type-id }

[Tom Gindin] Two points.  First, I was really asking our X.509 committee
types (Sharon, Hoyt, are you listening?) whether adding a new choice in
GeneralName would cause both X.509 and PKIX-1 to have to renumber all of
the extensions cited; if not, it's not clear to me that adding OTHER-NAME
is really better.  Second, what I meant by "OTHER-NAME's as
DirectoryString's" was OTHER-NAME's with values which are DirectoryString's
- there's no need for a new string type here.

(snip)




Received: from mail.ec.auckland.ac.nz (mail.student.auckland.ac.nz [130.216.35.201]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id KAA20426; Wed, 5 Jul 2000 10:02:56 -0700 (PDT)
Received: from kahu.cs.auckland.ac.nz ([e-mail] [130.216.36.13]) by mail.ec.auckland.ac.nz (8.9.3/8.8.6/cs-master) with SMTP id FAA17549; Thu, 6 Jul 2000 05:04:10 +1200 (NZST) (sender [e-mail])
Received: by kahu.cs.auckland.ac.nz (relaymail v0.9) id <96281665018859>; Thu, 6 Jul 2000 05:04:10 (NZST)
From: [e-mail] (Peter Gutmann)
To: [e-mail]
Subject: Re: RFC 2459 and internationalized domain names
Cc: [e-mail]
Sender: [e-mail]
Reply-To: [e-mail]
X-Charge-To: pgut001
X-Authenticated: relaymail v0.9 on kahu.cs.auckland.ac.nz
Date: Thu, 6 Jul 2000 05:04:10 (NZST)
Message-ID: <[e-mail]>

Paul Hoffman / IMC <[e-mail]> writes:
>At 12:31 PM -0400 7/5/00, Russ Housley wrote:
>>I agree that certificates should accommodate non-ASCII domain names
>>once they are finalized.  I do not understand why anything should be
>>done before IDN finishes their work.

>Because someone will be reading the PKIX RFC at some point after IDN is done.
>They may say "gee, this is stupid that they said to use IA5String for domain
>name, I'll just use UTF8String". Putting in an acknowledgement that the PKIX WG
>knows of some of the formats that we have locked down possibly changing might
>help promote future interoperability.

You could also do what a certain Spanish CA did and unilaterally extend the
string type which is causing problems to AnythingIWantString (so you can put
cedillas in a string-formerly-known-as-PrintableString for example).

Peter :-).



Received: from gandalf.trustpoint.com (gandalf.trustpoint.com [157.22.240.75]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id JAA20063 for <[e-mail]>; Wed, 5 Jul 2000 09:59:29 -0700 (PDT)
Received: from ronald.certicom.com (ronald [10.1.6.23]) by gandalf.trustpoint.com (8.8.7/8.8.7) with ESMTP id KAA01789; Wed, 5 Jul 2000 10:00:38 -0700
Received: (from ronald@localhost) by ronald.certicom.com (8.8.7/8.8.7) id KAA25606; Wed, 5 Jul 2000 10:00:44 -0700
Date: Wed, 5 Jul 2000 10:00:44 -0700
From: "Life is hard, and then you die" <[e-mail]>
To: =?iso-8859-1?Q?Martin_Lindstr=F6m?= <[e-mail]>
Cc: [e-mail], [e-mail]
Subject: Re: [ca-talk] CMP transport protocol - who should close the connection?
Message-ID: <[e-mail]>
Mail-Followup-To: =?iso-8859-1?Q?Martin_Lindstr=F6m?= <[e-mail]>, [e-mail], [e-mail]
References: <000301bfe684$504453f0$[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 8bit
X-Mailer: Mutt 1.0.1i
In-Reply-To: <000301bfe684$504453f0$[e-mail]>; from [e-mail] on Wed, Jul 05, 2000 at 03:24:13PM +0200

On Wed, Jul 05, 2000 at 03:24:13PM +0200, Martin Lindström wrote:
> 
> Regarding draft-ietf-pkix-cmp-transport-protocols-00.txt:
[snip]
> Suppose that a CR/CP is sent in one connection and when the
> client is about to send its certConf it connects to the server
> and sends the TCP message with the close bit set.
> Should the client wait for the server to close the connection
> or should it do it itself?
> IMO the client cannot really do it itself since it must be prepared
> to receive a pkiconf message from the CA (e.g. that the cert hash
> comparison failed), and if the server does not close the
> connection the client will either hang or timeout.

The client has two possibilities: it can either do a shutdown on
the client->server direction immediately, or then it has to wait
for the response from the server.

As an aside, and a purely implementation problem, quite a few
systems don't properly support shutdown(). Hence it is usally
safer for the client to wait for the server response and then
doing a close().

> So what I want is that section 2.3 is extended with:
> "If the connection close bit is set on a request, then the server
>  MUST set the bit in the response and close the connection after
>  sending the response. <add - begin> In the case the server does
>  not intend to send any response to the client request, the server
>  should close the connection directly. <add - end>"

That case never occurs. The protocol is a request/response protocol
and there is *always* a response.


  Cheers,

  Ronald



Received: from [165.227.249.13] (ip13.proper.com [165.227.249.13]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id JAA19173; Wed, 5 Jul 2000 09:42:52 -0700 (PDT)
Mime-Version: 1.0
X-Sender: [e-mail]
Message-Id: <p0432040db58915f36417@[165.227.249.13]>
In-Reply-To: <[e-mail]>
References: <[e-mail]>
Date: Wed, 5 Jul 2000 09:44:13 -0700
To: Russ Housley <[e-mail]>
From: Paul Hoffman / IMC <[e-mail]>
Subject: Re: RFC 2459 and internationalized domain names
Cc: [e-mail]
Content-Type: text/plain; charset="us-ascii" ; format="flowed"

At 12:31 PM -0400 7/5/00, Russ Housley wrote:
>I agree that certificates should accommodate non-ASCII domain names 
>once they are finalized.  I do not understand why anything should be 
>done before IDN finishes their work.

Because someone will be reading the PKIX RFC at some point after IDN 
is done. They may say "gee, this is stupid that they said to use 
IA5String for domain name, I'll just use UTF8String". Putting in an 
acknowledgement that the PKIX WG knows of some of the formats that we 
have locked down possibly changing might help promote future 
interoperability.

--Paul Hoffman, Director
--Internet Mail Consortium


Received: from mail.spyrus.com (mail.spyrus.com [207.212.34.20]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id JAA18490; Wed, 5 Jul 2000 09:32:11 -0700 (PDT)
Received: from rhousley_laptop.spyrus.com ([209.172.119.209]) by mail.spyrus.com (8.9.3/8.9.3) with ESMTP id JAA06343; Wed, 5 Jul 2000 09:32:59 -0700 (PDT)
Message-Id: <[e-mail]>
X-Sender: [e-mail] (Unverified)
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58 
Date: Wed, 05 Jul 2000 12:31:35 -0400
To: Paul Hoffman / IMC <[e-mail]>
From: Russ Housley <[e-mail]>
Subject: Re: RFC 2459 and internationalized domain names
Cc: [e-mail]
In-Reply-To: <p0432040eb586e5039935@[165.227.249.13]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed

Paul:

I agree that certificates should accommodate non-ASCII domain names once 
they are finalized.  I do not understand why anything should be done before 
IDN finishes their work.

Russ


At 07:10 PM 07/03/2000 -0700, Paul Hoffman / IMC wrote:
>Greetings again. There is active work in the IETF to allow non-ASCII 
>characters in doamin names. This is being considered in the IDN Working 
>Group (see <http://www.ietf.org/html.charters/idn-charter.html> for the WG 
>charter). There is a strong desire for these names in many parts of the world.
>
>If the wire format for the new domain names includes non-ASCII characters 
>(which seems likely to me), then we probably should change 2459 to handle 
>these new names. Fortunately, son-of-2459 is still not finished.
>
>Please note that:
>- The IDN WG may not come up with a protocol
>- The protocol may be ASCII-only, using an encoding scheme that maps to 
>the current rules for domain names
>- If there is a binary protocol, it is likely (but not definitely) going 
>to be UTF-8
>
>Given that, it might be wise of us to either change how domain names are 
>represented 2459 or to put warnings into the text about this  in 
>son-of-2459. It is likely that son-of-2459 will be finished well before 
>the IDN WG is finished.
>
>Oh, and if the IDN WG creates a binary protocol, there will be a strong 
>demand for changes to the email protocols to handle binary domain names in 
>headers. There will also be a strong demand for binary on the left-hand 
>side of the addr-spec. We may wan to consider these as well.
>
>Thoughts?
>
>--Paul Hoffman, Director
>--Internet Mail Consortium



Received: from certplus.com ([195.101.88.81]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id JAA17674 for <[e-mail]>; Wed, 5 Jul 2000 09:17:38 -0700 (PDT)
Received: from certplus.com (nt4_jmd.certplus.com [192.168.1.17]) by certplus.com (8.8.7/8.8.7) with ESMTP id QAA29780 for <[e-mail]>; Wed, 5 Jul 2000 16:48:17 +0200
Message-ID: <[e-mail]>
Date: Wed, 05 Jul 2000 18:17:49 +0200
From: Jean-Marc Desperrier <[e-mail]>
Organization: Certplus
X-Mailer: Mozilla 4.72 [en] (WinNT; I)
X-Accept-Language: en
MIME-Version: 1.0
To: [e-mail]
Subject: Re: RFC 2459 and internationalized domain names
References: <[e-mail]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

[e-mail] wrote:

> The format of GeneralName is :
> GeneralName ::= CHOICE {
>         otherName                   [0] INSTANCE OF OTHER-NAME,
>         rfc822Name                  [1] IA5String,
>         dNSName                     [2] IA5String,

> ...

>         uniformResourceIdentifier   [6] IA5String,
>
> It seems
> we need to create something like :
>         rfcSonOf822Name                  [9] UTF8strings,
>
> [Tom Gindin] I think it's rfc822I18N [9] UTF8String, but that's minor.

> The same applies to dNSName, and uniformResourceIdentifier.
>
> [Tom Gindin] I have one basic question here.  Does adding new members to
> this choice mean we have to change OID's for the extensions using it (not
> just SubjectAltName, but IssuerAltName, AuthorityKeyIdentifier,
> NameConstraints, CRLDistributionPoint, CertificateIssuer,
> IssuingDistributionPoint and AuthorityInfoAccess in RFC 2459 alone - and I
> might have missed one)?  If it does, should we and X.509 bite that
> particular bullet or define OTHER-NAME's as DirectoryString's instead?

OK, OTHER-NAME is the way to go.

It is clearly a lot better to define a specific OID for rfc822I18N and then
insert that kind of thing as an otherName element, and *not* to change the
syntax of GeneralName.

      OtherName ::= SEQUENCE {
           type-id    OBJECT IDENTIFIER,
           value      [0] EXPLICIT ANY DEFINED BY type-id }

The only thing that is needed is to define that "value" is of type UTF8String
or InternetDirectoryString when "type-id" is rfc822I18N,

OtherName might be anything, it's defined by the OID used.

Also a dNSNameI18N, and uniformResourceIdentifierI18N OID would be needed.

> It seems to me using a CHOICE format similar to DirectoryString for
> rfc822Name,
> dNSName, uniformResourceIdentifier, and a recommendation to use IA5String
> in the
> current state of things would have been a better solution.
>
> [Tom Gindin] It might well have been better (using AugmentedDirectoryString
> as a CHOICE between DirectoryString and IA5String, or
> InternetDirectoryString as a CHOICE between IA5String and the three Unicode
> string types), but it's probably too late.

It's too late, but I think the moral is that the standard should always leave
some room for the type of strings elements to evolve in the future.



Received: from firewall1.glaxowellcome.com ([e-mail] [192.58.204.204]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id IAA14887 for <[e-mail]>; Wed, 5 Jul 2000 08:34:06 -0700 (PDT)
Received: by firewall1.glaxowellcome.com; id LAA05040; Wed, 5 Jul 2000 11:35:44 -0400 (EDT)
Received: from ussun2m.glaxo.com(152.51.20.99) by firewall1.glaxowellcome.com via smap (V5.5) id xmaaq0283; Wed, 5 Jul 00 11:27:42 -0400
Received: by ussun2m.glaxo.com id KAA10881; Wed, 5 Jul 2000 10:56:00 -0400 (EDT)
Received: from 152.51.60.17 by securemail1.glaxo.com with SMTP ( WorldSecure Server SMTP Relay(WSS) v4.5); Wed, 05 Jul 2000 10:50:03 -0400
X-Server-Uuid: c7fabf50-5a2e-11d2-968c-00805fc1f894
Received: from 152.51.20.99 by securemail1.glaxo.com with SMTP ( WorldSecure Server SMTP Relay(WSS) v4.5); Fri, 23 Jun 2000 17:35:31 -0400
X-Server-Uuid: c7fabf50-5a2e-11d2-968c-00805fc1f894
Received: by ussun2m.glaxo.com id RAA15558; Fri, 23 Jun 2000 17:35:33 -0400 (EDT)
Received: by firewall1.glaxowellcome.com; id RAA27929; Fri, 23 Jun 2000 17:35:53 -0400 (EDT)
Received: from ns.secondary.com(208.184.76.39) by firewall1.glaxowellcome.com via smap (V5.5) id xma027631; Fri, 23 Jun 00 17:34:35 -0400
Received: from localhost (daemon@localhost) by ns.secondary.com ( 8.9.3/8.9.3) with SMTP id OAA06544; Fri, 23 Jun 2000 14:33:42 -0700 ( PDT)
Received: by mail.imc.org (bulk_mailer v1.12); Fri, 23 Jun 2000 14:33:33 -0700
Received: from iaik.tu-graz.ac.at (excalibur.iaik.tu-graz.ac.at [129.27.152.30]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id OAA06477 for <[e-mail]>; Fri, 23 Jun 2000 14:33:31 -0700 (PDT)
Received: from PLIPP2 [129.27.152.34] by iaik.tu-graz.ac.at ( SMTPD32-6.00) id A7AB19D0128; Fri, 23 Jun 2000 23:33:31 +0200
Received: from 127.0.0.1 [127.0.0.1] by PLIPP2 (IAIK S/MIME Mapper 2.0beta3 22/March/2000); Fr, 23 Jun 2000 23:34:23 +0100
From: "Peter Lipp" <[e-mail]>
To: "Michael Zolotarev" <[e-mail]>, [e-mail]
Subject: AW: AW: self-signed TSA [Was Re: Private Key Cloning]
Date: Fri, 23 Jun 2000 23:34:22 +0200
Message-ID: <[e-mail]>
MIME-Version: 1.0
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0)
In-Reply-To: <[e-mail]>
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700
Precedence: bulk
List-Archive: http://www.imc.org/ietf-pkix/mail-archive/
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: mailto:[e-mail]?body=unsubscribe
X-WSS-ID: 154D07A991476-01-02
X-WSS-ID: 157D949111757-01-01
Content-Type: multipart/mixed;  boundary="_-==154D07AF50==-_"

--_-==154D07AF50==-_
Content-Type: multipart/signed; 
 boundary=--IAIK.SMIME.MAPPER.8A03CDEB--; 
 micalg=sha1; 
 protocol="application/x-pkcs7-signature"
Content-Transfer-Encoding: 7bit

This is a multipart MIME message, it may require a MIME capable user agent.
----IAIK.SMIME.MAPPER.8A03CDEB--
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

> I guess the problem is a common misconception that a TSA is always a
> subsidiary/sub-service of a CA. Not necessary. TSA is/can_be a service on
> its own, with no inherited relationship to any CA at all.
Sure it can. But I bet it still will have certificates from some CA (more
than one maybe) that trust the TSA for doing their service properly. Do you
really believe the average user will and can go and check for each and every
service provider if it should be trusted? If he at some point really
consiously decided to trust a certain CA, it will be close to a miracle.
Most will accept somebody elses decisions, maybe preconfigured by the
vendor, and if the SW asks: should I trust, he will hit the "never ask me
that question again" button....

Peter



----IAIK.SMIME.MAPPER.8A03CDEB--
Content-Type: application/x-pkcs7-signature; 
 name=smime.p7s
Content-Transfer-Encoding: base64
Content-Disposition: attachment; 
 filename=smime.p7s

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAA
oIIVIDCCBE0wggM5oAMCAQICAwGGrTAJBgUrDgMCHQUAMIIBEzELMAkGA1UEBhMC
QVQxDzANBgNVBAgTBlN0eXJpYTENMAsGA1UEBxMER1JBWjEZMBcGA1UECRMQSW5m
ZmVsZGdhc3NlIDE2YTEmMCQGA1UEChMdR1JBWiBVTklWRVJTSVRZIE9GIFRFQ0hO
T0xPR1kxRzBFBgNVBAsTPkluc2l0dXRlIGZvciBBcHBsaWVkIEluZm9ybWF0aW9u
IFByb2Nlc3NpbmcgYW5kIENvbW11bmljYXRpb25zMRkwFwYDVQQLExBJQUlLIElO
VFJBTkVUIENBMRkwFwYDVQQDExBJQUlLIFRVLUdSQVogU0lHMSIwIAYDVQQMExlJ
QUlLIGVsZWN0cm9uaWMgc2lnbmF0dXJlMB4XDTk5MTEyODIwMjIzOVoXDTAwMTEy
ODIwMjIzOVowgZMxCzAJBgNVBAYTAkFUMSYwJAYDVQQKEx1HUkFaIFVOSVZFUlNJ
VFkgT0YgVEVDSE5PTE9HWTFHMEUGA1UECxM+SW5zaXR1dGUgZm9yIEFwcGxpZWQg
SW5mb3JtYXRpb24gUHJvY2Vzc2luZyBhbmQgQ29tbXVuaWNhdGlvbnMxEzARBgNV
BAMTClBldGVyIExpcHAwgZ0wDQYJKoZIhvcNAQEBBQADgYsAMIGHAoGBAM5s1aJQ
xXxczmMNSJtL4cv9nhMA+dtbUN4+DA5qfZBqcwR2zWw2VulPyrAeZDA1HFP8zlpk
PlC5C4hNnX+p7QdG8u0LMk45FwaatOm2r2gEmTYGH/znwQSrKTsZXi0d0VHZV0TX
yU/I3SlYxSXfjFafAVE09KKa2m8jcUOhF97dAgEDo4G0MIGxMDgGA1UdHwQxMC8w
LaAroCmkJzAlMRAwDgYDVQQKEwdpYWlrLmF0MREwDwYDVQQDEwhJQUlLQ1JMMTAR
BglghkgBhvhCAQEEBAMCAKAwKAYJYIZIAYb4QgENBBsWGVVzZXItQ2VydGlmaWNh
dGUgSU5UUkFORVQwDAYDVR0TBAUwAwEBADAdBgNVHREEFjAUgRJQZXRlci5MaXBw
QGlhaWsuYXQwCwYDVR0PBAQDAgbAMAkGBSsOAwIdBQADggEBAA4r/qDOLW8ChbuC
2pGzcf74Uv190Q45aHj99lMgNhPQRIVaLLNXJH+NYJxEvIwmVOWIXjdA03TqkOOq
FJ/tK31wV+RbrvaPaVUwRjPhC2f8rr+K6pp9mzUC1SolUEbRWVHgOZGsbnEJkTEr
oJOelFdKr0coT+Xeje/fI5d50P3CwsJLR2PFkiswnOoWBINi2nq6MGZ7fwmzW8F9
ZVstrNMQYCeEj4V2SR/YIUrDxsdqMQyorBe/su3eab3fOpPlonb86KKWH6jLdgpi
KGRoHGWeGgAWlMB0HdxaupX7Lm8LhVYZOdh9SpvO8AdhMyOXNHOKF6sMXCZvSEHy
2XUvbmAwggRUMIIDQKADAgECAgJOIDAJBgUrDgMCHQUAMIGZMQswCQYDVQQGEwJB
VDEmMCQGA1UEChMdR1JBWiBVTklWRVJTSVRZIE9GIFRFQ0hOT0xPR1kxRzBFBgNV
BAsTPkluc2l0dXRlIGZvciBBcHBsaWVkIEluZm9ybWF0aW9uIFByb2Nlc3Npbmcg
YW5kIENvbW11bmljYXRpb25zMRkwFwYDVQQDExBJQUlLIElOVFJBTkVUIENBMB4X
DTk5MTExNDEyNTE0OVoXDTAyMTIzMTIyNTkzMFowggETMQswCQYDVQQGEwJBVDEP
MA0GA1UECBMGU3R5cmlhMQ0wCwYDVQQHEwRHUkFaMRkwFwYDVQQJExBJbmZmZWxk
Z2Fzc2UgMTZhMSYwJAYDVQQKEx1HUkFaIFVOSVZFUlNJVFkgT0YgVEVDSE5PTE9H
WTFHMEUGA1UECxM+SW5zaXR1dGUgZm9yIEFwcGxpZWQgSW5mb3JtYXRpb24gUHJv
Y2Vzc2luZyBhbmQgQ29tbXVuaWNhdGlvbnMxGTAXBgNVBAsTEElBSUsgSU5UUkFO
RVQgQ0ExGTAXBgNVBAMTEElBSUsgVFUtR1JBWiBTSUcxIjAgBgNVBAwTGUlBSUsg
ZWxlY3Ryb25pYyBzaWduYXR1cmUwggEgMA0GCSqGSIb3DQEBAQUAA4IBDQAwggEI
AoIBAQDSyhKuZGsL1EPk5mOTG8RzhHS/Va+/WYjs7Zm91nwVHu1+XFLJeJ85AICk
SQ7yq9lWa9ur34cywbNhl/9QxaOBOiHkMvAuXxs2Bq/uhe/hEb1T7XgO12ptG80q
SOP8/nKxw1PXlbUkd1rD9727mO/5tpvagEQfz7CZQ5wI4HkrNw5uH/vsJ72wRcRT
FzmHy/nOX3Y9sXLd/V7TG8j1x0oNWsR3b0tHEWM+Oc1Qq5FfCknoMMCitSD38cUL
CCcLJtVxkOiapWaZrDXUAuhvshhsRPjkXh6IzpqsZEtRI64SurLoUUShPv108ELE
6rfQKtm9FNnlFRD954diwfFHko/lAgEFozMwMTARBglghkgBhvhCAQEEBAMCAAIw
DwYDVR0TBAgwBgEB/wIBATALBgNVHQ8EBAMCAQYwCQYFKw4DAh0FAAOCAQEAc26n
vl5jQspoqD0fzjpZkqGARmFVj9uHNqVoWttqw/y6t46OhJUcePEmXkKsFP4NuCFx
2MyvmbWb6R6QNQ5WfoarGWyQ382cQN6mccPS5weDjXAzYeGZUkx99K70ncVxkwq7
rINAhJtari2XSLxmfBJyTYrZuWEgd5C9NBuf2u3iZyArarOKPbrBjZxjmXwBbZ7t
sfAhSVMGSr2ODgQcQjf7ZndNIsQZL75HkN21Pj+/x3wnMCAQF50+Pt8ioAgZ/SAu
dxmdYNr2itI0vmsV/xjD1NQuwb6+HwmR2LxclhMzrT1VbtTDkRLD/h8LKC1OpKV8
lQlS7Ir+Od/XNafKJjCCA8owggKyoAMCAQICAQEwDQYJKoZIhvcNAQEEBQAwgZkx
CzAJBgNVBAYTAkFUMSYwJAYDVQQKEx1HUkFaIFVOSVZFUlNJVFkgT0YgVEVDSE5P
TE9HWTFHMEUGA1UECxM+SW5zaXR1dGUgZm9yIEFwcGxpZWQgSW5mb3JtYXRpb24g
UHJvY2Vzc2luZyBhbmQgQ29tbXVuaWNhdGlvbnMxGTAXBgNVBAMTEElBSUsgSU5U
UkFORVQgQ0EwHhcNOTkxMTE0MTIzMTU5WhcNMDIxMjMxMjI1OTMwWjCBmTELMAkG
A1UEBhMCQVQxJjAkBgNVBAoTHUdSQVogVU5JVkVSU0lUWSBPRiBURUNITk9MT0dZ
MUcwRQYDVQQLEz5JbnNpdHV0ZSBmb3IgQXBwbGllZCBJbmZvcm1hdGlvbiBQcm9j
ZXNzaW5nIGFuZCBDb21tdW5pY2F0aW9uczEZMBcGA1UEAxMQSUFJSyBJTlRSQU5F
VCBDQTCCASAwDQYJKoZIhvcNAQEBBQADggENADCCAQgCggEBAMLr+IHe6qeAtYLk
fvxyRI6ogrvBP5iKPEBZ7j3T1yVJL7CDPGH8hgPsI4qt6Fnzh2MuAq84JS58zX5x
LqEUC/E5xw1xyAzorC6yWwxGRhb+fvTg4OlM2JVsTlyJO6F/BWlXuZU33lgGky/R
X84sItXKhmhbUPscnHYBsVKcQO5rFcRrJK/5c1Mha/bcQNVDQaQw+HRCvr7T4mAV
Yi+DVJv6jb393CoDBnffGP/mcIkFGFO5D6lyfP8QiSs06+0unIYWwUn1YzQI2RNB
AjXrCuAJtlf4qYrGXC09Neg8ymoI2uOglo6scWiZXt/prxWoi+btPX8oWDl5+7DE
tCf0rx8CAQejHTAbMAwGA1UdEwQFMAMBAf8wCwYDVR0PBAQDAgEGMA0GCSqGSIb3
DQEBBAUAA4IBAQAfdOMJ/ePlmrY0flkgiL6vyRDBuWGcIaB/oGofngJzbQLa7X2s
hWzpIiVpvo64XcjIBuocpErhIQfc2UZTSqYYT7R2Uydh0wVeqScURuwuihFURPhI
7GWCSrNwym2lrwsva2Xh/MTyzhXs9vo29dP2djjelN8n347dXhKJOYJ0tsA583af
EKmKvkfzAb+sQLxEmPyasQTCGJMec/iWjLTsEDRfCrROYVgDZ4NcCpiRSv9mWw6s
PYB8Chf5fJq1waFzluFYSUkuF24NKVopr1E4dKt2Lc1zdMRGRztKQWeUiBLkqFCQ
xsi6iZrl1nvMCdF+scuLj7G4lNshx6n1ZcabMIIETTCCAzmgAwIBAgIDAw1NMAkG
BSsOAwIdBQAwggETMQswCQYDVQQGEwJBVDEPMA0GA1UECBMGU3R5cmlhMQ0wCwYD
VQQHEwRHcmF6MRkwFwYDVQQJExBJbmZmZWxkZ2Fzc2UgMTZhMSYwJAYDVQQKEx1H
UkFaIFVOSVZFUlNJVFkgT0YgVEVDSE5PTE9HWTFHMEUGA1UECxM+SW5zaXR1dGUg
Zm9yIEFwcGxpZWQgSW5mb3JtYXRpb24gUHJvY2Vzc2luZyBhbmQgQ29tbXVuaWNh
dGlvbnMxGTAXBgNVBAsTEElBSUsgSU5UUkFORVQgQ0ExGzAZBgNVBAMTEklBSUsg
VFUtR1JBWiBDUllQVDEgMB4GA1UEDBMXSUFJSyBjb25maWRlbnRpYWxpdHkgQ0Ew
HhcNOTkxMTI4MjAyMzM4WhcNMDAxMTI4MjAyMzM4WjCBkzELMAkGA1UEBhMCQVQx
JjAkBgNVBAoTHUdSQVogVU5JVkVSU0lUWSBPRiBURUNITk9MT0dZMUcwRQYDVQQL
Ez5JbnNpdHV0ZSBmb3IgQXBwbGllZCBJbmZvcm1hdGlvbiBQcm9jZXNzaW5nIGFu
ZCBDb21tdW5pY2F0aW9uczETMBEGA1UEAxMKUGV0ZXIgTGlwcDCBnTANBgkqhkiG
9w0BAQEFAAOBiwAwgYcCgYEAvQe3ZdxrE2Nv5z2ZLink1P2MFeQb5gYrS55w4jsX
ZGD5v9Ajnv3w30Ajcn7jI+blIvYYpmNQV476+aUHNZFUML/KN5WGVXfdBOxb2n+6
Porez8KMnUlq3cCvAdhVdquFjwaRHO5k7gY80hNAfVker52A1aXbrT0TaWGlCl25
sq0CAQWjgbQwgbEwOAYDVR0fBDEwLzAtoCugKaQnMCUxEDAOBgNVBAoTB2lhaWsu
YXQxETAPBgNVBAMTCElBSUtDUkwxMBEGCWCGSAGG+EIBAQQEAwIAoDAoBglghkgB
hvhCAQ0EGxYZVXNlci1DZXJ0aWZpY2F0ZSBJTlRSQU5FVDAMBgNVHRMEBTADAQEA
MB0GA1UdEQQWMBSBElBldGVyLkxpcHBAaWFpay5hdDALBgNVHQ8EBAMCA3gwCQYF
Kw4DAh0FAAOCAQEAhvbZ0/1a47YqiCYjsnsqxWhFufL9oPQzzK9sBDjZZwbpPnhD
ZN8PmBqWUXAo74a6oz7Q0W1QieAPCIGenFcVe5ui9m+9TDwtrQN1ECE5k3VuGlh9
l+1Sw5GjFEynARTDmaSRIc75EV/nx4a1LuHLkRYGC5Mg6LskWpIw7ShdPD54U/3Q
19iboaASh0ynfySjBsy1549hQcmi9UfMMX7u1QCCia2kd15u+YaVxtWoMHFB59q6
ELx+9XseEpEI/zBlvSwdyDTXWtnlxnzZjsyk0a/W+FpdeuZ7k2Dbf/Owx0nXS70M
HrH/AErvvbhxJ1BaAPC6TAN6da4xPpwy5XSRfjCCBFQwggNAoAMCAQICAnUwMAkG
BSsOAwIdBQAwgZkxCzAJBgNVBAYTAkFUMSYwJAYDVQQKEx1HUkFaIFVOSVZFUlNJ
VFkgT0YgVEVDSE5PTE9HWTFHMEUGA1UECxM+SW5zaXR1dGUgZm9yIEFwcGxpZWQg
SW5mb3JtYXRpb24gUHJvY2Vzc2luZyBhbmQgQ29tbXVuaWNhdGlvbnMxGTAXBgNV
BAMTEElBSUsgSU5UUkFORVQgQ0EwHhcNOTkxMTE0MTI1NTM2WhcNMDIxMjMxMjI1
OTMwWjCCARMxCzAJBgNVBAYTAkFUMQ8wDQYDVQQIEwZTdHlyaWExDTALBgNVBAcT
BEdyYXoxGTAXBgNVBAkTEEluZmZlbGRnYXNzZSAxNmExJjAkBgNVBAoTHUdSQVog
VU5JVkVSU0lUWSBPRiBURUNITk9MT0dZMUcwRQYDVQQLEz5JbnNpdHV0ZSBmb3Ig
QXBwbGllZCBJbmZvcm1hdGlvbiBQcm9jZXNzaW5nIGFuZCBDb21tdW5pY2F0aW9u
czEZMBcGA1UECxMQSUFJSyBJTlRSQU5FVCBDQTEbMBkGA1UEAxMSSUFJSyBUVS1H
UkFaIENSWVBUMSAwHgYDVQQMExdJQUlLIGNvbmZpZGVudGlhbGl0eSBDQTCCASAw
DQYJKoZIhvcNAQEBBQADggENADCCAQgCggEBAMEnzjatic90xi5VRmr0i2O16Z1a
SElQFZitoNvAzGw+KehOTuKeUr5ALHib9tGInNm+jPTWVGl/u5Hab1JRzXj0xAKy
qvZ+KphGy6ag6VcCVySJmeY1AqTM0W78XdFQXnlZuciBv00Ktoulb/Ktgh6c0YNg
o4UMVdxjGHJweibT1AGvlFe2BqulwtuwOLovMIuIyHHh+o6F2HXYKUB54GJpia1B
2IfmqcpBBFdYtDlHyrxugB5QhuhLo0BjD8jCe8B2gkQnI2wIeyfpLlH+u3/VQAl1
2cZKkqaqPpOgP/znsdh62QBSabrRluvCp9OQW9M8u+mJlrxIIVwtThfzIW0CAQWj
MzAxMBEGCWCGSAGG+EIBAQQEAwIAAjAPBgNVHRMECDAGAQH/AgEBMAsGA1UdDwQE
AwIBBjAJBgUrDgMCHQUAA4IBAQBa+v4JIzqbBydvFOaP/dA5D/GLWEWjPTF8tKcP
hxlEYABH8dW5E2tk/nNE2CDyGjkJtR+o9kiCDCa4N/qlc2LepJpa0I28Hi4wCd0C
uxSWpEuDHNDrW6Y/bU8gJ8DpskVl+lR0QFkqSCWAu3bY0e2VvUffk2ltrx1KvO64
vGX+ayZn2P7naGHPfYjCBWUKzW0zS8chVf0aehu/qXFuZDfy1MlDgEnPl1DQ1vSL
CMmFEDc99iNzcCU7ILn+RgWPNYPVhCUqoDQ6buX00ohfNVS/OHgqkWpa1HLvLRXq
E9NmYUJvfhE2zCY6w6bTME3IfDCXRat2Q3twP4/iP9xtsTbPMYICeDCCAnQCAQEw
ggEcMIIBEzELMAkGA1UEBhMCQVQxDzANBgNVBAgTBlN0eXJpYTENMAsGA1UEBxME
R1JBWjEZMBcGA1UECRMQSW5mZmVsZGdhc3NlIDE2YTEmMCQGA1UEChMdR1JBWiBV
TklWRVJTSVRZIE9GIFRFQ0hOT0xPR1kxRzBFBgNVBAsTPkluc2l0dXRlIGZvciBB
cHBsaWVkIEluZm9ybWF0aW9uIFByb2Nlc3NpbmcgYW5kIENvbW11bmljYXRpb25z
MRkwFwYDVQQLExBJQUlLIElOVFJBTkVUIENBMRkwFwYDVQQDExBJQUlLIFRVLUdS
QVogU0lHMSIwIAYDVQQMExlJQUlLIGVsZWN0cm9uaWMgc2lnbmF0dXJlAgMBhq0w
CQYFKw4DAhoFAKCBsTAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3
DQEJBTEPFw0wMDA2MjMyMTM0MjNaMCMGCSqGSIb3DQEJBDEWBBRxCE72xr47V3Mr
SVFLlPFfOZikgzBSBgkqhkiG9w0BCQ8xRTBDMAoGCCqGSIb3DQMHMA4GCCqGSIb3
DQMCAgIAgDANBggqhkiG9w0DAgIBQDANBggqhkiG9w0DAgIBKDAHBgUrDgMCBzAN
BgkqhkiG9w0BAQEFAASBgMiIJYnloS3RWMW4oAn/jeFn8V6nVPjyWfgnSWnK2ko8
D1cqCS31beJePiEa+7eFjgaz/luEEngzEHWmOIZLwg/fg9JQPUuWx2tDByoyp6IE
qdolRWRFIja4CYOToMUGmoXv1UqO5Lv8qa7M5bVS+JhMFyQvNwCoSrLWJwL87AgN
AAAAAAAA
----IAIK.SMIME.MAPPER.8A03CDEB----

--_-==154D07AF50==-_
Content-Type: text/plain; 
 charset=us-ascii; 
 name=wssalert.txt
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment; 
 filename=wssalert.txt

"WorldSecure Server <glaxo.com>" made the following
 annotations on 06/23/00 17:35:33
------------------------------------------------------------------------------

[ALERT] -- Security Manager:
Proxy decryption/verification failed.  The message could not be decrypted.


==============================================================================


--_-==154D07AF50==-_--



Received: from thalia.fm.intel.com (thalia.fm.intel.com [132.233.247.11]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id HAA12331 for <[e-mail]>; Wed, 5 Jul 2000 07:49:30 -0700 (PDT)
Received: from SMTP (fmsmsxvs04-1.fm.intel.com [132.233.42.204]) by thalia.fm.intel.com (8.9.1a+p1/8.9.1/d: relay.m4,v 1.30 2000/06/08 18:25:35 dmccart Exp $) with SMTP id OAA03904 for <[e-mail]>; Wed, 5 Jul 2000 14:51:36 GMT
Received: from fmsmsx26.fm.intel.com ([132.233.48.26]) by 132.233.48.204 (Norton AntiVirus for Internet Email Gateways 1.0) ; Wed, 05 Jul 2000 14:50:41 0000 (GMT)
Received: by fmsmsx26.fm.intel.com with Internet Mail Service (5.5.2650.21) id <N32LJQMK>; Wed, 5 Jul 2000 07:49:59 -0700
Message-ID: <[e-mail]>
From: "Eissa, Mohamed" <[e-mail]>
To: [e-mail]
Subject: CMP & CRS Which is better?
Date: Wed, 5 Jul 2000 07:49:57 -0700 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain; charset="iso-8859-1"

Hello everybody,

I am evaluating numer of CA servers and I the certification methodologies
with PKIX.
I am still confused what are the advantages/disadvantages of CRS(PKCS
messaging) and CMP protocols? What is the most popular one most of CA server
vendors support? 

Mohamed



Received: from e1.ny.us.ibm.com (e1.ny.us.ibm.com [32.97.182.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id HAA12262 for <[e-mail]>; Wed, 5 Jul 2000 07:48:36 -0700 (PDT)
From: [e-mail]
Received: from northrelay02.pok.ibm.com (northrelay02.pok.ibm.com [9.117.200.22]) by e1.ny.us.ibm.com (8.9.3/8.9.3) with ESMTP id KAA169554; Wed, 5 Jul 2000 10:47:59 -0400
Received: from D51MTA04.pok.ibm.com (d51mta04.pok.ibm.com [9.117.200.32]) by northrelay02.pok.ibm.com (8.8.8m3/NCO v4.9) with SMTP id KAA206300; Wed, 5 Jul 2000 10:49:51 -0400
Received: by D51MTA04.pok.ibm.com(Lotus SMTP MTA v4.6.5  (863.2 5-20-1999))  id 85256913.005176C8 ; Wed, 5 Jul 2000 10:49:48 -0400
X-Lotus-FromDomain: IBMUS
To: Jean-Marc Desperrier <[e-mail]>
cc: [e-mail]
Message-ID: <[e-mail]>
Date: Wed, 5 Jul 2000 10:49:38 -0400
Subject: Re: RFC 2459 and internationalized domain names
Mime-Version: 1.0
Content-type: text/plain; charset=us-ascii
Content-Disposition: inline

     Comments below.  Are we going to need to change over a third of the
extension OID's - and if so, should we try hard to avoid doing so?

          Tom Gindin

Jean-Marc Desperrier <[e-mail]> on 07/05/2000
05:40:40 AM

To:   [e-mail]
cc:
Subject:  Re: RFC 2459 and internationalized domain names



Paul Hoffman / IMC wrote:

> >My secondary comment is that PKIX really shouldn't be in the business of
> >specifying altName formats and semantics at all.  The definition of what
> >constitutes a valid email address, DNS name, IP address, and so forth,
has no
> >place in a PKIX RFC.  The same goes for name-matching rules: it's not up
to
> >PKIX to define these.  It's a loser's game, where PKIX will have to be
> >maintained indefinitely in order to keep up with the evolving Internet.
>
> Agree.

The current version of RFC2459 serves two purposes : defining the format of
the
certificate and defining some "best practices" for implementations of what
everyone must be able to support.
This best practices are needed, an ASN1 based format has just too many
possibilities.

[Tom Gindin] And somebody has to define the ASN.1 for each extension.  If
that doesn't belong in PKIX, why do we have an entire section on the use of
standard extensions?

> >If an Internet group wants to be compatible with PKIX, it should be up
to
> >them to define a PKIX sub-profile on what it means to conform to their
stuff.

And this would be a big problem because there would several different PKIX
sub-profiles.

If the standard of PKIX defines both the format and the best practices,
that means
it must be able to evolve easily to adapt to new practices.

Or there must be two separate documents for each of theses aspects.

Now if the RFC2459 wasn't so strict about the email format, url format,
etc...
this would be a good thing.

[Tom Gindin] Agreed.

The format of GeneralName is :
GeneralName ::= CHOICE {
        otherName                   [0] INSTANCE OF OTHER-NAME,
        rfc822Name                  [1] IA5String,
        dNSName                     [2] IA5String,
        x400Address                 [3] ORAddress,
        directoryName               [4] Name,
        ediPartyName                [5] EDIPartyName,
        uniformResourceIdentifier   [6] IA5String,
        iPAddress                   [7] OCTET STRING,
        registeredID                [8] OBJECT IDENTIFIER }

As these are implicits tags, this  is closed to evolutions in the format of
the
data, it is not possible to modify the standard to allow rfc822Name to be a
CHOICE
between UTF8strings, and IA5String, as could be done with explicit tags. It
seems
we need to create something like :
        rfcSonOf822Name                  [9] UTF8strings,

[Tom Gindin] I think it's rfc822I18N [9] UTF8String, but that's minor.

The same applies to dNSName, and uniformResourceIdentifier.

[Tom Gindin] I have one basic question here.  Does adding new members to
this choice mean we have to change OID's for the extensions using it (not
just SubjectAltName, but IssuerAltName, AuthorityKeyIdentifier,
NameConstraints, CRLDistributionPoint, CertificateIssuer,
IssuingDistributionPoint and AuthorityInfoAccess in RFC 2459 alone - and I
might have missed one)?  If it does, should we and X.509 bite that
particular bullet or define OTHER-NAME's as DirectoryString's instead?

It seems to me using a CHOICE format similar to DirectoryString for
rfc822Name,
dNSName, uniformResourceIdentifier, and a recommendation to use IA5String
in the
current state of things would have been a better solution.

[Tom Gindin] It might well have been better (using AugmentedDirectoryString
as a CHOICE between DirectoryString and IA5String, or
InternetDirectoryString as a CHOICE between IA5String and the three Unicode
string types), but it's probably too late.




Received: from exchsvr1.entegrity.com (exchsvr1.entegrity.com [207.215.19.3]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id GAA08821 for <[e-mail]>; Wed, 5 Jul 2000 06:23:25 -0700 (PDT)
Received: from roger (dave.cost.se [195.100.88.62]) by exchsvr1.entegrity.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21) id N706W8AX; Wed, 5 Jul 2000 06:31:44 -0700
From: "Martin Lindström" <[e-mail]>
To: <[e-mail]>
Cc: <[e-mail]>
Subject: CMP transport protocol - who should close the connection?
Date: Wed, 5 Jul 2000 15:24:13 +0200
Message-ID: <000301bfe684$504453f0$[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 8bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300

Regarding draft-ietf-pkix-cmp-transport-protocols-00.txt:
One of the reasons of introducing a protocol for transport of
CMP messages was that interoperability testing showed that there
were no clear definitions on who should close a connection and
when. The new protocol tries to solve these issues, but during
the PKIForum initiated CMP interoperability testing I have run
into some cases not covered by the draft.

Suppose that a CR/CP is sent in one connection and when the
client is about to send its certConf it connects to the server
and sends the TCP message with the close bit set.
Should the client wait for the server to close the connection
or should it do it itself?
IMO the client cannot really do it itself since it must be prepared
to receive a pkiconf message from the CA (e.g. that the cert hash
comparison failed), and if the server does not close the
connection the client will either hang or timeout.

So what I want is that section 2.3 is extended with:
"If the connection close bit is set on a request, then the server
 MUST set the bit in the response and close the connection after
 sending the response. <add - begin> In the case the server does
 not intend to send any response to the client request, the server
 should close the connection directly. <add - end>"

Comments?

/Martin

********* Entegrity Solutions *********
 Martin Lindström, Systems Designer
 Finlandsgatan 60
 S-166 74 Kista, Sweden
 Direct: [phone]
 Fax:    [phone]
 Cell:   [phone]
***************************************



Received: from certplus.com ([195.101.88.81]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id CAA28238 for <[e-mail]>; Wed, 5 Jul 2000 02:40:32 -0700 (PDT)
Received: from certplus.com (nt4_jmd.certplus.com [192.168.1.17]) by certplus.com (8.8.7/8.8.7) with ESMTP id KAA25796 for <[e-mail]>; Wed, 5 Jul 2000 10:11:09 +0200
Message-ID: <[e-mail]>
Date: Wed, 05 Jul 2000 11:40:40 +0200
From: Jean-Marc Desperrier <[e-mail]>
Organization: Certplus
X-Mailer: Mozilla 4.72 [en] (WinNT; I)
X-Accept-Language: en
MIME-Version: 1.0
To: [e-mail]
Subject: Re: RFC 2459 and internationalized domain names
References: <p0432040eb586e5039935@[165.227.249.13]> <[e-mail]> <p04320424b587e3244ec9@[165.227.249.13]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Paul Hoffman / IMC wrote:

> >My secondary comment is that PKIX really shouldn't be in the business of
> >specifying altName formats and semantics at all.  The definition of what
> >constitutes a valid email address, DNS name, IP address, and so forth, has no
> >place in a PKIX RFC.  The same goes for name-matching rules: it's not up to
> >PKIX to define these.  It's a loser's game, where PKIX will have to be
> >maintained indefinitely in order to keep up with the evolving Internet.
>
> Agree.

The current version of RFC2459 serves two purposes : defining the format of the
certificate and defining some "best practices" for implementations of what
everyone must be able to support.
This best practices are needed, an ASN1 based format has just too many
possibilities.

> >If an Internet group wants to be compatible with PKIX, it should be up to
> >them to define a PKIX sub-profile on what it means to conform to their stuff.

And this would be a big problem because there would several different PKIX
sub-profiles.

If the standard of PKIX defines both the format and the best practices, that means
it must be able to evolve easily to adapt to new practices.

Or there must be two separate documents for each of theses aspects.

Now if the RFC2459 wasn't so strict about the email format, url format, etc...
this would be a good thing.

The format of GeneralName is :
GeneralName ::= CHOICE {
        otherName                   [0] INSTANCE OF OTHER-NAME,
        rfc822Name                  [1] IA5String,
        dNSName                     [2] IA5String,
        x400Address                 [3] ORAddress,
        directoryName               [4] Name,
        ediPartyName                [5] EDIPartyName,
        uniformResourceIdentifier   [6] IA5String,
        iPAddress                   [7] OCTET STRING,
        registeredID                [8] OBJECT IDENTIFIER }

As these are implicits tags, this  is closed to evolutions in the format of the
data, it is not possible to modify the standard to allow rfc822Name to be a CHOICE
between UTF8strings, and IA5String, as could be done with explicit tags. It seems
we need to create something like :
        rfcSonOf822Name                  [9] UTF8strings,

The same applies to dNSName, and uniformResourceIdentifier.

It seems to me using a CHOICE format similar to DirectoryString for rfc822Name,
dNSName, uniformResourceIdentifier, and a recommendation to use IA5String in the
current state of things would have been a better solution.



Received: from rmx470-mta.mail.com (rmx470-mta.mail.com [165.251.48.48]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id AAA21629 for <[e-mail]>; Wed, 5 Jul 2000 00:42:14 -0700 (PDT)
Received: from web302-mc.mail.com (web302-mc.mail.com [165.251.48.163]) by rmx470-mta.mail.com (8.9.3/8.9.3) with SMTP id DAA20783 for <[e-mail]>; Wed, 5 Jul 2000 03:43:33 -0400 (EDT)
Message-ID: <[e-mail]>
Date: Wed, 5 Jul 2000 03:43:32 -0400 (EDT)
From: Pedrabissi  Raffaele <[e-mail]>
To: [e-mail]
Mime-Version: 1.0
Content-Type: text/plain
Content-Transfer-Encoding: 7bit
X-Mailer: mail.com
X-Originating-IP: 212.177.60.6

Good morning, I`m Raffaele Pedrabissi, a student of Politecnico of Milano
(ITALY-EUROPE) and I`m doing a stage in Alcatel of Vimercate (Milano-ITALY).
I write You because I had read the RFC 2459 for the electronic certicates.
Now I have a little problem: I`m searching a program in C language that
creates an electronic certificate and one that notices the same certificate.
Thank You for Your time.
Pedrabissi Raffaele.


______________________________________________
FREE Personalized Email at Mail.com
Sign up at http://www.mail.com/?sr=signup



Received: from d12lmsgate.de.ibm.com (d12lmsgate.de.ibm.com [195.212.91.199]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id XAA19929 for <[e-mail]>; Tue, 4 Jul 2000 23:40:09 -0700 (PDT)
From: [e-mail]
Received: from d12relay01.de.ibm.com (d12relay01.de.ibm.com [9.165.215.22]) by d12lmsgate.de.ibm.com (1.0.0) with ESMTP id IAA219202 for <[e-mail]>; Wed, 5 Jul 2000 08:40:20 +0200
Received: from d12mta05.de.ibm.com (d12mta05_cs0 [9.165.222.239]) by d12relay01.de.ibm.com (8.8.8m3/NCO v2.07) with SMTP id IAA200272 for <[e-mail]>; Wed, 5 Jul 2000 08:40:44 +0200
Received: by d12mta05.de.ibm.com(Lotus SMTP MTA v4.6.5  (863.2 5-20-1999))  id C1256913.0024AE73 ; Wed, 5 Jul 2000 08:40:39 +0200
X-Lotus-FromDomain: IBMIL@IBMDE
To: "Doug M Williscroft" <[e-mail]>
cc: [e-mail]
Message-ID: <[e-mail]>
Date: Wed, 5 Jul 2000 09:43:07 +0300
Subject: Re: Trading Partner Web Certificates
Mime-Version: 1.0
Content-type: text/plain; charset=us-ascii
Content-Disposition: inline

Doug, your design below requires distribution of the private key of the
trading partner to each of its employees allowed to access your site. This
clearly creates significant exposure to this key. What are the reasons for
taking this risk, rather than having the trading partner (or you) issue
certificates to each employee of the business partner allowed to access
your site?

If the problem is the need to manage a potentially complex policy for
deciding which users can access your site (using which certificates)...
this can be easily achieved using e.g. our Trust Establishment system
(download from our site http://www.hrl.il.ibm.com).

Best Regards,
Amir Herzberg

IBM Research Lab in Haifa (Tel Aviv Office)
http://www.hrl.il.ibm.com


"Doug M Williscroft" <[e-mail]> on 06/23/2000
09:30:21 PM

Please respond to "Doug M Williscroft" <[e-mail]>

To:   [e-mail]
cc:    (bcc: Amir Herzberg/Haifa/IBM)
Subject:  Trading Partner Web Certificates




This note is to elicit feedback on a PKI model that my organization has
implemented for web delivery/collection of information. We call it the
"trading partner certificate" model.

The trading partner certificate model does not attempt to provide the
full benefits of the grand PKI vision but limits itself to browser-based
extranets. The solution we have adopted is rather simple but - due to
limitations of existing technology - not especially elegant. Even so, we
believe it to provide significant authentication benefit at at
significantly lower cost than other alternatives.

At the end of this note I describe a desirable new function for
certificate management (at the browser and/or OS) that would provide
broad benefit for extranet applications under this model.  I believe
this additional functionality would be relatively easy to develop, and
would quite possibly find a large market.

Our model:
1) Establish a trading agreement with an organization through standard
business processes which include contractual definition of obligaitions.

2) Issue a trading partner certificate to the organization. (In our
current case the certificates are "anonymous"; they make no statement
about the trading partner. This is not a necessary component of the
model. Neither is it necessary that we be the certificate issuer.)

3) The trading partner installs the certificate and private key on all
browsers that will be used to access our services. (Most of our trading
partners use the IE5 browser which allows the private key to be flagged
as "not exportable" from the computer - a highly desirable feature in
our from our perspective.)

4) The trading partner registers its users in our extranet directory -
and assumes responsibility for managing those users - including
assignment of access permissions within the bounds of the trading
partner agreement. (At this point user administration requires some
intervention on our part - we anticipate fully externalized user
management in the future.)

5) Users connecting to our web servers are challenged (via SSL) to
provide a client certificate.

6) Users presenting a valid trading partner certificate are challenged
for UserID and Password.

7) Users presenting a valid password and the correct trading partner
certificate for that user's organization are granted access to the
appropriate services.

To impersonate a user an attacker must gain direct access to a computer
in the trading partner organization, and gain knowledge of a valid
userID and password pair. We see this 2-factor mechanism as offering
protection against password discovery (by attackers external to the
trading partner organization), and against man-in-the-middle attacks
based on URL hijacking or DNS poisoning.

Desirable new certificate management functionality:
It would be helpful to our trading partners if certificates/private keys
could be centrally distributed en-masse to all computers/user profiles
in a trading partner organization. Currently, our trading partners must
manually install the private key to each user login account that will
use our services - a tedious activity. This task must be repeated prior
to certificate expiry. Fortunately our trading partners are willing to
accept this administrative burden because they consider the services we
offer sufficiently valuable.

Comments?

--
Doug Williscroft
HealthNet/BC Architecture and Standards Branch
Ministry of Health Information Management Group

Telephone: [phone]
_______________________________________________





Received: from [165.227.249.13] (ip13.proper.com [165.227.249.13]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id LAA25304; Tue, 4 Jul 2000 11:56:21 -0700 (PDT)
Mime-Version: 1.0
X-Sender: [e-mail]
Message-Id: <p04320424b587e3244ec9@[165.227.249.13]>
In-Reply-To: <[e-mail]>
References: <p0432040eb586e5039935@[165.227.249.13]> <[e-mail]>
Date: Tue, 4 Jul 2000 11:57:37 -0700
To: Marc Branchaud <[e-mail]>, [e-mail]
From: Paul Hoffman / IMC <[e-mail]>
Subject: Re: RFC 2459 and internationalized domain names
Content-Type: text/plain; charset="us-ascii" ; format="flowed"

At 11:45 AM -0700 7/4/00, Marc Branchaud wrote:
>My main comment is that PKIX would be unwise to try to anticipate how other
>protocols might evolve.  PKIX should really wait until the IDN, email, or any
>other group, figures out what they're going to do before making any changes
>in a PKIX RFC.

Agree.

>My secondary comment is that PKIX really shouldn't be in the business of
>specifying altName formats and semantics at all.  The definition of what
>constitutes a valid email address, DNS name, IP address, and so forth, has no
>place in a PKIX RFC.  The same goes for name-matching rules: it's not up to
>PKIX to define these.  It's a loser's game, where PKIX will have to be
>maintained indefinitely in order to keep up with the evolving Internet.

Agree.

>What PKIX should do is provide generic space for altNames in PKIX certs and
>protocols, but leave the definition and handling of these to other groups.

Agree.

>If an Internet group wants to be compatible with PKIX, it should be up to
>them to define a PKIX sub-profile on what it means to conform to their stuff.

The problem with this is, as you point out below, that PKIX already 
*does* describe what a domain name is, what an email address is, and 
so on. If any the standards for these evolves (and we can expect they 
will), one of two situations arises:

- PKIX has to be revised to change with the standard.
- PKIX prevents users from identifying themselves using the revised standard.

>PKIX hasn't gone this way in the past though, despite these arguments, so I
>doubt it'll change now.

Agree.

--Paul Hoffman, Director
--Internet Mail Consortium


Received: from crack.x509.com ([e-mail] [199.175.150.1]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id LAA24941 for <[e-mail]>; Tue, 4 Jul 2000 11:43:27 -0700 (PDT)
Received: from xcert.com (saxifrage.x509.com [199.175.148.75]) by crack.x509.com (8.10.0/XCERT) with ESMTP id e64IihI22140 for <[e-mail]>; Tue, 4 Jul 2000 11:44:44 -0700 (PDT)
Sender: [e-mail]
Message-ID: <[e-mail]>
Date: Tue, 04 Jul 2000 11:45:44 -0700
From: Marc Branchaud <[e-mail]>
Organization: Xcert International Inc.
X-Mailer: Mozilla 4.73 [en] (X11; U; Linux 2.2.10 i686)
X-Accept-Language: en, fr
MIME-Version: 1.0
To: [e-mail]
Subject: Re: RFC 2459 and internationalized domain names
References: <p0432040eb586e5039935@[165.227.249.13]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Hi Paul...

My main comment is that PKIX would be unwise to try to anticipate how other
protocols might evolve.  PKIX should really wait until the IDN, email, or any
other group, figures out what they're going to do before making any changes
in a PKIX RFC.

My secondary comment is that PKIX really shouldn't be in the business of
specifying altName formats and semantics at all.  The definition of what
constitutes a valid email address, DNS name, IP address, and so forth, has no
place in a PKIX RFC.  The same goes for name-matching rules: it's not up to
PKIX to define these.  It's a loser's game, where PKIX will have to be
maintained indefinitely in order to keep up with the evolving Internet.

What PKIX should do is provide generic space for altNames in PKIX certs and
protocols, but leave the definition and handling of these to other groups. 
If an Internet group wants to be compatible with PKIX, it should be up to
them to define a PKIX sub-profile on what it means to conform to their stuff.

PKIX hasn't gone this way in the past though, despite these arguments, so I
doubt it'll change now.

		Marc

+------------------------------------------------------------------------+
 Marc Branchaud                                  \/
 Chief PKI Architect                             /\CERT INTERNATIONAL INC.
 [e-mail]        PKI References page:              www.xcert.com
 604-640-6227          www.xcert.com/~marcnarc/PKI/
+------------------------------------------------------------------------+


Received: from edelweb.fr (edelweb.fr [193.51.12.16]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id JAA22435 for <[e-mail]>; Tue, 4 Jul 2000 09:16:49 -0700 (PDT)
Received: from champagne.edelweb.fr (localhost.edelweb.fr [127.0.0.1]) by edelweb.fr with ESMTP id SAA17680 for <[e-mail]>; Tue, 4 Jul 2000 18:17:33 +0200 (MET DST)
Received: from champagne.edelweb.fr (champagne.edelweb.fr [193.51.14.161]) by edelweb.fr (nospam/1.3); Tue, 4 Jul 2000 18:17:33 +0200 (MET DST)
Received: from emeriau.edelweb.fr (emeriau.edelweb.fr [193.51.14.5]) by champagne.edelweb.fr (8.7.6/8.6.6) with ESMTP id SAA19044 for <[e-mail]>; Tue, 4 Jul 2000 18:17:32 +0200 (MET DST)
From: Peter Sylvester <[e-mail]>
Received: (sylvest@localhost) by emeriau.edelweb.fr (8.7.6/8.6.6) id SAA19428 for [e-mail]; Tue, 4 Jul 2000 18:17:32 +0200 (MET DST)
Date: Tue, 4 Jul 2000 18:17:32 +0200 (MET DST)
Message-Id: <[e-mail]>
To: [e-mail]
Subject: RE: I-D ACTION:draft-ietf-pkix-time-stamp-08.txt : SIA

Some time ago I had asked about the status of the 
Subject information Access extension mentioned in the actual
time stamping draft as being or to be defined in son of RFC2459.

It would be nice to hear some more details about that from
let's say one of the editors of the documents mentioned.

Thanks in advance
Peter Sylvester



Received: from mailout02.sul.t-online.com (mailout02.sul.t-online.com [194.25.134.17]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id IAA21927 for <[e-mail]>; Tue, 4 Jul 2000 08:55:13 -0700 (PDT)
From: [e-mail]
Received: from fwd01.sul.t-online.com  by mailout02.sul.t-online.com with smtp  id 139V3a-0003bo-05; Tue, 4 Jul 2000 17:56:18 +0200
Received: from webmail.t-online.de (340036226028-0001@[194.25.134.114]) by fwd01.sul.t-online.com with smtp id 139V3V-0HBHSyC; Tue, 4 Jul 2000 17:56:13 +0200
Date: 04 Jul 2000 15:56 GMT
Subject: kein Betreff
To: [e-mail]
X-Mailer: T-Online WebMail 0.99
MIME-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Message-ID: <[e-mail]>
X-Sender: [e-mail]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by ns.secondary.com id IAA21928

unsubscribe


Received: from [165.227.249.13] (ip13.proper.com [165.227.249.13]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id TAA05684 for <[e-mail]>; Mon, 3 Jul 2000 19:08:49 -0700 (PDT)
Mime-Version: 1.0
X-Sender: [e-mail] (Unverified)
Message-Id: <p0432040eb586e5039935@[165.227.249.13]>
Date: Mon, 3 Jul 2000 19:10:01 -0700
To: [e-mail]
From: Paul Hoffman / IMC <[e-mail]>
Subject: RFC 2459 and internationalized domain names
Content-Type: text/plain; charset="us-ascii" ; format="flowed"

Greetings again. There is active work in the IETF to allow non-ASCII 
characters in doamin names. This is being considered in the IDN 
Working Group (see 
<http://www.ietf.org/html.charters/idn-charter.html> for the WG 
charter). There is a strong desire for these names in many parts of 
the world.

If the wire format for the new domain names includes non-ASCII 
characters (which seems likely to me), then we probably should change 
2459 to handle these new names. Fortunately, son-of-2459 is still not 
finished.

Please note that:
- The IDN WG may not come up with a protocol
- The protocol may be ASCII-only, using an encoding scheme that maps 
to the current rules for domain names
- If there is a binary protocol, it is likely (but not definitely) 
going to be UTF-8

Given that, it might be wise of us to either change how domain names 
are represented 2459 or to put warnings into the text about this  in 
son-of-2459. It is likely that son-of-2459 will be finished well 
before the IDN WG is finished.

Oh, and if the IDN WG creates a binary protocol, there will be a 
strong demand for changes to the email protocols to handle binary 
domain names in headers. There will also be a strong demand for 
binary on the left-hand side of the addr-spec. We may wan to consider 
these as well.

Thoughts?

--Paul Hoffman, Director
--Internet Mail Consortium


Received: from balinese.baltimore.ie ([e-mail] [194.125.215.8]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id JAA23335 for <[e-mail]>; Mon, 3 Jul 2000 09:09:02 -0700 (PDT)
Received: by balinese.baltimore.ie; id RAA10553; Mon, 3 Jul 2000 17:10:12 +0100 (GMT/IST)
Received: from bobcat.baltimore.ie(192.168.20.10) by balinese.baltimore.ie via smap (V4.2) id xma010537; Mon, 3 Jul 00 17:09:54 +0100
Received: from baltimore.ie (lease212-21.baltimore.ie [192.168.21.212]) by bobcat.baltimore.ie (8.9.3/8.9.3) with ESMTP id RAA32581; Mon, 3 Jul 2000 17:09:53 +0100
Message-ID: <[e-mail]>
Date: Mon, 03 Jul 2000 17:09:55 +0100
From: Stephen Farrell <[e-mail]>
Reply-To: [e-mail]
Organization: Baltimore Technologies Ltd.
X-Mailer: Mozilla 4.72 [en] (WinNT; U)
X-Accept-Language: en
MIME-Version: 1.0
To: pkix <[e-mail]>
CC: xme <[e-mail]>, "Magnus =?iso-8859-1?Q?Nystr=F6m?="  <[e-mail]>
Subject: roaming credentials (sacred)
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Hi All,

I put up a slide in Adelaide about roaming credentials and it 
looks like we're on for a BOF in Pittsburgh (date TBD). The
strawman charter/BOF description is attached. So, if you're 
interested then subscribe to the list and let's see how much
progress we can make prior to Pittsburgh.

Paul Hoffman has kindly agreed to host the mailing list which 
he'll open for postings in a day or two, as soon as subscribing 
is seen to be working without problems, (but you can subscribe 
right now). Paul's also hosting the web site at:

           http://www.imc.org/ietf-sacred

If you have any questions in the meantime, feel free to 
mail Magnus and/or me directly.

Regards,
Stephen.

-- 
____________________________________________________________
Stephen Farrell         				   
Baltimore Technologies,   tel: (direct line) [phone]
61 Fitzwilliam Lane,                    fax: [phone]
Dublin 2.                mailto:[e-mail]
Ireland                             http://www.baltimore.com


Strawman charter for Securely Available Credentials (sacred) WG:
================================================================

Working Group name:      Securely Available Credentials (sacred)

Chairs (suggested):      Stephen Farrell, Baltimore Technologies
                         <[e-mail]>, and
                         Magnus Nystrom, RSA Security Inc.
                         <[e-mail]> 

Area:                    Security

Area Directors:          Jeffrey Schiller <[e-mail]>
                         Marcus Leech <[e-mail]>

Resp. Area Director:     TBD

Mailing list:            [e-mail]

Web Site:                http://www.imc.org/ietf-sacred/

Descr. of WG:

A nice feature of smart-card based PKIs, in addition to the security
offered by the cards themselves, is the "free-seating solution," or
the portability of user's credentials. In order to provide a similar
solution or service to environments where security is based on pure
software implementations or so-called "soft tokens" (a.k.a. "virtual
smart cards," software files containing information normally stored
on smart cards) some kind of credential store from which users can
download their soft-tokens, using some specified protocol is
required. This protocol will provide mobility for credentials.

Such a protocol and specified data format might also allow an
individual user to have the same set of credentials on, e.g., her
mobile phone as in her desktop. Adding an upload protocol to the
solution means that it in principle would be possible to always have
the credential store up-to-date.

Even in some cases where real smart cards are used, there may
be some benefit to using such a protocol - e.g. when a new card
is received, but "old" credentials should be used. If the cards
offered the appropriate install and delete interfaces, then the
credentials could be (securely) moved between cards.

Many desktop applications also require mobility of credentials, for 
example to  support some "kiosk" style operation, when a user 
upgrades a PC, or when "hot-desking". It is sometimes required to 
integrate such credential mobility with single-sign-on solutions. A 
protocol that could be used in the smart card case, can also be 
used to solve this case.

Finally, some applications may benefit from the ability to migrate
credentials from a device to a smart card, in particular where
the smart card using device has limited user interface capabililies,
e.g. a mobile phone.

Security is at a premium for this working group; only authorized
entities should be allowed to download credentials, credentials must
be protected against eavesdropping and cut & paste attacks; attackers
must not be able to succesfully replace an entities credentials at a
credential serer; etc.

Availability is also at a premium, a credential server must
be reachable from many different types of client with different
characteristics in terms of processing power, storage and
network connectivity.

The purpose of this working group is therefore to gather 
requirements for a solution beneficial to the Internet 
community, establish a framework for such a solution, and to
develop or adopt the required protocols and credential formats. 

Goals & Milestone:       

(The timeline assumes that the WG is approved just after 
Pittsburgh.)

Oct 00  Submit first draft of Requirements document
   
Nov 00  Submit first draft of Frameworks document

Dec 00  Submit second draft of Requirements document
        Submit second draft of Frameworks document
        Submit first draft of Protocol document (incl. PDU syntax)

Mar 01  Requirements document to Informational RFC
        Frameworks document to Informational RFC
        Submit second draft of Protocol document

Jun 01  Protocol document to Proposed Standard

Jul 01  WG recharters if appropriate


Outline BOF Agenda:

- agenda bashing
- scene setting (some problems that might be solved)
- HTTP/SASL strawman
- <other proposals>
- WG charter discussion


Received: from fgwmail6.fujitsu.co.jp (fgwmail6.fujitsu.co.jp [192.51.44.36]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id WAA04535 for <[e-mail]>; Sun, 2 Jul 2000 22:31:38 -0700 (PDT)
Received: from m4.gw.fujitsu.co.jp by fgwmail6.fujitsu.co.jp (8.9.3/3.7W-MX0006-Fujitsu Gateway) id OAA27818 for <[e-mail]>; Mon, 3 Jul 2000 14:32:11 +0900 (JST) (envelope-from [e-mail])
Received: from vishnu.ec.cs.fujitsu.co.jp by m4.gw.fujitsu.co.jp (8.9.3/3.7W-0006-Fujitsu Domain Master) id OAA18414; Mon, 3 Jul 2000 14:32:10 +0900 (JST)
Received: from ec.cs.fujitsu.co.jp (cath.ec.cs.fujitsu.co.jp [10.34.199.204]) by vishnu.ec.cs.fujitsu.co.jp (8.8.5+2.7Wbeta5/3.4W5-04/12/98 EC domain mail master) with ESMTP id OAA04595 for <[e-mail]>; Mon, 3 Jul 2000 14:32:10 +0900 (JST)
Message-ID: <[e-mail]>
Date: Mon, 03 Jul 2000 14:32:05 +0900
From: Kong QiuYan <[e-mail]>
X-Mailer: Mozilla 4.7 [ja] (WinNT; U)
X-Accept-Language: ja
MIME-Version: 1.0
To: [e-mail]
Subject: Re: certificate chain validation(policy extension)
References: <[e-mail]> <[e-mail]>
Content-Type: text/plain; charset=iso-2022-jp
Content-Transfer-Encoding: 7bit

 Thank you very much for the reply.

 I agree with you.  It depends on the policy constraints extension.

 However, I think that the process of (e)(f)  is to keep the certificate policy's
consistency in certificate chain. If the SkipCerts is greater than zero, and the policy
extension is null, how can we  explain it(in this case the Cert chain will be valid)? 

 Thanks in advance.  

KwonSung Chung wrote:
> 
> I think it is depend on policy constraints extension.
> 
> If requireExplicitPolicy sub-field of the Root certificate
> has 0 as value of SkipCerts, the certificate chain is invalid because
> the policy checking about CA certificate  must be processed.
> 
> But, in the case of positive integer(greater then  zero), the certificate chain is
> valid ( if other extension is valid).
> 
> ------------------
> KwonSung Chung
> KISA
> [e-mail]
> ------------------
> 
> Kong QiuYan wrote:
> 
> > Suppose I have a certificate chain consisting of a Root, a CA and a User
> > certificate.
> >
> > The policy extension in the Root certificate contains one oid of 1.1.1(critical)
> > The policy extension in the CA certificate does not exist.
> > The policy extension in the User certificate contains one oid of 1.1.1(critical)
> >
> > Assuming all other data is valid, is this a valid certificate chain?
> >
> > It appears to me that the algorithm defined in RFC2459 would determine that
> > this certificate path is valid.
> >
> > -----------
> > RFC2459 6.1 says:
> >
> >       (e)  Verify that policy information is consistent with the
> >       acceptable policy set:
> >
> >          (1) if the certificate policies extension is marked critical,
> >          the intersection of the policies extension and the acceptable
> >          policy set shall be non-null;
> >
> >          (2) the acceptable policy set is assigned the resulting
> >          intersection as its new value.
> >
> >       (g) Verify that the intersection of the acceptable policy set and
> >       the initial policy set is non-null.
> > ---------
> >
> > Personally, I think that all of the certificates in a valid path must have
> > policy extension(critical or non-critical). Am I wrong?
> >
> > QiuYan Kong,
> > Fujitsu Ltd

-- 
-------------------------------------------------
Kong QiuYan
FUJITSU LIMITED
EMail: [e-mail]
  TEL: [phone]


Received: from mtiwmhc27.worldnet.att.net (mtiwmhc27.worldnet.att.net [204.127.131.52]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id UAA00107 for <[e-mail]>; Sun, 2 Jul 2000 20:40:04 -0700 (PDT)
Received: from client20 ([129.37.81.139]) by mtiwmhc27.worldnet.att.net (InterMail vM.4.01.02.39 201-229-119-122) with SMTP id <20000703034020.BLYG2120.mtiwmhc27.worldnet.att.net@client20> for <[e-mail]>; Mon, 3 Jul 2000 03:40:20 +0000
Message-ID: <003b01bfe49f$41f6f5a0$0b0a0a0a@client20>
From: "Norm McLeod" <[e-mail]>
To: "PKIX Mailing List" <[e-mail]>
Subject: Senate Bill 671
Date: Sun, 2 Jul 2000 22:31:54 -0500
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="----=_NextPart_000_0035_01BFE475.541608E0"; protocol="application/x-pkcs7-signature"; micalg=SHA1
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.00.2919.6600
Disposition-Notification-To: "Norm McLeod" <[e-mail]>
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6600

This is a multi-part message in MIME format.

------=_NextPart_000_0035_01BFE475.541608E0
Content-Type: multipart/alternative;
	boundary="----=_NextPart_001_0036_01BFE475.541608E0"


------=_NextPart_001_0036_01BFE475.541608E0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Gentleman (& Ladies):

I have been watching and reading this list for a couple of months (not =
that I have a clue to most of the subject matter), I try to keep up =
anyway.

I have been interested in Public Key Encryption for a while now though. =
Not for some esoteric reason, but pure greed. I think somebody's gonna =
make a lot of money off of this technology, and I want some.

For the big one:

Does anybody have any opinions about Senate Bill 671, signed into law =
last Friday???



Digitally Signed Message
ASSURING you this message is from:
                                Norman McLeod

NEW: With the force of law, nationwide (US):
http://www.whitehouse.gov/WH/New/html/20000630.html

Public Encryption Key included With THIS Message

------=_NextPart_001_0036_01BFE475.541608E0
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META content=3D"text/html; charset=3Diso-8859-1" =
http-equiv=3DContent-Type>
<META content=3D"MSHTML 5.00.3018.900" name=3DGENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=3D#ffffff>
<DIV><FONT face=3DArial size=3D2>Gentleman (&amp; =
Ladies):<BR></FONT></DIV>
<DIV><FONT face=3DArial size=3D2>I have been watching and reading this =
list for a=20
couple of months (not that I have a clue to most of the subject matter), =
I try=20
to keep up anyway.</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>I have been interested in Public Key =
Encryption for=20
a while now though. Not for some esoteric reason, but pure greed. I =
think=20
somebody's gonna make a lot of money off of this technology, and I want=20
some.</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>For the big one:</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>Does anybody have any opinions about =
Senate Bill=20
671, signed into law last Friday???</DIV></FONT>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2><BR>Digitally Signed =
Message<BR>ASSURING you this=20
message is=20
from:<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
Norman McLeod</FONT></DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>NEW: With the force of law, nationwide =
(US):<BR><A=20
href=3D"http://www.whitehouse.gov/WH/New/html/20000630.html">http://www.w=
hitehouse.gov/WH/New/html/20000630.html</A></FONT></DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>Public Encryption Key included With =
THIS=20
Message</FONT></DIV></BODY></HTML>

------=_NextPart_001_0036_01BFE475.541608E0--

------=_NextPart_000_0035_01BFE475.541608E0
Content-Type: application/x-pkcs7-signature;
	name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment;
	filename="smime.p7s"

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIJCTCCArww
ggIloAMCAQICAwKbIzANBgkqhkiG9w0BAQQFADCBlDELMAkGA1UEBhMCWkExFTATBgNVBAgTDFdl
c3Rlcm4gQ2FwZTEUMBIGA1UEBxMLRHVyYmFudmlsbGUxDzANBgNVBAoTBlRoYXd0ZTEdMBsGA1UE
CxMUQ2VydGlmaWNhdGUgU2VydmljZXMxKDAmBgNVBAMTH1BlcnNvbmFsIEZyZWVtYWlsIFJTQSAx
OTk5LjkuMTYwHhcNMDAwNTE5MDcxNDI1WhcNMDEwNTE5MDcxNDI1WjBeMQ8wDQYDVQQEEwZNY0xl
b2QxDzANBgNVBCoTBk5vcm1hbjEWMBQGA1UEAxMNTm9ybWFuIE1jTGVvZDEiMCAGCSqGSIb3DQEJ
ARYTbm9ybWNsZW9kQHBvYm94LmNvbTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAuuqw4TY7
xlXa7mMixYaR7boDIbbLUcGJYWVKJ2WDCBRnuhEbKkBhVln32TJBd8rsc7g0mfawSgaxc44b42V4
BBiOeYkrn2dkOy5OyR7nGcaDjGcvRVu4LkAccc7dZcGlM8tbIdSkn1AWjp0ZJjJNG46Sq+PrPLvu
PBa2UodqUr0CAwEAAaNRME8wHgYDVR0RBBcwFYETbm9ybWNsZW9kQHBvYm94LmNvbTAMBgNVHRMB
Af8EAjAAMB8GA1UdIwQYMBaAFIir8WCDZlX05FjHRh3AYb0j18OMMA0GCSqGSIb3DQEBBAUAA4GB
AKOdz9bRSxCxw8mdA4yl+50u4qqesn1fmGyujeR9x25mFabyBemkCwwEeNz8hmZ1tYbTtN/hmKug
ATd6nBsIRUsB5yTkDkowHgO+9WQrgkP3iHdIy4JdOomMmkc51hU6gIDH1SXEGMRm0RshCVRQbryi
C+v8pvjLtgQaCCUdxucBMIIDFDCCAn2gAwIBAgIBCzANBgkqhkiG9w0BAQQFADCB0TELMAkGA1UE
BhMCWkExFTATBgNVBAgTDFdlc3Rlcm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3duMRowGAYDVQQK
ExFUaGF3dGUgQ29uc3VsdGluZzEoMCYGA1UECxMfQ2VydGlmaWNhdGlvbiBTZXJ2aWNlcyBEaXZp
c2lvbjEkMCIGA1UEAxMbVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIENBMSswKQYJKoZIhvcNAQkB
FhxwZXJzb25hbC1mcmVlbWFpbEB0aGF3dGUuY29tMB4XDTk5MDkxNjE0MDE0MFoXDTAxMDkxNTE0
MDE0MFowgZQxCzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxFDASBgNVBAcTC0R1
cmJhbnZpbGxlMQ8wDQYDVQQKEwZUaGF3dGUxHTAbBgNVBAsTFENlcnRpZmljYXRlIFNlcnZpY2Vz
MSgwJgYDVQQDEx9QZXJzb25hbCBGcmVlbWFpbCBSU0EgMTk5OS45LjE2MIGfMA0GCSqGSIb3DQEB
AQUAA4GNADCBiQKBgQCzaVqX1NAWC3q1xV3pIZwjcs0STEv3fs/H+8pyJPRCUqxXleN7YXoXhOf9
cjk4lLTq7WWnkgZeveBl9hm7lHl2TD65aHB1hBz0EXQAvAUsTwkDFzHM9EHUcsamXeKIRLCLLsRN
8fDWhT5s85WUeJF+QOmc0Y0VV47Cc+Uw3kb1TwIDAQABozcwNTASBgNVHRMBAf8ECDAGAQH/AgEA
MB8GA1UdIwQYMBaAFHJJwnM0xlX0C3ZygX539IfnxrIOMA0GCSqGSIb3DQEBBAUAA4GBAGvGWekx
+um27LED2N9ycv6RYEjqxlXde/BnjsZhcOdtwqU32J23FyhWBYvdXHVvxpGQxmxmcRPQEHxrkW+G
4CE2LcHX6rIJrc8tbcaDUpv7u/6ch538t+l0kuRcl678fqzKDW9yemcsa3P1hvmd9QBu9B0Hzp2e
gmMp75MJflXeMIIDLTCCApagAwIBAgIBADANBgkqhkiG9w0BAQQFADCB0TELMAkGA1UEBhMCWkEx
FTATBgNVBAgTDFdlc3Rlcm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3duMRowGAYDVQQKExFUaGF3
dGUgQ29uc3VsdGluZzEoMCYGA1UECxMfQ2VydGlmaWNhdGlvbiBTZXJ2aWNlcyBEaXZpc2lvbjEk
MCIGA1UEAxMbVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIENBMSswKQYJKoZIhvcNAQkBFhxwZXJz
b25hbC1mcmVlbWFpbEB0aGF3dGUuY29tMB4XDTk2MDEwMTAwMDAwMFoXDTIwMTIzMTIzNTk1OVow
gdExCzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUgVG93
bjEaMBgGA1UEChMRVGhhd3RlIENvbnN1bHRpbmcxKDAmBgNVBAsTH0NlcnRpZmljYXRpb24gU2Vy
dmljZXMgRGl2aXNpb24xJDAiBgNVBAMTG1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBDQTErMCkG
CSqGSIb3DQEJARYccGVyc29uYWwtZnJlZW1haWxAdGhhd3RlLmNvbTCBnzANBgkqhkiG9w0BAQEF
AAOBjQAwgYkCgYEA1GnX1LCUZFtx6UfYDFG26nKRsIRefS0Nj3sS34UldSh0OkIsYyeflXtL734Z
hx2G6qPduc6WZBrCFG5ErHzmj+hND3EfQDimAKOHePb5lIZererAXnbr2RSjXW56fAylS1V/Bhkp
f56aJtVquzgkCGqYx7Hao5iR/Xnb5VrEHLkCAwEAAaMTMBEwDwYDVR0TAQH/BAUwAwEB/zANBgkq
hkiG9w0BAQQFAAOBgQDH7JJ+Tvj1lqVnYiqk8E0RYNBvjWBYYawmu1I1XAjPMPuoSpaKH2JCI4wX
D/S6ZJwXrEcp352YXtJsYHFcoqzceePnbgBHH7UNKOgCneSa/RP0ptl8sfjcXyMmCZGAc9AUG95D
qYMl8uacLxXK/qarigd1iwzdUYRr5PjRzneigTGCAgAwggH8AgEBMIGcMIGUMQswCQYDVQQGEwJa
QTEVMBMGA1UECBMMV2VzdGVybiBDYXBlMRQwEgYDVQQHEwtEdXJiYW52aWxsZTEPMA0GA1UEChMG
VGhhd3RlMR0wGwYDVQQLExRDZXJ0aWZpY2F0ZSBTZXJ2aWNlczEoMCYGA1UEAxMfUGVyc29uYWwg
RnJlZW1haWwgUlNBIDE5OTkuOS4xNgIDApsjMAkGBSsOAwIaBQCggbowGAYJKoZIhvcNAQkDMQsG
CSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMDAwNzAzMDMzMTU0WjAjBgkqhkiG9w0BCQQxFgQU
Oil/9QDB0oCv/izMQHjrFCE61eIwWwYJKoZIhvcNAQkPMU4wTDAOBggqhkiG9w0DAgICAIAwCgYI
KoZIhvcNAwcwDQYIKoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZIhvcNAwICASgwBwYFKw4DAh0w
DQYJKoZIhvcNAQEBBQAEgYC1w7tAbGoB/JcO9sGJvhRf9ogTTxXWYlkbnEQWUksvQkAfGzS8pckg
Nt8h3cCaHxI6Wn44cXqecLunCODcnNmPtYd1bhzToVjZeU90NFeUCi5kCIjX5c+MOyJbLB9PIrgq
Qyph7Vlb0M5dz7gYqM574mPvr3xMsXtp9iljdcbaWAAAAAAAAA==

------=_NextPart_000_0035_01BFE475.541608E0--



Received: from stargate.zergo.com.au (IDENT:[e-mail] [203.2.208.130]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id SAA21245 for <[e-mail]>; Sun, 2 Jul 2000 18:34:01 -0700 (PDT)
Received: from sydneymail1.baltimore.com.au (sydneymail1.jp.zergo.com.au [192.168.71.5]) by stargate.zergo.com.au (8.9.1/8.8.7) with ESMTP id LAA04011; Mon, 3 Jul 2000 11:40:37 +1000
Received: by sydneymail1.jp.zergo.com.au with Internet Mail Service (5.5.2448.0) id <N62M071Y>; Mon, 3 Jul 2000 11:34:07 +1000
Message-ID: <[e-mail]>
From: Michael Zolotarev <[e-mail]>
To: Stephen Kent <[e-mail]>
Cc: "'PKIX'" <[e-mail]>
Subject: RE: I-D ACTION:draft-ietf-pkix-time-stamp-08.txt. HASH
Date: Mon, 3 Jul 2000 11:34:06 +1000 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2448.0)
Content-Type: multipart/mixed; boundary="----_=_NextPart_000_01BFE48E.C728EBE0"

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_000_01BFE48E.C728EBE0
Content-Type: text/plain;
	charset="iso-8859-1"

Stephen,
> 
> I may have lost track of the counter argument here.  Why would one 
> not want to have a TSA do the best possible job when it comes to 
> ensuring syntactic consistency re its inputs?

A few of us are being concerned that forcing the TSA to 'know' the hash oid
and to perform the sanity check is an unnecessary requirement, causing more
evil than good. 
Instead of reiterrating our position, I've attached a few messages from the
thread which summarize the views.

Regards
Michael


------_=_NextPart_000_01BFE48E.C728EBE0
Content-Type: message/rfc822
Content-Description: Re: I-D ACTION:draft-ietf-pkix-time-stamp-08.txt. HASH

Message-ID: <[e-mail]>
From: [e-mail]
To: Michael Zolotarev <[e-mail]>
Cc: Paul Koning <[e-mail]>, [e-mail], 
	[e-mail]
Subject: Re: I-D ACTION:draft-ietf-pkix-time-stamp-08.txt. HASH
Date: Wed, 21 Jun 2000 11:18:29 +1000
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2448.0)
Content-Type: text/plain;
	charset="iso-8859-1"

I agree as well.  There is no need for the TSA to check anything about the
imprint. This requirement should be removed from the draft.

Terry Hayes
[e-mail]

Michael Zolotarev wrote:

> > If I were to generate my imprint with hash algorithm FRED that has a
> > 37 byte digest, does it matter to the TSA?  No, it does not.  So why
> > are we saying that the TSA needs to know the OID for FRED, and the
> > associated digest length?
> >
> > The spec says that it's done to consistency-check the length of the
> > imprint.  Sure, but to what end?  If I send a digest generated by FRED
> > but truncate it to 31 bytes, what purpose is served by the TSA saying
> > "naughty boy you threw away 6 bytes"?  I may in fact have a legitimate
> > reason for doing this -- just as IPsec has a legitimate reason for
> > throwing away some of the hash bytes in the HMAC construct.  If it
> > actually mattered to the TSA algorithms, that would be one thing.  But
> > since the only purpose of the check is to do the check, let's get rid
> > of it, simplify the spec, make the TSA implementations more reliable,
> > and eliminate the need to ECO the spec every time a new hash appears.
> >
> >         paul
>
> I agree (expecting a public outcry here :). I always felt pretty
> uncomfortable with the TSA having to recognise the hash OID and checking
the
> length. And on top of if, this would now allow a client tp send a NO-HASH
> imprint, a clear text, if they want to.
>
> Michael
> >

------_=_NextPart_000_01BFE48E.C728EBE0
Content-Type: message/rfc822
Content-Description: RE: I-D ACTION:draft-ietf-pkix-time-stamp-08.txt. HASH

Message-ID: <[e-mail]>
From: Paul Koning <[e-mail]>
To: Michael Zolotarev <[e-mail]>
Cc: [e-mail], [e-mail]
Subject: RE: I-D ACTION:draft-ietf-pkix-time-stamp-08.txt. HASH
Date: Wed, 21 Jun 2000 01:04:42 +1000
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2448.0)
Content-Type: text/plain;
	charset="iso-8859-1"

>>>>> "Michael" == Michael Zolotarev <[e-mail]> writes:

 Michael> Folks, Haven't we already had a discussion about hash
 Michael> algorithm for messageImprint?


 Michael> I believe that the consensus was (and it is 100% reflected
 Michael> in the current draft) to allow a user to use whatever digest
 Michael> he/she wants. It is NOT a TSA concern if a user used 'weak'
 Michael> hash. The TSA does not inspect, modify, store or analyse the
 Michael> content of messageImprint - it only checks that the length
 Michael> of the hash corresponds to the hash algorithm. If so, then
 Michael> why should the draft imply any limitations on type of digest
 Michael> algorithms, except saying that they must be known?

 Michael> The position of the draft is, if I interpret it correctly:
 Michael> 1) The TSA does not care about hash algorithm used in
 Michael> messageImprint. But the algorithm must be known, to allow
 Michael> TSA to sanity-check the length of digested data.  2) The
 Michael> user is ADVICED to use strong hash, such as SHA-1 or MD5.

 Michael> This position of the draft with regards to hash is general,
 Michael> and provides enough space to grow, instead of being
 Michael> unnecessary restrictive. Can we leave it in peace :)?

Can we remove this unnecessary restrictions instead?

A rule of thumb of protocol design is that requirements are put in
because they are necessary for interoperability.  In the case we have
here, that rule of thumb doesn't apply.

If I were to generate my imprint with hash algorithm FRED that has a
37 byte digest, does it matter to the TSA?  No, it does not.  So why
are we saying that the TSA needs to know the OID for FRED, and the
associated digest length?

The spec says that it's done to consistency-check the length of the
imprint.  Sure, but to what end?  If I send a digest generated by FRED
but truncate it to 31 bytes, what purpose is served by the TSA saying
"naughty boy you threw away 6 bytes"?  I may in fact have a legitimate
reason for doing this -- just as IPsec has a legitimate reason for
throwing away some of the hash bytes in the HMAC construct.  If it
actually mattered to the TSA algorithms, that would be one thing.  But
since the only purpose of the check is to do the check, let's get rid
of it, simplify the spec, make the TSA implementations more reliable,
and eliminate the need to ECO the spec every time a new hash appears.

	  paul

------_=_NextPart_000_01BFE48E.C728EBE0
Content-Type: message/rfc822
Content-Description: RE: I-D ACTION:draft-ietf-pkix-time-stamp-08.txt. HASH

Message-ID: <[e-mail]>
From: Michael Zolotarev <[e-mail]>
To: [e-mail]
Cc: [e-mail]
Subject: RE: I-D ACTION:draft-ietf-pkix-time-stamp-08.txt. HASH
Date: Tue, 20 Jun 2000 13:21:12 +1000
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2448.0)
List-Unsubscribe: mailto:[e-mail]?body=unsubscribe
Content-Type: text/plain;
	charset="iso-8859-1"

Folks,

Haven't we already had a discussion about hash algorithm for messageImprint?


I believe that the consensus was (and it is 100% reflected in the current
draft) to allow a user to use whatever digest he/she wants. It is NOT a TSA
concern if a user used 'weak' hash. The TSA does not inspect, modify, store
or analyse the content of messageImprint - it only checks that the length of
the hash corresponds to the hash algorithm. If so, then why should the draft
imply any limitations on type of digest algorithms, except saying that they
must be known?

The position of the draft is, if I interpret it correctly:
1) The TSA does not care about hash algorithm used in messageImprint. But
the algorithm must be known, to allow TSA to sanity-check the length of
digested data.
2) The user is ADVICED to use strong hash, such as SHA-1 or MD5. 

This position of the draft with regards to hash is general, and provides
enough space to grow, instead of being unnecessary restrictive. Can we leave
it in peace :)?

Michael


> -----Original Message-----
> From: Paul Koning [mailto:[e-mail]]
> Sent: Tuesday, June 20, 2000 1:00 AM
> To: [e-mail]
> Cc: [e-mail]; [e-mail];
> [e-mail]
> Subject: Re: I-D ACTION:draft-ietf-pkix-time-stamp-08.txt
> 
> 
> >>>>> "Joerg" == Joerg Seidel <[e-mail]> writes:
> 
>  Joerg> Comments inline.
>  >> TSA implementations MUST support SHA-1.  TSA implementations
>  >> SHOULD support MD5.
> 
>  Joerg> I think there are good reasons not to use MD5 in time
>  Joerg> stamps. They should use a strong hash function in order to
>  Joerg> achive long validity periods. MD5 is likely to be unsafe (=not
>  Joerg> collision free) soon and is already discuraged by german
>  Joerg> authorities.
> 
>  Joerg> IF we add a section about algorithms, it should maybe read:
>  Joerg> "TSA implementations MUST support SHA-1.  TSA implementations
>  Joerg> SHOULD NOT support MD5.". But I think such a section is not
>  Joerg> very necessary.
> 
> IANAC, but from what I understand the currently known attacks on MD5
> are nowhere near strong enough to justify that.  
> 
> I don't have a problem with the current text (SHA-1 required, MD5
> recommended).  I do have a problem with text that implies that MD5 is
> bad, because I don't know of data that supports such an assertion.
> 
> Also, it doesn't seem like a good idea for the timestamp spec to give
> very different signals from the other security specs.  If there really
> is good reason to say these kinds of things about MD5, let's have them
> identified.  (German authorities are not a good reason.  Cryptanalysis
> that shows weaknesses of interesting size would be.)  If the issues
> are real, changes to MD5 text should be applied across the board.
> 
>       paul
> 

------_=_NextPart_000_01BFE48E.C728EBE0--


Received: from levitator.1div0.com ([213.250.43.61]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id QAA16923 for <[e-mail]>; Sun, 2 Jul 2000 16:39:44 -0700 (PDT)
Received: from intergalactic ([10.1.1.2]) by levitator.1div0.com (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with SMTP id BAA29494; Mon, 3 Jul 2000 01:27:25 +0200
Reply-To: <[e-mail]>
From: "denis bider" <[e-mail]>
To: "'Anders Rundgren'" <[e-mail]>, <[e-mail]>
Subject: RE: W2K fakes 128-bit crypto or not?
Date: Mon, 3 Jul 2000 01:41:03 +0200
Message-ID: <000101bfe47e$fc91f7a0$0201010a@intergalactic>
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2910.0)
X-MIMEOLE: Produced By Microsoft MimeOLE V5.00.2919.6700
In-Reply-To: <000a01bfe47e$db8e6de0$[e-mail]>
Importance: Normal

Hello Anders,

I have received no responses by members of this group.

I guess if the rumour had any merit then at least someone ought to have
heard? Or maybe not necessarily: just the other day I found sound-looking
information about how id Software has built a backdoor (yes, a back door,
kind of like Back Orifice) into its Quake product. Yes, Quake, the game.

It's interesting how these things don't get known or talked about - for
instance, the general population seems never to have heard about ECHELON.
Seems that, when it comes to striking news like this, people who haven't
seen the facts themselves are afraid of spreading the word, fearing that if
the rumour is proven wrong, they will be considered naive dummies without
credibility.

I have since subscribed to sci.crypt (hurray), so I'll run this W2K rumour
by them, too. I'll report if there is any response.

Regards,

denis


-----Original Message-----
From: Anders Rundgren [mailto:[e-mail]]
Sent: 3. julij 2000 01:40
To: [e-mail]; [e-mail]
Subject: W2K fakes 128-bit crypto or not?


Denis,
no news on this alarming news of yours?

Anders

-----Original Message-----
From: denis bider <[e-mail]>
To: 'Anders Rundgren' <[e-mail]>; [e-mail]
<[e-mail]>
Date: Saturday, June 17, 2000 15:43
Subject: Off-topic: crypto crippling


>[I would have posted this to the sci.crypt newsgroup, but I dislike doing
>that for several reasons - among them, slow message propagation, spam and
>last but not the least, I do not have Usenet configured and it takes a
while
>to find a server that carries sci.crypt. Does anyone know of a regular
>mailing list equivalent to the sci.crypt newsgroup?]
>
>Actually,
>
>I have heard a rumour that the '128-bit encryption' that Microsoft is
>shipping with Windows 2000 has actually been tweaked in such a way that it
>is only 128-bit when observed by a non-clued-in person, but is rather
40-bit
>for the people who know how it has been designed.
>
>In effect, rumour therefore has it that 88 bits out of the 128 are set in
>such a way that it is extremely easy to find them for someone who knows
how.
>The French are supposed to have found this out, and they are supposed to
>have been a little bit upset because of this fact.
>
>I am not sure how much of this is actually the truth. The person I received
>this information from might have confused this with the silent "3DES ->
DES"
>fallback in Windows that has been demonstrated lately.
>
>Can anyone confirm or deny the above rumour?
>
>Anyway. The bottom line is - I think people today are a little bit crazy to
>use, and even buy, security software as executables without any kind of
>access to the source code. It is plain stupid, and it gives the country
>which supplied you with the binaries a perfect weapon for the information
>wars that are due to ensue sooner or later. The world is not all roses all
>the time. Remember the several-billion-dollar deal which was lost by the
>European airplane manufacturer to Boeing because the USA was eavesdropping
>on their conversations with the purchaser?
>
>Iraq, Vatican and several others have learned this lesson when they bought
>black-box crypto machines from Crypto AG, only to find out that the machine
>transmits the encryption key almost in plaintext along with the encrypted
>message. Which, hence, was easily recoverable by folks from the NSA and
from
>the German intelligence agency.
>
>denis
>
>
>-----Original Message-----
>From: Anders Rundgren [mailto:[e-mail]]
>Sent: 17. junij 2000 14:44
>To: PKIX-List
>Subject: Why is Java still crypto-crippled?
>
>
>I have since quite a while been using W2K (Bill, it IS great!)  using
strong
>crypto
>although I live in Europe.   But why can't I get that for JDK?  Without
>special permissions.
>
>This is a *serious* threat to Java to be dependent on third-party tools
when
>the "other guy" has it all built-in!
>
>Anders
>
>Not religious about Java but likes it anyway.
>
>



Received: from d1o69.telia.com ([e-mail] [62.20.144.241]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id PAA16241 for <[e-mail]>; Sun, 2 Jul 2000 15:39:53 -0700 (PDT)
Received: from mega (t3o69p83.telia.com [62.20.145.83]) by d1o69.telia.com (8.8.8/8.8.8) with SMTP id AAA07495; Mon, 3 Jul 2000 00:40:53 +0200 (CEST)
Message-ID: <000a01bfe47e$db8e6de0$[e-mail]>
From: "Anders Rundgren" <[e-mail]>
To: <[e-mail]>, <[e-mail]>
Subject: W2K fakes 128-bit crypto or not?
Date: Mon, 3 Jul 2000 01:40:04 +0200
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 4.72.3110.5
X-MIMEOLE: Produced By Microsoft MimeOLE V4.72.3110.3
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by ns.secondary.com id PAA16242

Denis,
no news on this alarming news of yours?

Anders

-----Original Message-----
From: denis bider <[e-mail]>
To: 'Anders Rundgren' <[e-mail]>; [e-mail] <[e-mail]>
Date: Saturday, June 17, 2000 15:43
Subject: Off-topic: crypto crippling


>[I would have posted this to the sci.crypt newsgroup, but I dislike doing
>that for several reasons - among them, slow message propagation, spam and
>last but not the least, I do not have Usenet configured and it takes a while
>to find a server that carries sci.crypt. Does anyone know of a regular
>mailing list equivalent to the sci.crypt newsgroup?]
>
>Actually,
>
>I have heard a rumour that the '128-bit encryption' that Microsoft is
>shipping with Windows 2000 has actually been tweaked in such a way that it
>is only 128-bit when observed by a non-clued-in person, but is rather 40-bit
>for the people who know how it has been designed.
>
>In effect, rumour therefore has it that 88 bits out of the 128 are set in
>such a way that it is extremely easy to find them for someone who knows how.
>The French are supposed to have found this out, and they are supposed to
>have been a little bit upset because of this fact.
>
>I am not sure how much of this is actually the truth. The person I received
>this information from might have confused this with the silent "3DES -> DES"
>fallback in Windows that has been demonstrated lately.
>
>Can anyone confirm or deny the above rumour?
>
>Anyway. The bottom line is - I think people today are a little bit crazy to
>use, and even buy, security software as executables without any kind of
>access to the source code. It is plain stupid, and it gives the country
>which supplied you with the binaries a perfect weapon for the information
>wars that are due to ensue sooner or later. The world is not all roses all
>the time. Remember the several-billion-dollar deal which was lost by the
>European airplane manufacturer to Boeing because the USA was eavesdropping
>on their conversations with the purchaser?
>
>Iraq, Vatican and several others have learned this lesson when they bought
>black-box crypto machines from Crypto AG, only to find out that the machine
>transmits the encryption key almost in plaintext along with the encrypted
>message. Which, hence, was easily recoverable by folks from the NSA and from
>the German intelligence agency.
>
>denis
>
>
>-----Original Message-----
>From: Anders Rundgren [mailto:[e-mail]]
>Sent: 17. junij 2000 14:44
>To: PKIX-List
>Subject: Why is Java still crypto-crippled?
>
>
>I have since quite a while been using W2K (Bill, it IS great!)  using strong
>crypto
>although I live in Europe.   But why can't I get that for JDK?  Without
>special permissions.
>
>This is a *serious* threat to Java to be dependent on third-party tools when
>the "other guy" has it all built-in!
>
>Anders
>
>Not religious about Java but likes it anyway.
>
>



Received: from mailcity.com (fes-qout.whowhere.com [209.1.236.7]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id GAA28706 for <[e-mail]>; Sat, 1 Jul 2000 06:39:43 -0700 (PDT)
Received: from Unknown/Local ([?.?.?.?]) by mailcity.com; Sat Jul  1 06:40:03 2000
To: [e-mail]
Date: Sat, 01 Jul 2000 06:40:03 -0700
From: "chandrasekaran natarajan" <[e-mail]>
Message-ID: <[e-mail]>
Mime-Version: 1.0
X-Sent-Mail: off
Reply-To: [e-mail]
X-Mailer: MailCity Service
Subject: Re: DSA & ASN.1
X-Sender-Ip: 202.144.10.93
Organization: MailCity  (http://www.mailcity.lycos.com:80)
Content-Type: text/plain; charset=us-ascii
Content-Language: en
Content-Transfer-Encoding: 7bit

hello,

Can anyone let me know the ASN.1 Specification 
for Digital Signature Algorithm.

Thanks,

Chandar 
 


Send FREE Greetings for Father's Day--or any day!
Click here: http://www.whowhere.lycos.com/redirects/fathers_day.rdct