Re: Confirmation for subscribe ietf-pkix

[Christopher Stacy <[e-mail]>]

>>>>> On Fri, 30 Apr 1999 09:05:57 -0700, Paul Hoffman / IMC ("Paul") writes:

 Paul> At 11:53 AM 4/30/99 -0400, Christopher Stacy wrote:
 >> Looks kinda like a Majordomo bug, to me.
 Paul> No, it is a bug in the human who sent in the request. :-) You added the 
 Paul> name of the mailing list to the end of your "subscribe" request, even 
 Paul> though the instructions do not say you should do that.

Actually, my initial message was out of the blue without instructions,
and I didn't even know I was talking to majordomo.  I just sent to the
Internet de-facto standard address for requesting subscription changes.
My philosophy is that if there's going to a program processing mail,
it ought to be smart enough to figure out something like that.

 >> (Not yet being subscribed to this list, I didn't even know it was doing that.)
 Paul> You are now subscribed.

Thanks!

Chris




Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id PAA08459 for ietf-pkix-bks; Fri, 30 Apr 1999 15:31:05 -0700 (PDT)
Received: from I1.pilgrim.com (i1.pilgrim.com [206.3.211.10]) by mail.proper.com (8.8.8/8.8.5) with SMTP id PAA08454; Fri, 30 Apr 1999 15:31:04 -0700 (PDT)
Received: from BONK.pilgrim.com (bonk [206.3.211.31]) by I1.pilgrim.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via SMTP id SAA20357; Fri, 30 Apr 1999 18:33:21 -0400
Date: Fri, 30 Apr 1999 18:33:21 -0400
Message-Id: <[e-mail]>
From: Christopher Stacy <[e-mail]>
To: [e-mail]
CC: [e-mail]
In-reply-to: <[e-mail]> (message from Paul Hoffman / IMC on Fri, 30 Apr 1999 09:05:57 -0700)
Subject: Re: Confirmation for subscribe ietf-pkix
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

>>>>> On Fri, 30 Apr 1999 09:05:57 -0700, Paul Hoffman / IMC ("Paul") writes:

 Paul> At 11:53 AM 4/30/99 -0400, Christopher Stacy wrote:
 >> Looks kinda like a Majordomo bug, to me.
 Paul> No, it is a bug in the human who sent in the request. :-) You added the 
 Paul> name of the mailing list to the end of your "subscribe" request, even 
 Paul> though the instructions do not say you should do that.

Actually, my initial message was out of the blue without instructions,
and I didn't even know I was talking to majordomo.  I just sent to the
Internet de-facto standard address for requesting subscription changes.
My philosophy is that if there's going to a program processing mail,
it ought to be smart enough to figure out something like that.

 >> (Not yet being subscribed to this list, I didn't even know it was doing that.)
 Paul> You are now subscribed.

Thanks!

Chris



Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id MAA07075 for ietf-pkix-bks; Fri, 30 Apr 1999 12:11:01 -0700 (PDT)
Received: from gatekeeper.entrust.com (gatekeeper.entrust.com [204.101.128.170]) by mail.proper.com (8.8.8/8.8.5) with SMTP id MAA07071 for <[e-mail]>; Fri, 30 Apr 1999 12:10:59 -0700 (PDT)
Received: 	id OAB26636; Fri, 30 Apr 1999 14:53:42 -0400
Received: by gateway id <J96LB4B2>; Fri, 30 Apr 1999 14:56:00 -0400
Message-ID: <01E1D01C12D7D211AFC70090273D20B113C6DD@sothmxs06>
From: Sharon Boeyen <[e-mail]>
To: "'[e-mail]'" <[e-mail]>, "'[e-mail]'" <[e-mail]>, "'Blake Greenlee'" <[e-mail]>
Subject: Summary from April X.509 meeting 
Date: Fri, 30 Apr 1999 12:41:37 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.1960.3)
Content-Type: text/plain; charset="iso-8859-1"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

As you know, the meeting that resolved ballot comments on the PDAM to X.509
was held a couple of weeks ago. I'm still making the final revisions to the
text, based on meeting participant feedback to my drafts. The final text
that will be sent out for FPDAM (Final Proposed Draft Amendment) will be
available mid - late next week. In an effort to improve the flow of
communication between the X.509 group and other groups interested in that
work, I'm sending this as an INFORMAL summary of some of the changes to the
PDAM resulting from that meeting. Because the document is still under review
by attendees it is possible that the end result may differ slightly from the
way I've recorded here, but I think these are fairly representative
(editorial and other minor changes excluded).

Also, at the end I'll provide a summary of the defect reports currently
against X.509. I'm hoping to have the formal defect reports and the formal
Draft Technical Corrigenda (DTC) for all of these also available within a
week. You will notice that some of these defect reports are very old and
resolutions were agreed two years ago. However, some have not yet been
formally balloted as DTCs yet. 

ISO ballots on the FPDAM and on all DTCs for outstanding defect reports are
expected to be conducted over the summer months and resolution of those
ballots is expected to occur in October. 

When the documents have been completed and are available on a server, I'll
post a notice indicating where they can be found. 

------------------------------------------------------
FPDAM major changes:
1. X.509 will be re-titled "Public-Key and Attribute Certificate
Frameworks". It will be re-structured into 4 major sections: i) General
Introduction ii) Public-key certificate framework iii) Attribute certificate
framework iv) Directory use of public-key and attribute certificate
frameworks. Annex B will be deleted. 

2. CRLs - Clarified a number of issues relevant to 97 delta CRLs:
    - cert placed on hold and subsequently released (both on deltas) -
nothing need be carried forward to new base
    - cert revoked on delta and expires prior to issuance of new base -
revocation gets carried forward to new base
    - base crl pointed to be delta crl must be complete for given scope (ie
can be a full and complete CRL, distribution pt CRL etc)
   New enhancements in the area of delta CRLs
    - can issue delta CRLs for a base that was not published as a CRL
complete for scope  ('virtual' complete for scope CRL would be locally
constructed from published CRLs)
    - can identify base crl by its update time and/or crl number
    - new 'stream identifier' extension to enable unique identification of a
CRL among all CRLs issued by a particular issuer
   General CRL handling 
    - Annex M updated to align with new agreements and new extensions
including:
         - if basicConstraints extension is absent in a v3 cert it is an
end-entity cert (previously was type unknown)
         - no special case situation for ca or key compromise reason codes -
relying party checks crls for reason codes of interest - dependent on policy
   - Clarified text to state that revocation may be done directly by the
authority that issued the certs, indirectly by an authorized entity, or not
at all. Also clarified that CRLs are one mechanism but others are possible
(however they are outside the scope of 509)
(You'll find most of these changes reflected in the crlScope extension and
its description, revised description of deltaCRLIndicator extension, new
clause 12.6.4, revised annex M and new annex O) 
   
3. The syntax for privilegePolicy will not be standardized. Rather
privilegepolicy can be identified by an OID. The syntax from the PDAM and
corresponding SPIF syntax will both be included in an information annex
(Annex N) as examples only.

4. New certificate extensions defined (some of these are for privilege
management others are related to public-key certs in the 'traditional'
sense):
- delegator attribute identifier
- CRL stream identifier
- indirect issuer
- user notice
- SOA identifier
- base update time
- acceptable cert policies

5. New object class defined:
-  CP CPS

6. New attributes defined:
- attribute descriptor certificate
- certification practice statement
- certificate policy

7. New matching rules defined:
- owner issuer match
- authority ID match
- indirect issuer match
- delegator attribute id match
- owner attribute id match
- basic att constraints match
- attribute name constraints match
- time spec match
- attribute descriptor match
- acceptable cert policies match
- SOA id match

8. Assigned an oid to the special value "any policy" to be used in certs
issued from one CA to another CA.

9. Raised an issue regarding duplicate names and how to handle this problem
(mapping internal to external names raised in the issue to help generate
input)

10. Attribute certificate syntax - for v2 attribute certs owner and issuer
changed from CHOICE to SEQUENCE and constructs moved from inline to separate
constructs. Although in most cases a claimant will present both their
attribute cert and their public key cert that authenticates them, for those
cases where both are not provided, this change allows an attribute cert to
point to a public-key cert but also include general names that could help a
verifier find the public key cert in a repository.

11. Delegation path validation text re-written to accommodate new extensions
and provide a more comprehensive description of the role the extensions play
in the path validation.

---------------------------------------------------------
Defect reports - for ALL of these, resolutions have been agreed (either at
previous meetings or at this one) and will be documented as DTCs for ballot
shortly, or have already completed and are formally approved: (DR ## is the
Defect Report number, TC means completed ballot and formally approved, DTC
means approved for ballot). I'm only listing those against the 97 edition

DR 169  permutable property for PKCS  DTC 2
DR 183  public key usage                    TC 1
DR 184  certification path                     Rejected - no change
DR 185  forward & reverse certificates   DTC 4 
DR 200  crl dp & full crls                      DTC 3
DR 201  issuing dist pt                        DTC 3
DR 204  crl and expired revoked cert    DTC 5
DR 207  algorithm object class            DTC 6
DR 212  crl matching rules                  DTC 3
DR 213  crl matching rules                  DTC 3
DR 214  use of term 'canonical'            DTC 6
DR 216  certificate assertion                Rejected - no change
DR 218  certificate policy match           DTC 3
DR 219  absence of basic constraints   DTC 3
DR 220  crl version number                   DTC 3
DR 222  policy mapping                       DTC 7

On DR 219 and 220, I know these are of particular interest to PKIX. I
haven't written 
the formal documents yet, but to summarize:

DR 219 - the resolution agreed for ballot is that for a version 3
certificate, if the certificate does not contain a basicConstraints
extension, the certificate is to be considered an end-entity certificate. We
decided that the goal can be achieved with this resolution and that we won't
unnecessarily force the 'fattening' of ALL v3 certs by mandating the
extension always be present (we see that as the role of profiles).

DR 220 - In the list of notes following the ASN.1 in clause 11.2, note 3
will be modified so that rather than mandating that the version component
"shall" be absent if a CRL contains no critical extensions, the version
component "may" be absent....

Apologies for the length of this message, but I hope the information is
helpful to people who did not attend the 509 meeting when reviewing its
output. Also, I've most certainly forgotten some other technical changes
that were made so if something isn't listed here it isn't that I don't think
it was important, but that the memory is fading........

Sharon
 





Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id JAA05638 for ietf-pkix-bks; Fri, 30 Apr 1999 09:06:56 -0700 (PDT)
Received: from aum (ip11.proper.com [165.227.249.11]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id JAA05634 for <[e-mail]>; Fri, 30 Apr 1999 09:06:55 -0700 (PDT)
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.37 (Beta)
Date: Fri, 30 Apr 1999 09:05:57 -0700
To: [e-mail]
From: Paul Hoffman / IMC <[e-mail]>
Subject: Re: Confirmation for subscribe ietf-pkix
In-Reply-To: <[e-mail]>
References: < <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

At 11:53 AM 4/30/99 -0400, Christopher Stacy wrote:
>Looks kinda like a Majordomo bug, to me.

No, it is a bug in the human who sent in the request. :-) You added the 
name of the mailing list to the end of your "subscribe" request, even 
though the instructions do not say you should do that.

>(Not yet being subscribed to this list, I didn't even know it was doing that.)

You are now subscribed.

>Presumably this will get the attention of the list maintainer, though!

Yes, sending administrative messages that are read by all 1107 members of 
the mailing list will get my attention.

--Paul Hoffman, Director
--Internet Mail Consortium


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id IAA05499 for ietf-pkix-bks; Fri, 30 Apr 1999 08:51:07 -0700 (PDT)
Received: from I1.pilgrim.com (i1.pilgrim.com [206.3.211.10]) by mail.proper.com (8.8.8/8.8.5) with SMTP id IAA05489; Fri, 30 Apr 1999 08:51:05 -0700 (PDT)
Received: from BONK.pilgrim.com (bonk [206.3.211.31]) by I1.pilgrim.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via SMTP id LAA17188; Fri, 30 Apr 1999 11:53:20 -0400
Date: Fri, 30 Apr 1999 11:53:20 -0400
Message-Id: <[e-mail]>
From: Christopher Stacy <[e-mail]>
To: [e-mail]
CC: [e-mail], [e-mail], [e-mail]
In-reply-to:  <[e-mail]> ([e-mail])
Subject: Re: Confirmation for subscribe ietf-pkix
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Looks kinda like a Majordomo bug, to me.

(Not yet being subscribed to this list, I didn't even know it was doing that.)

Presumably this will get the attention of the list maintainer, though!

Sorry for the spam.



Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id IAA05099 for ietf-pkix-bks; Fri, 30 Apr 1999 08:09:36 -0700 (PDT)
Received: from ietf.org (odin.ietf.org [132.151.1.176]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id IAA05095 for <[e-mail]>; Fri, 30 Apr 1999 08:09:35 -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 LAA00820; Fri, 30 Apr 1999 11:10:46 -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-00.txt
Date: Fri, 30 Apr 1999 11:10:45 -0400
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

--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)	: R. Housley, S. Farrell
	Filename	: draft-ietf-pkix-ac509prof-00.txt
	Pages		: 31
	Date		: 29-Apr-99
	
Authorization support is required for various Internet
protocols, for example, TLS, CMS and their consumers,
and others. The X.509 AttributeCertificate provides a
structure that can form the basis for such services
([X.509], [XPDAM]). This specification defines two
profiles (basic and proxiable) for the use of X.509 
AttributeCertificates to provide such authorization
services.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-pkix-ac509prof-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-ac509prof-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-ac509prof-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-ac509prof-00.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-pkix-ac509prof-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 majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id HAA04973 for ietf-pkix-bks; Fri, 30 Apr 1999 07:58:40 -0700 (PDT)
Received: from Tandem.com (suntan.tandem.com [192.216.221.8]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id HAA04969; Fri, 30 Apr 1999 07:58:39 -0700 (PDT)
Received: from exccup-conn01.mis.tandem.com (exccup-conn01.mis.tandem.com [130.252.226.231]) by Tandem.com (8.9.3/2.0.1) with ESMTP id IAA29768; Fri, 30 Apr 1999 08:00:23 -0700 (PDT)
Received: by exccup-conn01.mis.tandem.com with Internet Mail Service (5.5.2559.0) id <JS2VRP10>; Fri, 30 Apr 1999 08:00:23 -0700
Message-ID: <[e-mail]>
From: "Kurn, David" <[e-mail]>
To: "'[e-mail]'" <[e-mail]>, [e-mail], [e-mail]
Subject: RE: Confirmation for subscribe ietf-pkix
Date: Fri, 30 Apr 1999 08:00:22 -0700
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2559.0)
Content-Type: text/plain; charset="ISO-8859-1"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

WHat is this?  And why is this message sent to the entire list?  HELP

And what does it mean to send "the followoing commands"?  As a subject?  In
the body of the message?  Via what protocol?

Not a very clear set of directions.

D Kurn

-----Original Message-----
From: [e-mail] [mailto:[e-mail]]
Sent: Friday, April 30, 1999 7:20 AM
To: [e-mail]; [e-mail]
Subject: Confirmation for subscribe ietf-pkix


--

Someone (possibly you) has requested that your email address be added
to or deleted from the mailing list "[e-mail]".

If you really want this action to be taken, please send the following
commands (exactly as shown) back to "[e-mail]":

auth df987f1a subscribe ietf-pkix [e-mail] [e-mail]

Make *very* sure that all goes on one line; your mail client might try hard
to break the line in two.

If you do not want to this action taken, just ignore this message and
no action will be taken.

If you have any questions about the policy of the list owner, please
contact "[e-mail]".

Thanks!

[e-mail]


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id HAA04730 for ietf-pkix-bks; Fri, 30 Apr 1999 07:19:51 -0700 (PDT)
Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id HAA04723; Fri, 30 Apr 1999 07:19:48 -0700 (PDT)
Date: Fri, 30 Apr 1999 07:19:48 -0700 (PDT)
Message-Id: <[e-mail]>
To: [e-mail], [e-mail]
From: [e-mail]
Subject: Confirmation for subscribe ietf-pkix
Reply-To: [e-mail]
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

--

Someone (possibly you) has requested that your email address be added
to or deleted from the mailing list "[e-mail]".

If you really want this action to be taken, please send the following
commands (exactly as shown) back to "[e-mail]":

auth df987f1a subscribe ietf-pkix [e-mail] [e-mail]

Make *very* sure that all goes on one line; your mail client might try hard
to break the line in two.

If you do not want to this action taken, just ignore this message and
no action will be taken.

If you have any questions about the policy of the list owner, please
contact "[e-mail]".

Thanks!

[e-mail]


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id JAA21963 for ietf-pkix-bks; Thu, 29 Apr 1999 09:39:59 -0700 (PDT)
Received: from caladan.verisign.com (caladan.verisign.com [205.180.232.21]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id JAA21957 for <[e-mail]>; Thu, 29 Apr 1999 09:39:57 -0700 (PDT)
Received: from mentat.verisign.com by caladan.verisign.com (8.8.5/BCH1.5) id JAA28396; Thu, 29 Apr 1999 09:37:02 -0700 (PDT)
Received: from newman.verisign.com by mentat.verisign.com (8.8.5/BCH1.0) id JAA11100; Thu, 29 Apr 1999 09:41:04 -0700 (PDT)
Received: by newman.verisign.com with Internet Mail Service (5.5.2448.0) id <J6LWYJRR>; Thu, 29 Apr 1999 09:41:05 -0700
Message-ID: <[e-mail]>
From: Michael Myers <[e-mail]>
To: "'Denis Pinkas'" <[e-mail]>, Stephen Kent <[e-mail]>
Cc: [e-mail]
Subject: RE: OSCP BIG BANG
Date: Thu, 29 Apr 1999 09:41:04 -0700
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2448.0)
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by mail.proper.com id JAA21958
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Denis,

I understand Steve is on vacation this week.  But I do wish to clarify -08
against your request.

You are restating a request for a requirement that we discussed during the
original last call.  Namely, a mandated relocation of AIA information from
the subject certificate to the CA certificate.  We debated this issue on the
list during the original last call with the resolution that the text remains
as written.  In constrast, Steve asked for additional clarity and precision
regarding an existing requirement; this we responded to.

We are not in the mode at this very late stage of introducing new
requirements or reopening issues which were previously resolved.  That work
has been done.  My thanks to all who provided their time and energy to the
effort.

Mike


> -----Original Message-----
> From: Denis Pinkas [mailto:[e-mail]]
> Sent: Wednesday, April 28, 1999 6:45 AM
> To: Stephen Kent
> Cc: [e-mail]
> Subject: OSCP BIG BANG
> 
> 
> The original title was "Re: WG Last call, redux".
> 
> Steve,
> 
> Thanks for giving the hint for the change. :-)
> 
> In the previous text, as it will be explained in detail, we 
> were somewhat
> inconsistent having a SHALL followed by a MAY.
> 
> The new text is proposing to keep the SHALL and change the 
> MAY into a MUST.
> I am basically proposing to change the SHALL into a SHOULD 
> and keep the MAY.
> 
> Both solutions are consistent. :-)
> 
> It seems now the Pandora box is re-opened  :-) and we have a 
> chance to fix the
> issue.
> 
> First, let me duplicate the section from the version 08 so 
> that people may save
> time, if they wish to follow this thread.
> 
> In version -08
> 
> 4.  Functional Requirements
> 
> 4.1  Certificate Content
> 
> In order to convey to OCSP clients a well-known point of 
> information access,
> CAs SHALL provide the capability to include the 
> AuthorityInfoAccess extension
> (defined in [RFC 2459], section 4.2.2.1) in certificates that 
> can be checked
> using OCSP.  Alternatively, the accessLocation for the OCSP 
> provider may be
> configured locally at the OCSP client.
> 
> CAs that support an OCSP service, either hosted locally or 
> provided by an
> Authorized Responder, MUST provide for the inclusion of a value for a
> uniformResourceIndicator (URI) accessLocation and the OID 
> value id-ad-ocsp for
> the accessMethod in the AccessDescription SEQUENCE.
> 
> The value of the accessLocation field in the subject 
> certificate defines the
> transport (e.g. HTTP) used to access the OCSP responder and 
> may contain other
> transport dependent information (e.g. a URL).
> 
> 
> In version 07 we had:
> 
> 
> 4.  Functional Requirements
> 
> 4.1  Certificate Content
> 
> In order to convey to OCSP clients a well-known point of 
> information access,
> CAs SHALL provide the capability to include the 
> AuthorityInfoAccess extension
> (defined in [PKIX1], section 4.2.2.1) in certificates that 
> can be checked using
> OCSP.  Alternatively, the accessLocation for the OCSP provider may be
> configured locally at the OCSP client.
> 
> CAs that support an OCSP service, either hosted locally or 
> provided by an
> Authorized Responder, MAY provide a value for a
> uniformResourceIndicator (URI) accessLocation and the OID 
> value id-ad-ocsp for
> the accessMethod in the AccessDescription SEQUENCE.
> 
> The value of the accessLocation field in the subject 
> certificate defines the
> transport (e.g. HTTP) used to access the OCSP responder and 
> may contain other
> transport dependent information (e.g. a URL).
> 
> (...)
> 
> The « MAY » in the second paragraph has been changed into a « MUST ».
> 
> Leaving the text out for a moment, let us consider the 
> following scenario:
> 
> A CA is started up with a CRL scheme. After one year of 
> operation, the CA
> wishes to offer an *additional* service available for *all* 
> the certificates,
> i.e. an On-line Certificate Status (OCS) Service.
> 
> For doing so, there is one single option: to revoke all the current
> certificates and re-issue new certificates with the 
> appropriate extension.
> 
> This is a BIG BANG situation. :-(
> 
> The consequences are quite important, among them, the size of 
> the CRLs is going
> to increase dramatically (there is no reason to stop that service).
> 
> The concern is that a smooth transition cannot occur. What 
> can we do ? Is there
> a panacea to this problem ?
> 
> Let us now take a closer look at the text. The last sentence 
> of the fist
> paragraph from 4.1 says: « Alternatively, the accessLocation 
> for the OCSP
> provider *may* be configured locally at the OCSP client. ». 
> If this is the
> case, then the extension is not used. If someone wanted to 
> deploy a system by
> configuring locally the system, CAs would nevertheless be 
> mandated to support
> the extension.  :-(
> 
> This is one argument for having SHALL changed into SHOULD, 
> i.e. « In order to
> convey to OCSP clients a well-known point of information 
> access, CAs SHOULD
> provide the capability to include the AuthorityInfoAccess extension »
> 
> When the local configuration is NOT used, let us now attempt 
> to solve the BIG
> BANG issue, and let us take a look at the text from RFC 2459.
> 
> « 4.2.2.1  Authority Information Access
> 
> The authority information access extension indicates how to access CA
> information and services for the issuer of the certificate in 
> which the
> extension appears. Information and services may include 
> on-line validation
> services and CA policy data.  (The location of CRLs is not 
> specified in this
> extension; that information is provided by the cRLDistributionPoints
> extension.)  This extension may be included in subject or CA 
> certificates, and
> it MUST be non-critical. »
> 
> The text allows the extension to be placed in CA certificate. 
> To my knowledge,
> a self-signed certificate is also a CA certificate. So it is 
> possible to have
> that extension is a self-signed certificate. The advantage is 
> two folds:
> 
> 1) the content of a self-signed certificate may change 
> without affecting the
> content of the leaf certificates or of the cross-certificates.
> 
> 2) since the extension is not in a leaf certificate, then it 
> makes leaf
> certificates smaller (remember low-fat leaf certificates ?)
> 
> We have defined in CMP a protocol to allow a certificate 
> rollover for trust
> points, so we know how to handle the renewal of a self-signed 
> certificate.
> 
> Now, I still guess that some people would like the current 
> text when a CA is
> started from the very beginning with an OCS service or when 
> that service is
> gradually offered to renewed certificates. So I would now 
> propose some text
> that handles all the three cases. Here is the new proposal 
> for a text to fit
> under 4.1.
> 
> 
> « 4.1  Certificate Content
> 
>  In order to convey to OCSP clients a well-known point of 
> information access,
> CAs SHOULD provide the capability to include the 
> AuthorityInfoAccess extension
> (defined in [RFC2459], section 4.2.2.1) either in every 
> certificate that can be
> checked using OCSP or in a self-signed certificate.  
> Alternatively, the
> accessLocation for the OCSP provider may be configured 
> locally at the OCSP
> client.
> 
> CAs that support an OCSP service, either hosted locally or 
> provided by an
> Authorized Responder, MAY provide for the inclusion of a value for a
> uniformResourceIndicator (URI) accessLocation and the OID 
> value id-ad-ocsp for
> the accessMethod in the AccessDescription SEQUENCE.
> 
> The value of the accessLocation field in the subject 
> certificate defines the
> transport (e.g. HTTP) used to access the OCSP responder and 
> may contain other
> transport dependent information (e.g. a URL). »
> 
> 
> Note: the other major change around this topic is in section 5.2.2.2
> Authorized Responders:
> 
> 
> In version 08 we have:
> 
>  (...)
> 
> 5.2.2.2  Authorized Responders
> 
>    The key that signs a certificate's status information need 
> not be the
>    same key that signed the certificate. It is necessary however to
>    ensure that the entity signing this information is authorized to do
>    so.  Therefore, a certificate's issuer MUST either sign the OCSP
>    responses itself or it MUST explicitly designate this authority to
>    another entity.  OCSP signing delegation SHALL be designated by the
>    inclusion of id-kp-OCSPSigning in an extendedKeyUsage certificate
>    extension included in the OCSP response signer's certificate.  This
>    certificate MUST be issued directly by the CA that issued the
>    certificate in question.
> 
> 
>    id-kp-OCSPSigning OBJECT IDENTIFIER ::= {id-kp 9}
> 
>    Systems or applications that rely on OCSP responses MUST be capable
>    of detecting and enforcing use of the id-ad-ocspSigning value as
>    described above. They MAY provide a means of locally 
> configuring one
>    or more OCSP signing authorities, and specifying the set of CAs for
>    which each signing authority is trusted. They MUST reject the
>    response if the certificate required to validate the 
> signature on the
>    response fails to meet at least one of the following criteria:
> 
>    1. Matches a local configuration of OCSP signing authority for the
>     certificate in question; or
> 
>    2. Is the certificate of the CA that issued the certificate in
>     question; or
> 
>    3. Includes a value of id-ad-ocspSigning in an ExtendedKeyUsage
>     extension and is issued by the CA that issued the certificate in
>     question."
> 
>    Additional acceptance or rejection criteria may apply to either the
>    response itself or to the certificate used to validate the 
> signature
>    on the response.
> 
> 
> While in version -07 we have:
> 
> 5.2.2.2  Authorized Responders
> 
>    The key that signs a certificate's status information need 
> not be the
>    same key that signed the certificate. A certificate's issuer MAY
>    explicitly delegate OCSP signing authority by issuing a certificate
>    including an extendedKeyUsage extension in the OCSP signer's
>    certificate containing the value id-kp-OCSPSigning.
> 
>    id-kp-OCSPSigning OBJECT IDENTIFIER ::= {id-kp 9}
> 
> 
> Denis
> 
> 
> > Several folks pointed out that I made the re-opening of 
> last call into a
> > treasure hunt!  Sorry 'bout that.  I am away from the 
> office and not easily
> > able to provide a diff, but I can describe the goal for the 
> changes, which
> > resulted in both editorial and sunstantive modifications to 
> the text.
> >
> > The concern I raised with the OCSP authors was that it was 
> not clear what
> > the hard and fast requirements were for CAs and clients 
> with regard to
> > supporting three different ways that OCSP can be "enabled." 
> I felt it
> > important to ensure that CAs and clients that claim 
> comformance would
> > provide a set of confuguration controls that would allow 
> interoperability,
> > if properly configured. So, the resvied text tries to make 
> this perfectly
> > clear. The final form of the requirements, with some abstraction, is
> > sumarized below:
> >
> >         - an OCSP-compliant CA SHALL be capable of issuing 
> OCSP responses
> > that are signed ditrectly by the CA, and MUST be able to 
> designate an OCSP
> > responder by issuing an appropriately marked certificate 
> directly to the
> > responder.  the choice or direct vs. delegated OCSP 
> responses is a local,
> > administrative option. the CA also SHALL be capable of 
> putting the AIA
> > extension into certs when it is the intent that these certs 
> will be checked
> > via OCSP, and MUST be capable of populating this extension 
> with the OID
> > specifying OCSP access method and a URI for such access.  
> (This last part
> > was changed from a MAy to a MUST, which seems reasonable to 
> ensure the goal
> > cited above.)
> >
> >         - an OCSP-compliant client MUST be able to accept 
> OCSP responses
> > via three different means: responses signed by the CA that 
> issued the cert
> > in question, responses signed by a responder directly 
> designated by that
> > CA, or via a locally designated responder.  It is a local 
> administrative
> > choice as to which of these options if enabled. If local 
> designation is
> > enabled, vendors have choices as to how fancy it gets, 
> e.g., how many OCSP
> > responders are specified, how one knows which ones are authorized to
> > provide status for which sets of certs, etc.
> >
> > Steve
> 


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id FAA19717 for ietf-pkix-bks; Thu, 29 Apr 1999 05:15:44 -0700 (PDT)
Received: from ietf.org (odin.ietf.org [132.151.1.176]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id FAA19713 for <[e-mail]>; Thu, 29 Apr 1999 05:15:42 -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 IAA12120; Thu, 29 Apr 1999 08:16:47 -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-ocsp-08.txt
Date: Thu, 29 Apr 1999 08:16:46 -0400
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

--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		: X.509 Internet Public Key Infrastructure Online Certificate Status Protocol - OCSP
	Author(s)	: C. Adams, M. Myers, A. Malpani, R. Ankney, S. Galperin
	Filename	: draft-ietf-pkix-ocsp-08.txt
	Pages		: 21
	Date		: 26-Apr-99
	
This document specifies a protocol useful in determining the current
status of a digital certificate without requiring CRLs. Additional
mechanisms addressing PKIX operational requirements are specified in
separate documents.
 
An overview of the protocol is provided in section 3. Functional
requirements are specified in section 4. Details of the protocol are
in section 5. We cover security issues with the protocol in section
6. Appendix A defines OCSP over HTTP, appendix B accumulates ASN.1
syntactic elements and appendix C specifies the mime types for the
messages.

The key words 'MUST', 'MUST NOT', 'REQUIRED', 'SHALL', 'SHALL NOT',
'SHOULD', 'SHOULD NOT', 'RECOMMENDED', 'MAY', and 'OPTIONAL' in this
document (in uppercase, as shown) are to be interpreted as described
in [RFC2119].

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-pkix-ocsp-08.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-ocsp-08.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-ocsp-08.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-ocsp-08.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-pkix-ocsp-08.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID:	<[e-mail]>

--OtherAccess--

--NextPart--




Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id EAA19319 for ietf-pkix-bks; Thu, 29 Apr 1999 04:13:44 -0700 (PDT)
Received: from popmail.inbox.se (popmail.inbox.se [193.12.72.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id EAA19315 for <[e-mail]>; Thu, 29 Apr 1999 04:13:42 -0700 (PDT)
Received: from stefan2 (accurata.inbox.se [193.12.72.24]) by popmail.inbox.se (8.9.3/8.9.3) with SMTP id NAA04258; Thu, 29 Apr 1999 13:15:13 +0200
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: Windows Eudora Pro Version 3.0 (32)
Date: Thu, 29 Apr 1999 13:15:14 +0200
To: [e-mail], [e-mail]
From: Stefan Santesson <[e-mail]>
Subject: Re: Closure of the QC biometric issue
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 mail.proper.com id EAA19316
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Thanks Peter,

I have also got a note from Magnus Nyström, RSA labs, pointing this out.

He proposed that this part should be changed into:

TypeOfBiometricData ::= CHOICE {
     predefinedBiometricType    PredefinedBiometricType,
     biometricDataOid           OBJECT IDENTIFIER } 

PredefinedBiometricType ::= INTEGER {
     picture(0),handwritten-signature(1)}
     (picture|handwritten-signature,...)

Is that OK to you?

/Stefan

At 10:48 AM 4/29/99, Peter Gutmann wrote:
>>PLEASE REVIEW THE FOLLOWING ASN.1 STRUCTURE AND COMMENT IN CASE OF ERRORS:
>>--------------------------------------------------------------------------
>>[...]
>>
>>TypeOfBiometricData ::== CHOICE {
>>     predefinedBiometricType    [0] INTEGER,
>>     biometricDataOid           [1] OBJECT IDENTIFIER }
>
>Not really an error but a style and ease-of-use issue: the tags are already
>distinct so there's no need to tag these items, which also means you don't
hide
>ASN.1 type information behind opaque implicit tags.
>
>Peter.
>
-------------------------------------------------------------------
Stefan Santesson                <[e-mail]>
Accurata Systemsäkerhet AB      http://www.accurata.se
Slagthuset                      Tel. [phone]              
211 20  Malmö                   Fax. [phone]              
Sweden                        Mobile [phone]

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


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id DAA18967 for ietf-pkix-bks; Thu, 29 Apr 1999 03:21:08 -0700 (PDT)
Received: from popmail.inbox.se (popmail.inbox.se [193.12.72.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id DAA18963 for <[e-mail]>; Thu, 29 Apr 1999 03:21:07 -0700 (PDT)
Received: from stefan2 (accurata.inbox.se [193.12.72.24]) by popmail.inbox.se (8.9.3/8.9.3) with SMTP id MAA03711; Thu, 29 Apr 1999 12:22:41 +0200
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: Windows Eudora Pro Version 3.0 (32)
Date: Thu, 29 Apr 1999 12:22:43 +0200
To: Peter Sylvester <[e-mail]>, [e-mail]
From: Stefan Santesson <[e-mail]>
Subject: Re: Closure of the QC biometric issue
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 mail.proper.com id DAA18964
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Peter,

At 11:21 AM 4/28/99 +0200, Peter Sylvester wrote:
>
>----- Begin Included Message -----
>
>>From [e-mail] Wed Apr 28 11:05:38 1999
>Date: Wed, 28 Apr 1999 08:59:57 +0200
>> -Source data format information has NOT been included by several reasons.
>> If the sourceDataURI are used then this information is already covered. If
>> sourceDataURI is NOT included then the source data issue have to be handled
>> outside of the certificate anyway, thus making a source data declaration in
>> the certificate of dubious value.
>>
>> -SourceDataUri has been included (as OPTIONAL) since it can be shown that
>> some PKI:s could benefit from this value without causing troubles for other
>> PKI:s.
>>
>How do you calculate the hash of source data starting from an SourceDataUri? 
>Do you take the data, a bitmap, the mime encapsulated data? Do you include
the
>mime type in the hash? Are there other attributes, creation date of the
document,
>etc.

Yes, this is typically something that we have to adress in the text (not
written yet).

If you have a text proposal, I would be very happy to receive it.

My opinion is that the hash should be calculated on the actual data. E.g.
If you have a JPEG image you calculate the hash on the file content, but
not on the filename etc. I'm not sure how to put this in writing so I
welcome suggestions on suitable text wordings.

/Stefan 

>
-------------------------------------------------------------------
Stefan Santesson                <[e-mail]>
Accurata Systemsäkerhet AB      http://www.accurata.se
Slagthuset                      Tel. [phone]              
211 20  Malmö                   Fax. [phone]              
Sweden                        Mobile [phone]

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


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id DAA18903 for ietf-pkix-bks; Thu, 29 Apr 1999 03:12:15 -0700 (PDT)
Received: from popmail.inbox.se (popmail.inbox.se [193.12.72.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id DAA18898 for <[e-mail]>; Thu, 29 Apr 1999 03:12:13 -0700 (PDT)
Received: from stefan2 (accurata.inbox.se [193.12.72.24]) by popmail.inbox.se (8.9.3/8.9.3) with SMTP id MAA03619 for <[e-mail]>; Thu, 29 Apr 1999 12:13:43 +0200
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: Windows Eudora Pro Version 3.0 (32)
Date: Thu, 29 Apr 1999 12:13:45 +0200
To: [e-mail]
From: Stefan Santesson <[e-mail]>
Subject: Minor typing error in RFC 2459
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 mail.proper.com id DAA18899
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

In RFC 2459, Appendix C (Page 116), there is a minor typing error in the
following text:

  "The character string type UTF8String will be introduced in the 1998
   version of ASN.1.  UTF8String is a universal type and has been
   assigned tag number 12.  The content of UTF8String was defined by RFC
   2044 and updated in RFC 2279, "UTF-8, a transformation Format of ISP
   10646."  ISO is expected to formally add UTF8String to the list of
   choices for DirectoryString in 1998 as well."


It should be "ISO 10646", not "ISP 10646"

/Stefan
-------------------------------------------------------------------
Stefan Santesson                <[e-mail]>
Accurata Systemsäkerhet AB      http://www.accurata.se
Slagthuset                      Tel. [phone]              
211 20  Malmö                   Fax. [phone]              
Sweden                        Mobile [phone]

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


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id PAA00231 for ietf-pkix-bks; Wed, 28 Apr 1999 15:56:10 -0700 (PDT)
Received: from dsg1.OpenDirectory.com.au ([203.108.249.145]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id PAA00219 for <[e-mail]>; Wed, 28 Apr 1999 15:55:22 -0700 (PDT)
Received: by DSG1 with Internet Mail Service (5.0.1458.49) id <JYG8RNB8>; Thu, 29 Apr 1999 08:56:28 +1000
Message-ID: <D1A949D4508DD1119C8100400533BEDC0BE99B@DSG1>
From: Alan Lloyd <[e-mail]>
To: "'Moshe Litvin'" <[e-mail]>, Alan Lloyd <[e-mail]>
Cc: [e-mail]
Subject: RE: SEIS: Re: Certificates, Directories, and Distinguished Names
Date: Thu, 29 Apr 1999 08:56:25 +1000
X-Priority: 3
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.0.1458.49)
Content-Type: text/plain
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Moshe,

I understand your comment and commercially we deal with that  - but with
ASN.1 and encoding schemes - if the implementation is not robust or has
good exit strategies then protocol/syntax decoding of unknown inputs can
cause serious fails.
For instance I think a good test of an LDAP server is to log in without
name or password, construct an entry in the client say of 10megabytes
and then just add it to the server (create the entry).. in some cases
the protocol processing code, the ASN.1 decode  or the object processors
(even before you get to access control checks, etc ) in the server will
explode.
My point is though that it sometime easier to implement a full range of
attributes, specifically naming  and string attribute types, than to
have exits which may fail or if they get called - just means that that
the attributes have to be implemented anyway.

regards alan

> -----Original Message-----
> From:	Moshe Litvin 
> Sent:	Tuesday, April 27, 1999 6:29 PM
> To:	Alan Lloyd
> Cc:	[e-mail]
> Subject:	Re: SEIS: Re: Certificates, Directories, and
> Distinguished Names
> 
> 
> 
> Alan Lloyd wrote:
> 
> <snip>
> 
> >
> >         Let me highlight some issues with 2459.
> 
> <snip>
> 
> >         3. Section 4.1.2.4  -last para page 19 - " The Telexstring
> and
> > Universal string ... Certificate Users SHOULD" .. this magic word
> > "Should"..
> >         There is no sure way of knowing what encoding is being rxd
> by an
> > implementation and if they do not decode strings correctly the
> > implementations will fail or crash. If building a commercial robust
> PKIX
> > implementation - one would expect a profile - if there are known
> uses of
> > the scheme out there, to say all recieving certificate using systems
> > must support this. ie a profile must dictate robustness to current
> > implementations - not leave an implementor with a guess and bugs.
> >
> 
> I disagree. Security software should always check its inputs carefully
> (assuming it may be hostile). No need to for special treatment here in
> regards for crashes.
> 
> regards,
> 
>     Moshe
>  << File: Card for Moshe Litvin >> 


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id PAA00102 for ietf-pkix-bks; Wed, 28 Apr 1999 15:47:04 -0700 (PDT)
Received: from mail.student.auckland.ac.nz (mail.student.auckland.ac.nz [130.216.35.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id PAA29997 for <[e-mail]>; Wed, 28 Apr 1999 15:47:01 -0700 (PDT)
Received: from cs26.cs.auckland.ac.nz ([e-mail] [130.216.36.9]) by mail.student.auckland.ac.nz (8.8.6/8.8.6/cs-master) with SMTP id KAA31016; Thu, 29 Apr 1999 10:48:28 +1200 (NZST) (sender [e-mail])
Received: by cs26.cs.auckland.ac.nz (relaymail v0.9) id <92533970822447>; Thu, 29 Apr 1999 10:48:28 (NZST)
From: [e-mail] (Peter Gutmann)
To: [e-mail], [e-mail]
Subject: Re: Closure of the QC biometric issue
Reply-To: [e-mail]
X-Charge-To: pgut001
X-Authenticated: relaymail v0.9 on cs26.cs.auckland.ac.nz
Date: Thu, 29 Apr 1999 10:48:28 (NZST)
Message-ID: <[e-mail]>
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

>PLEASE REVIEW THE FOLLOWING ASN.1 STRUCTURE AND COMMENT IN CASE OF ERRORS:
>--------------------------------------------------------------------------
>[...]
>
>TypeOfBiometricData ::== CHOICE {
>     predefinedBiometricType    [0] INTEGER,
>     biometricDataOid           [1] OBJECT IDENTIFIER }

Not really an error but a style and ease-of-use issue: the tags are already
distinct so there's no need to tag these items, which also means you don't hide
ASN.1 type information behind opaque implicit tags.

Peter.



Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id GAA25159 for ietf-pkix-bks; Wed, 28 Apr 1999 06:43:11 -0700 (PDT)
Received: from clbull.frcl.bull.fr (clbull.frcl.bull.fr [129.182.1.20]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id GAA25154 for <[e-mail]>; Wed, 28 Apr 1999 06:43:07 -0700 (PDT)
Received: from k2.frcl.bull.fr (k2.frcl.bull.fr [129.182.100.2]) by clbull.frcl.bull.fr (8.9.1a/8.9.1) with ESMTP id PAA41022; Wed, 28 Apr 1999 15:43:54 +0200
Received: from bull.net (frcls6118.frcl.bull.fr [129.182.109.213]) by k2.frcl.bull.fr (AIX4.2/UCB 8.7/8.7) with ESMTP id PAA25290; Wed, 28 Apr 1999 15:43:54 +0200 (DFT)
Message-ID: <[e-mail]>
Date: Wed, 28 Apr 1999 15:45:02 +0200
From: Denis Pinkas <[e-mail]>
Organization: Bull
X-Mailer: Mozilla 4.06 [fr] (Win95; I)
MIME-Version: 1.0
To: Stephen Kent <[e-mail]>
CC: [e-mail]
Subject: OSCP BIG BANG
References: <v04020a15b34509844f3d@[128.33.238.34]> <v04020a25b34641c27a7f@[128.33.238.34]>
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 8bit
Content-Transfer-Encoding: 8bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

The original title was "Re: WG Last call, redux".

Steve,

Thanks for giving the hint for the change. :-)

In the previous text, as it will be explained in detail, we were somewhat
inconsistent having a SHALL followed by a MAY.

The new text is proposing to keep the SHALL and change the MAY into a MUST.
I am basically proposing to change the SHALL into a SHOULD and keep the MAY.

Both solutions are consistent. :-)

It seems now the Pandora box is re-opened  :-) and we have a chance to fix the
issue.

First, let me duplicate the section from the version 08 so that people may save
time, if they wish to follow this thread.

In version -08

4.  Functional Requirements

4.1  Certificate Content

In order to convey to OCSP clients a well-known point of information access,
CAs SHALL provide the capability to include the AuthorityInfoAccess extension
(defined in [RFC 2459], section 4.2.2.1) in certificates that can be checked
using OCSP.  Alternatively, the accessLocation for the OCSP provider may be
configured locally at the OCSP client.

CAs that support an OCSP service, either hosted locally or provided by an
Authorized Responder, MUST provide for the inclusion of a value for a
uniformResourceIndicator (URI) accessLocation and the OID value id-ad-ocsp for
the accessMethod in the AccessDescription SEQUENCE.

The value of the accessLocation field in the subject certificate defines the
transport (e.g. HTTP) used to access the OCSP responder and may contain other
transport dependent information (e.g. a URL).


In version 07 we had:


4.  Functional Requirements

4.1  Certificate Content

In order to convey to OCSP clients a well-known point of information access,
CAs SHALL provide the capability to include the AuthorityInfoAccess extension
(defined in [PKIX1], section 4.2.2.1) in certificates that can be checked using
OCSP.  Alternatively, the accessLocation for the OCSP provider may be
configured locally at the OCSP client.

CAs that support an OCSP service, either hosted locally or provided by an
Authorized Responder, MAY provide a value for a
uniformResourceIndicator (URI) accessLocation and the OID value id-ad-ocsp for
the accessMethod in the AccessDescription SEQUENCE.

The value of the accessLocation field in the subject certificate defines the
transport (e.g. HTTP) used to access the OCSP responder and may contain other
transport dependent information (e.g. a URL).

(...)

The « MAY » in the second paragraph has been changed into a « MUST ».

Leaving the text out for a moment, let us consider the following scenario:

A CA is started up with a CRL scheme. After one year of operation, the CA
wishes to offer an *additional* service available for *all* the certificates,
i.e. an On-line Certificate Status (OCS) Service.

For doing so, there is one single option: to revoke all the current
certificates and re-issue new certificates with the appropriate extension.

This is a BIG BANG situation. :-(

The consequences are quite important, among them, the size of the CRLs is going
to increase dramatically (there is no reason to stop that service).

The concern is that a smooth transition cannot occur. What can we do ? Is there
a panacea to this problem ?

Let us now take a closer look at the text. The last sentence of the fist
paragraph from 4.1 says: « Alternatively, the accessLocation for the OCSP
provider *may* be configured locally at the OCSP client. ». If this is the
case, then the extension is not used. If someone wanted to deploy a system by
configuring locally the system, CAs would nevertheless be mandated to support
the extension.  :-(

This is one argument for having SHALL changed into SHOULD, i.e. « In order to
convey to OCSP clients a well-known point of information access, CAs SHOULD
provide the capability to include the AuthorityInfoAccess extension »

When the local configuration is NOT used, let us now attempt to solve the BIG
BANG issue, and let us take a look at the text from RFC 2459.

« 4.2.2.1  Authority Information Access

The authority information access extension indicates how to access CA
information and services for the issuer of the certificate in which the
extension appears. Information and services may include on-line validation
services and CA policy data.  (The location of CRLs is not specified in this
extension; that information is provided by the cRLDistributionPoints
extension.)  This extension may be included in subject or CA certificates, and
it MUST be non-critical. »

The text allows the extension to be placed in CA certificate. To my knowledge,
a self-signed certificate is also a CA certificate. So it is possible to have
that extension is a self-signed certificate. The advantage is two folds:

1) the content of a self-signed certificate may change without affecting the
content of the leaf certificates or of the cross-certificates.

2) since the extension is not in a leaf certificate, then it makes leaf
certificates smaller (remember low-fat leaf certificates ?)

We have defined in CMP a protocol to allow a certificate rollover for trust
points, so we know how to handle the renewal of a self-signed certificate.

Now, I still guess that some people would like the current text when a CA is
started from the very beginning with an OCS service or when that service is
gradually offered to renewed certificates. So I would now propose some text
that handles all the three cases. Here is the new proposal for a text to fit
under 4.1.


« 4.1  Certificate Content

 In order to convey to OCSP clients a well-known point of information access,
CAs SHOULD provide the capability to include the AuthorityInfoAccess extension
(defined in [RFC2459], section 4.2.2.1) either in every certificate that can be
checked using OCSP or in a self-signed certificate.  Alternatively, the
accessLocation for the OCSP provider may be configured locally at the OCSP
client.

CAs that support an OCSP service, either hosted locally or provided by an
Authorized Responder, MAY provide for the inclusion of a value for a
uniformResourceIndicator (URI) accessLocation and the OID value id-ad-ocsp for
the accessMethod in the AccessDescription SEQUENCE.

The value of the accessLocation field in the subject certificate defines the
transport (e.g. HTTP) used to access the OCSP responder and may contain other
transport dependent information (e.g. a URL). »


Note: the other major change around this topic is in section 5.2.2.2
Authorized Responders:


In version 08 we have:

 (...)

5.2.2.2  Authorized Responders

   The key that signs a certificate's status information need not be the
   same key that signed the certificate. It is necessary however to
   ensure that the entity signing this information is authorized to do
   so.  Therefore, a certificate's issuer MUST either sign the OCSP
   responses itself or it MUST explicitly designate this authority to
   another entity.  OCSP signing delegation SHALL be designated by the
   inclusion of id-kp-OCSPSigning in an extendedKeyUsage certificate
   extension included in the OCSP response signer's certificate.  This
   certificate MUST be issued directly by the CA that issued the
   certificate in question.


   id-kp-OCSPSigning OBJECT IDENTIFIER ::= {id-kp 9}

   Systems or applications that rely on OCSP responses MUST be capable
   of detecting and enforcing use of the id-ad-ocspSigning value as
   described above. They MAY provide a means of locally configuring one
   or more OCSP signing authorities, and specifying the set of CAs for
   which each signing authority is trusted. They MUST reject the
   response if the certificate required to validate the signature on the
   response fails to meet at least one of the following criteria:

   1. Matches a local configuration of OCSP signing authority for the
    certificate in question; or

   2. Is the certificate of the CA that issued the certificate in
    question; or

   3. Includes a value of id-ad-ocspSigning in an ExtendedKeyUsage
    extension and is issued by the CA that issued the certificate in
    question."

   Additional acceptance or rejection criteria may apply to either the
   response itself or to the certificate used to validate the signature
   on the response.


While in version -07 we have:

5.2.2.2  Authorized Responders

   The key that signs a certificate's status information need not be the
   same key that signed the certificate. A certificate's issuer MAY
   explicitly delegate OCSP signing authority by issuing a certificate
   including an extendedKeyUsage extension in the OCSP signer's
   certificate containing the value id-kp-OCSPSigning.

   id-kp-OCSPSigning OBJECT IDENTIFIER ::= {id-kp 9}


Denis


> Several folks pointed out that I made the re-opening of last call into a
> treasure hunt!  Sorry 'bout that.  I am away from the office and not easily
> able to provide a diff, but I can describe the goal for the changes, which
> resulted in both editorial and sunstantive modifications to the text.
>
> The concern I raised with the OCSP authors was that it was not clear what
> the hard and fast requirements were for CAs and clients with regard to
> supporting three different ways that OCSP can be "enabled." I felt it
> important to ensure that CAs and clients that claim comformance would
> provide a set of confuguration controls that would allow interoperability,
> if properly configured. So, the resvied text tries to make this perfectly
> clear. The final form of the requirements, with some abstraction, is
> sumarized below:
>
>         - an OCSP-compliant CA SHALL be capable of issuing OCSP responses
> that are signed ditrectly by the CA, and MUST be able to designate an OCSP
> responder by issuing an appropriately marked certificate directly to the
> responder.  the choice or direct vs. delegated OCSP responses is a local,
> administrative option. the CA also SHALL be capable of putting the AIA
> extension into certs when it is the intent that these certs will be checked
> via OCSP, and MUST be capable of populating this extension with the OID
> specifying OCSP access method and a URI for such access.  (This last part
> was changed from a MAy to a MUST, which seems reasonable to ensure the goal
> cited above.)
>
>         - an OCSP-compliant client MUST be able to accept OCSP responses
> via three different means: responses signed by the CA that issued the cert
> in question, responses signed by a responder directly designated by that
> CA, or via a locally designated responder.  It is a local administrative
> choice as to which of these options if enabled. If local designation is
> enabled, vendors have choices as to how fancy it gets, e.g., how many OCSP
> responders are specified, how one knows which ones are authorized to
> provide status for which sets of certs, etc.
>
> Steve



Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id CAA20858 for ietf-pkix-bks; Wed, 28 Apr 1999 02:19:39 -0700 (PDT)
Received: from edelweb.fr (edelweb.fr [193.51.12.16]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id CAA20854 for <[e-mail]>; Wed, 28 Apr 1999 02:19:37 -0700 (PDT)
Received: from champagne.edelweb.fr (localhost.edelweb.fr [127.0.0.1]) by edelweb.fr with ESMTP id LAA04553 for <[e-mail]>; Wed, 28 Apr 1999 11:21:08 +0200 (MET DST)
Received: from champagne.edelweb.fr (champagne.edelweb.fr [193.51.14.161]) by edelweb.fr (nospam/1.1); Wed, 28 Apr 1999 11:21:08 +0200 (MET DST)
Received: from emeriau.edelweb.fr (emeriau.edelweb.fr [193.51.14.5]) by champagne.edelweb.fr (8.6.10/8.6.6) with ESMTP id LAA01124 for <[e-mail]>; Wed, 28 Apr 1999 11:21:07 +0200
From: Peter Sylvester <[e-mail]>
Received: (sylvest@localhost) by emeriau.edelweb.fr (8.6.10/8.6.6) id LAA10071 for [e-mail]; Wed, 28 Apr 1999 11:21:07 +0200
Date: Wed, 28 Apr 1999 11:21:07 +0200
Message-Id: <[e-mail]>
To: [e-mail]
Subject: Re: Closure of the QC biometric issue
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

----- Begin Included Message -----

>From [e-mail] Wed Apr 28 11:05:38 1999
>Date: Wed, 28 Apr 1999 08:59:57 +0200
> -Source data format information has NOT been included by several reasons.
> If the sourceDataURI are used then this information is already covered. If
> sourceDataURI is NOT included then the source data issue have to be handled
> outside of the certificate anyway, thus making a source data declaration in
> the certificate of dubious value.
>
> -SourceDataUri has been included (as OPTIONAL) since it can be shown that
> some PKI:s could benefit from this value without causing troubles for other
> PKI:s.
>
How do you calculate the hash of source data starting from an SourceDataUri? 
Do you take the data, a bitmap, the mime encapsulated data? Do you include the
mime type in the hash? Are there other attributes, creation date of the document,
etc.


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id AAA19610 for ietf-pkix-bks; Wed, 28 Apr 1999 00:24:21 -0700 (PDT)
Received: from clbull.frcl.bull.fr (clbull.frcl.bull.fr [129.182.1.20]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id AAA19604 for <[e-mail]>; Wed, 28 Apr 1999 00:24:18 -0700 (PDT)
Received: from k2.frcl.bull.fr (k2.frcl.bull.fr [129.182.100.2]) by clbull.frcl.bull.fr (8.9.1a/8.9.1) with ESMTP id IAA14322; Wed, 28 Apr 1999 08:58:49 +0200
Received: from bull.net (frcls6118.frcl.bull.fr [129.182.109.213]) by k2.frcl.bull.fr (AIX4.2/UCB 8.7/8.7) with ESMTP id IAA28240; Wed, 28 Apr 1999 08:58:48 +0200 (DFT)
Message-ID: <[e-mail]>
Date: Wed, 28 Apr 1999 08:59:57 +0200
From: Denis Pinkas <[e-mail]>
Organization: Bull
X-Mailer: Mozilla 4.06 [fr] (Win95; I)
MIME-Version: 1.0
To: Stefan Santesson <[e-mail]>
CC: [e-mail]
Subject: Re: Closure of the QC biometric issue
References: <[e-mail]>
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 8bit
Content-Transfer-Encoding: 8bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Stephan,

I can live with it.  :-)

Denis


> All,
>
> I've tried my best to interpret the consensus, as far possible, regarding
> inclusion of biometric data in Qualified Certificates.
>
> The final (I hope) solution to this issue are definition of a new optional
> extension with the structure below.
>
> I know that this is not what everybody would like, but I hope that
> everybody can live with this as an acceptable solution, at this stage of
> evolution.

> Some final comments follow in the end.
>
> PLEASE REVIEW THE FOLLOWING ASN.1 STRUCTURE AND COMMENT IN CASE OF ERRORS:
> --------------------------------------------------------------------------
>
> Extension       ::=     SEQUENCE {
>   extnId                  OBJECT IDENTIFIER,
>   critical                BOOLEAN DEFAULT FALSE,
>   extnValue               OCTET STRING }
>
> biometric       EXTENSION ::= {
>   SYNTAX                BiometricSyntax
>   IDENTIFIED BY         id-qext-biometric }
>
> id-qext-biometric    OBJECT IDENTIFIER  ::= {id-qext xx}
>
> BiometricSyntax ::=     SEQUENCE OF BiometricData
>
> BiometricData ::= SEQUENCE {
>     typeOfBiometricData  TypeOfBiometricData,
>     hashAlgorithm        AlgorithmIdentifier,
>     biometricDataHash    OCTET STRING,
>     sourceDataUri        IA5String  OPTIONAL  }
>
> TypeOfBiometricData ::== CHOICE {
>      predefinedBiometricType    [0] INTEGER,
>      biometricDataOid           [1] OBJECT IDENTIFIER }
>
> with the following predefinedBiometricType defined:
>         0    picture
>         1    image of handwritten signature
>
> Minor comments:
>
> -Fingerprint has not been included due to the fact that fingerprint
> templates are used in machine verification, using a verification algorithm,
> while biometrics in this extension are aimed for human recognition.

> -Source data format information has NOT been included by several reasons.
> If the sourceDataURI are used then this information is already covered. If
> sourceDataURI is NOT included then the source data issue have to be handled
> outside of the certificate anyway, thus making a source data declaration in
> the certificate of dubious value.
>
> -SourceDataUri has been included (as OPTIONAL) since it can be shown that
> some PKI:s could benefit from this value without causing troubles for other
> PKI:s.
>
> -No storage of the source data itself has been included since this is not
> the way we want certificates to be used (according to consensus). The
> source data are never needed for security reasons, only for convenience,
> and we don't want to encourage overloading the certificate with data for
> convenience. Especially not when there are other ways to solve the same
> problem (such as using the sourceDataURI)
>
> If there are no serious objections to this (which has not already been
> discussed), I would like to bury this issue and move on.
>
> /Stefan
> -------------------------------------------------------------------
> Stefan Santesson                <[e-mail]>
> Accurata Systemsäkerhet AB      http://www.accurata.se
> Slagthuset                      Tel. [phone]
> 211 20  Malmö                   Fax. [phone]
> Sweden                        Mobile [phone]
>
> PGP fingerprint: 89BC 6C79 5B3D 591B 8547  1512 7D11 DBF4 528F 29A0
> -------------------------------------------------------------------



Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id IAA27548 for ietf-pkix-bks; Tue, 27 Apr 1999 08:58:25 -0700 (PDT)
Received: from relay7.UU.NET (relay7.UU.NET [192.48.96.17]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id IAA27544 for <[e-mail]>; Tue, 27 Apr 1999 08:58:23 -0700 (PDT)
Received: from xedia.com by relay7.UU.NET with SMTP  (peer crosschecked as: madway.xedia.com [198.202.232.199]) id QQgmtr25630; Tue, 27 Apr 1999 11:58:39 -0400 (EDT)
Received: from tonga.xedia.com by xedia.com (4.1/SMI-4.1) id AA20032; Tue, 27 Apr 99 11:58:19 EDT
Received: by tonga.xedia.com (SMI-8.6/SMI-SVR4) id LAA22849; Tue, 27 Apr 1999 11:58:37 -0400
Date: Tue, 27 Apr 1999 11:58:37 -0400
Message-Id: <[e-mail]>
From: Paul Koning <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
To: [e-mail]
Cc: [e-mail]
Subject: Re: SEIS: Re: Certificates, Directories, and Distinguished Names
References: <D1A949D4508DD1119C8100400533BEDC0BE98F@DSG1> <[e-mail]>
X-Mailer: VM 6.34 under 20.3 "Vatican City" XEmacs  Lucid
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

>>>>> "Moshe" == Moshe Litvin <[e-mail]> writes:

 Moshe> I disagree. Security software should always check its inputs
 Moshe> carefully (assuming it may be hostile). No need to for special
 Moshe> treatment here in regards for crashes.

I'd go further.  ALL protocol code must be implemented in that way.
If there is any bit pattern that I can send to a box that causes that
box to break (crash, or otherwise malfunction in a way that doesn't
straighten itself out after I stop harrassing it) then that
implementation is defective.  Full stop.  No excuses accepted.

I suppose there is no harm in mentioning that general principle in a
few places, but it shouldn't be described as specific to security
protocols, let alone PKIX profiles.

	paul


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id GAA22006 for ietf-pkix-bks; Tue, 27 Apr 1999 06:20:56 -0700 (PDT)
Received: from popmail.inbox.se (popmail.inbox.se [193.12.72.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id GAA22002 for <[e-mail]>; Tue, 27 Apr 1999 06:20:54 -0700 (PDT)
Received: from stefan2 (accurata.inbox.se [193.12.72.24]) by popmail.inbox.se (8.9.3/8.9.3) with SMTP id PAA17666 for <[e-mail]>; Tue, 27 Apr 1999 15:22:14 +0200
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: Windows Eudora Pro Version 3.0 (32)
Date: Tue, 27 Apr 1999 15:22:15 +0200
To: "[e-mail]" <[e-mail]>
From: Stefan Santesson <[e-mail]>
Subject: EU Electronic signature directive - Latest version available
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 mail.proper.com id GAA22003
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

All,

Since the process concerning the EU directive on electronic signatures has
finally come to (almost) closure, I have finally got my hands on the latest
electronic version of the draft directive, with a permission to publish it
on the QC-Website.

So you are all welcome to download the directive, and pass it on to others,
from:

http://www.accurata.se/QC/

Look under "Related information"

/Stefan
-------------------------------------------------------------------
Stefan Santesson                <[e-mail]>
Accurata Systemsäkerhet AB      http://www.accurata.se
Slagthuset                      Tel. [phone]              
211 20  Malmö                   Fax. [phone]              
Sweden                        Mobile [phone]

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


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id BAA11061 for ietf-pkix-bks; Tue, 27 Apr 1999 01:30:45 -0700 (PDT)
Received: from cale.checkpoint.com (ns.checkpoint.com [199.203.73.197]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id BAA11056 for <[e-mail]>; Tue, 27 Apr 1999 01:30:40 -0700 (PDT)
Received: from cale.checkpoint.com (gray.checkpoint.com [199.203.71.94]) by cale.checkpoint.com (8.9.1/8.9.1) with ESMTP id LAA20733; Tue, 27 Apr 1999 11:34:42 +0300 (IDT)
Message-ID: <[e-mail]>
Date: Tue, 27 Apr 1999 11:29:23 +0300
From: Moshe Litvin <[e-mail]>
X-Mailer: Mozilla 4.51 [en] (WinNT; I)
X-Accept-Language: en
MIME-Version: 1.0
To: Alan Lloyd <[e-mail]>
CC: [e-mail]
Subject: Re: SEIS: Re: Certificates, Directories, and Distinguished Names
References: <D1A949D4508DD1119C8100400533BEDC0BE98F@DSG1>
Content-Type: multipart/mixed; boundary="------------8B247012F499DBCE9D29A26B"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

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



Alan Lloyd wrote:

<snip>

>
>         Let me highlight some issues with 2459.

<snip>

>         3. Section 4.1.2.4  -last para page 19 - " The Telexstring and
> Universal string ... Certificate Users SHOULD" .. this magic word
> "Should"..
>         There is no sure way of knowing what encoding is being rxd by an
> implementation and if they do not decode strings correctly the
> implementations will fail or crash. If building a commercial robust PKIX
> implementation - one would expect a profile - if there are known uses of
> the scheme out there, to say all recieving certificate using systems
> must support this. ie a profile must dictate robustness to current
> implementations - not leave an implementor with a guess and bugs.
>

I disagree. Security software should always check its inputs carefully
(assuming it may be hostile). No need to for special treatment here in
regards for crashes.

regards,

    Moshe


--------------8B247012F499DBCE9D29A26B
Content-Type: text/x-vcard; charset=us-ascii;
 name="moshe.vcf"
Content-Transfer-Encoding: 7bit
Content-Description: Card for Moshe Litvin
Content-Disposition: attachment;
 filename="moshe.vcf"

begin:vcard 
n:Litvin;Moshe
tel;fax:[phone]
tel;work:[phone]
x-mozilla-html:TRUE
org:Check Point Software Technologies Ltd.
adr:;;;;;;
version:2.1
email;internet:[e-mail]
fn:Moshe Litvin
end:vcard

--------------8B247012F499DBCE9D29A26B--




Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id AAA09511 for ietf-pkix-bks; Tue, 27 Apr 1999 00:59:43 -0700 (PDT)
Received: from smtp.udac.net (smtp.udac.net [193.44.79.123]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id AAA09505 for <[e-mail]>; Tue, 27 Apr 1999 00:59:41 -0700 (PDT)
Received: from caesar.udac.se (caesar.udac.se [193.44.79.10]) by smtp.udac.net (8.9.1/8.9.1) with ESMTP id KAA07861 for <[e-mail]>; Tue, 27 Apr 1999 10:01:07 +0200
Received: from HYDRA ([195.198.186.71]) by caesar.udac.se (8.7.3/NetworkC-1) with SMTP id KAA52785; Tue, 27 Apr 1999 10:01:06 +0200
Received: by HYDRA with Microsoft Mail id <01BE9094.CD8D6D70@HYDRA>; Tue, 27 Apr 1999 10:00:39 +0200
Message-ID: <01BE9094.CD8D6D70@HYDRA>
From: Anders Rundgren <[e-mail]>
To: "[e-mail]" <[e-mail]>, "'Stefan Santesson'" <[e-mail]>
Subject: RE: Closure of the QC biometric issue
Date: Tue, 27 Apr 1999 10:00:37 +0200
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Stefan,
Thanx for a prompt response but my two questions regarding the access to
the bio-data-template-server are still unanswered.
Anders

>Certainly,
>1) URI are defined by RFC 2396.
>2) The source data is authenticated by the signed hash of the bio data,
>held in the new certificate extension.

>>Congratulations Stefan!
>>But before you cast it in stone, could you for us morons who do not fully
>>understand the implicit infrastructure that the QC-editors apparently work
>>with, explain a little bit on how "sourceDataUri" is to be used?  E.g. WHO
>>fetches the bio-data?  Authenticated by WHAT?
>
>>Anders
>>http://www.mobilephones-tng.com/papers/idcards.html



Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id AAA05682 for ietf-pkix-bks; Tue, 27 Apr 1999 00:03:28 -0700 (PDT)
Received: from popmail.inbox.se (popmail.inbox.se [193.12.72.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id AAA05678 for <[e-mail]>; Tue, 27 Apr 1999 00:03:26 -0700 (PDT)
Received: from stefan2 (accurata.inbox.se [193.12.72.24]) by popmail.inbox.se (8.9.3/8.9.3) with SMTP id JAA13613; Tue, 27 Apr 1999 09:04:51 +0200
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: Windows Eudora Pro Version 3.0 (32)
Date: Tue, 27 Apr 1999 09:04:53 +0200
To: Anders Rundgren <[e-mail]>, "[e-mail]" <[e-mail]>
From: Stefan Santesson <[e-mail]>
Subject: RE: Closure of the QC biometric issue
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 mail.proper.com id AAA05679
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Certainly,

1) URI are defined by RFC 2396.
2) The source data is authenticated by the signed hash of the bio data,
held in the new certificate extension.

/Stefan

At 05:32 PM 4/26/99 +0200, Anders Rundgren wrote:
>Congratulations Stefan!
>But before you cast it in stone, could you for us morons who do not fully
understand the implicit infrastructure that the QC-editors apparently work
with, explain a little bit on how "sourceDataUri" is to be used?  E.g. WHO
fetches the bio-data?  Authenticated by WHAT?
>
>Anders
>http://www.mobilephones-tng.com/papers/idcards.html
>
>
-------------------------------------------------------------------
Stefan Santesson                <[e-mail]>
Accurata Systemsäkerhet AB      http://www.accurata.se
Slagthuset                      Tel. [phone]              
211 20  Malmö                   Fax. [phone]              
Sweden                        Mobile [phone]

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


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id IAA29680 for ietf-pkix-bks; Mon, 26 Apr 1999 08:32:14 -0700 (PDT)
Received: from smtp.udac.net (smtp.udac.net [193.44.79.123]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id IAA29671 for <[e-mail]>; Mon, 26 Apr 1999 08:32:05 -0700 (PDT)
Received: from caesar.udac.se (caesar.udac.se [193.44.79.10]) by smtp.udac.net (8.9.1/8.9.1) with ESMTP id RAA31638 for <[e-mail]>; Mon, 26 Apr 1999 17:33:22 +0200
Received: from HYDRA ([195.198.186.71]) by caesar.udac.se (8.7.3/NetworkC-1) with SMTP id RAA41443; Mon, 26 Apr 1999 17:33:17 +0200
Received: by HYDRA with Microsoft Mail id <01BE900A.D2B91450@HYDRA>; Mon, 26 Apr 1999 17:32:57 +0200
Message-ID: <01BE900A.D2B91450@HYDRA>
From: Anders Rundgren <[e-mail]>
To: "[e-mail]" <[e-mail]>, "'Stefan Santesson'" <[e-mail]>
Cc: =?iso-8859-1?Q?=27Petra_Gl=F6ckner=27?= <[e-mail]>
Subject: RE: Closure of the QC biometric issue
Date: Mon, 26 Apr 1999 17:32:56 +0200
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by mail.proper.com id IAA29677
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Congratulations Stefan!
But before you cast it in stone, could you for us morons who do not fully understand the implicit infrastructure that the QC-editors apparently work with, explain a little bit on how "sourceDataUri" is to be used?  E.g. WHO fetches the bio-data?  Authenticated by WHAT?

Anders
http://www.mobilephones-tng.com/papers/idcards.html




Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id EAA27706 for ietf-pkix-bks; Mon, 26 Apr 1999 04:53:30 -0700 (PDT)
Received: from popmail.inbox.se (popmail.inbox.se [193.12.72.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id EAA27702 for <[e-mail]>; Mon, 26 Apr 1999 04:53:29 -0700 (PDT)
Received: from stefan2 (accurata.inbox.se [193.12.72.24]) by popmail.inbox.se (8.9.3/8.9.3) with SMTP id NAA06527; Mon, 26 Apr 1999 13:54:50 +0200
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: Windows Eudora Pro Version 3.0 (32)
Date: Mon, 26 Apr 1999 13:54:52 +0200
To: Alfred Arsenault <[e-mail]>, [e-mail]
From: Stefan Santesson <[e-mail]>
Subject: Comments on QC-parts of PKIX roadmap.
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 mail.proper.com id EAA27703
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Al,

You asked me in Minneapolis to check the new roadmap concerning the QC parts.
Well, I seam to have missed it's appearance on the list so here are my
comments a little bit late.

The following text is not quite right (from 3.6.1):

  "Certain organizations, such as countries, have recently mandated
   certain restrictions on certificates (such as that the subject of a
   certificate must be a natural person, or that the country of
   citizenship and/or country of residence of the subject must be
   included in the certificate).  A certificate which meets these
   restrictions is deemed a "qualified certificate."  In December 1998,
   PKIX adopted as a work item the development of a refinement of
   [RFC2459] that further profiles PKIX certificates into qualified
   certificates.  This work is reflected in [QC]."


In fact I would say that this is wrong. I don't know of any country making
such statements.

I would put it more like this:

"Certain countries are in a process of updating their legal frameworks in
order to regulate and incorporate recognition of signatures in electronic
form. Many of these frameworks introduce certain basic requirements on
certificates, often termed Qualified Certificates, supporting these types
of "legal" signatures. Partly as a result of this there is a need for a
specific certificate profile providing standardized support for certain
related issues such as a common structure for expressing unambiguous
identities of certified subjects (unmistakable identity). In December 1998,
PKIX adopted as a work item the development of a refinement of [RFC2459]
that further profiles PKIX certificates into qualified certificates.  This
work is reflected in [QC]."

Please feel free to edit this as you like.

/Stefan

-------------------------------------------------------------------
Stefan Santesson                <[e-mail]>
Accurata Systemsäkerhet AB      http://www.accurata.se
Slagthuset                      Tel. [phone]              
211 20  Malmö                   Fax. [phone]              
Sweden                        Mobile [phone]

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


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id CAA24294 for ietf-pkix-bks; Mon, 26 Apr 1999 02:07:24 -0700 (PDT)
Received: from popmail.inbox.se (popmail.inbox.se [193.12.72.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id CAA24290 for <[e-mail]>; Mon, 26 Apr 1999 02:07:22 -0700 (PDT)
Received: from stefan2 (accurata.inbox.se [193.12.72.24]) by popmail.inbox.se (8.9.3/8.9.3) with SMTP id LAA04781 for <[e-mail]>; Mon, 26 Apr 1999 11:08:42 +0200
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: Windows Eudora Pro Version 3.0 (32)
Date: Mon, 26 Apr 1999 11:08:43 +0200
To: <[e-mail]>
From: Stefan Santesson <[e-mail]>
Subject: Closure of the QC biometric issue
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 mail.proper.com id CAA24291
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

All,

I've tried my best to interpret the consensus, as far possible, regarding
inclusion of biometric data in Qualified Certificates.

The final (I hope) solution to this issue are definition of a new optional
extension with the structure below.

I know that this is not what everybody would like, but I hope that
everybody can live with this as an acceptable solution, at this stage of
evolution.

Some final comments follow in the end.

PLEASE REVIEW THE FOLLOWING ASN.1 STRUCTURE AND COMMENT IN CASE OF ERRORS:
--------------------------------------------------------------------------

Extension	::=	SEQUENCE {
  extnId		  OBJECT IDENTIFIER,
  critical		  BOOLEAN DEFAULT FALSE,
  extnValue		  OCTET STRING }

biometric 	EXTENSION ::= {
  SYNTAX		BiometricSyntax
  IDENTIFIED BY		id-qext-biometric }

id-qext-biometric    OBJECT IDENTIFIER	::= {id-qext xx}

BiometricSyntax	::=	SEQUENCE OF BiometricData

BiometricData ::= SEQUENCE {
    typeOfBiometricData  TypeOfBiometricData,
    hashAlgorithm        AlgorithmIdentifier,
    biometricDataHash    OCTET STRING,
    sourceDataUri        IA5String  OPTIONAL  }

TypeOfBiometricData ::== CHOICE {
     predefinedBiometricType    [0] INTEGER,
     biometricDataOid           [1] OBJECT IDENTIFIER } 

with the following predefinedBiometricType defined:
	0    picture
	1    image of handwritten signature




Minor comments:

-Fingerprint has not been included due to the fact that fingerprint
templates are used in machine verification, using a verification algorithm,
while biometrics in this extension are aimed for human recognition.

-Source data format information has NOT been included by several reasons.
If the sourceDataURI are used then this information is already covered. If
sourceDataURI is NOT included then the source data issue have to be handled
outside of the certificate anyway, thus making a source data declaration in
the certificate of dubious value.

-SourceDataUri has been included (as OPTIONAL) since it can be shown that
some PKI:s could benefit from this value without causing troubles for other
PKI:s.

-No storage of the source data itself has been included since this is not
the way we want certificates to be used (according to consensus). The
source data are never needed for security reasons, only for convenience,
and we don't want to encourage overloading the certificate with data for
convenience. Especially not when there are other ways to solve the same
problem (such as using the sourceDataURI)


If there are no serious objections to this (which has not already been
discussed), I would like to bury this issue and move on.

/Stefan
-------------------------------------------------------------------
Stefan Santesson                <[e-mail]>
Accurata Systemsäkerhet AB      http://www.accurata.se
Slagthuset                      Tel. [phone]              
211 20  Malmö                   Fax. [phone]              
Sweden                        Mobile [phone]

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


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id VAA22529 for ietf-pkix-bks; Sun, 25 Apr 1999 21:08:00 -0700 (PDT)
Received: from dsg1.OpenDirectory.com.au ([203.108.249.145]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id VAA22524 for <[e-mail]>; Sun, 25 Apr 1999 21:07:54 -0700 (PDT)
Received: by DSG1 with Internet Mail Service (5.0.1458.49) id <J4BWJT50>; Mon, 26 Apr 1999 14:08:56 +1000
Message-ID: <D1A949D4508DD1119C8100400533BEDC0BE98F@DSG1>
From: Alan Lloyd <[e-mail]>
To: "'Stephen Kent'" <[e-mail]>
Cc: [e-mail], [e-mail]
Subject: RE: SEIS: Re: Certificates, Directories, and Distinguished Names
Date: Mon, 26 Apr 1999 14:08:53 +1000
X-Priority: 3
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.0.1458.49)
Content-Type: text/plain; charset="iso-8859-1"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

	snip

> >
> >	If this is the approach to logical debate - that is also used to
> >debate technology issues , then one can see why these lists have
> >difficulty.
> 
> Yes, this is a logical approach to debate.  Sorry if my choice of
> terms was
> confusing, but I fear the real problem is deeper.
> 
	Yes it is. It is the general issue that 2459 is a massive amount
of paper which repeats much of X.509 and at the same time in some
(important) places confuses its implementation - specifically as the
text relates to CA management policies and certificate using system
validation. Yes I am very well aware that standards do not cover all
things or are correct. Thats why standards evolve and get bug fixes -
and then get profiled.

	Profiles on the other hand should not be tutorial or vague or in
error. As it is these documents that people will commit implementation
to. And in the case of X.509 and security - that wont be cheap.

	Let me highlight some issues with 2459.

	1. Section 2 second para - last sentence - what does that mean?

	2. Section 2 should also state that where certificate using
systems (signer and relying party) need to validate information without
a shared directory service, then the means and protocols by which they
perform this sharing is a local matter and outside the scope of this
profile. ie this situation does create ambiguity.

	3. Section 4.1.2.4  -last para page 19 - " The Telexstring and
Universal string ... Certificate Users SHOULD" .. this magic word
"Should".. 
	There is no sure way of knowing what encoding is being rxd by an
implementation and if they do not decode strings correctly the
implementations will fail or crash. If building a commercial robust PKIX
implementation - one would expect a profile - if there are known uses of
the scheme out there, to say all recieving certificate using systems
must support this. ie a profile must dictate robustness to current
implementations - not leave an implementor with a guess and bugs.


	4. Section 4.1.2.4 para "standard sets of (naming) attributes
... same as above.


	5. Section 4.1.2.4 (not a good section) Name comparison rules.
	X.500 relaxes name comparison on different
syntaxes/normalisation  to permit directory searching as the author of
the info may use a different syntax when storing to that from a user who
is searching. ie X.500 provides relaxation (approximate matching, etc)
to provide Search utility.

	I find it odd that certficate validation proposed by PKIX - in
which a cert cryptographically binds names to key material permits name
relaxation in the validation process?. In fact why verify a certificate
signature - if the means one finds its issuer with a relaxed name form.?
Isnt this weak and open to threats.
	IMHO the DN of the Issuer MUST be the CA - Case exact match.
	This name form relaxation text is repeated in subsequent
sections.

	6. Section 4.2.1.1 Authority Key Id (and Subject Key Id)
	The text mandates the use of this extension by ALL PKIX
certficates. However the ASN.1 seems to permit the choice of Issuer and
SN and or with Key Id . In the case of Key Id one  SHOULD use one of the
two Key Id methods proposed (as well as a third option as "sequence of
numbers" )

	It is unclear if Issuer and SN are compatible in developing
paths with the other methods, that the distinction between 160 bit sha
and the other is by saying by length - (20 bytes or 8 bytes) but if a
sequence of integers is used and its 8 or 20 bytes long (an Octet
String) - what happens?
	I would have thought that fwd and reverse certificate path
management/determination  is a critical piece of engineering - but the
text is not very clear about use for implicit interoperability.



	7. Section 4.2.5.1 Cert Policies
	The CPS pointer - a health warning should be provided in that
the CSP is not cryptographically bound to the certificate and can be
changed without referring to the certificate issuer.

	A small matter .. The User notice. "is intended for display to a
relying party." although this may have some utility - is it informative,
interactive, affect validation or provided before or after path
validation.


	8. Section 4.2.1.7 Subject Alt Names 
	I have difficulty with this thing - simply because of what is
the trust mechanism. If there is no Subject in the cert and Subject Alt
Name is used and is critical , then it is up to the certficate using
system to verify the subject. For instance if the "message" to be
verified / originator authentication is via "IP", and the IP form is
used in the subject alt name, then the certificate using system Must
validate the source IP address, ditto X.400, ditto smtp.
	If implementations do not do this  - all they are doing is
verifying a certficate path from something that cannot verify when it
has been deemed by the certficate issuer to be critical. (see also name
constraints).

	Part of the PKIX profile should highlight interfaces and
mechanisms when using certs with cert fields described in this way.
Otherwise interoperability and trust will not be achieved.


	9. Section 4.2.1.8 Issuer Alt name  - same as above - whats the
validation process - ie when reading certs for path validation from the
CA (eg via smtp or IP ) do I check its originating details are as
defined in the issuer alt name.


	10. Section 4.2.1.10 Basic Constraints - already discussed and
text offered - should cover certificate using system usage. ie an EE
cert cannot be used for cert signature verification.

	11. Section 4.2.1.11 Naming Constraints - 
	Text is unclear if this extension is mandated in PKIX CA
certificates or as X.509 says it can only be used in CA certs.
	If it is mandated and critical this will add a lot of complexity
to client/user/certficate using systems. re name types, alt names and
name relaxation (if used).. 

	12. Section 5.2.1. CRL Auth key Id
	I would like to see text that helps the implementor understand
there may a different between the Certificate signing key and the CRL
signing key and that the certs used to verify the CRL may have a
different auth key Id to that of the CA cert signing and that the
management of these must be maintained in the cert path validation.


	In closing, a profile should assist where it can the operational
implementation of a function. Specifically the thrust of the profile is
to get consistent trusted validation paths going. The issues raised
above affect interfaces, interpretation and choices.


	regards alan.


> Steve


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id BAA20489 for ietf-pkix-bks; Sat, 24 Apr 1999 01:19:22 -0700 (PDT)
Received: from web103.yahoomail.com (web103.yahoomail.com [205.180.60.68]) by mail.proper.com (8.8.8/8.8.5) with SMTP id BAA20485 for <[e-mail]>; Sat, 24 Apr 1999 01:19:20 -0700 (PDT)
Message-ID: <[e-mail]>
Received: from [12.72.55.119] by web103.yahoomail.com; Sat, 24 Apr 1999 01:21:04 PDT
Date: Sat, 24 Apr 1999 01:21:04 -0700 (PDT)
From: sankar ramamoorthi <[e-mail]>
Subject: subj.alt.name and uniqueness
To: [e-mail]
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Hi,

A question on subj.alt.name. RFC 2459 states that

'If the only subject identity included in the certificate is an
alternative name form (e.g., an electonic mail
address), then the subject distinguished name shall be empty (an empty
sequence), and the subjectAltName
must be present. If the subject field contains an empty sequence, the
subjectAltName extension
shall be marked critical'.

In the above case can I assume the subjectAltName will have the same
uniqueness characterstic
described for subject names?

In general what are uniqueness guarantees for subjectAltNames?

My motivation for this question comes from IPsec usage of
subjectAltNames to store
identies of IPsec devices.

Thanks,

-- sankar ramamoorthi --

_________________________________________________________
Do You Yahoo!?
Get your free @yahoo.com address at http://mail.yahoo.com



Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id SAA17960 for ietf-pkix-bks; Fri, 23 Apr 1999 18:36:43 -0700 (PDT)
Received: from mail.rdc1.md.home.com ([e-mail] [24.2.2.66]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id SAA17956 for <[e-mail]>; Fri, 23 Apr 1999 18:36:41 -0700 (PDT)
Received: from home.com ([24.4.133.54]) by mail.rdc1.md.home.com (InterMail v4.00.03 201-229-104) with ESMTP id <[e-mail]> for <[e-mail]>; Fri, 23 Apr 1999 18:37:52 -0700
Message-ID: <[e-mail]>
Date: Fri, 23 Apr 1999 21:37:56 -0400
From: Alfred Arsenault <[e-mail]>
Organization: @Home Network
X-Mailer: Mozilla 4.5 [en]C-AtHome0405  (Win95; U)
X-Accept-Language: en
MIME-Version: 1.0
To: [e-mail]
Subject: Re: Some term ambiguous on PKIX Roadmap 
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

<snip>
 For key management keys that are generated by the requester, the
      CA can send the user the requested public key, along with the CA's
      own private key, to encrypt some piece of data, and send it to the
      requester to be decrypted.  
<snip>
What CA's own private key above context means?
      CA's private key is so meaningless to send to a new requester?
      Can I interpret it as somewhat like a session key?
      And encrypt the session key with the requester's public key..
      If the requester really have a corresponding private key, 
      he can get the session key.
      Is my interpretation right?

<snip>

________________________________

Yes, your interpretation is right.  The paragraph in the Roadmap is in
error; it should say something like

For key management keys that are generated by the requester, the
      CA can use the requested public key to encrypt some piece of data,
and send it to the
      requester to be decrypted.  

___________________________

Depending on which encryption algorithm you're using, the encryption
might involve both the requested key, and the CA's private key; the
decryption would thus involve both the private key that matches the
requested public, and the CA's public.  Unfortunately, we didn't say
that very well.  It will be fixed in the next draft.

			Al Arsenault

--- These are my opinions, and do not necessarily represent those of my
employer or of any other organization with which I have a relationship.


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id LAA13984 for ietf-pkix-bks; Fri, 23 Apr 1999 11:35:23 -0700 (PDT)
Received: from prv-mail20.provo.novell.com (prv-mail20.Provo.Novell.COM [137.65.40.4]) by mail.proper.com (8.8.8/8.8.5) with SMTP id LAA13979 for <[e-mail]>; Fri, 23 Apr 1999 11:35:22 -0700 (PDT)
Received: from INET-PRV-Message_Server by prv-mail20.provo.novell.com with Novell_GroupWise; Fri, 23 Apr 1999 12:33:39 -0600
Message-Id: <[e-mail]>
X-Mailer: Novell GroupWise 5.5
Date: Fri, 23 Apr 1999 12:33:32 -0600
From: "Bob Jueneman" <[e-mail]>
To: <[e-mail]>, <[e-mail]>
Subject: RE: New CMC Draft available - Confirmation Message
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 mail.proper.com id LAA13980
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Yes.

Although revoking a certificate that the client has already started 
to use is awkward, it is at least fail safe. If someone receives 
a document that can't be validated they will go back to the user and 
complain, and the matter will be resolved quickly. But the other 
way around risks having a certificate published that was issued 
to the wrong person, or that the client doesn't accept because 
of the contents, etc.

One way to make this a little more graceful is to use the pending state, 
where the certificate is not published until it is accepted, and can
not be used to validate the certificate the client has already received
until the notice of acceptance has been received, e.g., in the form 
of a secret PIN sent out of band to that user to indicate acceptance.
This PIN can also be used to prove that the user actually saw and
read the notice of certificate issuance.

Regards,

Bob

>>> "Jim Schaad (Exchange)" <[e-mail]> 04/23/99 10:02AM >>>
Let me make sure that I understand what you are saying:

It is better for both the CA and the client, for a CA to revoke a
certificate that the CA has not received positive conformation of acceptance
(even if the client thinks it has accepted it and started to use it) than it
is for a CA to not revoke a certificate that a client has rejected.
Remember that for signing certificates the client can start using the cert
immeadiately and does not need to wait for it to be published in the DS.

jim


-----Original Message-----
From: Bob Jueneman [mailto:[e-mail]] 
Sent: Friday, April 16, 1999 3:38 PM
To: Jim Schaad (Exchange); '[e-mail]' ; IETF-PKIX (E-mail)
Subject: RE: New CMC Draft available - Confirmation Message


Jim,

I have to agree with Juergan.

The client shouldn't have to check for revocation if (s)he disagrees
with the
certificate, even though it might be prudent to do so.

But if the client does accept the certificate and the CA thinks it
hasn't, that 
is at least fail safe.

If the CA ends up calling the client, screaming "What do you mean you
are 
rejecting the certificate -- do you want to keep on working here?!",
then
at least the problem will end up getting resolved.

But if the client thinks it rejected the certificate and the CA goes
ahead 
and publishes it anyway, very real and perhaps substantial damages
could
occur - it might be someone else's public key, it might disclose
private information,
or it might contain a Reliance Limit that is higher than the client
wishes to accept., etc.

Positive acknowledgment of acceptance by the Subscriber is a firm
requirement.

Bob


>>> "Jim Schaad (Exchange)" <[e-mail]> 04/13/99
01:01PM >>>
Juergen,

The problem that I have with this approach is that there is no way of
knowing what the delay is going to be on the acceptance showing up on
at the
CA.  (Nor do all transport mechinisms guantee delivery.)  Thus a client
can
think it did accept a certificate and the CA can reach an opposite
conclusion.  If the client asks for revocation, it can later check to
make
sure that this operation occured.

jim


-----Original Message-----
From: Juergen Walter [mailto:[e-mail]] 
Sent: Tuesday, April 13, 1999 1:32 AM
To: Jim Schaad (Exchange); IETF-PKIX (E-mail)
Subject: Re: New CMC Draft available - Confirmation Message


Jim,

[snip]


> 
> > - there is no confirmation message from the client to the
> > CA/RA (thus, there
> > is no way for a client to reject a certificate that it does
> > not want (e.g.,
> > in the case where the CA has modified some of the fields in
> > the request)).
> 
> There is a simple way for a client to reject a certificate, it simply
puts
> in a revocation request on the certificates it just received.  I
don't
know
> of any reason for the oppositite to be required in a general
protocal.
That
> is the client must positively accept a certificate.
> 

When I remember right e. g. ABA Guidelines requires that an EE
explicitly confirms an issued certificate. This may be not a protocol
requirement in pure PKI implementations. But I know environments where
a
certificate receipt is at least an operational requirement. I think
that
an appropriate message (optional) would be an improvement. When the
rejection (i. e. sending of revocation request) stays away we have no
explicite confirmation of the certificate (may be a legal issue). The
time-frame of such stay away process may cause complicated validation
issues. I prefer a message that indicates the fact whether an EE
accept
his certificate or not. This may replace the revocation request on the
one hand and the pure revocation request on the other hand. 

 

Juergen


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id LAA13864 for ietf-pkix-bks; Fri, 23 Apr 1999 11:25:29 -0700 (PDT)
Received: from prv-mail20.provo.novell.com (prv-mail20.Provo.Novell.COM [137.65.40.4]) by mail.proper.com (8.8.8/8.8.5) with SMTP id LAA13860 for <[e-mail]>; Fri, 23 Apr 1999 11:25:28 -0700 (PDT)
Received: from INET-PRV-Message_Server by prv-mail20.provo.novell.com with Novell_GroupWise; Fri, 23 Apr 1999 12:26:03 -0600
Message-Id: <[e-mail]>
X-Mailer: Novell GroupWise 5.5
Date: Fri, 23 Apr 1999 12:25:53 -0600
From: "Bob Jueneman" <[e-mail]>
To: <[e-mail]>
Cc: <[e-mail]>
Subject: Re: Delta CRL processing
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 mail.proper.com id LAA13861
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Paul, I agree.

>Similarly, the only statements about a CA that can be normative are
>those that are externally observable.  If a CA publishes a CRL, that
>is observable.  If it generates one that it doesn't publish, that's an
>internal algorithm and illustrative only.
>
>With that in mind, if X.509 *requires* a CA to "issue" a CRL under
>some conditions, there are two possible conclusions:
>
>1. The term "issue" describes externally visible behavior, i.e., it is 
>synonymous with "publish", or
>
>2. The term "issue" describes internal behavior, is not meant as
>"publish" and the standard is in error in that it appears to require
>something that isn't observable.
>
>	paul

Since it is clear from the final paragraph of that section that the CA is 
not required to _publish_ the issued the CRL, the standard is over-reaching
by specifying something that isn't visible.  I would suggest submitting a
defect report to X.509 to remove the entire section having to do with 
"issuing" a certificate that isn't published and isn't needed.  Simultaneously,
we can clean up the language of RFC 2459 in a similar fashion..

Bob




Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id JAA12688 for ietf-pkix-bks; Fri, 23 Apr 1999 09:14:17 -0700 (PDT)
Received: from po1.bbn.com (PO1.BBN.COM [192.1.50.38]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id JAA12684 for <[e-mail]>; Fri, 23 Apr 1999 09:14:15 -0700 (PDT)
Received: from [128.33.238.34] (TC048.BBN.COM [128.33.238.48]) by po1.bbn.com (8.9.1/8.9.1) with ESMTP id MAA13000 for <[e-mail]>; Fri, 23 Apr 1999 12:15:18 -0400 (EDT)
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Message-Id: <v04020a25b34641c27a7f@[128.33.238.34]>
In-Reply-To: <[e-mail]>
References: <v04020a15b34509844f3d@[128.33.238.34]>
Date: Fri, 23 Apr 1999 12:15:12 -0400
To: [e-mail]
From: Stephen Kent <[e-mail]>
Subject: Re: WG Last call, redux
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Several folks pointed out that I made the re-opening of last call into a
treasure hunt!  Sorry 'bout that.  I am away from the office and not easily
able to provide a diff, but I can describe the goal for the changes, which
resulted in both editorial and sunstantive modifications to the text.

The concern I raised with the OCSP authors was that it was not clear what
the hard and fast requirements were for CAs and clients with regard to
supporting three different ways that OCSP can be "enabled." I felt it
important to ensure that CAs and clients that claim comformance would
provide a set of confuguration controls that would allow interoperability,
if properly configured. So, the resvied text tries to make this perfectly
clear. The final form of the requirements, with some abstraction, is
sumarized below:

	- an OCSP-compliant CA SHALL be capable of issuing OCSP responses
that are signed ditrectly by the CA, and MUST be able to designate an OCSP
responder by issuing an appropriately marked certificate directly to the
responder.  the choice or direct vs. delegated OCSP responses is a local,
administrative option. the CA also SHALL be capable of putting the AIA
extension into certs when it is the intent that these certs will be checked
via OCSP, and MUST be capable of populating this extension with the OID
specifying OCSP access method and a URI for such access.  (This last part
was changed from a MAy to a MUST, which seems reasonable to ensure the goal
cited above.)

	- an OCSP-compliant client MUST be able to accept OCSP responses
via three different means: responses signed by the CA that issued the cert
in question, responses signed by a responder directly designated by that
CA, or via a locally designated responder.  It is a local administrative
choice as to which of these options if enabled. If local designation is
enabled, vendors have choices as to how fancy it gets, e.g., how many OCSP
responders are specified, how one knows which ones are authorized to
provide status for which sets of certs, etc.


Steve


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id JAA12550 for ietf-pkix-bks; Fri, 23 Apr 1999 09:01:47 -0700 (PDT)
Received: from dfssl.exchange.microsoft.com (dfssl.exchange.microsoft.com [131.107.88.59]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id JAA12546 for <[e-mail]>; Fri, 23 Apr 1999 09:01:46 -0700 (PDT)
Received: by dfssl with Internet Mail Service (5.5.2580.0) id <25TF0BFT>; Fri, 23 Apr 1999 09:02:34 -0700
Message-ID: <2FBF98FC7852CF11912A0000000000010ECB5E93@DINO>
From: "Jim Schaad (Exchange)" <[e-mail]>
To: "'Bob Jueneman'" <[e-mail]>, "IETF-PKIX (E-mail)" <[e-mail]>
Subject: RE: New CMC Draft available - Confirmation Message
Date: Fri, 23 Apr 1999 09:02:33 -0700
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2580.0)
Content-Type: text/plain; charset="iso-8859-1"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Let me make sure that I understand what you are saying:

It is better for both the CA and the client, for a CA to revoke a
certificate that the CA has not received positive conformation of acceptance
(even if the client thinks it has accepted it and started to use it) than it
is for a CA to not revoke a certificate that a client has rejected.
Remember that for signing certificates the client can start using the cert
immeadiately and does not need to wait for it to be published in the DS.

jim


-----Original Message-----
From: Bob Jueneman [mailto:[e-mail]]
Sent: Friday, April 16, 1999 3:38 PM
To: Jim Schaad (Exchange); '[e-mail]' ; IETF-PKIX (E-mail)
Subject: RE: New CMC Draft available - Confirmation Message


Jim,

I have to agree with Juergan.

The client shouldn't have to check for revocation if (s)he disagrees
with the
certificate, even though it might be prudent to do so.

But if the client does accept the certificate and the CA thinks it
hasn't, that 
is at least fail safe.

If the CA ends up calling the client, screaming "What do you mean you
are 
rejecting the certificate -- do you want to keep on working here?!",
then
at least the problem will end up getting resolved.

But if the client thinks it rejected the certificate and the CA goes
ahead 
and publishes it anyway, very real and perhaps substantial damages
could
occur - it might be someone else's public key, it might disclose
private information,
or it might contain a Reliance Limit that is higher than the client
wishes to accept., etc.

Positive acknowledgment of acceptance by the Subscriber is a firm
requirement.

Bob


>>> "Jim Schaad (Exchange)" <[e-mail]> 04/13/99
01:01PM >>>
Juergen,

The problem that I have with this approach is that there is no way of
knowing what the delay is going to be on the acceptance showing up on
at the
CA.  (Nor do all transport mechinisms guantee delivery.)  Thus a client
can
think it did accept a certificate and the CA can reach an opposite
conclusion.  If the client asks for revocation, it can later check to
make
sure that this operation occured.

jim


-----Original Message-----
From: Juergen Walter [mailto:[e-mail]] 
Sent: Tuesday, April 13, 1999 1:32 AM
To: Jim Schaad (Exchange); IETF-PKIX (E-mail)
Subject: Re: New CMC Draft available - Confirmation Message


Jim,

[snip]


> 
> > - there is no confirmation message from the client to the
> > CA/RA (thus, there
> > is no way for a client to reject a certificate that it does
> > not want (e.g.,
> > in the case where the CA has modified some of the fields in
> > the request)).
> 
> There is a simple way for a client to reject a certificate, it simply
puts
> in a revocation request on the certificates it just received.  I
don't
know
> of any reason for the oppositite to be required in a general
protocal.
That
> is the client must positively accept a certificate.
> 

When I remember right e. g. ABA Guidelines requires that an EE
explicitly confirms an issued certificate. This may be not a protocol
requirement in pure PKI implementations. But I know environments where
a
certificate receipt is at least an operational requirement. I think
that
an appropriate message (optional) would be an improvement. When the
rejection (i. e. sending of revocation request) stays away we have no
explicite confirmation of the certificate (may be a legal issue). The
time-frame of such stay away process may cause complicated validation
issues. I prefer a message that indicates the fact whether an EE
accept
his certificate or not. This may replace the revocation request on the
one hand and the pure revocation request on the other hand. 

 

Juergen


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id HAA11859 for ietf-pkix-bks; Fri, 23 Apr 1999 07:58:37 -0700 (PDT)
Received: from relay4.UU.NET (relay4.UU.NET [192.48.96.14]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id HAA11855 for <[e-mail]>; Fri, 23 Apr 1999 07:58:36 -0700 (PDT)
Received: from xedia.com by relay4.UU.NET with SMTP  (peer crosschecked as: madway.xedia.com [198.202.232.199]) id QQgmet01549; Fri, 23 Apr 1999 10:56:21 -0400 (EDT)
Received: from tonga.xedia.com by xedia.com (4.1/SMI-4.1) id AA02059; Fri, 23 Apr 99 10:55:53 EDT
Received: by tonga.xedia.com (SMI-8.6/SMI-SVR4) id KAA15233; Fri, 23 Apr 1999 10:56:08 -0400
Date: Fri, 23 Apr 1999 10:56:08 -0400
Message-Id: <[e-mail]>
From: Paul Koning <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
To: [e-mail]
Cc: [e-mail]
Subject: Re: Delta CRL processing
References: <[e-mail]>
X-Mailer: VM 6.34 under 20.3 "Vatican City" XEmacs  Lucid
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

>>>>> "Bob" == Bob Jueneman <[e-mail]> writes:

 Bob> I must be dense, Russ. The text you attached seems to agree
 Bob> precisely with what Sharon said, and was exactly what I was
 Bob> requesting as well.

 Bob> Sharon used the term "publish", not "issue", and the last
 Bob> paragraph certainly seems to be quite explicit in allowing that
 Bob> option, by differentiating between issuing and publishing.

 Bob> Why do you disagree?  What am I missing?

 Bob> Bob


 >>>> Russ Housley <[e-mail]> 04/22/99 01:38PM >>>
 >> In a private message, Sharon Boeyen points out:
 >> 
 >> "As of the 1997 edition of X.509 a CA is NOT required to publish a
 >> full CRL."

 > I disagree with Sharon.  X.509-1997 says: " ... It is the
 > decision of a CA as to whether to provide delta-CRLs. However, a
 > delta-CRL shall not be issued without a corresponding complete
 > CRL being issued at the same time."  I have attached the entire
 > section on delta-CRLs from X.509-1997 at the end of this
 > message.

I think it would be a good idea to apply the normal "black box rule of 
protocol specification" to this issue.  In protocol specs, the only
parts that can be normative are those that describe externally visible 
behavior.  If anything is said about internal algorithms, that is only 
for illustrative purposes.

Similarly, the only statements about a CA that can be normative are
those that are externally observable.  If a CA publishes a CRL, that
is observable.  If it generates one that it doesn't publish, that's an
internal algorithm and illustrative only.

With that in mind, if X.509 *requires* a CA to "issue" a CRL under
some conditions, there are two possible conclusions:

1. The term "issue" describes externally visible behavior, i.e., it is 
synonymous with "publish", or

2. The term "issue" describes internal behavior, is not meant as
"publish" and the standard is in error in that it appears to require
something that isn't observable.

	paul


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id GAA11136 for ietf-pkix-bks; Fri, 23 Apr 1999 06:46:22 -0700 (PDT)
Received: from stax05.cubis.de (proxy.cubis.de [194.112.101.49]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id GAA11118; Fri, 23 Apr 1999 06:45:37 -0700 (PDT)
Received: from secunet.de (huehnlein.cubis.de [10.0.129.33]) by stax05.cubis.de (8.7.5/8.7.3) with ESMTP id PAA02374; Fri, 23 Apr 1999 15:04:16 +0200 (MET DST)
Message-ID: <[e-mail]>
Date: Fri, 23 Apr 1999 15:01:16 +0100
From: "Detlef =?iso-8859-1?Q?H=FChnlein?=" <[e-mail]>
Organization: Secunet GmbH - The Trust Company
X-Mailer: Mozilla 4.03 [en] (WinNT; I)
MIME-Version: 1.0
To: "[e-mail]" <[e-mail]>
Subject: Final Call for Papers - CQRE [Secure] networking
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by mail.proper.com id GAB11119
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Hallo!

Please accept my sincere appologies, if you receive this 
Final Call for Papers multiple times.

The mail is just to remind you that there are only !!! THREE !!! 
more weeks until the deadline for submission of extended 
abstracts on May 14th, 1999.

Recent news:
* best paper award at CQRE
* publication of proceedings in Springer's LNCS
* first invited speakers: 
   - Stephen Kent     (GTE)
   - Bruce Schneier   (Counterpane)
   - Helena Handschuh (Gemplus/ENST)

Best regards
    Detlef Huehnlein

***************************************************************
                  Final Call for Papers
            CQRE [Secure] Congress & Exhibition
        Duesseldorf, Germany, Nov. 30 - Dec. 2 1999
---------------------------------------------------------------
provides a new international forum covering most aspects of
information security with a special focus to the role of
information security in the context of rapidly evolving 
economic processes.
---------------------------------------------------------------
Deadline for submission of extended abstracts: May 14, 1999
CQRE - website: http://www.cqre.net (under construction)
CfP - at:       http://www.secunet.de/forum/cqre.html
mailing-list:   send mailto:[e-mail]
(where the subject is "subscribe" without paranthesis)
***************************************************************
The "CQRE [Secure] networking" provides a new international 
forum giving a close-up view on information security in the 
context of rapidly evolving economic processes. The 
unprecedented reliance on computer technology transformed 
the previous technical side-issue "information security" to 
a management problem requiring decisions of strategic
importance. Hence, the targeted audience represents decision 
makers from government, industry, commercial, and academic 
communities.

If you are developing solutions to problems relating to the 
protection of your country´s information infrastructure or 
a commercial enterprise, consider submitting a paper to the 
"CQRE [Secure] networking" conference.

We are looking for papers and panel discussions covering:

* electronic commerce
  - new business processes
  - secure business transactions
  - online merchandising
  - electronic payment / banking
  - innovative applications
* network security
  - virtual private networks
  - security aspects in internet utilization
  - security aspects in multimedia applications
  - intrusion detection systems
* legal aspects
  - digital signatures acts
  - privacy and anonymity
  - crypto regulation
  - liability
* corporate security
  - access control
  - secure teleworking
  - enterprise key management
  - IT-audit
  - risk / disaster management
  - security awareness and training
  - implementation, accreditation, and operation of secure systems
    in a government, business, or industry environment
* security technology
  - cryptography
  - public key infrastructures
  - chip card technology
  - biometrics
* trust management
  - evaluation of products and systems
  - international harmonization of security evaluation criterias
* standardization
* future perspectives

Any other contribution addressing the involvement of IT security 
in economic processes will be welcome.

Authors are invited to submit an extended abstract of their 
contribution to the program chair. The submissions should be 
original research results, survey articles or "high quality" 
case studies and position papers. Product advertisements are 
welcome for presentation, but will not be considered for the
proceedings. Manuscripts must be in English, and should not be 
more than 2.000 words. The extended abstracts should be in a 
form suitable for anonymous review, with no author names,
affiliations, acknowledgements or obvious references. 
Contributions must not be submitted in parallel to any conference 
or workshop that has proceedings. Separately, an abstract of 
the paper with no more than 200 words and with title, name and 
addresses (incl. an E-mail address) of the authors shall be 
submitted. In the case of multiple authors the contacting 
author must be clearly identified. We strongly encourage
electronic submission in Postscript format. The submissions 
must be in 11 pt format, use standard fonts or include the 
necessary fonts. Proposals for panel discussions should also be
sent to the program chair. Panels of interest include those that
present alternative/controversial viewpoints or those that 
encourage lively discussions of relevant issues. Panels that
are collections of unrefereed papers will not be considered.

Panel proposals should be a minimum of one page describing the 
subject matter, the appropriateness of the panel for this 
conference and should identify participants and their respective
viewpoints.

best paper award:
This award will be presented at CQRE to the authors of the best
paper to be selected by the program committee.

mailing list/ web-site:
If you want to receive emails with up to date information, please
send a brief mail to [e-mail]. You will find this call for 
papers and further information at http://www.secunet.de/forum/cqre.html.

publication:
The proceedings will be published by Springer-Verlag in the Lecture
Notes of Computer Science (LNCS) Series. The final papers must be
prepared as described in http://www.springer.de/comp/lncs/authors.html.

important dates:
deadline for submission of extended abstracts  May 14,  1999
deadline for submission of panel proposals     June 1,  1999
notification of acceptance                     June 25, 1999
deadline for submission of complete papers     July 30, 1999



program committee:
Johannes Buchmann  (TU Darmstadt)
Dirk Fox           (Secorvo)
Walter Fumy        (Siemens)
Ruediger Grimm     (GMD)
Helena Handschuh   (ENST/Gemplus)
Thomas Hoeren      (Uni Muenster)
Pil Joong Lee      (POSTECH)
Alfred Menezes     (U.o.Waterloo/Certicom)
David Naccache     (Gemplus)
Clifford Neumann   (USC)
Joachim Posegga    (German Telekom)
Mike Reiter        (Bell Labs)
Matt Robshaw       (RSA)
Richard Schlechter (EU-comm.)
Bruce Schneier     (Counterpane)
Tsuyoshi Takagi    (NTT)
Yiannis Tsiounis   (GTE Labs)
Michael Waidner    (IBM)
Moti Yung          (CERTCO)
Robert Zuccherato  (Entrust)

program chair:
Rainer Baumgart
secunet - Security Networks GmbH
Weidenauer Str. 223 - 225
57076 Siegen
Germany

Tel.: [phone]
Fax: [phone]
[e-mail]


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id FAA10018 for ietf-pkix-bks; Fri, 23 Apr 1999 05:05:12 -0700 (PDT)
Received: from edelweb.fr (edelweb.fr [193.51.12.16]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id FAA10009 for <[e-mail]>; Fri, 23 Apr 1999 05:04:55 -0700 (PDT)
Received: from champagne.edelweb.fr (localhost.edelweb.fr [127.0.0.1]) by edelweb.fr with ESMTP id OAA14395; Fri, 23 Apr 1999 14:03:15 +0200 (MET DST)
Received: from champagne.edelweb.fr (champagne.edelweb.fr [193.51.14.161]) by edelweb.fr (nospam/1.1); Fri, 23 Apr 1999 14:03:14 +0200 (MET DST)
Received: from emeriau.edelweb.fr (emeriau.edelweb.fr [193.51.14.5]) by champagne.edelweb.fr (8.6.10/8.6.6) with ESMTP id OAA05733; Fri, 23 Apr 1999 14:03:08 +0200
From: Peter Sylvester <[e-mail]>
Received: (sylvest@localhost) by emeriau.edelweb.fr (8.6.10/8.6.6) id OAA01367; Fri, 23 Apr 1999 14:03:08 +0200
Date: Fri, 23 Apr 1999 14:03:08 +0200
Message-Id: <[e-mail]>
To: [e-mail], [e-mail]
Subject: Re: Time-Stamp: Why not use several hashes?
Cc: [e-mail], [e-mail], [e-mail], [e-mail]
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

I support the request to have a SEQUENCE OF messageimprint in
a time stamp. 

Although this could be obtained by having a combined hash function,
this doesn't seem a good idea to me. If you add a new hash function,
the number of needed algorithm identifiers may double. 

Peter Sylvester







Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id XAA27793 for ietf-pkix-bks; Thu, 22 Apr 1999 23:29:49 -0700 (PDT)
Received: from ns.cmbchina.com ([202.96.161.112]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id XAA27789 for <[e-mail]>; Thu, 22 Apr 1999 23:29:47 -0700 (PDT)
Received: from cmbchina.com ([10.1.4.27]) by ns.cmbchina.com (Netscape Messaging Server 3.01)  with ESMTP id AAA3946 for <[e-mail]>; Fri, 23 Apr 1999 14:29:31 -0800
Message-ID: <[e-mail]>
Date: Fri, 23 Apr 1999 14:30:50 +0800
From: "Xiong Shao Jun" <[e-mail]>
Organization: China Merchants Bank
X-Mailer: Mozilla 4.04 [en] (Win95; I)
MIME-Version: 1.0
To: [e-mail]
Subject: sample PKIX message data ?
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Hi, folks, I'm doing some development on PKIX protocols. But I want to
know if there is
any sample PKIX message data available for test, of if there is any site
for protocol
comformality test.

Thanks in advance,

Xiong Shaojun



Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id XAA27727 for ietf-pkix-bks; Thu, 22 Apr 1999 23:24:52 -0700 (PDT)
Received: from mercury.softforum.co.kr ([210.124.178.130]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id XAA27723 for <[e-mail]>; Thu, 22 Apr 1999 23:24:48 -0700 (PDT)
Received: (from uucp@localhost) by mercury.softforum.co.kr (8.8.7/8.8.7) id AAA03162 for <[e-mail]>; Sat, 24 Apr 1999 00:27:13 +0900
Received: from earth(210.124.178.132) by mercury via smap (V2.1) id xma003160; Sat, 24 Apr 99 00:26:52 +0900
Received: from softforum.co.kr by earth.softforum.co.kr (8.8.8+Sun/SMI-SVR4) id PAA05810; Fri, 23 Apr 1999 15:21:14 +0900 (KST)
Message-ID: <[e-mail]>
Date: Fri, 23 Apr 1999 15:25:33 +0900
From: =?iso-8859-1?Q?=C0=CC=B5=BF=C8=A3?= <[e-mail]>
X-Mailer: Mozilla 4.5 [en] (Win98; I)
X-Accept-Language: en
MIME-Version: 1.0
To: ieft <[e-mail]>
Subject: Some term ambiguous on PKIX Roadmap
Content-Type: multipart/mixed; boundary="------------267F493D234CA87E6190FEE0"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

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


INTERNET DRAFT                PKIX Roadmap              26 February 1999



      For key management keys that are generated by the requester, the
      CA can send the user the requested public key, along with the CA's
      own private key, to encrypt some piece of data, and send it to the
      requester to be decrypted.  For example, the CA can generate some
      random challenge, and require some action to be taken after
      decryption (e.g., "decrypt this encrypted random number and send
      it back to me"). If the requester does not take the requested
      action, the CA concludes that the requester did not possess the
      private key, and the certificate is not issued.

      Another method of providing POP for key management keys is for the
      CA to generate the requested certificate, and then send it to the
      requester in encrypted form.  If the requester does not have
      access to the appropriate private key, the requester cannot
      decrypt the certificate, and thus cannot use it. After some period
      of time in which the certificate is not used, the CA will revoke
      the certificate.  (This only works if the certificate is not made
      available to any untrusted entities until after the requester has
      successfully decrypted it.)

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

      Above is 31page of PKIX Roadmap.
   
      What CA's own private key above context means?
      CA's private key is so meaningless to send to a new requester?
      Can I interpret it as somewhat like a session key?
      And encrypt the session key with the requester's public key..
      If the requester really have a corresponding private key, 
      he can get the session key.
      Is my interpretation right?
--------------267F493D234CA87E6190FEE0
Content-Type: text/x-vcard; charset=us-ascii;
 name="dhlee.vcf"
Content-Description: Card for À̵¿È£
Content-Disposition: attachment;
 filename="dhlee.vcf"
Content-Transfer-Encoding: 7bit

begin:vcard 
n:Lee;Dongho
tel;pager:015-7755-3705
tel;fax:[phone]
tel;home:02-962-2637
tel;work:02-3787-2031
x-mozilla-html:TRUE
fn;quoted-printable:=C0=CC=B5=BF=C8=A3
adr:;;;;;;
version:2.1
email;internet:[e-mail]
x-mozilla-cpt:;0
end:vcard

--------------267F493D234CA87E6190FEE0--



Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id TAA15069 for ietf-pkix-bks; Thu, 22 Apr 1999 19:57:08 -0700 (PDT)
Received: from po1.bbn.com (PO1.BBN.COM [192.1.50.38]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id TAA15060 for <[e-mail]>; Thu, 22 Apr 1999 19:57:07 -0700 (PDT)
Received: from [128.33.238.34] ([12.7.152.50]) by po1.bbn.com (8.9.1/8.9.1) with ESMTP id WAA28189; Thu, 22 Apr 1999 22:57:21 -0400 (EDT)
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Message-Id: <v04020a20b3458f4ad126@[128.33.238.34]>
In-Reply-To: <D1A949D4508DD1119C8100400533BEDC0BE987@DSG1>
Date: Thu, 22 Apr 1999 22:53:36 -0400
To: Alan Lloyd <[e-mail]>
From: Stephen Kent <[e-mail]>
Subject: RE: SEIS: Re: Certificates, Directories, and Distinguished Names
Cc: [e-mail], [e-mail]
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Alan,

I am puzzled by your comments.  Let me try one more time to clarify what I
said in my previous message.

<snip>

>> >Stephen - in all your words you never seem to come to grips with the
>> >fact that X.509 is not ambigious in so far that it permits systems to
>> be
>> >built without certificate extensions - and for those build such
>> systems
>> >to determine by local means or imply what is a EE or a CA cert and
>> what
>> >use that cert has (eg for message verification or cert
>> verification)..
>> >X.509 - was written some years ago and it correctly (a a standard
>> >should) provided a transition path to the use of cert extensions.
>>
>> Vome on Alan, we're talking about changes only with regard to X.509
>> v3.
>>
>	Groan --- Which happens to be specified in X.509. - the
>standard,

Version 1 of X.509 did not envision extensions; all it did was include a
version number, something that was left out of the CRL spec, by the way.
Our diccussion about how to mark CA certs applies ONLY to v3 certs, since
v1 certs failed to address this problem at all.  We're not talking about
how to fix v1 certs, only about how to make v3 certs unambiguous with
regard to CA marking.

>> >RFC 2459 came along some time later as a profile and just the fact
>> that
>> >people are discussing the issue in 2459 and it is unclear - means
>> there
>> >is a problem - in the Profile.
>>
>> 2459 did not come along much later than the adoption of X.509 v3. And,
>> no,
>> there is not a profile problem, as too many previous messages have
>> show in
>> detail.
>>
>	I was referring to the standard (X.509) was written earlier than
>the profiles .. thats a fact of life and common knowledge.
>
>	To respond to my point with pointless statement that tries to
>show me wrong me by changing context eg...
>	" 2459 did not come along much later than the adoption of X.509
>v3"
>	note the word "adoption" has been added to prove me wrong......

I used the word "adoption" to refer to final approval of X.509 v3, which
was fairly recent.  Both 2459 and X.509 v3 continued to evolve in parallel,
with each document making changes to reflect decisions in the other
standaards effort, so as to minimize differences between the two.  The term
adoption is perfectly appropriate here and is not some sort of trick to
change the topic. You argued that X.509 came first and thus has prority
over the 2459 profile.  Well, v3 of X.509 was not completed much before
2459, and as my example re the missing v1 CRL version number field points
out, being first and being a standard is no guarantee of correctness.

>
>	If this is the approach to logical debate - that is also used to
>debate technology issues , then one can see why these lists have
>difficulty.

Yes, this is a logical approach to debate.  Sorry if my choice of terms was
confusing, but I fear the real problem is deeper.

Steve


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id PAA03147 for ietf-pkix-bks; Thu, 22 Apr 1999 15:41:29 -0700 (PDT)
Received: from prv-mail20.provo.novell.com (prv-mail20.Provo.Novell.COM [137.65.40.4]) by mail.proper.com (8.8.8/8.8.5) with SMTP id PAA03143 for <[e-mail]>; Thu, 22 Apr 1999 15:41:28 -0700 (PDT)
Received: from INET-PRV-Message_Server by prv-mail20.provo.novell.com with Novell_GroupWise; Thu, 22 Apr 1999 16:42:03 -0600
Message-Id: <[e-mail]>
X-Mailer: Novell GroupWise 5.5
Date: Thu, 22 Apr 1999 16:41:55 -0600
From: "Bob Jueneman" <[e-mail]>
To: <[e-mail]>, <[e-mail]>
Cc: <[e-mail]>
Subject: Re: Delta CRL processing
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 mail.proper.com id PAA03144
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

I must be dense, Russ. The text you attached seems to agree precisely
with what Sharon said, and was exactly what I was requesting as well.

Sharon used the term "publish", not "issue", and the last paragraph 
certainly seems to be quite explicit in allowing that option, by differentiating 
between issuing and publishing.

Why do you disagree?  What am I missing? 

Bob


>>> Russ Housley <[e-mail]> 04/22/99 01:38PM >>>
>In a private message, Sharon Boeyen points out:
>
>  "As of the 1997 edition of X.509 a CA is NOT required to publish
>  a full CRL."

I disagree with Sharon.  X.509-1997 says: " ... It is the decision of a CA
as to whether to provide delta-CRLs. However, a delta-CRL shall not be
issued without a corresponding complete CRL being issued at the same time."
 I have attached the entire section on delta-CRLs from X.509-1997 at the
end of this message.

>I claim that not only does an X.509 CA not have to "publish" a full
>CRL, it also does not need to create a DER representation of the CRL
>or generate a signature of that DER.  The intent of the word "issue"
>is to ensure that at any point in time, there is a single, unique,
>unambiguous instance of a full CRL that would have been generated and
>published had the CA chosen to do so.  Or in other words, if an
>application reconstructs the revocation status for a certain point in
>time, it will always reconstruct the same status as would have been
>obtained had a full CRL been generated, published, and retrieved.  It
>must be impossible to take two different inputs (combinations of full,
>delta, and DP-partitioned CRLs) and arrive at conflicting conclusions
>as to the status of a given certificate.

Agree.

>This is analogous to the procedure for Certification Path Validation,
>which says:
>
>  "Conforming implementations ... are not required to implement this
>   algorithm, but shall be functionally equivalent to the external
>   behavior resulting from this procedure."
>
>Reference algorithms are often chosen to emphasize simplicity,
>correctness and tutorial value instead of operational efficiency.
>Optimizations may be applied as long as the optimized algorithm yields
>correct results.  The external result of CRL processing is the
>revocation status of a particular certificate at a particular time, and
>the correct answer is the one which would have been obtained from a
>full CRL.
>
>It would be perverse indeed to interpret X.509 as saying that optimized
>revocation methods are allowed, as long as you also perform the
>unoptimized reference method in parallel!
>

Russ


--- Begin Section 12.6.3.3 from X.509-1997 ---

12.6.3.3	Delta CRL indicator field

This CRL extension field identifies a CRL as being a delta-CRL only. This
field is defined as follows:

   deltaCRLIndicator EXTENSION ::= {
	SYNTAX		BaseCRLNumber
	IDENTIFIED BY 	id-ce-deltaCRLIndicator }
   BaseCRLNumber ::= CRLNumber

The value of type BaseCRLNumber identifies the CRL number of the base CRL
that was used as the starting point in the generation of this delta-CRL,
i.e. this delta-CRL contains the changes between the base CRL and the
complete CRL issued along with this delta-CRL. It is the decision of a CA
as to whether to provide delta-CRLs. However, a delta-CRL shall not be
issued without a corresponding complete CRL being issued at the same time.
The value of the CRL number, as conveyed in the CRL number extension field
(if present), shall be identical for both the delta-CRL and the
corresponding complete CRL. 

The CRL user constructing a locally held CRL from delta-CRLs shall consider
the constructed CRL incomplete and unusable if both the following
conditions are true:

-  the value of the CRLNumber of the received delta-CRL is more than one
greater than that of the CRLNumber of the delta-CRL last processed; and

-  the value of BaseCRLNumber of the received delta-crl has changed from
the BaseCRLNumber of the delta-CRL last processed.

This extension is always critical. A certificate user that does not
understand the use of delta-CRLs should not use a CRL containing this
extension, as the CRL may not be as complete as the user expects. CRLs not
containing critical extensions must contain all current CRL entries for the
issuing CA, including entries for all revoked user certificates and CA
certificates.

NOTE-It is the decision of the CA as to whether or not to distribute the
CRLs issued between two base CRLs. For example, it may be the policy of the
CA to distribute base CRLs via CD-ROM and delta-CRLs via an on-line service
such as the Directory. Although the CA had issued its CRL with the
associated  delta-CRL, it may be the CA's policy that the user shall
construct the current CRL by applying the delta-CRL to the base CRL held on
the CD-ROM.

--- End Section 12.6.3.3 from X.509-1997 ---


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id MAA00926 for ietf-pkix-bks; Thu, 22 Apr 1999 12:44:15 -0700 (PDT)
Received: from spyrus.com (mail.spyrus.com [207.212.34.30]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id MAA00922 for <[e-mail]>; Thu, 22 Apr 1999 12:44:14 -0700 (PDT)
Received: from rhousley_laptop.spyrus.com ([209.172.119.101]) by spyrus.com (8.7.6/8.7.3/arc) with SMTP id MAA12786; Thu, 22 Apr 1999 12:43:51 -0700 (PDT)
Message-Id: <4.1.19990422153903.009feb30@209.172.119.123>
X-Sender: rhousley@209.172.119.123 (Unverified)
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1 
Date: Thu, 22 Apr 1999 15:40:09 -0400
To: Francois Rousseau <[e-mail]>
From: Russ Housley <[e-mail]>
Subject: Re: Delta CRL processing
Cc: [e-mail]
In-Reply-To: <[e-mail]>
References: <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Francois:

Irt will still be a Proposed Draft Addendum, not a standard (yet).

Russ



At 03:34 PM 4/21/99 -0400, Francois Rousseau wrote:
>Note that Clause 12.6.3.3 on the Delta CRL indicator field in the Proposed
>Draft Amendment (PDAM) on X.509(97) was already clarifying part of this
>issue, however this item was discussed further at the last Directory
>Working Group meeting in Orlando.
>
>The revised Clause 12.6.3.3 in the Final PDAM (FPDAM) on X.509 (97) should
>soon be available. It will include a more precise explanation of the
>proposed rules for constructing delta-CRLs along with a more extensive
>example of their use.
>
>Francois Rousseau
>AEPOS Technologies



Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id MAA00856 for ietf-pkix-bks; Thu, 22 Apr 1999 12:37:41 -0700 (PDT)
Received: from spyrus.com (mail.spyrus.com [207.212.34.30]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id MAA00852 for <[e-mail]>; Thu, 22 Apr 1999 12:37:40 -0700 (PDT)
Received: from rhousley_laptop.spyrus.com ([209.172.119.101]) by spyrus.com (8.7.6/8.7.3/arc) with SMTP id MAA12644; Thu, 22 Apr 1999 12:37:18 -0700 (PDT)
Message-Id: <4.1.19990422153021.009fc1e0@209.172.119.123>
X-Sender: rhousley@209.172.119.123 (Unverified)
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1 
Date: Thu, 22 Apr 1999 15:38:26 -0400
To: "David P. Kemp" <[e-mail]>
From: Russ Housley <[e-mail]>
Subject: Re: Delta CRL processing
Cc: [e-mail]
In-Reply-To: <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

>In a private message, Sharon Boeyen points out:
>
>  "As of the 1997 edition of X.509 a CA is NOT required to publish
>  a full CRL."

I disagree with Sharon.  X.509-1997 says: " ... It is the decision of a CA
as to whether to provide delta-CRLs. However, a delta-CRL shall not be
issued without a corresponding complete CRL being issued at the same time."
 I have attached the entire section on delta-CRLs from X.509-1997 at the
end of this message.

>I claim that not only does an X.509 CA not have to "publish" a full
>CRL, it also does not need to create a DER representation of the CRL
>or generate a signature of that DER.  The intent of the word "issue"
>is to ensure that at any point in time, there is a single, unique,
>unambiguous instance of a full CRL that would have been generated and
>published had the CA chosen to do so.  Or in other words, if an
>application reconstructs the revocation status for a certain point in
>time, it will always reconstruct the same status as would have been
>obtained had a full CRL been generated, published, and retrieved.  It
>must be impossible to take two different inputs (combinations of full,
>delta, and DP-partitioned CRLs) and arrive at conflicting conclusions
>as to the status of a given certificate.

Agree.

>This is analogous to the procedure for Certification Path Validation,
>which says:
>
>  "Conforming implementations ... are not required to implement this
>   algorithm, but shall be functionally equivalent to the external
>   behavior resulting from this procedure."
>
>Reference algorithms are often chosen to emphasize simplicity,
>correctness and tutorial value instead of operational efficiency.
>Optimizations may be applied as long as the optimized algorithm yields
>correct results.  The external result of CRL processing is the
>revocation status of a particular certificate at a particular time, and
>the correct answer is the one which would have been obtained from a
>full CRL.
>
>It would be perverse indeed to interpret X.509 as saying that optimized
>revocation methods are allowed, as long as you also perform the
>unoptimized reference method in parallel!
>

Russ


--- Begin Section 12.6.3.3 from X.509-1997 ---

12.6.3.3	Delta CRL indicator field

This CRL extension field identifies a CRL as being a delta-CRL only. This
field is defined as follows:

   deltaCRLIndicator EXTENSION ::= {
	SYNTAX		BaseCRLNumber
	IDENTIFIED BY 	id-ce-deltaCRLIndicator }
   BaseCRLNumber ::= CRLNumber

The value of type BaseCRLNumber identifies the CRL number of the base CRL
that was used as the starting point in the generation of this delta-CRL,
i.e. this delta-CRL contains the changes between the base CRL and the
complete CRL issued along with this delta-CRL. It is the decision of a CA
as to whether to provide delta-CRLs. However, a delta-CRL shall not be
issued without a corresponding complete CRL being issued at the same time.
The value of the CRL number, as conveyed in the CRL number extension field
(if present), shall be identical for both the delta-CRL and the
corresponding complete CRL. 

The CRL user constructing a locally held CRL from delta-CRLs shall consider
the constructed CRL incomplete and unusable if both the following
conditions are true:

-  the value of the CRLNumber of the received delta-CRL is more than one
greater than that of the CRLNumber of the delta-CRL last processed; and

-  the value of BaseCRLNumber of the received delta-crl has changed from
the BaseCRLNumber of the delta-CRL last processed.

This extension is always critical. A certificate user that does not
understand the use of delta-CRLs should not use a CRL containing this
extension, as the CRL may not be as complete as the user expects. CRLs not
containing critical extensions must contain all current CRL entries for the
issuing CA, including entries for all revoked user certificates and CA
certificates.

NOTE-It is the decision of the CA as to whether or not to distribute the
CRLs issued between two base CRLs. For example, it may be the policy of the
CA to distribute base CRLs via CD-ROM and delta-CRLs via an on-line service
such as the Directory. Although the CA had issued its CRL with the
associated  delta-CRL, it may be the CA's policy that the user shall
construct the current CRL by applying the delta-CRL to the base CRL held on
the CD-ROM.

--- End Section 12.6.3.3 from X.509-1997 ---


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id MAA00536 for ietf-pkix-bks; Thu, 22 Apr 1999 12:16:51 -0700 (PDT)
Received: from aum (ip11.proper.com [165.227.249.11]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id MAA00532; Thu, 22 Apr 1999 12:16:44 -0700 (PDT)
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.33 (Beta)
Date: Thu, 22 Apr 1999 12:17:38 -0700
To: Stephen Kent <[e-mail]>, [e-mail]
From: Paul Hoffman / IMC <[e-mail]>
Subject: Re: WG Last call, redux
In-Reply-To: <v04020a15b34509844f3d@[128.33.238.34]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

At 01:24 PM 4/22/99 -0400, Stephen Kent wrote:
>Although the changes are largely editorial,
>designed to eliminate possible ambiguities, at least one substantive change
>was made and thus an abbreviated IETF and WG last call are being held, in
>parallel.

Care to give us a hint about the changes so that we can look at them in 
context in the draft?

--Paul Hoffman, Director
--Internet Mail Consortium


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id KAA28623 for ietf-pkix-bks; Thu, 22 Apr 1999 10:22:56 -0700 (PDT)
Received: from po1.bbn.com (PO1.BBN.COM [192.1.50.38]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id KAA28619 for <[e-mail]>; Thu, 22 Apr 1999 10:22:52 -0700 (PDT)
Received: from [128.33.238.34] (TC038.BBN.COM [128.33.238.38]) by po1.bbn.com (8.9.1/8.9.1) with ESMTP id NAA04502 for <[e-mail]>; Thu, 22 Apr 1999 13:23:49 -0400 (EDT)
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Message-Id: <v04020a15b34509844f3d@[128.33.238.34]>
Date: Thu, 22 Apr 1999 13:24:18 -0400
To: [e-mail]
From: Stephen Kent <[e-mail]>
Subject: WG Last call, redux
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Folks,

At my request, the OCSP document underwent some revisions after WG last
call, and IESG approval.  Although the changes are largely editorial,
designed to eliminate possible ambiguities, at least one substantive change
was made and thus an abbreviated IETF and WG last call are being held, in
parallel.  The WG is being explicitly notified of this last call to
expedite the process, but the notice from the IETF Secretariat will set the
officical closing date for comments.

Steve
----------------------------------




PKIX Working Group                               Michael Myers(VeriSign)
draft-ietf-pkix-ocsp-08.txt                         Rich Ankney (CertCo)
                                             Ambarish Malpani (ValiCert)
                                            Slava Galperin (Teknowledge)
                                   Carlisle Adams (Entrust Technologies)

Expires in 6 months                                           March 1999


                X.509 Internet Public Key Infrastructure
               Online Certificate Status Protocol - OCSP
                     <draft-ietf-pkix-ocsp-08.txt>


1.  Status of this Memo

   This document is an Internet-Draft and is in full conformance with
   all 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.

2.  Abstract

   This document specifies a protocol useful in determining the current
   status of a digital certificate without requiring CRLs. Additional
   mechanisms addressing PKIX operational requirements are specified in
   separate documents.

   An overview of the protocol is provided in section 3. Functional
   requirements are specified in section 4. Details of the protocol are
   in section 5. We cover security issues with the protocol in section
   6. Appendix A defines OCSP over HTTP, appendix B accumulates ASN.1
   syntactic elements and appendix C specifies the mime types for the
   messages.

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this


Myers, Ankney, Malpani, Galperin, Adams                         [Page 1]

INTERNET DRAFT                    OCSP                        March 1999



   document (in uppercase, as shown) are to be interpreted as described
   in [RFC2119].

3.  Protocol Overview

   In lieu of or as a supplement to checking against a periodic CRL, it
   may be necessary to obtain timely information regarding the
   revocation status of a certificate (cf. [RFC2459], Section 3.3).
   Examples include high-value funds transfer or large stock trades.

   The Online Certificate Status Protocol (OCSP) enables applications to
   determine the (revocation) state of an identified certificate. OCSP
   may be used to satisfy some of the operational requirements of
   providing more timely revocation information than is possible with
   CRLs and may also be used to obtain additional status information. An
   OCSP client issues a status request to an OCSP responder and suspends
   acceptance of the certificate in question until the responder
   provides a response.

   This protocol specifies the data that needs to be exchanged between
   an application checking the status of a certificate and the server
   providing that status.

3.1  Request

   An OCSP request contains the following data:

   -- protocol version
   -- service request
   -- target certificate identifier
   -- optional extensions which MAY be processed by the OCSP Responder

   Upon receipt of a request, an OCSP Responder determines if:

   1. the message is well formed

   2. the responder is configured to provide the requested service and

   3. the request contains the information needed by the responder
   If any one of the prior conditions are not met, the OCSP responder
   produces an error message; otherwise, it returns a definitive
   response.

3.2  Response

   OCSP responses can be of various types.  An OCSP response consists of
   a response type and the bytes of the actual response. There is one
   basic type of OCSP response that MUST be supported by all OCSP


Myers, Ankney, Malpani, Galperin, Adams                         [Page 2]

INTERNET DRAFT                    OCSP                        March 1999



   servers and clients. The rest of this section pertains only to this
   basic response type.

   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

   A definitive response message is composed of:

   -- version of the response syntax
   -- name of the responder
   -- responses for each of the certificates in a request
   -- optional extensions
   -- signature algorithm OID
   -- signature computed across hash of the response

   The response for each of the certificates in a request consists of

   -- target certificate identifier
   -- certificate status value
   -- response validity interval
   -- optional extensions

   This specification defines the following definitive response
   indicators for use in the certificate status value:

   -- good
   -- revoked
   -- unknown

   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


Myers, Ankney, Malpani, Galperin, Adams                         [Page 3]

INTERNET DRAFT                    OCSP                        March 1999



   the certificate being requested.

3.3  Exception Cases

   In case of errors, the OCSP Responder may return an error message.
   These messages are not signed. Errors can be of the following types:

   -- malformedRequest
   -- internalError
   -- tryLater
   -- sigRequired
   -- unauthorized

   A server produces the "malformedRequest" response if the request
   received does not conform to the OCSP syntax.

   The response "internalError" indicates that the OCSP responder
   reached an inconsistent internal state. The query should be retried,
   potentially with another responder.

   In the event that the OCSP responder is operational, but unable to
   return a status for the requested certificate, the "tryLater"
   response can be used to indicate that the service exists, but is
   temporarily unable to respond.

   The response "sigRequired" is returned in cases where the server
   requires the client sign the request in order to construct a
   response.

   The response "unauthorized" is returned in cases where the client is
   not authorized to make this query to this server.


3.4  Semantics of thisUpdate, nextUpdate and producedAt

   Responses can contain three times in them - thisUpdate, nextUpdate
   and producedAt. The semantics of these fields are:

   - thisUpdate: The time at which the status being indicated is
                 known to be correct
   - nextUpdate: The time at or before which newer information will
                 be available about the status of the certificate
   - producedAt: The time at which the OCSP responder signed this
                 response.

   If nextUpdate is not set, the responder is indicating that newer
   revocation information is available all the time.



Myers, Ankney, Malpani, Galperin, Adams                         [Page 4]

INTERNET DRAFT                    OCSP                        March 1999



3.5  Response Pre-production

   OCSP responders MAY pre-produce signed responses specifying the
   status of certificates at a specified time. The time at which the
   status was known to be correct SHALL be reflected in the thisUpdate
   field of the response. The time at or before which newer information
   will be available is reflected in the nextUpdate field, while the
   time at which the response was produced will appear in the producedAt
   field of the response.

3.6  OCSP Signature Authority Delegation

   The key that signs a certificate's status information need not be the
   same key that signed the certificate. A certificate's issuer
   explicitly delegates OCSP signing authority by issuing a certificate
   containing a unique value for extendedKeyUsage in the OCSP signer's
   certificate. This certificate MUST be issued directly to the
   responder by the cognizant CA.

3.7  CA Key Compromise

   If an OCSP responder knows that a particular CA's private key has
   been compromised, it MAY return the revoked state for all
   certificates issued by that CA.

4.  Functional Requirements

4.1  Certificate Content

   In order to convey to OCSP clients a well-known point of information
   access, CAs SHALL provide the capability to include the
   AuthorityInfoAccess extension (defined in [RFC2459], section 4.2.2.1)
   in certificates that can be checked using OCSP.  Alternatively, the
   accessLocation for the OCSP provider may be configured locally at the
   OCSP client.

   CAs that support an OCSP service, either hosted locally or provided
   by an Authorized Responder, MUST provide for the inclusion of a value
   for a uniformResourceIndicator (URI) accessLocation and the OID value
   id-ad-ocsp for the accessMethod in the AccessDescription SEQUENCE.

   The value of the accessLocation field in the subject certificate
   defines the transport (e.g. HTTP) used to access the OCSP responder
   and may contain other transport dependent information (e.g. a URL).






Myers, Ankney, Malpani, Galperin, Adams                         [Page 5]

INTERNET DRAFT                    OCSP                        March 1999



4.2  Signed Response Acceptance Requirements

   Prior to accepting a signed response as valid, OCSP clients SHALL
   confirm that:


   1. The certificate identified in a received response corresponds to
   that which was identified in the corresponding request;

   2. The signature on the response is valid;

   3. The identity of the signer matches the intended recipient of the
   request.

   4. The signer is currently authorized to sign the response.

   5. The time at which the status being indicated is known to be
   correct (thisUpdate) is sufficiently recent.

   6. When available, the time at or before which newer information will
   be available about the status of the certificate (nextUpdate) is
   greater than the current time.

5.  Detailed Protocol

   The ASN.1 syntax imports terms defined in [RFC2459]. For signature
   calculation, the data to be signed is encoded using the ASN.1
   distinguished encoding rules (DER) [X.690].

   ASN.1 EXPLICIT tagging is used as a default unless specified
   otherwise.

   The terms imported from elsewhere are: Extensions,
   CertificateSerialNumber, SubjectPublicKeyInfo, Name,
   AlgorithmIdentifier, CRLReason

5.1  Requests

   This section specifies the ASN.1 specification for a confirmation
   request. The actual formatting of the message could vary depending on
   the transport mechanism used (HTTP, SMTP, LDAP, etc.).

5.1.1  Request Syntax

   OCSPRequest     ::=     SEQUENCE {
       tbsRequest                  TBSRequest,
       optionalSignature   [0]     EXPLICIT Signature OPTIONAL }



Myers, Ankney, Malpani, Galperin, Adams                         [Page 6]

INTERNET DRAFT                    OCSP                        March 1999



   TBSRequest      ::=     SEQUENCE {
       version             [0]     EXPLICIT Version DEFAULT v1,
       requestorName       [1]     EXPLICIT GeneralName OPTIONAL,
       requestList                 SEQUENCE OF Request,
       requestExtensions   [2]     EXPLICIT Extensions OPTIONAL }

   Signature       ::=     SEQUENCE {
       signatureAlgorithm      AlgorithmIdentifier,
       signature               BIT STRING,
       certs               [0] EXPLICIT SEQUENCE OF Certificate OPTIONAL}

   Version         ::=             INTEGER  {  v1(0) }

   Request         ::=     SEQUENCE {
       reqCert                     CertID,
       singleRequestExtensions     [0] EXPLICIT Extensions OPTIONAL }

   CertID          ::=     SEQUENCE {
       hashAlgorithm       AlgorithmIdentifier,
       issuerNameHash      OCTET STRING, -- Hash of Issuer's DN
       issuerKeyHash       OCTET STRING, -- Hash of Issuers public key
       serialNumber        CertificateSerialNumber }

   issuerNameHash is the hash of the Issuer's distinguished name. The
   hash shall be calculated over the DER encoding of the issuer's name
   field in the certificate being checked. issuerKeyHash is the hash of
   the Issuer's public key. The hash shall be calculated over the value
   (excluding tag and length) of the subject public key field in the
   issuer's certificate. The hash algorithm used for both these hashes,
   is identified in hashAlgorithm. serialNumber is the serial number of
   the certificate for which status is being requested.

5.1.2  Notes on the Request Syntax

   The primary reason to use the hash of the CA's public key in addition
   to the hash of the CA's name, to identify the issuer, is that it is
   possible that two CAs may choose to use the same Name (uniqueness in
   the Name is a recommendation that cannot be enforced). Two CAs will
   never, however, have the same public key unless the CAs either
   explicitly decided to share their private key, or the key of one of
   the CAs was compromised.

   Support for any specific extension is OPTIONAL. The critical flag
   SHOULD NOT be set for any of them.  Section 5.4 suggests several
   useful extensions.  Additional extensions MAY be defined in
   additional RFCs. Unrecognized extensions MUST be ignored (unless they
   have the critical flag set and are not understood).



Myers, Ankney, Malpani, Galperin, Adams                         [Page 7]

INTERNET DRAFT                    OCSP                        March 1999



   The requestor MAY choose to sign the OCSP request. In that case, the
   signature is computed over the tbsRequest structure. If the request
   is signed, the requestor SHALL specify its name in the requestorName
   field. Also, for signed requests, the requestor MAY include
   certificates that help the OCSP responder verify the requestor's
   signature in the certs field of Signature.


5.2  Response Syntax

   This section specifies the ASN.1 specification for a confirmation
   response. The actual formatting of the message could vary depending
   on the transport mechanism used (HTTP, SMTP, LDAP, etc.).

5.2.1  ASN.1 Specification of the OCSP Response

   An OCSP response at a minimum consists of a responseStatus field
   indicating the processing status of the prior request. If the value
   of responseStatus is one of the error conditions, responseBytes are
   not set.

   OCSPResponse ::= SEQUENCE {
      responseStatus         OCSPResponseStatus,
      responseBytes          [0] EXPLICIT ResponseBytes OPTIONAL }

   OCSPResponseStatus ::= ENUMERATED {
       successful            (0),  --Response has valid confirmations
       malformedRequest      (1),  --Illegal confirmation request
       internalError         (2),  --Internal error in issuer
       tryLater              (3),  --Try again later
                                   --(4) is not used
       sigRequired           (5),  --Must sign the request
       unauthorized          (6)   --Request unauthorized
   }

   The value for responseBytes consists of an OBJECT IDENTIFIER and a
   response syntax identified by that OID encoded as an OCTET STRING:

   ResponseBytes ::=       SEQUENCE {
       responseType   OBJECT IDENTIFIER,
       response       OCTET STRING }

   For a basic OCSP responder, responseType will be id-pkix-ocsp-basic:

   id-pkix-ocsp           OBJECT IDENTIFIER ::= { id-ad-ocsp }
   id-pkix-ocsp-basic     OBJECT IDENTIFIER ::= { id-pkix-ocsp 1 }

   OCSP responders SHALL be capable of producing responses of the id-


Myers, Ankney, Malpani, Galperin, Adams                         [Page 8]

INTERNET DRAFT                    OCSP                        March 1999



   pkix-ocsp-basic response type. Correspondingly, OCSP clients SHALL be
   capable of receiving and processing responses of the id-pkix-ocsp-
   basic response type.

   The value for response SHALL be the DER encoding of
   BasicOCSPResponse:

   BasicOCSPResponse       ::= SEQUENCE {
      tbsResponseData      ResponseData,
      signatureAlgorithm   AlgorithmIdentifier,
      signature            BIT STRING,
      certs                [0] EXPLICIT SEQUENCE OF Certificate OPTIONAL }

   The value for signature SHALL be computed on the hash of the DER
   encoding ResponseData.

   ResponseData ::= SEQUENCE {
      version              [0] EXPLICIT Version DEFAULT v1,
      responderID              ResponderID,
      producedAt               GeneralizedTime,
      responses                SEQUENCE OF SingleResponse,
      responseExtensions   [1] EXPLICIT Extensions OPTIONAL }

   ResponderID ::= CHOICE {
      byName               [1] Name,
      byKey                [2] KeyHash }

   KeyHash ::= OCTET STRING -- SHA-1 hash of responder's public key
   (excluding the tag and length fields)

   SingleResponse ::= SEQUENCE {
      certID                       CertID,
      certStatus                   CertStatus,
      thisUpdate                   GeneralizedTime,
      nextUpdate         [0]       EXPLICIT GeneralizedTime OPTIONAL,
      singleExtensions   [1]       EXPLICIT Extensions OPTIONAL }

   CertStatus ::= CHOICE {
       good        [0]     IMPLICIT NULL,
       revoked     [1]     IMPLICIT RevokedInfo,
       unknown     [2]     IMPLICIT UnknownInfo }

   RevokedInfo ::= SEQUENCE {
       revocationTime              GeneralizedTime,
       revocationReason    [0]     EXPLICIT CRLReason OPTIONAL }

   UnknownInfo ::= NULL -- this can be replaced with an enumeration



Myers, Ankney, Malpani, Galperin, Adams                         [Page 9]

INTERNET DRAFT                    OCSP                        March 1999



5.2.2  Notes on OCSP Responses

5.2.2.1  Time

   The thisUpdate and nextUpdate fields define a recommended validity
   interval. This interval corresponds to the {thisUpdate, nextUpdate}
   interval in CRLs. Responses whose nextUpdate value is earlier than
   the local system time value SHOULD be considered unreliable.
   Responses whose thisUpdate time is later than the local system time
   SHOULD be considered unreliable. Responses where the nextUpdate value
   is not set are equivalent to a CRL with no time for nextUpdate (see
   Section 3.4).

   The producedAt time is the time at which this response was signed.

5.2.2.2  Authorized Responders

   The key that signs a certificate's status information need not be the
   same key that signed the certificate. It is necessary however to
   ensure that the entity signing this information is authorized to do
   so.  Therefore, a certificate's issuer MUST either sign the OCSP
   responses itself or it MUST explicitly designate this authority to
   another entity.  OCSP signing delegation SHALL be designated by the
   inclusion of id-kp-OCSPSigning in an extendedKeyUsage certificate
   extension included in the OCSP response signer's certificate.  This
   certificate MUST be issued directly by the CA that issued the
   certificate in question.

   id-kp-OCSPSigning OBJECT IDENTIFIER ::= {id-kp 9}

   Systems or applications that rely on OCSP responses MUST be capable
   of detecting and enforcing use of the id-ad-ocspSigning value as
   described above. They MAY provide a means of locally configuring one
   or more OCSP signing authorities, and specifying the set of CAs for
   which each signing authority is trusted. They MUST reject the
   response if the certificate required to validate the signature on the
   response fails to meet at least one of the following criteria:

   1. Matches a local configuration of OCSP signing authority for the
    certificate in question; or

   2. Is the certificate of the CA that issued the certificate in
    question; or

   3. Includes a value of id-ad-ocspSigning in an ExtendedKeyUsage
    extension and is issued by the CA that issued the certificate in
    question."



Myers, Ankney, Malpani, Galperin, Adams                        [Page 10]

INTERNET DRAFT                    OCSP                        March 1999



   Additional acceptance or rejection criteria may apply to either the
   response itself or to the certificate used to validate the signature
   on the response.


5.2.2.2.1  Revocation Checking of an Authorized Responder

   Since an Authorized OCSP responder provides status information for
   one or more CAs, OCSP clients need to know how to check that an
   authorized responder's certificate has not been revoked. CAs may
   choose to deal with this problem in one of three ways:

   - A CA may specify that an OCSP client can trust a responder for the
   lifetime of the responder's certificate. The CA does so by including
   the extension id-pkix-ocsp-nocheck. This SHOULD be a non-critical
   extension. The value of the extension should be NULL. CAs issuing
   such a certificate should realized that a compromise of the
   responder's key, is as serious as the compromise of a CA key used to
   sign CRLs, at least for the validity period of this certificate. CA's
   may choose to issue this type of certificate with a very short
   lifetime and renew it frequently.

   id-pkix-ocsp-nocheck OBJECT IDENTIFIER ::= { id-pkix-ocsp 5 }

   - A CA may specify how the responder's certificate be checked for
   revocation. This can be done using CRL Distribution Points if the
   check should be done using CRLs or CRL Distribution Points, or
   Authority Information Access if the check should be done in some
   other way. Details for specifying either of these two mechanisms are
   available in [RFC2459].

   - A CA may choose not to specify any method of revocation checking
   for the responder's certificate, in which case, it would be up to the
   OCSP client's local security policy to decide whether that
   certificate should be checked for revocation or not.

5.3  Mandatory and Optional Cryptographic Algorithms

   Clients that request OCSP services SHALL be capable of processing
   responses signed used DSA keys identified by the DSA sig-alg-oid
   specified in section 7.2.2 of [RFC2459]. Clients SHOULD also be
   capable of processing RSA signatures as specified in section 7.2.1 of
   [RFC2459]. OCSP responders SHALL support the SHA1 hashing algorithm.

5.4  Extensions

   This section defines some standard extensions, based on the extension
   model employed in X.509 version 3 certificates see [RFC2459]. Support


Myers, Ankney, Malpani, Galperin, Adams                        [Page 11]

INTERNET DRAFT                    OCSP                        March 1999



   for all extensions is optional for both clients and responders.  For
   each extension, the definition indicates its syntax, processing
   performed by the OCSP Responder, and any extensions which are
   included in the corresponding response.

5.4.1  Nonce

   The nonce cryptographically binds a request and a response to prevent
   replay attacks. The nonce is included as one of the requestExtensions
   in requests, while in responses it would be included as one of the
   responseExtensions. In both the request and the response, the nonce
   will be identified by the object identifier id-pkix-ocsp-nonce, while
   the extnValue is the value of the nonce.

   id-pkix-ocsp-nonce     OBJECT IDENTIFIER ::= { id-pkix-ocsp 2 }


5.4.2  CRL References

   It may be desirable for the OCSP responder to indicate the CRL on
   which a revoked or onHold certificate is found. This can be useful
   where OCSP is used between repositories, and also as an auditing
   mechanism. The CRL may be specified by a URL (the URL at which the
   CRL is available), a number (CRL number) or a time (the time at which
   the relevant CRL was created). These extensions will be specified as
   singleExtensions. The identifier for this extension will be id-pkix-
   ocsp-crl, while the value will be CrlID.

   id-pkix-ocsp-crl       OBJECT IDENTIFIER ::= { id-pkix-ocsp 3 }

   CrlID ::= SEQUENCE {
      crlUrl               [0]     EXPLICIT IA5String OPTIONAL,
      crlNum               [1]     EXPLICIT INTEGER OPTIONAL,
      crlTime              [2]     EXPLICIT GeneralizedTime OPTIONAL }

   For the choice crlUrl, the IA5String will specify the URL at which
   the CRL is available. For crlNum, the INTEGER will specify the value
   of the CRL number extension of the relevant CRL. For crlTime, the
   GeneralizedTime will indicate the time at which the relevant CRL was
   issued.

5.4.3  Acceptable Response Types

   An OCSP client MAY wish to specify the kinds of response types it
   understands. To do so, it SHOULD use an extension with the OID id-
   pkix-ocsp-response, and the value AcceptableResponses.  This
   extension is included as one of the requestExtensions in requests.
   The OIDs included in AcceptableResponses are the OIDs of the various


Myers, Ankney, Malpani, Galperin, Adams                        [Page 12]

INTERNET DRAFT                    OCSP                        March 1999



   response types this client can accept (e.g., id-pkix-ocsp-basic).

   id-pkix-ocsp-response  OBJECT IDENTIFIER ::= { id-pkix-ocsp 4 }

   AcceptableResponses ::= SEQUENCE OF OBJECT IDENTIFIER

   As noted in section 5.2.1, OCSP responders SHALL be capable of
   responding with responses of the id-pkix-ocsp-basic response type.
   Correspondingly, OCSP clients SHALL be capable of receiving and
   processing responses of the id-pkix-ocsp-basic response type.

5.4.4  Archive Cutoff

   An OCSP responder MAY choose to retain revocation information beyond
   a certificate's expiration. The date obtained by subtracting this
   retention interval value from the producedAt time in a response is
   defined as the certificate's "archive cutoff" date.

   OCSP-enabled applications would use an OCSP archive cutoff date to
   contribute to a proof that a digital signature was (or was not)
   reliable on the date it was produced even if the certificate needed
   to validate the signature has long since expired.

   OCSP servers that provide support for such historical reference
   SHOULD include an archive cutoff date extension in responses.  If
   included, this value SHALL be provided as an OCSP singleExtensions
   extension identified by id-pkix-ocsp-archive-cutoff and of syntax
   GeneralizedTime:

   id-pkix-ocsp-archive-cutoff  OBJECT IDENTIFIER ::= { id-pkix-ocsp 6 }

   ArchiveCutoff ::= GeneralizedTime

   To illustrate, if a server is operated with a 7-year retention
   interval policy and status was produced at time t1 then the value for
   ArchiveCutoff in the response would be (t1 - 7 years).

5.4.5  CRL Entry Extensions

   All the extensions specified as CRL Entry Extensions - in Section 5.3
   of [RFC2459] - are also supported as singleExtensions.

5.4.6  Service Locator

   An OCSP server may be operated in a mode whereby the server receives
   a request and routes it to the OCSP server which is known to be
   authoritative for the identified certificate.  The serviceLocator
   request extension is defined for this purpose.  This extension is


Myers, Ankney, Malpani, Galperin, Adams                        [Page 13]

INTERNET DRAFT                    OCSP                        March 1999



   included as one of the singleRequestExtensions in requests.

   id-pkix-ocsp-service-locator OBJECT IDENTIFIER ::= { id-pkix-ocsp 7 }

   ServiceLocator ::= SEQUENCE {
       issuer    Name,
       locator   AuthorityInfoAccessSyntax OPTIONAL }

   Values for these fields are obtained from the corresponding fields in
   the subject certificate.

6.  Security Considerations

   For this service to be effective, certificate using systems must
   connect to the certificate status service provider. In the event such
   a connection cannot be obtained, certificate-using systems could
   implement CRL processing logic as a fall-back position.

   A denial of service vulnerability is evident with respect to a flood
   of queries. The production of a cryptographic signature significantly
   affects response generation cycle time, thereby exacerbating the
   situation. Unsigned error responses open up the protocol to another
   denial of service attack, where the attacker sends false error
   responses.

   The use of precomputed responses allows replay attacks in which an
   old (good) response is replayed prior to its expiration date but
   after the certificate has been revoked. Deployments of OCSP should
   carefully evaluate the benefit of precomputed responses against the
   probability of a replay attack and the costs associated with its
   successful execution.

   Requests do not contain the responder they are directed to. This
   allows an attacker to replay a request to any number of OCSP
   responders.

   The reliance of HTTP caching in some deployment scenarios may result
   in unexpected results if intermediate servers are incorrectly
   configured or are known to possess cache management faults.
   Implementors are advised to take the reliability of HTTP cache
   mechanisms into account when deploying OCSP over HTTP.

7.  References

   [RFC2459] Internet X.509 Public Key Infrastructure Certificate and
             CRL Profile, R. Housley, W. Ford, W. Polk, D. Solo, RFC
             2459, January, 1999.



Myers, Ankney, Malpani, Galperin, Adams                        [Page 14]

INTERNET DRAFT                    OCSP                        March 1999



      [HTTP] Hypertext Transfer Protocol -- HTTP/1.1, R. Fielding, J.
             Gettys, J. Mogul, H. Frystyk and T. Berners-Lee, RFC 2068,
             January 1997.

   [RFC2119] Key words for use in RFCs to Indicate Requirement Levels,
             S. Bradner, RFC 2119, March 1997.

       [URL] Uniform Resource Locators (URL), T. Berners-Lee, L.
             Masinter, M.  McCahill, RFC 1738, December 1994.

     [X.690] ITU-T Recommendation X.690 (1994) | ISO/IEC 8825-1:1995,
             Information Technology - ASN.1 encoding rules:
             Specification of Basic Encoding Rules (BER), Canonical
             Encoding Rules (CER) and Distinguished Encoding Rules
             (DER).

8.  Author's Address

   Michael Myers
   VeriSign, Inc.
   1390 Shorebird Way
   Mountain View, CA 94019
   [e-mail]

   Rich Ankney
   CertCo, LLC
   13506 King Charles Dr.
   Chantilly, VA  20151
   [e-mail]

   Ambarish Malpani
   ValiCert, Inc.
   3160 W. Bayshore Drive
   Palo Alto, CA 94303
   [e-mail]
   650.567.5457

   Slava Galperin
   Teknowledge Corporation
   1810 Embarcadero Road
   Palo Alto, CA
   [e-mail]

   Carlisle Adams
   Entrust Technologies
   750 Heron Road, Suite E08
   Ottawa, Ontario
   K1V 1A7


Myers, Ankney, Malpani, Galperin, Adams                        [Page 15]

INTERNET DRAFT                    OCSP                        March 1999



   Canada
   [e-mail]



Appendix A

A.1 OCSP over HTTP

   This section describes the formatting that will be done to the request
   and response to support HTTP.

A.1.1 Request

   HTTP based OCSP requests can use either the GET or the POST method to
   submit their requests. To enable HTTP caching, small requests (that
   after encoding are less than 255 bytes), MAY be submitted using GET. If
   HTTP caching is not important, or the request is greater than 255 bytes,
   the request SHOULD be submitted using POST.  Where privacy is a
   requirement, OCSP transactions exchanged using HTTP MAY be protected
   using either TLS/SSL or some other lower layer protocol.

   An OCSP request using the GET method is constructed as follows:

   GET {url}/{url-encoding of base-64 encoding of the DER encoding of the
   OCSPRequest}

   where {url} may be derived from the value of AuthorityInfoAccess or
   other local configuration of the OCSP client.

   An OCSP request using the POST method is constructed as follows: The
   Content-Type header has the value "application/ocsp-request" while the
   body of the message is the binary value of the DER encoding of the
OCSPRequest.

A.1.2 Response

   An HTTP-based OCSP response is composed of the appropriate HTTP
   headers, followed by the binary value of the DER encoding of the
   OCSPResponse. The Content-Type header has the value
   "application/ocsp-response". The Content-Length header SHOULD specify
   the length of the response. Other HTTP headers MAY be present and MAY
   be ignored if not understood by the requestor.

Appendix B:  OCSP in ASN.1

   OCSP DEFINITIONS EXPLICIT TAGS::=

   BEGIN


Myers, Ankney, Malpani, Galperin, Adams                        [Page 16]

INTERNET DRAFT                    OCSP                        March 1999



   IMPORTS

         -- Directory Authentication Framework (X.509)
                Certificate, AlgorithmIdentifier, CRLReason
                FROM AuthenticationFramework { joint-iso-itu-t ds(5)
                         module(1) authenticationFramework(7) 3 }


   -- PKIX Certificate Extensions
                AuthorityInfoAccessSyntax
             FROM PKIX1Implicit88 {iso(1) identified-organization(3)
                     dod(6) internet(1) security(5) mechanisms(5) pkix(7)
                     id-mod(0) id-pkix1-implicit-88(2)}


             Name, GeneralName, CertificateSerialNumber, Extensions,
              id-kp, id-ad-ocsp
                FROM PKIX1Explicit88 {iso(1) identified-organization(3)
                     dod(6) internet(1) security(5) mechanisms(5) pkix(7)
                     id-mod(0) id-pkix1-explicit-88(1)};

   OCSPRequest     ::=     SEQUENCE {
       tbsRequest                  TBSRequest,
       optionalSignature   [0]     EXPLICIT Signature OPTIONAL }

   TBSRequest      ::=     SEQUENCE {
       version             [0] EXPLICIT Version DEFAULT v1,
       requestorName       [1] EXPLICIT GeneralName OPTIONAL,
       requestList             SEQUENCE OF Request,
       requestExtensions   [2] EXPLICIT Extensions OPTIONAL }

   Signature       ::=     SEQUENCE {
       signatureAlgorithm   AlgorithmIdentifier,
       signature            BIT STRING,
       certs                [0] EXPLICIT SEQUENCE OF Certificate OPTIONAL }

   Version  ::=  INTEGER  {  v1(0) }

   Request ::=     SEQUENCE {
       reqCert                    CertID,
       singleRequestExtensions    [0] EXPLICIT Extensions OPTIONAL }

   CertID ::= SEQUENCE {
       hashAlgorithm            AlgorithmIdentifier,
       issuerNameHash     OCTET STRING, -- Hash of Issuer's DN
       issuerKeyHash      OCTET STRING, -- Hash of Issuers public key
       serialNumber       CertificateSerialNumber }



Myers, Ankney, Malpani, Galperin, Adams                        [Page 17]

INTERNET DRAFT                    OCSP                        March 1999



   OCSPResponse ::= SEQUENCE {
      responseStatus         OCSPResponseStatus,
      responseBytes          [0] EXPLICIT ResponseBytes OPTIONAL }

   OCSPResponseStatus ::= ENUMERATED {
       successful            (0),      --Response has valid confirmations
       malformedRequest      (1),      --Illegal confirmation request
       internalError         (2),      --Internal error in issuer
       tryLater              (3),      --Try again later
                                       --(4) is not used
       sigRequired           (5),      --Must sign the request
       unauthorized          (6)       --Request unauthorized
   }

   ResponseBytes ::=       SEQUENCE {
       responseType   OBJECT IDENTIFIER,
       response       OCTET STRING }

   BasicOCSPResponse       ::= SEQUENCE {
      tbsResponseData      ResponseData,
      signatureAlgorithm   AlgorithmIdentifier,
      signature            BIT STRING,
      certs                [0] EXPLICIT SEQUENCE OF Certificate OPTIONAL }

   ResponseData ::= SEQUENCE {
      version              [0] EXPLICIT Version DEFAULT v1,
      responderID              ResponderID,
      producedAt               GeneralizedTime,
      responses                SEQUENCE OF SingleResponse,
      responseExtensions   [1] EXPLICIT Extensions OPTIONAL }

   ResponderID ::= CHOICE {
      byName   [1] Name,
      byKey    [2] KeyHash }

   KeyHash ::= OCTET STRING --SHA-1 hash of responder's public key
                            --(excluding the tag and length fields)

   SingleResponse ::= SEQUENCE {
      certID                       CertID,
      certStatus                   CertStatus,
      thisUpdate                   GeneralizedTime,
      nextUpdate           [0]     EXPLICIT GeneralizedTime OPTIONAL,
      singleExtensions     [1]     EXPLICIT Extensions OPTIONAL }

   CertStatus ::= CHOICE {
       good                [0]     IMPLICIT NULL,
       revoked             [1]     IMPLICIT RevokedInfo,


Myers, Ankney, Malpani, Galperin, Adams                        [Page 18]

INTERNET DRAFT                    OCSP                        March 1999



       unknown             [2]     IMPLICIT UnknownInfo }

   RevokedInfo ::= SEQUENCE {
       revocationTime              GeneralizedTime,
       revocationReason    [0]     EXPLICIT CRLReason OPTIONAL }

   UnknownInfo ::= NULL -- this can be replaced with an enumeration

   ArchiveCutoff ::= GeneralizedTime

   AcceptableResponses ::= SEQUENCE OF OBJECT IDENTIFIER

   ServiceLocator ::= SEQUENCE {
       issuer    Name,
       locator   AuthorityInfoAccessSyntax }

   -- Object Identifiers

   id-kp-OCSPSigning            OBJECT IDENTIFIER ::= { id-kp 9 }
   id-pkix-ocsp                 OBJECT IDENTIFIER ::= { id-ad-ocsp }
   id-pkix-ocsp-basic           OBJECT IDENTIFIER ::= { id-pkix-ocsp 1 }
   id-pkix-ocsp-nonce           OBJECT IDENTIFIER ::= { id-pkix-ocsp 2 }
   id-pkix-ocsp-crl             OBJECT IDENTIFIER ::= { id-pkix-ocsp 3 }
   id-pkix-ocsp-response        OBJECT IDENTIFIER ::= { id-pkix-ocsp 4 }
   id-pkix-ocsp-nocheck         OBJECT IDENTIFIER ::= { id-pkix-ocsp 5 }
   id-pkix-ocsp-archive-cutoff  OBJECT IDENTIFIER ::= { id-pkix-ocsp 6 }
   id-pkix-ocsp-service-locator OBJECT IDENTIFIER ::= { id-pkix-ocsp 7 }


   END

Appendix C: MIME registrations

C.1 application/ocsp-request

   To: [e-mail]
   Subject: Registration of MIME media type application/ocsp-request

   MIME media type name: application

   MIME subtype name: ocsp-request

   Required parameters: None

   Optional parameters: None

   Encoding considerations: binary



Myers, Ankney, Malpani, Galperin, Adams                        [Page 19]

INTERNET DRAFT                    OCSP                        March 1999



   Security considerations: Carries a  request for information. This
   request may optionally be cryptographically signed.

   Interoperability considerations: None

   Published specification: IETF PKIX Working Group Draft on Online
   Certificate Status Protocol - OCSP

   Applications which use this media type: OCSP clients

   Additional information:

     Magic number(s): None
     File extension(s): .ORQ
     Macintosh File Type Code(s): none

   Person & email address to contact for further information:
   Ambarish Malpani <[e-mail]>

   Intended usage: COMMON

   Author/Change controller:
   Ambarish Malpani <[e-mail]>

C.2 application/ocsp-response

   To: [e-mail]
   Subject: Registration of MIME media type application/ocsp-response

   MIME media type name: application

   MIME subtype name: ocsp-response

   Required parameters: None

   Optional parameters: None
   Encoding considerations: binary

   Security considerations: Carries a cryptographically signed
   response

   Interoperability considerations: None

   Published specification: IETF PKIX Working Group Draft on Online
   Certificate Status Protocol - OCSP

   Applications which use this media type: OCSP servers



Myers, Ankney, Malpani, Galperin, Adams                        [Page 20]

INTERNET DRAFT                    OCSP                        March 1999



   Additional information:

   Magic number(s): None
   File extension(s): .ORS
   Macintosh File Type Code(s): none

   Person & email address to contact for further information:
   Ambarish Malpani <[e-mail]>

   Intended usage: COMMON

   Author/Change controller:
   Ambarish Malpani <[e-mail]>





































Myers, Ankney, Malpani, Galperin, Adams                        [Page 21]


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id HAA26012 for ietf-pkix-bks; Thu, 22 Apr 1999 07:10:57 -0700 (PDT)
Received: from eastwood.aldigital.algroup.co.uk (eastwood.aldigital.algroup.co.uk [194.128.162.193]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id HAA26008 for <[e-mail]>; Thu, 22 Apr 1999 07:10:55 -0700 (PDT)
Received: from freeby.ben.algroup.co.uk (freeby.ben.algroup.co.uk [193.133.15.6]) by eastwood.aldigital.algroup.co.uk (8.8.8/8.6.12) with ESMTP id OAA20096; Thu, 22 Apr 1999 14:11:34 GMT
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 PAA03673; Thu, 22 Apr 1999 15:11:50 +0100
Message-ID: <[e-mail]>
Date: Thu, 22 Apr 1999 15:11:32 +0100
From: Ben Laurie <[e-mail]>
Organization: A.L. Group plc
X-Mailer: Mozilla 4.08 [en] (WinNT; I)
MIME-Version: 1.0
To: Denis Pinkas <[e-mail]>
CC: Stefan Santesson <[e-mail]>, [e-mail]
Subject: Re: New proposed solution to the QC biometric issue
References: <[e-mail]> <[e-mail]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Denis Pinkas wrote:
> My comments are along the lines.
> > I have given this quite a thought the last days and I must say that I would favor an OPTIONAL URI pointer.
> 
> Also I do not feel strong on this issue, I would favor the opposite. :-(
> 
> The rational is as follows:
> 
> 1) This data is private and may be released onbly if the subject wishes it. So it is very unlikely that you will find it in an URL free of access.

What has this got to do with anything? Or are you suggesting that not
revealing the URL will secure it?

> 2) If the indication to fetch the information points to one of out several places, some people are going to argue that a sequence of such info is needed.

So give them a sequence! Is there a shortage or something?

> The basic question is whether the certificate should refer to the location of the biometric data or whether the biometric data should refer to the information in the certificate. I would think that the opposite is more meaningful.

Which one is the opposite? If you mean that the biometric data should
refer to the cert, how do I find it when all I have in my hand is a
cert?

Cheers,

Ben.

--
http://www.apache-ssl.org/ben.html

"My grandfather once told me that there are two kinds of people: those
who work and those who take the credit. He told me to try to be in the
first group; there was less competition there."
     - Indira Gandhi


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id GAA25312 for ietf-pkix-bks; Thu, 22 Apr 1999 06:13:16 -0700 (PDT)
Received: from clbull.frcl.bull.fr (clbull.frcl.bull.fr [129.182.1.20]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id GAA25308 for <[e-mail]>; Thu, 22 Apr 1999 06:13:08 -0700 (PDT)
Received: from k2.frcl.bull.fr (k2.frcl.bull.fr [129.182.100.2]) by clbull.frcl.bull.fr (8.9.1a/8.9.1) with ESMTP id PAA08500; Thu, 22 Apr 1999 15:13:42 +0200
Received: from bull.net (frcls6118.frcl.bull.fr [129.182.109.213]) by k2.frcl.bull.fr (AIX4.2/UCB 8.7/8.7) with ESMTP id PAA23480; Thu, 22 Apr 1999 15:13:42 +0200 (DFT)
Message-ID: <[e-mail]>
Date: Thu, 22 Apr 1999 15:14:34 +0200
From: Denis Pinkas <[e-mail]>
Organization: Bull
X-Mailer: Mozilla 4.06 [fr] (Win95; I)
MIME-Version: 1.0
To: Stefan Santesson <[e-mail]>
CC: [e-mail]
Subject: Re: New proposed solution to the QC biometric issue
References: <[e-mail]>
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 8bit
Content-Transfer-Encoding: 8bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Stefan,

My comments are along the lines.

>  Stephen wrote:
> <snip>
>
>      I might be persuaded to provide an OPTIONAL pointer field if more evidence accumulates in favor of such, but it is not in the same category as the other pointers you cite.
>
> Steve,
>
> I have given this quite a thought the last days and I must say that I would favor an OPTIONAL URI pointer.

Also I do not feel strong on this issue, I would favor the opposite. :-(

The rational is as follows:

1) This data is private and may be released onbly if the subject wishes it. So it is very unlikely that you will find it in an URL free of access.
2) If the indication to fetch the information points to one of out several places, some people are going to argue that a sequence of such info is needed.

The basic question is whether the certificate should refer to the location of the biometric data or whether the biometric data should refer to the information in the certificate. I would think that the opposite is more meaningful.


> The rationale is mainly:
>
> 1) It doesn't matter from which source the relying party gets the source data (e.g. picture) as long as it does match the hash. So the optional URI are not THE place to get the information, but rather A place to find it. What I mean by this is that there is no conflict if the source data is provided by several means.
>
> 2) The authentication process could then be carried out independent of the transaction. I.e. the relying party could verify and display the picture regardless of which protocol the certificate was used and/or presented.
>
> So, what I see before me with a hash AND an optional URI of a picture, is standard clients that automatically displays the picture of the subject when they get hold of a certificate, without having to integrate that process with the corresponding transaction protocol where the certificate is used.
>
> Because if the URI is not allowed, then the process of obtaining the source data will have to be solved by locally defined standards, integrated with some protocol. And that will never be a general standard solution.

Beware. You mean that the standard solution will be to use the OPTIONAL field. :-)


> Further, since we clearly focus on two types of bio-data (picture and signature image)

maybe 3 three: add "fingerprint" whether it is coded as a bit-map or whatever.


> I would also favor that these types are associated wit a predefined integer value (not needing an OID).

Agreed.


> By the reasons above I propose this ASN.1 structure for a bio-data record:
>
> BiometricData ::= SEQUENCE {
> typeOfBiometricData TypeOfBioDataSyntax,
> hashAlgorithm AlgorithmIdentifier,
> biometricDataHash OCTET STRING,
> sourceDataUri IA5String OPTIONAL}
>
> TypeOfBioDataSyntax ::== CHOICE {
> predefinedBioType [0] INTEGER,
> bioDataOid [1] OBJECT IDENTIFIER }
>
> with the following predefinedBioType defined (so far):
> 0 picture
> 1 handwritten signature
>
> Concerning source data format I don't believe that has to be addressed any further.
> If an URI are used, then this is solved automatically. If not, this will have to be defined by local conventions. In extreme cases, the OID choice of TypeOfBioDataSyntax should be used to define both type and format.

No. there are multiple ways to encode a picture, so the type of encoding cannot be derived from the type of biometrics information. It may be useful to know in advance the encoding, to know if it can be processed.

I got a proposal from Anders Rundgren which solves the problem. He suggested to use mime-types
that allow to represent picture, sound. movie, text-file, xml-file, java-object etc. We could thus add a mime type defined as:

    mime_type   PRINTABLE STRING,

i.e. the string contains a text-string like "image/jpeg" . The advantage to using this scheme is that there already are many types defined.

As a conclusion I would favor:

BiometricData ::= SEQUENCE {
typeOfBiometricData TypeOfBioDataSyntax,
mime_type   PRINTABLE STRING,
hashAlgorithm AlgorithmIdentifier,
biometricDataHash OCTET STRING,
}

Regards,

Denis


> /Stefan
> -------------------------------------------------------------------
> Stefan Santesson <[e-mail]>
> Accurata Systemsäkerhet AB http://www.accurata.se
> Slagthuset Tel. [phone]
> 211 20 Malmö Fax. [phone]
> Sweden Mobile [phone]
>
> PGP fingerprint: 89BC 6C79 5B3D 591B 8547 1512 7D11 DBF4 528F 29A0
> -------------------------------------------------------------------



Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id EAA23705 for ietf-pkix-bks; Thu, 22 Apr 1999 04:57:41 -0700 (PDT)
Received: from popmail.inbox.se (popmail.inbox.se [193.12.72.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id EAA23701 for <[e-mail]>; Thu, 22 Apr 1999 04:57:39 -0700 (PDT)
Received: from stefan2 (accurata.inbox.se [193.12.72.24]) by popmail.inbox.se (8.9.3/8.9.3) with SMTP id NAA10823; Thu, 22 Apr 1999 13:58:27 +0200
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: Windows Eudora Pro Version 3.0 (32)
Date: Thu, 22 Apr 1999 13:58:29 +0200
To: Stephen Kent <[e-mail]>, "Peter Williams" <[e-mail]>
From: Stefan Santesson <[e-mail]>
Subject: Re: New proposed solution to the QC biometric issue
Cc: <[e-mail]>
Mime-Version: 1.0
Content-Type: text/enriched; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

At 01:37 PM 4/19/99 -0400, Stephen Kent wrote:

<<snip>=20

<excerpt>I might be persuaded to provide an OPTIONAL pointer field if
more evidence accumulates in favor of such, but it is not in the same
category as the other pointers you cite.


</excerpt>

Steve,


I have given this quite a thought the last days and I must say that I
would favor an OPTIONAL URI pointer.


The rationale is mainly:


1) It doesn't matter from which source the relying party gets the source
data (e.g. picture) as long as it does match the hash. So the optional
URI are not THE place to get the information, but rather A place to find
it. What I mean by this is that there is no conflict if the source data
is provided by several means.


2) The authentication process could then be carried out independent of
the transaction. I.e. the relying party could verify and display the
picture regardless of which protocol the certificate was used and/or
presented.


So, what I see before me with a hash AND an optional URI of a picture, is
standard clients that automatically displays the picture of the subject
when they get hold of a certificate, without having to integrate that
process with the corresponding transaction protocol where the certificate
is used.


Because if the URI is not allowed, then the process of obtaining the
source data will have to be solved by locally defined standards,
integrated with some protocol. And that will never be a general standard
solution.


Further, since we clearly focus on two types of bio-data (picture and
signature image) I would also favor that these types are associated wit a
predefined integer value (not needing an OID).



By the reasons above I propose this ASN.1 structure for a bio-data
record:



   BiometricData ::=3D SEQUENCE {

         typeOfBiometricData  TypeOfBioDataSyntax,

         hashAlgorithm        AlgorithmIdentifier,

         biometricDataHash    OCTET STRING,

         sourceDataUri        IA5String  OPTIONAL}


   TypeOfBioDataSyntax ::=3D=3D CHOICE {

         predefinedBioType    [0] INTEGER,

         bioDataOid           [1] OBJECT IDENTIFIER }=20


with the following predefinedBioType defined (so far):

	0    picture

	1    handwritten signature



Concerning source data format I don't believe that has to be addressed
any further.=20

If an URI are used, then this is solved automatically. If not, this will
have to be defined by local conventions. In extreme cases, the OID choice
of TypeOfBioDataSyntax should be used to define both type and format.



/Stefan

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

Stefan Santesson                <<[e-mail]>

Accurata Systems=E4kerhet AB      http://www.accurata.se

Slagthuset                      Tel. [phone]             =20

211 20  Malm=F6                   Fax. [phone]             =20

Sweden                        Mobile [phone]


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

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


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id CAA16024 for ietf-pkix-bks; Thu, 22 Apr 1999 02:22:26 -0700 (PDT)
Received: from nexus.webmatic.de (nexus.webmatic.de [195.206.76.2]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id CAA16020 for <[e-mail]>; Thu, 22 Apr 1999 02:22:24 -0700 (PDT)
Received: from chappi.deh.de (chappi.deh.de [195.206.79.60]) by nexus.webmatic.de (Postfix) with ESMTP id EC1DC4D; Thu, 22 Apr 1999 11:23:25 +0200 (CEST)
Received: from deh.de (juergen.deh.de [195.206.79.54]) by chappi.deh.de (8.9.0/8.9.0) with ESMTP id LAA03782; Thu, 22 Apr 1999 11:23:33 +0200
Message-ID: <[e-mail]>
Date: Thu, 22 Apr 1999 11:24:05 +0200
From: Juergen Walter <[e-mail]>
Reply-To: [e-mail]
Organization: DEH information systems GmbH
X-Mailer: Mozilla 4.51 [en] (WinNT; U)
X-Accept-Language: en
MIME-Version: 1.0
To: "David P. Kemp" <[e-mail]>
Cc: [e-mail]
Subject: Re: Delta CRL processing
References: <[e-mail]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Comments in line.

"David P. Kemp" wrote:
> 
> > From: Juergen Walter <[e-mail]>
> >
> > I think that a delta crl along with its base crl is just a (temporal?)
> > replacement of *a* CRL that is issued after the time when the base CRL
> > is isssued.
> 
> Agree.
> 
> > Two examples. # short for CRLNumber in the following.
> >
> > (1) Cert A is pending at CRL #1. Delta-CRL #2 is issued according to the
> > base CRL #1. Delta-CRL #2 indicates that Cert A is removedFromCRL i. e.
> > Cert A is valid. Delta-CRL #3 does not contain any CRL entry
> > corresponding to Cert A. A relying application that does only process
> > Delta-CRL #3 (but not Delta-CRL #2) returns the result that Cert A is
> > always pending. But Cert A is valid after Delta-CRL #2 is issued.
> 
> What do you mean by pending?  I assume you mean that Cert A appears
> on CRL #1 with a CRLReason of "certificateHold" in its entry extension.
> 
> If CRL #2 has no entry for Cert A, Delta-CRL #2 (referring to baseCRL #1)
> would have Cert A with a CRLReason of removedFromCRL.

I see. It was a wrong example. Thanks.

> Similarly, Delta-CRL #3 (referring to baseCRL #1) would have Cert A
> with a CRLReason of removedFromCRL, and so would Delta #4, Delta #5,
> and all other Deltas with a baseCRL of #1.
> 
> Your assertion that Delta-CRL #3 would indicate that cert A is on
> certificateHold is incorrect.

Agreed. Here is the replacement: (1)' Cert A is valid at the time when
CRL #1 is issued. Delta-CRL #2/baseCRL #1 has a CRL entry for Cert A
with reasonCode of "certificateHold". Delta-CRL #3/baseCRL #1 has not
any entry according to Cert A. Certificate path validation that does not
take notice of Delta-CRL #2 results in valid for the time interval
whereby the certificate was on hold.

> 
> > (2) Cert B is valid at CRL #1. Delta-CRL #2 contains a CRL entry for
> > Cert B. Cert B expires before Delta-CRL #3 is issued. Delta-CRL #3 may
> > not contain any CRL entry for Cert B. A relying application that does
> > process only Delta-CRL #3 (but not Delta-CRL #2) returns the result that
> > Cert B is valid before it expires. But Cert B was revoked prior to
> > expiration.
> 
> This situation is not specific to Delta CRLs, it applies to CRLs in
> general.

Agreed.

> 
> If the relying application wants to know whether a cert was revoked
> in a time interval, it must check the CRL issued at the end of that
> interval.  In your example, Cert B is revoked sometime between CRL #1
> and CRL #2, and it appears on CRL #2 and Delta-CRL #2.  If it appears
> on CRL #3, it will also appear on Delta-CRL #3 (referring to baseCRL #1).
> It would not appear on Delta-CRL #3 (referring to baseCRL #2)
> because CRL #2 already shows that Cert B is revoked.  Either case
> (Delta#3/Base#1 or Delta#3/Base#2) must return the same result
> as CRL #3.
> 
> > Therefore the corresponding RFC 2459 paragraph
> >
> > 'A CRL user constructing a locally held CRL from delta-CRLs MUST
> >    consider the constructed CRL incomplete and unusable if the CRLNumber
> >    of the received delta-CRL is more than one greater than the CRLnumber
> >    of the delta-CRL last processed.'
> >
> > should remain unchanged.
> 
> Your very first statement contradicts this. 

You are right again. The RFC 2459 is more suitable for those crls that I
called epsilon-CRLs. My examples are not delta-crl specific. It is
simply the fact that you need the appropriate CRLs for certificate path
validation at a certain time in the past.

> A delta CRL along with its
> base CRL must *IN EVERY CASE* yield identical results to a CRL issued
> (hypothetically or actually) at the time of the delta CRL.  That is the
> mathematical definition of a delta: the difference between two
> absolutes.
> 
> Proof by construction:  if you create Delta-CRL #15 as the difference
> between CRL #15 and CRL #1, then CRL #1 + Delta-CRL #15 must yield
> CRL #15.
> 
> The contents of Delta-CRLs #2,3,....14 are irrelevant.

I resume that nobody wants to implement epsilon-crls. Alternatively one
may split up large crls according to revocationTime intervals. Is it
prudent to go this way?

Juergen


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id NAA12697 for ietf-pkix-bks; Wed, 21 Apr 1999 13:58:41 -0700 (PDT)
Received: from prv-mail20.provo.novell.com (prv-mail20.Provo.Novell.COM [137.65.40.4]) by mail.proper.com (8.8.8/8.8.5) with SMTP id NAA12693 for <[e-mail]>; Wed, 21 Apr 1999 13:58:40 -0700 (PDT)
Received: from INET-PRV-Message_Server by prv-mail20.provo.novell.com with Novell_GroupWise; Wed, 21 Apr 1999 14:55:13 -0600
Message-Id: <[e-mail]>
X-Mailer: Novell GroupWise 5.5
Date: Wed, 21 Apr 1999 14:54:56 -0600
From: "Bob Jueneman" <[e-mail]>
To: <[e-mail]>, <[e-mail]>
Subject: Re: Delta CRL processing
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 mail.proper.com id NAA12694
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

David, I appreciate and agree with your analysis in this case.
It would indeed be perverse to implement a more efficient
algorithm such as delta-CRLs, and then force the CA to go 
through an onerous and unnecessary publication step.

If "issue" in this case is closer to "create the equivalent of and 
hold it in a private archive in case it's needed", I'm perfectly 
happy. But what, precisely, does  RFC 2459 currently require, 
and does the language need to be modified to fit this 
interpretation of x.509?

With respect to what Juergan called an epsilon-CRL, i.e.,
a delta CRL that is NOT cumulative since the last base, but 
instead is incremental, requiring the entire collection in order 
to be complete, I was not proposing such a construct -- I just
want to be clear that WASN'T what we were doing.

I'm not necessarily opposed to such a function -- I just
haven't heard a sufficient explanation of where it might
apply to be convinced yet.

Regards,

Bob

>>> "David P. Kemp" <[e-mail]> 04/21/99 01:27PM >>>

> From: Russ Housley <[e-mail]>
> 
> Bob:
> 
> delta-CRLs do not operate as you describe.  They are the updates since the
> specified base.  Further, X.509 requires the CA to issue a full CRL every
> time that a delta-CRL is generated.  RFC 2459 did not create this
> requirement, itis inherited from X.509.
> 
> Russ

We need a glossary which clarifies exactly what X.509 means by "issue".

In a private message, Sharon Boeyen points out:

  "As of the 1997 edition of X.509 a CA is NOT required to publish
  a full CRL."

I claim that not only does an X.509 CA not have to "publish" a full
CRL, it also does not need to create a DER representation of the CRL
or generate a signature of that DER.  The intent of the word "issue"
is to ensure that at any point in time, there is a single, unique,
unambiguous instance of a full CRL that would have been generated and
published had the CA chosen to do so.  Or in other words, if an
application reconstructs the revocation status for a certain point in
time, it will always reconstruct the same status as would have been
obtained had a full CRL been generated, published, and retrieved.  It
must be impossible to take two different inputs (combinations of full,
delta, and DP-partitioned CRLs) and arrive at conflicting conclusions
as to the status of a given certificate.

This is analogous to the procedure for Certification Path Validation,
which says:

  "Conforming implementations ... are not required to implement this
   algorithm, but shall be functionally equivalent to the external
   behavior resulting from this procedure."

Reference algorithms are often chosen to emphasize simplicity,
correctness and tutorial value instead of operational efficiency.
Optimizations may be applied as long as the optimized algorithm yields
correct results.  The external result of CRL processing is the
revocation status of a particular certificate at a particular time, and
the correct answer is the one which would have been obtained from a
full CRL.

It would be perverse indeed to interpret X.509 as saying that optimized
revocation methods are allowed, as long as you also perform the
unoptimized reference method in parallel!




Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id MAA12103 for ietf-pkix-bks; Wed, 21 Apr 1999 12:41:10 -0700 (PDT)
Received: from luc.ab.org (mail.ab.org [209.112.11.37]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id MAA12099 for <[e-mail]>; Wed, 21 Apr 1999 12:41:09 -0700 (PDT)
Received: from xfile ([207.112.70.165]) by luc.ab.org (Netscape Messaging Server 3.5)  with SMTP id 87; Wed, 21 Apr 1999 15:55:19 -0400
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: Windows Eudora Pro Version 3.0.1 (32)
Date: Wed, 21 Apr 1999 15:34:37 -0400
To: [e-mail]
From: Francois Rousseau <[e-mail]>
Subject: Re: Delta CRL processing
Cc: [e-mail]
In-Reply-To: <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Note that Clause 12.6.3.3 on the Delta CRL indicator field in the Proposed
Draft Amendment (PDAM) on X.509(97) was already clarifying part of this
issue, however this item was discussed further at the last Directory
Working Group meeting in Orlando.

The revised Clause 12.6.3.3 in the Final PDAM (FPDAM) on X.509 (97) should
soon be available. It will include a more precise explanation of the
proposed rules for constructing delta-CRLs along with a more extensive
example of their use.

Francois Rousseau
AEPOS Technologies


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id MAA11982 for ietf-pkix-bks; Wed, 21 Apr 1999 12:27:31 -0700 (PDT)
Received: from stingray.missi.ncsc.mil (stingray.missi.ncsc.mil [144.51.50.20]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id MAA11978 for <[e-mail]>; Wed, 21 Apr 1999 12:27:30 -0700 (PDT)
Received: from stingray.missi.ncsc.mil (root@localhost) by stingray.missi.ncsc.mil with ESMTP id PAA09702 for <[e-mail]>; Wed, 21 Apr 1999 15:28:30 -0400 (EDT)
Received: from missi.ncsc.mil (depot.missi.ncsc.mil [144.51.60.1]) by stingray.missi.ncsc.mil with ESMTP id PAA09698 for <[e-mail]>; Wed, 21 Apr 1999 15:28:30 -0400 (EDT)
Received: from ara.missi.ncsc.mil (ara.missi.ncsc.mil [144.51.56.12]) by missi.ncsc.mil (8.8.8/8.8.8) with ESMTP id PAA13152 for <[e-mail]>; Wed, 21 Apr 1999 15:28:41 -0400 (EDT)
Received: from ara.missi.ncsc.mil (ara.missi.ncsc.mil [144.51.56.12]) by ara.missi.ncsc.mil (8.9.1b+Sun/8.9.1) with SMTP id PAA09252 for <[e-mail]>; Wed, 21 Apr 1999 15:27:38 -0400 (EDT)
Message-Id: <[e-mail]>
Date: Wed, 21 Apr 1999 15:27:38 -0400 (EDT)
From: "David P. Kemp" <[e-mail]>
Reply-To: "David P. Kemp" <[e-mail]>
Subject: Re: Delta CRL processing
To: [e-mail]
MIME-Version: 1.0
Content-Type: TEXT/plain; charset=us-ascii
Content-MD5: HgASiX9m1Mm+DI2T3AT7OA==
X-Mailer: dtmail 1.3.0 CDE Version 1.3 SunOS 5.7 sun4u sparc 
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

> From: Russ Housley <[e-mail]>
> 
> Bob:
> 
> delta-CRLs do not operate as you describe.  They are the updates since the
> specified base.  Further, X.509 requires the CA to issue a full CRL every
> time that a delta-CRL is generated.  RFC 2459 did not create this
> requirement, itis inherited from X.509.
> 
> Russ

We need a glossary which clarifies exactly what X.509 means by "issue".

In a private message, Sharon Boeyen points out:

  "As of the 1997 edition of X.509 a CA is NOT required to publish
  a full CRL."

I claim that not only does an X.509 CA not have to "publish" a full
CRL, it also does not need to create a DER representation of the CRL
or generate a signature of that DER.  The intent of the word "issue"
is to ensure that at any point in time, there is a single, unique,
unambiguous instance of a full CRL that would have been generated and
published had the CA chosen to do so.  Or in other words, if an
application reconstructs the revocation status for a certain point in
time, it will always reconstruct the same status as would have been
obtained had a full CRL been generated, published, and retrieved.  It
must be impossible to take two different inputs (combinations of full,
delta, and DP-partitioned CRLs) and arrive at conflicting conclusions
as to the status of a given certificate.

This is analogous to the procedure for Certification Path Validation,
which says:

  "Conforming implementations ... are not required to implement this
   algorithm, but shall be functionally equivalent to the external
   behavior resulting from this procedure."

Reference algorithms are often chosen to emphasize simplicity,
correctness and tutorial value instead of operational efficiency.
Optimizations may be applied as long as the optimized algorithm yields
correct results.  The external result of CRL processing is the
revocation status of a particular certificate at a particular time, and
the correct answer is the one which would have been obtained from a
full CRL.

It would be perverse indeed to interpret X.509 as saying that optimized
revocation methods are allowed, as long as you also perform the
unoptimized reference method in parallel!



Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id LAA10913 for ietf-pkix-bks; Wed, 21 Apr 1999 11:14:04 -0700 (PDT)
Received: from stingray.missi.ncsc.mil (stingray.missi.ncsc.mil [144.51.50.20]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id LAA10909 for <[e-mail]>; Wed, 21 Apr 1999 11:14:03 -0700 (PDT)
Received: from stingray.missi.ncsc.mil (root@localhost) by stingray.missi.ncsc.mil with ESMTP id OAA00756 for <[e-mail]>; Wed, 21 Apr 1999 14:15:03 -0400 (EDT)
Received: from missi.ncsc.mil (depot.missi.ncsc.mil [144.51.60.1]) by stingray.missi.ncsc.mil with ESMTP id OAA00752 for <[e-mail]>; Wed, 21 Apr 1999 14:15:03 -0400 (EDT)
Received: from ara.missi.ncsc.mil (ara.missi.ncsc.mil [144.51.56.12]) by missi.ncsc.mil (8.8.8/8.8.8) with ESMTP id OAA04558 for <[e-mail]>; Wed, 21 Apr 1999 14:15:14 -0400 (EDT)
Received: from ara.missi.ncsc.mil (ara.missi.ncsc.mil [144.51.56.12]) by ara.missi.ncsc.mil (8.9.1b+Sun/8.9.1) with SMTP id OAA09236 for <[e-mail]>; Wed, 21 Apr 1999 14:14:11 -0400 (EDT)
Message-Id: <[e-mail]>
Date: Wed, 21 Apr 1999 14:14:11 -0400 (EDT)
From: "David P. Kemp" <[e-mail]>
Reply-To: "David P. Kemp" <[e-mail]>
Subject: Re: Delta CRL processing
To: [e-mail]
MIME-Version: 1.0
Content-Type: TEXT/plain; charset=us-ascii
Content-MD5: 6KuUEVD4FdJBUMulUlyTTA==
X-Mailer: dtmail 1.3.0 CDE Version 1.3 SunOS 5.7 sun4u sparc 
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

> From: Juergen Walter <[e-mail]>
> 
> I think that a delta crl along with its base crl is just a (temporal?)
> replacement of *a* CRL that is issued after the time when the base CRL
> is isssued.

Agree.


> Two examples. # short for CRLNumber in the following. 
> 
> (1) Cert A is pending at CRL #1. Delta-CRL #2 is issued according to the
> base CRL #1. Delta-CRL #2 indicates that Cert A is removedFromCRL i. e.
> Cert A is valid. Delta-CRL #3 does not contain any CRL entry
> corresponding to Cert A. A relying application that does only process
> Delta-CRL #3 (but not Delta-CRL #2) returns the result that Cert A is
> always pending. But Cert A is valid after Delta-CRL #2 is issued.

What do you mean by pending?  I assume you mean that Cert A appears
on CRL #1 with a CRLReason of "certificateHold" in its entry extension.

If CRL #2 has no entry for Cert A, Delta-CRL #2 (referring to baseCRL #1)
would have Cert A with a CRLReason of removedFromCRL.
Similarly, Delta-CRL #3 (referring to baseCRL #1) would have Cert A
with a CRLReason of removedFromCRL, and so would Delta #4, Delta #5,
and all other Deltas with a baseCRL of #1.

Your assertion that Delta-CRL #3 would indicate that cert A is on
certificateHold is incorrect.



> (2) Cert B is valid at CRL #1. Delta-CRL #2 contains a CRL entry for
> Cert B. Cert B expires before Delta-CRL #3 is issued. Delta-CRL #3 may
> not contain any CRL entry for Cert B. A relying application that does
> process only Delta-CRL #3 (but not Delta-CRL #2) returns the result that
> Cert B is valid before it expires. But Cert B was revoked prior to
> expiration.

This situation is not specific to Delta CRLs, it applies to CRLs in
general.

If the relying application wants to know whether a cert was revoked
in a time interval, it must check the CRL issued at the end of that
interval.  In your example, Cert B is revoked sometime between CRL #1
and CRL #2, and it appears on CRL #2 and Delta-CRL #2.  If it appears
on CRL #3, it will also appear on Delta-CRL #3 (referring to baseCRL #1).
It would not appear on Delta-CRL #3 (referring to baseCRL #2)
because CRL #2 already shows that Cert B is revoked.  Either case
(Delta#3/Base#1 or Delta#3/Base#2) must return the same result
as CRL #3.


> Therefore the corresponding RFC 2459 paragraph 
> 
> 'A CRL user constructing a locally held CRL from delta-CRLs MUST
>    consider the constructed CRL incomplete and unusable if the CRLNumber
>    of the received delta-CRL is more than one greater than the CRLnumber
>    of the delta-CRL last processed.'
> 
> should remain unchanged.


Your very first statement contradicts this.  A delta CRL along with its
base CRL must *IN EVERY CASE* yield identical results to a CRL issued
(hypothetically or actually) at the time of the delta CRL.  That is the
mathematical definition of a delta: the difference between two
absolutes.

Proof by construction:  if you create Delta-CRL #15 as the difference
between CRL #15 and CRL #1, then CRL #1 + Delta-CRL #15 must yield
CRL #15.

The contents of Delta-CRLs #2,3,....14 are irrelevant.



Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id JAA10187 for ietf-pkix-bks; Wed, 21 Apr 1999 09:56:42 -0700 (PDT)
Received: from spyrus.com (mail.spyrus.com [207.212.34.30]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id JAA10183 for <[e-mail]>; Wed, 21 Apr 1999 09:56:41 -0700 (PDT)
Received: from rhousley_laptop.spyrus.com ([209.172.119.101]) by spyrus.com (8.7.6/8.7.3/arc) with SMTP id JAA17249; Wed, 21 Apr 1999 09:56:16 -0700 (PDT)
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1 
Date: Wed, 21 Apr 1999 11:35:19 -0400
To: "Bob Jueneman" <[e-mail]>
From: Russ Housley <[e-mail]>
Subject: Re: Delta CRL processing
Cc: [e-mail]
In-Reply-To: <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Bob:

delta-CRLs do not operate as you describe.  They are the updates since the
specified base.  Further, X.509 requires the CA to issue a full CRL every
time that a delta-CRL is generated.  RFC 2459 did not create this
requirement, itis inherited from X.509.

Russ

At 07:02 PM 4/20/99 -0600, Bob Jueneman wrote:
>Russ,
>
>Let me poke at this for a moment.
>
>Does this make it crystal clear that relying party software is not
required to 
>to obtain each and every CRL that is issued, nor every delta that might have 
>been issued since the last time the base was updated?
>
>When I first suggested the concept of a delta CRL to Warwick, back during
>the waning days of PEM, I had in mind a "CRL CD of the month club"
>type of mechanism, whereby I could efficiently retrieve the large bulk of 
>CRLs and then download only the changes since that baseline.  Since the 
>deltas would be cumulative since the baseline, the latest delta would 
>always be correct.  I had in mind particularly the case where I am about 
>to jump on an airplane, and I want to do some kind of a "hit the road"
>option with a minimum of fuss and bother.
>
>By comparison, if the relying party is required to download each and every 
>delta that might have been issued, then either there will be a lot of 
>bandwidth wasted loading the same information about some revoked 
>certificate over and over again, or else (if such information is sent only
>once), the RP would be at risk of having missed one, and/or there would
>be a significant synchronization problem.
>
>If some applications want to receive deltas at one second intervals, and 
>for my purposes I only care about once a week, I don't want to be compelled
>to check or download any more data or any more often than is
>necessary for my application, regardless of what some other application 
>might require.
>
>I also question the need to issue a new, complete CRL every time a delta
>is issued.  Although it may not matter if I am operating a local CA with its 
>own
>repository, or if I am a public CA (same thing), it might matter a very great 
>deal if I am publishing all of my certs through some kind of a third party 
>repository  - the cost could end up being prohibitive.
>
>Is there something I don't understand?  If we have delta CRLs, why must
>we also support full CRLs at the same frequency -- this seems to defeat the 
>basic purpose of having delta CRLs in the first place??
>
>Bob
>
>>>> Russ Housley <[e-mail]> 04/20/99 12:23PM >>>
>Dave:
>
>I think that your proposed rewording is more clear.  Two things are important:
>
>	(1) The CA must issue a full CRL every time a delta is issued.
>
>	(2) The relying party may use a delta and the assocuated base.
>
>Russ
>
>
>At 06:03 PM 4/19/99 -0400, David P. Kemp wrote:
>>Russ,
>>
>>Thanks for the background info.  But do you agree that the sentence
>>quoted below does not accurately describe the usage of delta CRLs
>>(by either a server or an end user application), and should be
>>removed from the next version of the PKIX profile?
>>
>>The input to a delta CRL processor is one base CRL and one delta CRL.
>>There is no state involved in the process, and the CRLNumbers of
>>delta CRLs processed before or after the current one are irrelevant.
>>
>>The sentence as written is no more security-helpful than, for example:
>>
>>  "A CRL user constructing a locally held CRL from delta-CRLs MUST
>>   consider the constructed CRL incomplete and unusable if the
>>   delta-CRL is received on the third Thursday of the month."
>>
>>
>>Dave K.
>>
>>
>>
>>> From: Russ Housley <[e-mail]>
>>> 
>>> Dave:
>>> 
>>> I thought some background might help.  When I was drafting the CRL section
>>> for RFC 2459, I wanted to say "do not used delta-CRLs."  I was convinced
>>> that they have some value when a high-end server caches CRL information in
>>> a local format for rapid access.  In this environment, the delta-CRL is
>>> used to update the server-friendly data structure without having to process
>>> the entire CRL.  Note that X.509 requires that a full CRL be generated
>>> every time that a delta-CRL is generated.  So, it seemed to be reasonable
>>> that the server obtain the most recent full CRL when it has a few spare
>>> cycles.  This means that the delta-CRL information is only used for a brief
>>> period until the server have resources to convert the most recent full CRL
>>> into the server-friendly format.
>>> 
>>> Russ
>>> 
>>> 
>>> At 11:53 AM 4/19/99 -0400, David P. Kemp wrote:
>>> >
>>> >RFC 2459 section 5.2.4 contains the following requirement:
>>> >
>>> >  "A CRL user constructing a locally held CRL from delta-CRLs MUST
>>> >  consider the constructed CRL incomplete and unusable if the CRLNumber
>>> >  of the received delta-CRL is more than one greater than the CRLnumber
>>> >  of the delta-CRL last processed."
>>
>>       [remainder snipped]
>>
>



Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id JAA09998 for ietf-pkix-bks; Wed, 21 Apr 1999 09:41:33 -0700 (PDT)
Received: from nexus.webmatic.de (nexus.webmatic.de [195.206.76.2]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id JAA09992 for <[e-mail]>; Wed, 21 Apr 1999 09:41:24 -0700 (PDT)
Received: from chappi.deh.de (chappi.deh.de [195.206.79.60]) by nexus.webmatic.de (Postfix) with ESMTP id 85B6B5B; Wed, 21 Apr 1999 18:42:12 +0200 (CEST)
Received: from deh.de (juergen.deh.de [195.206.79.54]) by chappi.deh.de (8.9.0/8.9.0) with ESMTP id SAA01792; Wed, 21 Apr 1999 18:42:11 +0200
Message-ID: <[e-mail]>
Date: Wed, 21 Apr 1999 18:42:50 +0200
From: Juergen Walter <[e-mail]>
Reply-To: [e-mail]
Organization: DEH information systems GmbH
X-Mailer: Mozilla 4.51 [en] (WinNT; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Bob Jueneman <[e-mail]>
Cc: [e-mail], [e-mail], [e-mail]
Subject: Re: Delta CRL processing
References: <[e-mail]>
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 8bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

I think that a delta crl along with its base crl is just a (temporal?)
replacement of *a* CRL that is issued after the time when the base CRL
is isssued. If it is a regularly scheduled CRL which is replaced then
the CRLNumber ensures that no regularly scheduled CRL is missed by the
relying application. There might be more sophisticated mechanisms (a
detailed thisUpdate - nextUpdate analysis over a set of CRLs when
appropriately implemented) nevertheless CRLNumber might be the best. 

Two examples. # short for CRLNumber in the following. 

(1) Cert A is pending at CRL #1. Delta-CRL #2 is issued according to the
base CRL #1. Delta-CRL #2 indicates that Cert A is removedFromCRL i. e.
Cert A is valid. Delta-CRL #3 does not contain any CRL entry
corresponding to Cert A. A relying application that does only process
Delta-CRL #3 (but not Delta-CRL #2) returns the result that Cert A is
always pending. But Cert A is valid after Delta-CRL #2 is issued.

(2) Cert B is valid at CRL #1. Delta-CRL #2 contains a CRL entry for
Cert B. Cert B expires before Delta-CRL #3 is issued. Delta-CRL #3 may
not contain any CRL entry for Cert B. A relying application that does
process only Delta-CRL #3 (but not Delta-CRL #2) returns the result that
Cert B is valid before it expires. But Cert B was revoked prior to
expiration.

Therefore the corresponding RFC 2459 paragraph 

'A CRL user constructing a locally held CRL from delta-CRLs MUST
   consider the constructed CRL incomplete and unusable if the CRLNumber
   of the received delta-CRL is more than one greater than the CRLnumber
   of the delta-CRL last processed.'

should remain unchanged.

Clients that are not suitable for CRL downloading may use OCSP including
cashing. Another solution might be the use of CMP´s revocation
announcement (RFC 2510). Note, initially the intended usage of CMP´s
revocation announcement was different. Therefore you can not expect any
security measure that ensures that the client does not miss a particular
revocation announcement at protocol level.

Last but not least, Bob mentioned a new style delta-crl. I would like to
add new notation to Bob´s posting. An interesting question is the
following. Do we need an epsilon-crl i. e. a crl containing only changes
between the previously issued epsilon-crl and the current certificate
status information? Should be epsilon-crls regularly scheduled? Could a
crl issuer leave the crl generation at each time when an epsilon-crl is
issued? Is there a need for such an epsilon-crl? I tend to say yes.

I have chosen the term epsilon-crl to make it clear that a current
delta-crl MUST NOT generated in the above specified way.

Juergen 

Bob Jueneman wrote:
> 
> Russ,
> 
> Let me poke at this for a moment.
> 
> Does this make it crystal clear that relying party software is not required to
> to obtain each and every CRL that is issued, nor every delta that might have
> been issued since the last time the base was updated?
> 
> When I first suggested the concept of a delta CRL to Warwick, back during
> the waning days of PEM, I had in mind a "CRL CD of the month club"
> type of mechanism, whereby I could efficiently retrieve the large bulk of
> CRLs and then download only the changes since that baseline.  Since the
> deltas would be cumulative since the baseline, the latest delta would
> always be correct.  I had in mind particularly the case where I am about
> to jump on an airplane, and I want to do some kind of a "hit the road"
> option with a minimum of fuss and bother.
> 
> By comparison, if the relying party is required to download each and every
> delta that might have been issued, then either there will be a lot of
> bandwidth wasted loading the same information about some revoked
> certificate over and over again, or else (if such information is sent only
> once), the RP would be at risk of having missed one, and/or there would
> be a significant synchronization problem.
> 
> If some applications want to receive deltas at one second intervals, and
> for my purposes I only care about once a week, I don't want to be compelled
> to check or download any more data or any more often than is
> necessary for my application, regardless of what some other application
> might require.
> 
> I also question the need to issue a new, complete CRL every time a delta
> is issued.  Although it may not matter if I am operating a local CA with its own
> repository, or if I am a public CA (same thing), it might matter a very great
> deal if I am publishing all of my certs through some kind of a third party
> repository  - the cost could end up being prohibitive.
> 
> Is there something I don't understand?  If we have delta CRLs, why must
> we also support full CRLs at the same frequency -- this seems to defeat the
> basic purpose of having delta CRLs in the first place??
> 
> Bob
> 
> >>> Russ Housley <[e-mail]> 04/20/99 12:23PM >>>
> Dave:
> 
> I think that your proposed rewording is more clear.  Two things are important:
> 
>         (1) The CA must issue a full CRL every time a delta is issued.
> 
>         (2) The relying party may use a delta and the assocuated base.
> 
> Russ
> 
> At 06:03 PM 4/19/99 -0400, David P. Kemp wrote:
> >Russ,
> >
> >Thanks for the background info.  But do you agree that the sentence
> >quoted below does not accurately describe the usage of delta CRLs
> >(by either a server or an end user application), and should be
> >removed from the next version of the PKIX profile?
> >
> >The input to a delta CRL processor is one base CRL and one delta CRL.
> >There is no state involved in the process, and the CRLNumbers of
> >delta CRLs processed before or after the current one are irrelevant.
> >
> >The sentence as written is no more security-helpful than, for example:
> >
> >  "A CRL user constructing a locally held CRL from delta-CRLs MUST
> >   consider the constructed CRL incomplete and unusable if the
> >   delta-CRL is received on the third Thursday of the month."
> >
> >
> >Dave K.
> >
> >
> >
> >> From: Russ Housley <[e-mail]>
> >>
> >> Dave:
> >>
> >> I thought some background might help.  When I was drafting the CRL section
> >> for RFC 2459, I wanted to say "do not used delta-CRLs."  I was convinced
> >> that they have some value when a high-end server caches CRL information in
> >> a local format for rapid access.  In this environment, the delta-CRL is
> >> used to update the server-friendly data structure without having to process
> >> the entire CRL.  Note that X.509 requires that a full CRL be generated
> >> every time that a delta-CRL is generated.  So, it seemed to be reasonable
> >> that the server obtain the most recent full CRL when it has a few spare
> >> cycles.  This means that the delta-CRL information is only used for a brief
> >> period until the server have resources to convert the most recent full CRL
> >> into the server-friendly format.
> >>
> >> Russ
> >>
> >>
> >> At 11:53 AM 4/19/99 -0400, David P. Kemp wrote:
> >> >
> >> >RFC 2459 section 5.2.4 contains the following requirement:
> >> >
> >> >  "A CRL user constructing a locally held CRL from delta-CRLs MUST
> >> >  consider the constructed CRL incomplete and unusable if the CRLNumber
> >> >  of the received delta-CRL is more than one greater than the CRLnumber
> >> >  of the delta-CRL last processed."
> >
> >       [remainder snipped]
> >


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id SAA19890 for ietf-pkix-bks; Tue, 20 Apr 1999 18:02:19 -0700 (PDT)
Received: from prv-mail20.provo.novell.com (prv-mail20.Provo.Novell.COM [137.65.40.4]) by mail.proper.com (8.8.8/8.8.5) with SMTP id SAA19886 for <[e-mail]>; Tue, 20 Apr 1999 18:02:17 -0700 (PDT)
Received: from INET-PRV-Message_Server by prv-mail20.provo.novell.com with Novell_GroupWise; Tue, 20 Apr 1999 19:02:32 -0600
Message-Id: <[e-mail]>
X-Mailer: Novell GroupWise 5.5
Date: Tue, 20 Apr 1999 19:02:27 -0600
From: "Bob Jueneman" <[e-mail]>
To: <[e-mail]>, <[e-mail]>
Cc: <[e-mail]>
Subject: Re: Delta CRL processing
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 mail.proper.com id SAA19887
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Russ,

Let me poke at this for a moment.

Does this make it crystal clear that relying party software is not required to 
to obtain each and every CRL that is issued, nor every delta that might have 
been issued since the last time the base was updated?

When I first suggested the concept of a delta CRL to Warwick, back during
the waning days of PEM, I had in mind a "CRL CD of the month club"
type of mechanism, whereby I could efficiently retrieve the large bulk of 
CRLs and then download only the changes since that baseline.  Since the 
deltas would be cumulative since the baseline, the latest delta would 
always be correct.  I had in mind particularly the case where I am about 
to jump on an airplane, and I want to do some kind of a "hit the road"
option with a minimum of fuss and bother.

By comparison, if the relying party is required to download each and every 
delta that might have been issued, then either there will be a lot of 
bandwidth wasted loading the same information about some revoked 
certificate over and over again, or else (if such information is sent only
once), the RP would be at risk of having missed one, and/or there would
be a significant synchronization problem.

If some applications want to receive deltas at one second intervals, and 
for my purposes I only care about once a week, I don't want to be compelled
to check or download any more data or any more often than is
necessary for my application, regardless of what some other application 
might require.

I also question the need to issue a new, complete CRL every time a delta
is issued.  Although it may not matter if I am operating a local CA with its own
repository, or if I am a public CA (same thing), it might matter a very great 
deal if I am publishing all of my certs through some kind of a third party 
repository  - the cost could end up being prohibitive.

Is there something I don't understand?  If we have delta CRLs, why must
we also support full CRLs at the same frequency -- this seems to defeat the 
basic purpose of having delta CRLs in the first place??

Bob

>>> Russ Housley <[e-mail]> 04/20/99 12:23PM >>>
Dave:

I think that your proposed rewording is more clear.  Two things are important:

	(1) The CA must issue a full CRL every time a delta is issued.

	(2) The relying party may use a delta and the assocuated base.

Russ


At 06:03 PM 4/19/99 -0400, David P. Kemp wrote:
>Russ,
>
>Thanks for the background info.  But do you agree that the sentence
>quoted below does not accurately describe the usage of delta CRLs
>(by either a server or an end user application), and should be
>removed from the next version of the PKIX profile?
>
>The input to a delta CRL processor is one base CRL and one delta CRL.
>There is no state involved in the process, and the CRLNumbers of
>delta CRLs processed before or after the current one are irrelevant.
>
>The sentence as written is no more security-helpful than, for example:
>
>  "A CRL user constructing a locally held CRL from delta-CRLs MUST
>   consider the constructed CRL incomplete and unusable if the
>   delta-CRL is received on the third Thursday of the month."
>
>
>Dave K.
>
>
>
>> From: Russ Housley <[e-mail]>
>> 
>> Dave:
>> 
>> I thought some background might help.  When I was drafting the CRL section
>> for RFC 2459, I wanted to say "do not used delta-CRLs."  I was convinced
>> that they have some value when a high-end server caches CRL information in
>> a local format for rapid access.  In this environment, the delta-CRL is
>> used to update the server-friendly data structure without having to process
>> the entire CRL.  Note that X.509 requires that a full CRL be generated
>> every time that a delta-CRL is generated.  So, it seemed to be reasonable
>> that the server obtain the most recent full CRL when it has a few spare
>> cycles.  This means that the delta-CRL information is only used for a brief
>> period until the server have resources to convert the most recent full CRL
>> into the server-friendly format.
>> 
>> Russ
>> 
>> 
>> At 11:53 AM 4/19/99 -0400, David P. Kemp wrote:
>> >
>> >RFC 2459 section 5.2.4 contains the following requirement:
>> >
>> >  "A CRL user constructing a locally held CRL from delta-CRLs MUST
>> >  consider the constructed CRL incomplete and unusable if the CRLNumber
>> >  of the received delta-CRL is more than one greater than the CRLnumber
>> >  of the delta-CRL last processed."
>
>       [remainder snipped]
>



Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id RAA18693 for ietf-pkix-bks; Tue, 20 Apr 1999 17:32:04 -0700 (PDT)
Received: from dsg1.OpenDirectory.com.au ([203.108.249.145]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id RAA18689 for <[e-mail]>; Tue, 20 Apr 1999 17:32:01 -0700 (PDT)
Received: by DSG1 with Internet Mail Service (5.0.1458.49) id <JF42TZT3>; Wed, 21 Apr 1999 10:32:49 +1000
Message-ID: <D1A949D4508DD1119C8100400533BEDC0BE987@DSG1>
From: Alan Lloyd <[e-mail]>
To: "'Stephen Kent'" <[e-mail]>
Cc: [e-mail], [e-mail]
Subject: RE: SEIS: Re: Certificates, Directories, and Distinguished Names
Date: Wed, 21 Apr 1999 10:32:49 +1000
X-Priority: 3
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.0.1458.49)
Content-Type: text/plain
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

I wont continue this simply because of the context shifting in the
responses -  Sad examples below.


> -----Original Message-----
> From:	Stephen Kent 
> Sent:	Wednesday, April 14, 1999 11:29 PM
> To:	Alan Lloyd
> Cc:	[e-mail]; [e-mail]
> Subject:	SEIS: Re: Certificates, Directories, and Distinguished
> Names
> 
> --- Message on the SEIS mailing list ([e-mail])
> 
> Alan,
> 
> >Stephen - in all your words you never seem to come to grips with the
> >fact that X.509 is not ambigious in so far that it permits systems to
> be
> >built without certificate extensions - and for those build such
> systems
> >to determine by local means or imply what is a EE or a CA cert and
> what
> >use that cert has (eg for message verification or cert
> verification)..
> >X.509 - was written some years ago and it correctly (a a standard
> >should) provided a transition path to the use of cert extensions.
> 
> Vome on Alan, we're talking about changes only with regard to X.509
> v3.
> 
	Groan --- Which happens to be specified in X.509. - the
standard,

> >RFC 2459 came along some time later as a profile and just the fact
> that
> >people are discussing the issue in 2459 and it is unclear - means
> there
> >is a problem - in the Profile.
> 
> 2459 did not come along much later than the adoption of X.509 v3. And,
> no,
> there is not a profile problem, as too many previous messages have
> show in
> detail.
> 
	I was referring to the standard (X.509) was written earlier than
the profiles .. thats a fact of life and common knowledge. 

	To respond to my point with pointless statement that tries to
show me wrong me by changing context eg...
	" 2459 did not come along much later than the adoption of X.509
v3" 
	note the word "adoption" has been added to prove me wrong......


	If this is the approach to logical debate - that is also used to
debate technology issues , then one can see why these lists have
difficulty.


	regards as always. alan


> <text not contributing to resolution of the issue deleted ...>
> 
> Steve
> 
> 
> ----------------- SEIS mailing list ([e-mail])
> Info about this list: http://www.nc-forum.com/seis
> SEIS Contact: [e-mail]


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id RAA17944 for ietf-pkix-bks; Tue, 20 Apr 1999 17:07:07 -0700 (PDT)
Received: from dsg1.OpenDirectory.com.au ([203.108.249.145]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id RAA17939 for <[e-mail]>; Tue, 20 Apr 1999 17:07:00 -0700 (PDT)
Received: by DSG1 with Internet Mail Service (5.0.1458.49) id <JF42TZTK>; Wed, 21 Apr 1999 10:07:41 +1000
Message-ID: <D1A949D4508DD1119C8100400533BEDC0BE986@DSG1>
From: Alan Lloyd <[e-mail]>
To: "'Russ Housley'" <[e-mail]>, Moshe Litvin <[e-mail]>
Cc: [e-mail]
Subject: RE: CA vs. EE cert processing
Date: Wed, 21 Apr 1999 10:07:39 +1000
X-Priority: 3
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.0.1458.49)
Content-Type: text/plain
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

No problems with 2459 - time will tell - 
any chance of getting OCSP key identification compatable with it?
2459 requires Issuer Name, Auth Key Id and cert SN for identification -
magic... OCSP wants cert Ids hashed according to some chosen algorithm
the cert SN and optionally Issuer name (service locator extension) and
no Auth Key Id...
ie does OCSP validate according to 2459 MUSTS?

regards alan.


> -----Original Message-----
> From:	Russ Housley 
> Sent:	Tuesday, April 20, 1999 2:21 AM
> To:	Moshe Litvin
> Cc:	[e-mail]
> Subject:	Re: CA vs. EE cert processing
> 
> Moshe:
> 
> I will say is again.  There is not a problem with RFC 2459.  If an
> implementor wishes to support more than one profile, then that
> implementor
> must resolve any ambiguities that result.
> 
> As far as I am concerned, this issue has been thrashed to death, and
> we
> should bring this thread to an end.
> 
> Russ
> 
> 
> At 12:17 PM 4/18/99 +0300, Moshe Litvin wrote:
> >Russ,
> >
> >Russ Housley wrote:
> >
> >> I have kept quiet on this thread.  I cannot hold it in any longer.
> >>
> >> RFC 2459 has no ambiguity in this area.  If basicConstraints is
> present,
> >> then the cA boolean tells whether the certificate belongs to a CA
> or an EE.
> >>  If basicConstraints is absent, then the certificate belongs to an
> EE.  
> >Period.
> >
> >The term "ambiguity" is not the exact term. The problem is not
> ambiguity but
> >relying on out of band data. RFC 2459 is very clear as long as you
> know by 
> >out of
> >band data that the certificate was issued by RFC 2459 compliant CA.
> >
> >>
> >>
> >> If an implementor wishes to support other profiles in addition to
> RFC 2459,
> >> then the logic may be more complex.  Fine.  This was a market
> choice made
> >> by the implementor.
> >>
> >> I do not think that RFC 2459 should be altered to make support for
> multiple
> >> profiles easier.
> >
> >Why? do you think that whole world would choose adopt RFC 2459 and
> all the 
> >other
> >profiles (including the base X.509) will become obsolete?
> >
> >Why would you force software designers to choose between two
> contradicting 
> >profiles
> >of the same standard when you can easily allow them to support both?
> >
> >What is the compelling reason to prevent interpretability in that
> way?
> >
> >Moshe
> >


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id LAA05123 for ietf-pkix-bks; Tue, 20 Apr 1999 11:23:06 -0700 (PDT)
Received: from spyrus.com (mail.spyrus.com [207.212.34.30]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id LAA05119 for <[e-mail]>; Tue, 20 Apr 1999 11:23:05 -0700 (PDT)
Received: from rhousley_laptop.spyrus.com ([209.172.119.101]) by spyrus.com (8.7.6/8.7.3/arc) with SMTP id LAA24510; Tue, 20 Apr 1999 11:22:36 -0700 (PDT)
Message-Id: <[e-mail]>
X-Sender: [e-mail] (Unverified)
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1 
Date: Tue, 20 Apr 1999 14:23:11 -0400
To: "David P. Kemp" <[e-mail]>
From: Russ Housley <[e-mail]>
Subject: Re: Delta CRL processing
Cc: [e-mail]
In-Reply-To: <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Dave:

I think that your proposed rewording is more clear.  Two things are important:

	(1) The CA must issue a full CRL every time a delta is issued.

	(2) The relying party may use a delta and the assocuated base.

Russ


At 06:03 PM 4/19/99 -0400, David P. Kemp wrote:
>Russ,
>
>Thanks for the background info.  But do you agree that the sentence
>quoted below does not accurately describe the usage of delta CRLs
>(by either a server or an end user application), and should be
>removed from the next version of the PKIX profile?
>
>The input to a delta CRL processor is one base CRL and one delta CRL.
>There is no state involved in the process, and the CRLNumbers of
>delta CRLs processed before or after the current one are irrelevant.
>
>The sentence as written is no more security-helpful than, for example:
>
>  "A CRL user constructing a locally held CRL from delta-CRLs MUST
>   consider the constructed CRL incomplete and unusable if the
>   delta-CRL is received on the third Thursday of the month."
>
>
>Dave K.
>
>
>
>> From: Russ Housley <[e-mail]>
>> 
>> Dave:
>> 
>> I thought some background might help.  When I was drafting the CRL section
>> for RFC 2459, I wanted to say "do not used delta-CRLs."  I was convinced
>> that they have some value when a high-end server caches CRL information in
>> a local format for rapid access.  In this environment, the delta-CRL is
>> used to update the server-friendly data structure without having to process
>> the entire CRL.  Note that X.509 requires that a full CRL be generated
>> every time that a delta-CRL is generated.  So, it seemed to be reasonable
>> that the server obtain the most recent full CRL when it has a few spare
>> cycles.  This means that the delta-CRL information is only used for a brief
>> period until the server have resources to convert the most recent full CRL
>> into the server-friendly format.
>> 
>> Russ
>> 
>> 
>> At 11:53 AM 4/19/99 -0400, David P. Kemp wrote:
>> >
>> >RFC 2459 section 5.2.4 contains the following requirement:
>> >
>> >  "A CRL user constructing a locally held CRL from delta-CRLs MUST
>> >  consider the constructed CRL incomplete and unusable if the CRLNumber
>> >  of the received delta-CRL is more than one greater than the CRLnumber
>> >  of the delta-CRL last processed."
>
>       [remainder snipped]
>



Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id KAA03784 for ietf-pkix-bks; Tue, 20 Apr 1999 10:54:48 -0700 (PDT)
Received: from ns1.dmz.valicert.com (ns1.valicert.com [209.185.6.11]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id KAA03779 for <[e-mail]>; Tue, 20 Apr 1999 10:54:46 -0700 (PDT)
Received: from ns1.serverfarm.valicert.com (corporate-gw.valicert.com [209.185.6.5]) by ns1.dmz.valicert.com (8.9.2/8.9.2) with ESMTP id KAA24236; Tue, 20 Apr 1999 10:54:52 -0700 (PDT)
Received: from peternt (static-3-26.engineering.valicert.com [192.168.3.26] (may be forged)) by ns1.serverfarm.valicert.com (8.9.2/8.9.2) with SMTP id KAA15136; Tue, 20 Apr 1999 10:54:58 -0700 (PDT)
Message-ID: <00bd01be8b46$eaae84f0$[e-mail]>
From: "Peter Williams" <[e-mail]>
To: "Stephen Kent" <[e-mail]>
Cc: <[e-mail]>
Subject: Re: New proposed solution to the QC biometric issue
Date: Tue, 20 Apr 1999 11:00:30 -0500
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 V4.72.3110.3
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Specifying an "Optional" QC-extension-based URI name/locator to
subject's bio-template data is fine.


Peter.

    -----Original Message-----
    From: Stephen Kent <[e-mail]>
    To: Peter Williams <[e-mail]>
    Cc: [e-mail] <[e-mail]>
    Date: Monday, April 19, 1999 9:52 PM
    Subject: Re: New proposed solution to the QC biometric issue


    Peter,

    >I fail to see how one can rationalize the need of putting a CRL iDP
(with
    >http reference) into a cert, but one cannot point to user information
    >in similar form, on similar grounds. And similarly for the PKIX
    >CPS-reference - where additional CA-related information is
    >bound to the certificate via a PKIX-standarized https reference.

    I disagree with the analogy. The examples you cite involve pointers to
information that in intrinsic to the management of a PKI, and we have
reasonably well-described architectures that calls for inclusion of these
values in certs. the biometric data is anciliary, employed for user
authentication, not certificate validation, and we have no corresponding
architecture for use of the biometric data. I might be persuaded to provide
an OPTIONAL pointer field if more evidence accumulates in favor of such, but
it is not in the same category as the other pointers you cite.

    >If one were to accept the argument presented, then PKIX
    >should require SSL and S/MIME protocols to convey iDP
    >addressing signals, and ban CRL locating information from PKIX certs.

    see comments above.

    >Similarly, the CPS http reference put into 2459 by one of the WG
    >chairs should be presumably immediately banned - as bad practice. If
    >its technically inappropriate to convey legalistic user references, it
is
    >technically
    >inappropriate to convey rather similar authority references which
further
    > (legally) describe that PKI party!

    see comments above.

    >There is another side to this story, however. Based on the language
    >and intent of PKIX 2459, those deploying Internet CAs already
    >have all the freedom they need to do as some on the list are describing
:-
    >
    >- One can note that PKIX users may already name themselves using a
    >URI name-form - and in a manner wholly consistent with RFC 2459.
    >
    >- Should they name themselves with an https URI which happens to point
    >to their biometric profile, then I can only conclude that 2459 already
    >allows
    >what is being argued here in policy-regimes which establish their own
    >operating rules - as contemplated and facilitiated by PKIX 2459.
    >
    >- The URI name form plus the QC hash value can seeming
    >work together fine to accomplish what some people on the mailing list
want.
    >
    >- Those relying parties who respect a policy id which binds the URI
name and
    >hash fields at cert-processing time can now implement the desired
    >application
    >of PKIX certs. They can even now use certs to signal
    >specific biometric template data - as incorporated via a hash-based
secure
    >URI reference - into their policy-based cert issuing and handling
    >procedures.

    Very creative Peter, and syntactically valid, but I think it violates
the semantics of the subjectAltName field. 2459 says "The subject
alternative names extension allows additional identities to be bound to the
subject of the certificate." The URI you propose including is not the
identity of the subject; but is a blob of bits used to help authenticate the
subject's identity.

    Steve



Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id TAA18433 for ietf-pkix-bks; Mon, 19 Apr 1999 19:52:14 -0700 (PDT)
Received: from po1.bbn.com (PO1.BBN.COM [192.1.50.38]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id TAA18423 for <[e-mail]>; Mon, 19 Apr 1999 19:52:12 -0700 (PDT)
Received: from [128.33.238.78] (TC078.BBN.COM [128.33.238.78]) by po1.bbn.com (8.9.1/8.9.1) with ESMTP id WAA19622; Mon, 19 Apr 1999 22:53:00 -0400 (EDT)
Mime-Version: 1.0
Content-Type: multipart/alternative; boundary="============_-1287545686==_ma============"
X-Sender: [e-mail] (Unverified)
Message-Id: <v04020a01b340f9c66941@[128.33.238.214]>
In-Reply-To: <002601be8861$5fbb2ca0$[e-mail]>
Date: Mon, 19 Apr 1999 13:37:07 -0400
To: "Peter Williams" <[e-mail]>
From: Stephen Kent <[e-mail]>
Subject: Re: New proposed solution to the QC biometric issue
Cc: <[e-mail]>
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

--============_-1287545686==_ma============
Content-Type: text/plain; charset="us-ascii"

Peter,

>I fail to see how one can rationalize the need of putting a CRL iDP (with
>http reference) into a cert, but one cannot point to user information
>in similar form, on similar grounds. And similarly for the PKIX
>CPS-reference - where additional CA-related information is
>bound to the certificate via a PKIX-standarized https reference.

I disagree with the analogy.  The examples you cite involve pointers to
information that in intrinsic to the management of a PKI, and we have
reasonably well-described architectures that calls for inclusion of these
values in certs.  the biometric data is anciliary, employed for user
authentication, not certificate validation, and we have no corresponding
architecture for use of the biometric data. I might be persuaded to provide
an OPTIONAL pointer field if more evidence accumulates in favor of such,
but it is not in the same category as the other pointers you cite.

>If one were to accept the argument presented, then PKIX
>should require SSL  and  S/MIME protocols to convey iDP
>addressing signals, and ban CRL locating information from PKIX certs.

see comments above.

>Similarly, the CPS http reference put into 2459 by one of the WG
>chairs should be presumably immediately  banned  - as bad practice. If
>its technically inappropriate to convey  legalistic user references, it is
>technically
>inappropriate to convey rather similar authority references which further
> (legally) describe that PKI party!

see comments above.

>There is another side to this story, however. Based on the language
>and intent of PKIX 2459, those deploying Internet CAs already
>have all the freedom they need to do as some on the list are describing :-
>
>- One  can note that PKIX  users may already name themselves using a
>URI  name-form - and in a manner wholly consistent with RFC  2459.
>
>- Should they name themselves with an https URI which happens to point
>to their  biometric profile, then I can only conclude that 2459 already
>allows
>what is  being argued here in policy-regimes which establish their own
>operating rules - as contemplated and facilitiated by PKIX 2459.
>
>- The URI name form plus the QC hash value can seeming
>work together fine to accomplish what some people on the mailing list want.
>
>- Those relying parties who respect a policy id which binds the URI name and
>hash  fields at cert-processing time can now implement the desired
>application
>of  PKIX certs.  They can even now use certs to signal
>specific biometric template data - as incorporated via a hash-based secure
>URI reference - into their policy-based cert issuing and handling
>procedures.

Very creative Peter, and syntactically valid, but I think it violates the
semantics of the subjectAltName field. 2459 says "The subject alternative
names extension allows additional identities to be bound to the subject of
the certificate." The  URI you propose including is not the identity of the
subject; but is a blob of bits used to help authenticate the subject's
identity.

Steve
--============_-1287545686==_ma============
Content-Type: text/enriched; charset="us-ascii"

Peter,


>I fail to see how one can rationalize the need of putting a CRL iDP
(with

>http reference) into a cert, but one cannot point to user information

>in similar form, on similar grounds. And similarly for the PKIX

>CPS-reference - where additional CA-related information is

>bound to the certificate via a PKIX-standarized https reference.


I disagree with the analogy.  The examples you cite involve pointers to
information that in intrinsic to the management of a PKI, and we have
reasonably well-described architectures that calls for inclusion of
these values in certs.  the biometric data is anciliary, employed for
user authentication, not certificate validation, and we have no
corresponding architecture for use of the biometric data. I might be
persuaded to provide an OPTIONAL pointer field if more evidence
accumulates in favor of such, but it is not in the same category as the
other pointers you cite.


>If one were to accept the argument presented, then PKIX

>should require SSL  and  S/MIME protocols to convey iDP

>addressing signals, and ban CRL locating information from PKIX certs.


see comments above.


>Similarly, the CPS http reference put into 2459 by one of the WG

>chairs should be presumably immediately  banned  - as bad practice.
If

>its technically inappropriate to convey  legalistic user references,
it is

>technically

>inappropriate to convey rather similar authority references which
further

> (legally) describe that PKI party!


see comments above.


>There is another side to this story, however. Based on the language

>and intent of PKIX 2459, those deploying Internet CAs already

>have all the freedom they need to do as some on the list are
describing :-

>

>- One  can note that PKIX  users may already name themselves using a

>URI  name-form - and in a manner wholly consistent with RFC  2459.

>

>- Should they name themselves with an https URI which happens to
point

>to their  biometric profile, then I can only conclude that 2459
already

>allows

>what is  being argued here in policy-regimes which establish their
own

>operating rules - as contemplated and facilitiated by PKIX 2459.

>

>- The URI name form plus the QC hash value can seeming

>work together fine to accomplish what some people on the mailing list
want.

>

>- Those relying parties who respect a policy id which binds the URI
name and

>hash  fields at cert-processing time can now implement the desired

>application

>of  PKIX certs.  They can even now use certs to signal

>specific biometric template data - as incorporated via a hash-based
secure

>URI reference - into their policy-based cert issuing and handling

>procedures.


Very creative Peter, and syntactically valid, but I think it violates
the semantics of the subjectAltName field. 2459 says "The subject
alternative names extension allows additional identities to be bound to
the subject of the
certificate<bigger><bigger>.<fontfamily><param>Times</param>"
</fontfamily></bigger></bigger>The  URI you propose including is not
the identity of the subject; but is a blob of bits used to help
authenticate the subject's identity.


Steve

--============_-1287545686==_ma============--


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id PAA06326 for ietf-pkix-bks; Mon, 19 Apr 1999 15:03:00 -0700 (PDT)
Received: from stingray.missi.ncsc.mil (stingray.missi.ncsc.mil [144.51.50.20]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id PAA06321 for <[e-mail]>; Mon, 19 Apr 1999 15:02:58 -0700 (PDT)
Received: from stingray.missi.ncsc.mil (root@localhost) by stingray.missi.ncsc.mil with ESMTP id SAA27161 for <[e-mail]>; Mon, 19 Apr 1999 18:03:49 -0400 (EDT)
Received: from missi.ncsc.mil (depot.missi.ncsc.mil [144.51.60.1]) by stingray.missi.ncsc.mil with ESMTP id SAA27154 for <[e-mail]>; Mon, 19 Apr 1999 18:03:49 -0400 (EDT)
Received: from ara.missi.ncsc.mil (ara.missi.ncsc.mil [144.51.56.12]) by missi.ncsc.mil (8.8.8/8.8.8) with ESMTP id SAA02252 for <[e-mail]>; Mon, 19 Apr 1999 18:04:00 -0400 (EDT)
Received: from ara.missi.ncsc.mil (ara.missi.ncsc.mil [144.51.56.12]) by ara.missi.ncsc.mil (8.9.1b+Sun/8.9.1) with SMTP id SAA07274 for <[e-mail]>; Mon, 19 Apr 1999 18:03:01 -0400 (EDT)
Message-Id: <[e-mail]>
Date: Mon, 19 Apr 1999 18:03:01 -0400 (EDT)
From: "David P. Kemp" <[e-mail]>
Reply-To: "David P. Kemp" <[e-mail]>
Subject: Re: Delta CRL processing
To: [e-mail]
MIME-Version: 1.0
Content-Type: TEXT/plain; charset=us-ascii
Content-MD5: maFH09QS4KURqKQMHCpd2g==
X-Mailer: dtmail 1.3.0 CDE Version 1.3 SunOS 5.7 sun4u sparc 
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Russ,

Thanks for the background info.  But do you agree that the sentence
quoted below does not accurately describe the usage of delta CRLs
(by either a server or an end user application), and should be
removed from the next version of the PKIX profile?

The input to a delta CRL processor is one base CRL and one delta CRL.
There is no state involved in the process, and the CRLNumbers of
delta CRLs processed before or after the current one are irrelevant.

The sentence as written is no more security-helpful than, for example:

  "A CRL user constructing a locally held CRL from delta-CRLs MUST
   consider the constructed CRL incomplete and unusable if the
   delta-CRL is received on the third Thursday of the month."


Dave K.



> From: Russ Housley <[e-mail]>
> 
> Dave:
> 
> I thought some background might help.  When I was drafting the CRL section
> for RFC 2459, I wanted to say "do not used delta-CRLs."  I was convinced
> that they have some value when a high-end server caches CRL information in
> a local format for rapid access.  In this environment, the delta-CRL is
> used to update the server-friendly data structure without having to process
> the entire CRL.  Note that X.509 requires that a full CRL be generated
> every time that a delta-CRL is generated.  So, it seemed to be reasonable
> that the server obtain the most recent full CRL when it has a few spare
> cycles.  This means that the delta-CRL information is only used for a brief
> period until the server have resources to convert the most recent full CRL
> into the server-friendly format.
> 
> Russ
> 
> 
> At 11:53 AM 4/19/99 -0400, David P. Kemp wrote:
> >
> >RFC 2459 section 5.2.4 contains the following requirement:
> >
> >  "A CRL user constructing a locally held CRL from delta-CRLs MUST
> >  consider the constructed CRL incomplete and unusable if the CRLNumber
> >  of the received delta-CRL is more than one greater than the CRLnumber
> >  of the delta-CRL last processed."

       [remainder snipped]



Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id NAA03975 for ietf-pkix-bks; Mon, 19 Apr 1999 13:02:10 -0700 (PDT)
Received: from spyrus.com (mail.spyrus.com [207.212.34.30]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id NAA03970 for <[e-mail]>; Mon, 19 Apr 1999 13:02:09 -0700 (PDT)
Received: from rhousley_laptop.spyrus.com ([209.172.119.101]) by spyrus.com (8.7.6/8.7.3/arc) with SMTP id NAA03840; Mon, 19 Apr 1999 13:01:36 -0700 (PDT)
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1 
Date: Mon, 19 Apr 1999 15:44:49 -0400
To: "David P. Kemp" <[e-mail]>
From: Russ Housley <[e-mail]>
Subject: Re: Delta CRL processing
Cc: [e-mail]
In-Reply-To: <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Dave:

I thought some background might help.  When I was drafting the CRL section
for RFC 2459, I wanted to say "do not used delta-CRLs."  I was convinced
that they have some value when a high-end server caches CRL information in
a local format for rapid access.  In this environment, the delta-CRL is
used to update the server-friendly data structure without having to process
the entire CRL.  Note that X.509 requires that a full CRL be generated
every time that a delta-CRL is generated.  So, it seemed to be reasonable
that the server obtain the most recent full CRL when it has a few spare
cycles.  This means that the delta-CRL information is only used for a brief
period until the server have resources to convert the most recent full CRL
into the server-friendly format.

Russ


At 11:53 AM 4/19/99 -0400, David P. Kemp wrote:
>
>RFC 2459 section 5.2.4 contains the following requirement:
>
>  "A CRL user constructing a locally held CRL from delta-CRLs MUST
>  consider the constructed CRL incomplete and unusable if the CRLNumber
>  of the received delta-CRL is more than one greater than the CRLnumber
>  of the delta-CRL last processed."
>  
>
>Aside from being poorly specified (what happens the first time a
>delta-CRL is used and there isn't one that was last processed?), the
>requirement adds no security value.  But more importantly, it effectively
>precludes the use of delta-CRLs to support near-realtime certificate
>status checking.
>
>Consider the following scenario:
>
>1. A CA generates and posts to the distribution channel a full CRL every
>  7 days.  The thisUpdate field is set to time T, and the nextUpdate
>  field is set to time T + 7 days.
>
>2. The CA generates and posts to a (probably different) distribution
>  channel a delta CRL every 60 seconds.  The BaseCRLNumber refers to
>  the most recent full CRL issued in step 1 at time T.  (To conform
>  with another unnecessary RFC2459 requirement, the CA also "issues",
>  but does not necessarily post, a full CRL every 60 seconds,
>  incrementing CRLNumber each time.  These would be considered
>  unscheduled updates, despite their being "issued" on a regular
>  schedule. :-)  When I discussed the X.509 text with Hoyt a while
>  back, he pointed out the useful distinction between issuing and
>  distributing.  If a tree falls in an empty forest, is there a sound?
>  If a CRL is issued but not distributed, does it exist? :-)
>
>* A relying application validates a certificate, fetches the applicable
>  base CRL for time T, and fetches the current delta CRL, say for time
>  T + 13 hours 37 min.  A couple of hours later, it validates another
>  cert, fetching the delta CRL for time T + 15 hours 45 min.  Since
>  the base CRL is still valid, it doesn't need to be fetched again,
>  saving the bandwidth of a year's worth of revocations.
>  
>In this scenario, the relying application gets revocation information
>as fresh as its policy requires (24 hours, 4 hours, 15 min, or 1 min),
>yet it only incurs the transmission cost of fetching full CRLs every 7
>days.  The delta CRLs only contain up to a week's worth of revocations,
>so they don't add much overhead to the validation process.  They could
>either be fetched by the verifier(s) when needed, or fetched by the signer
>and passed to the verifier(s) along with the signed info.
>
>This scenario is, as far as I can tell, secure.  Yet it violates the
>1-up rule cited above.
>
>If the 1-up rule serves no security-enhancing purpose, can it be
>scrapped when the PKIX profile goes to Draft?  If the rule does enhance
>security, can someone describe the hole in this scenario?
>
>



Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id KAA29954 for ietf-pkix-bks; Mon, 19 Apr 1999 10:01:34 -0700 (PDT)
Received: from cale.checkpoint.com (ns.checkpoint.com [199.203.73.197]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id KAA29936 for <[e-mail]>; Mon, 19 Apr 1999 10:01:28 -0700 (PDT)
Received: from cale.checkpoint.com (gray.checkpoint.com [199.203.71.94]) by cale.checkpoint.com (8.9.1/8.9.1) with ESMTP id UAA29631; Mon, 19 Apr 1999 20:04:52 +0300 (IDT)
Message-ID: <[e-mail]>
Date: Mon, 19 Apr 1999 20:01:36 +0300
From: Moshe Litvin <[e-mail]>
X-Mailer: Mozilla 4.51 [en] (WinNT; I)
X-Accept-Language: en
MIME-Version: 1.0
To: Russ Housley <[e-mail]>
CC: [e-mail]
Subject: Re: CA vs. EE cert processing
References: <D1A949D4508DD1119C8100400533BEDC0E2B5C@DSG1> <[e-mail]> <[e-mail]>
Content-Type: multipart/mixed; boundary="------------4630A6D85B3B4D489B3A02D7"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

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



Russ Housley wrote:

> Moshe:
>
> I will say is again.  There is not a problem with RFC 2459.

What I tell you three times is true.

> If an
> implementor wishes to support more than one profile, then that implementor
> must resolve any ambiguities that result.
>
> As far as I am concerned, this issue has been thrashed to death, and we
> should bring this thread to an end.
>
> Russ
>
> At 12:17 PM 4/18/99 +0300, Moshe Litvin wrote:
> >Russ,
> >
> >Russ Housley wrote:
> >
> >> I have kept quiet on this thread.  I cannot hold it in any longer.
> >>
> >> RFC 2459 has no ambiguity in this area.  If basicConstraints is present,
> >> then the cA boolean tells whether the certificate belongs to a CA or an EE.
> >>  If basicConstraints is absent, then the certificate belongs to an EE.
> >Period.
> >
> >The term "ambiguity" is not the exact term. The problem is not ambiguity but
> >relying on out of band data. RFC 2459 is very clear as long as you know by
> >out of
> >band data that the certificate was issued by RFC 2459 compliant CA.
> >
> >>
> >>
> >> If an implementor wishes to support other profiles in addition to RFC 2459,
> >> then the logic may be more complex.  Fine.  This was a market choice made
> >> by the implementor.
> >>
> >> I do not think that RFC 2459 should be altered to make support for multiple
> >> profiles easier.
> >
> >Why? do you think that whole world would choose adopt RFC 2459 and all the
> >other
> >profiles (including the base X.509) will become obsolete?
> >
> >Why would you force software designers to choose between two contradicting
> >profiles
> >of the same standard when you can easily allow them to support both?
> >
> >What is the compelling reason to prevent interpretability in that way?
> >
> >Moshe
> >

--------------4630A6D85B3B4D489B3A02D7
Content-Type: text/x-vcard; charset=us-ascii;
 name="moshe.vcf"
Content-Transfer-Encoding: 7bit
Content-Description: Card for Moshe Litvin
Content-Disposition: attachment;
 filename="moshe.vcf"

begin:vcard 
n:Litvin;Moshe
tel;fax:[phone]
tel;work:[phone]
x-mozilla-html:TRUE
org:Check Point Software Technologies Ltd.
adr:;;;;;;
version:2.1
email;internet:[e-mail]
fn:Moshe Litvin
end:vcard

--------------4630A6D85B3B4D489B3A02D7--



Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id JAA29747 for ietf-pkix-bks; Mon, 19 Apr 1999 09:38:53 -0700 (PDT)
Received: from wuher.cygnacom.com (endor.cygnacom.com [205.177.169.102]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id JAA29742 for <[e-mail]>; Mon, 19 Apr 1999 09:38:52 -0700 (PDT)
Received: by WUHER with Internet Mail Service (5.0.1458.49) id <JH59HCSZ>; Mon, 19 Apr 1999 12:32:54 -0400
Message-ID: <51BF55C30B4FD1118B4900207812701E3165FB@WUHER>
From: Santosh Chokhani <[e-mail]>
To: "'David P. Kemp'" <[e-mail]>, [e-mail]
Subject: RE: Delta CRL processing
Date: Mon, 19 Apr 1999 12:32:53 -0400
X-Priority: 3
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.0.1458.49)
Content-Type: text/plain
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Dave:

You are correct.  This wording seems to be wrong.  The proper way to use
a delta CRL is to apply it to an appropriate base CRL.  A delta CRL need
not be applied previous deltas since deltas are issued with respect to a
base.

> -----Original Message-----
> From:	David P. Kemp [SMTP:[e-mail]]
> Sent:	Monday, April 19, 1999 11:53 AM
> To:	[e-mail]
> Subject:	Delta CRL processing
> 
> 
> RFC 2459 section 5.2.4 contains the following requirement:
> 
>   "A CRL user constructing a locally held CRL from delta-CRLs MUST
>   consider the constructed CRL incomplete and unusable if the
> CRLNumber
>   of the received delta-CRL is more than one greater than the
> CRLnumber
>   of the delta-CRL last processed."
>   
> 
> Aside from being poorly specified (what happens the first time a
> delta-CRL is used and there isn't one that was last processed?), the
> requirement adds no security value.  But more importantly, it
> effectively
> precludes the use of delta-CRLs to support near-realtime certificate
> status checking.
> 
> Consider the following scenario:
> 
> 1. A CA generates and posts to the distribution channel a full CRL
> every
>   7 days.  The thisUpdate field is set to time T, and the nextUpdate
>   field is set to time T + 7 days.
> 
> 2. The CA generates and posts to a (probably different) distribution
>   channel a delta CRL every 60 seconds.  The BaseCRLNumber refers to
>   the most recent full CRL issued in step 1 at time T.  (To conform
>   with another unnecessary RFC2459 requirement, the CA also "issues",
>   but does not necessarily post, a full CRL every 60 seconds,
>   incrementing CRLNumber each time.  These would be considered
>   unscheduled updates, despite their being "issued" on a regular
>   schedule. :-)  When I discussed the X.509 text with Hoyt a while
>   back, he pointed out the useful distinction between issuing and
>   distributing.  If a tree falls in an empty forest, is there a sound?
>   If a CRL is issued but not distributed, does it exist? :-)
> 
> * A relying application validates a certificate, fetches the
> applicable
>   base CRL for time T, and fetches the current delta CRL, say for time
>   T + 13 hours 37 min.  A couple of hours later, it validates another
>   cert, fetching the delta CRL for time T + 15 hours 45 min.  Since
>   the base CRL is still valid, it doesn't need to be fetched again,
>   saving the bandwidth of a year's worth of revocations.
>   
> In this scenario, the relying application gets revocation information
> as fresh as its policy requires (24 hours, 4 hours, 15 min, or 1 min),
> yet it only incurs the transmission cost of fetching full CRLs every 7
> days.  The delta CRLs only contain up to a week's worth of
> revocations,
> so they don't add much overhead to the validation process.  They could
> either be fetched by the verifier(s) when needed, or fetched by the
> signer
> and passed to the verifier(s) along with the signed info.
> 
> This scenario is, as far as I can tell, secure.  Yet it violates the
> 1-up rule cited above.
> 
> If the 1-up rule serves no security-enhancing purpose, can it be
> scrapped when the PKIX profile goes to Draft?  If the rule does
> enhance
> security, can someone describe the hole in this scenario?
> 


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id JAA29585 for ietf-pkix-bks; Mon, 19 Apr 1999 09:22:49 -0700 (PDT)
Received: from spyrus.com (mail.spyrus.com [207.212.34.30]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id JAA29580 for <[e-mail]>; Mon, 19 Apr 1999 09:22:47 -0700 (PDT)
Received: from rhousley_laptop.spyrus.com ([209.172.119.101]) by spyrus.com (8.7.6/8.7.3/arc) with SMTP id JAA27740; Mon, 19 Apr 1999 09:21:50 -0700 (PDT)
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1 
Date: Mon, 19 Apr 1999 12:20:51 -0400
To: Moshe Litvin <[e-mail]>
From: Russ Housley <[e-mail]>
Subject: Re: CA vs. EE cert processing
Cc: [e-mail]
In-Reply-To: <[e-mail]>
References: <D1A949D4508DD1119C8100400533BEDC0E2B5C@DSG1> <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Moshe:

I will say is again.  There is not a problem with RFC 2459.  If an
implementor wishes to support more than one profile, then that implementor
must resolve any ambiguities that result.

As far as I am concerned, this issue has been thrashed to death, and we
should bring this thread to an end.

Russ


At 12:17 PM 4/18/99 +0300, Moshe Litvin wrote:
>Russ,
>
>Russ Housley wrote:
>
>> I have kept quiet on this thread.  I cannot hold it in any longer.
>>
>> RFC 2459 has no ambiguity in this area.  If basicConstraints is present,
>> then the cA boolean tells whether the certificate belongs to a CA or an EE.
>>  If basicConstraints is absent, then the certificate belongs to an EE.  
>Period.
>
>The term "ambiguity" is not the exact term. The problem is not ambiguity but
>relying on out of band data. RFC 2459 is very clear as long as you know by 
>out of
>band data that the certificate was issued by RFC 2459 compliant CA.
>
>>
>>
>> If an implementor wishes to support other profiles in addition to RFC 2459,
>> then the logic may be more complex.  Fine.  This was a market choice made
>> by the implementor.
>>
>> I do not think that RFC 2459 should be altered to make support for multiple
>> profiles easier.
>
>Why? do you think that whole world would choose adopt RFC 2459 and all the 
>other
>profiles (including the base X.509) will become obsolete?
>
>Why would you force software designers to choose between two contradicting 
>profiles
>of the same standard when you can easily allow them to support both?
>
>What is the compelling reason to prevent interpretability in that way?
>
>Moshe
>



Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id IAA28743 for ietf-pkix-bks; Mon, 19 Apr 1999 08:53:10 -0700 (PDT)
Received: from stingray.missi.ncsc.mil (stingray.missi.ncsc.mil [144.51.50.20]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id IAA28738 for <[e-mail]>; Mon, 19 Apr 1999 08:53:09 -0700 (PDT)
Received: from stingray.missi.ncsc.mil (root@localhost) by stingray.missi.ncsc.mil with ESMTP id LAA26627 for <[e-mail]>; Mon, 19 Apr 1999 11:53:55 -0400 (EDT)
Received: from missi.ncsc.mil (depot.missi.ncsc.mil [144.51.60.1]) by stingray.missi.ncsc.mil with ESMTP id LAA26622 for <[e-mail]>; Mon, 19 Apr 1999 11:53:54 -0400 (EDT)
Received: from ara.missi.ncsc.mil (ara.missi.ncsc.mil [144.51.56.12]) by missi.ncsc.mil (8.8.8/8.8.8) with ESMTP id LAA18054 for <[e-mail]>; Mon, 19 Apr 1999 11:52:24 -0400 (EDT)
Received: from ara.missi.ncsc.mil (ara.missi.ncsc.mil [144.51.56.12]) by ara.missi.ncsc.mil (8.9.1b+Sun/8.9.1) with SMTP id LAA07064 for <[e-mail]>; Mon, 19 Apr 1999 11:53:07 -0400 (EDT)
Message-Id: <[e-mail]>
Date: Mon, 19 Apr 1999 11:53:07 -0400 (EDT)
From: "David P. Kemp" <[e-mail]>
Reply-To: "David P. Kemp" <[e-mail]>
Subject: Delta CRL processing
To: [e-mail]
MIME-Version: 1.0
Content-Type: TEXT/plain; charset=us-ascii
Content-MD5: +EkuJDM1RuT0JCeob+fTFw==
X-Mailer: dtmail 1.3.0 CDE Version 1.3 SunOS 5.7 sun4u sparc 
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

RFC 2459 section 5.2.4 contains the following requirement:

  "A CRL user constructing a locally held CRL from delta-CRLs MUST
  consider the constructed CRL incomplete and unusable if the CRLNumber
  of the received delta-CRL is more than one greater than the CRLnumber
  of the delta-CRL last processed."
  

Aside from being poorly specified (what happens the first time a
delta-CRL is used and there isn't one that was last processed?), the
requirement adds no security value.  But more importantly, it effectively
precludes the use of delta-CRLs to support near-realtime certificate
status checking.

Consider the following scenario:

1. A CA generates and posts to the distribution channel a full CRL every
  7 days.  The thisUpdate field is set to time T, and the nextUpdate
  field is set to time T + 7 days.

2. The CA generates and posts to a (probably different) distribution
  channel a delta CRL every 60 seconds.  The BaseCRLNumber refers to
  the most recent full CRL issued in step 1 at time T.  (To conform
  with another unnecessary RFC2459 requirement, the CA also "issues",
  but does not necessarily post, a full CRL every 60 seconds,
  incrementing CRLNumber each time.  These would be considered
  unscheduled updates, despite their being "issued" on a regular
  schedule. :-)  When I discussed the X.509 text with Hoyt a while
  back, he pointed out the useful distinction between issuing and
  distributing.  If a tree falls in an empty forest, is there a sound?
  If a CRL is issued but not distributed, does it exist? :-)

* A relying application validates a certificate, fetches the applicable
  base CRL for time T, and fetches the current delta CRL, say for time
  T + 13 hours 37 min.  A couple of hours later, it validates another
  cert, fetching the delta CRL for time T + 15 hours 45 min.  Since
  the base CRL is still valid, it doesn't need to be fetched again,
  saving the bandwidth of a year's worth of revocations.
  
In this scenario, the relying application gets revocation information
as fresh as its policy requires (24 hours, 4 hours, 15 min, or 1 min),
yet it only incurs the transmission cost of fetching full CRLs every 7
days.  The delta CRLs only contain up to a week's worth of revocations,
so they don't add much overhead to the validation process.  They could
either be fetched by the verifier(s) when needed, or fetched by the signer
and passed to the verifier(s) along with the signed info.

This scenario is, as far as I can tell, secure.  Yet it violates the
1-up rule cited above.

If the 1-up rule serves no security-enhancing purpose, can it be
scrapped when the PKIX profile goes to Draft?  If the rule does enhance
security, can someone describe the hole in this scenario?




Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id CAA22475 for ietf-pkix-bks; Sun, 18 Apr 1999 02:17:50 -0700 (PDT)
Received: from natasha1. (natasha-gw.checkpoint.com [199.203.73.129]) by mail.proper.com (8.8.8/8.8.5) with SMTP id CAA22457 for <[e-mail]>; Sun, 18 Apr 1999 02:17:43 -0700 (PDT)
Received: from cale.checkpoint.com (gray.checkpoint.com [199.203.71.94]) by cale.checkpoint.com (8.9.1/8.9.1) with ESMTP id MAA12694; Sun, 18 Apr 1999 12:20:29 +0300 (IDT)
Message-ID: <[e-mail]>
Date: Sun, 18 Apr 1999 12:17:12 +0300
From: Moshe Litvin <[e-mail]>
X-Mailer: Mozilla 4.51 [en] (WinNT; I)
X-Accept-Language: en
MIME-Version: 1.0
To: Russ Housley <[e-mail]>, [e-mail]
Subject: Re: CA vs. EE cert processing
References: <D1A949D4508DD1119C8100400533BEDC0E2B5C@DSG1> <[e-mail]>
Content-Type: multipart/mixed; boundary="------------AABD03B275790212FE65E1E5"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

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

Russ,

Russ Housley wrote:

> I have kept quiet on this thread.  I cannot hold it in any longer.
>
> RFC 2459 has no ambiguity in this area.  If basicConstraints is present,
> then the cA boolean tells whether the certificate belongs to a CA or an EE.
>  If basicConstraints is absent, then the certificate belongs to an EE.  Period.

The term "ambiguity" is not the exact term. The problem is not ambiguity but
relying on out of band data. RFC 2459 is very clear as long as you know by out of
band data that the certificate was issued by RFC 2459 compliant CA.

>
>
> If an implementor wishes to support other profiles in addition to RFC 2459,
> then the logic may be more complex.  Fine.  This was a market choice made
> by the implementor.
>
> I do not think that RFC 2459 should be altered to make support for multiple
> profiles easier.

Why? do you think that whole world would choose adopt RFC 2459 and all the other
profiles (including the base X.509) will become obsolete?

Why would you force software designers to choose between two contradicting profiles
of the same standard when you can easily allow them to support both?

What is the compelling reason to prevent interpretability in that way?

Moshe

--------------AABD03B275790212FE65E1E5
Content-Type: text/x-vcard; charset=us-ascii;
 name="moshe.vcf"
Content-Transfer-Encoding: 7bit
Content-Description: Card for Moshe Litvin
Content-Disposition: attachment;
 filename="moshe.vcf"

begin:vcard 
n:Litvin;Moshe
tel;fax:[phone]
tel;work:[phone]
x-mozilla-html:TRUE
org:Check Point Software Technologies Ltd.
adr:;;;;;;
version:2.1
email;internet:[e-mail]
fn:Moshe Litvin
end:vcard

--------------AABD03B275790212FE65E1E5--



Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id WAA19787 for ietf-pkix-bks; Fri, 16 Apr 1999 22:30:10 -0700 (PDT)
Received: from dsg1.OpenDirectory.com.au ([203.108.249.145]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id WAA19782 for <[e-mail]>; Fri, 16 Apr 1999 22:30:06 -0700 (PDT)
Received: by DSG1 with Internet Mail Service (5.0.1458.49) id <28N0K3GP>; Sat, 17 Apr 1999 15:30:20 +1000
Message-ID: <D1A949D4508DD1119C8100400533BEDC0E2BB9@DSG1>
From: Alan Lloyd <[e-mail]>
To: "'[e-mail] '" <[e-mail]>, "'Russ Housley '" <[e-mail]>
Subject: RE: CA vs. EE cert processing
Date: Sat, 17 Apr 1999 15:30:17 +1000
X-Priority: 3
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.0.1458.49)
Content-Type: text/plain
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Russ.

I aboslutely agree that the Profile should say that if the Ext BC is not
there OR it is there with a NULL then its an EE cert - but this does not
text define usage - which is the critical part.

And the SHALL NOT bit and the fuzzy words of 2119 just leave curiosity.

It would be nice if the para with SHALL NOT in is replaced with words
like.
"If the BC extension is not present or set to a NULL then the
certificate belongs to an EE and MUST NOT be used by the certificate
using system to verify the signature of a certificate." 

All done, precise, no indirection to other text which is fuzzy.

regards alan

----------
From: Russ Housley
To: [e-mail]
Sent: 4/16/99 4:32:32 AM
Subject: RE: CA vs. EE cert processing

I have kept quiet on this thread.  I cannot hold it in any longer.

RFC 2459 has no ambiguity in this area.  If basicConstraints is present,
then the cA boolean tells whether the certificate belongs to a CA or an
EE.
 If basicConstraints is absent, then the certificate belongs to an EE.
Period.

If an implementor wishes to support other profiles in addition to RFC
2459,
then the logic may be more complex.  Fine.  This was a market choice
made
by the implementor.

I do not think that RFC 2459 should be altered to make support for
multiple
profiles easier.

Russ



Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id SAA05023 for ietf-pkix-bks; Fri, 16 Apr 1999 18:27:06 -0700 (PDT)
Received: from ns1.dmz.valicert.com (ns1.valicert.com [209.185.6.11]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id SAA05019 for <[e-mail]>; Fri, 16 Apr 1999 18:27:05 -0700 (PDT)
Received: from ns1.serverfarm.valicert.com (corporate-gw.valicert.com [209.185.6.5]) by ns1.dmz.valicert.com (8.9.2/8.9.2) with ESMTP id SAA08790; Fri, 16 Apr 1999 18:26:52 -0700 (PDT)
Received: from peternt (static-3-26.engineering.valicert.com [192.168.3.26] (may be forged)) by ns1.serverfarm.valicert.com (8.9.2/8.9.2) with SMTP id SAA10742; Fri, 16 Apr 1999 18:26:59 -0700 (PDT)
Message-ID: <002601be8861$5fbb2ca0$[e-mail]>
From: "Peter Williams" <[e-mail]>
To: <[e-mail]>, "Stephen Kent" <[e-mail]>
Subject: Re: New proposed solution to the QC biometric issue
Date: Fri, 16 Apr 1999 18:32:21 -0500
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 V4.72.3110.3
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

-----Original Message-----
From: Stephen Kent <[e-mail]>
To: [e-mail] <[e-mail]>
Date: Friday, April 16, 1999 7:12 PM
Subject: Re: New proposed solution to the QC biometric issue


>Folks,
>
>We discussed the biometric issue at length and the current proposal to
>include a hash of a biometric template, for some well-defined set of human
>verifiable biometrics, is the compromise we have reached.
>
>We are not putting a biometrioc template in the cert because it might be
>very big and we generally discourage inclusion of very large data items in
>certs.
>
>We are not putting a URI in because, under different assumptions, the
>matching templame might be stored somewhere for reference, or might be
>passed as part of an application protocol.  If the template is not passed
>with the cert, then the application protocol may chose to include a URI.
>The only thing that does need to be in the cert, for secruity, is the hash
>of the template, and the management data to know what hash algorithm was
>employed, and what sort of template the hash refers to, e.g., facial image
>or handwriting.


Steve,

I fail to see how one can rationalize the need of putting a CRL iDP (with
http reference) into a cert, but one cannot point to user information
in similar form, on similar grounds. And similarly for the PKIX
CPS-reference - where additional CA-related information is
bound to the certificate via a PKIX-standarized https reference.

If one were to accept the argument presented, then PKIX
should require SSL  and  S/MIME protocols to convey iDP
addressing signals, and ban CRL locating information from PKIX certs.

Similarly, the CPS http reference put into 2459 by one of the WG
chairs should be presumably immediately  banned  - as bad practice. If
its technically inappropriate to convey  legalistic user references, it is
technically
inappropriate to convey rather similar authority references which further
 (legally) describe that PKI party!

There is another side to this story, however. Based on the language
and intent of PKIX 2459, those deploying Internet CAs already
have all the freedom they need to do as some on the list are describing :-

- One  can note that PKIX  users may already name themselves using a
URI  name-form - and in a manner wholly consistent with RFC  2459.

- Should they name themselves with an https URI which happens to point
to their  biometric profile, then I can only conclude that 2459 already
allows
what is  being argued here in policy-regimes which establish their own
operating rules - as contemplated and facilitiated by PKIX 2459.

- The URI name form plus the QC hash value can seeming
work together fine to accomplish what some people on the mailing list want.

- Those relying parties who respect a policy id which binds the URI name and
hash  fields at cert-processing time can now implement the desired
application
of  PKIX certs.  They can even now use certs to signal
specific biometric template data - as incorporated via a hash-based secure
URI reference - into their policy-based cert issuing and handling
procedures.

Peter

--------


2459 quotes:

"   The CPS Pointer qualifier contains a pointer to a Certification
   Practice Statement (CPS) published by the CA.  The pointer is in the
   form of a URI."


"   The subject alternative names extension allows additional identities
   to be bound to the subject of the certificate.  Defined options
   include an Internet electronic mail address, a DNS name, an IP
   address, and a uniform resource identifier (URI).  Other options
   exist, including completely local definitions.  Multiple name forms,
   and multiple instances of each name form, may be included. "

  "   Further, if the only subject identity included in the certificate is
   an alternative name form (e.g., an electronic mail address), then the
   subject distinguished name MUST be empty (an empty sequence), and the
   subjectAltName extension MUST be present. "



>Steve
>
>



Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id RAA04539 for ietf-pkix-bks; Fri, 16 Apr 1999 17:03:07 -0700 (PDT)
Received: from ns1.dmz.valicert.com (ns1.valicert.com [209.185.6.11]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id RAA04534 for <[e-mail]>; Fri, 16 Apr 1999 17:03:06 -0700 (PDT)
Received: from ns1.serverfarm.valicert.com (corporate-gw.valicert.com [209.185.6.5]) by ns1.dmz.valicert.com (8.9.2/8.9.2) with ESMTP id RAA08455 for <[e-mail]>; Fri, 16 Apr 1999 17:02:54 -0700 (PDT)
Received: from peternt (static-3-26.engineering.valicert.com [192.168.3.26] (may be forged)) by ns1.serverfarm.valicert.com (8.9.2/8.9.2) with SMTP id RAA09547 for <[e-mail]>; Fri, 16 Apr 1999 17:03:01 -0700 (PDT)
Message-ID: <000901be8855$a53da1b0$[e-mail]>
From: "Peter Williams" <[e-mail]>
To: <[e-mail]>
Subject: Re: New proposed solution to the QC biometric issue
Date: Fri, 16 Apr 1999 17:08:23 -0500
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 V4.72.3110.3
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Some biometric primers:

http://www.dss.state.ct.us/digital.htm

http://www.biometrics.org/
 
The PKIX QC project may not solve the probably
unsolvable Internet-name problem; but it may enable 
PKIX  to properly address biometrics!

Peter.



Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id QAA03987 for ietf-pkix-bks; Fri, 16 Apr 1999 16:02:17 -0700 (PDT)
Received: from po1.bbn.com (PO1.BBN.COM [192.1.50.38]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id QAA03983 for <[e-mail]>; Fri, 16 Apr 1999 16:02:16 -0700 (PDT)
Received: from [128.89.0.111] (YAKOV.BBN.COM [128.89.0.111]) by po1.bbn.com (8.9.1/8.9.1) with ESMTP id TAA22916; Fri, 16 Apr 1999 19:02:45 -0400 (EDT)
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
X-Sender: [e-mail] (Unverified)
Message-Id: <v04020a09b33d6da73a0d@[128.89.0.111]>
In-Reply-To: <[e-mail]>
Date: Fri, 16 Apr 1999 19:02:26 -0400
To: Petra Gloeckner <[e-mail]>
From: Stephen Kent <[e-mail]>
Subject: Re: New proposed solution to the QC biometric issue
Cc: [e-mail]
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Petra,

>4. The rationale as it stands is wrong from my point of view: There are
>no "biometric comparing algorithms" involved which have to compare
>reference data with actually measured verification data taken from the
>person to be authenticated. An acceptable wording would be: "The
>rationale for supporting biometric data (i.e. a certificate holder
>portrait image) would be to support biometric data in a qualified
>certificate in the sense of a certified attribute of the certificate
>holding person."

I'm a bit confused by your statement. Biometric authentication is
generically done by registering a user and creating a template that
characterizes the biometric for that user.  later, when the user tries to
"login" a new biometric is captured and is compared, algorithmically, to
the template.  if a suitably high score is achieved, the user is
authenticated.  In the more restricted cases we are considering here, the
assumption is that the template is an image of a user's face or of his/her
handwritten signature, that will be viewed by a person acting as the
authenticator, matched against an in-person image of the user or signature.

Steve


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id PAA03844 for ietf-pkix-bks; Fri, 16 Apr 1999 15:44:46 -0700 (PDT)
Received: from po1.bbn.com (PO1.BBN.COM [192.1.50.38]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id PAA03840 for <[e-mail]>; Fri, 16 Apr 1999 15:44:45 -0700 (PDT)
Received: from [128.89.0.111] (YAKOV.BBN.COM [128.89.0.111]) by po1.bbn.com (8.9.1/8.9.1) with ESMTP id SAA20956 for <[e-mail]>; Fri, 16 Apr 1999 18:45:21 -0400 (EDT)
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
X-Sender: [e-mail] (Unverified)
Message-Id: <v04020a08b33d6af29736@[128.89.0.111]>
In-Reply-To: <002601be8781$dfff8b30$[e-mail]>
Date: Fri, 16 Apr 1999 18:39:21 -0400
To: <[e-mail]>
From: Stephen Kent <[e-mail]>
Subject: Re: New proposed solution to the QC biometric issue
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Folks,

We discussed the biometric issue at length and the current proposal to
include a hash of a biometric template, for some well-defined set of human
verifiable biometrics, is the compromise we have reached.

We are not putting a biometrioc template in the cert because it might be
very big and we generally discourage inclusion of very large data items in
certs.

We are not putting a URI in because, under different assumptions, the
matching templame might be stored somewhere for reference, or might be
passed as part of an application protocol.  If the template is not passed
with the cert, then the application protocol may chose to include a URI.
The only thing that does need to be in the cert, for secruity, is the hash
of the template, and the management data to know what hash algorithm was
employed, and what sort of template the hash refers to, e.g., facial image
or handwriting.

Steve


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id PAA03758 for ietf-pkix-bks; Fri, 16 Apr 1999 15:38:23 -0700 (PDT)
Received: from prv-mail20.provo.novell.com (prv-mail20.Provo.Novell.COM [137.65.40.4]) by mail.proper.com (8.8.8/8.8.5) with SMTP id PAA03754 for <[e-mail]>; Fri, 16 Apr 1999 15:38:22 -0700 (PDT)
Received: from INET-PRV-Message_Server by prv-mail20.provo.novell.com with Novell_GroupWise; Fri, 16 Apr 1999 16:38:04 -0600
Message-Id: <[e-mail]>
X-Mailer: Novell GroupWise 5.5
Date: Fri, 16 Apr 1999 16:38:00 -0600
From: "Bob Jueneman" <[e-mail]>
To: <[e-mail]>, <[e-mail]>, <[e-mail]>
Subject: RE: New CMC Draft available - Confirmation Message
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 mail.proper.com id PAA03755
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Jim,

I have to agree with Juergan.

The client shouldn't have to check for revocation if (s)he disagrees with the
certificate, even though it might be prudent to do so.

But if the client does accept the certificate and the CA thinks it hasn't, that 
is at least fail safe.

If the CA ends up calling the client, screaming "What do you mean you are 
rejecting the certificate -- do you want to keep on working here?!", then
at least the problem will end up getting resolved.

But if the client thinks it rejected the certificate and the CA goes ahead 
and publishes it anyway, very real and perhaps substantial damages could
occur - it might be someone else's public key, it might disclose private information,
or it might contain a Reliance Limit that is higher than the client wishes to accept., etc.

Positive acknowledgment of acceptance by the Subscriber is a firm requirement.

Bob


>>> "Jim Schaad (Exchange)" <[e-mail]> 04/13/99 01:01PM >>>
Juergen,

The problem that I have with this approach is that there is no way of
knowing what the delay is going to be on the acceptance showing up on at the
CA.  (Nor do all transport mechinisms guantee delivery.)  Thus a client can
think it did accept a certificate and the CA can reach an opposite
conclusion.  If the client asks for revocation, it can later check to make
sure that this operation occured.

jim


-----Original Message-----
From: Juergen Walter [mailto:[e-mail]] 
Sent: Tuesday, April 13, 1999 1:32 AM
To: Jim Schaad (Exchange); IETF-PKIX (E-mail)
Subject: Re: New CMC Draft available - Confirmation Message


Jim,

[snip]


> 
> > - there is no confirmation message from the client to the
> > CA/RA (thus, there
> > is no way for a client to reject a certificate that it does
> > not want (e.g.,
> > in the case where the CA has modified some of the fields in
> > the request)).
> 
> There is a simple way for a client to reject a certificate, it simply puts
> in a revocation request on the certificates it just received.  I don't
know
> of any reason for the oppositite to be required in a general protocal.
That
> is the client must positively accept a certificate.
> 

When I remember right e. g. ABA Guidelines requires that an EE
explicitly confirms an issued certificate. This may be not a protocol
requirement in pure PKI implementations. But I know environments where a
certificate receipt is at least an operational requirement. I think that
an appropriate message (optional) would be an improvement. When the
rejection (i. e. sending of revocation request) stays away we have no
explicite confirmation of the certificate (may be a legal issue). The
time-frame of such stay away process may cause complicated validation
issues. I prefer a message that indicates the fact whether an EE accept
his certificate or not. This may replace the revocation request on the
one hand and the pure revocation request on the other hand. 

 

Juergen



Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id NAA01998 for ietf-pkix-bks; Fri, 16 Apr 1999 13:30:55 -0700 (PDT)
Received: from po1.bbn.com (PO1.BBN.COM [192.1.50.38]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id NAA01986 for <[e-mail]>; Fri, 16 Apr 1999 13:30:51 -0700 (PDT)
Received: from [128.89.0.111] (YAKOV.BBN.COM [128.89.0.111]) by po1.bbn.com (8.9.1/8.9.1) with ESMTP id QAA17414; Fri, 16 Apr 1999 16:30:51 -0400 (EDT)
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
X-Sender: [e-mail] (Unverified)
Message-Id: <v04020a05b33bb949b831@[128.33.238.53]>
In-Reply-To: <[e-mail]>
References: Your message of "Wed, 14 Apr 1999 12:57:35 +0200."             <[e-mail]>
Date: Thu, 15 Apr 1999 11:46:33 -0400
To: Stephen Farrell <[e-mail]>
From: Stephen Kent <[e-mail]>
Subject: Re: New proposed solution to the QC biometric issue
Cc: [e-mail]
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Stephen,

>- if you're only storing a hash, how do I find the
>original - maybe a URI is needed in addition

maybe, but not always.  the template can be passed as part of a
transaction, or be stored in a file, or whatever.  because there are
multiple, legitimate ways to provide the template, and nthey may differ for
the same cert user in different contexts, I think it inappropriate to
incorporate any one in the cert itself.

>- if you buy into the above, couldn't the URI replace
>the OID (since e.g. a HTTP response has a MIME type
>which identififes at least the syntax and also
>identifies the transfer encoding of the actual data)

I'm not in favor of the above, and anyway, HTTP is but one possible
transport medium ...

>- you'll need an algo id somewhere or you can't recalc. the
>hash



>- you'll need to specify how the actual data is to be
>flattened before hash calculation (e.g. strip CR/LF or
>whatever), this could be incorporated with the
>algo id (so use a transform id)

do you mean canonicalize the template?  these templates are typically
binary, not ASCII, I think.  Any canonicalization rules should be specified
in the ID we use to specify the template type, maybe as a sub-type.

Steve


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id DAA01572 for ietf-pkix-bks; Fri, 16 Apr 1999 03:17:09 -0700 (PDT)
Received: from clbull.frcl.bull.fr (clbull.frcl.bull.fr [129.182.1.20]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id DAA01567 for <[e-mail]>; Fri, 16 Apr 1999 03:16:52 -0700 (PDT)
Received: from k2.frcl.bull.fr (k2.frcl.bull.fr [129.182.100.2]) by clbull.frcl.bull.fr (8.9.1a/8.9.1) with ESMTP id MAA21642; Fri, 16 Apr 1999 12:17:12 +0200
Received: from bull.net (frcls6118.frcl.bull.fr [129.182.109.213]) by k2.frcl.bull.fr (AIX4.2/UCB 8.7/8.7) with ESMTP id MAA43106; Fri, 16 Apr 1999 12:17:09 +0200 (DFT)
Message-ID: <[e-mail]>
Date: Fri, 16 Apr 1999 12:17:41 +0200
From: Denis Pinkas <[e-mail]>
Organization: Bull
X-Mailer: Mozilla 4.06 [fr] (Win95; I)
MIME-Version: 1.0
To: Petra Gloeckner <[e-mail]>
CC: [e-mail]
Subject: Re: New proposed solution to the QC biometric issue
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Petra,

My comments are along the lines.

> Denis Pinkas wrote:
> >
> > >From these examples, it can be seen that a URI is not mandatory, but the
> > name of the corresponding file would be usefull as well as the type of
> > biometric information. As far as the typeOfBiometricData is concerned I
> > would prefer an integer instead of an OID: it is shorter (when
> > certificates are stored in smart cards) and we could expand the list of
> > integers as needed. At the time being, two integers seem sufficient
> > (picture or manual signature).
> >
>
> Denis,
>
> why would you like to include the name of the corresponding file in
> the certificate as well?

> I originally thought to have the name of the file to point to the right
> attached file and the extension of the file to select the right viewer.

The name of the file is not  needed if there is some "other ways" to
differentiate (in the case when there are multiple attachments) between an
attached picture, a manual signature and, maybe, a fingerprint (that was not in
my original list).

I am however still wondering if there might be some interrest to have
nevertheless the extension of the file, for exemple: GIF, TIF, BMP, MPG, MP3,
etc ... to know, only when looking at the certificate, what kind of viewer will
be necessary. I do not feel strong on this issue, I am trying to find the pros
and cons before taking a decision. Other thoughts ?

Regards,

Denis


> Without this name I'd suggest the following structure considering the
> comments of Stephen and you:
>
>    BiometricData ::= SEQUENCE {
>          URIorOID             URIorOIDsyntax,
>          hashalgorithm        AlgorithmIdentifier,
>          biometricDataHash    OCTET STRING }
>
>    URIorOIDsyntax ::== CHOICE {
>          uri                  [0] IA5String
>          typeOfBiometricData  [1] INTEGER }
>
> with the following types of biometric data defined so far:
>         0    picture
>         1    manual signature
>
> Best regards - Petra



Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id XAA21262 for ietf-pkix-bks; Thu, 15 Apr 1999 23:39:05 -0700 (PDT)
Received: from smtp.udac.net (smtp.udac.net [193.44.79.123]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id XAA21258 for <[e-mail]>; Thu, 15 Apr 1999 23:39:03 -0700 (PDT)
Received: from caesar.udac.se (caesar.udac.se [193.44.79.10]) by smtp.udac.net (8.9.1/8.9.1) with ESMTP id IAA02517 for <[e-mail]>; Fri, 16 Apr 1999 08:39:34 +0200
Received: from mega (t1o69p77.telia.com [62.20.144.77]) by caesar.udac.se (8.7.3/NetworkC-1) with SMTP id IAA89969; Fri, 16 Apr 1999 08:39:30 +0200
Message-ID: <000801be87db$ffd55070$[e-mail]>
From: "Anders Rundgren" <[e-mail]>
To: "Paul Koning" <[e-mail]>, <[e-mail]>
Subject: Re: New proposed solution to the QC biometric issue
Date: Fri, 16 Apr 1999 08:37:36 +0100
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.2106.4
X-MimeOLE: Produced By Microsoft MimeOLE V4.72.2106.4
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by mail.proper.com id XAA21259
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Paul,
<snip>>


>I'm puzzled.  A week or two ago it sounded like this whole topic had
>been talked to death and was being set aside entirely.  Now it seems
>all to be coming back again.  Do we have to debate the entire thing
>all over?


Paul,
I understand that you are puzzled.  The problem is that the IETF have grossly
underestimated the task of making a QC profile that will get the importance it should.

I think that QCs as a whole should haven been discussed in an own list by people
who have interests in this and have a wider background than just PKI. 
Now the PKIX-list is filled with (for many people) annoying, and largely uninteresting posts.
In the case of bio-metrics it is IMO as an initial step enough to find out:

1) What kind of bio-metric data that should be supported and why

2) How the infrastructure is supposed to work (in particular access to the original bio-data template).
There could be a few variants here are otherwise consensus may not be reached

When the requirements are known - then it is time for the ASN.1 - people
to make a TECHNICAL solution.  Of course there must be technical discussions
going on from the start to see that the end-result is useful.  

But this wish is probably MUCH too late to be realized.

Anders



Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id NAA26425 for ietf-pkix-bks; Thu, 15 Apr 1999 13:52:35 -0700 (PDT)
Received: from relay5.UU.NET (relay5.UU.NET [192.48.96.15]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id NAA26420 for <[e-mail]>; Thu, 15 Apr 1999 13:52:34 -0700 (PDT)
Received: from xedia.com by relay5.UU.NET with SMTP  (peer crosschecked as: madway.xedia.com [198.202.232.199]) id QQglcd06407 for <[e-mail]>; Thu, 15 Apr 1999 16:52:13 -0400 (EDT)
Received: from tonga.xedia.com by xedia.com (4.1/SMI-4.1) id AA16374; Thu, 15 Apr 99 16:51:52 EDT
Received: by tonga.xedia.com (SMI-8.6/SMI-SVR4) id QAA19225; Thu, 15 Apr 1999 16:52:01 -0400
Date: Thu, 15 Apr 1999 16:52:01 -0400
Message-Id: <[e-mail]>
From: Paul Koning <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
To: [e-mail]
Subject: Re: New proposed solution to the QC biometric issue
References: <002601be8781$dfff8b30$[e-mail]>
X-Mailer: VM 6.34 under 20.3 "Vatican City" XEmacs  Lucid
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

>>>>> "Anders" == Anders Rundgren <[e-mail]> writes:

 Anders> <snip>

 >>> There are two kinds of biometric attributes that can be used : a
 >>> picture or a manual signature from the certificate owner.

 Anders> Fingerprints are coming strong.

I'm puzzled.  A week or two ago it sounded like this whole topic had
been talked to death and was being set aside entirely.  Now it seems
all to be coming back again.  Do we have to debate the entire thing
all over?

	paul




Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id MAA25875 for ietf-pkix-bks; Thu, 15 Apr 1999 12:59:37 -0700 (PDT)
Received: from gatekeeper.entrust.com (gatekeeper.entrust.com [204.101.128.170]) by mail.proper.com (8.8.8/8.8.5) with SMTP id MAA25869 for <[e-mail]>; Thu, 15 Apr 1999 12:59:35 -0700 (PDT)
Received: 	id PAA23100; Thu, 15 Apr 1999 15:55:26 -0400
Received: by gateway id <269J4YKT>; Thu, 15 Apr 1999 15:57:48 -0400
Message-ID: <01E1D01C12D7D211AFC70090273D20B112BDD1@sothmxs06>
From: Robert Zuccherato <[e-mail]>
To: "'Manuel Heras Gilsanz'" <[e-mail]>
Cc: Denis Pinkas <[e-mail]>, "'Jose A. Manas'" <[e-mail]>, [e-mail], [e-mail]
Subject: RE: Time-Stamp: Why not use several hashes?
Date: Thu, 15 Apr 1999 15:57:47 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.1960.3)
Content-Type: text/plain; charset="iso-8859-1"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

My comments are below.

> ----------
> From: 	Manuel Heras Gilsanz[SMTP:[e-mail]]
> Sent: 	Wednesday, April 14, 1999 6:39 PM
> To: 	Robert Zuccherato
> Cc: 	Denis Pinkas; 'Jose A. Manas'; [e-mail]; [e-mail]
> Subject: 	Re: Time-Stamp: Why not use several hashes?
> 
> Robert,
> 
> > I think that if a common hash function is broken (for example SHA-1)
> then no
> > signature created within that infrastructure, with that hash function
> can be
> > trusted, including the TSA's.  Thus, I am reluctant to include multiple
> > hashes within the message imprint.  It will not actually help if the
> hash
> > algorithm used to sign the token is broken.  [...]
> 
> I don't agree with you in the importance assigned to the hashes used in
> the request itself and those used in the signatures. I think both hashes
> have unequal impact on the process, for several reasons:
> 
> -The digital signature is not necessarily the single evidence supporting
> the validity of time-stamp tokens; there could exist some form of
> linking, there could be inter-TSA cross-time-stamping, etc., and in
> these cases the weakest point in the architecture is the path from the
> user document to the TSA, i.e., the message imprint(s) provided by the
> user in the time-stamp request. [In fact, reliable time-stamping schemes
> can be devised without resort to digital signatures.]
> 
But in the scheme we describe, the digital signature is the single evidence
supporting the validity of the time stamp tokens.

> -Digital signatures can become obsolete (they will when the certificates
> of the user, the TSA and/or main CA expire), but in time-stamping
> operations time is essential, and TS-tokens should survive to the pass
> of time. If a hash were broken, the digital signatures could be
> re-issued (time is not essential in them), whereas time-stamps using
> this (single) algorithm for imprint generation would have to be
> invalidated.
> 
Well actually if SHA-1, for example, was broken today then every timestamp
signed using SHA-1 would be invalidated.  What is more likely though is that
SHA-1 would be broken over a period of time and people would know that it
was nearing the end of its useful life.  Then tokens signed using SHA-1
should be re-timestamped.  Similarly, if the message imprint was computed
using SHA-1, the message and the token together could be re-timestamped to
show that the message and imprint existed before SHA-1 actually broke.

> -New document imprints cannot be obtained without cooperation from the
> user, whereas additional digital signatures can be provided by the TSA
> independently. Therefore providing support for several message imprints
> in a single request would greatly reduce the need of user intervention,
> and would increase the time between renewals.
> 
Surely you are not suggesting that a TSA would re-issue EVERY timestamp that
it had issued using a particular hash algorithm.  What is more likely is
that the TSA would inform user's that an algorithm was reaching the end of
it's lifetime and advise them to re-timestamp those items which are still
important.  This requires user interaction.


> > Also, as I stated earlier, if
> > certain individuals really want to do this, they can do it by defining a
> new
> > OID.
> 
> 
> In Section 2.1, "Requirements on the TSA" of the current TS PKIX draft,
> point 8 specifies that the OIDs of the hashes provided by the users must
> be analyzed by the TSA in order to check that they are "sufficiently
> secure"; this is a very important and appropriate requirement,
> introduced to prevent the use of potentially weak hashes. According to
> this requirement, users cannot (unilaterally) define new hash OIDs in
> order to aggregate several "normal" hashes into one, since these OIDs
> would be unknown to the TSA, and therefore rejected. Apart from this
> conflict with the requirements on TSA operation, I sincerely believe it
> is much easier to accomodate the multiple-imprints construct within the
> protocol structures, thus avoiding the need of agreeing on a full set of
> OIDs for multiple-hash functions.
> 
I did not mean to imply that a user could unilaterally define a new hash
OID.  A TSA would most likely list in its policy which hash functions were
acceptable to it.  If the TSA felt that this was an important issue, one of
those could be an OID signaling a concatenation of hashes.

	Robert.





Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id MAA25837 for ietf-pkix-bks; Thu, 15 Apr 1999 12:54:52 -0700 (PDT)
Received: from smtp.udac.net (smtp.udac.net [193.44.79.123]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id MAA25833 for <[e-mail]>; Thu, 15 Apr 1999 12:54:46 -0700 (PDT)
Received: from caesar.udac.se (caesar.udac.se [193.44.79.10]) by smtp.udac.net (8.9.1/8.9.1) with ESMTP id VAA24104 for <[e-mail]>; Thu, 15 Apr 1999 21:55:16 +0200
Received: from mega (t1o69p12.telia.com [62.20.144.12]) by caesar.udac.se (8.7.3/NetworkC-1) with SMTP id VAA32326; Thu, 15 Apr 1999 21:54:06 +0200
Message-ID: <002501be8781$d88f8d50$[e-mail]>
From: "Anders Rundgren" <[e-mail]>
To: "Stefan Santesson" <[e-mail]>, "Stephen Farrell" <[e-mail]>
Cc: <[e-mail]>, <[e-mail]>
Subject: Re: New proposed solution to the QC biometric issue 
Date: Thu, 15 Apr 1999 21:52:12 +0100
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.2106.4
X-MimeOLE: Produced By Microsoft MimeOLE V4.72.2106.4
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by mail.proper.com id MAA25834
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Stephen,

>- if you're only storing a hash, how do I find the 
>original - maybe a URI is needed in addition

Absolutely!  Although I am more into calling them URLs...

Unfortunately this scheme has a few inherent problems that some of the
other proposed schemes do not exibit:

1) Who has access to these URIs?  Assuming they are networked this
is a problem.

2) The exclusion of the "real thing" from QCs makes it impossible to sign
in a STANDARD way (PKCS #7) and retaining biodata as the URIs do
not have to be accessible for anyone and they may also die after the
cert has expired. 

3) One (networked) fetch for each biometric attribute slows down the process a bit.

Regards
Anders
http://www.mobilephones-tng.com





Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id MAA25818 for ietf-pkix-bks; Thu, 15 Apr 1999 12:53:58 -0700 (PDT)
Received: from smtp.udac.net (smtp.udac.net [193.44.79.123]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id MAA25814 for <[e-mail]>; Thu, 15 Apr 1999 12:53:54 -0700 (PDT)
Received: from caesar.udac.se (caesar.udac.se [193.44.79.10]) by smtp.udac.net (8.9.1/8.9.1) with ESMTP id VAA24095 for <[e-mail]>; Thu, 15 Apr 1999 21:54:23 +0200
Received: from mega (t1o69p12.telia.com [62.20.144.12]) by caesar.udac.se (8.7.3/NetworkC-1) with SMTP id VAA102017; Thu, 15 Apr 1999 21:54:22 +0200
Message-ID: <002601be8781$dfff8b30$[e-mail]>
From: "Anders Rundgren" <[e-mail]>
To: "Denis Pinkas" <[e-mail]>, <[e-mail]>
Subject: Re: New proposed solution to the QC biometric issue
Date: Thu, 15 Apr 1999 21:52:28 +0100
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.2106.4
X-MimeOLE: Produced By Microsoft MimeOLE V4.72.2106.4
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by mail.proper.com id MAA25815
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

<snip>
>> Proposed text:
>>
>> " In some cases the subject name that is contained in a public key
>> certificate may not be meaningful enough. This may happen because of the
>> existence of synonyms or because of the use of pseudonyms. A distinction
>> could be made if more attributes were present. However, adding more
>> attributes to a public key certificate placed in a public repository
>> would be going against privacy protection. 

I do not agree on your conclusion.  Whatever attributes you put in a certificate
they should not be in a PUBLIC repository.   A so trivial item like "dateOfBirth" is
a thing that many people object to having published. 

<snip>

>>There are two kinds of biometric
>> attributes that can be used : a picture or a manual signature from the
>> certificate owner.


Fingerprints are coming strong.

http://www.veridicom.com/

Note: There are at least 25 other companies doing similar stuff although I
was impressed by Veridicom's system as the manage to make their
templates a mere 300 bytes.  Formulas rather than pattern it seems.

Fingerprints have one big advantage over the other two items:

They CAN actually be used to automatically verify a persons authenticity at
an entrance in a reasonable controlled area.  That you can cut of a person's
finger is true but there is always some end to what is possible in terms
of security.  The fingerprint solution is very LOW-COST and complements
a smart-card PIN-code very well.

<snip>

Regards
Anders
http://www.mobilephones-tng.com




Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id MAA25379 for ietf-pkix-bks; Thu, 15 Apr 1999 12:07:27 -0700 (PDT)
Received: from spyrus.com (mail.spyrus.com [207.212.34.30]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id MAA25375 for <[e-mail]>; Thu, 15 Apr 1999 12:07:26 -0700 (PDT)
Received: from rhousley_laptop.spyrus.com ([209.66.108.101]) by spyrus.com (8.7.6/8.7.3/arc) with SMTP id MAA12701 for <[e-mail]>; Thu, 15 Apr 1999 12:06:42 -0700 (PDT)
Message-Id: <[e-mail]>
X-Sender: [e-mail] (Unverified)
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1 
Date: Thu, 15 Apr 1999 14:32:32 -0400
To: [e-mail]
From: Russ Housley <[e-mail]>
Subject: RE: CA vs. EE cert processing
In-Reply-To: <v04020a05b33a4da98bab@[128.33.238.50]>
References: <D1A949D4508DD1119C8100400533BEDC0E2B5C@DSG1>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

I have kept quiet on this thread.  I cannot hold it in any longer.

RFC 2459 has no ambiguity in this area.  If basicConstraints is present,
then the cA boolean tells whether the certificate belongs to a CA or an EE.
 If basicConstraints is absent, then the certificate belongs to an EE.  Period.

If an implementor wishes to support other profiles in addition to RFC 2459,
then the logic may be more complex.  Fine.  This was a market choice made
by the implementor.

I do not think that RFC 2459 should be altered to make support for multiple
profiles easier.

Russ


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id KAA24187 for ietf-pkix-bks; Thu, 15 Apr 1999 10:07:58 -0700 (PDT)
Received: from smtp7.ny.us.ibm.com (smtp7.ny.us.ibm.com [198.133.22.19]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id KAA24183 for <[e-mail]>; Thu, 15 Apr 1999 10:07:57 -0700 (PDT)
From: [e-mail]
Received: from northrelay02.pok.ibm.com (northrelay02.pok.ibm.com [9.117.200.22]) by smtp7.ny.us.ibm.com (8.8.8/8.8.7) with ESMTP id NAA81684; Thu, 15 Apr 1999 13:08:11 -0400
Received: from D51MTA05.pok.ibm.com (d51mta05.pok.ibm.com [9.117.200.33]) by northrelay02.pok.ibm.com (8.8.8m2/NCO v1.8) with SMTP id NAA211208; Thu, 15 Apr 1999 13:07:48 -0400
Received: by D51MTA05.pok.ibm.com(Lotus SMTP MTA Internal build v4.6.2  (651.2 6-10-1998))  id 85256754.005E13E5 ; Thu, 15 Apr 1999 13:07:34 -0400
X-Lotus-FromDomain: IBMUS
To: Petra Gloeckner <[e-mail]>
cc: Denis Pinkas <[e-mail]>, [e-mail]
Message-ID: <[e-mail]>
Date: Thu, 15 Apr 1999 13:07:20 -0400
Subject: Re: New proposed solution to the QC biometric issue
Mime-Version: 1.0
Content-type: text/plain; charset=us-ascii
Content-Disposition: inline
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

     Wouldn't a better syntax for URIorOIDsyntax be

   URIorOIDsyntax ::== CHOICE {
      uri            IA5String,
       biometricType    [0] IMPLICIT OBJECT IDENTIFIER
   } ?

     You could add a third choice value as:
      stdBiometricType [1] IMPLICIT StdBiometricType
   StdBiometricType ::= INTEGER {
     PICTURE_GIF (0), HANDWRITTEN_SIGNATURE_GIF(1)      -- more to follow
   }
     I think you have to specify both the format and the interpretation of
a graphic for pictures and manual signatures.

          Tom Gindin


Petra Gloeckner <[e-mail]> on 04/15/99 11:54:36 AM

To:   Denis Pinkas <[e-mail]>
cc:   [e-mail] (bcc: Tom Gindin/Watson/IBM)
Subject:  Re: New proposed solution to the QC biometric issue





Denis Pinkas wrote:
>
> >From these examples, it can be seen that a URI is not mandatory, but the
> name of the corresponding file would be usefull as well as the type of
> biometric information. As far as the typeOfBiometricData is concerned I
> would prefer an integer instead of an OID: it is shorter (when
> certificates are stored in smart cards) and we could expand the list of
> integers as needed. At the time being, two integers seem sufficient
> (picture or manual signature).
>

Denis,

why would you like to include the name of the corresponding file in
the certificate as well?

Without this name I'd suggest the following structure considering the
comments of Stephen and you:

   BiometricData ::= SEQUENCE {
         URIorOID         URIorOIDsyntax,
         hashalgorithm        AlgorithmIdentifier,
         biometricDataHash    OCTET STRING }

   URIorOIDsyntax ::== CHOICE {
      uri            [0] IA5String
         typeOfBiometricData  [1] INTEGER }

with the following types of biometric data defined so far:
     0    picture
     1    manual signature

Best regards - Petra




Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id IAA23539 for ietf-pkix-bks; Thu, 15 Apr 1999 08:55:47 -0700 (PDT)
Received: from sonne.darmstadt.gmd.de (sonne.darmstadt.gmd.de [141.12.62.20]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id IAA23535 for <[e-mail]>; Thu, 15 Apr 1999 08:55:45 -0700 (PDT)
Received: from darmstadt.gmd.de (pc-ravenna [141.12.33.61]) by sonne.darmstadt.gmd.de (8.8.8/8.8.5) with ESMTP id RAA02535; Thu, 15 Apr 1999 17:55:08 +0200 (MET DST)
Message-ID: <[e-mail]>
Date: Thu, 15 Apr 1999 17:54:36 +0200
From: Petra Gloeckner <[e-mail]>
X-Mailer: Mozilla 4.08 [en] (WinNT; I)
MIME-Version: 1.0
To: Denis Pinkas <[e-mail]>
CC: [e-mail]
Subject: Re: New proposed solution to the QC biometric issue
References: <[e-mail]> <[e-mail]> <[e-mail]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Denis Pinkas wrote:
> 
> >From these examples, it can be seen that a URI is not mandatory, but the
> name of the corresponding file would be usefull as well as the type of
> biometric information. As far as the typeOfBiometricData is concerned I
> would prefer an integer instead of an OID: it is shorter (when
> certificates are stored in smart cards) and we could expand the list of
> integers as needed. At the time being, two integers seem sufficient
> (picture or manual signature).
> 

Denis,

why would you like to include the name of the corresponding file in
the certificate as well? 

Without this name I'd suggest the following structure considering the
comments of Stephen and you:

   BiometricData ::= SEQUENCE {
         URIorOID	      URIorOIDsyntax,
         hashalgorithm        AlgorithmIdentifier,
         biometricDataHash    OCTET STRING }

   URIorOIDsyntax ::== CHOICE {
	 uri		      [0] IA5String 
         typeOfBiometricData  [1] INTEGER }

with the following types of biometric data defined so far:
	0    picture
	1    manual signature

Best regards - Petra


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id IAA23078 for ietf-pkix-bks; Thu, 15 Apr 1999 08:07:44 -0700 (PDT)
Received: from sonne.darmstadt.gmd.de (sonne.darmstadt.gmd.de [141.12.62.20]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id IAA23074 for <[e-mail]>; Thu, 15 Apr 1999 08:07:42 -0700 (PDT)
Received: from darmstadt.gmd.de (pc-ravenna [141.12.33.61]) by sonne.darmstadt.gmd.de (8.8.8/8.8.5) with ESMTP id RAA01306; Thu, 15 Apr 1999 17:06:27 +0200 (MET DST)
Message-ID: <[e-mail]>
Date: Thu, 15 Apr 1999 17:05:55 +0200
From: Petra Gloeckner <[e-mail]>
X-Mailer: Mozilla 4.08 [en] (WinNT; I)
MIME-Version: 1.0
To: [e-mail]
CC: [e-mail]
Subject: Re: New proposed solution to the QC biometric issue
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

I'm forwarding the following comment on behalf of Bruno Struif who 
is involoved in biometric technologies and algorithms at GMD:

Comment to "Biometrics in Qualified Certificates"

1. The only biometric data which may have some relevance to qualified
certificates is  a "certificate holder portrait image" (i.e. a foto) in
a defined coding scheme.
2. If the foto is too big (about 2 kbytes in a compressed version), the
hash value of the foto may be used.
3. If the hash value is used then the hash algorithm has to be denoted
and the reference where the foto from which the hash value was derived
is located. A verifier has to fetch the foto, to hash it and to compare
the computed hash value with the hash value presented in the qualified
certificate.
4. The rationale as it stands is wrong from my point of view: There are
no "biometric comparing algorithms" involved which have to compare
reference data with actually measured verification data taken from the
person to be authenticated. An acceptable wording would be: "The
rationale for supporting biometric data (i.e. a certificate holder
portrait image) would be to support biometric data in a qualified
certificate in the sense of a certified attribute of the certificate
holding person."

Bruno Struif
e-mail: [e-mail]


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id GAA17786 for ietf-pkix-bks; Thu, 15 Apr 1999 06:34:53 -0700 (PDT)
Received: from popmail.inbox.se (popmail.inbox.se [193.12.72.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id GAA17782 for <[e-mail]>; Thu, 15 Apr 1999 06:34:51 -0700 (PDT)
Received: from stefan2 (accurata.inbox.se [193.12.72.24]) by popmail.inbox.se (8.9.3/8.9.3) with SMTP id PAA21169; Thu, 15 Apr 1999 15:32:02 +0200
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: Windows Eudora Pro Version 3.0 (32)
Date: Thu, 15 Apr 1999 15:32:02 +0200
To: Denis Pinkas <[e-mail]>, Petra Gloeckner <[e-mail]>
From: Stefan Santesson <[e-mail]>
Subject: Re: New proposed solution to the QC biometric issue
Cc: [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 mail.proper.com id GAA17783
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Denis,

In general good suggestions but I oppose to the following general approach:

At 12:42 PM 4/15/99 +0200, Denis Pinkas wrote:
<snip>
>"In order to achieve a balance
>between these two opposite requirements the hash values of some
>additional attributes can be placed in a public key certificate."

As a general approach this would be a bad thing to do.

Most name attributes doesn't have enough name space for a hash to provide
any protection against exhaustive search for the originating data.

Say for example that you provide hash on names. It would not be to hard to
make an exhaustive search on frequent names and thereby find most of the
names through their hash.

The same with a social security number or a birth date. The name space are
in these cases tiny compared to the computing power of a single workstation.

So providing additional "hidden" attributes by providing their hash will
generally require some additional construct algorithm which prevents
exhaustive search (e.g. adding random data and/or combining several
attributes), and such logic is well beyond the scope of the QC work (As I
see it now).

/Stefan

-------------------------------------------------------------------
Stefan Santesson                <[e-mail]>
Accurata Systemsäkerhet AB      http://www.accurata.se
Slagthuset                      Tel. [phone]              
211 20  Malmö                   Fax. [phone]              
Sweden                        Mobile [phone]

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


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id EAA16441 for ietf-pkix-bks; Thu, 15 Apr 1999 04:42:12 -0700 (PDT)
Received: from epic.iris.com (epic.iris.com [198.112.211.21]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id EAA16437 for <[e-mail]>; Thu, 15 Apr 1999 04:42:09 -0700 (PDT)
From: [e-mail]
Subject: WG process and interactions (RE: CA vs. EE cert processing)
To: Stephen Kent <[e-mail]>
Cc: "'[e-mail] '" <[e-mail]>
X-Mailer: Lotus Notes PVCS Build (based on 165)  "Mar 11 1999"
Date: Thu, 15 Apr 1999 11:42:38 GMT
Message-ID: <[e-mail]>
X-Priority: 3 (Normal)
X-MIMETrack: Serialize by Router on Epic/Iris(Daily Build (based on 166.1)|Apr  6 1999) at 04/15/99 07:44:59 AM
MIME-Version: 1.0
Content-type: text/plain; charset=us-ascii
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

> from joining in.  I have received several private messages expressing
> support for the position I have stated, but these, and probably other
> folks, don't want to become engaged in a protracted e-mail exchange of
this
> sort.

>From a process point of view, this is very unfortunate. It's important to
the
WG for the members to be able to recognize the same "rough concensus" as
the
chair. People should be encouraged to feel comfortable stating their
opinion
and _not_ engaging in protracted exchanges, if that's what they prefer. So,
here's my attempt at encouraging :-).
     Mez



Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id EAA16152 for ietf-pkix-bks; Thu, 15 Apr 1999 04:21:21 -0700 (PDT)
Received: from clbull.frcl.bull.fr (clbull.frcl.bull.fr [129.182.1.20]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id EAA16148 for <[e-mail]>; Thu, 15 Apr 1999 04:21:17 -0700 (PDT)
Received: from k2.frcl.bull.fr (k2.frcl.bull.fr [129.182.100.2]) by clbull.frcl.bull.fr (8.9.1a/8.9.1) with ESMTP id NAA14906 for <[e-mail]>; Thu, 15 Apr 1999 13:21:38 +0200
Received: from bull.net (frcls6118.frcl.bull.fr [129.182.109.213]) by k2.frcl.bull.fr (AIX4.2/UCB 8.7/8.7) with ESMTP id NAA23518 for <[e-mail]>; Thu, 15 Apr 1999 13:21:38 +0200 (DFT)
Message-ID: <[e-mail]>
Date: Thu, 15 Apr 1999 13:22:07 +0200
From: Denis Pinkas <[e-mail]>
Organization: Bull
X-Mailer: Mozilla 4.06 [fr] (Win95; I)
MIME-Version: 1.0
To: [e-mail]
Subject: Re: New proposed solution to the QC biometric issue
References: <[e-mail]> <[e-mail]> <[e-mail]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

In the attached message, I would guess that everyone would have noticed that
I wrote "synonyms", but I meant "homonyms".  :-)

Denis

> Petra,
>
> It has been requested on the list to indicate the usage of such
> data.While this kind of information does not belong to the core
> document, it would nevertheless be interresting to place it in an
> informative annex. Hereafter is a first stone to build that section.
> This is not the single way to use the extension, but one way. From this,
> you can see the implications on the ASN1.
>
> Proposed text:
>
> " In some cases the subject name that is contained in a public key
> certificate may not be meaningful enough. This may happen because of the
> existence of synonyms or because of the use of pseudonyms. A distinction
> could be made if more attributes were present. However, adding more
> attributes to a public key certificate placed in a public repository
> would be going against privacy protection. In order to achieve a balance
> between these two opposite requirements the hash values of some
> additional attributes can be placed in a public key certificate. When
> these additional attributes are provided by the certificate owner, then
> they can be verified. Using biometric attributes may allow to
> unambiguously identify a person. There are two kinds of biometric
> attributes that can be used : a picture or a manual signature from the
> certificate owner.
>
> A picture can be used if the verifier once met the person and later on
> wants to verify that the certificate that he got is relative to the
> person which was met. In such a case, at the first exchange the picture
> is sent and the hash contained in the certificate may be used by the
> verifier to verify that it is the right person. At the next exchange the
> picture does not need to be sent again.
>
> A manual signatuere may be used if a signed document has been received
> before hand. In such a case, at the first exchange the drawing of the
> manual signature is sent and the hash contained in the certificate may
> be used by the verifier to verify that it is the right manual signature.
> At the next exchange the manual signature does not need to be sent
> again."
>
> >From these examples, it can be seen that a URI is not mandatory, but the
> name of the corresponding file would be usefull as well as the type of
> biometric information. As far as the typeOfBiometricData is concerned I
> would prefer an integer instead of an OID: it is shorter (when
> certificates are stored in smart cards) and we could expand the list of
> integers as needed. At the time being, two integers seem sufficient
> (picture or manual signature).
>
> Regards,
>
> Denis
>
> > Hi Stephen,
> >
> > Stephen Farrell wrote:
> > >
> > > - you'll need an algo id somewhere or you can't recalc. the
> > > hash
> >
> > yes, I agree. So I correct my ASN.1 definition of the BiometricData:
> >
> > BiometricData ::= SEQUENCE {
> >          typeOfBiometricData  OBJECT IDENTIFIER
> >          hashalgorithm        AlgorithmIdentifier
> >          biometricDataHash    OCTET STRING }
> >
> > > - you'll need to specify how the actual data is to be
> > > flattened before hash calculation (e.g. strip CR/LF or
> > > whatever), this could be incorporated with the
> > > algo id (so use a transform id)
> >
> > As I understood the whole discussion the reference data has been
> > provided before, i.e. it is already existing and pre-stored.
> > There is no new verification data which needs to be transformed
> > and compared against the reference data. The purpose of the
> > biometrics extension is just to verify by a signed message that
> > the provided reference data belongs to the certificate holder.
> >
> > Correct me, if I'm wrong!
> >
> > Petra



Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id DAA14211 for ietf-pkix-bks; Thu, 15 Apr 1999 03:41:42 -0700 (PDT)
Received: from clbull.frcl.bull.fr (clbull.frcl.bull.fr [129.182.1.20]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id DAA14202 for <[e-mail]>; Thu, 15 Apr 1999 03:41:39 -0700 (PDT)
Received: from k2.frcl.bull.fr (k2.frcl.bull.fr [129.182.100.2]) by clbull.frcl.bull.fr (8.9.1a/8.9.1) with ESMTP id MAA20342; Thu, 15 Apr 1999 12:42:01 +0200
Received: from bull.net (frcls6118.frcl.bull.fr [129.182.109.213]) by k2.frcl.bull.fr (AIX4.2/UCB 8.7/8.7) with ESMTP id MAA44808; Thu, 15 Apr 1999 12:42:01 +0200 (DFT)
Message-ID: <[e-mail]>
Date: Thu, 15 Apr 1999 12:42:30 +0200
From: Denis Pinkas <[e-mail]>
Organization: Bull
X-Mailer: Mozilla 4.06 [fr] (Win95; I)
MIME-Version: 1.0
To: Petra Gloeckner <[e-mail]>
CC: [e-mail]
Subject: Re: New proposed solution to the QC biometric issue
References: <[e-mail]> <[e-mail]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Petra,

It has been requested on the list to indicate the usage of such
data.While this kind of information does not belong to the core
document, it would nevertheless be interresting to place it in an
informative annex. Hereafter is a first stone to build that section.
This is not the single way to use the extension, but one way. From this,
you can see the implications on the ASN1.

Proposed text:

" In some cases the subject name that is contained in a public key
certificate may not be meaningful enough. This may happen because of the
existence of synonyms or because of the use of pseudonyms. A distinction
could be made if more attributes were present. However, adding more
attributes to a public key certificate placed in a public repository
would be going against privacy protection. In order to achieve a balance
between these two opposite requirements the hash values of some
additional attributes can be placed in a public key certificate. When
these additional attributes are provided by the certificate owner, then
they can be verified. Using biometric attributes may allow to
unambiguously identify a person. There are two kinds of biometric
attributes that can be used : a picture or a manual signature from the
certificate owner.

A picture can be used if the verifier once met the person and later on
wants to verify that the certificate that he got is relative to the
person which was met. In such a case, at the first exchange the picture
is sent and the hash contained in the certificate may be used by the
verifier to verify that it is the right person. At the next exchange the
picture does not need to be sent again.

A manual signatuere may be used if a signed document has been received
before hand. In such a case, at the first exchange the drawing of the
manual signature is sent and the hash contained in the certificate may
be used by the verifier to verify that it is the right manual signature.
At the next exchange the manual signature does not need to be sent
again."

>From these examples, it can be seen that a URI is not mandatory, but the
name of the corresponding file would be usefull as well as the type of
biometric information. As far as the typeOfBiometricData is concerned I
would prefer an integer instead of an OID: it is shorter (when
certificates are stored in smart cards) and we could expand the list of
integers as needed. At the time being, two integers seem sufficient
(picture or manual signature).

Regards,

Denis


> Hi Stephen,
>
> Stephen Farrell wrote:
> >
> > - you'll need an algo id somewhere or you can't recalc. the
> > hash
>
> yes, I agree. So I correct my ASN.1 definition of the BiometricData:
>
> BiometricData ::= SEQUENCE {
>          typeOfBiometricData  OBJECT IDENTIFIER
>          hashalgorithm        AlgorithmIdentifier
>          biometricDataHash    OCTET STRING }
>
> > - you'll need to specify how the actual data is to be
> > flattened before hash calculation (e.g. strip CR/LF or
> > whatever), this could be incorporated with the
> > algo id (so use a transform id)
>
> As I understood the whole discussion the reference data has been
> provided before, i.e. it is already existing and pre-stored.
> There is no new verification data which needs to be transformed
> and compared against the reference data. The purpose of the
> biometrics extension is just to verify by a signed message that
> the provided reference data belongs to the certificate holder.
>
> Correct me, if I'm wrong!
>
> Petra



Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id CAA10143 for ietf-pkix-bks; Thu, 15 Apr 1999 02:51:21 -0700 (PDT)
Received: from sonne.darmstadt.gmd.de (sonne.darmstadt.gmd.de [141.12.62.20]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id CAA10137 for <[e-mail]>; Thu, 15 Apr 1999 02:51:18 -0700 (PDT)
Received: from darmstadt.gmd.de (pc-ravenna [141.12.33.61]) by sonne.darmstadt.gmd.de (8.8.8/8.8.5) with ESMTP id LAA03591; Thu, 15 Apr 1999 11:50:27 +0200 (MET DST)
Message-ID: <[e-mail]>
Date: Thu, 15 Apr 1999 11:49:56 +0200
From: Petra Gloeckner <[e-mail]>
X-Mailer: Mozilla 4.08 [en] (WinNT; I)
MIME-Version: 1.0
To: Stephen Farrell <[e-mail]>
CC: Stefan Santesson <[e-mail]>, [e-mail]
Subject: Re: New proposed solution to the QC biometric issue
References: <[e-mail]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Hi Stephen,

Stephen Farrell wrote:
> 
> - you'll need an algo id somewhere or you can't recalc. the
> hash

yes, I agree. So I correct my ASN.1 definition of the BiometricData:

BiometricData ::= SEQUENCE { 
         typeOfBiometricData  OBJECT IDENTIFIER 
	 hashalgorithm	      AlgorithmIdentifier
         biometricDataHash    OCTET STRING }
 
> - you'll need to specify how the actual data is to be
> flattened before hash calculation (e.g. strip CR/LF or
> whatever), this could be incorporated with the
> algo id (so use a transform id)

As I understood the whole discussion the reference data has been 
provided before, i.e. it is already existing and pre-stored. 
There is no new verification data which needs to be transformed 
and compared against the reference data. The purpose of the 
biometrics extension is just to verify by a signed message that 
the provided reference data belongs to the certificate holder.

Correct me, if I'm wrong!

Petra


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id AAA05923 for ietf-pkix-bks; Thu, 15 Apr 1999 00:39:31 -0700 (PDT)
Received: from popmail.inbox.se (popmail.inbox.se [193.12.72.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id AAA05919 for <[e-mail]>; Thu, 15 Apr 1999 00:39:28 -0700 (PDT)
Received: from stefan2 (accurata.inbox.se [193.12.72.24]) by popmail.inbox.se (8.9.3/8.9.3) with SMTP id JAA17048; Thu, 15 Apr 1999 09:39:22 +0200
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: Windows Eudora Pro Version 3.0 (32)
Date: Thu, 15 Apr 1999 09:39:22 +0200
To: Stephen Farrell <[e-mail]>
From: Stefan Santesson <[e-mail]>
Subject: Re: New proposed solution to the QC biometric issue 
Cc: [e-mail], [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 mail.proper.com id AAA05920
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Good idea Stephen,

I like the idea to include an URI, Im not so sure that the OID should be
excluded though. But maybe the best thing would be to make both OID and URI
optional.

/Stefan

At 04:42 PM 4/14/99 +0100, Stephen Farrell wrote:
>
>Stefan,
>
>Haven't followed this but a couple of thoughts occur:
>
>- if you're only storing a hash, how do I find the 
>original - maybe a URI is needed in addition
>
>- if you buy into the above, couldn't the URI replace
>the OID (since e.g. a HTTP response has a MIME type
>which identififes at least the syntax and also 
>identifies the transfer encoding of the actual data)
>
>- you'll need an algo id somewhere or you can't recalc. the
>hash
>
>- you'll need to specify how the actual data is to be
>flattened before hash calculation (e.g. strip CR/LF or
>whatever), this could be incorporated with the
>algo id (so use a transform id)
>
>Regards,
>Stephen.
>
>
-------------------------------------------------------------------
Stefan Santesson                <[e-mail]>
Accurata Systemsäkerhet AB      http://www.accurata.se
Slagthuset                      Tel. [phone]              
211 20  Malmö                   Fax. [phone]              
Sweden                        Mobile [phone]

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


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id XAA01440 for ietf-pkix-bks; Wed, 14 Apr 1999 23:24:52 -0700 (PDT)
Received: from natasha1. (natasha-gw.checkpoint.com [199.203.73.129]) by mail.proper.com (8.8.8/8.8.5) with SMTP id XAA01435 for <[e-mail]>; Wed, 14 Apr 1999 23:24:49 -0700 (PDT)
Received: from cale.checkpoint.com (gray.checkpoint.com [199.203.71.94]) by cale.checkpoint.com (8.9.1/8.9.1) with ESMTP id JAA28023; Thu, 15 Apr 1999 09:27:21 +0300 (IDT)
Message-ID: <[e-mail]>
Date: Thu, 15 Apr 1999 09:23:58 +0300
From: Moshe Litvin <[e-mail]>
X-Mailer: Mozilla 4.51 [en] (WinNT; I)
X-Accept-Language: en
MIME-Version: 1.0
To: Stephen Kent <[e-mail]>
CC: [e-mail]
Subject: Re: CA vs. EE cert processing
References: <v04020a17b331af2ed303@[128.33.238.98]> <v04020a0bb332fcbd7733@[128.33.238.98]> <v04020a01b33978524f43@[128.33.238.70]>
Content-Type: multipart/mixed; boundary="------------9B79D27B2162F7F83D56B30F"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

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



Stephen Kent wrote:

<snip>

> As David pointed out, this analysis focuses on the wrong cert.  The problem
> is NOT for EE certs, but for CA certs. We need to determine if a cert is or
> is not a CA cert when we encounter it along a path prior to the terminal
> cert.

<snip>

Steve,

The problem is determining weather a certificate is eligible to be in a
certificate path prior to the terminal cert. That is, is it an EE certificate or a
CA certificate. And the problem is what to do if the certificate doesn't contain
the basicConstraints extension.

Moshe



--------------9B79D27B2162F7F83D56B30F
Content-Type: text/x-vcard; charset=us-ascii;
 name="moshe.vcf"
Content-Transfer-Encoding: 7bit
Content-Description: Card for Moshe Litvin
Content-Disposition: attachment;
 filename="moshe.vcf"

begin:vcard 
n:Litvin;Moshe
tel;fax:[phone]
tel;work:[phone]
x-mozilla-html:TRUE
org:Check Point Software Technologies Ltd.
adr:;;;;;;
version:2.1
email;internet:[e-mail]
fn:Moshe Litvin
end:vcard

--------------9B79D27B2162F7F83D56B30F--



Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id PAA10829 for ietf-pkix-bks; Wed, 14 Apr 1999 15:46:57 -0700 (PDT)
Received: from smtp.bankinter.es (dns.bankinter.es [195.235.30.34]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id PAA10825 for <[e-mail]>; Wed, 14 Apr 1999 15:46:48 -0700 (PDT)
Received: from nexo.es (h029217.nexo.es [195.235.29.217]) by smtp.bankinter.es (8.8.8+Sun/8.8.8) with ESMTP id AAA13330; Thu, 15 Apr 1999 00:43:40 +0200 (MET DST)
Message-ID: <[e-mail]>
Date: Thu, 15 Apr 1999 00:39:10 +0200
From: Manuel Heras Gilsanz <[e-mail]>
X-Mailer: Mozilla 4.5 [en] (Win95; I)
X-Accept-Language: en
MIME-Version: 1.0
To: Robert Zuccherato <[e-mail]>
CC: Denis Pinkas <[e-mail]>, "'Jose A. Manas'" <[e-mail]>, [e-mail], [e-mail]
Subject: Re: Time-Stamp: Why not use several hashes?
References: <01E1D01C12D7D211AFC70090273D20B112BDBE@sothmxs06>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Robert,

> I think that if a common hash function is broken (for example SHA-1) then no
> signature created within that infrastructure, with that hash function can be
> trusted, including the TSA's.  Thus, I am reluctant to include multiple
> hashes within the message imprint.  It will not actually help if the hash
> algorithm used to sign the token is broken.  [...]

I don't agree with you in the importance assigned to the hashes used in
the request itself and those used in the signatures. I think both hashes
have unequal impact on the process, for several reasons:

-The digital signature is not necessarily the single evidence supporting
the validity of time-stamp tokens; there could exist some form of
linking, there could be inter-TSA cross-time-stamping, etc., and in
these cases the weakest point in the architecture is the path from the
user document to the TSA, i.e., the message imprint(s) provided by the
user in the time-stamp request. [In fact, reliable time-stamping schemes
can be devised without resort to digital signatures.]

-Digital signatures can become obsolete (they will when the certificates
of the user, the TSA and/or main CA expire), but in time-stamping
operations time is essential, and TS-tokens should survive to the pass
of time. If a hash were broken, the digital signatures could be
re-issued (time is not essential in them), whereas time-stamps using
this (single) algorithm for imprint generation would have to be
invalidated.

-Whereas there is (in principle) no imposed restriction on the structure
of user documents to be time-stamped, the digitally signed constructs
follow rigid definitions that limit the degrees of freedom in a search
for collisions to a hash function.

-New document imprints cannot be obtained without cooperation from the
user, whereas additional digital signatures can be provided by the TSA
independently. Therefore providing support for several message imprints
in a single request would greatly reduce the need of user intervention,
and would increase the time between renewals.


> Also, as I stated earlier, if
> certain individuals really want to do this, they can do it by defining a new
> OID.


In Section 2.1, "Requirements on the TSA" of the current TS PKIX draft,
point 8 specifies that the OIDs of the hashes provided by the users must
be analyzed by the TSA in order to check that they are "sufficiently
secure"; this is a very important and appropriate requirement,
introduced to prevent the use of potentially weak hashes. According to
this requirement, users cannot (unilaterally) define new hash OIDs in
order to aggregate several "normal" hashes into one, since these OIDs
would be unknown to the TSA, and therefore rejected. Apart from this
conflict with the requirements on TSA operation, I sincerely believe it
is much easier to accomodate the multiple-imprints construct within the
protocol structures, thus avoiding the need of agreeing on a full set of
OIDs for multiple-hash functions.


Best wishes,

     - Manuel -

Robert Zuccherato wrote:

>
> > ----------
> > From:         Jose A. Manas[SMTP:[e-mail]]
> > Sent:         Monday, April 12, 1999 4:24 AM
> > To:   Denis Pinkas
> > Cc:   Manuel Heras Gilsanz; [e-mail]; [e-mail]
> > Subject:      Re: Time-Stamp: Why not use several hashes?
> >
> > Denis,
> > I feel uneasy with both arguments.
> >
> > If a guy finds out how to provoke collisions on a hash functions,
> > there is a serious temptation to exploit the hole before
> > publishing it. Breaking a time-stamp infrastructure is a nice
> > goal: you break it before anybody knows it can be broken,
> > and then there is a difficult question about when the TSA was
> > no longer to be trusted.
> >
> > I have some concern as well with respect to breaking a digital
> > signature. If broken but time-stamped,
> > a TSA can still prove that it was signed
> > before it was breakable. But if you break the TSA itself, then
> > there is no help. That about breaking the hash.
> >
> > Still, if you break the TSA signature, you have audit records
> > (stored evidence in the TSA) to help you (as far as there are
> > no collisions in the hash).
> >
> > Alltogether, I aim to say that breaking a hash does break down
> > everything, and it sounds interesting to foresee the case.
> > Allowing for several messageimprints sounds as a cheap end
> > effective countermeasure.
> >
> > pp
> >
> > Denis Pinkas wrote:
> > >
> > > Manuel,
> > >
> > > We want to keep the protocol simple. The threat you mention can be
> > countered
> > > by another way: re-time-stamp later on with a new hash function. If
> > SHA-1
> > > gets broken one day, this will not happen in just one day. Some
> > > cryptographer will first find some weaknesses before you can really
> > forge a
> > > meaningfull message that has the same hash. So you get some time for
> > > re-stamping.
> > >
> > > If this argument were used, then we should sign TWICE, i.e.  in case one
> > > digital signature algorithm was broken. We do not do that. There is no
> > > reason to do it for the hash function.
> > >
> > > Regards,
> > >
> > > Denis
> > >
> > > > Hi.
> > > >
> > > > In the (now expired) latest PKIX draft on time-stamping protocols from
> > > > Sept. 23, 1998, time-stamp requests and tokens support the insertion
> > of
> > > > a single message imprint.
> > > >
> > > > I think several message imprints should be supported. If a hash
> > > > algorithm were broken, time-stamp tokens using it (as the single
> > message
> > > > imprint) would have to be regarded invalid (even if some kind of
> > linking
> > > > mechanism were implemented!). If several hashes had been used, the
> > token
> > > > would still be valid, and it could be promptly renewed in order to
> > > > prevent invalidation should further advances in cryptography render
> > > > other hashes obsolete!
> > > >
> > > > (One must be careful here: there are different extents to which a hash
> > > > algorithm could be broken; in Appendix A of  PKITS-D3
> > > > [http://www.fnmt.es/pkits] there is an interesting analysis of the
> > > > implications that the different kinds of hash failures would have on
> > the
> > > > time-stamping process.)
> > > >
> > > > Of course the requirements on the time-stamp verification process
> > would
> > > > also have be modified to require ("MUST" level) *all* the hashes to
> > > > correctly verify in order to regard the corresponding time-stamp token
> > > > valid.
> > > >
> > > > Best regards,
> > > >
> > > >     - Manuel -
> > > >
> > > > ----
> > > > Manuel Heras-Gilsanz ([e-mail])
> > > > Independent Security Consultant
> > > > Phone: [phone]
> >
> > -- --------------------------------------------------------
> > Prof. Jose A. Manas                     <[e-mail]>
> > Dpt. Telematica                 http://www.dit.upm.es/~pepe
> > E.T.S.I. Telecomunicacion           tel: [+34] 91 336 73 25
> > Ciudad Universitaria                gsm: [+34] 607 73 38 94
> > E-28040 Madrid, SPAIN               fax: [+34] 91 336 73 33
> >




Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id IAA05291 for ietf-pkix-bks; Wed, 14 Apr 1999 08:42:11 -0700 (PDT)
Received: from mail0.sse.ie (mail0.sse.ie [193.120.32.47]) by mail.proper.com (8.8.8/8.8.5) with SMTP id IAA05287 for <[e-mail]>; Wed, 14 Apr 1999 08:42:09 -0700 (PDT)
Received: from mail2.sse.ie by mail0.sse.ie; Wed, 14 Apr 1999 16:42:18 +0100
Received: from mail0.sse.ie (mail0.sse.ie) by mail2.sse.ie (Content Technologies SMTPRS 2.0.15) with ESMTP id <[e-mail]>; Wed, 14 Apr 1999 16:42:12 +0100
Received: from baboo.sse.ie ([e-mail] [193.120.32.109]) by mail0.sse.ie (8.9.1a/8.9.1) with ESMTP id QAA25946; Wed, 14 Apr 1999 16:42:06 +0100 (BST)
Received: from baboo.sse.ie (farrell@baboo [193.120.32.109]) by baboo.sse.ie (8.9.1/8.9.1) with ESMTP id QAA20978; Wed, 14 Apr 1999 16:42:05 +0100 (BST)
Message-Id: <[e-mail]>
X-Mailer: exmh version 1.6.9 8/22/96
To: Stefan Santesson <[e-mail]>
Cc: [e-mail], [e-mail]
Subject: Re: New proposed solution to the QC biometric issue 
In-Reply-To: Your message of "Wed, 14 Apr 1999 12:57:35 +0200." <[e-mail]> 
MIME-Version: 1.0
Date: Wed, 14 Apr 1999 16:42:05 +0100
From: Stephen Farrell <[e-mail]>
Content-Type: text/plain; charset=us-ascii
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Stefan,

Haven't followed this but a couple of thoughts occur:

- if you're only storing a hash, how do I find the 
original - maybe a URI is needed in addition

- if you buy into the above, couldn't the URI replace
the OID (since e.g. a HTTP response has a MIME type
which identififes at least the syntax and also 
identifies the transfer encoding of the actual data)

- you'll need an algo id somewhere or you can't recalc. the
hash

- you'll need to specify how the actual data is to be
flattened before hash calculation (e.g. strip CR/LF or
whatever), this could be incorporated with the
algo id (so use a transform id)

Regards,
Stephen.




Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id IAA04868 for ietf-pkix-bks; Wed, 14 Apr 1999 08:16:04 -0700 (PDT)
Received: from clbull.frcl.bull.fr (clbull.frcl.bull.fr [129.182.1.20]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id IAA04864 for <[e-mail]>; Wed, 14 Apr 1999 08:16:01 -0700 (PDT)
Received: from k2.frcl.bull.fr (k2.frcl.bull.fr [129.182.100.2]) by clbull.frcl.bull.fr (8.9.1a/8.9.1) with ESMTP id RAA24136; Wed, 14 Apr 1999 17:16:21 +0200
Received: from bull.net (frcls6118.frcl.bull.fr [129.182.109.213]) by k2.frcl.bull.fr (AIX4.2/UCB 8.7/8.7) with ESMTP id RAA26216; Wed, 14 Apr 1999 17:16:20 +0200 (DFT)
Message-ID: <[e-mail]>
Date: Wed, 14 Apr 1999 17:16:45 +0200
From: Denis Pinkas <[e-mail]>
Organization: Bull
X-Mailer: Mozilla 4.06 [fr] (Win95; I)
MIME-Version: 1.0
To: Stefan Santesson <[e-mail]>
CC: [e-mail]
Subject: Re: New proposed solution to the QC biometric issue
References: <[e-mail]>
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 8bit
Content-Transfer-Encoding: 8bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Stefan,

I welcome and support your proposal in general.

> All,
>
> The long debate regarding biometric data in Qualified certificates ended
> with the conclusion:
>
> "For bio-metric data to be included in the QC, the list has to provide an
> agreeable solution that can enhance interoperability in some meaningful
> way. Until then this issue will not be addressed in the profile."
>
> Well, since then I have had a lot of off list discussions ending up in a
> new conclusion:
>
> 1) It could be valuable to include support for biometric data aimed for
> human verification (not machine verification), e.g. human verification of
> picture image or signature image. In fact face recognition and signature
> recognition are regarded as the two major implementations which justify
> this proposed expansion of the draft.

I would propose that we limit our goal, for the time being, to these two
biometric features which seem indeed enough.

> 2) The supported solution should only address storage of a hash value of
> biometric data. This would provide all necessary functionality for
> authenticating bio-data without loading the certificates to much.

Correct.

> 3) Storage of bio-data-hash should NOT be done in the PersonalData field
> since this data is conceptually different from id-attributes. Further,
> since bio-data need storage of 2 parameters (OID + hash), those values
> can't be stored in a single predefined attribute. Instead a new optional
> extension should be defined for this purpose.

I agree.

> Petra Glöckner has prepared a proposal for this new extension in QC as
> follows:

I have several minor concerns with this following ASN1  proposal, but I will
wait a little bit to see other responses before commenting any further.

Thanks again for your efforts for trying to find a consensus,

Regards,

Denis

> Extension ::=  SEQUENCE {
>   extnId              OBJECT IDENTIFIER,
>   critical            BOOLEAN DEFAULT FALSE,
>   extnValue           OCTET STRING }
>
> biometric       EXTENSION ::= {
>   SYNTAX            BiometricSyntax
>   IDENTIFIED BY     id-qext-biometric }
>
> id-qext-biometric    OBJECT IDENTIFIER  ::= {id-qext xx}
>
> BiometricSyntax  ::=  SEQUENCE OF BiometricData
>
> BiometricData   ::=     SEQUENCE {
>   typeOfBiometricData  OBJECT IDENTIFIER
>   biometricDataHash    OCTET STRING }
>
> So with this concrete proposal I would like to reopen the issue for
> comments on this.
> Consequently I will move this issue to the unsettled topics on the QC web (
> http://www.accurata.se/QC/ )
>
> /Stefan
> -------------------------------------------------------------------
> Stefan Santesson                <[e-mail]>
> Accurata Systemsäkerhet AB      http://www.accurata.se
> Slagthuset                      Tel. [phone]
> 211 20  Malmö                   Fax. [phone]
> Sweden                        Mobile [phone]
>
> PGP fingerprint: 89BC 6C79 5B3D 591B 8547  1512 7D11 DBF4 528F 29A0
> -------------------------------------------------------------------



Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id IAA04791 for ietf-pkix-bks; Wed, 14 Apr 1999 08:12:16 -0700 (PDT)
Received: from smtp.udac.net (smtp.udac.net [193.44.79.123]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id IAA04784 for <[e-mail]>; Wed, 14 Apr 1999 08:12:12 -0700 (PDT)
Received: from caesar.udac.se (caesar.udac.se [193.44.79.10]) by smtp.udac.net (8.9.1/8.9.1) with ESMTP id RAA04060 for <[e-mail]>; Wed, 14 Apr 1999 17:12:19 +0200
Received: from HYDRA ([195.198.186.77]) by caesar.udac.se (8.7.3/NetworkC-1) with SMTP id RAA70700; Wed, 14 Apr 1999 17:12:17 +0200
Received: by HYDRA with Microsoft Mail id <01BE8699.F270F580@HYDRA>; Wed, 14 Apr 1999 17:12:16 +0200
Message-ID: <01BE8699.F270F580@HYDRA>
From: Anders Rundgren <[e-mail]>
To: "[e-mail]" <[e-mail]>, "'Stefan Santesson'" <[e-mail]>
Subject: RE: New proposed solution to the QC biometric issue
Date: Wed, 14 Apr 1999 17:12:14 +0200
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 mail.proper.com id IAA04788
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

<snip>

Stefan,

This is a little bit like the DS issue.  Without any specified infrastructure the
inclusion of hashed biometrics in QCs becomes too theoretical.

Being the originator of the request for biometric data in QCs I feel bad about
the idea of hash of biometrics since this is very inconvenient (my guess) compared to
store the real thing in "signed, certified, structured, container" that a certificate
is.  If this is "all we get" you could IMO equally well drop it entirely as all serious
implementers will probably use other measures to achieve the functionality required. 

For an almost complete down-to-earth ASN.1-free solution trying solve today's problems
with current technology, please look into:

http://www.mobilephones-tng.com/papers/idcards.html

This solution is (mainly) intended for use locally in banks, security controls etc. where you want
to know that the bearer of a card is the person it was issued for.  Not exactly rocket-science
(application-wise) but pretty useful anyway.  And unlike current photo-cards impossible to forge.

But I do believe that fully automatic fingerprint verification as a COMPLEMENT to the ID-cert
and PIN-code would work wonders in entrance controls.   To steal both a person's card, PIN-code
AND forge a "finger emulator" seems pretty hard.  Actually there is a much bigger risk associated
with persons you trust which no digital signature, biometric or whatever has a cure for!

The presented solution works fine with current smart-card technology which I also find
important since most QCs will probably be stored in such.

Regards
Anders Rundgren
Senior Internet e-commerce Architect
+46   70 - 627 74 37

PS If you insist on the hash scheme I think that it makes sense to write a simple spec.
on how you meant that it should work as well.   There is a bit more to biometrics than
just ASN.1-code... DS


>Well, since then I have had a lot of off list discussions ending up in a
>new conclusion:

>1) It could be valuable to include support for biometric data aimed for
>human verification (not machine verification), e.g. human verification of
>picture image or signature image. In fact face recognition and signature
>recognition are regarded as the two major implementations which justify
>this proposed expansion of the draft. 

>2) The supported solution should only address storage of a hash value of
>biometric data. This would provide all necessary functionality for
>authenticating bio-data without loading the certificates to much.

>3) Storage of bio-data-hash should NOT be done in the PersonalData field
>since this data is conceptually different from id-attributes. Further,
>since bio-data need storage of 2 parameters (OID + hash), those values
>can't be stored in a single predefined attribute. Instead a new optional
>extension should be defined for this purpose.

>Petra Glöckner has prepared a proposal for this new extension in QC as
>follows:

>Extension ::=  SEQUENCE {
  >extnId              OBJECT IDENTIFIER,
  >critical            BOOLEAN DEFAULT FALSE,
  >extnValue           OCTET STRING }

>biometric 	EXTENSION ::= {
  >SYNTAX            BiometricSyntax
  >IDENTIFIED BY     id-qext-biometric }

>id-qext-biometric    OBJECT IDENTIFIER  ::= {id-qext xx}

>BiometricSyntax  ::=  SEQUENCE OF BiometricData

>BiometricData	::=	SEQUENCE {
  >typeOfBiometricData  OBJECT IDENTIFIER
  >biometricDataHash    OCTET STRING }



>So with this concrete proposal I would like to reopen the issue for
>comments on this.

Thanx!




Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id IAA04650 for ietf-pkix-bks; Wed, 14 Apr 1999 08:02:18 -0700 (PDT)
Received: from THOR.INNOSOFT.COM ([e-mail] [192.160.253.66]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id IAA04645 for <[e-mail]>; Wed, 14 Apr 1999 08:02:17 -0700 (PDT)
Received: from threadgill.austin.innosoft.com ([207.8.108.5]) by INNOSOFT.COM (PMDF V5.2-32 #30494) with ESMTP id <[e-mail]> for [e-mail]; Wed, 14 Apr 1999 08:01:39 PDT
Received: from threadgill.austin.innosoft.com (threadgill.austin.innosoft.com [207.8.108.5]) by austin.innosoft.com (PMDF V5.2-30 #13579) with SMTP id <[e-mail]>; Wed, 14 Apr 1999 10:01:20 -0500 (CDT)
Date: Wed, 14 Apr 1999 10:01:20 -0500
From: Mark Wahl <[e-mail]>
Subject: Re: Double quotes in DNs
In-reply-to: "Your message of Wed, 14 Apr 1999 11:03:13 +0200." <[e-mail]>
To: Martin =?iso-8859-1?Q?Lindstr=F6m?= <[e-mail]>
Cc: [e-mail], [e-mail], [e-mail], [e-mail]
Message-id: <[e-mail]>
MIME-version: 1.0
X-Mailer: exmh version 2.0.2 2/24/98
Content-type: text/plain; charset=us-ascii
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

RFC 2253, which obsoletes RFC 1779, describes in section 2.4 the procedure
by which an ASN.1 attribute value is converted to a string.  You do not need
to have a double quote as part of the _attribute_value_ for your O.  The 
double quote is automatically added by the process of converting an X.500
DN encoding (BER) to an LDAP DN encoding (BNF).  Thesefore the PrintableString 
character set is suitable, just use  

Martin Lindstrom, Creative Computing

as the value.

Mark Wahl, Directory Product Architect
Innosoft International, Inc.



Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id GAA03824 for ietf-pkix-bks; Wed, 14 Apr 1999 06:59:15 -0700 (PDT)
Received: from po1.bbn.com (PO1.BBN.COM [192.1.50.38]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id GAA03820 for <[e-mail]>; Wed, 14 Apr 1999 06:59:14 -0700 (PDT)
Received: from [128.33.238.50] (TC101.BBN.COM [128.33.238.101]) by po1.bbn.com (8.9.1/8.9.1) with ESMTP id JAA13067; Wed, 14 Apr 1999 09:59:20 -0400 (EDT)
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Message-Id: <v04020a05b33a4da98bab@[128.33.238.50]>
In-Reply-To: <D1A949D4508DD1119C8100400533BEDC0E2B5C@DSG1>
Date: Wed, 14 Apr 1999 09:55:35 -0400
To: Alan Lloyd <[e-mail]>
From: Stephen Kent <[e-mail]>
Subject: RE: CA vs. EE cert processing
Cc: "'[e-mail] '" <[e-mail]>
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Alan,

>
>I am also surprised that with the number of X.500 specialists on this
>list that they are not saying that X.509 has errors.
>I think most of think that X.509 is a standard that provides a
>transition strategy to the use of extensions. And RFC 2450 is a profile
>(hence its title) that determines how (repeat HOW) that standard is
>used.
>If the profile reflects an ambiguity (which is deemed by a few) in the
>standard, then the profile document has failed.
>
>Simple isnt it.

Simplie or simplistic :-).

Based on my quite a few years of experience in the IETF community, I'd say
that tone and duration of this message exchange have deterred many people
from joining in.  I have received several private messages expressing
support for the position I have stated, but these, and probably other
folks, don't want to become engaged in a protracted e-mail exchange of this
sort.

I've submitted a defect report to the X.509 editor and the matter will be
addressed at the meeting next week.  I suggest we not waste time on the
list until we hear from the X.509 folks.

steve


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id GAA03526 for ietf-pkix-bks; Wed, 14 Apr 1999 06:32:41 -0700 (PDT)
Received: from po1.bbn.com (PO1.BBN.COM [192.1.50.38]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id GAA03522 for <[e-mail]>; Wed, 14 Apr 1999 06:32:40 -0700 (PDT)
Received: from [128.33.238.50] (TC050.BBN.COM [128.33.238.50]) by po1.bbn.com (8.9.1/8.9.1) with ESMTP id JAA01736; Wed, 14 Apr 1999 09:31:29 -0400 (EDT)
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
X-Sender: [e-mail] (Unverified)
Message-Id: <v04020a03b3397f4ef32b@[128.33.238.70]>
In-Reply-To: <D1A949D4508DD1119C8100400533BEDC0BE97D@DSG1>
Date: Wed, 14 Apr 1999 09:29:06 -0400
To: Alan Lloyd <[e-mail]>
From: Stephen Kent <[e-mail]>
Subject: RE: SEIS:  RE: Certificates, Directories, and Distinguished Names
Cc: [e-mail], [e-mail]
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Alan,

>Stephen - in all your words you never seem to come to grips with the
>fact that X.509 is not ambigious in so far that it permits systems to be
>built without certificate extensions - and for those build such systems
>to determine by local means or imply what is a EE or a CA cert and what
>use that cert has (eg for message verification or cert verification)..
>X.509 - was written some years ago and it correctly (a a standard
>should) provided a transition path to the use of cert extensions.

Vome on Alan, we're talking about changes only with regard to X.509 v3.

>RFC 2459 came along some time later as a profile and just the fact that
>people are discussing the issue in 2459 and it is unclear - means there
>is a problem - in the Profile.

2459 did not come along much later than the adoption of X.509 v3. And, no,
there is not a profile problem, as too many previous messages have show in
detail.


<text not contributing to resolution of the issue deleted ...>

Steve


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id GAA03502 for ietf-pkix-bks; Wed, 14 Apr 1999 06:31:22 -0700 (PDT)
Received: from po1.bbn.com (PO1.BBN.COM [192.1.50.38]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id GAA03498 for <[e-mail]>; Wed, 14 Apr 1999 06:31:19 -0700 (PDT)
Received: from [128.33.238.50] (TC050.BBN.COM [128.33.238.50]) by po1.bbn.com (8.9.1/8.9.1) with ESMTP id JAA01760; Wed, 14 Apr 1999 09:31:35 -0400 (EDT)
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
X-Sender: [e-mail] (Unverified)
Message-Id: <v04020a04b33980a04290@[128.33.238.70]>
In-Reply-To: <[e-mail]>
References: <v04020a18b331b07b2125@[128.33.238.98]> <v04020a0ab332fc3d5915@[128.33.238.98]>
Date: Tue, 13 Apr 1999 19:20:03 -0400
To: Moshe Litvin <[e-mail]>
From: Stephen Kent <[e-mail]>
Subject: Re: CA vs. EE cert processing
Cc: [e-mail]
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Moshe,

>If PKIX mandated inclusion of basicConstraint then PKIX CA would issue
>certificates that are unambiguous to every X.509v3 verifier. The verifier need
>to know that the CA is a PKIX only if the certificate doesn't contain the
>extension. Once the extension is in the certificate the ambiguity disappear.

Yes, all of our certs would be unambiguous, but, as I have said several
times before, the problem would exist for PKIX-compliant verifiers.  So, I
am not pursuing a partial solution.

>PKIX chose to signal EE certificate by the absence of the extension, a way
>that
>require out of band knowledge.
>
>Based on this analyses I call PKIX broken. You can tell that it is X.509
>fault,
>but PKIX failed to fix it, when it could easily make things much better.

But, that would be a wrong conclusion.  remember, what a verifier needs is
an ability to unambiguously identify CA certs, not EE certs, and we did
that. PKIX fixed the problem that X.509 presented in so far as making CA
certs unambiguous.

>Mandating a basicConstraint is not the only way for removing that ambiguity.
>PKIX can mandate inclusion of a keyUsage extension or of a policy OID that
>specify that this is a PKIX certificate. Both of this solutions allows
>processing of the certificate without out of band knowledge, but I think that
>the basicConstraint way is simpler.

Yes, we could trigger on other extensions, but I think that misses the
point, i.e., X.509 needs to be fixed.

Steve


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id GAA03494 for ietf-pkix-bks; Wed, 14 Apr 1999 06:31:13 -0700 (PDT)
Received: from po1.bbn.com (PO1.BBN.COM [192.1.50.38]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id GAA03490 for <[e-mail]>; Wed, 14 Apr 1999 06:31:11 -0700 (PDT)
Received: from [128.33.238.50] (TC050.BBN.COM [128.33.238.50]) by po1.bbn.com (8.9.1/8.9.1) with ESMTP id JAA01702; Wed, 14 Apr 1999 09:31:17 -0400 (EDT)
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
X-Sender: [e-mail] (Unverified)
Message-Id: <v04020a01b33978524f43@[128.33.238.70]>
In-Reply-To: <[e-mail]>
References: <v04020a17b331af2ed303@[128.33.238.98]> <v04020a0bb332fcbd7733@[128.33.238.98]>
Date: Wed, 14 Apr 1999 09:26:12 -0400
To: Moshe Litvin <[e-mail]>
From: Stephen Kent <[e-mail]>
Subject: Re: CA vs. EE cert processing
Cc: [e-mail]
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Moshe,

<snip>

>> I agree that a CA could put the extension in all certs and thus be able to
>> say "not my fault; I did what I could."  But this does not address the
>> verifier problem in other than a heuristic fashion.
>
>Why? If a certificate contain the extension no heuristics are necessary for
>validating this certificate. If a CA put the basicConstraint extension in
>all the
>certificate that it issues than no certificate that the CA issues needs
>heuristics
>to process it.

I think you're veering away from the core problem here.  If we assume a
PKIX-only environment, then we have no ambiguity.  if we assume a mixed
2459 and X.509 environment, then we have ambuguity and a 2459 change cannot
unilaterally fix it.  (By the way, your last sentence should read "then the
certificate verifier ..." not "then the CA ...")

>> I want to
>> deterministic solution to the problem, and the suggested change to 2459
>> does not yield that.
>
>The suggested solution is not complete but it is very deterministic. If it
>will be
>accepted in its strongest form (MUST put basicConstraint in all the
>certificate)
>then no PKIX CA will issue a certificate that needs heuristics by X.509
>verifier
>(be it PKIX, other profile or raw X.509).
>
>A CA can create unambiguous certificates. We should encourage them to do so.

Again, we seem to be loosing track on the context.  Certs issued in
compliance with 2459 are unambiguous, relative to that standard.

<snip>
>
>The verifier has the ambiguity, but the CA can help him solve it. The
>verifier code
>will have some kind of heuristics but they won't be triggered if the CA will
>produce unambiguous certificates.

It can help, but a partial solution is not very satisfying and I am not
persuaded that we should change 2459 to address a problem that can be
solved by a change to another, equally newly issued standard.

<snip>

>>  If we were willing to posit that no such
>> CAs will exist, then we would not have a problem, because in a purely
>> 2459-compliant system (CAs and verifiers) there is not ambiguity.  You seem
>> to be switching perspectives in analyzing this issue.
>
>No my perspective is fixed. I think that a CA should assume as little as
>possible
>of a possible verifier namely:
>
>1. Correct DER decoding
>2. Correct handling of the basic X.509 fields.
>3. Considering a certificate as invalid if it cannot correctly handle a
>critical
>extension.
>
>A CA is not limited to creating certificates that can be validated by the
>minimal
>verifier but it should try to make sure that if the minimal verifier cannot
>correctly validate the certificate it will fail validation.  X.509
>provides the
>mechanism for doing so in the critical flag.
>
>With this model we can compare both options for basicConstraint. We have 3
>types of
>minimal verifiers with respect to the basicConstraint:
>
>A. Verifier that does not understand basicConstraint.
>B. A verifier that understand basicConstraint.
>C. A verifier that is PKIX compliant and knows by out of band means that
>so is the
>CA
>
>We also have 3 types of EE certificate:
>
>i. Without basicConstraint
>ii. With non-critical basicConstraint
>iii. With critical basicConstraint
>
>You can complete the table and see in which combination the verifier can
>identify
>the certificate as EE certificate and where it could have accepted it as a CA
>certificate.

As David pointed out, this analysis focuses on the wrong cert.  The problem
is NOT for EE certs, but for CA certs. We need to determine if a cert is or
is not a CA cert when we encounter it along a path prior to the terminal
cert.


<snip>

>> X.509 failed to solve this problem because it permits compliant CAs to
>> never include basicConstraints, thus creating the ambiguity.  The notes
>> fail to fix the problem, because they just "recommend" what to do.  In the
>> IETF we try to be very careful in our use of the magir words
>> MUST/SHOULD/MAY to avoid these problems.
>>
>
>I think that recommended is a similar to SHOULD, maybe to MAY. I don't
>think that
>it is "SHOULD NOT", but english isn't my mother's tongue.
>
>My question is still open - why PKIX chose to ignore the recommendation and
>invented private semantics?
>
>X.509 offered a standard syntax , if that wasn't enough we could use private
>syntax. But using private semantics is the worse option.

You are criticising PKIX for not following a recommendation of X.509, but
if 2459 had done so, and merely recommended inclusion of the extension in
EE certs, there would still be ambiguity because a compliant implementation
could still choose to not to include the extenstion for EE certs.  2459
fixed part of the ambiguity created in X.509, by mandating the extension in
CA certs, which are the certs that we have to establish are authorized to
be the issuer in subordinate certs.

X.509 created the ambiguity; this fact is not debatable and I do not plan
to spend any more time on arguments of this form.

steve


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id FAA02117 for ietf-pkix-bks; Wed, 14 Apr 1999 05:42:51 -0700 (PDT)
Received: from popmail.inbox.se (popmail.inbox.se [193.12.72.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id FAA02111 for <[e-mail]>; Wed, 14 Apr 1999 05:42:49 -0700 (PDT)
Received: from stefan2 (accurata.inbox.se [193.12.72.24]) by popmail.inbox.se (8.9.3/8.9.3) with SMTP id MAA09715 for <[e-mail]>; Wed, 14 Apr 1999 12:57:36 +0200
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: Windows Eudora Pro Version 3.0 (32)
Date: Wed, 14 Apr 1999 12:57:35 +0200
To: [e-mail]
From: Stefan Santesson <[e-mail]>
Subject: New proposed solution to the QC biometric issue
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 mail.proper.com id FAA02113
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

All,

The long debate regarding biometric data in Qualified certificates ended
with the conclusion:

"For bio-metric data to be included in the QC, the list has to provide an
agreeable solution that can enhance interoperability in some meaningful
way. Until then this issue will not be addressed in the profile."

Well, since then I have had a lot of off list discussions ending up in a
new conclusion:

1) It could be valuable to include support for biometric data aimed for
human verification (not machine verification), e.g. human verification of
picture image or signature image. In fact face recognition and signature
recognition are regarded as the two major implementations which justify
this proposed expansion of the draft. 

2) The supported solution should only address storage of a hash value of
biometric data. This would provide all necessary functionality for
authenticating bio-data without loading the certificates to much.

3) Storage of bio-data-hash should NOT be done in the PersonalData field
since this data is conceptually different from id-attributes. Further,
since bio-data need storage of 2 parameters (OID + hash), those values
can't be stored in a single predefined attribute. Instead a new optional
extension should be defined for this purpose.

Petra Glöckner has prepared a proposal for this new extension in QC as
follows:

Extension ::=  SEQUENCE {
  extnId              OBJECT IDENTIFIER,
  critical            BOOLEAN DEFAULT FALSE,
  extnValue           OCTET STRING }

biometric 	EXTENSION ::= {
  SYNTAX            BiometricSyntax
  IDENTIFIED BY     id-qext-biometric }

id-qext-biometric    OBJECT IDENTIFIER  ::= {id-qext xx}

BiometricSyntax  ::=  SEQUENCE OF BiometricData

BiometricData	::=	SEQUENCE {
  typeOfBiometricData  OBJECT IDENTIFIER
  biometricDataHash    OCTET STRING }



So with this concrete proposal I would like to reopen the issue for
comments on this.
Consequently I will move this issue to the unsettled topics on the QC web (
http://www.accurata.se/QC/ ) 

/Stefan
-------------------------------------------------------------------
Stefan Santesson                <[e-mail]>
Accurata Systemsäkerhet AB      http://www.accurata.se
Slagthuset                      Tel. [phone]              
211 20  Malmö                   Fax. [phone]              
Sweden                        Mobile [phone]

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


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id EAA00142 for ietf-pkix-bks; Wed, 14 Apr 1999 04:00:45 -0700 (PDT)
Received: from dsg1.OpenDirectory.com.au ([203.108.249.145]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id EAA00137 for <[e-mail]>; Wed, 14 Apr 1999 04:00:37 -0700 (PDT)
Received: by DSG1 with Internet Mail Service (5.0.1458.49) id <26MCL9FN>; Wed, 14 Apr 1999 21:00:38 +1000
Message-ID: <D1A949D4508DD1119C8100400533BEDC0E2B5C@DSG1>
From: Alan Lloyd <[e-mail]>
To: "'[e-mail] '" <[e-mail]>, "'Stephen Kent '" <[e-mail]>
Cc: "'[e-mail] '" <[e-mail]>
Subject: RE: CA vs. EE cert processing
Date: Wed, 14 Apr 1999 21:00:37 +1000
X-Priority: 3
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.0.1458.49)
Content-Type: text/plain
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Comments 

Steve wrote:

Itoo  am surprised that there is disagreement, but about the need to
change
X.509, not to change 2459.  PKIX is new, but X.509 for v3 is essentially
just as new.  an argument based on deployed PKIX vs. X.509 v3 compliant
systems does not hold water. I object to the notion that we should
change
2459 to compensate for what strikes me as an oversight in X.509.

Steve

I am also surprised that with the number of X.500 specialists on this
list that they are not saying that X.509 has errors.
I think most of think that X.509 is a standard that provides a
transition strategy to the use of extensions. And RFC 2450 is a profile
(hence its title) that determines how (repeat HOW) that standard is
used.
If the profile reflects an ambiguity (which is deemed by a few) in the
standard, then the profile document has failed.

Simple isnt it.

regards alan 


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id CAA24881 for ietf-pkix-bks; Wed, 14 Apr 1999 02:02:37 -0700 (PDT)
Received: from marcellus.cost.se (marcellus.cost.se [195.100.88.66]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id CAA24877 for <[e-mail]>; Wed, 14 Apr 1999 02:02:33 -0700 (PDT)
Received: from roger ([10.0.0.20]) by marcellus.cost.se (8.9.3/8.9.3) with SMTP id KAA11027; Wed, 14 Apr 1999 10:59:15 +0200 (MET DST)
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: Windows Eudora Pro Version 3.0 (32)
Date: Wed, 14 Apr 1999 11:03:13 +0200
To: [e-mail]
From: Martin =?iso-8859-1?Q?Lindstr=F6m?= <[e-mail]>
Subject: Double quotes in DNs
Cc: [e-mail], [e-mail], [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 mail.proper.com id CAA24878
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

I've got a concrete question about using double quotes '"' as parts
of a distinguished name. Suppose I want my Organization to be:
Martin Lindstrom, Creative Computing. Since the attribute value
contains a ',' character i put the string within quotes (as stated in
RFC1779). O="Martin Lindstrom, Creative Computing".

RFC2459 has a rule (4.1.2.4) of how to choose which ASN.1 string 
to use from the CHOICE structure DirectoryString, and I start trying
to use a PrintableString.
If the double quotes were to be part of the coding I can't use
a PrintableString (since '"' characters are not part of the
PrintableString set according to X.680), but would have to use
a BMPString.
On the other hand, I could remove the double quotes before I
encode the DN and encode the Organization attribute as a PrintableString. 
But this leads to that I have to, when I decode, parse the names in 
the DN to find out if I have to put back any removed double quotes. 
If I didn't put back the double quotes, I would not have a DN 
which is valid according to RFC1779 anymore.

OK, the question would be: "Should double quotes be part of an
encoding or not?".

Regards Martin Lindström

______________________________________
         Entegrity Solutions

  Martin Lindström
  Senior Systems Engineer 

  Finlandsgatan 60 
  S-164 74 Kista, Sweden
  Direct: [phone]
  Fax:    [phone]
  Cell:   [phone]
______________________________________



Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id BAA24802 for ietf-pkix-bks; Wed, 14 Apr 1999 01:58:56 -0700 (PDT)
Received: from nexus.webmatic.de (nexus.webmatic.de [195.206.76.2]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id BAA24798 for <[e-mail]>; Wed, 14 Apr 1999 01:58:55 -0700 (PDT)
Received: from chappi.deh.de (chappi.deh.de [195.206.79.60]) by nexus.webmatic.de (Postfix) with ESMTP id E59194D; Wed, 14 Apr 1999 10:59:16 +0200 (CEST)
Received: from deh.de (juergen.deh.de [195.206.79.54]) by chappi.deh.de (8.9.0/8.9.0) with ESMTP id KAA24457; Wed, 14 Apr 1999 10:59:22 +0200
Message-ID: <[e-mail]>
Date: Wed, 14 Apr 1999 10:59:43 +0200
From: Juergen Walter <[e-mail]>
Reply-To: [e-mail]
Organization: DEH information systems GmbH
X-Mailer: Mozilla 4.51 [en] (WinNT; U)
X-Accept-Language: en
MIME-Version: 1.0
To: "Jim Schaad (Exchange)" <[e-mail]>, Carlisle Adams <[e-mail]>, "IETF-PKIX (E-mail)" <[e-mail]>
Subject: Re: New CMC Draft available - Confirmation Message
References: <2FBF98FC7852CF11912A0000000000010ECB5E54@DINO>
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 8bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Carlisle, Jim

Comments in line.

"Jim Schaad (Exchange)" wrote:
> 
> Juergen,
> 
> The problem that I have with this approach is that there is no way of
> knowing what the delay is going to be on the acceptance showing up on at the
> CA.  (Nor do all transport mechinisms guantee delivery.)  Thus a client can
> think it did accept a certificate and the CA can reach an opposite
> conclusion.  If the client asks for revocation, it can later check to make
> sure that this operation occured.

As Carlisle mentioned I prefer to publish the certificate in a
repository (database, directory, OCSP server) after the client had
explicitly confirmed when required. Whether the repository is public or
intended for a closed user group it doesn´t matter, at least the client
itself should have access to its own certificate (status information).
In PKIs there no repository exists one may use the certification
announcement message for that purpose. In both cases the client may
check its confirmation.

I agree with Jim that a rejected certificate has to be revoked even if
has not been published yet when it was sent to the client. The
revocation request message is sufficiently, when we consider PKIs where
no confirmation message is required. But if this explicite confirmation
is required, no message format is available in the current CMP draft.
The first application of the issued certificate e. g. in a signned
S/MIME message may indicate clients confirmation why the certificate is
enclosed in the S/MIME message. Is this an explicite confirmation? I am
not sure.

Alternatively, the client may send its certificate to a repository. If
the repository is triggered by clients "publication request" then it may
be an explicite confirmation. Have we specified or planned an
appropriate message yet? The current publication info is contained in
the certification request before the certificate is issued, isn´t it? 

I would like to propose that the confirmation message in CMP should be
replaced by a message that allows the client to confirm explicitly or to
reject its certificate if appropriate. I believe that the current
protocol design of CMP:
1: initial request: EE -> CA
2: initial response: CA -> EE
3: confirmation: EE -> CA when confirmed,
3´: revocation request: CA -> EE when rejected
...
may be improved by the proposed new message.   

Last but not least. Have we already specified an appropriate revocation
reason that may occur after certificate issuing when the revocation
request is applied?

Juergen

[snip]


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id AAA21521 for ietf-pkix-bks; Wed, 14 Apr 1999 00:03:34 -0700 (PDT)
Received: from clbull.frcl.bull.fr (clbull.frcl.bull.fr [129.182.1.20]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id AAA21513 for <[e-mail]>; Wed, 14 Apr 1999 00:03:24 -0700 (PDT)
Received: from k2.frcl.bull.fr (k2.frcl.bull.fr [129.182.100.2]) by clbull.frcl.bull.fr (8.9.1a/8.9.1) with ESMTP id JAA20142 for <[e-mail]>; Wed, 14 Apr 1999 09:03:43 +0200
Received: from bull.net (frcls6118.frcl.bull.fr [129.182.109.213]) by k2.frcl.bull.fr (AIX4.2/UCB 8.7/8.7) with ESMTP id JAA30028 for <[e-mail]>; Wed, 14 Apr 1999 09:03:37 +0200 (DFT)
Message-ID: <[e-mail]>
Date: Wed, 14 Apr 1999 09:04:03 +0200
From: Denis Pinkas <[e-mail]>
Organization: Bull
X-Mailer: Mozilla 4.06 [fr] (Win95; I)
MIME-Version: 1.0
To: [e-mail]
Subject: Re: Time-Stamp: Why not use several hashes?
References: <01E1D01C12D7D211AFC70090273D20B112BDBE@sothmxs06>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

> I think that if a common hash function is broken (for example SHA-1) then no
> signature created within that infrastructure, with that hash function can be
> trusted, including the TSA's.

I concur with Robert.

> Thus, I am reluctant to include multiple
> hashes within the message imprint.

Me too.

Regards,

Denis


> It will not actually help if the hash
> algorithm used to sign the token is broken.  Also, as I stated earlier, if
> certain individuals really want to do this, they can do it by defining a new
> OID.
>
> > ----------
> > From:         Jose A. Manas[SMTP:[e-mail]]
> > Sent:         Monday, April 12, 1999 4:24 AM
> > To:   Denis Pinkas
> > Cc:   Manuel Heras Gilsanz; [e-mail]; [e-mail]
> > Subject:      Re: Time-Stamp: Why not use several hashes?
> >
> > Denis,
> > I feel uneasy with both arguments.
> >
> > If a guy finds out how to provoke collisions on a hash functions,
> > there is a serious temptation to exploit the hole before
> > publishing it. Breaking a time-stamp infrastructure is a nice
> > goal: you break it before anybody knows it can be broken,
> > and then there is a difficult question about when the TSA was
> > no longer to be trusted.
> >
> > I have some concern as well with respect to breaking a digital
> > signature. If broken but time-stamped,
> > a TSA can still prove that it was signed
> > before it was breakable. But if you break the TSA itself, then
> > there is no help. That about breaking the hash.
> >
> > Still, if you break the TSA signature, you have audit records
> > (stored evidence in the TSA) to help you (as far as there are
> > no collisions in the hash).
> >
> > Alltogether, I aim to say that breaking a hash does break down
> > everything, and it sounds interesting to foresee the case.
> > Allowing for several messageimprints sounds as a cheap end
> > effective countermeasure.
> >
> > pp
> >
> > Denis Pinkas wrote:
> > >
> > > Manuel,
> > >
> > > We want to keep the protocol simple. The threat you mention can be
> > countered
> > > by another way: re-time-stamp later on with a new hash function. If
> > SHA-1
> > > gets broken one day, this will not happen in just one day. Some
> > > cryptographer will first find some weaknesses before you can really
> > forge a
> > > meaningfull message that has the same hash. So you get some time for
> > > re-stamping.
> > >
> > > If this argument were used, then we should sign TWICE, i.e.  in case one
> > > digital signature algorithm was broken. We do not do that. There is no
> > > reason to do it for the hash function.
> > >
> > > Regards,
> > >
> > > Denis
> > >
> > > > Hi.
> > > >
> > > > In the (now expired) latest PKIX draft on time-stamping protocols from
> > > > Sept. 23, 1998, time-stamp requests and tokens support the insertion
> > of
> > > > a single message imprint.
> > > >
> > > > I think several message imprints should be supported. If a hash
> > > > algorithm were broken, time-stamp tokens using it (as the single
> > message
> > > > imprint) would have to be regarded invalid (even if some kind of
> > linking
> > > > mechanism were implemented!). If several hashes had been used, the
> > token
> > > > would still be valid, and it could be promptly renewed in order to
> > > > prevent invalidation should further advances in cryptography render
> > > > other hashes obsolete!
> > > >
> > > > (One must be careful here: there are different extents to which a hash
> > > > algorithm could be broken; in Appendix A of  PKITS-D3
> > > > [http://www.fnmt.es/pkits] there is an interesting analysis of the
> > > > implications that the different kinds of hash failures would have on
> > the
> > > > time-stamping process.)
> > > >
> > > > Of course the requirements on the time-stamp verification process
> > would
> > > > also have be modified to require ("MUST" level) *all* the hashes to
> > > > correctly verify in order to regard the corresponding time-stamp token
> > > > valid.
> > > >
> > > > Best regards,
> > > >
> > > >     - Manuel -
> > > >
> > > > ----
> > > > Manuel Heras-Gilsanz ([e-mail])
> > > > Independent Security Consultant
> > > > Phone: [phone]
> >
> > -- --------------------------------------------------------
> > Prof. Jose A. Manas                     <[e-mail]>
> > Dpt. Telematica                http://www.dit.upm.es/~pepe
> > E.T.S.I. Telecomunicacion           tel: [+34] 91 336 73 25
> > Ciudad Universitaria                gsm: [+34] 607 73 38 94
> > E-28040 Madrid, SPAIN               fax: [+34] 91 336 73 33
> >



Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id NAA25129 for ietf-pkix-bks; Tue, 13 Apr 1999 13:52:15 -0700 (PDT)
Received: from po1.bbn.com (PO1.BBN.COM [192.1.50.38]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id NAA25125 for <[e-mail]>; Tue, 13 Apr 1999 13:52:14 -0700 (PDT)
Received: from [128.33.238.70] (TC070.BBN.COM [128.33.238.70]) by po1.bbn.com (8.9.1/8.9.1) with ESMTP id QAA16117; Tue, 13 Apr 1999 16:52:26 -0400 (EDT)
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Message-Id: <v04020a10b3394883ec69@[128.33.238.189]>
In-Reply-To: <[e-mail]>
Date: Tue, 13 Apr 1999 16:51:18 -0400
To: [e-mail]
From: Stephen Kent <[e-mail]>
Subject: Re: CA vs. EE cert processing
Cc: [e-mail]
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

John,

<snip>

>>I agree that a CA could put the extension in all certs and thus be able to
>>say "not my fault; I did what I could."  But this does not address the
>>verifier problem in other than a heuristic fashion.  I want to
>>deterministic solution to the problem, and the suggested change to 2459
>>does not yield that.
>
>It's purely deterministic.  If PKIX mandated the presence of the
>basicConstraints extension, then a verifier could, without any
>outside knowledge, immediately categorize a certificate as
>"CA cert", "EE cert" or "Unknown (and not PKIX-compliant)".  For
>certificates that fall into one of the first two categories,
>the certificate would be processed accordingly; for a
>certificate in the "unknown" category, the verifier gets to
>chose whether to consider the cert as an EE or CA cert, possibly
>based on out-of-band information, but may also chose to reject
>it (if it is only interested in talking with PKIX-compliant
>systems).

we define determinism differently.  the "else" at the end of your decision
tree is still where the problem arises.

>If PKIX doesn't mandate the presence of the basicConstraints extension,
>then a verifier can't distinguish between a PKIX-complaint EE cert and
>a non-PKIX compliant CA cert that has chosen not to use the extension.

or an X.509 compliant CA that has chosen not to innclue the extension; we
can't fix CAs that are non-compliant witgh both PKIX and X.509, and so I
don't worry about them in analyzing these problems; but it is X.509 that
creates the problem, all by itself, in the realm of compliant CAs.

>
>Assuming that we file a DR against X.509, then as I see it the X.509
>committee has several choices:
>
>i)  Decide that X.509 is fine as-is, and make no change.
>
>ii) Add clarifying text that defines that certificates without a
>    basicConstraints extension should be considered to be EE certs.
>
>iii) Mandate that EE certs omit the basicConstraints extension and that
>     it is present and critical in CA certs.
>
>iv) Mandate that the basicContraints extension be present in all certs.
>
>
>
>If they pick (i), then changing PKIX to require the extension is the
>only way to generate certs that are unambiguous to a verifier.
>Reducing the impact of the ambiguity is progress, even if it can't
>be eliminated altogether, and at least PKIX-compliant certificates
>won't trigger it.

yes, it would be progress, but it is not a desirable end state.

>If they pick (ii), then PKIX would be fine whether or not we required
>basicConstraints in EE certs, and the ambiguity would slowly vanish as
>systems that generate un-extended CA certs come into compliance with
>X.509.  However, even V1 certs haven't yet vanished from the world,
>so I imagine this process is likely to take a long time, so having all
>PKIX certs contain the extension is still a win as it eliminates the
>ambiguity immediately.

yes, but our focus in PKIX is on v3 certs, as discussed before, and nothing
we can do in 2459 will fix that legacy problem.

>If they pick (iii), the current PKIX spec will be fine (once newly
>non-complaint X.509 certs vanish from the world), and a PKIX spec
>that mandated the use of basicConstraints in EE certs would be
>non-compliant.  However, this would be a non-backwards-compatible
>change to X.509, and so if this option were taken, then it would
>probably require an accompanying change to the certificate version
>number.  For this reason alone, I think this option is unlikely to
>be chosen.  A half-way position would be to recommend that EE certs
>omit the extension, but to permit verifiers to accept EE certs with
>the extension set.  In this case, either flavor of PKIX would be
>fine, although having all PKIX certs contain the extension is still
>a win as it eliminates the ambiguity immediately.

OK, let's igine this one.

>If they pick (iv), then the current PKIX profile will be non-compliant,
>and PKIX will continue to generate certificates that X.509 deems to
>be ambiguous.  The proposed change to PKIX would generate certificates
>that are compliant with both current X.509 and the new X.509.
>
yes.

>
>It seems that in all cases, having PKIX generate certificates
>that are unambiguous under today's X.509 is worthwhile.
>
we don't reach the same conclusion, probably because "worthwhile" is
subjective and we've already determined that we have different values wrt
this debate.

>I must say, I'm suprised that there is disagreement over this, since
>writing a profile to avoid ambiguous areas of its parent spec seems
>so fundamental that I must be missing something.  The only down-side
>I can see to requiring the extension in all certs is that it costs
>a few extra bytes.  There's no significant number of deployed PKIX
>systems, so compatibility isn't a major issue (and the proposed
>change wouldn't break compatibility anyway, as verifiers would
>still have the option of treating non-extended certs as EE certs).

Itoo  am surprised that there is disagreement, but about the need to change
X.509, not to change 2459.  PKIX is new, but X.509 for v3 is essentially
just as new.  an argument based on deployed PKIX vs. X.509 v3 compliant
systems does not hold water. I object to the notion that we should change
2459 to compensate for what strikes me as an oversight in X.509.

Steve


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id NAA25017 for ietf-pkix-bks; Tue, 13 Apr 1999 13:49:06 -0700 (PDT)
Received: from gatekeeper.entrust.com (gatekeeper.entrust.com [204.101.128.170]) by mail.proper.com (8.8.8/8.8.5) with SMTP id NAA25011 for <[e-mail]>; Tue, 13 Apr 1999 13:49:04 -0700 (PDT)
Received: 	id QAC12699; Tue, 13 Apr 1999 16:29:34 -0400
Received: by gateway id <269J4MKJ>; Tue, 13 Apr 1999 16:31:36 -0400
Message-ID: <01E1D01C12D7D211AFC70090273D20B104F067@sothmxs06>
From: Carlisle Adams <[e-mail]>
To: "'[e-mail]'" <[e-mail]>, "'Jim Schaad (Exchange)'" <[e-mail]>
Cc: "IETF-PKIX (E-mail)" <[e-mail]>
Subject: RE: New CMC Draft available - Confirmation Message
Date: Tue, 13 Apr 1999 15:58:23 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.1960.3)
Content-Type: text/plain
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Hi Jim,

> ----------
> From: 	Jim Schaad (Exchange)[SMTP:[e-mail]]
> Sent: 	Tuesday, April 13, 1999 3:01 PM
> To: 	'[e-mail]'; IETF-PKIX (E-mail)
> Subject: 	RE: New CMC Draft available - Confirmation Message
> 
> Juergen,
> 
> The problem that I have with this approach is that there is no way of
> knowing what the delay is going to be on the acceptance showing up on at
> the
> CA.  (Nor do all transport mechinisms guantee delivery.)  Thus a client
> can
> think it did accept a certificate and the CA can reach an opposite
> conclusion.  If the client asks for revocation, it can later check to make
> sure that this operation occured.
 
Note that if client acceptance is the trigger for CA publication of the
certificate, it is still the case that the client can later check to make
sure that its confirmation message was received (i.e., by looking wherever
certs get posted).

Uncertainties on the client end notwithstanding, Juergen makes a good point
(which I forgot to mention in my previous posting on CMC comments):  some
environments require the CA to receive an explicit acceptance from the
client in order to treat the certificate as "ready for use" and to issue it
publicly.  (This may be for legal, liability, or other reasons.)  A
confirmation message is a useful way to satisfy that requirement within the
protocol.

Carlisle.



Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id MAA21311 for ietf-pkix-bks; Tue, 13 Apr 1999 12:18:31 -0700 (PDT)
Received: from doggate.exchange.microsoft.com (doggate.exchange.microsoft.com [131.107.88.55]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id MAA21307 for <[e-mail]>; Tue, 13 Apr 1999 12:18:30 -0700 (PDT)
Received: by doggate.exchange.microsoft.com with Internet Mail Service (5.5.2232.9) id <2TW7ZPVV>; Tue, 13 Apr 1999 12:18:15 -0700
Message-ID: <2FBF98FC7852CF11912A0000000000010ECB5E54@DINO>
From: "Jim Schaad (Exchange)" <[e-mail]>
To: "'[e-mail]'" <[e-mail]>, "IETF-PKIX (E-mail)" <[e-mail]>
Subject: RE: New CMC Draft available - Confirmation Message
Date: Tue, 13 Apr 1999 12:01:31 -0700
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2232.9)
Content-Type: text/plain; charset="windows-1252"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Juergen,

The problem that I have with this approach is that there is no way of
knowing what the delay is going to be on the acceptance showing up on at the
CA.  (Nor do all transport mechinisms guantee delivery.)  Thus a client can
think it did accept a certificate and the CA can reach an opposite
conclusion.  If the client asks for revocation, it can later check to make
sure that this operation occured.

jim


-----Original Message-----
From: Juergen Walter [mailto:[e-mail]]
Sent: Tuesday, April 13, 1999 1:32 AM
To: Jim Schaad (Exchange); IETF-PKIX (E-mail)
Subject: Re: New CMC Draft available - Confirmation Message


Jim,

[snip]


> 
> > - there is no confirmation message from the client to the
> > CA/RA (thus, there
> > is no way for a client to reject a certificate that it does
> > not want (e.g.,
> > in the case where the CA has modified some of the fields in
> > the request)).
> 
> There is a simple way for a client to reject a certificate, it simply puts
> in a revocation request on the certificates it just received.  I don't
know
> of any reason for the oppositite to be required in a general protocal.
That
> is the client must positively accept a certificate.
> 

When I remember right e. g. ABA Guidelines requires that an EE
explicitly confirms an issued certificate. This may be not a protocol
requirement in pure PKI implementations. But I know environments where a
certificate receipt is at least an operational requirement. I think that
an appropriate message (optional) would be an improvement. When the
rejection (i. e. sending of revocation request) stays away we have no
explicite confirmation of the certificate (may be a legal issue). The
time-frame of such stay away process may cause complicated validation
issues. I prefer a message that indicates the fact whether an EE accept
his certificate or not. This may replace the revocation request on the
one hand and the pure revocation request on the other hand. 

 

Juergen


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id KAA18240 for ietf-pkix-bks; Tue, 13 Apr 1999 10:43:21 -0700 (PDT)
Received: from gatekeeper.entrust.com (gatekeeper.entrust.com [204.101.128.170]) by mail.proper.com (8.8.8/8.8.5) with SMTP id KAA18232 for <[e-mail]>; Tue, 13 Apr 1999 10:43:12 -0700 (PDT)
Received: 	id NAA20412; Tue, 13 Apr 1999 13:34:58 -0400
Received: by gateway id <G4CA5SWQ>; Tue, 13 Apr 1999 13:37:19 -0400
Message-ID: <01E1D01C12D7D211AFC70090273D20B112BDBE@sothmxs06>
From: Robert Zuccherato <[e-mail]>
To: Denis Pinkas <[e-mail]>, "'Jose A. Manas'" <[e-mail]>
Cc: Manuel Heras Gilsanz <[e-mail]>, [e-mail], [e-mail]
Subject: RE: Time-Stamp: Why not use several hashes?
Date: Tue, 13 Apr 1999 13:30:55 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.1960.3)
Content-Type: text/plain; charset="iso-8859-1"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

I think that if a common hash function is broken (for example SHA-1) then no
signature created within that infrastructure, with that hash function can be
trusted, including the TSA's.  Thus, I am reluctant to include multiple
hashes within the message imprint.  It will not actually help if the hash
algorithm used to sign the token is broken.  Also, as I stated earlier, if
certain individuals really want to do this, they can do it by defining a new
OID.

> ----------
> From: 	Jose A. Manas[SMTP:[e-mail]]
> Sent: 	Monday, April 12, 1999 4:24 AM
> To: 	Denis Pinkas
> Cc: 	Manuel Heras Gilsanz; [e-mail]; [e-mail]
> Subject: 	Re: Time-Stamp: Why not use several hashes?
> 
> Denis,
> I feel uneasy with both arguments.
> 
> If a guy finds out how to provoke collisions on a hash functions,
> there is a serious temptation to exploit the hole before
> publishing it. Breaking a time-stamp infrastructure is a nice
> goal: you break it before anybody knows it can be broken,
> and then there is a difficult question about when the TSA was
> no longer to be trusted.
> 
> I have some concern as well with respect to breaking a digital
> signature. If broken but time-stamped, 
> a TSA can still prove that it was signed
> before it was breakable. But if you break the TSA itself, then
> there is no help. That about breaking the hash.
> 
> Still, if you break the TSA signature, you have audit records
> (stored evidence in the TSA) to help you (as far as there are
> no collisions in the hash).
> 
> Alltogether, I aim to say that breaking a hash does break down
> everything, and it sounds interesting to foresee the case.
> Allowing for several messageimprints sounds as a cheap end
> effective countermeasure.
> 
> pp
> 
> Denis Pinkas wrote:
> > 
> > Manuel,
> > 
> > We want to keep the protocol simple. The threat you mention can be
> countered
> > by another way: re-time-stamp later on with a new hash function. If
> SHA-1
> > gets broken one day, this will not happen in just one day. Some
> > cryptographer will first find some weaknesses before you can really
> forge a
> > meaningfull message that has the same hash. So you get some time for
> > re-stamping.
> > 
> > If this argument were used, then we should sign TWICE, i.e.  in case one
> > digital signature algorithm was broken. We do not do that. There is no
> > reason to do it for the hash function.
> > 
> > Regards,
> > 
> > Denis
> > 
> > > Hi.
> > >
> > > In the (now expired) latest PKIX draft on time-stamping protocols from
> > > Sept. 23, 1998, time-stamp requests and tokens support the insertion
> of
> > > a single message imprint.
> > >
> > > I think several message imprints should be supported. If a hash
> > > algorithm were broken, time-stamp tokens using it (as the single
> message
> > > imprint) would have to be regarded invalid (even if some kind of
> linking
> > > mechanism were implemented!). If several hashes had been used, the
> token
> > > would still be valid, and it could be promptly renewed in order to
> > > prevent invalidation should further advances in cryptography render
> > > other hashes obsolete!
> > >
> > > (One must be careful here: there are different extents to which a hash
> > > algorithm could be broken; in Appendix A of  PKITS-D3
> > > [http://www.fnmt.es/pkits] there is an interesting analysis of the
> > > implications that the different kinds of hash failures would have on
> the
> > > time-stamping process.)
> > >
> > > Of course the requirements on the time-stamp verification process
> would
> > > also have be modified to require ("MUST" level) *all* the hashes to
> > > correctly verify in order to regard the corresponding time-stamp token
> > > valid.
> > >
> > > Best regards,
> > >
> > >     - Manuel -
> > >
> > > ----
> > > Manuel Heras-Gilsanz ([e-mail])
> > > Independent Security Consultant
> > > Phone: [phone]
> 
> -- --------------------------------------------------------
> Prof. Jose A. Manas                     <[e-mail]>
> Dpt. Telematica                 http://www.dit.upm.es/~pepe
> E.T.S.I. Telecomunicacion           tel: [+34] 91 336 73 25
> Ciudad Universitaria                gsm: [+34] 607 73 38 94
> E-28040 Madrid, SPAIN               fax: [+34] 91 336 73 33
> 


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id BAA27745 for ietf-pkix-bks; Tue, 13 Apr 1999 01:31:41 -0700 (PDT)
Received: from nexus.webmatic.de (nexus.webmatic.de [195.206.76.2]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id BAA27737 for <[e-mail]>; Tue, 13 Apr 1999 01:31:39 -0700 (PDT)
Received: from chappi.deh.de (chappi.deh.de [195.206.79.60]) by nexus.webmatic.de (Postfix) with ESMTP id 5CD7E4D; Tue, 13 Apr 1999 10:31:56 +0200 (CEST)
Received: from deh.de (juergen.deh.de [195.206.79.54]) by chappi.deh.de (8.9.0/8.9.0) with ESMTP id KAA19442; Tue, 13 Apr 1999 10:32:01 +0200
Message-ID: <[e-mail]>
Date: Tue, 13 Apr 1999 10:32:21 +0200
From: Juergen Walter <[e-mail]>
Reply-To: [e-mail]
Organization: DEH information systems GmbH
X-Mailer: Mozilla 4.51 [en] (WinNT; U)
X-Accept-Language: en
MIME-Version: 1.0
To: "Jim Schaad (Exchange)" <[e-mail]>, "IETF-PKIX (E-mail)" <[e-mail]>
Subject: Re: New CMC Draft available - Confirmation Message
References: <2FBF98FC7852CF11912A0000000000010ECB5E49@DINO>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Jim,

[snip]


> 
> > - there is no confirmation message from the client to the
> > CA/RA (thus, there
> > is no way for a client to reject a certificate that it does
> > not want (e.g.,
> > in the case where the CA has modified some of the fields in
> > the request)).
> 
> There is a simple way for a client to reject a certificate, it simply puts
> in a revocation request on the certificates it just received.  I don't know
> of any reason for the oppositite to be required in a general protocal.  That
> is the client must positively accept a certificate.
> 

When I remember right e. g. ABA Guidelines requires that an EE
explicitly confirms an issued certificate. This may be not a protocol
requirement in pure PKI implementations. But I know environments where a
certificate receipt is at least an operational requirement. I think that
an appropriate message (optional) would be an improvement. When the
rejection (i. e. sending of revocation request) stays away we have no
explicite confirmation of the certificate (may be a legal issue). The
time-frame of such stay away process may cause complicated validation
issues. I prefer a message that indicates the fact whether an EE accept
his certificate or not. This may replace the revocation request on the
one hand and the pure revocation request on the other hand. 

 

Juergen


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id UAA06034 for ietf-pkix-bks; Mon, 12 Apr 1999 20:08:27 -0700 (PDT)
Received: from www.eci.com.cn ([159.226.41.14]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id UAA06030 for <[e-mail]>; Mon, 12 Apr 1999 20:08:23 -0700 (PDT)
Received: from eci.com.cn ([10.226.41.80]) by www.eci.com.cn (Netscape Messaging Server 3.5)  with ESMTP id 296 for <[e-mail]>; Tue, 13 Apr 1999 11:07:16 +0100
Message-ID: <[e-mail]>
Date: Tue, 13 Apr 1999 11:08:22 +0800
From: "gang cao" <[e-mail]>
X-Mailer: Mozilla 4.06 [en] (Win98; I)
MIME-Version: 1.0
To: [e-mail]
Subject: cross-certify?
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

hi,
    I  want to know something about cross-certify.
I read  some RFC and draft ,but found few about
this.who could tell me some information about
cross-certify and where can i find paper about
cross-certify?
    thanks for help.



Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id SAA24173 for ietf-pkix-bks; Mon, 12 Apr 1999 18:59:00 -0700 (PDT)
Received: from mail.rdc1.md.home.com ([e-mail] [24.2.2.66]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id SAA24169 for <[e-mail]>; Mon, 12 Apr 1999 18:58:58 -0700 (PDT)
Received: from home.com ([24.4.133.54]) by mail.rdc1.md.home.com (InterMail v4.00.03 201-229-104) with ESMTP id <[e-mail]> for <[e-mail]>; Mon, 12 Apr 1999 18:59:12 -0700
Message-ID: <[e-mail]>
Date: Mon, 12 Apr 1999 21:56:38 -0400
From: Alfred Arsenault <[e-mail]>
Organization: @Home Network
X-Mailer: Mozilla 4.5 [en]C-AtHome0405  (Win95; U)
X-Accept-Language: en
MIME-Version: 1.0
To: [e-mail]
Subject: Changes to RFC 2459
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Folks,

	As long as we're talking about changes that can be made to RFC 2459
when it progresses to Draft Standard, I'd like to throw out this
suggestion:

	can section 6 be reworded to be consistent in the use of the term "root
CA" with the rest of the PKIX documents?  For example, in the following
paragraph:

	The "most-trusted CA" is a matter of policy: it could be a root 	CA in
a hierarchical PKI; the CA that issued the verifier's own
   	certificate(s); or any other CA in a network PKI.  The path
   	validation procedure is the same regardless of the choice of 	
"most-trusted CA."

	If "most-trusted CA" is replaced with "root CA"; and root CA is
replaced with some other term (like "top CA" or something), then we
could get rid of a paragraph in the Roadmap that I really don't like.

		Al Arsenault


  - my views are my own, and do not necessarily represent those of my
employer or of any other organization with which I might have a
relationship.


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id RAA23529 for ietf-pkix-bks; Mon, 12 Apr 1999 17:57:14 -0700 (PDT)
Received: from ns.cmbchina.com ([202.96.161.112]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id RAA23523 for <[e-mail]>; Mon, 12 Apr 1999 17:57:09 -0700 (PDT)
Received: from cmbchina.com ([10.1.4.27]) by ns.cmbchina.com (Netscape Messaging Server 3.01)  with ESMTP id AAA25622; Tue, 13 Apr 1999 08:55:59 -0800
Message-ID: <[e-mail]>
Date: Tue, 13 Apr 1999 08:57:22 +0800
From: "Xiong Shao Jun" <[e-mail]>
Organization: China Merchants Bank
X-Mailer: Mozilla 4.04 [en] (Win95; I)
MIME-Version: 1.0
To: Carlisle Adams <[e-mail]>, Russ Housley <[e-mail]>
CC: [e-mail]
Subject: Re: About Diffie-Hellman algorithm and Shamir threshold
References: <01E1D01C12D7D211AFC70090273D20B104F05F@sothmxs06>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Russ, Carlisle, thank you very much. How about Shamir threshold secret sharing,
the OID,
the parameter representation?

Thanks again,
Xiong Shaojun

Carlisle Adams wrote:

> Hi,
>
> Russ is right.  When we were putting in the final edits to turn the Internet
> Draft into an RFC, I remembered to update the OID to the correct value, but
> forgot to update "DHParameter" to "DomainParameters".
>
> RFC 2459 has the proper parameter to correspond to the OID.  RFC 2510 will
> need to be updated whenever the opportunity arises.  Thank you for catching
> this!
>
> Some day all the PKIX documents will be perfect...  :-)
>
> Carlisle.
>
> > ----------
> > From:         Russ Housley[SMTP:[e-mail]]
> > Sent:         Monday, April 12, 1999 10:05 AM
> > To:   Xiong Shao Jun
> > Cc:   [e-mail]
> > Subject:      Re: About Diffie-Hellman algorithm and Shamir threshold
> >
> > Xiong Shao Jun:
> >
> > The definition in RFC 2459 is aligned with the Draft ANSI X9.42
> > specification and the Draft IEEE P1363 speciification.
> >
> > I think that you uncovered a bug in RFC 2510.
> >
> > Russ
> >
> >
> > At 01:17 PM 4/11/99 +0800, Xiong Shao Jun wrote:
> > >Hi, I have two problems. The first is about Diffie-Hellman algorithm. In
> > >PKIX part1, now
> > >rfc2459, the algorithm is described as:
> > >
> > >OID:    1.2.840.10046.2.1
> > >DomainParameters ::= SEQUENCE {
> > >        p            INTEGER, -- odd prime, p=jq+1
> > >        g            INTEGER, -- generator, g
> > >        q            INTEGER, -- factor of p-1
> > >        j            INTEGER OPTIONAL, -- subgroup factor
> > >        validationParms    ValidationParms OPTIONAL }
> > >
> > >ValidationParms    ::= SEQUENCE {
> > >        seed            BIT STRING
> > >    pgenCounter   INTEGER }
> > >
> > >while in certificate management protocol, now rfc2510, the algorithms is
> > >described as
> > >below:
> > >OID:    1.2.840.10046.2.1
> > >DHParameter ::= SEQUENCE {
> > >        prime INTEGER, -- p
> > >        base  INTEGER  -- g
> > >}
> > >
> > >So which is the most up to date description, and which should I
> > >implement?
> > >
> >





Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id PAA22129 for ietf-pkix-bks; Mon, 12 Apr 1999 15:28:20 -0700 (PDT)
Received: from prv-mail20.provo.novell.com (prv-mail20.Provo.Novell.COM [137.65.40.4]) by mail.proper.com (8.8.8/8.8.5) with SMTP id PAA22125 for <[e-mail]>; Mon, 12 Apr 1999 15:28:19 -0700 (PDT)
Received: from INET-PRV-Message_Server by prv-mail20.provo.novell.com with Novell_GroupWise; Mon, 12 Apr 1999 16:27:53 -0600
Message-Id: <[e-mail]>
X-Mailer: Novell GroupWise 5.5
Date: Mon, 12 Apr 1999 16:27:46 -0600
From: "Tolga Acar" <[e-mail]>
To: <[e-mail]>
Subject: Diffie-Hellman DomainParameters
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 mail.proper.com id PAA22126
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

In RFC 2459, Section 7.3.2, two components of the DomainParameters are defined as:

"g specifies the generator of the multiplicative subgroup of order g"
"q specifies the prime factor of p-1"

The order of the subgroup is the order of g, g is not the order; g is the multiplicative subgroup generator. The order of g is q, which is a large prime factor of p-1.

I think the definitions would be correct and more clear if defined as:

"g specifies the generator of the multiplicative subgroup of order q".
"q specifies the prime factor of p-1, and the order of g in GF(p)".

- Tolga



Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id PAA21972 for ietf-pkix-bks; Mon, 12 Apr 1999 15:11:05 -0700 (PDT)
Received: from trustpoint.com ([e-mail] [216.100.231.61]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id PAA21967 for <[e-mail]>; Mon, 12 Apr 1999 15:11:04 -0700 (PDT)
Received: from mobile (mobile [192.168.42.7]) by trustpoint.com (8.8.7/8.8.7) with SMTP id PAA19701 for <[e-mail]>; Mon, 12 Apr 1999 15:11:17 -0700
From: "Amit Kapoor" <[e-mail]>
To: "PKIX" <[e-mail]>
Subject: PKIX CMP: Transaction Identifier in use
Date: Mon, 12 Apr 1999 15:05:54 -0700
Message-ID: <000e01be8530$a256e240$[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.2173.0
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V4.72.2106.4
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

	According to the CMP spec. (RFC2510) the CA
	is supposed to reject the initialization
	request (B8) if the transaction identifier
	is in use.  Should there not be a
	bit in failure information in the error message
	indicating the same so the client programs
	can automatically recover and send the same 
	request with a  different identifier?

	Thanks.

Amit


	


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id PAA21959 for ietf-pkix-bks; Mon, 12 Apr 1999 15:10:20 -0700 (PDT)
Received: from gatekeeper.entrust.com (gatekeeper.entrust.com [204.101.128.170]) by mail.proper.com (8.8.8/8.8.5) with SMTP id PAA21955 for <[e-mail]>; Mon, 12 Apr 1999 15:10:19 -0700 (PDT)
Received: 	id SAA16352; Mon, 12 Apr 1999 18:06:52 -0400
Received: by gateway id <G4CA53VF>; Mon, 12 Apr 1999 18:09:14 -0400
Message-ID: <01E1D01C12D7D211AFC70090273D20B104F064@sothmxs06>
From: Carlisle Adams <[e-mail]>
To: "'[e-mail]'" <[e-mail]>
Cc: "'[e-mail]'" <[e-mail]>
Subject: RE: Cross certification message protection (RFC2510)
Date: Mon, 12 Apr 1999 18:02:51 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.1960.3)
Content-Type: text/plain
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Hi Mike,

Sorry for the long delay in responding, but I was out of town for over a
week when you posted your message and have been swamped with a number of
things since I got back.

> ----------
> From: 	[e-mail][SMTP:[e-mail]]
> Sent: 	Thursday, March 25, 1999 4:17 PM
> To: 	[e-mail]
> Cc: 	ietf-pkix
> Subject: 	Re: Cross certification message protection (RFC2510)
> 
> Juergen,
>      I am not really questioning the benifits/differences between signing
>      and generating a MAC. My question is about what appears to be a
> conflict
>      in the spec. In one place it says you must protect the message with a
> MAC,
>      and in another place it says you must protect the message with a
> digital
>      signature. I was wondering which section (B7 or 4.6.1) is correct.
 
Note that in some sense the conflict is only an illusion:  Section 4
describes mandatory functionality (i.e., every CMP-compliant entity MUST
support these functions, such as cross-certification); and Appendix B
describes the mandatory profile for those functions (i.e., these are the
sorts of values that MUST appear in various fields in order to support the
required functions).  However, since 4.6.1 steps a bit over the line and
talks about a particular mechanism to implement the function (i.e., the
MAC), then the mechanism in 4.6.1 should really align with B7 to save
confusion, even though technically it doesn't need to.

Note, too, that it doesn't matter whether 4.6.1 and B7 use MAC or SIG:  this
is only the minimum profile for interoperability.  In true IETF fashion,
compliant implementations must support the mandatory set of things, but are
perfectly free to never actually use them in day-to-day operation.  Thus,
Juergen need not be too concerned if the profile mandates MAC but he'd
rather use a SIG.

In any case, to keep confusion to a minimum, 4.6.1 and B7 should be aligned.
It seemed to me that SIG might be easier in practice (since CAs wishing to
cross-certify may already have trusted copies of each other's certificates),
but I'm happy to put MAC in B7 if you prefer (I've heard a couple of other
votes privately for MAC).  In terms of actual editing, this requires
slightly less typing than changing 4.6.1 to SIG...  :-)

I'm trying to collect a list of typos/issues/etc. that people have caught
with respect to RFC 2510.  Whenever there is an opportunity to update it
(e.g., if the Working Group decides to consider progressing it to Draft, as
it seems to be considering with RFC 2459), I will put these things in.

Thanks for noticing this and bringing it to my attention!

Carlisle.



Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id JAA18493 for ietf-pkix-bks; Mon, 12 Apr 1999 09:52:35 -0700 (PDT)
Received: from gatekeeper.entrust.com (gatekeeper.entrust.com [204.101.128.170]) by mail.proper.com (8.8.8/8.8.5) with SMTP id JAA18489 for <[e-mail]>; Mon, 12 Apr 1999 09:52:33 -0700 (PDT)
Received: 	id MAA08432; Mon, 12 Apr 1999 12:48:46 -0400
Received: by gateway id <G4CA5MYJ>; Mon, 12 Apr 1999 12:51:07 -0400
Message-ID: <01E1D01C12D7D211AFC70090273D20B104F05F@sothmxs06>
From: Carlisle Adams <[e-mail]>
To: Xiong Shao Jun <[e-mail]>, "'Russ Housley'" <[e-mail]>
Cc: [e-mail]
Subject: RE: About Diffie-Hellman algorithm and Shamir threshold
Date: Mon, 12 Apr 1999 12:44:47 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.1960.3)
Content-Type: text/plain
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Hi,

Russ is right.  When we were putting in the final edits to turn the Internet
Draft into an RFC, I remembered to update the OID to the correct value, but
forgot to update "DHParameter" to "DomainParameters".

RFC 2459 has the proper parameter to correspond to the OID.  RFC 2510 will
need to be updated whenever the opportunity arises.  Thank you for catching
this!

Some day all the PKIX documents will be perfect...  :-)

Carlisle.


> ----------
> From: 	Russ Housley[SMTP:[e-mail]]
> Sent: 	Monday, April 12, 1999 10:05 AM
> To: 	Xiong Shao Jun
> Cc: 	[e-mail]
> Subject: 	Re: About Diffie-Hellman algorithm and Shamir threshold
> 
> Xiong Shao Jun:
> 
> The definition in RFC 2459 is aligned with the Draft ANSI X9.42
> specification and the Draft IEEE P1363 speciification.
> 
> I think that you uncovered a bug in RFC 2510.
> 
> Russ
> 
> 
> At 01:17 PM 4/11/99 +0800, Xiong Shao Jun wrote:
> >Hi, I have two problems. The first is about Diffie-Hellman algorithm. In
> >PKIX part1, now
> >rfc2459, the algorithm is described as:
> >
> >OID:    1.2.840.10046.2.1
> >DomainParameters ::= SEQUENCE {
> >        p            INTEGER, -- odd prime, p=jq+1
> >        g            INTEGER, -- generator, g
> >        q            INTEGER, -- factor of p-1
> >        j            INTEGER OPTIONAL, -- subgroup factor
> >        validationParms    ValidationParms OPTIONAL }
> >
> >ValidationParms    ::= SEQUENCE {
> >        seed            BIT STRING
> >    pgenCounter   INTEGER }
> >
> >while in certificate management protocol, now rfc2510, the algorithms is
> >described as
> >below:
> >OID:    1.2.840.10046.2.1
> >DHParameter ::= SEQUENCE {
> >        prime INTEGER, -- p
> >        base  INTEGER  -- g
> >}
> >
> >So which is the most up to date description, and which should I
> >implement?
> >
> 


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id JAA18290 for ietf-pkix-bks; Mon, 12 Apr 1999 09:28:29 -0700 (PDT)
Received: from gatekeeper.entrust.com (gatekeeper.entrust.com [204.101.128.170]) by mail.proper.com (8.8.8/8.8.5) with SMTP id JAA18284 for <[e-mail]>; Mon, 12 Apr 1999 09:28:27 -0700 (PDT)
Received: 	id MAA26690; Mon, 12 Apr 1999 12:23:21 -0400
Received: by gateway id <G4CA5M4G>; Mon, 12 Apr 1999 12:25:41 -0400
Message-ID: <01E1D01C12D7D211AFC70090273D20B104F05E@sothmxs06>
From: Carlisle Adams <[e-mail]>
To: "'Jim Schaad (Exchange)'" <[e-mail]>
Cc: "IETF-PKIX (E-mail)" <[e-mail]>
Subject: RE: New CMC Draft available
Date: Mon, 12 Apr 1999 12:19:23 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.1960.3)
Content-Type: text/plain; charset="iso-8859-1"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Hi Jim,

> ----------
> From: 	Jim Schaad (Exchange)[SMTP:[e-mail]]
> Sent: 	Monday, April 12, 1999 12:47 AM
> To: 	'Carlisle Adams'; IETF-PKIX (E-mail)
> Subject: 	RE: New CMC Draft available
> 
> Carlisle,
> 
> Sorry about taking so long on replying to this, but the few times that I
> get
> sick I really do a good job of getting sick.  Comments are inline
 
No problem.  Thanks for getting back to me, and I hope you're feeling
better.

> > -----Original Message-----
> > From: Carlisle Adams [mailto:[e-mail]]
> > Sent: Monday, March 15, 1999 3:42 PM
> > To: IETF-PKIX (E-mail)
> > Subject: RE: New CMC Draft available
> > 
> > Abstract:  there is not a *need* for an interface to PK certification
> > products and services based on [CMS] and [PKCS10]; there is a 
> > *desire* for
> > such an interface.  Nothing *needs* to be based on CMS and PKCS10
> > (especially since, as noted in the conformance section, 
> > existing deployed
> > software is not immediately compliant with this 
> > specification).  However,
> > there is great *desire* to base the protocols on CMS and 
> > PKCS10, since these
> > are familiar.  Please change "need" in bullet 1 to "desire" 
> > (and change
> > "immediate needs" in the opening sentence to "immediate concerns", or
> > similar).
> 
> I don't really know what to say on this point.  One person's desires are
> another person's needs.
 
Backward compatibility with a large installed base may partly justify the
use of the word "need" here.  However, it has already been admitted that the
installed base is not immediately compliant with this protocol.  Can you
suggest one good reason why there is a "need" for such an interface rather
than a "desire"?  If not, please replace the word.

> > 
> > Section 2:  this may be obvious to many, but I think that stating the
> > following underlying operational assumption will help to clarify the
> > operational model for this protocol.  "Underlying assumption: 
> >  every PKI
> > entity will have a signing key pair and will request a verification
> > certificate in its initialization message (i.e., an entity 
> > will never ask
> > for an encryption certificate _only_ in its initialization 
> > message)."  [The
> > reason that it might help to clarify this is that RFC 2510 
> > does not have
> > this restriction.]
> 
> I am not sure that I agree with this statment.  I believe that it is
> possible in this model to obtain just an encryption certificate.  There
> are
> no limits in the model that prevent this.  The one-time shared secret can
> be
> used to identify the end user to the CA, and the request could just be for
> an encryption certificate.  There would be no way to renew such a
> situation
> as no proof of identity could easily be offered with just an encryption
> certificate, but the initial request could easily be made.
 
You say "There are no limits in the model that prevent this", but the
operational model of CMC is that this initial request gets enveloped in a
SignedData construct.  How does an entity without a signature key pair sign
this request for an encryption certificate?

> > 
> > Also, "NoSignatureValue contains the hash of the 
> > certification request." --
> > why force the implementer to do an extra hash here for no 
> > purpose?  Why not
> > say that NoSignatureValue "contains the value 1234", or similar?
> 
> This could easily be a constant value, I put the hash in for two reasons.
> First, the code base that I was using computed the hash anyway so there
> were
> no reasons not to use it.  Second, by including the hash the most obious
> of
> transmissions errors could potentially be found.  Unless there are other
> who
> support using a constant value, I do not plan to change this.
 
With respect to your first reason, I have to wonder how many people are
using a code base identical to the one that you are using (and so whether
this is really a strong enough reason to use the hash).  As for your second
reason, it seems to me that detection and handling of transmission errors
should really have nothing whatsoever to do with this protocol (there's no
reason to mix the functionality of different layers here), and so perhaps
this is not a strong enough reason to use the hash either.

Unless there are other, better, reasons for causing implementers to do the
extra hash computation, I suggest removing it.

> > 
> > Section 5.7:  should note in first paragraph that PKCS10 
> > cannot be used to
> > provide this functionality.
> 
> This is not correct.  The correct statement, which I will pass by the
> other
> authors, is that simple enrollment messages cannot provide this
> functionality.  There is no reason that a PKCS10 included as part of a
> full
> enrollment request cannot provide the functionality needed.
 
The section discusses POP for encryption-only keys.  How, exactly, can PKCS
#10 handle a request for an encryption-only key pair, even if it is included
as part of a full enrollment request (i.e., what goes in the "signature"
field of the PKCS #10)?

> > 
> > Also, it appears (from the text in bullet 4a and the text in 
> > the second-last
> > sentence of the section) that the DecryptedPOP structure 
> > should contain
> > "request    TaggedRequest" rather than "bodyPartID    
> > BodyPartID".  That is,
> > the decrypted POP needs to contain the actual request itself 
> > (not just an
> > ID).
> 
> I have changed the language on this slightly.  What is placed here is the
> body part id of the request.  The request is included by reference and the
> text now states this.
 
I assume what you mean by this is that the request is included by reference
*in the decryptedPOP structure*, but is included by value elsewhere in this
message.  Otherwise, the server still needs to keep state information.

 
(...key recovery stuff...)

> We will look at the comments on this section for a new draft.  As I
> anounced
> at the IETF meeting we are pulling out all of the archiving text and
> placing
> it into a seperate draft.  That draft will address both the archiving and
> server side key generation issues.
 
Sorry I was not able to attend the last IETF meeting due to other travel
commitments.  What was the justification for this decision?  Given that
these functions are very important for some environments, is there a good
reason to delay their inclusion in this document?  What time frame do you
envision for this separate draft?  Just curious.

I suppose it is fortuitous that this functionality is addressed in RFC 2510
for those that need it now.

> > 
> > Section 5.14:  "The query pending attribute allows for a 
> > client to query a
> > server about the state..." -- how does the client know when 
> > to do this?  Is
> > there a time-to-check-back value included somewhere in the server's
> > response?
> 
> This value is in the CMCStatusInfo structure.  We will include a text
> reference here to that fact.
 
You're right; I missed this.  Sorry.

> > 
> > Finally, there is some  functionality missing in this 
> > specification that
> > will be very important for some environments.
> > 
> > - there is currently no way for a CA/RA to provide a trust 
> > anchor (public
> > key or self-signed cert) to the client during initialization.
> 
> Given the number of ways that this can be done, and the impliciations
> about
> the fact that clients are going to start automatically accepting such
> certificates as trust anchors, the author's are hesitant to include this
> fucntionality.  Please place on the list as a seperate topic of discussion
> to see how much support exists for this.
 
It is customary to mandate one mechanism (and allow others) for
interoperability purposes, precisely when there are a number of ways that
something can be done.  There should be little reason for hesitancy with
respect to at least specifying a mechanism; such functionality was included
in RFC 2510 and received no objection whatever.

> > - there is no confirmation message from the client to the 
> > CA/RA (thus, there
> > is no way for a client to reject a certificate that it does 
> > not want (e.g.,
> > in the case where the CA has modified some of the fields in 
> > the request)).
> 
> There is a simple way for a client to reject a certificate, it simply puts
> in a revocation request on the certificates it just received.  I don't
> know
> of any reason for the oppositite to be required in a general protocal.
> That
> is the client must positively accept a certificate.  
 
It seems much cleaner and simpler to me to be able to reject a certificate
before it is publicly issued than to have to go through the hassle of
issuing it and then revoking it (especially given the fact that revocation
status is still not universally checked by browsers and other
"certificate-aware" software).  I thought this might have been an important
consideration.

> > 
> > - CA key rollover is not described.  (This might be considered to be
> > out-of-scope of the current document, but it is very much 
> > in-scope for a
> > specification on how to do comprehensive certificate 
> > management, which is
> > what the title of this document suggests.)
> 
> There are really two different points that need to be addressed here and
> they are seperate problems.  The problem of rolling over a CA key is not
> really a big issue from what I can tell.  All you do is issue the new CA
> certificate and start referencing it correctly using AIA and CDP
> extensions.
> I think the problem you really want to address here is the question of
> trust
> anchor roll-over.  Before we addressed this we would need to address the
> question of doing trust anchor issues at all.
 
Trust anchor roll-over is certainly an important problem, and I agree that
in some ways it is a separate issue.

However, CA key roll-over is not simply a matter of issuing a new
certificate and referencing it correctly.  The sort of procedure described
in RFC 2510 (OldWithNew, NewWithOld, etc.) is necessary so that certificate
paths can be constructed automatically in all circumstances (i.e., cert is
signed with new CA key but verifier has a cross-certificate for old CA key,
etc.).  This is not exclusively a trust anchor issue because it pertains to
CAs in the middle of the path as well.



Thanks again for your responses to my earlier comments!  I appreciate your
efforts to take my concerns into consideration...

Carlisle.



Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id HAA16782 for ietf-pkix-bks; Mon, 12 Apr 1999 07:09:31 -0700 (PDT)
Received: from spyrus.com (mail.spyrus.com [207.212.34.30]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id HAA16778 for <[e-mail]>; Mon, 12 Apr 1999 07:09:30 -0700 (PDT)
Received: from rhousley_laptop.spyrus.com ([209.172.119.101]) by spyrus.com (8.7.6/8.7.3/arc) with SMTP id HAA11902; Mon, 12 Apr 1999 07:07:12 -0700 (PDT)
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1 
Date: Mon, 12 Apr 1999 10:05:42 -0400
To: "Xiong Shao Jun" <[e-mail]>
From: Russ Housley <[e-mail]>
Subject: Re: About Diffie-Hellman algorithm and Shamir threshold
Cc: [e-mail]
In-Reply-To: <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Xiong Shao Jun:

The definition in RFC 2459 is aligned with the Draft ANSI X9.42
specification and the Draft IEEE P1363 speciification.

I think that you uncovered a bug in RFC 2510.

Russ


At 01:17 PM 4/11/99 +0800, Xiong Shao Jun wrote:
>Hi, I have two problems. The first is about Diffie-Hellman algorithm. In
>PKIX part1, now
>rfc2459, the algorithm is described as:
>
>OID:    1.2.840.10046.2.1
>DomainParameters ::= SEQUENCE {
>        p            INTEGER, -- odd prime, p=jq+1
>        g            INTEGER, -- generator, g
>        q            INTEGER, -- factor of p-1
>        j            INTEGER OPTIONAL, -- subgroup factor
>        validationParms    ValidationParms OPTIONAL }
>
>ValidationParms    ::= SEQUENCE {
>        seed            BIT STRING
>    pgenCounter   INTEGER }
>
>while in certificate management protocol, now rfc2510, the algorithms is
>described as
>below:
>OID:    1.2.840.10046.2.1
>DHParameter ::= SEQUENCE {
>        prime INTEGER, -- p
>        base  INTEGER  -- g
>}
>
>So which is the most up to date description, and which should I
>implement?
>



Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id GAA16213 for ietf-pkix-bks; Mon, 12 Apr 1999 06:06:09 -0700 (PDT)
Received: from natasha1. (natasha-gw.checkpoint.com [199.203.73.129]) by mail.proper.com (8.8.8/8.8.5) with SMTP id GAA16209 for <[e-mail]>; Mon, 12 Apr 1999 06:06:05 -0700 (PDT)
Received: from cale.checkpoint.com (gray.checkpoint.com [199.203.71.94]) by cale.checkpoint.com (8.9.1/8.9.1) with ESMTP id QAA21138; Mon, 12 Apr 1999 16:08:20 +0300 (IDT)
Message-ID: <[e-mail]>
Date: Mon, 12 Apr 1999 16:04:51 +0300
From: Moshe Litvin <[e-mail]>
X-Mailer: Mozilla 4.51 [en] (WinNT; I)
X-Accept-Language: en
MIME-Version: 1.0
To: "David P. Kemp" <[e-mail]>
CC: [e-mail]
Subject: Re: CA vs. EE cert processing
References: <[e-mail]>
Content-Type: multipart/mixed; boundary="------------AB3A2DC0AE8F3831974FCFC2"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

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

David,

"David P. Kemp" wrote:

<snip>

>
> How much current software would be helped by changing the requirements
> on EE certs (i.e. would magically start behaving differently if PKIX
> were modified)?
>
>   My answer: none.
>
> How would changing PKIX affect the development of new verifying software
> (i.e. what would new software do differently if PKIX is changed vs.
> not changed, recognizing that up to 3 types of certs -
> non-RFC2459 X.509, RFC2459, and new-modified-PKIX - will be around
> for a while)?
>
>   My answer: nothing.

You are asking the wrong questions. The correct questions are:

How much current software would be helped by an EE certificate that contains
the basicConstraint (i.e. won't consider it as a CA certificate in the path
validation process)

    My answer: Every PKIX compliant software(*) and I guess a lot of non PKIX
compliant X.509 software.

How would changing PKIX affect the development of new issuing software
(i.e. what would new software do differently if PKIX is changed vs.
not changed)

    My answer: I guess that most CA vendor that consider the internet as their
market would follow it.

Change to PKIX won't change the verifying software, but its behavior will be
changes as a result in the change of the certificate.

Moshe

(*) PKIX compliant verifier MUST recognize the basicConstraint extension.
Section 4.2 says:

   At a minimum, applications conforming to this profile MUST recognize
   the extensions which must or may be critical in this specification.
   These extensions are:  .... basic constraints (see sec. 4.2.1.10) ....


--------------AB3A2DC0AE8F3831974FCFC2
Content-Type: text/x-vcard; charset=us-ascii;
 name="moshe.vcf"
Content-Transfer-Encoding: 7bit
Content-Description: Card for Moshe Litvin
Content-Disposition: attachment;
 filename="moshe.vcf"

begin:vcard 
n:Litvin;Moshe
tel;fax:[phone]
tel;work:[phone]
x-mozilla-html:TRUE
org:Check Point Software Technologies Ltd.
adr:;;;;;;
version:2.1
email;internet:[e-mail]
fn:Moshe Litvin
end:vcard

--------------AB3A2DC0AE8F3831974FCFC2--



Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id FAA15827 for ietf-pkix-bks; Mon, 12 Apr 1999 05:12:03 -0700 (PDT)
Received: from mail.student.auckland.ac.nz (mail.student.auckland.ac.nz [130.216.35.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id FAA15809; Mon, 12 Apr 1999 05:11:25 -0700 (PDT)
Received: from cs26.cs.auckland.ac.nz ([e-mail] [130.216.36.9]) by mail.student.auckland.ac.nz (8.8.6/8.8.6/cs-master) with SMTP id AAA21458; Tue, 13 Apr 1999 00:11:34 +1200 (NZST) (sender [e-mail])
Received: by cs26.cs.auckland.ac.nz (relaymail v0.9) id <92391909404745>; Tue, 13 Apr 1999 00:11:34 (NZST)
From: [e-mail] (Peter Gutmann)
To: [e-mail], [e-mail]
Subject: Re: Possible ambiguities in encoding of signatures, encrypted keys
Reply-To: [e-mail]
X-Charge-To: pgut001
X-Authenticated: relaymail v0.9 on cs26.cs.auckland.ac.nz
Date: Tue, 13 Apr 1999 00:11:34 (NZST)
Message-ID: <[e-mail]>
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

William Whyte <[e-mail]> writes:
 
>>Currently both RFC 2459 and CMS refer to RFC 2313/2437 for the encoding of RSA
>>signatures/encrypted data (RFC 2459, 7.2.1; CMS, 12.3.2.1 and 12.2.2 - what I'm
>>about to describe applies to other algorithms as well, but I'll stick with RSA
>>to keep it simple).  These RFC's make the assumption that the encoded value
>>will be of the same length as the modulus, zero-padding the value if required
>>(RFC 2437, 7.2.1 and 8.1.1), however when this padding is used the encoded
>>value doesn't follow the DER any more.
 
>I'm not sure this is right. The signature is an octet string or a bit string,
>not an integer, and it's perfectly legal to have an OCTET STRING or BIT STRING
>with leading null bytes.
 
Ah, of course!  This only leaves the signatures which have internal structure
(eg DSA, a SEQUENCE containing two INTEGER's), and they have their own rules
which don't clash with RFC 2459/CMS.
 
(Didn't PKIX at one point include a requirement for DH values, encoded as bit
 strings, to be shifted up so the MSB was the first nonzero bit in the string,
 thankfully this vanished soon after it appeared because it would've been a
 right pain to implement)
 
Is anyone aware of any implementations which break if the signature/encrypted
data value isn't padded out as required?  You'd probably have to go out of your
way to write code which does this, I'm wondering whether any code does actually
complain if the data isn't exactly the right size.  The reason I'm asking is
that I've always encoded things in the minimum number of bytes (as if it was a
DER INTEGER) rather than padding with zeroes which so far hasn't caused any
problems.
 
Peter.
 



Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id CAA12206 for ietf-pkix-bks; Mon, 12 Apr 1999 02:33:25 -0700 (PDT)
Received: from natasha1. (natasha-gw.checkpoint.com [199.203.73.129]) by mail.proper.com (8.8.8/8.8.5) with SMTP id CAA12202 for <[e-mail]>; Mon, 12 Apr 1999 02:33:21 -0700 (PDT)
Received: from cale.checkpoint.com (gray.checkpoint.com [199.203.71.94]) by cale.checkpoint.com (8.9.1/8.9.1) with ESMTP id MAA04325; Mon, 12 Apr 1999 12:35:34 +0300 (IDT)
Message-ID: <[e-mail]>
Date: Mon, 12 Apr 1999 12:32:01 +0300
From: Moshe Litvin <[e-mail]>
X-Mailer: Mozilla 4.51 [en] (WinNT; I)
X-Accept-Language: en
MIME-Version: 1.0
To: Stephen Kent <[e-mail]>
CC: [e-mail]
Subject: Re: CA vs. EE cert processing
References: <v04020a17b331af2ed303@[128.33.238.98]> <v04020a0bb332fcbd7733@[128.33.238.98]>
Content-Type: multipart/mixed; boundary="------------9F90A261CB7FB330CF514ADF"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

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

Steve,

<snip>

Stephen Kent wrote:

> >We cannot remove the possibility of ambiguity but we can generate certificates
> >that are not affected by it.
>
> I agree that a CA could put the extension in all certs and thus be able to
> say "not my fault; I did what I could."  But this does not address the
> verifier problem in other than a heuristic fashion.

Why? If a certificate contain the extension no heuristics are necessary for
validating this certificate. If a CA put the basicConstraint extension in all the
certificate that it issues than no certificate that the CA issues needs heuristics
to process it.

> I want to
> deterministic solution to the problem, and the suggested change to 2459
> does not yield that.

The suggested solution is not complete but it is very deterministic. If it will be
accepted in its strongest form (MUST put basicConstraint in all the certificate)
then no PKIX CA will issue a certificate that needs heuristics by X.509 verifier
(be it PKIX, other profile or raw X.509).

A CA can create unambiguous certificates. We should encourage them to do so.

>
>
> >>
> >> <snip>
> >
> >It is not probabilistic improvements. A CA that put the basicConstraints
> >extension is 100% not ambiguous. What probablistic about that?
> >
> >Why discourage CA's from generating unambiguous certificates?
>
> See my comments above. I was referring to the verifier, not the CA.  Sorry
> for the ambiguity :-)!  The CA doesn't have a problem; verifiers have the
> problem we are trying to address.
>

The verifier has the ambiguity, but the CA can help him solve it. The verifier code
will have some kind of heuristics but they won't be triggered if the CA will
produce unambiguous certificates.

>
> <snip>
> >
> >Adding the extension is not a heuristic improvement, a certificate with the
> >extension is certificate that doesn't need heuristics period.
> >
> >Admittedly the verifier will have heuristics but the CA can ensure that they
> >won't be activated.
>
> No, it cannot!  So long as there are CAs following X.509 but not the 2459
> profile, verifiers would need heuristics to process certs without
> extensions issued by those CAs.

This is exatclty what I wrote.


>  If we were willing to posit that no such
> CAs will exist, then we would not have a problem, because in a purely
> 2459-compliant system (CAs and verifiers) there is not ambiguity.  You seem
> to be switching perspectives in analyzing this issue.

No my perspective is fixed. I think that a CA should assume as little as possible
of a possible verifier namely:

1. Correct DER decoding
2. Correct handling of the basic X.509 fields.
3. Considering a certificate as invalid if it cannot correctly handle a critical
extension.

A CA is not limited to creating certificates that can be validated by the minimal
verifier but it should try to make sure that if the minimal verifier cannot
correctly validate the certificate it will fail validation.  X.509 provides the
mechanism for doing so in the critical flag.

With this model we can compare both options for basicConstraint. We have 3 types of
minimal verifiers with respect to the basicConstraint:

A. Verifier that does not understand basicConstraint.
B. A verifier that understand basicConstraint.
C. A verifier that is PKIX compliant and knows by out of band means that so is the
CA

We also have 3 types of EE certificate:

i. Without basicConstraint
ii. With non-critical basicConstraint
iii. With critical basicConstraint

You can complete the table and see in which combination the verifier can identify
the certificate as EE certificate and where it could have accepted it as a CA
certificate.

>
>
> >>
> >
> >X.509 already addresses the problem and suggests:
> >
> >   It is recommended that it be flagged critical, otherwise an entity which is
> >not
> >   authorized to be a CA may issue certificates and a certificate-using system
> >   may unwittingly use such a certificate.
> >
> >For some reason PKIX decided to ignore the recommendation and invent it's own
> >private semantics.
>
> X.509 failed to solve this problem because it permits compliant CAs to
> never include basicConstraints, thus creating the ambiguity.  The notes
> fail to fix the problem, because they just "recommend" what to do.  In the
> IETF we try to be very careful in our use of the magir words
> MUST/SHOULD/MAY to avoid these problems.
>

I think that recommended is a similar to SHOULD, maybe to MAY. I don't think that
it is "SHOULD NOT", but english isn't my mother's tongue.

My question is still open - why PKIX chose to ignore the recommendation and
invented private semantics?

X.509 offered a standard syntax , if that wasn't enough we could use private
syntax. But using private semantics is the worse option.

Moshe


--------------9F90A261CB7FB330CF514ADF
Content-Type: text/x-vcard; charset=us-ascii;
 name="moshe.vcf"
Content-Transfer-Encoding: 7bit
Content-Description: Card for Moshe Litvin
Content-Disposition: attachment;
 filename="moshe.vcf"

begin:vcard 
n:Litvin;Moshe
tel;fax:[phone]
tel;work:[phone]
x-mozilla-html:TRUE
org:Check Point Software Technologies Ltd.
adr:;;;;;;
version:2.1
email;internet:[e-mail]
fn:Moshe Litvin
end:vcard

--------------9F90A261CB7FB330CF514ADF--



Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id CAA12145 for ietf-pkix-bks; Mon, 12 Apr 1999 02:25:48 -0700 (PDT)
Received: from puma.baltimore.ie ([e-mail] [194.125.215.8]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id CAA12113; Mon, 12 Apr 1999 02:22:00 -0700 (PDT)
Received: by puma.baltimore.ie; id KAA21213; Mon, 12 Apr 1999 10:44:58 +0100 (GMT/IST)
Received: from ocelot.baltimore.ie(10.49.0.10) by puma.baltimore.ie via smap (4.1) id xma021196; Mon, 12 Apr 99 10:44:09 +0100
Received: from knuckle (knuckle.baltimore.ie [10.49.0.103]) by ocelot.baltimore.ie (8.8.7/8.8.5) with SMTP id KAA20706; Mon, 12 Apr 1999 10:12:07 +0100
Received: by localhost with Microsoft MAPI; Mon, 12 Apr 1999 10:20:56 +0100
Message-ID: <[e-mail]>
From: William Whyte <[e-mail]>
To: "'[e-mail]'" <[e-mail]>, "[e-mail]" <[e-mail]>, "[e-mail]" <[e-mail]>
Subject: RE: Possible ambiguities in encoding of signatures, encrypted keys
Date: Mon, 12 Apr 1999 10:20:54 +0100
Organization: Baltimore Technologies
X-Mailer: Microsoft Internet E-mail/MAPI - 8.0.0.4211
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Hi Peter,

> Currently both RFC 2459 and CMS refer to RFC 2313/2437 for the encoding of RSA
> signatures/encrypted data (RFC 2459, 7.2.1; CMS, 12.3.2.1 and 12.2.2 - what I'm
> about to describe applies to other algorithms as well, but I'll stick with RSA
> to keep it simple).  These RFC's make the assumption that the encoded value
> will be of the same length as the modulus, zero-padding the value if required
> (RFC 2437, 7.2.1 and 8.1.1), however when this padding is used the encoded
> value doesn't follow the DER any more.

I'm not sure this is right. The signature is an octet string or a
bit string, not an integer, and it's perfectly legal to have an
OCTET STRING or BIT STRING with leading null bytes. RFC 2313 says:

8.4 Integer-to-octet-string conversion

   The integer encrypted data y shall be converted to an octet string ED
   of length k, the encrypted data. 

and it's the octet string that's encoded.

Cheers,

William


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id BAA11761 for ietf-pkix-bks; Mon, 12 Apr 1999 01:22:05 -0700 (PDT)
Received: from selva.dit.upm.es (selva-gw.dit.upm.es [138.4.2.7]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id BAA11751 for <[e-mail]>; Mon, 12 Apr 1999 01:21:55 -0700 (PDT)
Received: from dit.upm.es (toro-3.dit.upm.es [138.4.21.3]) by selva.dit.upm.es (8.9.1a/8.9.1) with ESMTP id KAA00374; Mon, 12 Apr 1999 10:19:31 +0200 (MET DST)
Message-ID: <[e-mail]>
Date: Mon, 12 Apr 1999 10:24:42 +0200
From: "Jose A. Manas" <[e-mail]>
X-Mailer: Mozilla 4.51 [en] (Win95; I)
X-Accept-Language: en
MIME-Version: 1.0
To: Denis Pinkas <[e-mail]>
CC: Manuel Heras Gilsanz <[e-mail]>, "[e-mail]" <[e-mail]>, [e-mail]
Subject: Re: Time-Stamp: Why not use several hashes?
References: <[e-mail]> <[e-mail]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Denis,
I feel uneasy with both arguments.

If a guy finds out how to provoke collisions on a hash functions,
there is a serious temptation to exploit the hole before
publishing it. Breaking a time-stamp infrastructure is a nice
goal: you break it before anybody knows it can be broken,
and then there is a difficult question about when the TSA was
no longer to be trusted.

I have some concern as well with respect to breaking a digital
signature. If broken but time-stamped, 
a TSA can still prove that it was signed
before it was breakable. But if you break the TSA itself, then
there is no help. That about breaking the hash.

Still, if you break the TSA signature, you have audit records
(stored evidence in the TSA) to help you (as far as there are
no collisions in the hash).

Alltogether, I aim to say that breaking a hash does break down
everything, and it sounds interesting to foresee the case.
Allowing for several messageimprints sounds as a cheap end
effective countermeasure.

pp

Denis Pinkas wrote:
> 
> Manuel,
> 
> We want to keep the protocol simple. The threat you mention can be countered
> by another way: re-time-stamp later on with a new hash function. If SHA-1
> gets broken one day, this will not happen in just one day. Some
> cryptographer will first find some weaknesses before you can really forge a
> meaningfull message that has the same hash. So you get some time for
> re-stamping.
> 
> If this argument were used, then we should sign TWICE, i.e.  in case one
> digital signature algorithm was broken. We do not do that. There is no
> reason to do it for the hash function.
> 
> Regards,
> 
> Denis
> 
> > Hi.
> >
> > In the (now expired) latest PKIX draft on time-stamping protocols from
> > Sept. 23, 1998, time-stamp requests and tokens support the insertion of
> > a single message imprint.
> >
> > I think several message imprints should be supported. If a hash
> > algorithm were broken, time-stamp tokens using it (as the single message
> > imprint) would have to be regarded invalid (even if some kind of linking
> > mechanism were implemented!). If several hashes had been used, the token
> > would still be valid, and it could be promptly renewed in order to
> > prevent invalidation should further advances in cryptography render
> > other hashes obsolete!
> >
> > (One must be careful here: there are different extents to which a hash
> > algorithm could be broken; in Appendix A of  PKITS-D3
> > [http://www.fnmt.es/pkits] there is an interesting analysis of the
> > implications that the different kinds of hash failures would have on the
> > time-stamping process.)
> >
> > Of course the requirements on the time-stamp verification process would
> > also have be modified to require ("MUST" level) *all* the hashes to
> > correctly verify in order to regard the corresponding time-stamp token
> > valid.
> >
> > Best regards,
> >
> >     - Manuel -
> >
> > ----
> > Manuel Heras-Gilsanz ([e-mail])
> > Independent Security Consultant
> > Phone: [phone]

-- --------------------------------------------------------
Prof. Jose A. Manas                     <[e-mail]>
Dpt. Telematica                 http://www.dit.upm.es/~pepe
E.T.S.I. Telecomunicacion           tel: [+34] 91 336 73 25
Ciudad Universitaria                gsm: [+34] 607 73 38 94
E-28040 Madrid, SPAIN               fax: [+34] 91 336 73 33


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id VAA10187 for ietf-pkix-bks; Sun, 11 Apr 1999 21:48:37 -0700 (PDT)
Received: from doggate.exchange.microsoft.com (doggate.exchange.microsoft.com [131.107.88.55]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id VAA10183 for <[e-mail]>; Sun, 11 Apr 1999 21:48:36 -0700 (PDT)
Received: by doggate.exchange.microsoft.com with Internet Mail Service (5.5.2232.9) id <2TW7YV9L>; Sun, 11 Apr 1999 21:48:03 -0700
Message-ID: <2FBF98FC7852CF11912A0000000000010ECB5E49@DINO>
From: "Jim Schaad (Exchange)" <[e-mail]>
To: "'Carlisle Adams'" <[e-mail]>, "IETF-PKIX (E-mail)" <[e-mail]>
Subject: RE: New CMC Draft available
Date: Sun, 11 Apr 1999 21:47:51 -0700
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2232.9)
Content-Type: text/plain; charset="iso-8859-1"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Carlisle,

Sorry about taking so long on replying to this, but the few times that I get
sick I really do a good job of getting sick.  Comments are inline

> -----Original Message-----
> From: Carlisle Adams [mailto:[e-mail]]
> Sent: Monday, March 15, 1999 3:42 PM
> To: IETF-PKIX (E-mail)
> Subject: RE: New CMC Draft available
> 
> Abstract:  there is not a *need* for an interface to PK certification
> products and services based on [CMS] and [PKCS10]; there is a 
> *desire* for
> such an interface.  Nothing *needs* to be based on CMS and PKCS10
> (especially since, as noted in the conformance section, 
> existing deployed
> software is not immediately compliant with this 
> specification).  However,
> there is great *desire* to base the protocols on CMS and 
> PKCS10, since these
> are familiar.  Please change "need" in bullet 1 to "desire" 
> (and change
> "immediate needs" in the opening sentence to "immediate concerns", or
> similar).

I don't really know what to say on this point.  One person's desires are
another person's needs.

> 
> Section 2, Section 2.1, and elsewhere:  the document sometimes uses
> "certificate authority", sometimes uses "certification 
> authority", sometimes
> uses "Certification Authority", and so on.  Please be 
> consistent throughout.
> [Note that "Certification Authority" is the official term in various
> Standards.]

Done
--- Brian -- we need to decide on certificate request or certification
request and use this consistantly as well.

> 
> Section 2:  this may be obvious to many, but I think that stating the
> following underlying operational assumption will help to clarify the
> operational model for this protocol.  "Underlying assumption: 
>  every PKI
> entity will have a signing key pair and will request a verification
> certificate in its initialization message (i.e., an entity 
> will never ask
> for an encryption certificate _only_ in its initialization 
> message)."  [The
> reason that it might help to clarify this is that RFC 2510 
> does not have
> this restriction.]

I am not sure that I agree with this statment.  I believe that it is
possible in this model to obtain just an encryption certificate.  There are
no limits in the model that prevent this.  The one-time shared secret can be
used to identify the end user to the CA, and the request could just be for
an encryption certificate.  There would be no way to renew such a situation
as no proof of identity could easily be offered with just an encryption
certificate, but the initial request could easily be made.

> 
> Section 3.3.3.1:  "D-H private keys cannot always be used..." 
> -- note that
> is may also be true for RSA keys that are held in a 
> decrypt-only device, so
> you need not restrict this section to D-H.

You are quite correct, and we will modify the text to address this problem.

> 
> Also, "NoSignatureValue contains the hash of the 
> certification request." --
> why force the implementer to do an extra hash here for no 
> purpose?  Why not
> say that NoSignatureValue "contains the value 1234", or similar?

This could easily be a constant value, I put the hash in for two reasons.
First, the code base that I was using computed the hash anyway so there were
no reasons not to use it.  Second, by including the hash the most obious of
transmissions errors could potentially be found.  Unless there are other who
support using a constant value, I do not plan to change this.

> 
> Section 5.2 (second paragraph):  "Servers SHOULD provide this 
> method or have
> a bilateral method..." -- I would prefer the following for 
> interoperability
> reasons:  "Servers MUST provide this method and MAY also have 
> a bilateral
> method...".

We have made this change.

> 
> Section 5.7:  should note in first paragraph that PKCS10 
> cannot be used to
> provide this functionality.

This is not correct.  The correct statement, which I will pass by the other
authors, is that simple enrollment messages cannot provide this
functionality.  There is no reason that a PKCS10 included as part of a full
enrollment request cannot provide the functionality needed.

> 
> Also, it appears (from the text in bullet 4a and the text in 
> the second-last
> sentence of the section) that the DecryptedPOP structure 
> should contain
> "request    TaggedRequest" rather than "bodyPartID    
> BodyPartID".  That is,
> the decrypted POP needs to contain the actual request itself 
> (not just an
> ID).

I have changed the language on this slightly.  What is placed here is the
body part id of the request.  The request is included by reference and the
text now states this.

> 
> Section 5.9 (last paragraph):  "the server responds with a 
> Key Recovery
> Response containing the newly generated key." -- it doesn't 
> really make any
> sense semantically to use a key recovery response to 
> implement off-client
> key generation (since off-client key generation is not key 
> recovery).  Why
> not simply define a new message ("OffClientKeyGenRep") with 
> the same syntax
> as Key Recovery Response?

> 
> Also, "The details of the request control statement not 
> covered in this
> document...".  This will limit the use of this protocol in 
> some environments
> (those that mandate central key gen.).  A request message needs to be
> defined for this purpose.
> 
> Section 5.9.3:  "The ContentInfo contains the requested private key
> material." -- does it also contain the newly-created 
> recipient (i.e., EE)
> certificate?  If not, how can this response be used for off-client key
> generation?  [Note that according to CMS, it is not clear 
> that it's legal
> for a CA to put the EE certificate in this construct....]
> 
> Sections 5.9.4.1, 5.9.4.2, 5.9.4.3:  in each section you need 
> to say that
> the private key (DH-PrivateKey, DSA-PrivateKey, or RSAPrivateKey) must
> subsequently be re-encoded as an OCTET STRING (in order to 
> fit within the
> structure defined in Section 5.9.4).

We will look at the comments on this section for a new draft.  As I anounced
at the IETF meeting we are pulling out all of the archiving text and placing
it into a seperate draft.  That draft will address both the archiving and
server side key generation issues.

> 
> Section 5.10:  "low-end IP router that does not retain its 
> own certificate
> in non-volatile memory".  I might prefer "low-end IP router 
> that does not
> retain in non-volatile memory the certificates of those 
> entities with whom
> it needs to communicate".  Entities certainly need to get the 
> certificates
> of others in order to talk with them; do they really need to 
> keep their own
> certificates for most of their activities?

The original text on this issue is actually correct.  THe problem is that
router does not keep its own certificate during events such as power cycles.
After obtaining its own certificate from some type of directory service,
that certificate is presented as part of protocal to talk to the next
router.  Thus each router needs to get it's own certificate from a
centeralized location, but gets the other router's certificate from the
other router.

> 
> Section 5.11:  "The fields in a GetCRL have the following 
> meanings:  --
> issuerName is the value of the Issuer DN in the subject 
> certificate."  This
> will not work for Indirect CRLs.  Perhaps this field should 
> hold the name of
> the CRL issuer instead...

done

> 
> Section 5.12:  "it is impossible to produce a reliable 
> digital signature."
> -- this should be clarified to "it is impossible to produce a reliable
> digital signature (prior to the certification of a new 
> signature key pair)."

We have a couple of different suggestions for cleaning up this wording and
we will do so.

> 
> Section 5.14:  "The query pending attribute allows for a 
> client to query a
> server about the state..." -- how does the client know when 
> to do this?  Is
> there a time-to-check-back value included somewhere in the server's
> response?

This value is in the CMCStatusInfo structure.  We will include a text
reference here to that fact.

> 
> Section 6.1:  "The request is placed in the cmsSequence if it 
> is a full pki
> message and the reqSequence field for a simple enrollment 
> message." -- in
> the latter case, is this still a nested message?  (I.e., what is the
> difference between a "non-nested" message with a PKCS10 in 
> the reqSequence
> and a "nested" message with a simple enrollment message in 
> the reqSequence?)

There are a couple of different opinions on this amoung the author's.  We
will argue this out and put in clarification text on this issue

> 
> Sections 7.2, 7.3:  replace "BER" with "DER" since signatures are
> involved...

What is being referenced here is a CMS SignedData object (since we are
looking at full requests).  CMS explicity states these may be BER encoded
objects.

> 
> Section 12:  update the CRMF reference to RFC 2511 and the PKIXCERT
> reference to RFC 2459.  Also, was DH-SIG not updated to some 
> other draft
> recently?

In progress.  

> 
> 
> Finally, there is some  functionality missing in this 
> specification that
> will be very important for some environments.
> 
> - there is currently no way for a CA/RA to provide a trust 
> anchor (public
> key or self-signed cert) to the client during initialization.
> 

Given the number of ways that this can be done, and the impliciations about
the fact that clients are going to start automatically accepting such
certificates as trust anchors, the author's are hesitant to include this
fucntionality.  Please place on the list as a seperate topic of discussion
to see how much support exists for this.

> - there is no confirmation message from the client to the 
> CA/RA (thus, there
> is no way for a client to reject a certificate that it does 
> not want (e.g.,
> in the case where the CA has modified some of the fields in 
> the request)).

There is a simple way for a client to reject a certificate, it simply puts
in a revocation request on the certificates it just received.  I don't know
of any reason for the oppositite to be required in a general protocal.  That
is the client must positively accept a certificate.  

> 
> - cross-certification is not described.  (It appears to be 
> possible to do
> this with the existing messages, but without a prescribed method
> interoperability is unlikely.)

I don't understand why you think that interopability is a problem.  If a CA
generates a certificate request then it can get a cross-certificate.  The
real problem of interopability here is far more in the question of the
procedures required to accept such a request not in the request itself.

> 
> - as mentioned above, off-client key generation needs to be 
> specified (both
> request and response).  It would also be nice to be able to 
> ask for this as
> part of the Full PKI Request message, rather than having to 
> use separate
> req/rep messages.

Will be addressed in a seperate draft.

> 
> - CA key rollover is not described.  (This might be considered to be
> out-of-scope of the current document, but it is very much 
> in-scope for a
> specification on how to do comprehensive certificate 
> management, which is
> what the title of this document suggests.)

There are really two different points that need to be addressed here and
they are seperate problems.  The problem of rolling over a CA key is not
really a big issue from what I can tell.  All you do is issue the new CA
certificate and start referencing it correctly using AIA and CDP extensions.
I think the problem you really want to address here is the question of trust
anchor roll-over.  Before we addressed this we would need to address the
question of doing trust anchor issues at all.

> 
> 
> 
> That's all.  Aside from a few other typos, etc., the document 
> looks great!
> 
> Carlisle.
> 

Jim Schaad


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id VAA09929 for ietf-pkix-bks; Sun, 11 Apr 1999 21:10:53 -0700 (PDT)
Received: from mail.student.auckland.ac.nz (mail.student.auckland.ac.nz [130.216.35.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id VAA09906; Sun, 11 Apr 1999 21:06:58 -0700 (PDT)
Received: from cs26.cs.auckland.ac.nz ([e-mail] [130.216.36.9]) by mail.student.auckland.ac.nz (8.8.6/8.8.6/cs-master) with SMTP id QAA04716; Mon, 12 Apr 1999 16:07:02 +1200 (NZST) (sender [e-mail])
Received: by cs26.cs.auckland.ac.nz (relaymail v0.9) id <92389002120806>; Mon, 12 Apr 1999 16:07:01 (NZST)
From: [e-mail] (Peter Gutmann)
To: [e-mail], [e-mail]
Subject: Possible ambiguities in encoding of signatures, encrypted keys
Reply-To: [e-mail]
X-Charge-To: pgut001
X-Authenticated: relaymail v0.9 on cs26.cs.auckland.ac.nz
Date: Mon, 12 Apr 1999 16:07:01 (NZST)
Message-ID: <[e-mail]>
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Currently both RFC 2459 and CMS refer to RFC 2313/2437 for the encoding of RSA
signatures/encrypted data (RFC 2459, 7.2.1; CMS, 12.3.2.1 and 12.2.2 - what I'm
about to describe applies to other algorithms as well, but I'll stick with RSA
to keep it simple).  These RFC's make the assumption that the encoded value
will be of the same length as the modulus, zero-padding the value if required
(RFC 2437, 7.2.1 and 8.1.1), however when this padding is used the encoded
value doesn't follow the DER any more.  Although neither RFC 2459 or CMS
require this, the former does imply it when it says (Section 4) "the
certificate is encoded with the ASN.1 distinguished encoding rules (DER)".
Because the signature will be zero-padded a small portion of the time as per
RFC 2313/2437, it's not a DER-encoded value.  In addition I would suspect that
most implementations don't perform the zero-padding (although it's hard to
check because it occurs only about once every 256 times), so they wouldn't
comply with RFC 2313/2437.
 
The zero-padding requirement isn't something which is right or wrong one way or
the other, not padding means you get DER-compliant encodings, but padding is
necessary to allow one-pass encoding of CMS data (unless you use the indefinite
encoding all the way down) since the signature at the end of an arbitrary
amount of data could suddenly shrink by one (or more) bytes, requiring
everything to be re-encoded from the start.
 
To clear up this problem, I'd recommend the following:
 
Change the text in RFC 2459, section 4, to read:
 
  "the tbsCertificate is encoded with the ASN.1 distinguished encoding rules
   (DER)"
 
and add the following text wherever a reference to RFC 2313/2437 is made (I've
listed the section numbers above):
 
  Although RFC 2313/2437 requires that the encoded values be zero-padded to
  match the size of the modulus, this padding doesn't comply with the ASN.1
  distinguished encoding rules (DER) which allow at most one leading zero byte,
  and only if the MSB of the value is set.  Some implementations may choose to
  pad the value as per the RFC's, others may choose to follow the DER.  Both of
  these encoding forms are acceptable, and implementations should be able to
  process both zero-padded and non-padded values.
 
If necessary I guess RFC 2459 could be a bit more strict (always require DER),
but CMS should allow both forms since, as I've outlined above, requiring DER
would make one-pass encoding impossible.
 
Peter.
 



Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id QAA24884 for ietf-pkix-bks; Sun, 11 Apr 1999 16:22:13 -0700 (PDT)
Received: from dsg1.OpenDirectory.com.au ([203.108.249.145]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id QAA24879 for <[e-mail]>; Sun, 11 Apr 1999 16:22:03 -0700 (PDT)
Received: by DSG1 with Internet Mail Service (5.0.1458.49) id <2XG6NQQ3>; Mon, 12 Apr 1999 09:22:06 +1000
Message-ID: <D1A949D4508DD1119C8100400533BEDC0BE97E@DSG1>
From: Alan Lloyd <[e-mail]>
To: "'Anders Rundgren'" <[e-mail]>, Stephen Kent <[e-mail]>
Cc: [e-mail], [e-mail]
Subject: RE: CyberPhone Trust Propagation  Was: A $25,000,000,000 PKI
Date: Mon, 12 Apr 1999 09:22:05 +1000
X-Priority: 3
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.0.1458.49)
Content-Type: text/plain
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Anders, I think that the debate can and will go no where as do some
simply because the profile work is based on purity of the PKI model and
signed email messages over the internet.
There are three major components (comms and messaging protocols aside)
to the application of certificate systems for large scale use (I dont
bother with bespoke ones) - and that is a directory infrastructure, a
business and business entity information model that reflects the
business transactions (between the relevant directory enities) and an
overlaid PKI/CA model and functions that reflect the cost/trust/risk
aspects of delivering these services - and these processes/interactions
align to protected services one wants to deploy. In your case its domain
agile telephone devices, but it could be toll tickets or tram fares.

I think as time goes on - reality will set in and different
architectures/models for PKI system will emerge ... nature and
commercial effort  has a way of doing this.

Certainly my experience is showing that PKI on its own aint much use. It
needs the operational bits too.

regards alan

> -----Original Message-----
> From:	Anders Rundgren 
> Sent:	Sunday, April 11, 1999 2:30 PM
> To:	Stephen Kent
> Cc:	[e-mail]; [e-mail]
> Subject:	Re: CyberPhone Trust Propagation  Was: A $25,000,000,000
> PKI
> 
> Steve,
> 
> >It is not the server that grants the user the right to purchase, it
> is the
> >company.  The company can choose to do this in various ways, as
> described
> >in earlier messages.  Your approach introduces added vulnerabilities
> into
> >the system, realtive to a model in which the purchasing agent
> directly
> >controls his/her private key.
> 
> 
> But "your" model adds the following security problems when purchasers
> that have their purchaser keys and certs in a smart card:
> 
> 1) Key (card) distribution.  Make sure the right person gets it
> 
> 2) A need for trust in external software when purchasing outside of
> the company
> premises.  If at all possible for SW reasons.  And logging, what about
> that?
> 
> 3) As it probably can take days to get a new purchaser card in case of
> loss you may have to "borrow" somebody else's.  Normal human behavior
> 
> 4) No control of use or abuse until it may be too late.  Non-repudian
> is useless if your purchaser made your company go bankrupt
> 
> 
> 
> And then "your" model also adds the following PITAs
> 
> 1) Slow and expensive issuing of cards
> 
> 2) Hard to get a card if not physically close to the issuer
> 
> 
> As I see it, massive issuing and distribution of private keys
> introduce
> security problems that (unlike secure PK-servers and "Thin PKI") do
> not
> have any real solutions.
> 
> 
> But I will cease this debate as we are approaching "dead-lock" unless
> there
> are others who seems willing (and competent) to continue. 
> 
> Regards
> Anders
> 
> http://www.mobilephones-tng.com
> 
> 


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id QAA24424 for ietf-pkix-bks; Sun, 11 Apr 1999 16:06:12 -0700 (PDT)
Received: from dsg1.OpenDirectory.com.au ([203.108.249.145]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id QAA24394 for <[e-mail]>; Sun, 11 Apr 1999 16:05:41 -0700 (PDT)
Received: by DSG1 with Internet Mail Service (5.0.1458.49) id <2XG6NQQL>; Mon, 12 Apr 1999 09:05:14 +1000
Message-ID: <D1A949D4508DD1119C8100400533BEDC0BE97D@DSG1>
From: Alan Lloyd <[e-mail]>
To: "'Stephen Kent'" <[e-mail]>
Cc: [e-mail], [e-mail]
Subject: RE: SEIS:  RE: Certificates, Directories, and Distinguished Names
Date: Mon, 12 Apr 1999 09:05:13 +1000
X-Priority: 3
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.0.1458.49)
Content-Type: text/plain; charset="iso-8859-1"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Stephen - in all your words you never seem to come to grips with the
fact that X.509 is not ambigious in so far that it permits systems to be
built without certificate extensions - and for those build such systems
to determine by local means or imply what is a EE or a CA cert and what
use that cert has (eg for message verification or cert verification)..
X.509 - was written some years ago and it correctly (a a standard
should) provided a transition path to the use of cert extensions.

RFC 2459 came along some time later as a profile and just the fact that
people are discussing the issue in 2459 and it is unclear - means there
is a problem - in the Profile.

Just the fact you added this to your response says something about the
issue.

	Because 2459 requires inclusion of the extension in a CA cert,
there is no
	ambiguity.  If a CA chose to insert the extension in an EE cert,
despite
	the RFC's admonition, it would be redundant in the 2459 context,
but not
	cause an error.  You should refer to RFC 2119 to gain a better
understanding of the term "SHOULD" as used in RFCs.


and as for 2119 the extract: who can understand this stuff when applied
to a real system specification or profile?


4. SHOULD NOT   This phrase, or the phrase "NOT RECOMMENDED" mean that
   there may exist valid reasons in particular circumstances when the
   particular behavior is acceptable or even useful, but the full
   implications should be understood and the case carefully weighed
   before implementing any behavior described with this label.


Work that one out if you can when building large scale trusted system in
which many EE/clients will access many CA domains and do trusted
processing ....

Groan..............In my book Profiles have Musts (mandated),
Conditionals with the condition applied,  or Dont Use or Dont
Care/Ignore

shall, shall not or may or could ... mean an ambigious mess.

Sorry Stephen - use all the words you like - even throw a dictionary at
me -- but 2459 + 2119 = what??    in terms of trusted, consistent
engineering ????

As said X.509 is a Standard that permits transition to using certificate
extensions for CAs and EEs  - and describes this as a local issue ..
thats pretty clear in my mind.

2459 and 2119  its unclear and ambigious - and that is the last thing
you want in an engineering PROFILE that will be used to make products
with.



regards alan

PS why are the words different in 509 Basic Contsraints to that of 2459
Basic Constraints? as they do introduce the ambiguity about EEs and what
they can do re cert validation?







> -----Original Message-----
> From:	Stephen Kent 
> Sent:	Saturday, April 10, 1999 6:29 AM
> To:	Alan Lloyd
> Cc:	[e-mail]; [e-mail]
> Subject:	RE: SEIS:  RE: Certificates, Directories, and
> Distinguished Names
> 
> Alan,
> 
> >Thats the same as 509 or near enough. Its not too informative as its
> >abstract theory rather than operational policy. Oh well.
> 
> indefinate antecedent, error ...
> 
> >
> >As a question on basic constrains why is the text in 509 different
> from
> >RFC 2459
> >
> >X.509 - 12.4.2.1 Basic Constraints
> >This field indicates if the subject may act as a CA, with the
> certified
> >public key being used to verify certificate signatures. If so, a
> >certification path length constraint may also be specified. This
> field
> >is defined as follows....
> >
> >
> >rfc 2459 -4.2.1.10  Basic Constraints
> >
> >   The basic constraints extension identifies whether the subject of
> the
> >   certificate is a CA and how deep a certification path may exist
> >   through that CA.
> >........
> >
> >   This extension MUST appear as a critical extension in all CA
> >   certificates.  This extension SHOULD NOT appear in end entity
> >   certificates.
> >
> >It strikes me that 2459 is ambigious simply because it did not
> embrase
> >the X.509 text re "certificate using system" and the fact 2459 uses
> >SHOULD NOT without actuallly defining the conditions if it is or is
> not
> >there in EE - as X.509 states.
> 
> Because 2459 requires inclusion of the extension in a CA cert, there
> is no
> ambiguity.  If a CA chose to insert the extension in an EE cert,
> despite
> the RFC's admonition, it would be redundant in the 2459 context, but
> not
> cause an error.  You should refer to RFC 2119 to gain a better
> understanding of the term "SHOULD" as used in RFCs.
> 
> steve


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id AAA17556 for ietf-pkix-bks; Sun, 11 Apr 1999 00:35:02 -0700 (PDT)
Received: from natasha1. (natasha-gw.checkpoint.com [199.203.73.129]) by mail.proper.com (8.8.8/8.8.5) with SMTP id AAA17552 for <[e-mail]>; Sun, 11 Apr 1999 00:34:59 -0700 (PDT)
Received: from cale.checkpoint.com (gray.checkpoint.com [199.203.71.94]) by cale.checkpoint.com (8.9.1/8.9.1) with ESMTP id KAA22639; Sun, 11 Apr 1999 10:37:08 +0300 (IDT)
Message-ID: <[e-mail]>
Date: Sun, 11 Apr 1999 10:33:36 +0300
From: Moshe Litvin <[e-mail]>
X-Mailer: Mozilla 4.51 [en] (WinNT; I)
X-Accept-Language: en
MIME-Version: 1.0
To: Stephen Kent <[e-mail]>, [e-mail]
Subject: Re: CA vs. EE cert processing
References: <v04020a18b331b07b2125@[128.33.238.98]> <v04020a0ab332fc3d5915@[128.33.238.98]>
Content-Type: multipart/mixed; boundary="------------8F3CCC50A7BE4CF10CB7B01D"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

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

Steve,

If PKIX mandated inclusion of basicConstraint then PKIX CA would issue
certificates that are unambiguous to every X.509v3 verifier. The verifier need
to know that the CA is a PKIX only if the certificate doesn't contain the
extension. Once the extension is in the certificate the ambiguity disappear.

PKIX chose to signal EE certificate by the absence of the extension, a way that
require out of band knowledge.

Based on this analyses I call PKIX broken. You can tell that it is X.509 fault,
but PKIX failed to fix it, when it could easily make things much better.

Mandating a basicConstraint is not the only way for removing that ambiguity.
PKIX can mandate inclusion of a keyUsage extension or of a policy OID that
specify that this is a PKIX certificate. Both of this solutions allows
processing of the certificate without out of band knowledge, but I think that
the basicConstraint way is simpler.

Moshe

Stephen Kent wrote:

> Moshe,
>
> >RFC2459 IS broken in the since the it recommends generating EE certificate
> >that
> >require out of band information to to know that it not a CA certificate.
>
> I disagree. The ambiguity arises only because X.509 allows both EE and CA
> certs to not have this extension, as my analysis shows, and because the
> verifier does not know whether a PKIX or X.509 compliant CA issued the
> cert.
>
> Steve

--------------8F3CCC50A7BE4CF10CB7B01D
Content-Type: text/x-vcard; charset=us-ascii;
 name="moshe.vcf"
Content-Transfer-Encoding: 7bit
Content-Description: Card for Moshe Litvin
Content-Disposition: attachment;
 filename="moshe.vcf"

begin:vcard 
n:Litvin;Moshe
tel;fax:[phone]
tel;work:[phone]
x-mozilla-html:TRUE
org:Check Point Software Technologies Ltd.
adr:;;;;;;
version:2.1
email;internet:[e-mail]
fn:Moshe Litvin
end:vcard

--------------8F3CCC50A7BE4CF10CB7B01D--



Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id WAA16770 for ietf-pkix-bks; Sat, 10 Apr 1999 22:17:03 -0700 (PDT)
Received: from ns.cmbchina.com ([202.96.161.112]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id WAA16762 for <[e-mail]>; Sat, 10 Apr 1999 22:17:00 -0700 (PDT)
Received: from cmbchina.com ([10.1.4.27]) by ns.cmbchina.com (Netscape Messaging Server 3.01)  with ESMTP id AAA24651 for <[e-mail]>; Sun, 11 Apr 1999 13:15:48 -0800
Message-ID: <[e-mail]>
Date: Sun, 11 Apr 1999 13:17:09 +0800
From: "Xiong Shao Jun" <[e-mail]>
Organization: China Merchants Bank
X-Mailer: Mozilla 4.04 [en] (Win95; I)
MIME-Version: 1.0
To: [e-mail]
Subject: About Diffie-Hellman algorithm and Shamir threshold
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Hi, I have two problems. The first is about Diffie-Hellman algorithm. In
PKIX part1, now
rfc2459, the algorithm is described as:

OID:    1.2.840.10046.2.1
DomainParameters ::= SEQUENCE {
        p            INTEGER, -- odd prime, p=jq+1
        g            INTEGER, -- generator, g
        q            INTEGER, -- factor of p-1
        j            INTEGER OPTIONAL, -- subgroup factor
        validationParms    ValidationParms OPTIONAL }

ValidationParms    ::= SEQUENCE {
        seed            BIT STRING
    pgenCounter   INTEGER }

while in certificate management protocol, now rfc2510, the algorithms is
described as
below:
OID:    1.2.840.10046.2.1
DHParameter ::= SEQUENCE {
        prime INTEGER, -- p
        base  INTEGER  -- g
}

So which is the most up to date description, and which should I
implement?



Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id UAA16253 for ietf-pkix-bks; Sat, 10 Apr 1999 20:31:39 -0700 (PDT)
Received: from smtp.udac.net (smtp.udac.net [193.44.79.123]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id UAA16249 for <[e-mail]>; Sat, 10 Apr 1999 20:31:37 -0700 (PDT)
Received: from caesar.udac.se (caesar.udac.se [193.44.79.10]) by smtp.udac.net (8.9.1/8.9.1) with ESMTP id FAA20621 for <[e-mail]>; Sun, 11 Apr 1999 05:31:42 +0200
Received: from mega (t4o69p116.telia.com [62.20.145.236]) by caesar.udac.se (8.7.3/NetworkC-1) with SMTP id FAA61885; Sun, 11 Apr 1999 05:31:37 +0200
Message-ID: <000601be83d3$ef054270$[e-mail]>
From: "Anders Rundgren" <[e-mail]>
To: "Stephen Kent" <[e-mail]>
Cc: <[e-mail]>, <[e-mail]>
Subject: Re: CyberPhone Trust Propagation  Was: A $25,000,000,000 PKI
Date: Sun, 11 Apr 1999 05:29:47 +0100
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.2106.4
X-MimeOLE: Produced By Microsoft MimeOLE V4.72.2106.4
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by mail.proper.com id UAA16250
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Steve,

>It is not the server that grants the user the right to purchase, it is the
>company.  The company can choose to do this in various ways, as described
>in earlier messages.  Your approach introduces added vulnerabilities into
>the system, realtive to a model in which the purchasing agent directly
>controls his/her private key.


But "your" model adds the following security problems when purchasers
that have their purchaser keys and certs in a smart card:

1) Key (card) distribution.  Make sure the right person gets it

2) A need for trust in external software when purchasing outside of the company
premises.  If at all possible for SW reasons.  And logging, what about that?

3) As it probably can take days to get a new purchaser card in case of
loss you may have to "borrow" somebody else's.  Normal human behavior

4) No control of use or abuse until it may be too late.  Non-repudian
is useless if your purchaser made your company go bankrupt



And then "your" model also adds the following PITAs

1) Slow and expensive issuing of cards

2) Hard to get a card if not physically close to the issuer


As I see it, massive issuing and distribution of private keys introduce
security problems that (unlike secure PK-servers and "Thin PKI") do not
have any real solutions.


But I will cease this debate as we are approaching "dead-lock" unless there
are others who seems willing (and competent) to continue. 

Regards
Anders

http://www.mobilephones-tng.com





Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id HAA11816 for ietf-pkix-bks; Sat, 10 Apr 1999 07:58:53 -0700 (PDT)
Received: from po1.bbn.com (PO1.BBN.COM [192.1.50.38]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id HAA11812 for <[e-mail]>; Sat, 10 Apr 1999 07:58:51 -0700 (PDT)
Received: from [128.33.238.189] (tc238-189.bbn.com [128.33.238.189]) by po1.bbn.com (8.9.1/8.9.1) with ESMTP id KAA17780; Sat, 10 Apr 1999 10:58:43 -0400 (EDT)
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
X-Sender: [e-mail] (Unverified)
Message-Id: <v04020a05b33412a03b9e@[128.33.238.86]>
In-Reply-To: <D1A949D4508DD1119C8100400533BEDC0BE978@DSG1>
Date: Fri, 9 Apr 1999 16:29:10 -0400
To: Alan Lloyd <[e-mail]>
From: Stephen Kent <[e-mail]>
Subject: RE: SEIS:  RE: Certificates, Directories, and Distinguished Names
Cc: [e-mail], [e-mail]
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Alan,

>Thats the same as 509 or near enough. Its not too informative as its
>abstract theory rather than operational policy. Oh well.

indefinate antecedent, error ...

>
>As a question on basic constrains why is the text in 509 different from
>RFC 2459
>
>X.509 - 12.4.2.1 Basic Constraints
>This field indicates if the subject may act as a CA, with the certified
>public key being used to verify certificate signatures. If so, a
>certification path length constraint may also be specified. This field
>is defined as follows....
>
>
>rfc 2459 -4.2.1.10  Basic Constraints
>
>   The basic constraints extension identifies whether the subject of the
>   certificate is a CA and how deep a certification path may exist
>   through that CA.
>........
>
>   This extension MUST appear as a critical extension in all CA
>   certificates.  This extension SHOULD NOT appear in end entity
>   certificates.
>
>It strikes me that 2459 is ambigious simply because it did not embrase
>the X.509 text re "certificate using system" and the fact 2459 uses
>SHOULD NOT without actuallly defining the conditions if it is or is not
>there in EE - as X.509 states.

Because 2459 requires inclusion of the extension in a CA cert, there is no
ambiguity.  If a CA chose to insert the extension in an EE cert, despite
the RFC's admonition, it would be redundant in the 2459 context, but not
cause an error.  You should refer to RFC 2119 to gain a better
understanding of the term "SHOULD" as used in RFCs.

steve


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id HAA11810 for ietf-pkix-bks; Sat, 10 Apr 1999 07:58:51 -0700 (PDT)
Received: from po1.bbn.com (PO1.BBN.COM [192.1.50.38]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id HAA11806 for <[e-mail]>; Sat, 10 Apr 1999 07:58:49 -0700 (PDT)
Received: from [128.33.238.189] (tc238-189.bbn.com [128.33.238.189]) by po1.bbn.com (8.9.1/8.9.1) with ESMTP id KAA17769; Sat, 10 Apr 1999 10:58:35 -0400 (EDT)
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
X-Sender: [e-mail] (Unverified)
Message-Id: <v04020a03b334098020dc@[128.33.238.86]>
In-Reply-To: <D1A949D4508DD1119C8100400533BEDC0BE977@DSG1>
Date: Fri, 9 Apr 1999 15:53:31 -0400
To: Alan Lloyd <[e-mail]>
From: Stephen Kent <[e-mail]>
Subject: RE: CA vs. EE cert processing
Cc: [e-mail]
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Alan,

>When one builds a system comprising many CA functions for different
>product domains, its likely that the key generation function is used to
>generate keys for more than one of these CA functions - however this
>approach is according to trust and operational requirements. Naturally
>the theory in this process is that the root level CA function then in
>fact signs the subordinate CA function certificate with its key and the
>sub CA also signs its certs with its own key. However, we also expect in
>this process - in terms of procedure that the root level CA could check
>components of the certificate it is signing - such as the extensions
>being applied - eg BC = CA .. and the client software used - the
>certficate using system also checks this correctly..

No argument about what the CA and relying parties should do.  Of course, in
practice the latter tend not to do all of what is nominally required.

>ie. one must also verify that if a CA is using BC = CA that the client
>has in fact verified that - again the proof of doing that is in the
>system design and implementation. ie what gives proof of path
>processing. Its all part of the system verification process - that each
>part of the PKI is coherent and trusted.

Each part is trusted relative to its functions, yes.

>My point was that X.509 states that this extension is set or not  to let
>the certificate using system determine if it can use the public key to
>validate certficates .. However, the standard also permits non extended
>certficates to be used in a system and the certificate using system to
>verify certificates  with the implicit knowledge that a cert chain does
>equal an EE cert with superior CAs.

Ah, now I see your point.  You are suggesting that while X.509 was not in
error for not requiring CAs to mark CA certs, even when they are v3 certs,
because one might build a system that relied upon the CAs, and all EEs, not
doing the wrong thing.  Note that one has to rely on all CAs and EEs since
otherwise an EE can take advantage of the lack of marking to pretend it is
a CA.  This is an unwise basis on which to build a system, from a security
perspective, and thus I do fault X.509, despite your description of a
context in which the ambuguity might be mitigated.

>My last point is that 2459 can profile X.509 say all CA certs must have
>this extension set. EE certs may have this extension set to null or not
>be there.
>
>No ambiguity as far as I am concerned.

Yes, that's right, and that's what 2459 already says.

Steve


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id HAA11804 for ietf-pkix-bks; Sat, 10 Apr 1999 07:58:40 -0700 (PDT)
Received: from po1.bbn.com (PO1.BBN.COM [192.1.50.38]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id HAA11800 for <[e-mail]>; Sat, 10 Apr 1999 07:58:39 -0700 (PDT)
Received: from [128.33.238.189] (tc238-189.bbn.com [128.33.238.189]) by po1.bbn.com (8.9.1/8.9.1) with ESMTP id KAA17772; Sat, 10 Apr 1999 10:58:40 -0400 (EDT)
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
X-Sender: [e-mail] (Unverified)
Message-Id: <v04020a04b3340ff39ac8@[128.33.238.86]>
In-Reply-To: <006c01be8250$6fe05540$[e-mail]>
Date: Fri, 9 Apr 1999 16:24:15 -0400
To: "Anders Rundgren" <[e-mail]>
From: Stephen Kent <[e-mail]>
Subject: Re: CyberPhone Trust Propagation  Was: A $25,000,000,000 PKI
Cc: <[e-mail]>, <[e-mail]>
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Anders,

<snip>

>Now to the scenarios presented on my web (Shared Certificates
>and Dynamic Certificates) that represent two much more complicated situations
>that an open environment introduce.
>
>If those scenarious introduce trust propagation it would mean that the
>intermediary
>private key server performed something on behalf of the client.  But, IT
>IS THE
>OTHER WAY AROUND!  It is the intermediary server that grants a client the
>right
>to perform a purchase on the servers behalf.  Yes, when you purchase for a
>company
>it is the company that buys.  That the purchase was initiated by the
>client does
>not change this a single bit.  A company assumes that you do your work  -
>not that it has
>to screem and shout to make you perform!  And you have in this role
>obligations
>only to your company (=server).

It is not the server that grants the user the right to purchase, it is the
company.  The company can choose to do this in various ways, as described
in earlier messages.  Your approach introduces added vulnerabilities into
the system, realtive to a model in which the purchasing agent directly
controls his/her private key.

>That is why CyberPhone does not break any (of the mostly unwritten) rules
>regarding
>key use and trust.
>
>It does though assume that a server and private keys stored on it can be
>responsible
>in the same way as a natural person.  As I wrote in another posting this
>is what is
>happening all the time (except for signatures that are not yet
>implemented) in automated
>invoicing systems so there is "Nothing new under the Sun".

Servers are not principles (a security term of art), i.e., they are not
accountable entities.  Only people are. Putting a collection of private
keys on a server creates a new opportunity for someone other than the
accountable entity (user) to cause objects to be signed on behalf of the
user.  yes, many automated systems in the current environemnt offer poor
security, such as the one you describe.  I hate to see the veneer of PKI
applied to a system that retains the many of the security problems of these
existing systems.

Steve


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id HAA11795 for ietf-pkix-bks; Sat, 10 Apr 1999 07:57:58 -0700 (PDT)
Received: from po1.bbn.com (PO1.BBN.COM [192.1.50.38]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id HAA11791 for <[e-mail]>; Sat, 10 Apr 1999 07:57:57 -0700 (PDT)
Received: from [128.33.238.189] (tc238-189.bbn.com [128.33.238.189]) by po1.bbn.com (8.9.1/8.9.1) with ESMTP id KAA17564; Sat, 10 Apr 1999 10:57:46 -0400 (EDT)
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
X-Sender: [e-mail] (Unverified)
Message-Id: <v04020a02b334080dc9b0@[128.33.238.86]>
In-Reply-To: <001801be8243$db209d40$[e-mail]>
Date: Fri, 9 Apr 1999 16:24:35 -0400
To: "Anders Rundgren" <[e-mail]>
From: Stephen Kent <[e-mail]>
Subject: Re: A $25,000,000,000 PKI   Was:Spec. on QC-low-fat & QC-heavy-bio
Cc: <[e-mail]>, <[e-mail]>
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Anders,

>
>This is it! And I am not talking about Coca-Cola :-) I am talking about
>current PKI
>schemes.   They PROMISE you a lot but when it comes to down-to-earth
>specifications on how all this is going to be performed in a cost-efficient,
>convenient and secure (handling-wise) way there is Zilch, Nada, Nothing.

Our experiences differ.  I have PKI clients who are much more positive
about current technology capabilities.

>If you do as I asked Stefan, convert the scenario presented in my paper
>"Dynamic Certificates" (
>http://www.mobilephones-tng.com/v100/dynamiccerts.html )
>to the "classical" way of doing things you will for each design decision
>create
>a lot of new hard questions.  A system that can only do "A-B" operations
>is totally insufficient for 21st century usage.  Why do SET support a
>three-party operation?
>Because an on-line account-based purchase involves (at least) three parties!

Different forms of transactions embody different models for participants.
Some are two party, some 3, some more.  I do note that SET mamages to get
by with X.509 certs under the current model.

>Regarding CyberPhone's "unethical" use of digital signatures there seems
>to be fairly
>limited consensus on your and Stefan's views.  I.e. digital signature laws
>are not
>in harmony with automated systems in any way.  My guess is that the
>lawyers will
>have to go back to the "drawing board" some day.

No doubt that more legal work is needed, but that does not mean that the
approach you favor will necessarily fare better under revised laws.

>As an example I can mention OBI that allows an order to be "Authorized" by
>signing it and sending it to the selling organization.   The authorizer can be
>a person or an automated process.  OBI is for REAL which makes a difference.
>
>Actually, CyberPhone (like SET ServerWallets and OBI) does not break away
>from PKIX at all, it just uses current PKIX technology (+ a few new
>protocols) in
>a more or less novel way that is targeted at existing and future
>commercial uses
>and business processes.

If CyberPhone does not break from the PKIX model, there cannot be a need
for changes to that model to accommodate it.  So, let's stop wasting the
time of the folks on these mailing lists.

Steve


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id LAA00919 for ietf-pkix-bks; Fri, 9 Apr 1999 11:58:17 -0700 (PDT)
Received: from gatekeeper.entrust.com (gatekeeper.entrust.com [204.101.128.170]) by mail.proper.com (8.8.8/8.8.5) with SMTP id LAA00915 for <[e-mail]>; Fri, 9 Apr 1999 11:58:16 -0700 (PDT)
Received: 	id OAA22647; Fri, 9 Apr 1999 14:54:52 -0400
Received: by gateway id <G4CA5C9Z>; Fri, 9 Apr 1999 14:57:11 -0400
Message-ID: <01E1D01C12D7D211AFC70090273D20B104F059@sothmxs06>
From: Carlisle Adams <[e-mail]>
To: "'[e-mail]'" <[e-mail]>
Cc: "'[e-mail]'" <[e-mail]>
Subject: RE: CMP message format. A naive question
Date: Fri, 9 Apr 1999 14:51:04 -0400 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.1960.3)
Content-Type: text/plain
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Hi Michael,

Which of the three questions in your e-mail was the "naive question"
referred to in the title?  :-)

> ----------
> From: 	Michael Zolotarev[SMTP:[e-mail]]
> Reply To: 	[e-mail]
> Sent: 	Wednesday, April 07, 1999 10:03 PM
> To: 	'PKIX mailing group'
> Subject: 	CMP message format. A naive question
> 
> The CMP message format can be very appropriately used  for
> non-cert-related 
> PKI services, such as TimeStamping, AttributeCertificates, DCS etc
> 
> 
> Q1. Are there any reasons (technical, patent-related, religious,...) why 
> the CMP message structure can not or should not be used for non-CMP PKI 
> services?
 
There are no reasons of which I am aware.  In fact, the original intent was
for this message structure to be generally useful to PKIX (rather than
specific to CMP), which is why we called it "PKIMessage".

> Q2. If the CMP format can be legitimately used for non-certificate 
> management protocol operations, then what would be the IDs for the new 
> PKIBody content? Has anybody sorted out or reserved the IDs above [23]?
 
Nobody has mentioned / proposed using numbers above 23 to me.  I therefore
assume that such numbers are available for use within this message
structure.

> Q3. What would be the name to use, when it is not a Cert Mgm Prot-related 
> message any longer?. "Generic PKI Message Format" (GPMF)?
 
Finding satisfactory names for things is sometimes the easiest, and
sometimes the most difficult, part of such an exercise.  Perhaps coming up
with concrete proposals for other PKIBody contents first would be
preferable.  :-)

As one example, now that PKIX is officially chartered to look at Attribute
Certificates, the group may want to consider defining PKIBody contents to
request that an Attribute Authority issue an AC containing some specific
privileges, and to carry the appropriate response.

Carlisle.



Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id LAA00465 for ietf-pkix-bks; Fri, 9 Apr 1999 11:06:12 -0700 (PDT)
Received: from stingray.missi.ncsc.mil (stingray.missi.ncsc.mil [144.51.50.20]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id LAA00461 for <[e-mail]>; Fri, 9 Apr 1999 11:06:10 -0700 (PDT)
Received: from stingray.missi.ncsc.mil (root@localhost) by stingray.missi.ncsc.mil with ESMTP id OAA09454 for <[e-mail]>; Fri, 9 Apr 1999 14:06:10 -0400 (EDT)
Received: from missi.ncsc.mil (depot.missi.ncsc.mil [144.51.60.1]) by stingray.missi.ncsc.mil with ESMTP id OAA09450 for <[e-mail]>; Fri, 9 Apr 1999 14:06:09 -0400 (EDT)
Received: from ara.missi.ncsc.mil (ara.missi.ncsc.mil [144.51.56.12]) by missi.ncsc.mil (8.8.8/8.8.8) with ESMTP id OAA17916 for <[e-mail]>; Fri, 9 Apr 1999 14:04:41 -0400 (EDT)
Received: from ara.missi.ncsc.mil (ara.missi.ncsc.mil [144.51.56.12]) by ara.missi.ncsc.mil (8.9.1b+Sun/8.9.1) with SMTP id OAA02332 for <[e-mail]>; Fri, 9 Apr 1999 14:05:43 -0400 (EDT)
Message-Id: <[e-mail]>
Date: Fri, 9 Apr 1999 14:05:43 -0400 (EDT)
From: "David P. Kemp" <[e-mail]>
Reply-To: "David P. Kemp" <[e-mail]>
Subject: Re: CA vs. EE cert processing
To: [e-mail]
MIME-Version: 1.0
Content-Type: TEXT/plain; charset=us-ascii
Content-MD5: rMi3nWck4uB5FyofofayEw==
X-Mailer: dtmail 1.3.0 CDE Version 1.3 SunOS 5.7 sun4u sparc 
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

> From: [e-mail]
> 
> It's purely deterministic.  If PKIX mandated the presence of the
> basicConstraints extension, then a verifier could, without any
> outside knowledge, immediately categorize a certificate as
> "CA cert", "EE cert" or "Unknown (and not PKIX-compliant)".

A verifier doesn't need to categorize a particular certificate,
it needs to validate a path.  You are proposing to change the
requirements on EE certs; CA certs are *unaffected* by the proposal.
It doesn't make any difference to the verifier whether the last
cert in a path is definitely an EE, definitely a CA, or unknown.
All that matters is that every cert but the last is definitely
a CA, and requiring a CA=false flag in every EE cert does not
affect the validity of the path.

Software which returns either "valid" or "invalid" when presented
with a path containing ambiguous certs will not change its behavior,
regardless of whether EE cert requirements are changed.



> If they pick (ii), then PKIX would be fine whether or not we required
> basicConstraints in EE certs, and the ambiguity would slowly vanish as
> systems that generate un-extended CA certs come into compliance with
> X.509.  However, even V1 certs haven't yet vanished from the world,
> so I imagine this process is likely to take a long time, so having all
> PKIX certs contain the extension is still a win as it eliminates the
> ambiguity immediately.

Why do you assume that putting the extension into CA certs in response to
a change in X.509 would take a long time, but that putting it into EE
certs in response to a change in PKIX would happen immediately?
There are a lot fewer of the former.  And though we might not wish to
believe it, there might be people out there who use X.509 but not the PKIX
profile :-).  Picking option (ii) would help everyone, not just those in
the Internet universe.


> It seems that in all cases, having PKIX generate certificates
> that are unambiguous under today's X.509 is worthwhile.

How much current software would be helped by changing the requirements
on EE certs (i.e. would magically start behaving differently if PKIX
were modified)?

  My answer: none.

How would changing PKIX affect the development of new verifying software
(i.e. what would new software do differently if PKIX is changed vs.
not changed, recognizing that up to 3 types of certs -
non-RFC2459 X.509, RFC2459, and new-modified-PKIX - will be around
for a while)?

  My answer: nothing.



Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id GAA27872 for ietf-pkix-bks; Fri, 9 Apr 1999 06:57:49 -0700 (PDT)
Received: from epic.iris.com (epic.iris.com [198.112.211.21]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id GAA27867 for <[e-mail]>; Fri, 9 Apr 1999 06:57:45 -0700 (PDT)
From: [e-mail]
Subject: Re: CA vs. EE cert processing
To: Stephen Kent <[e-mail]>
Cc: Moshe Litvin <[e-mail]>, [e-mail]
Date: Fri, 09 Apr 1999 13:58:10 GMT
Message-ID: <[e-mail]>
X-Priority: 3 (Normal)
X-MIMETrack: Serialize by Router on Epic/Iris(Daily Build (based on 166.1)|Apr  6 1999) at 04/09/99 10:00:02 AM
MIME-Version: 1.0
Content-type: text/plain; charset=us-ascii
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Steve Kent writes:

>>> The ambiguity exists in ALL verifiers, PKIX or not.  Thus pointing
>>> the finger at PKIX is not rational.
>>>
>>
>>The ambiguity does exist in ALL verifiers, but it doesn't exist in all
CA's. A
>>CA that follows PKIX creates ambiguous certificates. Only CA that does
does
>>something that it SHOULD NOT do create unambiguous certificates. Here
pointing
>>the finger at PKIX is very rational.
>>
>>We cannot remove the possibility of ambiguity but we can generate
certificates
>>that are not affected by it.
>
>I agree that a CA could put the extension in all certs and thus be able to
>say "not my fault; I did what I could."  But this does not address the
>verifier problem in other than a heuristic fashion.  I want to
>deterministic solution to the problem, and the suggested change to 2459
>does not yield that.

It's purely deterministic.  If PKIX mandated the presence of the
basicConstraints extension, then a verifier could, without any
outside knowledge, immediately categorize a certificate as
"CA cert", "EE cert" or "Unknown (and not PKIX-compliant)".  For
certificates that fall into one of the first two categories,
the certificate would be processed accordingly; for a
certificate in the "unknown" category, the verifier gets to
chose whether to consider the cert as an EE or CA cert, possibly
based on out-of-band information, but may also chose to reject
it (if it is only interested in talking with PKIX-compliant
systems).

If PKIX doesn't mandate the presence of the basicConstraints extension,
then a verifier can't distinguish between a PKIX-complaint EE cert and
a non-PKIX compliant CA cert that has chosen not to use the extension.


Assuming that we file a DR against X.509, then as I see it the X.509
committee has several choices:

i)  Decide that X.509 is fine as-is, and make no change.

ii) Add clarifying text that defines that certificates without a
    basicConstraints extension should be considered to be EE certs.

iii) Mandate that EE certs omit the basicConstraints extension and that
     it is present and critical in CA certs.

iv) Mandate that the basicContraints extension be present in all certs.



If they pick (i), then changing PKIX to require the extension is the
only way to generate certs that are unambiguous to a verifier.
Reducing the impact of the ambiguity is progress, even if it can't
be eliminated altogether, and at least PKIX-compliant certificates
won't trigger it.

If they pick (ii), then PKIX would be fine whether or not we required
basicConstraints in EE certs, and the ambiguity would slowly vanish as
systems that generate un-extended CA certs come into compliance with
X.509.  However, even V1 certs haven't yet vanished from the world,
so I imagine this process is likely to take a long time, so having all
PKIX certs contain the extension is still a win as it eliminates the
ambiguity immediately.

If they pick (iii), the current PKIX spec will be fine (once newly
non-complaint X.509 certs vanish from the world), and a PKIX spec
that mandated the use of basicConstraints in EE certs would be
non-compliant.  However, this would be a non-backwards-compatible
change to X.509, and so if this option were taken, then it would
probably require an accompanying change to the certificate version
number.  For this reason alone, I think this option is unlikely to
be chosen.  A half-way position would be to recommend that EE certs
omit the extension, but to permit verifiers to accept EE certs with
the extension set.  In this case, either flavor of PKIX would be
fine, although having all PKIX certs contain the extension is still
a win as it eliminates the ambiguity immediately.

If they pick (iv), then the current PKIX profile will be non-compliant,
and PKIX will continue to generate certificates that X.509 deems to
be ambiguous.  The proposed change to PKIX would generate certificates
that are compliant with both current X.509 and the new X.509.



It seems that in all cases, having PKIX generate certificates
that are unambiguous under today's X.509 is worthwhile.


I must say, I'm suprised that there is disagreement over this, since
writing a profile to avoid ambiguous areas of its parent spec seems
so fundamental that I must be missing something.  The only down-side
I can see to requiring the extension in all certs is that it costs
a few extra bytes.  There's no significant number of deployed PKIX
systems, so compatibility isn't a major issue (and the proposed
change wouldn't break compatibility anyway, as verifiers would
still have the option of treating non-extended certs as EE certs).


John



Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id GAA27517 for ietf-pkix-bks; Fri, 9 Apr 1999 06:11:21 -0700 (PDT)
Received: from www.fnmt.es (www.fnmt.es [194.224.27.14]) by mail.proper.com (8.8.8/8.8.5) with SMTP id GAA27513 for <[e-mail]>; Fri, 9 Apr 1999 06:11:19 -0700 (PDT)
Received: from dnsp.epc.fnmt.es (dnsp.epc.fnmt.es [193.149.3.17]) by www.fnmt.es (NTMail 3.02.13) with ESMTP id ya023762 for <[e-mail]>; Fri, 9 Apr 1999 15:06:22 +0100
Message-ID: <01c901be828a$4192f3c0$[e-mail]>
From: "=?iso-8859-1?Q?Juan_Luis_L=F3pez?=" <[e-mail]>
To: <[e-mail]>
Cc: <[e-mail]>
Subject: RE: Time Stamp: tsa field in TSTInfo
Date: Fri, 9 Apr 1999 15:09:47 +0200
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 8bit
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
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Michael,

I am not sure about what you want to say. The core time stamp information
(TSTInfo) needs to be signed by the tsa in order to have a proof of
existence value otherwise is valueless and that information TSTInfo should
not be trusted.

If you are saying that some other authority interprets an originally signed
time stamp token and extends its trust to its users by adding it to its own
structures, then the later authority should verify the signed token and thus
discovering in the process the identity of the former tsa. If that authority
wished to include information about time-stamp's origin into its structures
it could just retrieve that information from signature verification process
and simply add it together with the TSTInfo, as a new field.

Did I manage to understand you?

Juan Luis
    ------------------------------------------------------------------------
-------------
Juan Luis López                                              <[e-mail]>
Project Engineer
http://www.fnmt.es/pkits
Fábrica Nacional de Moneda y Timbre             tel: [+34] 91 506 48 40
C/ Juan de Mariana, 17                                  fax: [+34] 91 506 48
51
E-28045 Madrid, SPAIN

-----Mensaje original-----
De: Michael Zolotarev <[e-mail]>
Para: 'Robert Zuccherato' <[e-mail]>; 'Juan Luis Lopez'
<[e-mail]>
CC: '[e-mail]' <[e-mail]>
Fecha: jueves 8 de abril de 1999 2:28
Asunto: RE: Time Stamp: tsa field in TSTInfo


>The core time stamp information can be used indirectly, as a field inside
>some third party WhateverService (WS) structure. Even (!) if this WS
>structure gets signed/ enveloped, the signer is not going to be the TSA.
>DCS as it stands now may serve as an example.
>
>So, having tsa inside the TSTInfo may come as a useful thing - the WS
>clients may still want to know the TimeStamp's origin.
>
>Michael Zolotarev
>Technical Architect
>Baltimore Technologies Limited (Australia)
>



Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id CAA19762 for ietf-pkix-bks; Fri, 9 Apr 1999 02:59:04 -0700 (PDT)
Received: from smtp.bankinter.es (dns.bankinter.es [195.235.30.34]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id CAA19753 for <[e-mail]>; Fri, 9 Apr 1999 02:59:01 -0700 (PDT)
Received: from nexo.es (h028153.nexo.es [195.235.28.153]) by smtp.bankinter.es (8.8.8+Sun/8.8.8) with ESMTP id LAA26811; Fri, 9 Apr 1999 11:56:37 +0200 (MET DST)
Message-ID: <[e-mail]>
Date: Fri, 09 Apr 1999 11:58:42 +0200
From: Manuel Heras Gilsanz <[e-mail]>
X-Mailer: Mozilla 4.5 [en] (Win95; I)
X-Accept-Language: en
MIME-Version: 1.0
To: Denis Pinkas <[e-mail]>
CC: "[e-mail]" <[e-mail]>, [e-mail]
Subject: Re: Time-Stamp: Why not use several hashes?
References: <[e-mail]> <[e-mail]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Denis,

Re-time-stamping *requires* cooperation from the user. Re-signing can be
performed by the TSA without user cooperation. Therefore the document and the
signature hashes do not demand the same "contingency planning".
The thing is, most users will time-stamp their documents and then forget to keep
track of the cryptographic advances. If the TSA finds itself unable to contact
some user, it will be unable to re-time-stamp the document; on the other, if a
new signature algorithm were needed, a renewed time-stamp could be obtained even
if the user were having holidays in Bahamas, with the mobile phone switched off.

On yet another hand, if the TSA implements some linking protocol in which
several hashes are used, then there is no need to re-issue tokens whose
signature hashes are broken. The TSA can again take appropriate measures without
the user cooperation.

Best regards,

    - Manuel -

Denis Pinkas wrote:

> Manuel,
>
> We want to keep the protocol simple. The threat you mention can be countered
> by another way: re-time-stamp later on with a new hash function. If SHA-1
> gets broken one day, this will not happen in just one day. Some
> cryptographer will first find some weaknesses before you can really forge a
> meaningfull message that has the same hash. So you get some time for
> re-stamping.
>
> If this argument were used, then we should sign TWICE, i.e.  in case one
> digital signature algorithm was broken. We do not do that. There is no
> reason to do it for the hash function.
>
> Regards,
>
> Denis
>
> > Hi.
> >
> > In the (now expired) latest PKIX draft on time-stamping protocols from
> > Sept. 23, 1998, time-stamp requests and tokens support the insertion of
> > a single message imprint.
> >
> > I think several message imprints should be supported. If a hash
> > algorithm were broken, time-stamp tokens using it (as the single message
> > imprint) would have to be regarded invalid (even if some kind of linking
> > mechanism were implemented!). If several hashes had been used, the token
> > would still be valid, and it could be promptly renewed in order to
> > prevent invalidation should further advances in cryptography render
> > other hashes obsolete!
> >
> > (One must be careful here: there are different extents to which a hash
> > algorithm could be broken; in Appendix A of  PKITS-D3
> > [http://www.fnmt.es/pkits] there is an interesting analysis of the
> > implications that the different kinds of hash failures would have on the
> > time-stamping process.)
> >
> > Of course the requirements on the time-stamp verification process would
> > also have be modified to require ("MUST" level) *all* the hashes to
> > correctly verify in order to regard the corresponding time-stamp token
> > valid.
> >
> > Best regards,
> >
> >     - Manuel -
> >
> > ----
> > Manuel Heras-Gilsanz ([e-mail])
> > Independent Security Consultant
> > Phone: [phone]



Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id CAA19391 for ietf-pkix-bks; Fri, 9 Apr 1999 02:56:04 -0700 (PDT)
Received: from edelweb.fr (edelweb.fr [193.51.12.16]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id CAA19384 for <[e-mail]>; Fri, 9 Apr 1999 02:56:03 -0700 (PDT)
Received: from champagne.edelweb.fr (localhost.edelweb.fr [127.0.0.1]) by edelweb.fr with ESMTP id LAA25965; Fri, 9 Apr 1999 11:55:52 +0200 (MET DST)
Received: from champagne.edelweb.fr (champagne.edelweb.fr [193.51.14.161]) by edelweb.fr (nospam/1.1); Fri, 9 Apr 1999 11:55:52 +0200 (MET DST)
Received: from emeriau.edelweb.fr (emeriau.edelweb.fr [193.51.14.5]) by champagne.edelweb.fr (8.6.10/8.6.6) with ESMTP id LAA16567; Fri, 9 Apr 1999 11:55:51 +0200
From: Peter Sylvester <[e-mail]>
Received: (sylvest@localhost) by emeriau.edelweb.fr (8.6.10/8.6.6) id LAA06045; Fri, 9 Apr 1999 11:55:51 +0200
Date: Fri, 9 Apr 1999 11:55:51 +0200
Message-Id: <[e-mail]>
To: [e-mail], [e-mail]
Subject: Re: Time Stamp: tsa field in TSTInfo
Cc: [e-mail]
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

> Generally speaking, I  am not found of too many OPTIONS. Whenever we can avoid
> one, we should: this is much easier for interoperability testing. In that case I
> would favour the mandatory support of the authenticated attribute from ESS and
> suppress the name from the content of the token.
> 

I second that; a value that can occur in two places has
the tendancy to be misused. Someone might come up with
the idea of both places with a different name. 

Somehow this reminds me to alternate names in certificates :-) 

Peter Sylvester

 


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id CAA16741 for ietf-pkix-bks; Fri, 9 Apr 1999 02:02:29 -0700 (PDT)
Received: from edelweb.fr (edelweb.fr [193.51.12.16]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id CAA16737 for <[e-mail]>; Fri, 9 Apr 1999 02:02:27 -0700 (PDT)
Received: from champagne.edelweb.fr (localhost.edelweb.fr [127.0.0.1]) by edelweb.fr with ESMTP id LAA23204; Fri, 9 Apr 1999 11:02:16 +0200 (MET DST)
Received: from champagne.edelweb.fr (champagne.edelweb.fr [193.51.14.161]) by edelweb.fr (nospam/1.1); Fri, 9 Apr 1999 11:02:15 +0200 (MET DST)
Received: from emeriau.edelweb.fr (emeriau.edelweb.fr [193.51.14.5]) by champagne.edelweb.fr (8.6.10/8.6.6) with ESMTP id LAA15790; Fri, 9 Apr 1999 11:02:14 +0200
From: Peter Sylvester <[e-mail]>
Received: (sylvest@localhost) by emeriau.edelweb.fr (8.6.10/8.6.6) id LAA06001; Fri, 9 Apr 1999 11:02:14 +0200
Date: Fri, 9 Apr 1999 11:02:14 +0200
Message-Id: <[e-mail]>
To: [e-mail], [e-mail], [e-mail]
Subject: optional fields in time stamp responses.
Cc: [e-mail]
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

It seems to me that a lot of fields in a time stamp response
or dcs response can be avoided by using signed/authenticated
attributes. 

For example the time can be replaced by a signing time attribute.

In general I believe that an attribute that contains a cms
document plus a description/pointer would be very useful:

- The responses from TDAs are just signed documents.

- You want to include DCS token cpkc for your signature
  cert and another for possession of data in the signature
  of the data. 

- In an ess three way signed/encrypted/signed structure, one
  might add a dcs validation response for the encryption
  cert to indicate that the recipients dcs server 'authorisation'
  to use the encryption key. 

Otherwise each application protocol like time stamping or dcs can 
define its own oid (which would be necessary anyway for oscp
responses).

Thoughts?
PS
  
 
 


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id BAA16571 for ietf-pkix-bks; Fri, 9 Apr 1999 01:41:41 -0700 (PDT)
Received: from clbull.frcl.bull.fr (clbull.frcl.bull.fr [129.182.1.20]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id BAA16567 for <[e-mail]>; Fri, 9 Apr 1999 01:41:38 -0700 (PDT)
Received: from k2.frcl.bull.fr (k2.frcl.bull.fr [129.182.100.2]) by clbull.frcl.bull.fr (8.9.1a/8.9.1) with ESMTP id KAA19546; Fri, 9 Apr 1999 10:41:31 +0200
Received: from bull.net (frcls6118.frcl.bull.fr [129.182.109.213]) by k2.frcl.bull.fr (AIX4.2/UCB 8.7/8.7) with ESMTP id KAA42628; Fri, 9 Apr 1999 10:41:31 +0200 (DFT)
Message-ID: <[e-mail]>
Date: Fri, 09 Apr 1999 10:41:40 +0200
From: Denis Pinkas <[e-mail]>
Organization: Bull
X-Mailer: Mozilla 4.06 [fr] (Win95; I)
MIME-Version: 1.0
To: Manuel Heras Gilsanz <[e-mail]>
CC: "[e-mail]" <[e-mail]>, [e-mail]
Subject: Re: Time-Stamp: Why not use several hashes?
References: <[e-mail]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Manuel,

We want to keep the protocol simple. The threat you mention can be countered
by another way: re-time-stamp later on with a new hash function. If SHA-1
gets broken one day, this will not happen in just one day. Some
cryptographer will first find some weaknesses before you can really forge a
meaningfull message that has the same hash. So you get some time for
re-stamping.

If this argument were used, then we should sign TWICE, i.e.  in case one
digital signature algorithm was broken. We do not do that. There is no
reason to do it for the hash function.

Regards,

Denis


> Hi.
>
> In the (now expired) latest PKIX draft on time-stamping protocols from
> Sept. 23, 1998, time-stamp requests and tokens support the insertion of
> a single message imprint.
>
> I think several message imprints should be supported. If a hash
> algorithm were broken, time-stamp tokens using it (as the single message
> imprint) would have to be regarded invalid (even if some kind of linking
> mechanism were implemented!). If several hashes had been used, the token
> would still be valid, and it could be promptly renewed in order to
> prevent invalidation should further advances in cryptography render
> other hashes obsolete!
>
> (One must be careful here: there are different extents to which a hash
> algorithm could be broken; in Appendix A of  PKITS-D3
> [http://www.fnmt.es/pkits] there is an interesting analysis of the
> implications that the different kinds of hash failures would have on the
> time-stamping process.)
>
> Of course the requirements on the time-stamp verification process would
> also have be modified to require ("MUST" level) *all* the hashes to
> correctly verify in order to regard the corresponding time-stamp token
> valid.
>
> Best regards,
>
>     - Manuel -
>
> ----
> Manuel Heras-Gilsanz ([e-mail])
> Independent Security Consultant
> Phone: [phone]



Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id BAA16251 for ietf-pkix-bks; Fri, 9 Apr 1999 01:12:21 -0700 (PDT)
Received: from clbull.frcl.bull.fr (clbull.frcl.bull.fr [129.182.1.20]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id BAA16247 for <[e-mail]>; Fri, 9 Apr 1999 01:12:17 -0700 (PDT)
Received: from k2.frcl.bull.fr (k2.frcl.bull.fr [129.182.100.2]) by clbull.frcl.bull.fr (8.9.1a/8.9.1) with ESMTP id KAA15386; Fri, 9 Apr 1999 10:12:08 +0200
Received: from bull.net (frcls6118.frcl.bull.fr [129.182.109.213]) by k2.frcl.bull.fr (AIX4.2/UCB 8.7/8.7) with ESMTP id KAA41266; Fri, 9 Apr 1999 10:12:09 +0200 (DFT)
Message-ID: <[e-mail]>
Date: Fri, 09 Apr 1999 10:12:17 +0200
From: Denis Pinkas <[e-mail]>
Organization: Bull
X-Mailer: Mozilla 4.06 [fr] (Win95; I)
MIME-Version: 1.0
To: Robert Zuccherato <[e-mail]>
CC: [e-mail]
Subject: Re: Time Stamp: tsa field in TSTInfo
References: <01E1D01C12D7D211AFC70090273D20B112BD90@sothmxs06>
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 8bit
Content-Transfer-Encoding: 8bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Robert,

> Okay, I will make the tsa name optional as well.  However, it MUST be
> present if the authenticated attribute from ESS is not included.  I think
> that since time stamp tokens will be used as evidence in support of
> non-repudiation, there should be some identification of the TSA within the
> signed part of the token.

Generally speaking, I  am not found of too many OPTIONS. Whenever we can avoid
one, we should: this is much easier for interoperability testing. In that case I
would favour the mandatory support of the authenticated attribute from ESS and
suppress the name from the content of the token.

Regards,

Denis


>
> > ----------
> > From:         Denis Pinkas[SMTP:[e-mail]]
> > Sent:         Thursday, April 08, 1999 6:16 AM
> > To:   Peter Sylvester
> > Cc:   [e-mail]; [e-mail]; [e-mail]
> > Subject:      Re: Time Stamp: tsa field in TSTInfo
> >
> > Peter,
> >
> > I concur with your proposal, ie. use an signed (also called
> > "authenticated")
> > attribute from ESS that indicates the certificate used by the TSA and
> > suppress the
> > name of the TSA from the signed structure. This "useful" attribute is
> > indeed in
> > ESS, not CMS - where it should have been. :-(
> >
> > Since the verifier will need anyway to get that certificate to verify the
> > signature, then, at that time, it will get the name of the TSA.
> >
> > Regards,
> >
> > Denis
> >
> >
> > > >
> > > > Actually, I believe that when using CMS only the content (in this case
> > > > TSTInfo) is signed along with any authenticated attributes.  Thus, the
> > > > distinguishing information for the TSA would not be signed if it was
> > not
> > > > included within the TSTInfo structure.
> > > If the TST provider want to surely indicate its identity, one
> > > can use an ess signing certificate attribute.
> > >
> > > This seems preferable to me (if the tendancy is avoid to reinvent
> > things).
> > >
> > > The ess stuff was probably not avaiable at the time when
> > > the tst draft was written for the first time.
> > >
> > >
> > > >
> > > >       Robert.
> > > >
> > > > > ----------
> > > > > From:       Juan Luis López[SMTP:[e-mail]]
> > > > > Sent:       Wednesday, April 07, 1999 5:25 AM
> > > > > To:         pkix
> > > > > Subject:    Time Stamp: tsa field in TSTInfo
> > > > >
> > > > >     Hi everybody!
> > > > >
> > > > >     I am involved in a Time Stamping project and we are analysing
> > the PKIX
> > > > > draft about this subject.
> > > > >
> > > > >     I would like to give my opinion on an issue to the list:
> > > > >     It seems not appropriate to include a field in TSTInfo structure
> > > > > related to the tsa identity, i.e. tsa field. I don't find this field
> > > > > necessary because it is repeated when using a CMS or PKCS#7 envelope
> > to
> > > > > encapsulate the token information. This information would be
> > redundant
> > > > > since an identifier distinguishing the given tsa should be present
> > in the
> > > > > signerInfo structure.
> > > > >
> > > > >     So, I recommend the deletion of this field.
> > > > >
> > > > >     Regards,
> > > > >    Juan Luis López
> > > > >
> > > > >
> > > > >
> > > > >
> > --------------------------------------------------------------------------
> > > > > -----------
> > > > > Juan Luis López                                              <
> > > > > [e-mail]>
> > > > > Project Engineer
> > > > > http://www.fnmt.es/pkits
> > > > > Fábrica Nacional de Moneda y Timbre             tel: [+34] 91 506 48
> > 40
> > > > > C/ Juan de Mariana, 17                                  fax: [+34]
> > 91 506
> > > > > 48 51
> > > > > E-28045 Madrid, SPAIN
> > > > >
> > > >
> >



Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id AAA15192 for ietf-pkix-bks; Fri, 9 Apr 1999 00:46:59 -0700 (PDT)
Received: from dsg1.OpenDirectory.com.au ([203.108.249.145]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id AAA15177 for <[e-mail]>; Fri, 9 Apr 1999 00:46:52 -0700 (PDT)
Received: by DSG1 with Internet Mail Service (5.0.1458.49) id <22ZNQL99>; Fri, 9 Apr 1999 17:46:22 +1000
Message-ID: <D1A949D4508DD1119C8100400533BEDC0BE978@DSG1>
From: Alan Lloyd <[e-mail]>
To: "'Stephen Kent'" <[e-mail]>
Cc: [e-mail], [e-mail]
Subject: RE: SEIS:  RE: Certificates, Directories, and Distinguished Names
Date: Fri, 9 Apr 1999 17:46:20 +1000
X-Priority: 3
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.0.1458.49)
Content-Type: text/plain
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Thats the same as 509 or near enough. Its not too informative as its
abstract theory rather than operational policy. Oh well.


As a question on basic constrains why is the text in 509 different from
RFC 2459

X.509 - 12.4.2.1 Basic Constraints
This field indicates if the subject may act as a CA, with the certified
public key being used to verify certificate signatures. If so, a
certification path length constraint may also be specified. This field
is defined as follows....


rfc 2459 -4.2.1.10  Basic Constraints

   The basic constraints extension identifies whether the subject of the
   certificate is a CA and how deep a certification path may exist
   through that CA.
........

   This extension MUST appear as a critical extension in all CA
   certificates.  This extension SHOULD NOT appear in end entity
   certificates.

It strikes me that 2459 is ambigious simply because it did not embrase
the X.509 text re "certificate using system" and the fact 2459 uses
SHOULD NOT without actuallly defining the conditions if it is or is not
there in EE - as X.509 states.

regards alan

> -----Original Message-----
> From:	Stephen Kent 
> Sent:	Friday, April 09, 1999 10:30 AM
> To:	Alan Lloyd
> Cc:	[e-mail]; [e-mail]
> Subject:	SEIS:  RE: Certificates, Directories, and Distinguished
> Names
> 
> --- Message on the SEIS mailing list ([e-mail])
> 
> Alan,
> 
> >
> >In addition - who will own the root level key for all this PKIX
> >compliant stuff?
> 
> PKIX does not assume any single root CA in its model. See section 6.1
> of
> 2459 for its discussion of starting points for cert path validation.
> 
> Steve
> 
> 
> ----------------- SEIS mailing list ([e-mail])
> Info about this list: http://www.nc-forum.com/seis
> SEIS Contact: [e-mail]


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id AAA12589 for ietf-pkix-bks; Fri, 9 Apr 1999 00:18:48 -0700 (PDT)
Received: from www.fnmt.es (www.fnmt.es [194.224.27.14]) by mail.proper.com (8.8.8/8.8.5) with SMTP id AAA12585 for <[e-mail]>; Fri, 9 Apr 1999 00:18:47 -0700 (PDT)
Received: from dnsp.epc.fnmt.es (dnsp.epc.fnmt.es [193.149.3.17]) by www.fnmt.es (NTMail 3.02.13) with ESMTP id va023551 for <[e-mail]>; Fri, 9 Apr 1999 09:13:51 +0100
Message-ID: <007001be8258$db187a60$[e-mail]>
From: "Juan G. de la Vega" <[e-mail]>
To: "Robert Zuccherato" <[e-mail]>, "'Denis Pinkas'" <[e-mail]>
Cc: <[e-mail]>
Subject: RE: Time Stamping: comments on nonce field
Date: Fri, 9 Apr 1999 09:16:15 +0200
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 8bit
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
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

That´s fine.

-----Mensaje original-----
De: Robert Zuccherato <[e-mail]>
Para: Robert Zuccherato <[e-mail]>; 'Denis Pinkas'
<[e-mail]>
CC: [e-mail] <[e-mail]>; 'Juan G. de la Vega'
<[e-mail]>
Fecha: jueves 8 de abril de 1999 17:30
Asunto: RE: Time Stamping: comments on nonce field


Okay.  I will make it optional in both the request and response.

> ----------
> From: Denis Pinkas[SMTP:[e-mail]]
> Sent: Thursday, April 08, 1999 6:10 AM
> To: Robert Zuccherato
> Cc: [e-mail]; 'Juan G. de la Vega'
> Subject: Re: Time Stamping: comments on nonce field
>
> Robert,
>
> Some refinements to your response.
>
> The nonce is there for systems that do not have their own reliable clock
> and
> thus cannot test the freshness of the response by simply looking at the
> signing
> time. This is a replay protection. This has nothing to do whether a hash
> of the
> message is or is not present.
>
> I would make it OPTIONAL both in the request and in the response and
> maintain
> the current text that says: " ...must be present if the similar field in
> TimeStampReq is present ..."
>
> Regards,
>
> Denis
>
>
> > > ----------
> > > From:         Juan G. de la Vega[SMTP:[e-mail]]
> > > Sent:         Wednesday, April 07, 1999 5:39 AM
> > > To:   [e-mail]
> > > Subject:      Time Stamping: comments on nonce field
> > >
> > >         First of all, the declaration of this field in the request and
> > > token is somehow incoherent, while the nonce is mandatory in
> TimeStapReq
> > > (it is not declared OPTIONAL), the TimeStampToken´s nonce is OPTIONAL
> but
> > > it is stated that "...must be present if the similar field in
> TimeStampReq
> > > is present..." and hence the clause OPTIONAL is meaningless and
> confusing
> > > for this field shall always be present.
> > >
> > As I have said in the past, this was a mistake that I made because I did
> not
> > manage to fully include support for TSA production of a "signed time".
> This
> > would be a token which does not include a nonce or message imprint.
> TSA's
> > could produce these tokens and make them available (for example on a
> > website) for anyone who wants to obtain them.  This will be rectified in
> the
> > upcoming draft.
> >
> > > I would suggest this field to be declared OPTIONAL both in the request
> and
> > > token or better deleted if we take into account the following:
> > >
> > >     As far as I understand, a nonce value is present in the request
> and
> > > token in order for the requester to be able to match the responses
> from
> > > the TSA with her requests when using an asynchronous transport. It can
> be
> > > argued that such functionality should be left to the transport layer
> when
> > > required, but furthermore I must say that the nonce is not necessary
> since
> > > matching can be performed using the "messageImprint" field.
> > >
> > Actually, the reason that the nonce is there and mandatory is to prevent
> > replay attacks.  Someone else could have obtained a time stamp on the
> data
> > before your request.  Thus, it is possible that the time stamp you
> received
> > is not "fresh".  Without a nonce, determining the freshness of the
> timestamp
> > is difficult.
> >
> >         Robert.
>



Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id AAA11970 for ietf-pkix-bks; Fri, 9 Apr 1999 00:03:05 -0700 (PDT)
Received: from www.fnmt.es ([193.149.2.14]) by mail.proper.com (8.8.8/8.8.5) with SMTP id AAA11966 for <[e-mail]>; Fri, 9 Apr 1999 00:03:03 -0700 (PDT)
Received: from dnsp.epc.fnmt.es (dnsp.epc.fnmt.es [193.149.3.17]) by www.fnmt.es (NTMail 3.02.13) with ESMTP id ba023531 for <[e-mail]>; Fri, 9 Apr 1999 08:58:09 +0100
Message-ID: <005801be8256$aa206280$[e-mail]>
From: "Juan G. de la Vega" <[e-mail]>
To: "Denis Pinkas" <[e-mail]>, "Robert Zuccherato" <[e-mail]>
Cc: <[e-mail]>
Subject: RE: Time Stamping: comments on nonce field
Date: Fri, 9 Apr 1999 09:00:33 +0200
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 8bit
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
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

-----Mensaje original-----
De: Denis Pinkas <[e-mail]>
Para: Robert Zuccherato <[e-mail]>
CC: [e-mail] <[e-mail]>; 'Juan G. de la Vega'
<[e-mail]>
Fecha: jueves 8 de abril de 1999 13:06
Asunto: Re: Time Stamping: comments on nonce field


>I would make it OPTIONAL both in the request and in the response and
maintain
>the current text that says: " ...must be present if the similar field in

>TimeStampReq is present ..."


Completely agreed.

Juan.
____________________________________________
Juan González-de-la-Vega
Software Engineer
e-mail: <[e-mail]>
FNMT - Fábrica Nacional de Moneda y Timbre
Phone: [phone].
Fax: [phone]




Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id XAA11911 for ietf-pkix-bks; Thu, 8 Apr 1999 23:58:51 -0700 (PDT)
Received: from www.fnmt.es ([193.149.2.14]) by mail.proper.com (8.8.8/8.8.5) with SMTP id XAA11907 for <[e-mail]>; Thu, 8 Apr 1999 23:58:50 -0700 (PDT)
Received: from dnsp.epc.fnmt.es (dnsp.epc.fnmt.es [193.149.3.17]) by www.fnmt.es (NTMail 3.02.13) with ESMTP id xa023527 for <[e-mail]>; Fri, 9 Apr 1999 08:53:54 +0100
Message-ID: <004f01be8256$12164400$[e-mail]>
From: "Juan G. de la Vega" <[e-mail]>
To: "Robert Zuccherato" <[e-mail]>, <[e-mail]>
Subject: RE: Time Stamping: comments on nonce field
Date: Fri, 9 Apr 1999 08:56:16 +0200
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 8bit
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
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Hi again,

-----Mensaje original-----
De: Robert Zuccherato <[e-mail]>
Para: [e-mail] <[e-mail]>; 'Juan G. de la Vega'
<[e-mail]>
Fecha: miércoles 7 de abril de 1999 19:06
Asunto: RE: Time Stamping: comments on nonce field

>Actually, the reason that the nonce is there and mandatory is to prevent
>replay attacks.  Someone else could have obtained a time stamp on the data
>before your request.  Thus, it is possible that the time stamp you received
>is not "fresh".  Without a nonce, determining the freshness of the
timestamp
>is difficult.
Now, I have get it right.

Freshness of a time stamp is a delicate issue. Theoretically, replay can be
avoided by adding some information provided by the requester to the request,
this added info must be processed by the server and the result returned in
the response in a way that authenticates that server "at that moment" (with
regard to the matching request).

    In our case the "server process" roughly consists of adding the actual
time and signing the bunch, and the added information provided by the
requester can be the hash value (one-way, collision resistant and 2^128
possibilities being a very large range). As I said in the prev. message,
only when there is no hash value the nonce becomes neccessary to defeat
replay.

In relation to this, the scenario you depict seems odd to me; if someone
else had my data before I want to time-stamp it, I already have a bigger
problem, if the data are public and I still want to time-stamp it, a replay
attack would mean that someone would provide me with a signed token that
backdates (in regard to me) the data I possess (umm!, interesting in some
cases... just kidding: I agree with you that an additional mechanism would
fit in this case).

If you mean that a previous message of mine could have been intercepted in
transit and someone else has my hash value (not my data), we have a branch
here:

    1) Passive eavesdropping: I have the token returned from the TSA. The
reason for me to restamp my data is token renewal, but in this case the
messageImprints field will be different from the old request since the token
should be tied to the document and hashed together in order to transitively
extend the validity of the time stamp from the past to the present.

    2)Interception: If I later try to stamp the data and replay-attacked I
will get the original time when I first wanted to time stamp it. I woudn´t
attack that way but simply would intercept all messages (An additional
replay mechanism?).

What I am trying to say is that freshness of a time stamp is not
neccessarily related to the possibility of replay, i.e. we find the problem
of "hostage messages" (someone intercepts your message, keeps it, and time
stamps it at a much later time) that not even the nonce solves. Can we
afford an intentionally produced delay in time stamping?.
 Sadly, the best way to determine the "freshness" of a time stamp is
comparing its time to the local time and check if the interval
request-response fits your local policy (the bad news are that you can do
nothing "a posteriori").

regards,

Juan.




Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id WAA07130 for ietf-pkix-bks; Thu, 8 Apr 1999 22:17:59 -0700 (PDT)
Received: from smtp.udac.net (smtp.udac.net [193.44.79.123]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id WAA07126 for <[e-mail]>; Thu, 8 Apr 1999 22:17:57 -0700 (PDT)
Received: from caesar.udac.se (caesar.udac.se [193.44.79.10]) by smtp.udac.net (8.9.1/8.9.1) with ESMTP id HAA03836 for <[e-mail]>; Fri, 9 Apr 1999 07:17:54 +0200
Received: from mega (t4o69p79.telia.com [62.20.145.199]) by caesar.udac.se (8.7.3/NetworkC-1) with SMTP id HAA94903; Fri, 9 Apr 1999 07:17:48 +0200
Message-ID: <006c01be8250$6fe05540$[e-mail]>
From: "Anders Rundgren" <[e-mail]>
To: "Stephen Kent" <[e-mail]>, "Stefan Santesson" <[e-mail]>
Cc: <[e-mail]>, <[e-mail]>
Subject: CyberPhone Trust Propagation  Was: A $25,000,000,000 PKI
Date: Fri, 9 Apr 1999 07:15:58 +0100
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.2106.4
X-MimeOLE: Produced By Microsoft MimeOLE V4.72.2106.4
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by mail.proper.com id WAA07127
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Steve,

Sorry for changing subject all the time but there are soo many issues
to discuss.  This is an explantation on a major issue regarding private keys and
trust.  Don't be fooled by the language or terminology that may suck a bit
since neither English or this part of PKI is a speciality of mine.  I am sort of
a hands-on guy rather than a philosopher.

Basically I feel that you and many others believe that CyberPhone with its
intermediary key-server, propagates trust from the client to the end-RP.

This is definitely possible and true if CyberPhone is used in the same context as
Kerberos.  I.e. for authentication and authorization WITHIN an organization
(putting on my marketing hat I would say CyberPhone does this much better
than Kerberos as the former is 100% based on PKI).

Now to the scenarios presented on my web (Shared Certificates
and Dynamic Certificates) that represent two much more complicated situations
that an open environment introduce.

If those scenarious introduce trust propagation it would mean that the intermediary
private key server performed something on behalf of the client.  But, IT IS THE
OTHER WAY AROUND!  It is the intermediary server that grants a client the right
to perform a purchase on the servers behalf.  Yes, when you purchase for a company
it is the company that buys.  That the purchase was initiated by the client does
not change this a single bit.  A company assumes that you do your work  - not that it has
to screem and shout to make you perform!  And you have in this role obligations
only to your company (=server).

That is why CyberPhone does not break any (of the mostly unwritten) rules regarding
key use and trust.

It does though assume that a server and private keys stored on it can be responsible
in the same way as a natural person.  As I wrote in another posting this is what is
happening all the time (except for signatures that are not yet implemented) in automated
invoicing systems so there is "Nothing new under the Sun".  

Regards
Anders

http://www.mobilephones-tng.com


<snip>

>>So what is so fundamentally flawed in the CyberPhone concept with respect
>>to digital
>>signature laws?
>
>I won't comment on the question of the legality of CyberPhone, vis a vis,
>the current hodge podge of digital signature laws.  However, I was not
>aware of SET wallte servers, e.g., in the corporate context you describe.
>An employee using a cert issued for company purchasing, etc. may or may not
>be the real "owner" of the private key.  If the cert identifies the subject
>as a role, and the user is the role occupant, then the company is
>intentionally maintaining accountability on a purely internal basis.
>Technicall, this can be done reasonably well by issuing the cert via a
>smart card or PC card, so that the user has not (easy) access or knowledge
>of the private key.  However, if the subject of the cert is an
>organizationl person (not role), then I think of the issue of ownership
>differently.  The company needs to revoke the cert when the employee leaves
>of changes roles and no longer has the same purchasing authoirzation.  (Of
>course, this points out why an attribute cert might be better in this case
>...)
>
>steve
>



Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id WAA06417 for ietf-pkix-bks; Thu, 8 Apr 1999 22:05:17 -0700 (PDT)
Received: from dsg1.OpenDirectory.com.au ([203.108.249.145]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id WAA06403 for <[e-mail]>; Thu, 8 Apr 1999 22:05:05 -0700 (PDT)
Received: by DSG1 with Internet Mail Service (5.0.1458.49) id <22ZNQL9D>; Fri, 9 Apr 1999 15:04:39 +1000
Message-ID: <D1A949D4508DD1119C8100400533BEDC0BE977@DSG1>
From: Alan Lloyd <[e-mail]>
To: "'Stephen Kent'" <[e-mail]>
Cc: [e-mail]
Subject: RE: CA vs. EE cert processing
Date: Fri, 9 Apr 1999 15:04:38 +1000
X-Priority: 3
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.0.1458.49)
Content-Type: text/plain
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

When one builds a system comprising many CA functions for different
product domains, its likely that the key generation function is used to
generate keys for more than one of these CA functions - however this
approach is according to trust and operational requirements. Naturally
the theory in this process is that the root level CA function then in
fact signs the subordinate CA function certificate with its key and the
sub CA also signs its certs with its own key. However, we also expect in
this process - in terms of procedure that the root level CA could check
components of the certificate it is signing - such as the extensions
being applied - eg BC = CA .. and the client software used - the
certficate using system also checks this correctly..
 
ie. one must also verify that if a CA is using BC = CA that the client
has in fact verified that - again the proof of doing that is in the
system design and implementation. ie what gives proof of path
processing. Its all part of the system verification process - that each
part of the PKI is coherent and trusted.


My point was that X.509 states that this extension is set or not  to let
the certificate using system determine if it can use the public key to
validate certficates .. However, the standard also permits non extended
certficates to be used in a system and the certificate using system to
verify certificates  with the implicit knowledge that a cert chain does
equal an EE cert with superior CAs. 

My last point is that 2459 can profile X.509 say all CA certs must have
this extension set. EE certs may have this extension set to null or not
be there.

No ambiguity as far as I am concerned.


regards alan
> -----Original Message-----
> From:	Stephen Kent 
> Sent:	Friday, April 09, 1999 10:36 AM
> To:	Alan Lloyd
> Cc:	[e-mail]
> Subject:	RE: CA vs. EE cert processing
> 
> Alan,
> 
> >X.509 defines that Basic Constraints is used to indicate that the
> public
> >key in the cert is valid for testing certificate signatures - by a
> >certificate using system eg. a client or EE. By definition it means
> that
> >in  (eg.) a 3 tier CA model that the root level CA has granted a
> private
> >and public key ( in a cert with BC set to CA) to a middle level CA to
> >issue certificates with and "advertise the fact (in its certificate)
> >that the root trusts the middle CA to issue certs and for clients to
> >validate such certs using the middle CAs public key.
> >
> >It strikes me that any PKIX compliant top level ROOT CA will set this
> >extension to ensure that the correct PKeys are used to validate certs
> >which point to itself. However, what the client software does with
> this
> >extension is another matter. Both have to be compatable. If an EE in
> its
> >validation path gets a cert with which it wants to validate a lower
> >level certificate with and this extension is not set - it should give
> up
> >- if ideology is maintained. However, X.509 permits an exit to this
> >process to enable a CA path to be built and validated without cert
> >extensions - simply because that is what they are - optional
> certificate
> >extensions.
> 
> This is a very muddled description that I have a bit of trouble
> following.
> For example, the root CA in your example would not, in general, grant
> "a
> private and public key" to another CA.  Do you mean the root CA would
> sign
> a cert with the publci key of the middle CA?  Please restate your
> argument
> using terms from X.509 and/or 2459 so I, and maybe others, can more
> clearly
> understand your point.
> 
> Steve


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id UAA01614 for ietf-pkix-bks; Thu, 8 Apr 1999 20:47:58 -0700 (PDT)
Received: from smtp.udac.net (smtp.udac.net [193.44.79.123]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id UAA01604 for <[e-mail]>; Thu, 8 Apr 1999 20:47:55 -0700 (PDT)
Received: from caesar.udac.se (caesar.udac.se [193.44.79.10]) by smtp.udac.net (8.9.1/8.9.1) with ESMTP id FAA03092 for <[e-mail]>; Fri, 9 Apr 1999 05:47:50 +0200
Received: from mega (t4o69p7.telia.com [62.20.145.127]) by caesar.udac.se (8.7.3/NetworkC-1) with SMTP id FAA11639; Fri, 9 Apr 1999 05:47:45 +0200
Message-ID: <001801be8243$db209d40$[e-mail]>
From: "Anders Rundgren" <[e-mail]>
To: "Stephen Kent" <[e-mail]>, "Stefan Santesson" <[e-mail]>
Cc: <[e-mail]>, "'SEIS-List'" <[e-mail]>
Subject: Re: A $25,000,000,000 PKI   Was:Spec. on QC-low-fat & QC-heavy-bio
Date: Fri, 9 Apr 1999 05:45:53 +0100
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.2106.4
X-MimeOLE: Produced By Microsoft MimeOLE V4.72.2106.4
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by mail.proper.com id UAA01608
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Steve,

<snip>


>>CyberPhone does a LOT more than address devices with limited capabilities.
>>It also addresses certificate management, traceability and transaction
>>logging, business transaction models, and last but not least end-user security
>>including resource loss, revocation, backup and recovery.

>I believe that all of the other issues you cite here are addressable via
>means that do not require creating a proxy private key agent.

This is it! And I am not talking about Coca-Cola :-) I am talking about current PKI
schemes.   They PROMISE you a lot but when it comes to down-to-earth
specifications on how all this is going to be performed in a cost-efficient,
convenient and secure (handling-wise) way there is Zilch, Nada, Nothing.

If you do as I asked Stefan, convert the scenario presented in my paper
"Dynamic Certificates" ( http://www.mobilephones-tng.com/v100/dynamiccerts.html )
to the "classical" way of doing things you will for each design decision create
a lot of new hard questions.  A system that can only do "A-B" operations
is totally insufficient for 21st century usage.  Why do SET support a three-party operation?
Because an on-line account-based purchase involves (at least) three parties!

Regarding CyberPhone's "unethical" use of digital signatures there seems to be fairly
limited consensus on your and Stefan's views.  I.e. digital signature laws are not
in harmony with automated systems in any way.  My guess is that the lawyers will
have to go back to the "drawing board" some day. 

As an example I can mention OBI that allows an order to be "Authorized" by
signing it and sending it to the selling organization.   The authorizer can be
a person or an automated process.  OBI is for REAL which makes a difference.

Actually, CyberPhone (like SET ServerWallets and OBI) does not break away
from PKIX at all, it just uses current PKIX technology (+ a few new protocols) in
a more or less novel way that is targeted at existing and future commercial uses
and business processes.

Regards
Anders

PS No views on the bio stuff ( http://www.mobilephones-tng.com/papers/idcards.html  )?  DS




Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id TAA24439 for ietf-pkix-bks; Thu, 8 Apr 1999 19:19:17 -0700 (PDT)
Received: from po1.bbn.com (PO1.BBN.COM [192.1.50.38]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id TAA24435 for <[e-mail]>; Thu, 8 Apr 1999 19:19:15 -0700 (PDT)
Received: from [128.33.238.53] (TC053.BBN.COM [128.33.238.53]) by po1.bbn.com (8.9.1/8.9.1) with ESMTP id WAA18254; Thu, 8 Apr 1999 22:18:30 -0400 (EDT)
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Message-Id: <v04020a08b332fb11127f@[128.33.238.98]>
In-Reply-To: <D1A949D4508DD1119C8100400533BEDC0BE96E@DSG1>
Date: Thu, 8 Apr 1999 20:35:54 -0400
To: Alan Lloyd <[e-mail]>
From: Stephen Kent <[e-mail]>
Subject: RE: CA vs. EE cert processing
Cc: [e-mail]
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Alan,

>X.509 defines that Basic Constraints is used to indicate that the public
>key in the cert is valid for testing certificate signatures - by a
>certificate using system eg. a client or EE. By definition it means that
>in  (eg.) a 3 tier CA model that the root level CA has granted a private
>and public key ( in a cert with BC set to CA) to a middle level CA to
>issue certificates with and "advertise the fact (in its certificate)
>that the root trusts the middle CA to issue certs and for clients to
>validate such certs using the middle CAs public key.
>
>It strikes me that any PKIX compliant top level ROOT CA will set this
>extension to ensure that the correct PKeys are used to validate certs
>which point to itself. However, what the client software does with this
>extension is another matter. Both have to be compatable. If an EE in its
>validation path gets a cert with which it wants to validate a lower
>level certificate with and this extension is not set - it should give up
>- if ideology is maintained. However, X.509 permits an exit to this
>process to enable a CA path to be built and validated without cert
>extensions - simply because that is what they are - optional certificate
>extensions.

This is a very muddled description that I have a bit of trouble following.
For example, the root CA in your example would not, in general, grant "a
private and public key" to another CA.  Do you mean the root CA would sign
a cert with the publci key of the middle CA?  Please restate your argument
using terms from X.509 and/or 2459 so I, and maybe others, can more clearly
understand your point.

Steve


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id TAA24433 for ietf-pkix-bks; Thu, 8 Apr 1999 19:19:14 -0700 (PDT)
Received: from po1.bbn.com (PO1.BBN.COM [192.1.50.38]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id TAA24429 for <[e-mail]>; Thu, 8 Apr 1999 19:19:13 -0700 (PDT)
Received: from [128.33.238.53] (TC053.BBN.COM [128.33.238.53]) by po1.bbn.com (8.9.1/8.9.1) with ESMTP id WAA18247; Thu, 8 Apr 1999 22:18:22 -0400 (EDT)
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Message-Id: <v04020a07b332f9dbc9cd@[128.33.238.98]>
In-Reply-To: <D1A949D4508DD1119C8100400533BEDC0DDB8A@DSG1>
Date: Thu, 8 Apr 1999 20:29:37 -0400
To: Alan Lloyd <[e-mail]>
From: Stephen Kent <[e-mail]>
Subject: RE: Certificates, Directories, and Distinguished Names
Cc: <[e-mail]>, <[e-mail]>
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Alan,

>
>In addition - who will own the root level key for all this PKIX
>compliant stuff?

PKIX does not assume any single root CA in its model. See section 6.1 of
2459 for its discussion of starting points for cert path validation.

Steve


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id TAA24422 for ietf-pkix-bks; Thu, 8 Apr 1999 19:19:02 -0700 (PDT)
Received: from po1.bbn.com (PO1.BBN.COM [192.1.50.38]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id TAA24418 for <[e-mail]>; Thu, 8 Apr 1999 19:19:01 -0700 (PDT)
Received: from [128.33.238.53] (TC053.BBN.COM [128.33.238.53]) by po1.bbn.com (8.9.1/8.9.1) with ESMTP id WAA18269; Thu, 8 Apr 1999 22:18:50 -0400 (EDT)
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Message-Id: <v04020a0bb332fcbd7733@[128.33.238.98]>
In-Reply-To: <[e-mail]>
References: <v04020a17b331af2ed303@[128.33.238.98]>
Date: Thu, 8 Apr 1999 20:47:47 -0400
To: Moshe Litvin <[e-mail]>
From: Stephen Kent <[e-mail]>
Subject: Re: CA vs. EE cert processing
Cc: [e-mail]
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Moseh,

><snip>
>
>> >the first one aside for the moment, PKIX would be a better player in the
>> >broader X.509 world if it chose not to generate certificates that are
>> >ambiguous to such a world.
>>
>> The ambiguity exists in ALL verifiers, PKIX or not.  Thus pointing the
>> finger at PKIX is not rational.
>>
>
>The ambiguity does exist in ALL verifiers, but it doesn't exist in all CA's. A
>CA that follows PKIX creates ambiguous certificates. Only CA that does does
>something that it SHOULD NOT do create unambiguous certificates. Here pointing
>the finger at PKIX is very rational.
>
>We cannot remove the possibility of ambiguity but we can generate certificates
>that are not affected by it.

I agree that a CA could put the extension in all certs and thus be able to
say "not my fault; I did what I could."  But this does not address the
verifier problem in other than a heuristic fashion.  I want to
deterministic solution to the problem, and the suggested change to 2459
does not yield that.

>>
>> <snip>
>
>It is not probabilistic improvements. A CA that put the basicConstraints
>extension is 100% not ambiguous. What probablistic about that?
>
>Why discourage CA's from generating unambiguous certificates?

See my comments above. I was referring to the verifier, not the CA.  Sorry
for the ambiguity :-)!  The CA doesn't have a problem; verifiers have the
problem we are trying to address.

<snip>
>
>Adding the extension is not a heuristic improvement, a certificate with the
>extension is certificate that doesn't need heuristics period.
>
>Admittedly the verifier will have heuristics but the CA can ensure that they
>won't be activated.

No, it cannot!  So long as there are CAs following X.509 but not the 2459
profile, verifiers would need heuristics to process certs without
extensions issued by those CAs.  If we were willing to posit that no such
CAs will exist, then we would not have a problem, because in a purely
2459-compliant system (CAs and verifiers) there is not ambiguity.  You seem
to be switching perspectives in analyzing this issue.

>>
>
>X.509 already addresses the problem and suggests:
>
>   It is recommended that it be flagged critical, otherwise an entity which is
>not
>   authorized to be a CA may issue certificates and a certificate-using system
>   may unwittingly use such a certificate.
>
>For some reason PKIX decided to ignore the recommendation and invent it's own
>private semantics.

X.509 failed to solve this problem because it permits compliant CAs to
never include basicConstraints, thus creating the ambiguity.  The notes
fail to fix the problem, because they just "recommend" what to do.  In the
IETF we try to be very careful in our use of the magir words
MUST/SHOULD/MAY to avoid these problems.

Steve


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id TAA24379 for ietf-pkix-bks; Thu, 8 Apr 1999 19:18:16 -0700 (PDT)
Received: from po1.bbn.com (PO1.BBN.COM [192.1.50.38]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id TAA24371 for <[e-mail]>; Thu, 8 Apr 1999 19:18:15 -0700 (PDT)
Received: from [128.33.238.53] (TC053.BBN.COM [128.33.238.53]) by po1.bbn.com (8.9.1/8.9.1) with ESMTP id WAA17918; Thu, 8 Apr 1999 22:18:00 -0400 (EDT)
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Message-Id: <v04020a05b332f79941fe@[128.33.238.98]>
In-Reply-To: <002501be8187$1cdd0f10$[e-mail]>
Date: Thu, 8 Apr 1999 20:22:59 -0400
To: "Anders Rundgren" <[e-mail]>
From: Stephen Kent <[e-mail]>
Subject: Re: A $25,000,000,000 PKI   Was:Spec. on QC-low-fat & QC-heavy-bio
Cc: <[e-mail]>, "'SEIS-List'" <[e-mail]>
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Anders,

<snip>

Well, at least we agreed on much of the SET stuff.

>>Since most of the purchases over the web are
>>done from PCs, the thin n client argument is not relevant.
>
>That is true for the current situation - not for the mobile future though.

Maybe I should call the cell phone an anexoric client, not just a thin
client :-).  Advocates of other approaches to mobility assumje more
powerful computation bases, as we discussed earlier.  The cell phone (PCS)
is one, speculative approach.  It may be just as successful as the VSAT
technology that was poised to sweep the data networking industry in the
mid-80s.

>Hum, maybe you should take a look on GlobeSet's (a leader in SET) ServerWallet
>and see why the developed it.

I'll look into it.

<snip>

>>The solution you propose is definately NOT high quality.
>
>By design?  I am fully convinced (not such a big surprise though :-))  that if
>the CyberPhone concept and associated server technology is developed by
>the best brains
>in the industry it could match any quality standards.  Regarding the
>security model
>it is not so far from a PKI-only version of Kerberos which seems to be higly
>regarded by security people.

Kerberos is not used for applications requiring non-repudiation, whereas a
primary motivator for PKI use is NR..

>>It is an effort to
>>take advantage of devices with limited capabilities, and skew security
>>design principles to accommodate these limitations.
>
>CyberPhone does a LOT more than address devices with limited capabilities.
>It also addresses certificate management, traceability and transaction
>logging,
>business transaction models, and last but not least end-user security
>including
>resource loss, revocation, backup and recovery.

I believe that all of the other issues you cite here are addressable via
means that do not require creating a proxy private key agent.

Stve


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id TAA24363 for ietf-pkix-bks; Thu, 8 Apr 1999 19:18:04 -0700 (PDT)
Received: from po1.bbn.com (PO1.BBN.COM [192.1.50.38]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id TAA24359 for <[e-mail]>; Thu, 8 Apr 1999 19:18:03 -0700 (PDT)
Received: from [128.33.238.53] (TC053.BBN.COM [128.33.238.53]) by po1.bbn.com (8.9.1/8.9.1) with ESMTP id WAA17897; Thu, 8 Apr 1999 22:17:49 -0400 (EDT)
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Message-Id: <v04020a03b332f5f7dff4@[128.33.238.98]>
In-Reply-To: <002401be8187$1a0d4d40$[e-mail]>
Date: Thu, 8 Apr 1999 20:16:41 -0400
To: "Anders Rundgren" <[e-mail]>
From: Stephen Kent <[e-mail]>
Subject: Re: A $25,000,000,000 PKI   Was:Spec. on QC-low-fat & QC-heavy-bio
Cc: <[e-mail]>, <[e-mail]>
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Anders,

>May I ask a question regarding signature laws which I am pretty ignorant of?
>
>If a company runs a SET Wallet Server for their employees to use, is not
>the company
>responsible for signatures produced by the certificate and keys stored on that
> server?
>
>Legally as well as technically.
>
>Now to the users (with their CyberPhones) that initiates transactions:
>They are responsible to
>their company that as a minimum records all transations with user
>identity.  Or
>it could require a sign op as well.
>
>Looks OK to me.
>
>So what is so fundamentally flawed in the CyberPhone concept with respect
>to digital
>signature laws?

I won't comment on the question of the legality of CyberPhone, vis a vis,
the current hodge podge of digital signature laws.  However, I was not
aware of SET wallte servers, e.g., in the corporate context you describe.
An employee using a cert issued for company purchasing, etc. may or may not
be the real "owner" of the private key.  If the cert identifies the subject
as a role, and the user is the role occupant, then the company is
intentionally maintaining accountability on a purely internal basis.
Technicall, this can be done reasonably well by issuing the cert via a
smart card or PC card, so that the user has not (easy) access or knowledge
of the private key.  However, if the subject of the cert is an
organizationl person (not role), then I think of the issue of ownership
differently.  The company needs to revoke the cert when the employee leaves
of changes roles and no longer has the same purchasing authoirzation.  (Of
course, this points out why an attribute cert might be better in this case
...)

steve


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id RAA22556 for ietf-pkix-bks; Thu, 8 Apr 1999 17:59:31 -0700 (PDT)
Received: from smtp.bankinter.es (dns.bankinter.es [195.235.30.34]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id RAA22552 for <[e-mail]>; Thu, 8 Apr 1999 17:59:29 -0700 (PDT)
Received: from nexo.es (h028125.nexo.es [195.235.28.125]) by smtp.bankinter.es (8.8.8+Sun/8.8.8) with ESMTP id CAA26409; Fri, 9 Apr 1999 02:57:13 +0200 (MET DST)
Message-ID: <[e-mail]>
Date: Fri, 09 Apr 1999 02:56:58 +0200
From: Manuel Heras Gilsanz <[e-mail]>
X-Mailer: Mozilla 4.5 [en] (Win95; I)
X-Accept-Language: en
MIME-Version: 1.0
To: Robert Zuccherato <[e-mail]>
CC: [e-mail], [e-mail]
Subject: Re: Time-Stamp: Why not use several hashes?
References: <01E1D01C12D7D211AFC70090273D20B112BD97@sothmxs06>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Robert,

what you propose would seem a very reasonable solution to deal with an
*existing*, closed protocol that one would wish to stretch (via "syntax
abuse"), but in my opinion such a proliferation of OIDs should not be
enforced (or strongly promoted) from the very standard definition.

Regards,

     - Manuel -


Robert Zuccherato wrote:

> Manuel;
>
> This is presently supported.  Since a MessageImprint is a hashAlgorithm
> (AlgorithmIdentifier) followed by the hashedMessage (an OCTET STRING) all
> you have to do is define an AlgorithmIdentifier which means "the SHA-1 hash
> concatenated with the MD5 hash" for example and then include the SHA-1 hash
> of the message concatenated with the MD5 hash in the hashedMessage field.
>
>         Robert.
>
> > ----------
> > From:         Manuel Heras Gilsanz[SMTP:[e-mail]]
> > Sent:         Thursday, April 08, 1999 4:45 PM
> > To:   [e-mail]; [e-mail]
> > Subject:      Time-Stamp: Why not use several hashes?
> >
> > Hi.
> >
> > In the (now expired) latest PKIX draft on time-stamping protocols from
> > Sept. 23, 1998, time-stamp requests and tokens support the insertion of
> > a single message imprint.
> >
> > I think several message imprints should be supported. If a hash
> > algorithm were broken, time-stamp tokens using it (as the single message
> > imprint) would have to be regarded invalid (even if some kind of linking
> > mechanism were implemented!). If several hashes had been used, the token
> > would still be valid, and it could be promptly renewed in order to
> > prevent invalidation should further advances in cryptography render
> > other hashes obsolete!
> >
> > (One must be careful here: there are different extents to which a hash
> > algorithm could be broken; in Appendix A of  PKITS-D3
> > [http://www.fnmt.es/pkits] there is an interesting analysis of the
> > implications that the different kinds of hash failures would have on the
> > time-stamping process.)
> >
> > Of course the requirements on the time-stamp verification process would
> > also have be modified to require ("MUST" level) *all* the hashes to
> > correctly verify in order to regard the corresponding time-stamp token
> > valid.
> >
> > Best regards,
> >
> >     - Manuel -
> >
> > ----
> > Manuel Heras-Gilsanz ([e-mail])
> > Independent Security Consultant
> > Phone: [phone]
> >



Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id OAA20346 for ietf-pkix-bks; Thu, 8 Apr 1999 14:24:04 -0700 (PDT)
Received: from gatekeeper.entrust.com (gatekeeper.entrust.com [204.101.128.170]) by mail.proper.com (8.8.8/8.8.5) with SMTP id OAA20342 for <[e-mail]>; Thu, 8 Apr 1999 14:24:03 -0700 (PDT)
Received: 	id RAA15733; Thu, 8 Apr 1999 17:19:47 -0400
Received: by gateway id <G4CAZ9H6>; Thu, 8 Apr 1999 17:22:07 -0400
Message-ID: <01E1D01C12D7D211AFC70090273D20B112BD97@sothmxs06>
From: Robert Zuccherato <[e-mail]>
To: [e-mail], [e-mail], "'Manuel Heras Gilsanz'" <[e-mail]>
Subject: RE: Time-Stamp: Why not use several hashes?
Date: Thu, 8 Apr 1999 17:15:59 -0400 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.1960.3)
Content-Type: text/plain
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Manuel;

This is presently supported.  Since a MessageImprint is a hashAlgorithm
(AlgorithmIdentifier) followed by the hashedMessage (an OCTET STRING) all
you have to do is define an AlgorithmIdentifier which means "the SHA-1 hash
concatenated with the MD5 hash" for example and then include the SHA-1 hash
of the message concatenated with the MD5 hash in the hashedMessage field.

	Robert.

> ----------
> From: 	Manuel Heras Gilsanz[SMTP:[e-mail]]
> Sent: 	Thursday, April 08, 1999 4:45 PM
> To: 	[e-mail]; [e-mail]
> Subject: 	Time-Stamp: Why not use several hashes?
> 
> Hi.
> 
> In the (now expired) latest PKIX draft on time-stamping protocols from
> Sept. 23, 1998, time-stamp requests and tokens support the insertion of
> a single message imprint.
> 
> I think several message imprints should be supported. If a hash
> algorithm were broken, time-stamp tokens using it (as the single message
> imprint) would have to be regarded invalid (even if some kind of linking
> mechanism were implemented!). If several hashes had been used, the token
> would still be valid, and it could be promptly renewed in order to
> prevent invalidation should further advances in cryptography render
> other hashes obsolete!
> 
> (One must be careful here: there are different extents to which a hash
> algorithm could be broken; in Appendix A of  PKITS-D3
> [http://www.fnmt.es/pkits] there is an interesting analysis of the
> implications that the different kinds of hash failures would have on the
> time-stamping process.)
> 
> Of course the requirements on the time-stamp verification process would
> also have be modified to require ("MUST" level) *all* the hashes to
> correctly verify in order to regard the corresponding time-stamp token
> valid.
> 
> Best regards,
> 
>     - Manuel -
> 
> ----
> Manuel Heras-Gilsanz ([e-mail])
> Independent Security Consultant
> Phone: [phone]
> 


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id NAA20001 for ietf-pkix-bks; Thu, 8 Apr 1999 13:45:23 -0700 (PDT)
Received: from smtp.bankinter.es (dns.bankinter.es [195.235.30.34]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id NAA19997 for <[e-mail]>; Thu, 8 Apr 1999 13:45:19 -0700 (PDT)
Received: from nexo.es (h024055.nexo.es [195.235.24.55]) by smtp.bankinter.es (8.8.8+Sun/8.8.8) with ESMTP id WAA06655; Thu, 8 Apr 1999 22:43:32 +0200 (MET DST)
Message-ID: <[e-mail]>
Date: Thu, 08 Apr 1999 22:45:47 +0200
From: Manuel Heras Gilsanz <[e-mail]>
X-Mailer: Mozilla 4.5 [en] (Win95; I)
X-Accept-Language: en
MIME-Version: 1.0
To: "[e-mail]" <[e-mail]>, [e-mail]
Subject: Time-Stamp: Why not use several hashes?
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Hi.

In the (now expired) latest PKIX draft on time-stamping protocols from
Sept. 23, 1998, time-stamp requests and tokens support the insertion of
a single message imprint.

I think several message imprints should be supported. If a hash
algorithm were broken, time-stamp tokens using it (as the single message
imprint) would have to be regarded invalid (even if some kind of linking
mechanism were implemented!). If several hashes had been used, the token
would still be valid, and it could be promptly renewed in order to
prevent invalidation should further advances in cryptography render
other hashes obsolete!

(One must be careful here: there are different extents to which a hash
algorithm could be broken; in Appendix A of  PKITS-D3
[http://www.fnmt.es/pkits] there is an interesting analysis of the
implications that the different kinds of hash failures would have on the
time-stamping process.)

Of course the requirements on the time-stamp verification process would
also have be modified to require ("MUST" level) *all* the hashes to
correctly verify in order to regard the corresponding time-stamp token
valid.

Best regards,

    - Manuel -

----
Manuel Heras-Gilsanz ([e-mail])
Independent Security Consultant
Phone: [phone]



Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id LAA18496 for ietf-pkix-bks; Thu, 8 Apr 1999 11:46:44 -0700 (PDT)
Received: from smtp.udac.net (smtp.udac.net [193.44.79.123]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id LAA18492 for <[e-mail]>; Thu, 8 Apr 1999 11:46:42 -0700 (PDT)
Received: from caesar.udac.se (caesar.udac.se [193.44.79.10]) by smtp.udac.net (8.9.1/8.9.1) with ESMTP id UAA31854 for <[e-mail]>; Thu, 8 Apr 1999 20:47:29 +0200
Received: from mega (t1o69p19.telia.com [62.20.144.19]) by caesar.udac.se (8.7.3/NetworkC-1) with SMTP id UAA114985; Thu, 8 Apr 1999 20:47:26 +0200
Message-ID: <00a001be81f8$5f75c9e0$[e-mail]>
From: "Anders Rundgren" <[e-mail]>
To: "Simon Corell" <[e-mail]>, "Stephen Kent" <[e-mail]>, "'Stefan Santesson'" <[e-mail]>
Cc: <[e-mail]>, "'SEIS-List'" <[e-mail]>
Subject: Re: A $25,000,000,000 PKI Was:Spec. on QC-low-fat &Q C-heavy-bio
Date: Thu, 8 Apr 1999 20:45:35 +0100
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.2106.4
X-MimeOLE: Produced By Microsoft MimeOLE V4.72.2106.4
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by mail.proper.com id LAA18493
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Hi Simon,

<snip>

>It is a pity that the definitions used was based on the technology.  I tried
>hard to introduce the "digital stamp" as a termus tecnicus to digital
>signatures produced by legal bodies.

That sounds like a really good idea and considering the currently not
so widely use of digital signatures, I would not bury this thing yet.

BTW, "Digital Stamps" could not only be applied to legal bodies but
could also be produced by machines like ticket automates where
the ISSUER is a legal body and the SUBJECT (signer) is a particular
unit.

<snip>

Regards
Anders
http://www.mobilephones-tng.com




Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id LAA18481 for ietf-pkix-bks; Thu, 8 Apr 1999 11:45:55 -0700 (PDT)
Received: from mail01-ewr.pilot.net (mail-ewr-1.pilot.net [206.98.230.18]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id LAA18477 for <[e-mail]>; Thu, 8 Apr 1999 11:45:54 -0700 (PDT)
From: [e-mail]
Received: from mailgw.firstdata.com ([204.48.27.166]) by mail01-ewr.pilot.net with ESMTP id OAA23411; Thu, 8 Apr 1999 14:46:38 -0400 (EDT)
Received: from lnsunr02.firstdata.com (lnsunr02.firstdata.com [192.168.247.16]) by mailgw.firstdata.com with SMTP id OAA10839; Thu, 8 Apr 1999 14:46:37 -0400 (EDT)
Received: by lnsunr02.firstdata.com(Lotus SMTP MTA v4.6.3  (733.2 10-16-1998))  id 8525674D.00667C27 ; Thu, 8 Apr 1999 14:39:24 -0400
X-Lotus-FromDomain: FDC
To: Stefan Santesson <[e-mail]>
cc: Denis Pinkas <[e-mail]>, IETF-PXIX <[e-mail]>
Message-ID: <[e-mail]>
Date: Thu, 8 Apr 1999 11:43:03 -0700
Subject: Re: Conclusion - Biometric inclusion in QC
Mime-Version: 1.0
Content-type: multipart/mixed;  Boundary="0__=1S2azjQQRCdoVrZbv23XGtS6P2vwgYDaQtsStoN7HBYrysF4rM8zLsmG"
Content-Disposition: inline
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

--0__=1S2azjQQRCdoVrZbv23XGtS6P2vwgYDaQtsStoN7HBYrysF4rM8zLsmG
Content-type: text/plain; charset=us-ascii
Content-Disposition: inline

somewhat related is the AADS work on parameterised risk management
and certified assurance level of the various components (see various AADS
discussion at http://www.garlic.com/~lynn/). There has been the suggestion
that a consistent set of risk management & assurance level parameters be
specified so that they might also be used in certificate extensions (like does
an AADS authentication chipcard use pin activiation or biometric activation,
what is the assurance level of the chipcard, what assurance level is the
chip activiation, etc).

an issue with regard to AADS biometric is whether or not the biometric and
identification information is "public"  .... much of AADS use in civilian and
consumer scenerios worries about propogating identity information like
names around the net ... i.e. being able to do digital signed transactions
w/o having to divulge consumer name to parties involved.






Stefan Santesson <[e-mail]> on 03/31/99 04:06:39 AM

To:   Denis Pinkas <[e-mail]>
cc:   IETF-PXIX <[e-mail]>
Subject:  Re: Conclusion - Biometric inclusion in QC




At 11:09 AM 3/31/99 +0200, Denis Pinkas wrote:
<snip>
>I do not believe you met any Dennis Pinkas, maybe you met a Denis Pinkas.

Sorry for that !

<snip>
>> And don't forget that putting a hash of a picture in a QC, is already a
>> valid option. For example you can use this hash as a unique identifier
>> (issued by the CA) and put it in the dNQualifier attribute. Then include an
>> attributeSemantics OID defining this property. And you are all set !!
>
>If I understand correctly, you mean that we have some means to have an
extension,
>... but we still need to define that extension.
>This is exactly what I am advocating for.
>

Not exactly an extension. We define a new "PersonalData" field stored in
the otherName field in the subjectAltName extension. All this is found in
section 3.2.1 of the draft.

This field has the capability you are asking for. i.e. holding a hash of a
photo, plus the fact that you can communicate to the relying party that it
does.

/Stefan


>Regards,
>
>Denis



-------------------------------------------------------------------
Stefan Santesson                <[e-mail]>
Accurata Systems
--0__=1S2azjQQRCdoVrZbv23XGtS6P2vwgYDaQtsStoN7HBYrysF4rM8zLsmG
Content-type: text/plain; charset=iso-8859-1
Content-Disposition: inline
Content-transfer-encoding: quoted-printable


=E4kerhet AB      http://www.accurata.se
Slagthuset                      Tel. [phone]
211 20  Malm=F6                   Fax. [phone]
Sweden                        Mobile [phone]

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


=

--0__=1S2azjQQRCdoVrZbv23XGtS6P2vwgYDaQtsStoN7HBYrysF4rM8zLsmG--



Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id LAA18347 for ietf-pkix-bks; Thu, 8 Apr 1999 11:35:00 -0700 (PDT)
Received: from tomcat.sac.verio.net ([e-mail] [209.162.64.15]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id LAA18343 for <[e-mail]>; Thu, 8 Apr 1999 11:34:46 -0700 (PDT)
Received: from mcg.org.br (pm08-29.sac.verio.net [209.162.65.95]) by tomcat.sac.verio.net (8.9.1a/8.9.1) with ESMTP id LAA26462; Thu, 8 Apr 1999 11:33:33 -0700 (PDT)
Message-ID: <[e-mail]>
Date: Thu, 08 Apr 1999 11:31:53 -0700
From: Ed Gerck <[e-mail]>
X-Mailer: Mozilla 4.51 [en] (Win98; I)
X-Accept-Language: en
MIME-Version: 1.0
To: Patrik =?iso-8859-1?Q?F=E4ltstr=F6m?= <[e-mail]>
CC: Stefan Santesson <[e-mail]>, Anders Rundgren <[e-mail]>, Stephen Kent <[e-mail]>, [e-mail], "'SEIS-List'" <[e-mail]>
Subject: Trust, was Re: SEIS: Re: A $25,000,000,000 PKI 
References: <[e-mail]> <v04204c07b332805eae80@[192.168.110.1]>
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 8bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Patrik Fältström wrote:

> It is also the case that if you also have a contract between the
> parties exchanging information, or for example the party which hands
> out the keys, things get extremely complicated -- and I have not seen
> a single person being able to come with a formula for "TRUST" ever,
> and I doubt anyone will.

See:

1. Ed Gerck, "Towards Real-World Models of Trust: Reliance on Received
Information", in http://www.mcg.org.br/trustdef.htm

2.  Ed Gerck, "Trust Points" from http://www.mcg.org.br/trustdef.txt excerpted in
"Digital Certificates: Applied Internet Security" by J. Feghhi, J. Feghhi and P.
Williams, Addison-Wesley , ISBN 0-20-130980-7, p. 194-195, 1998.

3. John Gregory, "Electronic Legal Records: Pretty Good Authentication?", in
http://www.callacbd.ca/summit/auth-johngregory.html

4. Lea Viljanen, with Web page at  http://www.nixu.fi/~lea/  in a paper delivered
in an Internet seminar in Finland, had the following excerpt which may well
illustrate the usefulness of the approach in [1] above:

"If we analyze the first case following Gerck's definition of trust
being "[that which is] essential to a communication channel but which cannot
be transferred from the source to a destination using that channel"
(see 2.2 ), we must first analyze what is the communication channel in
this case. Here we find that the certificates themselves are the
channel/medium with which the data conveying some trust expressions are
transmitted. So trust to the certificates themselves cannot be
transferred using the certificates.

To define trust in a communication system from this point of view also
yields the interesting point that we can have several trust requirements
for a communication system. Each observer can have a list of trust
requirements for every level of the communication system, for example
trust for the hardware, trust only data carried by operator X or only
within our own corporate network, trust only data-origin-authenticated
messages etc. For us to trust the information received from the
communication all these trust conditions must be satisfied. The
existence of these multiple layers of trust is usually ignored."


Cheers,

Ed Gerck



Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id KAA17720 for ietf-pkix-bks; Thu, 8 Apr 1999 10:27:18 -0700 (PDT)
Received: from mail-out1.apple.com (mail-out1.apple.com [17.254.0.52]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id KAA17716 for <[e-mail]>; Thu, 8 Apr 1999 10:27:17 -0700 (PDT)
Received: from mailgate1.apple.com (A17-128-100-225.apple.com [17.128.100.225]) by mail-out1.apple.com (8.8.5/8.8.5) with ESMTP id KAA08898 for <[e-mail]>; Thu, 8 Apr 1999 10:23:08 -0700
Received: from scv1.apple.com (scv1.apple.com) by mailgate1.apple.com (mailgate1.apple.com- SMTPRS 2.0.15) with ESMTP id <[e-mail]>; Thu, 08 Apr 1999 10:23:03 -0700
Received: from [17.205.41.166] (aram1.apple.com [17.205.41.166]) by scv1.apple.com (8.9.3/8.9.3) with ESMTP id KAA28576; Thu, 8 Apr 1999 10:23:01 -0700
Message-Id: <[e-mail]>
X-Mailer: Microsoft Outlook Express Macintosh Edition - 4.5 (0410)
Date: Thu, 08 Apr 1999 10:23:01 -0700
Subject: Re: A $25,000,000,000 PKI   Was:Spec. on QC-low-fat & QC-heavy-bio
From: "Aram Perez" <[e-mail]>
To: Stefan Santesson <[e-mail]>, Anders Rundgren <[e-mail]>, Stephen Kent <[e-mail]>
Cc: [e-mail], "'SEIS-List'" <[e-mail]>
MIME-Version: 1.0
X-Priority: 3
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Stefan Santesson wrote:

> Anders,
> 
> First of all - I'm not a lawyer. All I'm saying is just my opinion.

Neither am I (but I'll give my opinion anyway :-).

>
> Second. The person responsible for a signature, regardless of type, is the
> person who created it and whose intent it expresses.
>
> I.e. You are ALWAYS responsible for signatures created by YOU and you are
> NEVER responsible for signatures created by someone else.

I don't believe this is legally correct. I can give a "power of attorney" to
someone else who can sign for me and I will be responsible for what that
person signs.

[snip]

Regards,
Aram Perez
Apple Computer, Inc.


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id KAA17530 for ietf-pkix-bks; Thu, 8 Apr 1999 10:09:44 -0700 (PDT)
Received: from nix.swip.net (nix.swip.net [192.71.220.2]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id KAA17526 for <[e-mail]>; Thu, 8 Apr 1999 10:09:42 -0700 (PDT)
Received: from [192.168.110.1] (workstation1.swip.net [130.244.254.1])  by nix.swip.net (8.8.8/8.8.8) with ESMTP  id TAA25740;  Thu, 8 Apr 1999 19:10:02 +0200 (MET DST)
Mime-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1" ; format="flowed"
X-Sender: [e-mail] (Unverified)
Message-Id: <v04204c07b332805eae80@[192.168.110.1]>
In-Reply-To: <[e-mail]>
References: <[e-mail]>
Date: Thu, 8 Apr 1999 19:06:47 +0200
To: Stefan Santesson <[e-mail]>, "Anders Rundgren" <[e-mail]>, "Stephen Kent" <[e-mail]>
From: Patrik =?iso-8859-1?Q?F=E4ltstr=F6m?=  <[e-mail]>
Subject: Re: SEIS:  Re: A $25,000,000,000 PKI   Was:Spec. on QC-low-fat &  QC-heavy-bio
Cc: <[e-mail]>, "'SEIS-List'" <[e-mail]>
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by mail.proper.com id KAA17527
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

At 16.52 +0200 1999-04-08, Stefan Santesson wrote:
>I.e. You are ALWAYS responsible for signatures created by YOU and you are
>NEVER responsible for signatures created by someone else.
>
>Who owns the techiqe, keys, system, infrastructure etc. are totally
>irrelevant to this fact.

In this step, yes. BUT, the party which you, as the signer, is 
sending the signed data to, have to trust the data itself, and the 
proposed fact that you were the one sending it.

I.e. you as a signer is signing data just because you want someone 
else to trust your information.

The infrastructure, keys, system etc is something which can be used 
at a later stage (see below).

>So, last, what remains is the problem of providing strong evidence if the
>above fact is repudiated. I.e. if you deny that a signature was created as
>e result of your consious act, representing your intent.
>
>This however WILL be dependent on technique, keys, system, infrastructure etc.
>
>So when we are talking about law and technique, we are ONLY talking about
>factors which effect the EVIDENCE VALUE. Not factors that decide whether a
>signature is legal or not.
>
>ALL SIGNATURES ARE LEGAL. It's only the fact that some of them are harder
>to prove in court than others.

In legal systems like the one we have in Sweden, any party can to the 
court use any kind of evidence. In Swedish we call it "fri 
bevisprövning". I have been told, that in other legal systems, other 
rules can exist.

It is also the case that if you also have a contract between the 
parties exchanging information, or for example the party which hands 
out the keys, things get extremely complicated -- and I have not seen 
a single person being able to come with a formula for "TRUST" ever, 
and I doubt anyone will.

    paf



Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id JAA16655 for ietf-pkix-bks; Thu, 8 Apr 1999 09:04:56 -0700 (PDT)
Received: from aunt15.ausys.se (void1.ausys.se [62.20.78.253]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id JAA16647 for <[e-mail]>; Thu, 8 Apr 1999 09:04:51 -0700 (PDT)
Received: by aunt15.ausys.se with Internet Mail Service (5.5.1960.3) id <2NB2THYT>; Thu, 8 Apr 1999 18:05:01 +0200
Message-ID: <[e-mail]>
From: Simon Corell <[e-mail]>
To: "'Anders Rundgren'" <[e-mail]>, Stephen Kent <[e-mail]>, "'Stefan Santesson'" <[e-mail]>
Cc: [e-mail], "'SEIS-List'" <[e-mail]>
Subject: RE: SEIS:  RE: A $25,000,000,000 PKI   Was:Spec. on QC-low-fat &Q C-heavy-bio
Date: Thu, 8 Apr 1999 18:05:00 +0200 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.1960.3)
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by mail.proper.com id JAA16652
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Thank you Stefan for this straight forward remark - you are quite right but
there are nevertheless exemptions and in some jurisdictions digital
signatures is not even acknowledged unless defined in the law. That's why we
had such problems with the EU Directive on this subject. Most of us don't
want any specifications at all others want every bit specified, certified,
sealed and signed and .....
The difference between legal and natural persons is a fact. Legal bodies
cannot write and just because we are using the same technology doesn't
change this fact. The old handwriting means so much more from a social and
legal point of view and that's why it cannot be exchanged (without previous
agreements) by automatically processes. The most important function of a
document paper or electronic is the word "acknowledgement". If you don't
know what your are doing an ever so good technical solution is worthless -
also in the Nordic countries - as a proof. 
It is a pity that the definitions used was based on the technology.  I tried
hard to introduce the "digital stamp" as a termus tecnicus to digital
signatures produced by legal bodies. Now you are going the other way and
introduce Qualified certificates produced by natural persons. After ten
years with this type of discussion I don't mind really
but the big issue is still to implement TRUST and I have noticed since long
that words and the meaning of words is essential and from an educational
point of view we had won a lot by separating the definitions of the two
types of usage already by the word. /Simon

Simon Corell, Product Manager LL.B.
iD2 Technologies, Liljeholmsvägen 14, P.O.Box 44055, 100 73 Sweden
Phone: [phone], Mobile: [phone], Fax: [phone]
mail to: [e-mail], http://www.iD2tech.com
IT Prize grand winner '98
 
iD2's forthcoming event
 - Netec '99, Stand E139A - 21-22 April Helsinki




-----Original Message-----
From: Anders Rundgren [mailto:[e-mail]]
Sent: den 8 april 1999 17:19
To: Stephen Kent; 'Stefan Santesson'
Cc: [e-mail]; 'SEIS-List'
Subject: SEIS: RE: A $25,000,000,000 PKI Was:Spec. on QC-low-fat
&QC-heavy-bio


--- Message on the SEIS mailing list ([e-mail])

Stefan,
>First of all - I'm not a lawyer. All I'm saying is just my opinion.

>Second. The person responsible for a signature, regardless of type, is the
>person who created it and whose intent it expresses.

>I.e. You are ALWAYS responsible for signatures created by YOU and you are
>NEVER responsible for signatures created by someone else.

Now you hit a VERY interesting point that I would like to concentrate on as
it seems to be the "stumbling block" for DS as required by CyberPhone:

You talk about "you" and the "person" etc. signing things.

How about let's say, automatically produced invoices like telephone bills
wrt
signing?

<snip>

Regards
Anders
http://www.mobilephones-tng.com



----------------- SEIS mailing list ([e-mail])
Info about this list: http://www.nc-forum.com/seis
SEIS Contact: [e-mail]


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id IAA16262 for ietf-pkix-bks; Thu, 8 Apr 1999 08:18:08 -0700 (PDT)
Received: from smtp.udac.net (smtp.udac.net [193.44.79.123]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id IAA16258 for <[e-mail]>; Thu, 8 Apr 1999 08:18:06 -0700 (PDT)
Received: from caesar.udac.se (caesar.udac.se [193.44.79.10]) by smtp.udac.net (8.9.1/8.9.1) with ESMTP id RAA24080 for <[e-mail]>; Thu, 8 Apr 1999 17:18:51 +0200
Received: from HYDRA ([195.198.186.68]) by caesar.udac.se (8.7.3/NetworkC-1) with SMTP id RAA46975; Thu, 8 Apr 1999 17:18:45 +0200
Received: by HYDRA with Microsoft Mail id <01BE81E3.E227C8D0@HYDRA>; Thu, 8 Apr 1999 17:18:56 +0200
Message-ID: <01BE81E3.E227C8D0@HYDRA>
From: Anders Rundgren <[e-mail]>
To: Stephen Kent <[e-mail]>, "'Stefan Santesson'" <[e-mail]>
Cc: "[e-mail]" <[e-mail]>, "'SEIS-List'" <[e-mail]>
Subject: RE: A $25,000,000,000 PKI   Was:Spec. on QC-low-fat &QC-heavy-bio
Date: Thu, 8 Apr 1999 17:18:54 +0200
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Stefan,
>First of all - I'm not a lawyer. All I'm saying is just my opinion.

>Second. The person responsible for a signature, regardless of type, is the
>person who created it and whose intent it expresses.

>I.e. You are ALWAYS responsible for signatures created by YOU and you are
>NEVER responsible for signatures created by someone else.

Now you hit a VERY interesting point that I would like to concentrate on as
it seems to be the "stumbling block" for DS as required by CyberPhone:

You talk about "you" and the "person" etc. signing things.

How about let's say, automatically produced invoices like telephone bills wrt
signing?

<snip>

Regards
Anders
http://www.mobilephones-tng.com




Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id HAA15998 for ietf-pkix-bks; Thu, 8 Apr 1999 07:56:51 -0700 (PDT)
Received: from gatekeeper.entrust.com (gatekeeper.entrust.com [204.101.128.170]) by mail.proper.com (8.8.8/8.8.5) with SMTP id HAA15994 for <[e-mail]>; Thu, 8 Apr 1999 07:56:49 -0700 (PDT)
Received: 	id KAA03423; Thu, 8 Apr 1999 10:49:27 -0400
Received: by gateway id <G4CAZ6S1>; Thu, 8 Apr 1999 10:51:46 -0400
Message-ID: <01E1D01C12D7D211AFC70090273D20B112BD90@sothmxs06>
From: Robert Zuccherato <[e-mail]>
To: Peter Sylvester <[e-mail]>, "'Denis Pinkas'" <[e-mail]>
Cc: [e-mail], [e-mail]
Subject: RE: Time Stamp: tsa field in TSTInfo
Date: Thu, 8 Apr 1999 10:45:47 -0400 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.1960.3)
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by mail.proper.com id HAA15995
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Okay, I will make the tsa name optional as well.  However, it MUST be
present if the authenticated attribute from ESS is not included.  I think
that since time stamp tokens will be used as evidence in support of
non-repudiation, there should be some identification of the TSA within the
signed part of the token.

> ----------
> From: 	Denis Pinkas[SMTP:[e-mail]]
> Sent: 	Thursday, April 08, 1999 6:16 AM
> To: 	Peter Sylvester
> Cc: 	[e-mail]; [e-mail]; [e-mail]
> Subject: 	Re: Time Stamp: tsa field in TSTInfo
> 
> Peter,
> 
> I concur with your proposal, ie. use an signed (also called
> "authenticated")
> attribute from ESS that indicates the certificate used by the TSA and
> suppress the
> name of the TSA from the signed structure. This "useful" attribute is
> indeed in
> ESS, not CMS - where it should have been. :-(
> 
> Since the verifier will need anyway to get that certificate to verify the
> signature, then, at that time, it will get the name of the TSA.
> 
> Regards,
> 
> Denis
> 
> 
> > >
> > > Actually, I believe that when using CMS only the content (in this case
> > > TSTInfo) is signed along with any authenticated attributes.  Thus, the
> > > distinguishing information for the TSA would not be signed if it was
> not
> > > included within the TSTInfo structure.
> > If the TST provider want to surely indicate its identity, one
> > can use an ess signing certificate attribute.
> >
> > This seems preferable to me (if the tendancy is avoid to reinvent
> things).
> >
> > The ess stuff was probably not avaiable at the time when
> > the tst draft was written for the first time.
> >
> >
> > >
> > >       Robert.
> > >
> > > > ----------
> > > > From:       Juan Luis López[SMTP:[e-mail]]
> > > > Sent:       Wednesday, April 07, 1999 5:25 AM
> > > > To:         pkix
> > > > Subject:    Time Stamp: tsa field in TSTInfo
> > > >
> > > >     Hi everybody!
> > > >
> > > >     I am involved in a Time Stamping project and we are analysing
> the PKIX
> > > > draft about this subject.
> > > >
> > > >     I would like to give my opinion on an issue to the list:
> > > >     It seems not appropriate to include a field in TSTInfo structure
> > > > related to the tsa identity, i.e. tsa field. I don't find this field
> > > > necessary because it is repeated when using a CMS or PKCS#7 envelope
> to
> > > > encapsulate the token information. This information would be
> redundant
> > > > since an identifier distinguishing the given tsa should be present
> in the
> > > > signerInfo structure.
> > > >
> > > >     So, I recommend the deletion of this field.
> > > >
> > > >     Regards,
> > > >    Juan Luis López
> > > >
> > > >
> > > >
> > > >
> --------------------------------------------------------------------------
> > > > -----------
> > > > Juan Luis López                                              <
> > > > [e-mail]>
> > > > Project Engineer
> > > > http://www.fnmt.es/pkits
> > > > Fábrica Nacional de Moneda y Timbre             tel: [+34] 91 506 48
> 40
> > > > C/ Juan de Mariana, 17                                  fax: [+34]
> 91 506
> > > > 48 51
> > > > E-28045 Madrid, SPAIN
> > > >
> > >
> 


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id HAA15945 for ietf-pkix-bks; Thu, 8 Apr 1999 07:51:04 -0700 (PDT)
Received: from popmail.inbox.se (popmail.inbox.se [193.12.72.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id HAA15941 for <[e-mail]>; Thu, 8 Apr 1999 07:51:02 -0700 (PDT)
Received: from stefan2 (accurata.inbox.se [193.12.72.24]) by popmail.inbox.se (8.9.3/8.9.3) with SMTP id QAA25568; Thu, 8 Apr 1999 16:51:43 +0200
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: Windows Eudora Pro Version 3.0 (32)
Date: Thu, 08 Apr 1999 16:52:27 +0200
To: "Anders Rundgren" <[e-mail]>, "Stephen Kent" <[e-mail]>
From: Stefan Santesson <[e-mail]>
Subject: Re: A $25,000,000,000 PKI   Was:Spec. on QC-low-fat & QC-heavy-bio
Cc: <[e-mail]>, "'SEIS-List'" <[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 mail.proper.com id HAA15942
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Anders,

First of all - I'm not a lawyer. All I'm saying is just my opinion.

Second. The person responsible for a signature, regardless of type, is the
person who created it and whose intent it expresses.

I.e. You are ALWAYS responsible for signatures created by YOU and you are
NEVER responsible for signatures created by someone else.

Who owns the techiqe, keys, system, infrastructure etc. are totally
irrelevant to this fact.

So, last, what remains is the problem of providing strong evidence if the
above fact is repudiated. I.e. if you deny that a signature was created as
e result of your consious act, representing your intent.

This however WILL be dependent on technique, keys, system, infrastructure etc.

So when we are talking about law and technique, we are ONLY talking about
factors which effect the EVIDENCE VALUE. Not factors that decide whether a
signature is legal or not.

ALL SIGNATURES ARE LEGAL. It's only the fact that some of them are harder
to prove in court than others.

/Stefan

P.s. Th above should not be mixed with the fact that some authorities may
require a minimum security level for signatures in order to accept them
(e.g. for a signature to be in hand writing). This is an option open to all
relying parties, i.e. to say - It has to be at least this good or I will
reject it.


 


At 07:14 AM 4/8/99 +0100, Anders Rundgren wrote:
>Hi Stefan + Steve,
>
>May I ask a question regarding signature laws which I am pretty ignorant of?
>
>If a company runs a SET Wallet Server for their employees to use, is not
the company
>responsible for signatures produced by the certificate and keys stored on
that server?
>
>Legally as well as technically. 
>
>Now to the users (with their CyberPhones) that initiates transactions:
They are responsible to
>their company that as a minimum records all transations with user
identity.  Or
>it could require a sign op as well.
>
>Looks OK to me.
>
>So what is so fundamentally flawed in the CyberPhone concept with respect
to digital
>signature laws?
>
>Regards
>Anders
>http://www.mobilephones-tng.com
>
>
-------------------------------------------------------------------
Stefan Santesson                <[e-mail]>
Accurata Systemsäkerhet AB      http://www.accurata.se
Slagthuset                      Tel. [phone]              
211 20  Malmö                   Fax. [phone]              
Sweden                        Mobile [phone]

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


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id HAA15758 for ietf-pkix-bks; Thu, 8 Apr 1999 07:34:20 -0700 (PDT)
Received: from gatekeeper.entrust.com (gatekeeper.entrust.com [204.101.128.170]) by mail.proper.com (8.8.8/8.8.5) with SMTP id HAA15753 for <[e-mail]>; Thu, 8 Apr 1999 07:34:18 -0700 (PDT)
Received: 	id KAA23252; Thu, 8 Apr 1999 10:30:18 -0400
Received: by gateway id <G4CAZ6NL>; Thu, 8 Apr 1999 10:32:39 -0400
Message-ID: <01E1D01C12D7D211AFC70090273D20B112BD8F@sothmxs06>
From: Robert Zuccherato <[e-mail]>
To: Robert Zuccherato <[e-mail]>, "'Denis Pinkas'" <[e-mail]>
Cc: [e-mail], "'Juan G. de la Vega'" <[e-mail]>
Subject: RE: Time Stamping: comments on nonce field
Date: Thu, 8 Apr 1999 10:26:40 -0400 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.1960.3)
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by mail.proper.com id HAA15755
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Okay.  I will make it optional in both the request and response.

> ----------
> From: 	Denis Pinkas[SMTP:[e-mail]]
> Sent: 	Thursday, April 08, 1999 6:10 AM
> To: 	Robert Zuccherato
> Cc: 	[e-mail]; 'Juan G. de la Vega'
> Subject: 	Re: Time Stamping: comments on nonce field
> 
> Robert,
> 
> Some refinements to your response.
> 
> The nonce is there for systems that do not have their own reliable clock
> and
> thus cannot test the freshness of the response by simply looking at the
> signing
> time. This is a replay protection. This has nothing to do whether a hash
> of the
> message is or is not present.
> 
> I would make it OPTIONAL both in the request and in the response and
> maintain
> the current text that says: " ...must be present if the similar field in
> TimeStampReq is present ..."
> 
> Regards,
> 
> Denis
> 
> 
> > > ----------
> > > From:         Juan G. de la Vega[SMTP:[e-mail]]
> > > Sent:         Wednesday, April 07, 1999 5:39 AM
> > > To:   [e-mail]
> > > Subject:      Time Stamping: comments on nonce field
> > >
> > >         First of all, the declaration of this field in the request and
> > > token is somehow incoherent, while the nonce is mandatory in
> TimeStapReq
> > > (it is not declared OPTIONAL), the TimeStampToken´s nonce is OPTIONAL
> but
> > > it is stated that "...must be present if the similar field in
> TimeStampReq
> > > is present..." and hence the clause OPTIONAL is meaningless and
> confusing
> > > for this field shall always be present.
> > >
> > As I have said in the past, this was a mistake that I made because I did
> not
> > manage to fully include support for TSA production of a "signed time".
> This
> > would be a token which does not include a nonce or message imprint.
> TSA's
> > could produce these tokens and make them available (for example on a
> > website) for anyone who wants to obtain them.  This will be rectified in
> the
> > upcoming draft.
> >
> > > I would suggest this field to be declared OPTIONAL both in the request
> and
> > > token or better deleted if we take into account the following:
> > >
> > >     As far as I understand, a nonce value is present in the request
> and
> > > token in order for the requester to be able to match the responses
> from
> > > the TSA with her requests when using an asynchronous transport. It can
> be
> > > argued that such functionality should be left to the transport layer
> when
> > > required, but furthermore I must say that the nonce is not necessary
> since
> > > matching can be performed using the "messageImprint" field.
> > >
> > Actually, the reason that the nonce is there and mandatory is to prevent
> > replay attacks.  Someone else could have obtained a time stamp on the
> data
> > before your request.  Thus, it is possible that the time stamp you
> received
> > is not "fresh".  Without a nonce, determining the freshness of the
> timestamp
> > is difficult.
> >
> >         Robert.
> 


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id EAA14208 for ietf-pkix-bks; Thu, 8 Apr 1999 04:49:59 -0700 (PDT)
Received: from smtp.udac.net (smtp.udac.net [193.44.79.123]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id EAA14203 for <[e-mail]>; Thu, 8 Apr 1999 04:49:54 -0700 (PDT)
Received: from caesar.udac.se (caesar.udac.se [193.44.79.10]) by smtp.udac.net (8.9.1/8.9.1) with ESMTP id NAA29167 for <[e-mail]>; Thu, 8 Apr 1999 13:34:31 +0200
Received: from HYDRA ([195.198.186.68]) by caesar.udac.se (8.7.3/NetworkC-1) with SMTP id NAA28169; Thu, 8 Apr 1999 13:34:25 +0200
Received: by HYDRA with Microsoft Mail id <01BE81C4.8B8EFE90@HYDRA>; Thu, 8 Apr 1999 13:34:36 +0200
Message-ID: <01BE81C4.8B8EFE90@HYDRA>
From: Anders Rundgren <[e-mail]>
To: "'Denis Pinkas'" <[e-mail]>
Cc: "'[e-mail]'" <[e-mail]>
Subject: RE: Low-fat leaf certificates
Date: Thu, 8 Apr 1999 13:34:35 +0200
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Denis,
>Anders,

>Your E-mail got burried under hundred of other E-mails. Sorry for the delay to respond.

Nema Problema!

>You misunderstood my talk. I am advocating against numerous extensions to >certificates that could be
>handled generically by "administrative" certificates that contain information valid for a >large number of
>leaf certificates.

Unfortunately I did not had the opportunity to attend RSA99 so I did my own 
interpretation of low-fat leaf-certificates which obviously was wrong.

No chance to get my hands on some kind of document on that?

Regards
Anders

PS Below is my version/interpretation of low-fat DS

http://www.mobilephones-tng.com/papers/idcards.html





Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id EAA13979 for ietf-pkix-bks; Thu, 8 Apr 1999 04:23:47 -0700 (PDT)
Received: from edelweb.fr (edelweb.fr [193.51.12.16]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id EAA13975 for <[e-mail]>; Thu, 8 Apr 1999 04:23:45 -0700 (PDT)
Received: from champagne.edelweb.fr (localhost.edelweb.fr [127.0.0.1]) by edelweb.fr with ESMTP id NAA04521; Thu, 8 Apr 1999 13:24:16 +0200 (MET DST)
Received: from champagne.edelweb.fr (champagne.edelweb.fr [193.51.14.161]) by edelweb.fr (nospam/1.1); Thu, 8 Apr 1999 13:24:16 +0200 (MET DST)
Received: from emeriau.edelweb.fr (emeriau.edelweb.fr [193.51.14.5]) by champagne.edelweb.fr (8.6.10/8.6.6) with ESMTP id NAA25942; Thu, 8 Apr 1999 13:24:15 +0200
From: Peter Sylvester <[e-mail]>
Received: (sylvest@localhost) by emeriau.edelweb.fr (8.6.10/8.6.6) id NAA05404; Thu, 8 Apr 1999 13:24:14 +0200
Date: Thu, 8 Apr 1999 13:24:14 +0200
Message-Id: <[e-mail]>
To: [e-mail], [e-mail], [e-mail]
Subject: RE: Time Stamp: tsa field in TSTInfo
Cc: [e-mail]
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

 
> The core time stamp information can be used indirectly, as a field inside 
> some third party WhateverService (WS) structure. Even (!) if this WS 
> structure gets signed/ enveloped, the signer is not going to be the TSA. 
> DCS as it stands now may serve as an example.
I am not sure what you want to say: 

A TimeStampToken is a CMS document that contains the signature
of the TSA, and a DCS provider can choose to include this in the
DCS response to indicate the time. So you have all the signerinfo
of the TSA, TDAs and DCS, etc.


> 
> So, having tsa inside the TSTInfo may come as a useful thing - the WS 
> clients may still want to know the TimeStamp's origin.
Agreed. 


 


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id DAA13268 for ietf-pkix-bks; Thu, 8 Apr 1999 03:24:27 -0700 (PDT)
Received: from www.fnmt.es ([193.149.2.14]) by mail.proper.com (8.8.8/8.8.5) with SMTP id DAA13264 for <[e-mail]>; Thu, 8 Apr 1999 03:24:26 -0700 (PDT)
Received: from dnsp.epc.fnmt.es (dnsp.epc.fnmt.es [193.149.3.17]) by www.fnmt.es (NTMail 3.02.13) with ESMTP id wa023448 for <[e-mail]>; Thu, 8 Apr 1999 12:20:09 +0100
Message-ID: <014c01be81a9$e2bac660$[e-mail]>
From: "=?iso-8859-1?Q?Juan_Luis_L=F3pez?=" <[e-mail]>
To: "Robert Zuccherato" <[e-mail]>, "pkix" <[e-mail]>
Subject: RE: Time Stamp: tsa field in TSTInfo
Date: Thu, 8 Apr 1999 12:22:14 +0200
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 8bit
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
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Yes, you're right. But, the only thing that we should take into account is
that the token is actually signed by the tsa. What tsa? the one signing the
token. This information shall be present in the "sid" field of the
SignerInfo structure. Optionally, the tsa certificate(s) could be
incorporated in the SignedData structure. So, why should we use the tsa
field in the TSTInfo structure when CMS Signed Data is used specifically for
the purpose of authenticating the signer? I mean, why are you signing "who
you are" if the signature itself (actually the process of verifying it)
provides that information?

Juan Luis
    ------------------------------------------------------------------------
-------------
Juan Luis López                                              <[e-mail]>
Project Engineer
http://www.fnmt.es/pkits
Fábrica Nacional de Moneda y Timbre             tel: [+34] 91 506 48 40
C/ Juan de Mariana, 17                                  fax: [+34] 91 506 48
51
E-28045 Madrid, SPAIN


-----Mensaje original-----
De: Robert Zuccherato <[e-mail]>
Para: pkix <[e-mail]>; 'Juan Luis López' <[e-mail]>
Fecha: miércoles 7 de abril de 1999 18:47
Asunto: RE: Time Stamp: tsa field in TSTInfo


Actually, I believe that when using CMS only the content (in this case
TSTInfo) is signed along with any authenticated attributes.  Thus, the
distinguishing information for the TSA would not be signed if it was not
included within the TSTInfo structure.

Robert.

> ----------
> From: Juan Luis López[SMTP:[e-mail]]
> Sent: Wednesday, April 07, 1999 5:25 AM
> To: pkix
> Subject: Time Stamp: tsa field in TSTInfo
>
> Hi everybody!
>
> I am involved in a Time Stamping project and we are analysing the PKIX
> draft about this subject.
>
> I would like to give my opinion on an issue to the list:
> It seems not appropriate to include a field in TSTInfo structure
> related to the tsa identity, i.e. tsa field. I don't find this field
> necessary because it is repeated when using a CMS or PKCS#7 envelope to
> encapsulate the token information. This information would be redundant
> since an identifier distinguishing the given tsa should be present in the
> signerInfo structure.
>
> So, I recommend the deletion of this field.
>
> Regards,
> Juan Luis López
>
>
>
> --------------------------------------------------------------------------
> -----------
> Juan Luis López <
> [e-mail]>
> Project Engineer
> http://www.fnmt.es/pkits
> Fábrica Nacional de Moneda y Timbre tel: [+34] 91 506 48 40
> C/ Juan de Mariana, 17 fax: [+34] 91 506
> 48 51
> E-28045 Madrid, SPAIN
>



Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id DAA13182 for ietf-pkix-bks; Thu, 8 Apr 1999 03:16:03 -0700 (PDT)
Received: from clbull.frcl.bull.fr (clbull.frcl.bull.fr [129.182.1.20]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id DAA13178 for <[e-mail]>; Thu, 8 Apr 1999 03:15:58 -0700 (PDT)
Received: from k2.frcl.bull.fr (k2.frcl.bull.fr [129.182.100.2]) by clbull.frcl.bull.fr (8.9.1a/8.9.1) with ESMTP id NAA19166; Thu, 8 Apr 1999 13:16:10 +0200
Received: from bull.net (frcls6118.frcl.bull.fr [129.182.109.213]) by k2.frcl.bull.fr (AIX4.2/UCB 8.7/8.7) with ESMTP id NAA44874; Thu, 8 Apr 1999 13:18:15 +0200 (DFT)
Message-ID: <[e-mail]>
Date: Thu, 08 Apr 1999 12:16:54 +0200
From: Denis Pinkas <[e-mail]>
Organization: Bull
X-Mailer: Mozilla 4.06 [fr] (Win95; I)
MIME-Version: 1.0
To: Peter Sylvester <[e-mail]>
CC: [e-mail], [e-mail], [e-mail]
Subject: Re: Time Stamp: tsa field in TSTInfo
References: <[e-mail]>
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 8bit
Content-Transfer-Encoding: 8bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Peter,

I concur with your proposal, ie. use an signed (also called "authenticated")
attribute from ESS that indicates the certificate used by the TSA and suppress the
name of the TSA from the signed structure. This "useful" attribute is indeed in
ESS, not CMS - where it should have been. :-(

Since the verifier will need anyway to get that certificate to verify the
signature, then, at that time, it will get the name of the TSA.

Regards,

Denis


> >
> > Actually, I believe that when using CMS only the content (in this case
> > TSTInfo) is signed along with any authenticated attributes.  Thus, the
> > distinguishing information for the TSA would not be signed if it was not
> > included within the TSTInfo structure.
> If the TST provider want to surely indicate its identity, one
> can use an ess signing certificate attribute.
>
> This seems preferable to me (if the tendancy is avoid to reinvent things).
>
> The ess stuff was probably not avaiable at the time when
> the tst draft was written for the first time.
>
>
> >
> >       Robert.
> >
> > > ----------
> > > From:       Juan Luis López[SMTP:[e-mail]]
> > > Sent:       Wednesday, April 07, 1999 5:25 AM
> > > To:         pkix
> > > Subject:    Time Stamp: tsa field in TSTInfo
> > >
> > >     Hi everybody!
> > >
> > >     I am involved in a Time Stamping project and we are analysing the PKIX
> > > draft about this subject.
> > >
> > >     I would like to give my opinion on an issue to the list:
> > >     It seems not appropriate to include a field in TSTInfo structure
> > > related to the tsa identity, i.e. tsa field. I don't find this field
> > > necessary because it is repeated when using a CMS or PKCS#7 envelope to
> > > encapsulate the token information. This information would be redundant
> > > since an identifier distinguishing the given tsa should be present in the
> > > signerInfo structure.
> > >
> > >     So, I recommend the deletion of this field.
> > >
> > >     Regards,
> > >    Juan Luis López
> > >
> > >
> > >
> > > --------------------------------------------------------------------------
> > > -----------
> > > Juan Luis López                                              <
> > > [e-mail]>
> > > Project Engineer
> > > http://www.fnmt.es/pkits
> > > Fábrica Nacional de Moneda y Timbre             tel: [+34] 91 506 48 40
> > > C/ Juan de Mariana, 17                                  fax: [+34] 91 506
> > > 48 51
> > > E-28045 Madrid, SPAIN
> > >
> >



Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id DAA12773 for ietf-pkix-bks; Thu, 8 Apr 1999 03:10:18 -0700 (PDT)
Received: from clbull.frcl.bull.fr (clbull.frcl.bull.fr [129.182.1.20]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id DAA12281 for <[e-mail]>; Thu, 8 Apr 1999 03:10:08 -0700 (PDT)
Received: from k2.frcl.bull.fr (k2.frcl.bull.fr [129.182.100.2]) by clbull.frcl.bull.fr (8.9.1a/8.9.1) with ESMTP id NAA14996; Thu, 8 Apr 1999 13:10:07 +0200
Received: from bull.net (frcls6118.frcl.bull.fr [129.182.109.213]) by k2.frcl.bull.fr (AIX4.2/UCB 8.7/8.7) with ESMTP id NAA24984; Thu, 8 Apr 1999 13:12:11 +0200 (DFT)
Message-ID: <[e-mail]>
Date: Thu, 08 Apr 1999 12:10:50 +0200
From: Denis Pinkas <[e-mail]>
Organization: Bull
X-Mailer: Mozilla 4.06 [fr] (Win95; I)
MIME-Version: 1.0
To: Robert Zuccherato <[e-mail]>
CC: [e-mail], "'Juan G. de la Vega'" <[e-mail]>
Subject: Re: Time Stamping: comments on nonce field
References: <01E1D01C12D7D211AFC70090273D20B112BD84@sothmxs06>
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 8bit
Content-Transfer-Encoding: 8bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Robert,

Some refinements to your response.

The nonce is there for systems that do not have their own reliable clock and
thus cannot test the freshness of the response by simply looking at the signing
time. This is a replay protection. This has nothing to do whether a hash of the
message is or is not present.

I would make it OPTIONAL both in the request and in the response and maintain
the current text that says: " ...must be present if the similar field in
TimeStampReq is present ..."

Regards,

Denis


> > ----------
> > From:         Juan G. de la Vega[SMTP:[e-mail]]
> > Sent:         Wednesday, April 07, 1999 5:39 AM
> > To:   [e-mail]
> > Subject:      Time Stamping: comments on nonce field
> >
> >         First of all, the declaration of this field in the request and
> > token is somehow incoherent, while the nonce is mandatory in TimeStapReq
> > (it is not declared OPTIONAL), the TimeStampToken´s nonce is OPTIONAL but
> > it is stated that "...must be present if the similar field in TimeStampReq
> > is present..." and hence the clause OPTIONAL is meaningless and confusing
> > for this field shall always be present.
> >
> As I have said in the past, this was a mistake that I made because I did not
> manage to fully include support for TSA production of a "signed time".  This
> would be a token which does not include a nonce or message imprint.  TSA's
> could produce these tokens and make them available (for example on a
> website) for anyone who wants to obtain them.  This will be rectified in the
> upcoming draft.
>
> > I would suggest this field to be declared OPTIONAL both in the request and
> > token or better deleted if we take into account the following:
> >
> >     As far as I understand, a nonce value is present in the request and
> > token in order for the requester to be able to match the responses from
> > the TSA with her requests when using an asynchronous transport. It can be
> > argued that such functionality should be left to the transport layer when
> > required, but furthermore I must say that the nonce is not necessary since
> > matching can be performed using the "messageImprint" field.
> >
> Actually, the reason that the nonce is there and mandatory is to prevent
> replay attacks.  Someone else could have obtained a time stamp on the data
> before your request.  Thus, it is possible that the time stamp you received
> is not "fresh".  Without a nonce, determining the freshness of the timestamp
> is difficult.
>
>         Robert.



Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id CAA10236 for ietf-pkix-bks; Thu, 8 Apr 1999 02:22:08 -0700 (PDT)
Received: from clbull.frcl.bull.fr (clbull.frcl.bull.fr [129.182.1.20]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id CAA10232 for <[e-mail]>; Thu, 8 Apr 1999 02:22:05 -0700 (PDT)
Received: from k2.frcl.bull.fr (k2.frcl.bull.fr [129.182.100.2]) by clbull.frcl.bull.fr (8.9.1a/8.9.1) with ESMTP id MAA15560; Thu, 8 Apr 1999 12:22:25 +0200
Received: from bull.net (frcls6118.frcl.bull.fr [129.182.109.213]) by k2.frcl.bull.fr (AIX4.2/UCB 8.7/8.7) with ESMTP id MAA22286; Thu, 8 Apr 1999 12:24:29 +0200 (DFT)
Message-ID: <[e-mail]>
Date: Thu, 08 Apr 1999 11:23:08 +0200
From: Denis Pinkas <[e-mail]>
Organization: Bull
X-Mailer: Mozilla 4.06 [fr] (Win95; I)
MIME-Version: 1.0
To: Anders Rundgren <[e-mail]>
CC: "'[e-mail]'" <[e-mail]>
Subject: Re: Low-fat leaf certificates
References: <01BE7B7E.2DB86EB0@HYDRA>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Anders,

Your E-mail got burried under hundred of other E-mails. Sorry for the delay to respond.

You misunderstood my talk. I am advocating against numerous extensions to certificates that could be
handled generically by "administrative" certificates that contain information valid for a large number of
leaf certificates.

So the topic you address is unrelated.

Regards,

Denis


> David,
> Just to make sure that you don't misunderstand me:
>
> I am VERY much in favor of your "Low-fat leaf certificates".
>
> That is what CyberPhone is all about.  A CyberID SUBJECT is
> supposed to consist of just two items:
>
> 1)  "Name"  (an alias/friendly name [as you are allowed to change name without changing "e"-identity])
>
> 2) "dnQualifier"  (a static [probably random] unique identifier in the domain)
>
> It is hard to get much slimmer than that!
>
> But a "low-fat" cert may have a "fat" cousin cert that does the dirty work in the
> rare situations that requires it.  And if they can share a common format life will
> be simpler than if all "fat" data has to be handled "out-of-band" instead of in
> nice "structured signed and certified containers of data"
>
> Regards
> Anders
> http://www.mobilephones-tng.com



Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id CAA10087 for ietf-pkix-bks; Thu, 8 Apr 1999 02:06:09 -0700 (PDT)
Received: from natasha1. (natasha-gw.checkpoint.com [199.203.73.129]) by mail.proper.com (8.8.8/8.8.5) with SMTP id CAA10082 for <[e-mail]>; Thu, 8 Apr 1999 02:06:06 -0700 (PDT)
Received: from cale.checkpoint.com (gray.checkpoint.com [199.203.71.94]) by cale.checkpoint.com (8.9.1/8.9.1) with ESMTP id LAA19238; Thu, 8 Apr 1999 11:08:44 +0200 (IST)
Message-ID: <[e-mail]>
Date: Thu, 08 Apr 1999 12:05:06 +0300
From: Moshe Litvin <[e-mail]>
X-Mailer: Mozilla 4.51 [en] (WinNT; I)
X-Accept-Language: en
MIME-Version: 1.0
To: Stephen Kent <[e-mail]>
CC: [e-mail], Stephen Kent <[e-mail]>, [e-mail]
Subject: Re: CA vs. EE cert processing
References: <v04020a17b331af2ed303@[128.33.238.98]>
Content-Type: multipart/mixed; boundary="------------AE38C6DF985690259B2AADF2"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

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



Stephen Kent wrote:

<snip>

> >the first one aside for the moment, PKIX would be a better player in the
> >broader X.509 world if it chose not to generate certificates that are
> >ambiguous to such a world.
>
> The ambiguity exists in ALL verifiers, PKIX or not.  Thus pointing the
> finger at PKIX is not rational.
>

The ambiguity does exist in ALL verifiers, but it doesn't exist in all CA's. A
CA that follows PKIX creates ambiguous certificates. Only CA that does does
something that it SHOULD NOT do create unambiguous certificates. Here pointing
the finger at PKIX is very rational.

We cannot remove the possibility of ambiguity but we can generate certificates
that are not affected by it.

>
> <snip>
>
> >
> >On the contrary, changing RFC 2459 to require the inclusion of the
> >basicConstraints extension on all certificates would help alleviate this
> >ambiguity, and in some cases could completely address it.  As you have
> >pointed out, there is only an ambiguity when processing a certificate
> >without a basicConstraints extension.  By constraining PKIX to avoid
> >generating such certificates, we would avoid any confusion in
> >certificates generated by PKIX systems, whether or not the verifier
> >is PKIX-compliant, and more importantly whether or not the verifier
> >knows that the issuing system was PKIX-compliant.
>
> Changing PKIX to mandate inclusion of basicConstrants would improve the
> odds, but not fix the problem.  I don't view changes that have only
> probabilistic improvements to be warranted, in general, and certainly not
> here.

It is not probabilistic improvements. A CA that put the basicConstraints
extension is 100% not ambiguous. What probablistic about that?

Why discourage CA's from generating unambiguous certificates?

>
>
> >If RFC2459 were modified to require the extension, then it would
> >be permissible for a verifier to make its own decisions about how
> >to handle an ambiguous certificate (one without a basicConstraints
> >extension).  Reasonable options might include rejecting the
> >certificate, asking for user guidance, or applying site-specific
> >policy to determine how to treat it.  The way RFC2459 is currently
> >written, a PKIX verifier doesn't have these options - it must treat
> >such a certificate as an EE certificate, whether or not that's the
> >right thing to do (i.e. whether or not the issuing CA meant the
> >certificate to be an EE or a CA cert).
>
> What is needed is an algorithm for a verifier to use to determine whether a
> cert is an EE cert or a CA cert. We do not have such an algorithm in the
> face of certs that are generated in compliance with X.509, period.  I don't
> want a heuristic improvement here, I want a fix.
>

Adding the extension is not a heuristic improvement, a certificate with the
extension is certificate that doesn't need heuristics period.

Admittedly the verifier will have heuristics but the CA can ensure that they
won't be activated.

>
> <snip>
>
> >
> >The PKIX working group doesn't have the ability to change X.509; we
> >only have control of the PKIX specs.  A change to RFC 2459 would allow
> >us to avoid stumbling into into this ambiguity in X.509, with the result
> >that:
> >
> >i)  PKIX certificates would not be ambiguous to an X.509 verifier,
> >
> >and ii) PKIX verifiers would be able to distinguish ambiguous non-PKIX
> >certs
> >from unambiguous certs, without having to know whether the certificate
> >issuer was PKIX-compliant.
>
> As David Kemp pointed out, we can file a DR to address this problem.
>

X.509 already addresses the problem and suggests:

   It is recommended that it be flagged critical, otherwise an entity which is
not
   authorized to be a CA may issue certificates and a certificate-using system
   may unwittingly use such a certificate.

For some reason PKIX decided to ignore the recommendation and invent it's own
private semantics.

Moshe


--------------AE38C6DF985690259B2AADF2
Content-Type: text/x-vcard; charset=us-ascii;
 name="moshe.vcf"
Content-Transfer-Encoding: 7bit
Content-Description: Card for Moshe Litvin
Content-Disposition: attachment;
 filename="moshe.vcf"

begin:vcard 
n:Litvin;Moshe
tel;fax:[phone]
tel;work:[phone]
x-mozilla-html:TRUE
org:Check Point Software Technologies Ltd.
adr:;;;;;;
version:2.1
email;internet:[e-mail]
fn:Moshe Litvin
end:vcard

--------------AE38C6DF985690259B2AADF2--



Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id BAA09882 for ietf-pkix-bks; Thu, 8 Apr 1999 01:48:54 -0700 (PDT)
Received: from natasha1. (natasha-gw.checkpoint.com [199.203.73.129]) by mail.proper.com (8.8.8/8.8.5) with SMTP id BAA09878 for <[e-mail]>; Thu, 8 Apr 1999 01:48:50 -0700 (PDT)
Received: from cale.checkpoint.com (gray.checkpoint.com [199.203.71.94]) by cale.checkpoint.com (8.9.1/8.9.1) with ESMTP id KAA18085 for <[e-mail]>; Thu, 8 Apr 1999 10:51:35 +0200 (IST)
Message-ID: <[e-mail]>
Date: Thu, 08 Apr 1999 11:47:58 +0300
From: Moshe Litvin <[e-mail]>
X-Mailer: Mozilla 4.51 [en] (WinNT; I)
X-Accept-Language: en
MIME-Version: 1.0
To: [e-mail]
Subject: Re: CA vs. EE cert processing
References: <v04020a18b331b07b2125@[128.33.238.98]>
Content-Type: multipart/mixed; boundary="------------9F583804C3587A1243E4E12E"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

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

Steve,

RFC2459 IS broken in the since the it recommends generating EE certificate that
require out of band information to to know that it not a CA certificate.

Moshe

Stephen Kent wrote:

> Aram,
>
> >My two cents: I agree with John. Given that RFC2459 is not a "standard" yet
> >and thus no standard-compliant software exists out there, we should "fix"
> >RFC2459 to do the right thing for existing legacy software, and the new
> >RFC2459 compliant software.
>
> The right thing is to avoid the ambiguity introduced by X.509; changing
> 2459 cannot fix that.  2459 is not broken, so please don't use the term
> "fix" when referring to it.
>
> Steve

--------------9F583804C3587A1243E4E12E
Content-Type: text/x-vcard; charset=us-ascii;
 name="moshe.vcf"
Content-Transfer-Encoding: 7bit
Content-Description: Card for Moshe Litvin
Content-Disposition: attachment;
 filename="moshe.vcf"

begin:vcard 
n:Litvin;Moshe
tel;fax:[phone]
tel;work:[phone]
x-mozilla-html:TRUE
org:Check Point Software Technologies Ltd.
adr:;;;;;;
version:2.1
email;internet:[e-mail]
fn:Moshe Litvin
end:vcard

--------------9F583804C3587A1243E4E12E--



Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id WAA07360 for ietf-pkix-bks; Wed, 7 Apr 1999 22:28:38 -0700 (PDT)
Received: from dsg1.OpenDirectory.com.au ([203.108.249.145]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id WAA07355 for <[e-mail]>; Wed, 7 Apr 1999 22:28:28 -0700 (PDT)
Received: by DSG1 with Internet Mail Service (5.0.1458.49) id <22ZNQLYG>; Thu, 8 Apr 1999 15:28:38 +1000
Message-ID: <D1A949D4508DD1119C8100400533BEDC0BE96E@DSG1>
From: Alan Lloyd <[e-mail]>
To: "'Stephen Kent'" <[e-mail]>
Cc: [e-mail]
Subject: RE: CA vs. EE cert processing
Date: Thu, 8 Apr 1999 15:28:36 +1000
X-Priority: 3
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.0.1458.49)
Content-Type: text/plain
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Stephen - not to extend this debate - 
X.509 defines that Basic Constraints is used to indicate that the public
key in the cert is valid for testing certificate signatures - by a
certificate using system eg. a client or EE. By definition it means that
in  (eg.) a 3 tier CA model that the root level CA has granted a private
and public key ( in a cert with BC set to CA) to a middle level CA to
issue certificates with and "advertise the fact (in its certificate)
that the root trusts the middle CA to issue certs and for clients to
validate such certs using the middle CAs public key.

It strikes me that any PKIX compliant top level ROOT CA will set this
extension to ensure that the correct PKeys are used to validate certs
which point to itself. However, what the client software does with this
extension is another matter. Both have to be compatable. If an EE in its
validation path gets a cert with which it wants to validate a lower
level certificate with and this extension is not set - it should give up
- if ideology is maintained. However, X.509 permits an exit to this
process to enable a CA path to be built and validated without cert
extensions - simply because that is what they are - optional certificate
extensions.


I see no ambiguity - just flexibility - 2459 can profile this
flexibility out if desired.

regards alan



> -----Original Message-----
> From:	Stephen Kent 
> Sent:	Thursday, April 08, 1999 1:49 AM
> To:	Alan Lloyd
> Cc:	[e-mail]
> Subject:	RE: CA vs. EE cert processing
> 
> Alan,
> 
> I disagree. There is no obvious reason for this base standard to allow
> for
> this ambiguity.   This is not a problem that is out of scope for the
> base
> standard.  we agree, though, that adherence to the 2459 profile
> advoids
> ambiguity.  The reason for this debate is that some folks felt the
> ambiguity was the fault of 2459, whereas the analysis shows it to be
> intrinsic in X.509.  Thus no fix to 2459 will remove the ambiguity.
> 
> steve


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id WAA06958 for ietf-pkix-bks; Wed, 7 Apr 1999 22:16:11 -0700 (PDT)
Received: from smtp.udac.net (smtp.udac.net [193.44.79.123]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id WAA06954 for <[e-mail]>; Wed, 7 Apr 1999 22:16:09 -0700 (PDT)
Received: from caesar.udac.se (caesar.udac.se [193.44.79.10]) by smtp.udac.net (8.9.1/8.9.1) with ESMTP id HAA22618 for <[e-mail]>; Thu, 8 Apr 1999 07:16:53 +0200
Received: from mega (t1o69p95.telia.com [62.20.144.95]) by caesar.udac.se (8.7.3/NetworkC-1) with SMTP id HAA41282; Thu, 8 Apr 1999 07:16:35 +0200
Message-ID: <002401be8187$1a0d4d40$[e-mail]>
From: "Anders Rundgren" <[e-mail]>
To: "Stephen Kent" <[e-mail]>, "Stefan Santesson" <[e-mail]>
Cc: <[e-mail]>, "'SEIS-List'" <[e-mail]>
Subject:  Re: A $25,000,000,000 PKI   Was:Spec. on QC-low-fat & QC-heavy-bio
Date: Thu, 8 Apr 1999 07:14:45 +0100
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.2106.4
X-MimeOLE: Produced By Microsoft MimeOLE V4.72.2106.4
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by mail.proper.com id WAA06955
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Hi Stefan + Steve,

May I ask a question regarding signature laws which I am pretty ignorant of?

If a company runs a SET Wallet Server for their employees to use, is not the company
responsible for signatures produced by the certificate and keys stored on that server?

Legally as well as technically. 

Now to the users (with their CyberPhones) that initiates transactions: They are responsible to
their company that as a minimum records all transations with user identity.  Or
it could require a sign op as well.

Looks OK to me.

So what is so fundamentally flawed in the CyberPhone concept with respect to digital
signature laws?

Regards
Anders
http://www.mobilephones-tng.com




Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id WAA06949 for ietf-pkix-bks; Wed, 7 Apr 1999 22:16:01 -0700 (PDT)
Received: from smtp.udac.net (smtp.udac.net [193.44.79.123]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id WAA06944 for <[e-mail]>; Wed, 7 Apr 1999 22:15:59 -0700 (PDT)
Received: from caesar.udac.se (caesar.udac.se [193.44.79.10]) by smtp.udac.net (8.9.1/8.9.1) with ESMTP id HAA22612 for <[e-mail]>; Thu, 8 Apr 1999 07:16:44 +0200
Received: from mega (t1o69p95.telia.com [62.20.144.95]) by caesar.udac.se (8.7.3/NetworkC-1) with SMTP id HAA41316; Thu, 8 Apr 1999 07:16:40 +0200
Message-ID: <002501be8187$1cdd0f10$[e-mail]>
From: "Anders Rundgren" <[e-mail]>
To: "Stephen Kent" <[e-mail]>
Cc: "Stephen Kent" <[e-mail]>, <[e-mail]>, "'SEIS-List'" <[e-mail]>
Subject: Re: A $25,000,000,000 PKI   Was:Spec. on QC-low-fat & QC-heavy-bio
Date: Thu, 8 Apr 1999 07:14:50 +0100
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.2106.4
X-MimeOLE: Produced By Microsoft MimeOLE V4.72.2106.4
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by mail.proper.com id WAA06946
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Steve,

>I know a numnber of reasons why SET has not been accepted in the U.S., if
>that's the context you're citing, and they are largely independent of the
>issues you cite.  For example, U.S. consumer protection laws make the
>advantages of SET over simple use of SSL and a credit card number
>unattractive to users.

You are absolute right. SET is a European problem currently.

> Since most online merchants can make a fair amount
>of money despite the security limitations (e.g., lack of origin
>non-repudaition) of the current paradigm, there is insufficient motivation
>for them to change to SET.

Right.

>Since most of the purchases over the web are
>done from PCs, the thin n client argument is not relevant.

That is true for the current situation - not for the mobile future though.

Hum, maybe you should take a look on GlobeSet's (a leader in SET) ServerWallet
and see why the developed it.  

>All of our employees have computers, those who travel have laptops.  Not
>all have cell phones.  of the ones that do have cell phones, few would be
>capable opf making use of the certs you describe, i.e., not many are PCS
>phones.


Sure, but I am talking about the year 2003 or so. 


>The solution you propose is definately NOT high quality.

By design?  I am fully convinced (not such a big surprise though :-))  that if
the CyberPhone concept and associated server technology is developed by the best brains
in the industry it could match any quality standards.  Regarding the security model
it is not so far from a PKI-only version of Kerberos which seems to be higly
regarded by security people.

>It is an effort to
>take advantage of devices with limited capabilities, and skew security
>design principles to accommodate these limitations.

CyberPhone does a LOT more than address devices with limited capabilities.
It also addresses certificate management, traceability and transaction logging, 
business transaction models, and last but not least end-user security including
resource loss, revocation, backup and recovery.

<snip>

Regards
Anders
http://www.mobilephones-tng.com




Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id VAA06462 for ietf-pkix-bks; Wed, 7 Apr 1999 21:24:20 -0700 (PDT)
Received: from NOD.RESTON.MCI.NET (nod.Reston.mci.net [166.45.6.38]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id VAA06458 for <[e-mail]>; Wed, 7 Apr 1999 21:24:19 -0700 (PDT)
Received: from mci.net ([166.45.3.11]) by shoe.reston.mci.net (PMDF V5.2-29 #33823) with ESMTP id <[e-mail]> for [e-mail]; Thu, 8 Apr 1999 00:24:29 EDT
Date: Wed, 07 Apr 1999 21:24:26 -0700
From: Paul Krumviede <[e-mail]>
Subject: Re: A $25,000,000,000 PKI   Was:Spec. on QC-low-fat & QC-heavy-bio
To: [e-mail]
Cc: "'SEIS-List'" <[e-mail]>
Message-id: <[e-mail]>
Organization: MCI WorldCom
MIME-version: 1.0
X-Mailer: Mozilla 4.5 [en] (Win98; U)
Content-type: text/plain; charset=us-ascii
Content-transfer-encoding: 7BIT
X-Accept-Language: en
References: <v04020a02b3311debd2da@[128.89.0.111]>
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Stephen Kent wrote:
> 
> Anders,

> >> As I said
> >>before, you should pursue any implementation approach you think is
> >>fruitful, but don't ask this standards body to tailor parts of its work to
> >>facilitate your (decidely nont mainstream) approach to using certs.
> >
> >It COULD  become mainstream...
> >
> >Now we both know pretty well where we stand in this case so
> >could please somebody else comment on this?
> 
> I'm sure they will.

One somebody else's comment:

I'm uncomfortable with the suggested use of certs.

-paul


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id UAA06015 for ietf-pkix-bks; Wed, 7 Apr 1999 20:30:31 -0700 (PDT)
Received: from dsg1.OpenDirectory.com.au ([203.108.249.145]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id UAA06010 for <[e-mail]>; Wed, 7 Apr 1999 20:30:29 -0700 (PDT)
Received: by DSG1 with Internet Mail Service (5.0.1458.49) id <22ZNQLXL>; Thu, 8 Apr 1999 13:31:02 +1000
Message-ID: <D1A949D4508DD1119C8100400533BEDC0BE96C@DSG1>
From: Alan Lloyd <[e-mail]>
To: "'Stephen Kent'" <[e-mail]>
Cc: [e-mail], [e-mail]
Subject: RE: SEIS:  RE: Certificates, Directories, and Distinguished Names
Date: Thu, 8 Apr 1999 13:31:01 +1000
X-Priority: 3
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.0.1458.49)
Content-Type: text/plain
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Yes its is probably best to teminate this discusion - simply because,
and as usual, one asks the harder questions openly eg. Cert Subject and
Issuer Alt names why, when, where?  - and DNS names in certs and the
validation issues.. and the rekey issues (for the real world) because of
organisational and personnel churn (if email addresses are used).. And I
(and others) follow this up with sound experience in dealing with
distributed information engineering (eg directories), validation and
revokation issues and also major global applications that wish to use
PKI functionality ...

what do you get back? not a lot.


One aspect of inventing standards is that should serve at least five
years of development and product introduction into operational  business
systems.

regards alan





> -----Original Message-----
> From:	Stephen Kent 
> Sent:	Thursday, April 08, 1999 10:41 AM
> To:	Alan Lloyd
> Cc:	[e-mail]; [e-mail]
> Subject:	SEIS:  RE: Certificates, Directories, and Distinguished
> Names
> 
> --- Message on the SEIS mailing list ([e-mail])
> 
> Alan,
> 
> We seem to be making no progress wrt this discussion, like many of our
> previous debates.  Let save a few virtual trees and call it quits.
> 
> Steve
> 
> 
> ----------------- SEIS mailing list ([e-mail])
> Info about this list: http://www.nc-forum.com/seis
> SEIS Contact: [e-mail]


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id UAA05807 for ietf-pkix-bks; Wed, 7 Apr 1999 20:08:10 -0700 (PDT)
Received: from dsg1.OpenDirectory.com.au ([203.108.249.145]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id UAA05801 for <[e-mail]>; Wed, 7 Apr 1999 20:08:04 -0700 (PDT)
Received: by DSG1 with Internet Mail Service (5.0.1458.49) id <22ZNQLXF>; Thu, 8 Apr 1999 13:08:21 +1000
Message-ID: <D1A949D4508DD1119C8100400533BEDC0BE96B@DSG1>
From: Alan Lloyd <[e-mail]>
To: "'Tony Bartoletti'" <[e-mail]>, "''Stephen Kent' '" <[e-mail]>
Cc: "'''[e-mail] ' ' '" <[e-mail]>, "'''[e-mail] ' ' '" <[e-mail]>
Subject: RE: Certificates, Directories, and Distinguished Names
Date: Thu, 8 Apr 1999 13:08:21 +1000
X-Priority: 3
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.0.1458.49)
Content-Type: text/plain; charset="iso-8859-1"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Tony, thanks for that. May I address something that has always concerned
me about the view presented of directories.

snips from the text.


> I make an analogy between some folks reluctance to "bank",
> and those who are similarly ill-at-ease allowing what might
> be considered privacy info to be accessible via directories.
	snip
> I see this sentiment "below the surface" when discussions of
> global directories with searchable hierarchical Names are on
> the table.  It suggests a lack of control on the part of the
> data-owner, and no amount of "we can make it real real secure
> with lots of money" will assuage the unease.
> 
	If I said use a "database" for the PKI and personal info - which
has been used all over the planet for the last 25 years - people are
comfortable with that. If I said directory systems - there is an
assumption that the whole planet can read the info regardless.

	Directories - are really a shift in information engineering that
removes the distributed limitations of RDBs and in addition provides a
coherent OO schema approach, a coherent authentication and ACI regime,
use of common protocols for access, distribution and replication nad
many other new properties for engineering distributed systems.
Directories are nothing more than a major advancement in information
storage and information protection technology and provide many common
things that one would have to bespokely engineer with Data base
approaches.

	Why there is this view that X.500 is big,slow, is the worlds one
and only directory (which will never be deployed) and cannot be used for
private data instead of an RDB - astounds me - simply because all that
is so so wrong. All directories are is an evolution in information
engineering for storage and access which should be used to one advantage
and privately if desired  - after all that is what technology
improvements are about.

	I would like to think that those proposing a PKI for the
internet or internet related services see the limitations of trying to
put all ones data in an RDB and try telling a customer - all you need is
this certificate server - in which you have to name things the same way
or a different way to the other 26 databases they have with named items
in.

	The issue of deploying secure information services - in most
cases requires that a major clean up of the 10s of databases and address
books one has with many name forms - first -- real world approaches to
this is directory services (which can be private).

	hope this helps 
	thanks and regards alan
> These concerns seem laughable in the face of the main PKI
> motivations dealt with here, being high-volume internet commerce.
> And yet I am sure there are many who see the promise of security
> (in privacy and identity) in public key technology, and hope to
> see it serve their ends in this way.
> 
> This is not to disparage the notion that directories will
> be deployed and critical in a great many venues.  If my "private"
> information were not lying around on the disks of credit agencies,
> I would have a hard time using all the plastic in my wallet.
> 
> I simply share the feelings of many, I suspect, that commercial
> concerns about how to best use keys and certs will overshadow
> those uses where there are not quick-bucks to be made, and
> that protocols tailored to the commercial uses will force
> others into obscurity.
> 
> Regards,
> 
> ___tony___
>  
> 
> At 07:57 AM 4/8/99 +1000, Alan Lloyd wrote:
> > 
> >Tony - not sure if I understand the thread or the last para.
> >
> >And dont get me wrong either re the value of PKIs. Having worked with
> >directories for about 12 years and PKIs for 5 or so, for real
> >operational business environments I appreciate the standards process,
> >the profiling process and the need to deal with operational models
> which
> >today must include a distributed and consistent information
> management
> >capability.
> >
> >My line of comments try to address a major concern of the PKIX
> process
> >is: that design anchors such as email addresses in certs, databases
> >instead of distributed directory systems, inflexibility in PKI
> profiles
> >because of theory, no recognition that business application (eg
> mobile
> >phones, car tagging, banking, etc) needs to be dealt with in terms of
> >its PKI approach differently and and the need to keep adding things
> in
> >certs that are dynamic in the real world - makes the discussion
> critical
> >to say the least. 
> >
> >As said PKIX is trying to profile X.509.. I have been involved with
> the
> >directory X.500 ISPs for a few years - and that effort was reduced to
> >zero almost because the technology and products surfaced into the
> market
> >place and started dealing with real businesses - and that trying to
> >mandate/option protocol and information fields in tables in standards
> >for all circumstances in global business is impossible.
> >
> >In addition trying to shoe horn one PKI/CA - key management profile/
> >cert processing design for all aspects of trusted transactions -
> which
> >just happen to run over the internet, will also prove to be an
> >impossible task.
> >
> >In addition - who will own the root level key for all this PKIX
> >compliant stuff?
> >
> >As said PKIs will be built like directory services - for business
> >domains  and vertfical markets that provide EC services under the
> >control of those who want to invest in such (PKI supported) services.
> >
> >regards alan
> >
> > 
> >----------
> >From: Tony Bartoletti
> >To: Alan Lloyd; 'Stephen Kent'
> >Cc: ''[e-mail] ' '; ''[e-mail] ' '
> >Sent: 4/8/99 3:26:06 AM
> >Subject: RE: Certificates, Directories, and Distinguished Names
> >
> >Just a General Observation:
> >
> >The "pack-it-in-the-cert"/"pack-it-in-a-directory" debate seems to
> >parallel, in some ways, the recent thread on Anders' "CyberPhone"
> >approach to outsourcing one's private-key handling.
> >
> >And "convenience," indeed, can only be ignored at one's peril (in
> >a business model, at least:)
> >
> >Over all of this, I cannot help but be reminded of those who lived
> >through the Great Depression, and to this day feel uncomfortable
> >placing their money in banks.  They will insist upon dealing in
> >"cash", the kind they can stuff under their mattress, or bury in
> >a steel box in the backyard.  Foolish at it may seem to most, they
> >insist upon being the final arbiters of their security/destiny,
> >however ill-equipped to the task they may be.
> >
> >No amount of argument that, statistically, their money would be
> >safer in a bank, or as bits-on-a-disk, will dissuade them.
> >(And who knows, in the long run, if they will be wrong or right?)
> >
> >Must we promote a world so hostile to these individualists (they
> >are many, if not majority) that they become shut-out of the future
> >benefits that PKIs may afford?
> >
> >Is this concern not a silent undercurrent to many of these debates?
> >
> >___tony___
> >
> >
> >
> >Tony Bartoletti                                             LL
> >Center for Information Operations and Assurance          LL LL
> >Lawrence Livermore National Laboratory                LL LL LL
> >PO Box 808, L - 303                                   LL LL LL
> >Livermore, CA 94551-9900                              LL LL LLLLLLLL
> >phone: [phone]   fax: [phone]               LL LLLLLLLL
> >email: [e-mail]                                   LLLLLLLL
> >
> >
> >
> 
> Tony Bartoletti                                             LL
> Center for Information Operations and Assurance          LL LL
> Lawrence Livermore National Laboratory                LL LL LL
> PO Box 808, L - 303                                   LL LL LL
> Livermore, CA 94551-9900                              LL LL LLLLLLLL
> phone: [phone]   fax: [phone]               LL LLLLLLLL
> email: [e-mail]                                   LLLLLLLL


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id TAA05310 for ietf-pkix-bks; Wed, 7 Apr 1999 19:03:32 -0700 (PDT)
Received: from stargate.zergo.com.au ([e-mail] [203.2.208.130]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id TAA05306 for <[e-mail]>; Wed, 7 Apr 1999 19:03:28 -0700 (PDT)
Received: from michaelz (dhcp-64.ws.zergo.com.au [192.168.72.64]) by stargate.zergo.com.au (8.9.1/8.8.7) with SMTP id MAA00519 for <[e-mail] >; Thu, 8 Apr 1999 12:03:16 +1000
Received: by localhost with Microsoft MAPI; Thu, 8 Apr 1999 12:03:34 +1000
Message-ID: <[e-mail]>
From: Michael Zolotarev <[e-mail]>
Reply-To: "[e-mail]" <[e-mail]>
To: "'PKIX mailing group'" <[e-mail]>
Subject: CMP message format. A naive question
Date: Thu, 8 Apr 1999 12:03:32 +1000
Organization: Baltimore Pty Ltd
X-Mailer: Microsoft Internet E-mail/MAPI - 8.0.0.4211
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

The CMP message format can be very appropriately used  for non-cert-related 
PKI services, such as TimeStamping, AttributeCertificates, DCS etc


Q1. Are there any reasons (technical, patent-related, religious,...) why 
the CMP message structure can not or should not be used for non-CMP PKI 
services?
Q2. If the CMP format can be legitimately used for non-certificate 
management protocol operations, then what would be the IDs for the new 
PKIBody content? Has anybody sorted out or reserved the IDs above [23]?
Q3. What would be the name to use, when it is not a Cert Mgm Prot-related 
message any longer?. "Generic PKI Message Format" (GPMF)?

Michael Z


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id SAA04916 for ietf-pkix-bks; Wed, 7 Apr 1999 18:16:04 -0700 (PDT)
Received: from po1.bbn.com (PO1.BBN.COM [192.1.50.38]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id SAA04911 for <[e-mail]>; Wed, 7 Apr 1999 18:16:02 -0700 (PDT)
Received: from [128.33.238.98] (TC082.BBN.COM [128.33.238.82]) by po1.bbn.com (8.9.1/8.9.1) with ESMTP id VAA00466; Wed, 7 Apr 1999 21:16:43 -0400 (EDT)
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Message-Id: <v04020a18b331b07b2125@[128.33.238.98]>
In-Reply-To: <[e-mail]>
Date: Wed, 7 Apr 1999 21:03:33 -0400
To: "Aram Perez" <[e-mail]>
From: Stephen Kent <[e-mail]>
Subject: Re: CA vs. EE cert processing
Cc: [e-mail]
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Aram,

>My two cents: I agree with John. Given that RFC2459 is not a "standard" yet
>and thus no standard-compliant software exists out there, we should "fix"
>RFC2459 to do the right thing for existing legacy software, and the new
>RFC2459 compliant software.

The right thing is to avoid the ambiguity introduced by X.509; changing
2459 cannot fix that.  2459 is not broken, so please don't use the term
"fix" when referring to it.

Steve


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id SAA04909 for ietf-pkix-bks; Wed, 7 Apr 1999 18:15:59 -0700 (PDT)
Received: from po1.bbn.com (PO1.BBN.COM [192.1.50.38]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id SAA04905 for <[e-mail]>; Wed, 7 Apr 1999 18:15:58 -0700 (PDT)
Received: from [128.33.238.98] (TC082.BBN.COM [128.33.238.82]) by po1.bbn.com (8.9.1/8.9.1) with ESMTP id VAA00454; Wed, 7 Apr 1999 21:16:39 -0400 (EDT)
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Message-Id: <v04020a17b331af2ed303@[128.33.238.98]>
In-Reply-To: <[e-mail]>
Date: Wed, 7 Apr 1999 21:01:05 -0400
To: [e-mail]
From: Stephen Kent <[e-mail]>
Subject: Re: CA vs. EE cert processing
Cc: Stephen Kent <[e-mail]>, [e-mail]
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

John,

<snip>

>There are two parts to "this ambiguity".  The one as stated where a PKIX
>verifier encounters a certificate without a basicConstraints extension, and
>another one where a non-PKIX verifier encounters such a certificate.
>Leaving
>the first one aside for the moment, PKIX would be a better player in the
>broader X.509 world if it chose not to generate certificates that are
>ambiguous to such a world.

The ambiguity exists in ALL verifiers, PKIX or not.  Thus pointing the
finger at PKIX is not rational.

<snip>

>
>On the contrary, changing RFC 2459 to require the inclusion of the
>basicConstraints extension on all certificates would help alleviate this
>ambiguity, and in some cases could completely address it.  As you have
>pointed out, there is only an ambiguity when processing a certificate
>without a basicConstraints extension.  By constraining PKIX to avoid
>generating such certificates, we would avoid any confusion in
>certificates generated by PKIX systems, whether or not the verifier
>is PKIX-compliant, and more importantly whether or not the verifier
>knows that the issuing system was PKIX-compliant.

Changing PKIX to mandate inclusion of basicConstrants would improve the
odds, but not fix the problem.  I don't view changes that have only
probabilistic improvements to be warranted, in general, and certainly not
here.

>If RFC2459 were modified to require the extension, then it would
>be permissible for a verifier to make its own decisions about how
>to handle an ambiguous certificate (one without a basicConstraints
>extension).  Reasonable options might include rejecting the
>certificate, asking for user guidance, or applying site-specific
>policy to determine how to treat it.  The way RFC2459 is currently
>written, a PKIX verifier doesn't have these options - it must treat
>such a certificate as an EE certificate, whether or not that's the
>right thing to do (i.e. whether or not the issuing CA meant the
>certificate to be an EE or a CA cert).

What is needed is an algorithm for a verifier to use to determine whether a
cert is an EE cert or a CA cert. We do not have such an algorithm in the
face of certs that are generated in compliance with X.509, period.  I don't
want a heuristic improvement here, I want a fix.

<snip>

>
>The PKIX working group doesn't have the ability to change X.509; we
>only have control of the PKIX specs.  A change to RFC 2459 would allow
>us to avoid stumbling into into this ambiguity in X.509, with the result
>that:
>
>i)  PKIX certificates would not be ambiguous to an X.509 verifier,
>
>and ii) PKIX verifiers would be able to distinguish ambiguous non-PKIX
>certs
>from unambiguous certs, without having to know whether the certificate
>issuer was PKIX-compliant.

As David Kemp pointed out, we can file a DR to address this problem.

Steve


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id RAA04544 for ietf-pkix-bks; Wed, 7 Apr 1999 17:40:34 -0700 (PDT)
Received: from po1.bbn.com (PO1.BBN.COM [192.1.50.38]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id RAA04540 for <[e-mail]>; Wed, 7 Apr 1999 17:40:33 -0700 (PDT)
Received: from [128.33.238.98] (TC098.BBN.COM [128.33.238.98]) by po1.bbn.com (8.9.1/8.9.1) with ESMTP id UAA25061; Wed, 7 Apr 1999 20:40:43 -0400 (EDT)
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Message-Id: <v04020a01b3311d77b7a5@[128.89.0.111]>
In-Reply-To: <D1A949D4508DD1119C8100400533BEDC0BE968@DSG1>
Date: Wed, 7 Apr 1999 20:40:47 -0400
To: Alan Lloyd <[e-mail]>
From: Stephen Kent <[e-mail]>
Subject: RE: Certificates, Directories, and Distinguished Names
Cc: <[e-mail]>, <[e-mail]>
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Alan,

We seem to be making no progress wrt this discussion, like many of our
previous debates.  Let save a few virtual trees and call it quits.

Steve


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id RAA04516 for ietf-pkix-bks; Wed, 7 Apr 1999 17:38:34 -0700 (PDT)
Received: from poptop.llnl.gov (poptop.llnl.gov [128.115.18.65]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id RAA04512 for <[e-mail]>; Wed, 7 Apr 1999 17:38:34 -0700 (PDT)
Received: from catalyst (catalyst.llnl.gov [128.115.223.10]) by poptop.llnl.gov (8.8.8/LLNL-3.0.2/pop.llnl.gov-5.1) with SMTP id RAA17258; Wed, 7 Apr 1999 17:38:49 -0700 (PDT)
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.3 (32)
Date: Wed, 07 Apr 1999 17:38:20 -0700
To: Alan Lloyd <[e-mail]>, "''Stephen Kent' '" <[e-mail]>
From: Tony Bartoletti <[e-mail]>
Subject: RE: Certificates, Directories, and Distinguished Names
Cc: "'''[e-mail] ' ' '" <[e-mail]>, "'''[e-mail] ' ' '" <[e-mail]>
In-Reply-To: <D1A949D4508DD1119C8100400533BEDC0DDB8A@DSG1>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Alan,

I try here to accomodate viewpoints that are often at odds,
judging from the long life these threads exhibit.

I make an analogy between some folks reluctance to "bank",
and those who are similarly ill-at-ease allowing what might
be considered privacy info to be accessible via directories.

Granted, I might be foolish to think my money is safer under
my pillow (in general) than as bits on a magnetic disk far
far away.  I am more likely to be robbed at home than to
have my account drained by a nefarious bank-insider.

Yet some still insist on having their "gold" in their own
hands, where they can see it and control it, directly and
absolutely.

I see this sentiment "below the surface" when discussions of
global directories with searchable hierarchical Names are on
the table.  It suggests a lack of control on the part of the
data-owner, and no amount of "we can make it real real secure
with lots of money" will assuage the unease.

Alot of folks, like the "bank-non-trustors" are less worried
about abuses perpetrated by their neighbors, or even by the
individual stranger, than they are by the power of the state.

The (US) second amendment, once a form of balance to that
power, is clearly impotent by orders of magnitude.  Yet the
people have one card that almost no amount of power can
abuse, and that is cryptography, and by allowance unforgeable
identity.  They can jail or torture me, but it is in my power
to relinquish the key or not.

These concerns seem laughable in the face of the main PKI
motivations dealt with here, being high-volume internet commerce.
And yet I am sure there are many who see the promise of security
(in privacy and identity) in public key technology, and hope to
see it serve their ends in this way.

This is not to disparage the notion that directories will
be deployed and critical in a great many venues.  If my "private"
information were not lying around on the disks of credit agencies,
I would have a hard time using all the plastic in my wallet.

I simply share the feelings of many, I suspect, that commercial
concerns about how to best use keys and certs will overshadow
those uses where there are not quick-bucks to be made, and
that protocols tailored to the commercial uses will force
others into obscurity.

Regards,

___tony___
 

At 07:57 AM 4/8/99 +1000, Alan Lloyd wrote:
> 
>Tony - not sure if I understand the thread or the last para.
>
>And dont get me wrong either re the value of PKIs. Having worked with
>directories for about 12 years and PKIs for 5 or so, for real
>operational business environments I appreciate the standards process,
>the profiling process and the need to deal with operational models which
>today must include a distributed and consistent information management
>capability.
>
>My line of comments try to address a major concern of the PKIX process
>is: that design anchors such as email addresses in certs, databases
>instead of distributed directory systems, inflexibility in PKI profiles
>because of theory, no recognition that business application (eg mobile
>phones, car tagging, banking, etc) needs to be dealt with in terms of
>its PKI approach differently and and the need to keep adding things in
>certs that are dynamic in the real world - makes the discussion critical
>to say the least. 
>
>As said PKIX is trying to profile X.509.. I have been involved with the
>directory X.500 ISPs for a few years - and that effort was reduced to
>zero almost because the technology and products surfaced into the market
>place and started dealing with real businesses - and that trying to
>mandate/option protocol and information fields in tables in standards
>for all circumstances in global business is impossible.
>
>In addition trying to shoe horn one PKI/CA - key management profile/
>cert processing design for all aspects of trusted transactions - which
>just happen to run over the internet, will also prove to be an
>impossible task.
>
>In addition - who will own the root level key for all this PKIX
>compliant stuff?
>
>As said PKIs will be built like directory services - for business
>domains  and vertfical markets that provide EC services under the
>control of those who want to invest in such (PKI supported) services.
>
>regards alan
>
> 
>----------
>From: Tony Bartoletti
>To: Alan Lloyd; 'Stephen Kent'
>Cc: ''[e-mail] ' '; ''[e-mail] ' '
>Sent: 4/8/99 3:26:06 AM
>Subject: RE: Certificates, Directories, and Distinguished Names
>
>Just a General Observation:
>
>The "pack-it-in-the-cert"/"pack-it-in-a-directory" debate seems to
>parallel, in some ways, the recent thread on Anders' "CyberPhone"
>approach to outsourcing one's private-key handling.
>
>And "convenience," indeed, can only be ignored at one's peril (in
>a business model, at least:)
>
>Over all of this, I cannot help but be reminded of those who lived
>through the Great Depression, and to this day feel uncomfortable
>placing their money in banks.  They will insist upon dealing in
>"cash", the kind they can stuff under their mattress, or bury in
>a steel box in the backyard.  Foolish at it may seem to most, they
>insist upon being the final arbiters of their security/destiny,
>however ill-equipped to the task they may be.
>
>No amount of argument that, statistically, their money would be
>safer in a bank, or as bits-on-a-disk, will dissuade them.
>(And who knows, in the long run, if they will be wrong or right?)
>
>Must we promote a world so hostile to these individualists (they
>are many, if not majority) that they become shut-out of the future
>benefits that PKIs may afford?
>
>Is this concern not a silent undercurrent to many of these debates?
>
>___tony___
>
>
>
>Tony Bartoletti                                             LL
>Center for Information Operations and Assurance          LL LL
>Lawrence Livermore National Laboratory                LL LL LL
>PO Box 808, L - 303                                   LL LL LL
>Livermore, CA 94551-9900                              LL LL LLLLLLLL
>phone: [phone]   fax: [phone]               LL LLLLLLLL
>email: [e-mail]                                   LLLLLLLL
>
>
>

Tony Bartoletti                                             LL
Center for Information Operations and Assurance          LL LL
Lawrence Livermore National Laboratory                LL LL LL
PO Box 808, L - 303                                   LL LL LL
Livermore, CA 94551-9900                              LL LL LLLLLLLL
phone: [phone]   fax: [phone]               LL LLLLLLLL
email: [e-mail]                                   LLLLLLLL


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id RAA04501 for ietf-pkix-bks; Wed, 7 Apr 1999 17:37:01 -0700 (PDT)
Received: from po1.bbn.com (PO1.BBN.COM [192.1.50.38]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id RAA04497 for <[e-mail]>; Wed, 7 Apr 1999 17:37:00 -0700 (PDT)
Received: from [128.33.238.98] (TC098.BBN.COM [128.33.238.98]) by po1.bbn.com (8.9.1/8.9.1) with ESMTP id UAA24197; Wed, 7 Apr 1999 20:37:26 -0400 (EDT)
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Message-Id: <v04020a06b3312dbcd617@[128.89.0.111]>
In-Reply-To: <D1A949D4508DD1119C8100400533BEDC0BE969@DSG1>
Date: Wed, 7 Apr 1999 11:48:39 -0400
To: Alan Lloyd <[e-mail]>
From: Stephen Kent <[e-mail]>
Subject: RE: CA vs. EE cert processing
Cc: [e-mail]
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Alan,

I disagree. There is no obvious reason for this base standard to allow for
this ambiguity.   This is not a problem that is out of scope for the base
standard.  we agree, though, that adherence to the 2459 profile advoids
ambiguity.  The reason for this debate is that some folks felt the
ambiguity was the fault of 2459, whereas the analysis shows it to be
intrinsic in X.509.  Thus no fix to 2459 will remove the ambiguity.

steve


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id RAA04495 for ietf-pkix-bks; Wed, 7 Apr 1999 17:36:55 -0700 (PDT)
Received: from po1.bbn.com (PO1.BBN.COM [192.1.50.38]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id RAA04490 for <[e-mail]>; Wed, 7 Apr 1999 17:36:52 -0700 (PDT)
Received: from [128.33.238.98] (TC098.BBN.COM [128.33.238.98]) by po1.bbn.com (8.9.1/8.9.1) with ESMTP id UAA24205; Wed, 7 Apr 1999 20:37:29 -0400 (EDT)
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Message-Id: <v04020a07b3312f242ad0@[128.89.0.111]>
In-Reply-To: <001c01be80b8$52da0430$[e-mail]>
Date: Wed, 7 Apr 1999 20:29:35 -0400
To: "Anders Rundgren" <[e-mail]>
From: Stephen Kent <[e-mail]>
Subject: Re: A $25,000,000,000 PKI   Was:Spec. on QC-low-fat & QC-heavy-bio
Cc: "Stephen Kent" <[e-mail]>, "Stefan Santesson" <[e-mail]>, <[e-mail]>, "'SEIS-List'" <[e-mail]>
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Anders,

>Initially PKI was about certs and global X500 directories - Did not happen
>
>Now it is zillions of certs distributed in various ways - Slow deployment
>
>So I do really believe there is room for a "third wave"

If the "third wave" does not match the PKIX model, you may wish to form a
WG to produces standards suited specifically to it.  The SPKI folks have
made space available.

Steve


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id RAA04488 for ietf-pkix-bks; Wed, 7 Apr 1999 17:36:41 -0700 (PDT)
Received: from po1.bbn.com (PO1.BBN.COM [192.1.50.38]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id RAA04484 for <[e-mail]>; Wed, 7 Apr 1999 17:36:39 -0700 (PDT)
Received: from [128.33.238.98] (TC098.BBN.COM [128.33.238.98]) by po1.bbn.com (8.9.1/8.9.1) with ESMTP id UAA24183; Wed, 7 Apr 1999 20:37:17 -0400 (EDT)
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Message-Id: <v04020a02b3311debd2da@[128.89.0.111]>
In-Reply-To: <00b501be8087$962bdd70$[e-mail]>
Date: Wed, 7 Apr 1999 20:28:18 -0400
To: "Anders Rundgren" <[e-mail]>
From: Stephen Kent <[e-mail]>
Subject: Re: A $25,000,000,000 PKI   Was:Spec. on QC-low-fat & QC-heavy-bio
Cc: "Stephen Kent" <[e-mail]>, <[e-mail]>, "'SEIS-List'" <[e-mail]>
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Anders,

>> Nobody has a lot of experience with large
>>scale deployment of PKIs in these contexts, so a statement about the
>>relative difficulties of deployment of certs to end users vs. the approach
>>you propose is premature. Insecure servers are a growing problem for
>>businesses, so I also challange your second assertion.
>
>SET is an example of a large-scale PKI deployment that has _almost_
>flopped due to some of the factors that CyberPhone solves. Like:
>
>Certificate distribution
>Thin client sw
>Mobile universal usage

I know a numnber of reasons why SET has not been accepted in the U.S., if
that's the context you're citing, and they are largely independent of the
issues you cite.  For example, U.S. consumer protection laws make the
advantages of SET over simple use of SSL and a credit card number
unattractive to users.  Since most online merchants can make a fair amount
of money despite the security limitations (e.g., lack of origin
non-repudaition) of the current paradigm, there is insufficient motivation
for them to change to SET.  Since most of the purchases over the web are
done from PCs, the thin n client argument is not relevant.

><large snip>
>>Finally, your proposal is clearly focused on one particular deployment
>>model, which may or may not be realized.  There are others, based on more
>>computationally capable, mobile, personal devices, e.g., PDAs.
>
>Computationally capable devices do not solve
>client certificate or client software distribution.

Most of the client cert distribution problems I've had client discuss are
not solved by your proposal, merely through centralization of certificate
storage and by having a server act as a proxy for applying signatures.

>The market for mobile phones is so much bigger than for other
>devices (PDAs, PCs) etc. so IF this solution gets wide acceptance on
>the mobile phone market - most other client PKI solutions MAY just die.
>I.e. why pay additional money for certs, readers, software if your
>employees already have a high-quality solution in their hands?

All of our employees have computers, those who travel have laptops.  Not
all have cell phones.  of the ones that do have cell phones, few would be
capable opf making use of the certs you describe, i.e., not many are PCS
phones.

The solution you propose is definately NOT high quality. It is an effort to
take advantage of devices with limited capabilities, and skew security
design principles to accommodate these limitations.  Such an approach might
be commercially successful; as others have pointed out, convenience and
good marketing often win out over other factors.  But that doesn't mean we
have to
skew our standards to embrace such approaches.

>BTW, why do you think MSFT is so interested in the mobile phone market?
>Because it is there the future of IT is happening!

Microsoft is interested in almost everything; after missing the Internet's
initial surge they hedge their bets extensively, a luxury that comes from
having so much money to play with.

>> As I said
>>before, you should pursue any implementation approach you think is
>>fruitful, but don't ask this standards body to tailor parts of its work to
>>facilitate your (decidely nont mainstream) approach to using certs.
>
>It COULD  become mainstream...
>
>Now we both know pretty well where we stand in this case so
>could please somebody else comment on this?

I'm sure they will.

Steve


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id QAA03819 for ietf-pkix-bks; Wed, 7 Apr 1999 16:27:35 -0700 (PDT)
Received: from stargate.zergo.com.au ([e-mail] [203.2.208.130]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id QAA03815 for <[e-mail]>; Wed, 7 Apr 1999 16:27:33 -0700 (PDT)
Received: from michaelz (dhcp-64.ws.zergo.com.au [192.168.72.64]) by stargate.zergo.com.au (8.9.1/8.8.7) with SMTP id JAA29356; Thu, 8 Apr 1999 09:26:56 +1000
Received: by localhost with Microsoft MAPI; Thu, 8 Apr 1999 09:27:15 +1000
Message-ID: <[e-mail]>
From: Michael Zolotarev <[e-mail]>
Reply-To: "[e-mail]" <[e-mail]>
To: "'Robert Zuccherato'" <[e-mail]>, "'Juan Luis Lopez'" <[e-mail]>
Cc: "'[e-mail]'" <[e-mail]>
Subject: RE: Time Stamp: tsa field in TSTInfo
Date: Thu, 8 Apr 1999 09:27:12 +1000
Organization: Baltimore Pty Ltd
X-Mailer: Microsoft Internet E-mail/MAPI - 8.0.0.4211
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

The core time stamp information can be used indirectly, as a field inside 
some third party WhateverService (WS) structure. Even (!) if this WS 
structure gets signed/ enveloped, the signer is not going to be the TSA. 
DCS as it stands now may serve as an example.

So, having tsa inside the TSTInfo may come as a useful thing - the WS 
clients may still want to know the TimeStamp's origin.

Michael Zolotarev
Technical Architect
Baltimore Technologies Limited (Australia)



Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id OAA02863 for ietf-pkix-bks; Wed, 7 Apr 1999 14:57:10 -0700 (PDT)
Received: from dsg1.OpenDirectory.com.au ([203.108.249.145]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id OAA02855 for <[e-mail]>; Wed, 7 Apr 1999 14:57:02 -0700 (PDT)
Received: by DSG1 with Internet Mail Service (5.0.1458.49) id <22ZNQLV2>; Thu, 8 Apr 1999 07:57:29 +1000
Message-ID: <D1A949D4508DD1119C8100400533BEDC0DDB8A@DSG1>
From: Alan Lloyd <[e-mail]>
To: "''Stephen Kent' '" <[e-mail]>, "'Tony Bartoletti '" <[e-mail]>
Cc: "'''[e-mail] ' ' '" <[e-mail]>, "'''[e-mail] ' ' '" <[e-mail]>
Subject: RE: Certificates, Directories, and Distinguished Names
Date: Thu, 8 Apr 1999 07:57:28 +1000
X-Priority: 3
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.0.1458.49)
Content-Type: text/plain
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

 
Tony - not sure if I understand the thread or the last para.

And dont get me wrong either re the value of PKIs. Having worked with
directories for about 12 years and PKIs for 5 or so, for real
operational business environments I appreciate the standards process,
the profiling process and the need to deal with operational models which
today must include a distributed and consistent information management
capability.

My line of comments try to address a major concern of the PKIX process
is: that design anchors such as email addresses in certs, databases
instead of distributed directory systems, inflexibility in PKI profiles
because of theory, no recognition that business application (eg mobile
phones, car tagging, banking, etc) needs to be dealt with in terms of
its PKI approach differently and and the need to keep adding things in
certs that are dynamic in the real world - makes the discussion critical
to say the least. 

As said PKIX is trying to profile X.509.. I have been involved with the
directory X.500 ISPs for a few years - and that effort was reduced to
zero almost because the technology and products surfaced into the market
place and started dealing with real businesses - and that trying to
mandate/option protocol and information fields in tables in standards
for all circumstances in global business is impossible.

In addition trying to shoe horn one PKI/CA - key management profile/
cert processing design for all aspects of trusted transactions - which
just happen to run over the internet, will also prove to be an
impossible task.

In addition - who will own the root level key for all this PKIX
compliant stuff?

As said PKIs will be built like directory services - for business
domains  and vertfical markets that provide EC services under the
control of those who want to invest in such (PKI supported) services.

regards alan

 
----------
From: Tony Bartoletti
To: Alan Lloyd; 'Stephen Kent'
Cc: ''[e-mail] ' '; ''[e-mail] ' '
Sent: 4/8/99 3:26:06 AM
Subject: RE: Certificates, Directories, and Distinguished Names

Just a General Observation:

The "pack-it-in-the-cert"/"pack-it-in-a-directory" debate seems to
parallel, in some ways, the recent thread on Anders' "CyberPhone"
approach to outsourcing one's private-key handling.

And "convenience," indeed, can only be ignored at one's peril (in
a business model, at least:)

Over all of this, I cannot help but be reminded of those who lived
through the Great Depression, and to this day feel uncomfortable
placing their money in banks.  They will insist upon dealing in
"cash", the kind they can stuff under their mattress, or bury in
a steel box in the backyard.  Foolish at it may seem to most, they
insist upon being the final arbiters of their security/destiny,
however ill-equipped to the task they may be.

No amount of argument that, statistically, their money would be
safer in a bank, or as bits-on-a-disk, will dissuade them.
(And who knows, in the long run, if they will be wrong or right?)

Must we promote a world so hostile to these individualists (they
are many, if not majority) that they become shut-out of the future
benefits that PKIs may afford?

Is this concern not a silent undercurrent to many of these debates?

___tony___



Tony Bartoletti                                             LL
Center for Information Operations and Assurance          LL LL
Lawrence Livermore National Laboratory                LL LL LL
PO Box 808, L - 303                                   LL LL LL
Livermore, CA 94551-9900                              LL LL LLLLLLLL
phone: [phone]   fax: [phone]               LL LLLLLLLL
email: [e-mail]                                   LLLLLLLL



Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id NAA01881 for ietf-pkix-bks; Wed, 7 Apr 1999 13:11:14 -0700 (PDT)
Received: from prv-mail20.provo.novell.com (prv-mail20.Provo.Novell.COM [137.65.40.4]) by mail.proper.com (8.8.8/8.8.5) with SMTP id NAA01877 for <[e-mail]>; Wed, 7 Apr 1999 13:11:13 -0700 (PDT)
Received: from INET-PRV-Message_Server by prv-mail20.provo.novell.com with Novell_GroupWise; Wed, 07 Apr 1999 14:11:06 -0600
Message-Id: <[e-mail]>
X-Mailer: Novell GroupWise 5.5
Date: Wed, 07 Apr 1999 14:10:52 -0600
From: "Bob Jueneman" <[e-mail]>
To: <[e-mail]>, <[e-mail]>, <[e-mail]>
Cc: <[e-mail]>, <[e-mail]>
Subject: SEIS:  RE: Certificates, Directories, and Distinguished Names
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 mail.proper.com id NAA01878
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Tony is right on with respect to the concerns that some individuals 
will have with respect to technology.  When ATMs and direct deposit
technology first emerged, it was the accountants and finance managers
within some companies that were the most doubting Thomas's.

Certainly as we get closer to Y2K, there are a fairly sizeable number
of people who are buying gold and platinum double eagles rather
than trusting a fractional deposit banking system, and who can say
at this time whether they are right or wrong.

I spend a fairly significant amount of my time engaging with various 
attorneys and legislators and debating the relative risk/benefit
of PKI in general, and the risk of a compromise of Grandma's 
private key in particular, and I can testify that the is a large portion 
of the highly influential public that is not yet sold.

Of course from my perspective they are straining at gnats and 
swallowing camels -- they are concerned that a virus could 
somehow compromise a private key, but at the same time they 
willing allow a typed document on a letterhead to serve as a legally 
binding signature, not to mention a faxed signature or simply a fax
with an automatically inserted origination code on the top of the 
page.

They will undoubtedly come around -- I remember with some shock 
the first time I went to a legal meeting and all of the attorneys had
laptops and there were not legal pads in sight.

But until that day comes, they are the folks that are writing the laws, 
not us, much as I try to play gadfly in that community.

Bob



>--- Message on the SEIS mailing list ([e-mail])
>
>Just a General Observation:
>
>The "pack-it-in-the-cert"/"pack-it-in-a-directory" debate seems to
>parallel, in some ways, the recent thread on Anders' "CyberPhone"
>approach to outsourcing one's private-key handling.
>
>And "convenience," indeed, can only be ignored at one's peril (in
>a business model, at least:)
>
>Over all of this, I cannot help but be reminded of those who lived
>through the Great Depression, and to this day feel uncomfortable
>placing their money in banks.  They will insist upon dealing in
>"cash", the kind they can stuff under their mattress, or bury in
>a steel box in the backyard.  Foolish at it may seem to most, they
>insist upon being the final arbiters of their security/destiny,
>however ill-equipped to the task they may be.
>
>No amount of argument that, statistically, their money would be
>safer in a bank, or as bits-on-a-disk, will dissuade them.
>(And who knows, in the long run, if they will be wrong or right?)
>
>Must we promote a world so hostile to these individualists (they
>are many, if not majority) that they become shut-out of the future
>benefits that PKIs may afford?
>
>Is this concern not a silent undercurrent to many of these debates?
>
>___tony___
>
>
>
>Tony Bartoletti                                             LL
>Center for Information Operations and Assurance          LL LL
>Lawrence Livermore National Laboratory                LL LL LL
>PO Box 808, L - 303                                   LL LL LL
>Livermore, CA 94551-9900                              LL LL LLLLLLLL
>phone: [phone]   fax: [phone]               LL LLLLLLLL
>email: [e-mail]                                   LLLLLLLL
>
>
>----------------- SEIS mailing list ([e-mail])
>Info about this list: http://www.nc-forum.com/seis 
>SEIS Contact: [e-mail] 
>




Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id MAA01729 for ietf-pkix-bks; Wed, 7 Apr 1999 12:46:26 -0700 (PDT)
Received: from smtp.udac.net (smtp.udac.net [193.44.79.123]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id MAA01725 for <[e-mail]>; Wed, 7 Apr 1999 12:46:24 -0700 (PDT)
Received: from caesar.udac.se (caesar.udac.se [193.44.79.10]) by smtp.udac.net (8.9.1/8.9.1) with ESMTP id VAA18337 for <[e-mail]>; Wed, 7 Apr 1999 21:46:59 +0200
Received: from mega (t1o69p54.telia.com [62.20.144.54]) by caesar.udac.se (8.7.3/NetworkC-1) with SMTP id VAA111991; Wed, 7 Apr 1999 21:46:50 +0200
Message-ID: <004401be8137$81e47510$[e-mail]>
From: "Anders Rundgren" <[e-mail]>
To: "Stefan Santesson" <[e-mail]>
Cc: <[e-mail]>, "'SEIS-List'" <[e-mail]>
Subject: Re: A $25,000,000,000 PKI   Was:Spec. on QC-low-fat & QC-heavy-bio
Date: Wed, 7 Apr 1999 21:45:00 +0100
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.2106.4
X-MimeOLE: Produced By Microsoft MimeOLE V4.72.2106.4
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by mail.proper.com id MAA01726
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Is this a battle between two Swedes only? Come on guys!

Stefan, my original spec on the low-fat/heavy-bio, did never got a reaction.

<snip>

>The thing that interests me is who have the exclusive right to use the key,
>and that this right is protected. 

Agreed, except that I don't see why such a right should/must be exclusive.

>>2) I think that the thin client solution has more with sw distribution which
>>is a true bottleneck recognized by most of the IT-industry 
>
>You are solving yesterdays problems. 
>
>The problem with exporting client software is a general problem which a
>whole industry is working on. Java is one step along the line and we will
>see more and better solutions. In a world where bandwidth are increasing we
>will se more of "download what you need, when you need it" type of
>approaches. 

You are almost right.  Security-critical sw developed by several different 
companies requires signed code that you must trust.  This complicates
things considerably.  My approach does probably (not 100% sure here since
CyberPhone is currently only a glossy broschyre) NOT require download
of security-code from independent sources as it is a "Generic Security Platform".

>This does not require the private keys to be used within a server.

This is definitely another question and I would say (while taking on my
marketing hat) that CyberPhone is a "thin PKI" (new sexy term born
this very second) solution that could solve even harder problems than the
"thin client" did.

> But I'll never like as a general tradeoff that private keys MUST be operated by
>the server. 

They don't.  Only in the case they belong to a server-based resource like
a SET account, OBI purchaser

<snip>
>>So I do really believe there is room for a "third wave"

>Yes there are, but is surely won't be private key servers.

>However, a layered structure with a few long lived general certificates
>(QC) that support a large number of specialized short lived certificates,
>may very well be part of that "third wave".

Hum, another IETF-Swede said in another mailing-list that the need for a static
indentity (like an SSN) in a cert is not at all required to maintain a long-lasting
certificate-based relationship in a convenient way.  I asked him if for a
high-level spec. on how he thought that that would work.  He never did it.  I
feel the same thing for your suggestion.  How?  Please...

If you take my "Dynamic Certificates" paper and try to cast that
into conventional PKI you will end up in misery.  Misery = twice the cost,
twice the PITA. and a big chance to be bypassed by other solutions.

Anders



Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id KAA00389 for ietf-pkix-bks; Wed, 7 Apr 1999 10:26:30 -0700 (PDT)
Received: from poptop.llnl.gov (poptop.llnl.gov [128.115.18.65]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id KAA00384 for <[e-mail]>; Wed, 7 Apr 1999 10:26:29 -0700 (PDT)
Received: from catalyst (catalyst.llnl.gov [128.115.223.10]) by poptop.llnl.gov (8.8.8/LLNL-3.0.2/pop.llnl.gov-5.1) with SMTP id KAA15892; Wed, 7 Apr 1999 10:26:35 -0700 (PDT)
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.3 (32)
Date: Wed, 07 Apr 1999 10:26:06 -0700
To: Alan Lloyd <[e-mail]>, "'Stephen Kent'" <[e-mail]>
From: Tony Bartoletti <[e-mail]>
Subject: RE: Certificates, Directories, and Distinguished Names
Cc: "''[e-mail] ' '" <[e-mail]>, "''[e-mail] ' '" <[e-mail]>
In-Reply-To: <D1A949D4508DD1119C8100400533BEDC0BE968@DSG1>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Just a General Observation:

The "pack-it-in-the-cert"/"pack-it-in-a-directory" debate seems to
parallel, in some ways, the recent thread on Anders' "CyberPhone"
approach to outsourcing one's private-key handling.

And "convenience," indeed, can only be ignored at one's peril (in
a business model, at least:)

Over all of this, I cannot help but be reminded of those who lived
through the Great Depression, and to this day feel uncomfortable
placing their money in banks.  They will insist upon dealing in
"cash", the kind they can stuff under their mattress, or bury in
a steel box in the backyard.  Foolish at it may seem to most, they
insist upon being the final arbiters of their security/destiny,
however ill-equipped to the task they may be.

No amount of argument that, statistically, their money would be
safer in a bank, or as bits-on-a-disk, will dissuade them.
(And who knows, in the long run, if they will be wrong or right?)

Must we promote a world so hostile to these individualists (they
are many, if not majority) that they become shut-out of the future
benefits that PKIs may afford?

Is this concern not a silent undercurrent to many of these debates?

___tony___



Tony Bartoletti                                             LL
Center for Information Operations and Assurance          LL LL
Lawrence Livermore National Laboratory                LL LL LL
PO Box 808, L - 303                                   LL LL LL
Livermore, CA 94551-9900                              LL LL LLLLLLLL
phone: [phone]   fax: [phone]               LL LLLLLLLL
email: [e-mail]                                   LLLLLLLL


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id KAA00193 for ietf-pkix-bks; Wed, 7 Apr 1999 10:13:52 -0700 (PDT)
Received: from edelweb.fr (edelweb.fr [193.51.12.16]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id KAA00189 for <[e-mail]>; Wed, 7 Apr 1999 10:13:50 -0700 (PDT)
Received: from champagne.edelweb.fr (localhost.edelweb.fr [127.0.0.1]) by edelweb.fr with ESMTP id TAA02331; Wed, 7 Apr 1999 19:14:32 +0200 (MET DST)
Received: from champagne.edelweb.fr (champagne.edelweb.fr [193.51.14.161]) by edelweb.fr (nospam/1.1); Wed, 7 Apr 1999 19:14:32 +0200 (MET DST)
Received: from emeriau.edelweb.fr (emeriau.edelweb.fr [193.51.14.5]) by champagne.edelweb.fr (8.6.10/8.6.6) with ESMTP id TAA11002; Wed, 7 Apr 1999 19:14:31 +0200
From: Peter Sylvester <[e-mail]>
Received: (sylvest@localhost) by emeriau.edelweb.fr (8.6.10/8.6.6) id TAA04926; Wed, 7 Apr 1999 19:14:30 +0200
Date: Wed, 7 Apr 1999 19:14:30 +0200
Message-Id: <[e-mail]>
To: [e-mail], [e-mail], [e-mail]
Subject: RE: Time Stamp: tsa field in TSTInfo
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

> 
> Actually, I believe that when using CMS only the content (in this case
> TSTInfo) is signed along with any authenticated attributes.  Thus, the
> distinguishing information for the TSA would not be signed if it was not
> included within the TSTInfo structure.
If the TST provider want to surely indicate its identity, one 
can use an ess signing certificate attribute.

This seems preferable to me (if the tendancy is avoid to reinvent things).

The ess stuff was probably not avaiable at the time when
the tst draft was written for the first time. 
 

> 
> 	Robert.
> 
> > ----------
> > From: 	Juan Luis López[SMTP:[e-mail]]
> > Sent: 	Wednesday, April 07, 1999 5:25 AM
> > To: 	pkix
> > Subject: 	Time Stamp: tsa field in TSTInfo
> > 
> >     Hi everybody!
> >  
> >     I am involved in a Time Stamping project and we are analysing the PKIX
> > draft about this subject.
> >  
> >     I would like to give my opinion on an issue to the list:
> >     It seems not appropriate to include a field in TSTInfo structure
> > related to the tsa identity, i.e. tsa field. I don't find this field
> > necessary because it is repeated when using a CMS or PKCS#7 envelope to
> > encapsulate the token information. This information would be redundant
> > since an identifier distinguishing the given tsa should be present in the
> > signerInfo structure.
> >  
> >     So, I recommend the deletion of this field.
> >  
> >     Regards,
> >    Juan Luis López
> >  
> >  
> >    
> > --------------------------------------------------------------------------
> > -----------
> > Juan Luis López                                              <
> > [e-mail]>
> > Project Engineer                                             
> > http://www.fnmt.es/pkits
> > Fábrica Nacional de Moneda y Timbre             tel: [+34] 91 506 48 40
> > C/ Juan de Mariana, 17                                  fax: [+34] 91 506
> > 48 51
> > E-28045 Madrid, SPAIN               
> > 
> 


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id JAA29721 for ietf-pkix-bks; Wed, 7 Apr 1999 09:25:43 -0700 (PDT)
Received: from mail-out2.apple.com (mail-out2.apple.com [17.254.0.51]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id JAA29717 for <[e-mail]>; Wed, 7 Apr 1999 09:25:43 -0700 (PDT)
Received: from mailgate1.apple.com (A17-128-100-225.apple.com [17.128.100.225]) by mail-out2.apple.com (8.8.5/8.8.5) with ESMTP id JAA16368 for <[e-mail]>; Wed, 7 Apr 1999 09:17:55 -0700
Received: from scv1.apple.com (scv1.apple.com) by mailgate1.apple.com (mailgate1.apple.com- SMTPRS 2.0.15) with ESMTP id <[e-mail]>; Wed, 07 Apr 1999 09:17:45 -0700
Received: from [17.205.41.166] (aram1.apple.com [17.205.41.166]) by scv1.apple.com (8.9.3/8.9.3) with ESMTP id JAA07970; Wed, 7 Apr 1999 09:17:44 -0700
Message-Id: <[e-mail]>
X-Mailer: Microsoft Outlook Express Macintosh Edition - 4.5 (0410)
Date: Wed, 07 Apr 1999 09:17:44 -0700
Subject: Re: CA vs. EE cert processing
From: "Aram Perez" <[e-mail]>
To: [e-mail], Stephen Kent <[e-mail]>
Cc: [e-mail]
MIME-Version: 1.0
X-Priority: 3
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

My two cents: I agree with John. Given that RFC2459 is not a "standard" yet
and thus no standard-compliant software exists out there, we should "fix"
RFC2459 to do the right thing for existing legacy software, and the new
RFC2459 compliant software.

Aram Perez
Apple Computer, Inc.

>
>
> Steve writes:
>
>>This memo examines certificate processing with regard to determining
>>whether a certificate is associated with a CA or an EE, to determine where
>>the ambiguity lies and thus help clarify this discussion. Upon further
>>analysis I discovered that the issue is more complex that I originally
>>realized, and so my simple algorithm was oversimplified. However the
>>suggestions put forth so far (as best I recall) also seem to miss the
>>point, as explained below.
>>
>>First question: is this a v1 certificate or a v3 certificate?
>> ...
>>
>>Second question: is there a basicConstraints extension present in the
>>certificate? If not, then according to RFC 2459 this must be an EE cert,
>>since CA certs MUST contain this extension. But, according to X.509, if
> the
>>constraint is absent (or present but marked non-critical and not
> understood
>>by the implementation), then it is up to the implementation to use other
>>means of determining if the certificate is for a CA or an EE.  At this
>>point we have ambiguity, based on examining only the presence or absence
> of
>>this constraint in a v3 cert.  X.509 does not specify what else should be
>>done. So, not knowing if the certificate was issued by an RFC 2459
>>compliant CA, or an X.509 compliant CA, we have to go to "Plan B."  Note
>>that nothing we change in RFC 2459 can fix this problem as the ambiguity
> is
>>traceable to X.509.
>
> There are two parts to "this ambiguity".  The one as stated where a PKIX
> verifier encounters a certificate without a basicConstraints extension, and
> another one where a non-PKIX verifier encounters such a certificate.
> Leaving
> the first one aside for the moment, PKIX would be a better player in the
> broader X.509 world if it chose not to generate certificates that are
> ambiguous to such a world.
>
>>If we have a basicConstraints extension, [then everything's fine -
>>no ambiguity (JCW)].
>>
>>Plan B:  We are here because we have a v3 certificate with no
>>basicConstraints extension and because we don't know if the CA that issued
>>the certificate was operating in compliance with either 2459 or X.509.  We
>>now have to examine other fields of the certificate, or have some out of
>>band mechanism to help.  X.509 provides no guidance on how to do this,
>>which leaves implementers wondering.  RFC 2459 provides no guidance
> because
>>a CA complying with the RFC would not have this problem.
>>
>>So, how can we remove this residual ambiguity?  Well, it can't be removed
>>by a change only to RFC 2459, because that standard is not the source of
>>the ambiguity.  If one were to change X.509, to require that a compliant
> CA
>>include the basicConstraints extension (critical or not), when a
>>certificate was issued to a CA, then the ambiguity would be removed at its
>>source.  If this change were made to X.509, no change to 2459 would be
>>required.  Specifically, changing 2459 to call for inclusion of this
>>constraint for EE certificates (either as a SHOULD or MUST) would not
>>address the ambiguity encountered above.
>
> On the contrary, changing RFC 2459 to require the inclusion of the
> basicConstraints extension on all certificates would help alleviate this
> ambiguity, and in some cases could completely address it.  As you have
> pointed out, there is only an ambiguity when processing a certificate
> without a basicConstraints extension.  By constraining PKIX to avoid
> generating such certificates, we would avoid any confusion in
> certificates generated by PKIX systems, whether or not the verifier
> is PKIX-compliant, and more importantly whether or not the verifier
> knows that the issuing system was PKIX-compliant.
>
> If RFC2459 were modified to require the extension, then it would
> be permissible for a verifier to make its own decisions about how
> to handle an ambiguous certificate (one without a basicConstraints
> extension).  Reasonable options might include rejecting the
> certificate, asking for user guidance, or applying site-specific
> policy to determine how to treat it.  The way RFC2459 is currently
> written, a PKIX verifier doesn't have these options - it must treat
> such a certificate as an EE certificate, whether or not that's the
> right thing to do (i.e. whether or not the issuing CA meant the
> certificate to be an EE or a CA cert).
>
>>Some have suggested that we should consider changes to 2459 to help
>>alleviate problems resulting from CAs that do not comply with 2459.  The
>>above analysis suggests that if the source of the certificate is an X.509
>>compliant CA, the solution lies with a change to X.509.  If the CA is not
>>assumed to comply with either 2459 or X.509, I do not see how fixing
> either
>>2459 or X.509 could possible help.
>
> The PKIX working group doesn't have the ability to change X.509; we
> only have control of the PKIX specs.  A change to RFC 2459 would allow
> us to avoid stumbling into into this ambiguity in X.509, with the result
> that:
>
> i)  PKIX certificates would not be ambiguous to an X.509 verifier,
>
> and ii) PKIX verifiers would be able to distinguish ambiguous non-PKIX
> certs
> from unambiguous certs, without having to know whether the certificate
> issuer was PKIX-compliant.
>
>
> John
>
>



Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id JAA29613 for ietf-pkix-bks; Wed, 7 Apr 1999 09:10:41 -0700 (PDT)
Received: from gatekeeper.entrust.com (gatekeeper.entrust.com [204.101.128.170]) by mail.proper.com (8.8.8/8.8.5) with SMTP id JAA29609 for <[e-mail]>; Wed, 7 Apr 1999 09:10:40 -0700 (PDT)
Received: 	id MAA10392; Wed, 7 Apr 1999 12:07:48 -0400
Received: by gateway id <G4CAZWL2>; Wed, 7 Apr 1999 12:10:08 -0400
Message-ID: <01E1D01C12D7D211AFC70090273D20B112BD84@sothmxs06>
From: Robert Zuccherato <[e-mail]>
To: [e-mail], "'Juan G. de la Vega'" <[e-mail]>
Subject: RE: Time Stamping: comments on nonce field
Date: Wed, 7 Apr 1999 12:04:13 -0400 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.1960.3)
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by mail.proper.com id JAA29610
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

My comments are below:

> ----------
> From: 	Juan G. de la Vega[SMTP:[e-mail]]
> Sent: 	Wednesday, April 07, 1999 5:39 AM
> To: 	[e-mail]
> Subject: 	Time Stamping: comments on nonce field
> 
>         First of all, the declaration of this field in the request and
> token is somehow incoherent, while the nonce is mandatory in TimeStapReq
> (it is not declared OPTIONAL), the TimeStampToken´s nonce is OPTIONAL but
> it is stated that "...must be present if the similar field in TimeStampReq
> is present..." and hence the clause OPTIONAL is meaningless and confusing
> for this field shall always be present. 
> 
As I have said in the past, this was a mistake that I made because I did not
manage to fully include support for TSA production of a "signed time".  This
would be a token which does not include a nonce or message imprint.  TSA's
could produce these tokens and make them available (for example on a
website) for anyone who wants to obtain them.  This will be rectified in the
upcoming draft.

> I would suggest this field to be declared OPTIONAL both in the request and
> token or better deleted if we take into account the following:
>  
>     As far as I understand, a nonce value is present in the request and
> token in order for the requester to be able to match the responses from
> the TSA with her requests when using an asynchronous transport. It can be
> argued that such functionality should be left to the transport layer when
> required, but furthermore I must say that the nonce is not necessary since
> matching can be performed using the "messageImprint" field.
> 
Actually, the reason that the nonce is there and mandatory is to prevent
replay attacks.  Someone else could have obtained a time stamp on the data
before your request.  Thus, it is possible that the time stamp you received
is not "fresh".  Without a nonce, determining the freshness of the timestamp
is difficult.

	Robert.




Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id IAA29468 for ietf-pkix-bks; Wed, 7 Apr 1999 08:51:30 -0700 (PDT)
Received: from gatekeeper.entrust.com (gatekeeper.entrust.com [204.101.128.170]) by mail.proper.com (8.8.8/8.8.5) with SMTP id IAA29464 for <[e-mail]>; Wed, 7 Apr 1999 08:51:28 -0700 (PDT)
Received: 	id LAA00151; Wed, 7 Apr 1999 11:48:23 -0400
Received: by gateway id <G4CAZWGX>; Wed, 7 Apr 1999 11:50:43 -0400
Message-ID: <01E1D01C12D7D211AFC70090273D20B112BD82@sothmxs06>
From: Robert Zuccherato <[e-mail]>
To: pkix <[e-mail]>, =?iso-8859-1?Q?=27Juan_Luis_L=F3pez=27?= <[e-mail]>
Subject: RE: Time Stamp: tsa field in TSTInfo
Date: Wed, 7 Apr 1999 11:44:48 -0400 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.1960.3)
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by mail.proper.com id IAA29465
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Actually, I believe that when using CMS only the content (in this case
TSTInfo) is signed along with any authenticated attributes.  Thus, the
distinguishing information for the TSA would not be signed if it was not
included within the TSTInfo structure.

	Robert.

> ----------
> From: 	Juan Luis López[SMTP:[e-mail]]
> Sent: 	Wednesday, April 07, 1999 5:25 AM
> To: 	pkix
> Subject: 	Time Stamp: tsa field in TSTInfo
> 
>     Hi everybody!
>  
>     I am involved in a Time Stamping project and we are analysing the PKIX
> draft about this subject.
>  
>     I would like to give my opinion on an issue to the list:
>     It seems not appropriate to include a field in TSTInfo structure
> related to the tsa identity, i.e. tsa field. I don't find this field
> necessary because it is repeated when using a CMS or PKCS#7 envelope to
> encapsulate the token information. This information would be redundant
> since an identifier distinguishing the given tsa should be present in the
> signerInfo structure.
>  
>     So, I recommend the deletion of this field.
>  
>     Regards,
>    Juan Luis López
>  
>  
>    
> --------------------------------------------------------------------------
> -----------
> Juan Luis López                                              <
> [e-mail]>
> Project Engineer                                             
> http://www.fnmt.es/pkits
> Fábrica Nacional de Moneda y Timbre             tel: [+34] 91 506 48 40
> C/ Juan de Mariana, 17                                  fax: [+34] 91 506
> 48 51
> E-28045 Madrid, SPAIN               
> 


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id HAA28938 for ietf-pkix-bks; Wed, 7 Apr 1999 07:48:30 -0700 (PDT)
Received: from stingray.missi.ncsc.mil (stingray.missi.ncsc.mil [144.51.50.20]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id HAA28932 for <[e-mail]>; Wed, 7 Apr 1999 07:48:29 -0700 (PDT)
Received: from stingray.missi.ncsc.mil (root@localhost) by stingray.missi.ncsc.mil with ESMTP id KAA17552 for <[e-mail]>; Wed, 7 Apr 1999 10:49:11 -0400 (EDT)
Received: from missi.ncsc.mil (depot.missi.ncsc.mil [144.51.60.1]) by stingray.missi.ncsc.mil with ESMTP id KAA17548 for <[e-mail]>; Wed, 7 Apr 1999 10:49:11 -0400 (EDT)
Received: from ara.missi.ncsc.mil (ara.missi.ncsc.mil [144.51.56.12]) by missi.ncsc.mil (8.8.8/8.8.8) with ESMTP id KAA18603 for <[e-mail]>; Wed, 7 Apr 1999 10:47:42 -0400 (EDT)
Received: from ara.missi.ncsc.mil (ara.missi.ncsc.mil [144.51.56.12]) by ara.missi.ncsc.mil (8.9.1b+Sun/8.9.1) with SMTP id KAA01212 for <[e-mail]>; Wed, 7 Apr 1999 10:48:49 -0400 (EDT)
Message-Id: <[e-mail]>
Date: Wed, 7 Apr 1999 10:48:49 -0400 (EDT)
From: "David P. Kemp" <[e-mail]>
Reply-To: "David P. Kemp" <[e-mail]>
Subject: Re: CA vs. EE cert processing
To: [e-mail]
MIME-Version: 1.0
Content-Type: TEXT/plain; charset=us-ascii
Content-MD5: SzZkhah/IKEF5AxoL9RtBw==
X-Mailer: dtmail 1.3.0 CDE Version 1.3 SunOS 5.7 sun4u sparc 
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

> From: [e-mail]
> 
> The PKIX working group doesn't have the ability to change X.509; we
> only have control of the PKIX specs.  A change to RFC 2459 would allow
> us to avoid stumbling into into this ambiguity in X.509, with the result
> that:
> 
> i)  PKIX certificates would not be ambiguous to an X.509 verifier,
> 
> and ii) PKIX verifiers would be able to distinguish ambiguous non-PKIX
> certs
> from unambiguous certs, without having to know whether the certificate
> issuer was PKIX-compliant.


The ITU has the ability to change X.509; this ambiguity should qualify
for treatment as a defect, if someone takes it upon themselves to generate
a DR.

You are correct that requiring the extension in EE certs would eliminate
the ambiguity.  But so would any one of:

 * correcting the incompletely-specified X.509 / ISO 9594-8
 * providing for manual intervention in user agents
 * including the Key Usage extension in EE certs
 * choosing to include the Basic Constraints extension in EE certs - PKIX
    does not prohibit that practice, just discourages it.

Changing PKIX from SHOULD NOT to SHOULD would not help - the ambiguity
would remain.  And changing it to MUST would suddenly bring all previously
conforming EE certs into non-conformance, as well as forcing the inclusion
of redundant information in newly-issued certs.

The right answer is to fix X.509 to require the basic constraints
extension in CA certs.  It already requires the version number to be
present in v3 certs; certs with the version number omitted
unambiguously default to v1.



Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id GAA28327 for ietf-pkix-bks; Wed, 7 Apr 1999 06:37:11 -0700 (PDT)
Received: from epic.iris.com (epic.iris.com [198.112.211.21]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id GAA28321 for <[e-mail]>; Wed, 7 Apr 1999 06:37:07 -0700 (PDT)
From: [e-mail]
Subject: Re: CA vs. EE cert processing
To: Stephen Kent <[e-mail]>
Cc: [e-mail]
Date: Wed, 07 Apr 1999 13:38:19 GMT
Message-ID: <[e-mail]>
X-Priority: 3 (Normal)
X-MIMETrack: Serialize by Router on Epic/Iris(Daily Build (based on 166.1)|Apr  6 1999) at 04/07/99 09:40:08 AM
MIME-Version: 1.0
Content-type: text/plain; charset=us-ascii
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Steve writes:

>This memo examines certificate processing with regard to determining
>whether a certificate is associated with a CA or an EE, to determine where
>the ambiguity lies and thus help clarify this discussion. Upon further
>analysis I discovered that the issue is more complex that I originally
>realized, and so my simple algorithm was oversimplified. However the
>suggestions put forth so far (as best I recall) also seem to miss the
>point, as explained below.
>
>First question: is this a v1 certificate or a v3 certificate?
> ...
>
>Second question: is there a basicConstraints extension present in the
>certificate? If not, then according to RFC 2459 this must be an EE cert,
>since CA certs MUST contain this extension. But, according to X.509, if
the
>constraint is absent (or present but marked non-critical and not
understood
>by the implementation), then it is up to the implementation to use other
>means of determining if the certificate is for a CA or an EE.  At this
>point we have ambiguity, based on examining only the presence or absence
of
>this constraint in a v3 cert.  X.509 does not specify what else should be
>done. So, not knowing if the certificate was issued by an RFC 2459
>compliant CA, or an X.509 compliant CA, we have to go to "Plan B."  Note
>that nothing we change in RFC 2459 can fix this problem as the ambiguity
is
>traceable to X.509.

There are two parts to "this ambiguity".  The one as stated where a PKIX
verifier encounters a certificate without a basicConstraints extension, and
another one where a non-PKIX verifier encounters such a certificate.
Leaving
the first one aside for the moment, PKIX would be a better player in the
broader X.509 world if it chose not to generate certificates that are
ambiguous to such a world.

>If we have a basicConstraints extension, [then everything's fine -
>no ambiguity (JCW)].
>
>Plan B:  We are here because we have a v3 certificate with no
>basicConstraints extension and because we don't know if the CA that issued
>the certificate was operating in compliance with either 2459 or X.509.  We
>now have to examine other fields of the certificate, or have some out of
>band mechanism to help.  X.509 provides no guidance on how to do this,
>which leaves implementers wondering.  RFC 2459 provides no guidance
because
>a CA complying with the RFC would not have this problem.
>
>So, how can we remove this residual ambiguity?  Well, it can't be removed
>by a change only to RFC 2459, because that standard is not the source of
>the ambiguity.  If one were to change X.509, to require that a compliant
CA
>include the basicConstraints extension (critical or not), when a
>certificate was issued to a CA, then the ambiguity would be removed at its
>source.  If this change were made to X.509, no change to 2459 would be
>required.  Specifically, changing 2459 to call for inclusion of this
>constraint for EE certificates (either as a SHOULD or MUST) would not
>address the ambiguity encountered above.

On the contrary, changing RFC 2459 to require the inclusion of the
basicConstraints extension on all certificates would help alleviate this
ambiguity, and in some cases could completely address it.  As you have
pointed out, there is only an ambiguity when processing a certificate
without a basicConstraints extension.  By constraining PKIX to avoid
generating such certificates, we would avoid any confusion in
certificates generated by PKIX systems, whether or not the verifier
is PKIX-compliant, and more importantly whether or not the verifier
knows that the issuing system was PKIX-compliant.

If RFC2459 were modified to require the extension, then it would
be permissible for a verifier to make its own decisions about how
to handle an ambiguous certificate (one without a basicConstraints
extension).  Reasonable options might include rejecting the
certificate, asking for user guidance, or applying site-specific
policy to determine how to treat it.  The way RFC2459 is currently
written, a PKIX verifier doesn't have these options - it must treat
such a certificate as an EE certificate, whether or not that's the
right thing to do (i.e. whether or not the issuing CA meant the
certificate to be an EE or a CA cert).

>Some have suggested that we should consider changes to 2459 to help
>alleviate problems resulting from CAs that do not comply with 2459.  The
>above analysis suggests that if the source of the certificate is an X.509
>compliant CA, the solution lies with a change to X.509.  If the CA is not
>assumed to comply with either 2459 or X.509, I do not see how fixing
either
>2459 or X.509 could possible help.

The PKIX working group doesn't have the ability to change X.509; we
only have control of the PKIX specs.  A change to RFC 2459 would allow
us to avoid stumbling into into this ambiguity in X.509, with the result
that:

i)  PKIX certificates would not be ambiguous to an X.509 verifier,

and ii) PKIX verifiers would be able to distinguish ambiguous non-PKIX
certs
from unambiguous certs, without having to know whether the certificate
issuer was PKIX-compliant.


John




Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id CAA23249 for ietf-pkix-bks; Wed, 7 Apr 1999 02:41:05 -0700 (PDT)
Received: from www.fnmt.es (www.fnmt.es [194.224.27.14]) by mail.proper.com (8.8.8/8.8.5) with SMTP id CAA23245 for <[e-mail]>; Wed, 7 Apr 1999 02:41:03 -0700 (PDT)
Received: from dnsp.epc.fnmt.es (dnsp.epc.fnmt.es [193.149.3.17]) by www.fnmt.es (NTMail 3.02.13) with ESMTP id va023239 for <[e-mail]>; Wed, 7 Apr 1999 11:36:49 +0100
Message-ID: <008201be80da$81bb1560$[e-mail]>
From: "Juan G. de la Vega" <[e-mail]>
To: <[e-mail]>
Subject: Time Stamping: comments on nonce field
Date: Wed, 7 Apr 1999 11:39:04 +0200
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_007F_01BE80EB.3CE282A0"
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
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

This is a multi-part message in MIME format.

------=_NextPart_000_007F_01BE80EB.3CE282A0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Hi PKIX-ers,
=20
    I have some comments on Time Stamping protocols regarding "nonce" =
field:
=20
        First of all, the declaration of this field in the request and =
token is somehow incoherent, while the nonce is mandatory in TimeStapReq =
(it is not declared OPTIONAL), the TimeStampToken=B4s nonce is OPTIONAL =
but it is stated that "...must be present if the similar field in =
TimeStampReq is present..." and hence the clause OPTIONAL is meaningless =
and confusing for this field shall always be present. I would suggest =
this field to be declared OPTIONAL both in the request and token or =
better deleted if we take into account the following:
=20
    As far as I understand, a nonce value is present in the request and =
token in order for the requester to be able to match the responses from =
the TSA with her requests when using an asynchronous transport. It can =
be argued that such functionality should be left to the transport layer =
when required, but furthermore I must say that the nonce is not =
necessary since matching can be performed using the "messageImprint" =
field.
    The only justification at hand to defend the "nonce" is when asking =
a TSA "What time it is" (not including messageImprints field), and in =
order to defeat replay attacks in this case... Anyway, this use of a TSA =
steps aside from "providing a proof-of-existence for a particular =
message in an instant in time" and personally don't like it; I would =
call that a STS (secure time source) (i.e.: authenticated NTP) and would =
not force TS protocols modifications for that use.
=20
    Regards,
=20
    Juan.
____________________________________________
Juan Gonz=E1lez-de-la-Vega
Software Engineer
E-mail: <[e-mail]>
FNMT - F=E1brica Nacional de Moneda y Timbre
Phone: [phone].
Fax: [phone]

------=_NextPart_000_007F_01BE80EB.3CE282A0
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD W3 HTML//EN">
<HTML>
<HEAD>

<META content=3Dtext/html;charset=3Diso-8859-1 =
http-equiv=3DContent-Type>
<META content=3D'"MSHTML 4.72.3110.7"' name=3DGENERATOR>
</HEAD>
<BODY bgColor=3D#ffffff>
<DIV>
<DIV><FONT size=3D2>Hi PKIX-ers,</FONT></DIV>
<DIV><FONT size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT size=3D2>&nbsp;&nbsp;&nbsp; I have some comments on Time =
Stamping=20
protocols regarding</FONT><FONT size=3D2> &quot;nonce&quot; =
field:</FONT></DIV>
<DIV><FONT size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT size=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; First of =
all, the=20
declaration of this field in the request and token is somehow =
incoherent, while=20
the nonce is mandatory in TimeStapReq (it is not declared OPTIONAL), the =

TimeStampToken&acute;s nonce is OPTIONAL but it is stated that =
&quot;...must be=20
present if the similar field in TimeStampReq is present...&quot; and =
hence the=20
clause OPTIONAL is meaningless and confusing for this field shall always =
be=20
present. I would suggest this field to be declared OPTIONAL both in the =
request=20
and token or better deleted if we take into account the =
following:</FONT></DIV>
<DIV><FONT size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT size=3D2>&nbsp;&nbsp;&nbsp; As far as I understand, a nonce =
value is=20
present in the request and token in order for the requester to be able =
to match=20
the responses from the TSA with her requests when using an asynchronous=20
transport. It can be argued that such functionality should be left to =
the=20
transport layer when required, but furthermore I must say that the nonce =
is not=20
necessary since matching can be performed using the =
&quot;messageImprint&quot;=20
field.</FONT></DIV>
<DIV><FONT size=3D2>&nbsp;&nbsp;&nbsp; The only justification at hand to =
defend=20
the &quot;nonce&quot; is when asking a TSA &quot;What time it is&quot; =
(not=20
including messageImprints field), and in order to defeat replay attacks =
in this=20
case... Anyway, this use of a TSA steps aside from &quot;providing a=20
proof-of-existence for a particular message in an instant in time&quot; =
and=20
personally don't like it; I would call that a STS (secure time source) =
(i.e.:=20
authenticated NTP) and would not force TS protocols modifications for =
that=20
use.</FONT></DIV>
<DIV><FONT size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT size=3D2>&nbsp;&nbsp;&nbsp; Regards,</FONT></DIV>
<DIV><FONT size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT size=3D2>&nbsp;&nbsp;&nbsp; Juan.</FONT></DIV></DIV>
<DIV><FONT color=3D#000000=20
size=3D2>____________________________________________<BR>Juan=20
Gonz&aacute;lez-de-la-Vega<BR>Software Engineer<BR>E-mail: &lt;<A=20
href=3D"mailto:[e-mail]">[e-mail]</A>&gt;<BR>FNMT -=20
F&aacute;brica Nacional de Moneda y Timbre<BR>Phone: [phone] =
40.<BR>Fax:=20
[phone]</FONT></DIV></BODY></HTML>

------=_NextPart_000_007F_01BE80EB.3CE282A0--



Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id CAA23120 for ietf-pkix-bks; Wed, 7 Apr 1999 02:27:05 -0700 (PDT)
Received: from www.fnmt.es (www.fnmt.es [194.224.27.14]) by mail.proper.com (8.8.8/8.8.5) with SMTP id CAA23115 for <[e-mail]>; Wed, 7 Apr 1999 02:27:03 -0700 (PDT)
Received: from dnsp.epc.fnmt.es (dnsp.epc.fnmt.es [193.149.3.17]) by www.fnmt.es (NTMail 3.02.13) with ESMTP id ra023235 for <[e-mail]>; Wed, 7 Apr 1999 11:22:43 +0100
Message-ID: <01d201be80d8$b28e15e0$[e-mail]>
From: "=?iso-8859-1?Q?Juan_Luis_L=F3pez?=" <[e-mail]>
To: "pkix" <[e-mail]>
Subject: Time Stamp: tsa field in TSTInfo
Date: Wed, 7 Apr 1999 11:25:54 +0200
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_01CF_01BE80E9.66146320"
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
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

This is a multi-part message in MIME format.

------=_NextPart_000_01CF_01BE80E9.66146320
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

    Hi everybody!
=20
    I am involved in a Time Stamping project and we are analysing the =
PKIX draft about this subject.
=20
    I would like to give my opinion on an issue to the list:
    It seems not appropriate to include a field in TSTInfo structure =
related to the tsa identity, i.e. tsa field. I don't find this field =
necessary because it is repeated when using a CMS or PKCS#7 envelope to =
encapsulate the token information. This information would be redundant =
since an identifier distinguishing the given tsa should be present in =
the signerInfo structure.
=20
    So, I recommend the deletion of this field.
=20
    Regards,
   Juan Luis L=F3pez
=20

    =
-------------------------------------------------------------------------=
------------
Juan Luis L=F3pez                                              =
<[e-mail]>
Project Engineer                                              =
http://www.fnmt.es/pkits
F=E1brica Nacional de Moneda y Timbre             tel: [+34] 91 506 48 =
40
C/ Juan de Mariana, 17                                  fax: [+34] 91 =
506 48 51
E-28045 Madrid, SPAIN              =20

------=_NextPart_000_01CF_01BE80E9.66146320
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD W3 HTML//EN">
<HTML>
<HEAD>

<META content=3Dtext/html;charset=3Diso-8859-1 =
http-equiv=3DContent-Type><!DOCTYPE HTML PUBLIC "-//W3C//DTD W3 =
HTML//EN">
<META content=3D'"MSHTML 4.72.3110.7"' name=3DGENERATOR>
</HEAD>
<BODY bgColor=3D#ffffff>
<DIV>
<DIV><FONT color=3D#000000 size=3D2>&nbsp;&nbsp;&nbsp; <FONT =
color=3D#000000>Hi=20
everybody!</FONT></FONT></DIV>
<DIV><FONT color=3D#000000 size=3D2><FONT =
color=3D#000000></FONT></FONT>&nbsp;</DIV>
<DIV><FONT color=3D#000000 size=3D2>&nbsp;&nbsp;&nbsp; I am involved in =
a Time=20
Stamping project and we are analysing the PKIX draft about this=20
subject.</FONT></DIV>
<DIV><FONT color=3D#000000 size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT color=3D#000000 size=3D2>&nbsp;&nbsp;&nbsp; I would like to =
give my=20
opinion on an issue to the list:</FONT></DIV>
<DIV><FONT color=3D#000000 size=3D2><FONT =
color=3D#000000>&nbsp;&nbsp;&nbsp; It seems=20
not appropriate to include a field in TSTInfo structure related to the =
tsa=20
identity, i.e. tsa field. I don't find this field necessary because it =
is=20
repeated when using a CMS or PKCS#7 envelope to encapsulate the token=20
information. This information would be redundant since an identifier=20
distinguishing the given tsa should be present in the signerInfo=20
structure.</FONT></FONT></DIV>
<DIV><FONT color=3D#000000 size=3D2><FONT =
color=3D#000000></FONT></FONT>&nbsp;</DIV>
<DIV><FONT color=3D#000000 size=3D2><FONT =
color=3D#000000>&nbsp;&nbsp;&nbsp; So, I=20
recommend the deletion of this field.</FONT></FONT></DIV>
<DIV><FONT color=3D#000000 size=3D2><FONT =
color=3D#000000></FONT></FONT>&nbsp;</DIV>
<DIV><FONT color=3D#000000 size=3D2><FONT =
color=3D#000000>&nbsp;&nbsp;&nbsp;=20
Regards,</FONT></FONT></DIV>
<DIV><FONT color=3D#000000 size=3D2><FONT =
color=3D#000000></FONT></FONT>&nbsp;<FONT=20
color=3D#000000 size=3D2><FONT color=3D#000000>&nbsp; Juan Luis=20
L&oacute;pez</FONT></FONT></DIV>
<DIV><FONT color=3D#000000 size=3D2><FONT =
color=3D#000000></FONT></FONT>&nbsp;</DIV>
<DIV>&nbsp;</DIV></DIV>
<DIV><FONT color=3D#000000 size=3D2>&nbsp;&nbsp;&nbsp;=20
-------------------------------------------------------------------------=
------------<BR>Juan=20
Luis=20
L&oacute;pez&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&=
nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
&lt;<A href=3D"mailto:[e-mail]">[e-mail]</A>&gt;<BR>Project=20
Engineer&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;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
<A=20
href=3D"http://www.fnmt.es/pkits">http://www.fnmt.es/pkits</A><BR>F&aacut=
e;brica=20
Nacional de Moneda y=20
Timbre&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&=
nbsp;=20
tel: [+34] 91 506 48 40<BR>C/ Juan de Mariana,=20
17&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;=20
fax: [+34] 91 506 48 51<BR>E-28045 Madrid,=20
SPAIN&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;=20
</FONT></DIV></BODY></HTML>

------=_NextPart_000_01CF_01BE80E9.66146320--



Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id BAA21888 for ietf-pkix-bks; Wed, 7 Apr 1999 01:47:18 -0700 (PDT)
Received: from popmail.inbox.se (popmail.inbox.se [193.12.72.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id BAA21843 for <[e-mail]>; Wed, 7 Apr 1999 01:46:57 -0700 (PDT)
Received: from stefan2 (accurata.inbox.se [193.12.72.24]) by popmail.inbox.se (8.8.7/8.8.7) with SMTP id KAA03333; Wed, 7 Apr 1999 10:47:35 +0200
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: Windows Eudora Pro Version 3.0 (32)
Date: Wed, 07 Apr 1999 10:48:17 +0200
To: "Anders Rundgren" <[e-mail]>, "Stephen Kent" <[e-mail]>
From: Stefan Santesson <[e-mail]>
Subject: Re: A $25,000,000,000 PKI   Was:Spec. on QC-low-fat & QC-heavy-bio
Cc: <[e-mail]>, "'SEIS-List'" <[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 mail.proper.com id BAA21846
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Anders,

At 06:34 AM 4/7/99 +0100, Anders Rundgren wrote:
<snip>
>1) The problem is that the private keys to a company purchaser cert are
>not "yours".  I.e. they are owned by the company that can control their
use 100%
>if they never leave their secure server.  That is a very good working model.

Who owns a private key??? I don't care.
The thing that interests me is who have the exclusive right to use the key,
and that this right is protected. 

>
>2) I think that the thin client solution has more with sw distribution which
>is a true bottleneck recognized by most of the IT-industry 
>

You are solving yesterdays problems. 

The problem with exporting client software is a general problem which a
whole industry is working on. Java is one step along the line and we will
see more and better solutions. In a world where bandwidth are increasing we
will se more of "download what you need, when you need it" type of
approaches. This does not require the private keys to be used within a server.

I could support almost any type of client server solution where "thin"
clients gets software on demand to deploy what ever they are used for. But
I'll never like as a general tradeoff that private keys MUST be operated by
the server. 

To me you can put everything BUT the private keys (and one basic
certificate) in the server.

<snip>
>
>Initially PKI was about certs and global X500 directories - Did not happen
>
>Now it is zillions of certs distributed in various ways - Slow deployment
>
>So I do really believe there is room for a "third wave"
>

Yes there are, but is surely won't be private key servers.

However, a layered structure with a few long lived general certificates
(QC) that support a large number of specialized short lived certificates,
may very well be part of that "third wave".

And that seems to be not that far away from your thoughts.

>Anders
>
>

/Stefan
-------------------------------------------------------------------
Stefan Santesson                <[e-mail]>
Accurata Systemsäkerhet AB      http://www.accurata.se
Slagthuset                      Tel. [phone]              
211 20  Malmö                   Fax. [phone]              
Sweden                        Mobile [phone]

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


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id BAA19802 for ietf-pkix-bks; Wed, 7 Apr 1999 01:19:29 -0700 (PDT)
Received: from stargate.zergo.com.au ([e-mail] [203.2.208.130]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id BAA19798 for <[e-mail]>; Wed, 7 Apr 1999 01:19:25 -0700 (PDT)
Received: from michaelz (dhcp-64.ws.zergo.com.au [192.168.72.64]) by stargate.zergo.com.au (8.9.1/8.8.7) with SMTP id SAA23860; Wed, 7 Apr 1999 18:18:21 +1000
Received: by localhost with Microsoft MAPI; Wed, 7 Apr 1999 18:18:37 +1000
Message-ID: <[e-mail]>
From: Michael Zolotarev <[e-mail]>
Reply-To: "[e-mail]" <[e-mail]>
To: "'Anders Rundgren'" <[e-mail]>
Cc: "[e-mail]" <[e-mail]>
Subject: RE: A $25,000,000,000 PKI 
Date: Wed, 7 Apr 1999 18:18:32 +1000
Organization: Baltimore Pty Ltd
X-Mailer: Microsoft Internet E-mail/MAPI - 8.0.0.4211
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Anders
You wrote:
>Why do you think network-centric computing and thin clients are the new 
favorites
>among IT-managers?  Because these solutions give them both control
>and convenience.

I just want to place my vote - it is difficult to disagree. Convenience 
rules.

With the advent of the 'thin client', when a terminal/mobilePh becomes just 
a secure empty-shell UI device, with the actual applications running on a 
host somewhere else, the whole idea of a physical 'flesh and blood' PKI 
client gets quite hazy. A server, running applications on behalf of 
thousands of devices, will inevitably come to host the PKI services as 
well, implementing some kind of VirtualCertificates, possibly employing 
private-key-servers etc. Because it is convenient.

However, the fact that a physical topology of the client changes, does not 
change the nature of the PKI-based solution. As Stefan Santesson wrote:
>Using this angle to view this kind of system design makes it quite clear
>that this design is simply a matter of local policy which by no means
>should affect general PKI standards and technical profiles.

The problem of securing the host may scare off a company A - only to clear 
the market for a company B.

BTW the 'lack of computation power' may not be a valid argument at all, as 
maintaining an Authenticated Secure Link between the thin client 
(CyberPhone) and the server may demand a great deal of 'computations' in 
the future  (and we all know that tomorrow's mobile devices will posses the 
power of today's supercomputers (some brass music here pls.).

Michael Z


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id AAA19208 for ietf-pkix-bks; Wed, 7 Apr 1999 00:40:56 -0700 (PDT)
Received: from dsg1.OpenDirectory.com.au ([203.108.249.145]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id AAA19204 for <[e-mail]>; Wed, 7 Apr 1999 00:40:53 -0700 (PDT)
Received: by DSG1 with Internet Mail Service (5.0.1458.49) id <22ZNQLS7>; Wed, 7 Apr 1999 17:41:18 +1000
Message-ID: <D1A949D4508DD1119C8100400533BEDC0DDB70@DSG1>
From: Alan Lloyd <[e-mail]>
To: "'Stephen Kent '" <[e-mail]>, "'Anders Rundgren '" <[e-mail]>
Cc: "'[e-mail] '" <[e-mail]>, "''SEIS-List' '" <[e-mail]>
Subject: RE: A $25,000,000,000 PKI   Was:Spec. on QC-low-fat & QC-heavy-bi o
Date: Wed, 7 Apr 1999 17:41:16 +1000
X-Priority: 3
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.0.1458.49)
Content-Type: text/plain
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

 
I love this stuff - reality at last.

As said - PKI and certs is a theoretical function applied to operational
systems based on cost/trust/risk parameters.

They (PKIUs and certs - and their validation) can be simple and cheap to
deal with traveller kiosks, phone cards, freeway tolls - (ie. processed
within a business policy (using directory services))   in fact their
utility here is greater than barcoding people, getting retina scans, the
name of ones cat and getting this signed off as being genuine by the
chair of the UN and 20 lawers just so they get a key pair and then
making them sign mail with this.



On a more serious note - and as said trying to profile certs/PKIs  for
"the Internet" - when the Internet technologies will be used in many,
many  ways for many reasons is a hard task. Not complying to PXIX may be
the norm for most certificate usage, particularly if there are 1bn phone
users and millions of tagged cars around the place.

Anders - about this money stuff - can we talk percentages?

regards alan


And then there is the cost issue.  This is CHEAP, mass-produced stuff.

Imagine a PKI that 2005 has 1 billion users (projected mobile phone
deployment)
where each user pays $25 to have his/hers CyberID.  That is

    $25,000,000,000 / Year !!!!

VeriSign, Thawte, are you listening?

It is absolutely worth HUGE sums to create secure servers and even
"adjust" laws on
digital signatures.  Maybe BBN could be interested in the server
business? :-)

Anders Rundgren
Senior Internet e-commerce Architect

http://www.mobilephones-tng.com





Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id VAA10960 for ietf-pkix-bks; Tue, 6 Apr 1999 21:35:52 -0700 (PDT)
Received: from smtp.udac.net (smtp.udac.net [193.44.79.123]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id VAA10952 for <[e-mail]>; Tue, 6 Apr 1999 21:35:50 -0700 (PDT)
Received: from caesar.udac.se (caesar.udac.se [193.44.79.10]) by smtp.udac.net (8.9.1/8.9.1) with ESMTP id GAA06494 for <[e-mail]>; Wed, 7 Apr 1999 06:36:31 +0200
Received: from mega (t3o69p107.telia.com [62.20.145.107]) by caesar.udac.se (8.7.3/NetworkC-1) with SMTP id GAA48513; Wed, 7 Apr 1999 06:36:24 +0200
Message-ID: <001c01be80b8$52da0430$[e-mail]>
From: "Anders Rundgren" <[e-mail]>
To: "Stephen Kent" <[e-mail]>, "Stefan Santesson" <[e-mail]>
Cc: <[e-mail]>, "'SEIS-List'" <[e-mail]>
Subject: Re: A $25,000,000,000 PKI   Was:Spec. on QC-low-fat & QC-heavy-bio
Date: Wed, 7 Apr 1999 06:34:35 +0100
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.2106.4
X-MimeOLE: Produced By Microsoft MimeOLE V4.72.2106.4
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by mail.proper.com id VAA10956
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Stefan,
>I totally agree with Steve here.

I am so surpriced :-)

>The approach to let a server manage and use your private keys to sign your
>signatures seams to be bad design for the sake of saving a little
>processing power in the client. It seams even more bad taken into
>consideration that computational power and memory capacity in clients
>become cheaper every day.

1) The problem is that the private keys to a company purchaser cert are
not "yours".  I.e. they are owned by the company that can control their use 100%
if they never leave their secure server.  That is a very good working model.

2) I think that the thin client solution has more with sw distribution which
is a true bottleneck recognized by most of the IT-industry 

>But creating and maintaining a general super secure multi-private-key
>center will not be cheaper and cheaper every day. 

Well, once done it will become cheaper compared to the alternatives.  Why
do you think network-centric computing and thin clients are the new favorites
among IT-managers?  Because these solutions give them both control
and convenience.

<snip>

Initially PKI was about certs and global X500 directories - Did not happen

Now it is zillions of certs distributed in various ways - Slow deployment

So I do really believe there is room for a "third wave"

Anders




Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id TAA02397 for ietf-pkix-bks; Tue, 6 Apr 1999 19:52:06 -0700 (PDT)
Received: from europe.std.com (europe.std.com [199.172.62.20]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id TAA02393 for <[e-mail]>; Tue, 6 Apr 1999 19:52:05 -0700 (PDT)
Received: from world.std.com by europe.std.com (STD1.2/BZS-8-1.0) id WAA06929; Tue, 6 Apr 1999 22:52:27 -0400 (EDT)
Received: by world.std.com (TheWorld/Spike-2.0) id AA04977; Tue, 6 Apr 1999 22:52:27 -0400
Message-Id: <[e-mail]>
To: Stefan Santesson <[e-mail]>
Cc: [e-mail], "'SEIS-List'" <[e-mail]>
Subject: Re: SEIS: Re: A $25,000,000,000 PKI Was:Spec. on QC-low-fat & QC-heavy-bio 
In-Reply-To: Your message of "Wed, 07 Apr 1999 01:09:17 EDT." <[e-mail]> 
Date: Tue, 06 Apr 1999 22:52:27 -0400
From: Dan Geer <[e-mail]>
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

    The approach to let a server manage and use your private keys to
    sign your signatures seams to be bad design for the sake of saving
    a little processing power in the client.

In this and all other matters of public acceptance of security
practices/devices, never underestimate the lure of convenience.
How else could one explain automatic surveillance traded off with
not having to carry correct change for the toll booth, say?

A bit afield,

--dan



Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id TAA02354 for ietf-pkix-bks; Tue, 6 Apr 1999 19:50:00 -0700 (PDT)
Received: from dsg1.OpenDirectory.com.au ([203.108.249.145]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id TAA02333; Tue, 6 Apr 1999 19:49:49 -0700 (PDT)
Received: by DSG1 with Internet Mail Service (5.0.1458.49) id <22ZNQLR4>; Wed, 7 Apr 1999 12:50:05 +1000
Message-ID: <D1A949D4508DD1119C8100400533BEDC0BE969@DSG1>
From: Alan Lloyd <[e-mail]>
To: "'Paul Hoffman / IMC'" <[e-mail]>, Stephen Kent <[e-mail]>, [e-mail]
Subject: RE: CA vs. EE cert processing
Date: Wed, 7 Apr 1999 12:50:01 +1000
X-Priority: 3
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.0.1458.49)
Content-Type: text/plain
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

I think the issue saying that X.509 is broken - is somewhat wrong.   If
it broken - then whats the alternative??   Ditto X. things are
ambiguious - when most tec specs (and I can name a few) that have more
holes than substance.

X.509 is a information and functional specification that does not
dictate HOW to use things in operational systems. That is a PROFILING
issue. Its just that the PXIX work is now PROFILING X.509 and naturally
operational Usage issues need to be dealt with in this process..

regards alan


> -----Original Message-----
> From:	Paul Hoffman / IMC 
> Sent:	Wednesday, April 07, 1999 6:13 AM
> To:	Stephen Kent; [e-mail]
> Subject:	Re: CA vs. EE cert processing
> 
> This summary is great. However, I come to slightly different
> conclusions 
> than you do, based on the same logic. My conclusion is that X.509 by
> itself 
> is broken due to the (now glaring) ambiguity. RFC 2459, though no
> paragon 
> of clarity, fixes the problem of X.509. Thus, *any* CA vendor or cert 
> authority who doesn't follow RFC 2459, for at least this part of the
> cert, 
> is using a broken protocol.
> 
> <gratuitous-swipe>
> Folks who implement protocols that start with "X." are used to this
> kind of 
> ambiguity. Let them figure out how to fix it.
> </gratuitous-swipe>
> 
> Should we have added an "ConformsToRFC2459" attribute to RFC 2459?
> 
> --Paul Hoffman, Director
> --Internet Mail Consortium


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id RAA24491 for ietf-pkix-bks; Tue, 6 Apr 1999 17:31:17 -0700 (PDT)
Received: from springfield.SIMPSONS (rotek1.lnk.telstra.net [139.130.48.58]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id RAA24486 for <[e-mail]>; Tue, 6 Apr 1999 17:31:14 -0700 (PDT)
Received: by SPRINGFIELD with Internet Mail Service (5.5.2232.9) id <2LSTP78Y>; Wed, 7 Apr 1999 10:29:56 +1000
Message-ID: <C13ABC20EDDAD111B29E0000B456EABC0A638E@SPRINGFIELD>
From: Andrew Probert <[e-mail]>
To: "'Anders Rundgren'" <[e-mail]>, Stephen Kent <[e-mail]>
Cc: [e-mail], "'SEIS-List'" <[e-mail]>
Subject: RE: A $25,000,000,000 PKI   Was:Spec. on QC-low-fat & QC-heavy-bi o
Date: Wed, 7 Apr 1999 10:29:55 +1000 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2232.9)
Content-Type: text/plain
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

I personally don't have a problem with private keys and certs being used in
digital phones, the keyboard being used for PIN entry, and some smart
applications for interaction, say with IVR servers and the newly released
Wireless Application Protocol to web servers.  [Insert new YASP (yet another
security protocol) here?]

All of this is technically viable, and desirable.  

No bio cert required.  The PIN to unlock the feature surely would be
sufficient for authentication.

Andew Probert
Rotek Consulting   http://www.rotek.com.au
a Division of Secure Network Solutions
Tel  [phone]
Fax [phone]



> -----Original Message-----
> From:	Anders Rundgren [SMTP:[e-mail]]
> Sent:	Wednesday, April 07, 1999 9:46 AM
> To:	Stephen Kent
> Cc:	[e-mail]; 'SEIS-List'
> Subject:	Re: A $25,000,000,000 PKI   Was:Spec. on QC-low-fat &
> QC-heavy-bio
> 
> Steve,
> 
> >>Of course, they are built on the fundamental principle that the
> >>client always has the "final" cert and key.  CyberPhone is not.
> >
> >Yes, this is the assumption, and it is a widely held one.  To change it a
> >lot of folks will need to be convinced otherwise.  You have a lot of work
> >ahead :-)!
> 
> 
> I know.  But its fun as well.
> 
> <snip>
> 
> >> Did you actually read the dynamic certs paper?
> 
> >Yes, and I don't buy all of it's premises.  The companies are the ones on
> >the hook, as you say, but they also need individual accountability, hence
> >the need for individual certs.
> 
> You got that in the CyberID.  Accountability is internal affaires is'nt
> it?
> 
> > Nobody has a lot of experience with large
> >scale deployment of PKIs in these contexts, so a statement about the
> >relative difficulties of deployment of certs to end users vs. the
> approach
> >you propose is premature. Insecure servers are a growing problem for
> >businesses, so I also challange your second assertion.
> 
> SET is an example of a large-scale PKI deployment that has _almost_
> flopped due to some of the factors that CyberPhone solves. Like:
> 
> Certificate distribution
> Thin client sw
> Mobile universal usage
> 
> <large snip>
> >Finally, your proposal is clearly focused on one particular deployment
> >model, which may or may not be realized.  There are others, based on more
> >computationally capable, mobile, personal devices, e.g., PDAs.
> 
> Computationally capable devices do not solve
> client certificate or client software distribution.
> 
> The market for mobile phones is so much bigger than for other
> devices (PDAs, PCs) etc. so IF this solution gets wide acceptance on
> the mobile phone market - most other client PKI solutions MAY just die.
> I.e. why pay additional money for certs, readers, software if your
> employees already have a high-quality solution in their hands?
> 
> BTW, why do you think MSFT is so interested in the mobile phone market?
> Because it is there the future of IT is happening!
> 
> > As I said
> >before, you should pursue any implementation approach you think is
> >fruitful, but don't ask this standards body to tailor parts of its work
> to
> >facilitate your (decidely nont mainstream) approach to using certs.
> 
> It COULD  become mainstream...
> 
> Now we both know pretty well where we stand in this case so
> could please somebody else comment on this? 
> 
> Anders
> 


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id QAA24122 for ietf-pkix-bks; Tue, 6 Apr 1999 16:59:07 -0700 (PDT)
Received: from falcon.prod.itd.earthlink.net (falcon.prod.itd.earthlink.net [207.217.120.74]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id QAA24118 for <[e-mail]>; Tue, 6 Apr 1999 16:59:05 -0700 (PDT)
Received: from lattin (sdn-ar-005casfraP082.dialsprint.net [158.252.212.84]) by falcon.prod.itd.earthlink.net (8.8.7/8.8.5) with SMTP id QAA22312; Tue, 6 Apr 1999 16:59:19 -0700 (PDT)
From: "Bill Lattin" <[e-mail]>
To: "Meggison, Tim" <[e-mail]>, "Tony Bartoletti" <[e-mail]>, "Dan Geer" <[e-mail]>, <[e-mail]>
Subject: RE: Time-stamp server. TimePrecision info
Date: Tue, 6 Apr 1999 16:58:51 -0700
Message-ID: <000501be8089$6b4aed60$54d4fc9e@lattin>
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.2173.0
X-MimeOLE: Produced By Microsoft MimeOLE V4.72.2106.4
In-Reply-To: <[e-mail]>
Importance: Normal
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

I agree.  Let's not arbitrarily limit ourselves based on current
capabilities or applications.  We are regularly trying to overcome arbitrary
limitations in other areas - such as address space, time format problems,
cryptographic key lengths - a little extra effort here can mean a system
that will work for centuries.  NTP works well today.  Let's extend it to
work well in future applications.

Bill Lattin
TTFN & Associates

> -----Original Message-----
> From: [e-mail] [mailto:[e-mail]]On Behalf
> Of Meggison, Tim
> Sent: Tuesday, April 06, 1999 10:56
> To: Tony Bartoletti; Dan Geer; [e-mail]
> Subject: RE: Time-stamp server. TimePrecision info
>
>
> I agree - we need to stop putting false limitations into
> standards/protocols.
>
> Rather than asking "What applications require microseconds today", let's
> turn it around and ask "Provide proof that microseconds won't be
> necessary a
> year from today."
>
> Let the market determine if it needs timestamps with the greater
> granularity.
>
> -----Original Message-----
> From: Tony Bartoletti [mailto:[e-mail]]
> Sent: Tuesday, April 06, 1999 1:37 PM
> To: Dan Geer; [e-mail]
> Subject: Re: Time-stamp server. TimePrecision info
>
>
> It may be true that, out of a sense of fairness, some events are
> considered "simultaneous" if they occur within the same second,
> or minute.  But 100 years ago, that may have been "days or weeks".
>
> I see technology rocketing ahead so fast my head spins.  Try, if
> you can, to imagine processor speeds and typical transmission
> bandwidths 1000 times greater than the fastest today.  It will
> not be too far off.  So I must concur with those who ask "What
> harm in allowing microseconds, or even nanoseconds, to be
> representable in the protocol?  We may not (yet) have many
> applications where such resolution (in signatures, certs, and
> authentication) is critical.  But can the same be said for
> "hours"?  Generally, no.
>
> Whatever you do, do not make a determination based upon saving
> a few bytes.  Such a decision will appear laughable in 10 years.
>
> ___tony___
>
>
> At 10:36 PM 4/2/99 -0500, Dan Geer wrote:
> >
> >We argue most about mechanism when we are least
> >reconciled with respect to requirement.  Perhaps
> >I can provide a succulent target:
> >
> >  The requirement for time is event serialization
> >  sufficient to support an economic level of recourse.
> >
> >Unremarkably, two events within the error band are
> >definitionally simultaneous -- the NYSE tick is
> >not micro-seconds but rather macro- and many events
> >are declared simultaneous in the interest of fairness,
> >to take a central example from high-value commerce.
> >
> >Is there an economist in the house?
> >
> >--dan
> >
> >
> >
>
> Tony Bartoletti                                             LL
> Center for Information Operations and Assurance          LL LL
> Lawrence Livermore National Laboratory                LL LL LL
> PO Box 808, L - 303                                   LL LL LL
> Livermore, CA 94551-9900                              LL LL LLLLLLLL
> phone: [phone]   fax: [phone]               LL LLLLLLLL
> email: [e-mail]                                   LLLLLLLL
>



Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id QAA23549 for ietf-pkix-bks; Tue, 6 Apr 1999 16:08:03 -0700 (PDT)
Received: from popmail.inbox.se (popmail.inbox.se [193.12.72.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id QAA23545 for <[e-mail]>; Tue, 6 Apr 1999 16:08:01 -0700 (PDT)
Received: from stefan2 (accurata.inbox.se [193.12.72.24]) by popmail.inbox.se (8.8.7/8.8.7) with SMTP id BAA32642; Wed, 7 Apr 1999 01:08:36 +0200
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: Windows Eudora Pro Version 3.0 (32)
Date: Wed, 07 Apr 1999 01:09:17 +0200
To: Stephen Kent <[e-mail]>, "Anders Rundgren" <[e-mail]>
From: Stefan Santesson <[e-mail]>
Subject: Re: SEIS:  Re: A $25,000,000,000 PKI   Was:Spec. on QC-low-fat & QC-heavy-bio
Cc: <[e-mail]>, "'SEIS-List'" <[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 mail.proper.com id QAA23546
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

I totally agree with Steve here.

The approach to let a server manage and use your private keys to sign your
signatures seams to be bad design for the sake of saving a little
processing power in the client. It seams even more bad taken into
consideration that computational power and memory capacity in clients
become cheaper every day.

But creating and maintaining a general super secure multi-private-key
center will not be cheaper and cheaper every day. 

To help viewing and comparing this system design with other systems, I view
the private-key-server as being a part of the client system. This simply
because this server handles the clients keys and will fall under the
clients responsibility.

So the question is if it is wise in some cases to split a normal client
into a sub-client-server system, which from the relying party's viewpoint
still acts like one client.

Using this angle to view this kind of system design makes it quite clear
that this design is simply a matter of local policy which by no means
should affect general PKI standards and technical profiles. 

/Stefan


At 05:47 PM 4/6/99 -0400, Stephen Kent wrote:
>--- Message on the SEIS mailing list ([e-mail])
>
>Anders,
>
>>>As far as a relying party is concerned, applying the signature consistent
>>>with the certificate associated with the transaction is the basis (though
>>>not the whole story) for non-repudiation of the transaction. All of the
>>>digital signature laws and guidelines embody this notion, as do all
>>>technical standards with which I am familiar.
>>
>>Of course, they are built on the fundamental principle that the
>>client always has the "final" cert and key.  CyberPhone is not.
>
>Yes, this is the assumption, and it is a widely held one.  To change it a
>lot of folks will need to be convinced otherwise.  You have a lot of work
>ahead :-)!
>
>>>If one has a security failure
>>>at the server, it's not the relying party's problem, it is the client's
>>>problem.
>>>This sort of server design introduces a new component to the
>>>system that must be trusted by the client
>>
>>The real "Client" in a business-to-business situation is the company (and
>>their server)
>>that have much more problems with their employees and certificate
>>distribution than they have
>>with unsecure servers.  By having the "person-client" sign a transaction
>>as well you are technically on the safe side.   Did you actually read the
>>dynamic certs paper?
>
>Yes, and I don't buy all of it's premises.  The companies are the ones on
>the hook, as you say, but they also need individual accountability, hence
>the need for individual certs.  Nobody has a lot of experience with large
>scale deployment of PKIs in these contexts, so a statement about the
>relative difficulties of deployment of certs to end users vs. the approach
>you propose is premature. Insecure servers are a growing problem for
>businesses, so I also challange your second assertion.
>
>>>and creates a higher value target if the server is shared by more than one
>>>user.  I'd say that makes this type of approach, in your system or any
>>>similar one,
>>>potentially a lot less secure than systems in which the signing is
>>>performed solely by the
>>>client.
>>
>>You say: "You can't build a secure server".  I say: "Every Internet-bank
>>system needs
>>the same security level that a CyberPhone intermediary server requires"
>
>Not necessarily.  The Internet banking we see today lacks non-repudiation,
>for one thing.
>
>>>While I can't prevent people from making a security implementation
>>>tradeoff in favor of systems of this sort, I certainly would not endorse
>>>any accommodations to a standard to facilitate system design approaches of
>>>this sort, due to the adverse secruity implications.
>>
>>I would not be so sure about that since there are TONS of advantages to
>>gain if you read carefully the around 25 pages of information on the site.
>
>What I read was probably less than the full 25 pages, given that I printed
>it and it didn't look that thick.  However, my tolerance for market
>literature as a means of technical communication is limited ...
>
>>And then there is the cost issue.  This is CHEAP, mass-produced stuff.
>>
>>Imagine a PKI that 2005 has 1 billion users (projected mobile phone
>>deployment)
>>where each user pays $25 to have his/hers CyberID.  That is
>>
>>    $25,000,000,000 / Year !!!!
>>
>>VeriSign, Thawte, are you listening?
>>
>>It is absolutely worth HUGE sums to create secure servers and even
>>"adjust" laws on
>>digital signatures.  Maybe BBN could be interested in the server
business? :-)
>
>Well, CyberTrust, the organization for which I am the CTO, is in the CA
>business and we understand how hard it is to make CA systems secure,
>despite the relatively restricted interfaces they exhibit.  I'm not saying
>that one can't develop and manage such secure servers, but it is very hard.
>
>Finally, your proposal is clearly focused on one particular deployment
>model, which may or may not be realized.  There are others, based on more
>computationally capable, mobile, personal devices, e.g., PDAs.  As I said
>before, you should pursue any implementation approach you think is
>fruitful, but don't ask this standards body to tailor parts of its work to
>facilitate your (decidely nont mainstream) approach to using certs.
>
>Steve
>
>
>----------------- SEIS mailing list ([e-mail])
>Info about this list: http://www.nc-forum.com/seis
>SEIS Contact: [e-mail]
>
-------------------------------------------------------------------
Stefan Santesson                <[e-mail]>
Accurata Systemsäkerhet AB      http://www.accurata.se
Slagthuset                      Tel. [phone]              
211 20  Malmö                   Fax. [phone]              
Sweden                        Mobile [phone]

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


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id PAA23418 for ietf-pkix-bks; Tue, 6 Apr 1999 15:52:22 -0700 (PDT)
Received: from dsg1.OpenDirectory.com.au ([203.108.249.145]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id PAA23413 for <[e-mail]>; Tue, 6 Apr 1999 15:52:13 -0700 (PDT)
Received: by DSG1 with Internet Mail Service (5.0.1458.49) id <22ZNQLQN>; Wed, 7 Apr 1999 08:52:39 +1000
Message-ID: <D1A949D4508DD1119C8100400533BEDC0BE968@DSG1>
From: Alan Lloyd <[e-mail]>
To: "'Stephen Kent'" <[e-mail]>
Cc: "''[e-mail] ' '" <[e-mail]>, "''[e-mail] ' '" <[e-mail]>
Subject: RE: Certificates, Directories, and Distinguished Names
Date: Wed, 7 Apr 1999 08:52:36 +1000
X-Priority: 3
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.0.1458.49)
Content-Type: text/plain; charset="iso-8859-1"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Thanks for that.

> -----Original Message-----
> From:	Stephen Kent 
> Sent:	Wednesday, April 07, 1999 12:42 AM
> To:	Alan Lloyd
> Cc:	''[e-mail] ' '; ''[e-mail] ' '
> Subject:	RE: Certificates, Directories, and Distinguished Names
> 
> Alan,
> 
> >	This can be agreed with or:
> >
> >	Say I get a cert/key from Honest John cert co - and its
> >recognised by a few dozen traveller kiosks around the country and
> toll
> >plazas on freeways.
> >	 When I use it from the car, the email address of the
> >transaction is toll booth 23@ Tullamaine -free way. roads and when I
> go
> >bush... another one day  the email address is
> >[e-mail]
> 
> Gee, you Aussies really like to send mail from out of the way places
> :-).
	yes, they are  so far "out of the way" that we have cars and
internet services there :-)

> We agree that the message recipients care more about who you are than
> the
> origin of a specific message.  However, in the e-mail world, the IDs
> people
> are comfortable with, are e-mail addresses.  
	Thats a view that should evolve - I dont like remembering email
addresses - simply because they seem to be changing  often.
	Quote from an OpenDirectory slide - circa 10 years ago -
Directories are use to hold information that one cannot remember  or
changes often and this is related to a name - that can be remebered and
does not change (or rarely changes).

> S/MIME decided to prefer that
> form of ID for their application environment, and so it is appropriate
> for
> PKIX to support it. It is also an ID form supported in IPsec for
> individuals.  This is just another case of folks in the Internet
> choosing
> to make use of an existing naming infrastructure,
> 
	Oh I see - I wondered what this Internet stuff was about -
perhaps I should use it too - and then my views might get accepted. :-) 

	(or perhaps I dont think that using email addresses instead of
directory systems is the way to go - ie. I dont believe in applying
newer technologies - business level directory systems - in the old way -
like email systems - simply because there is a difference and a damn
good reason for not doing so) 

	ie. Engineering concepts -  EG.  If I have a hammer (mail system
concepts)  and then get an electric drill (a directory system ) do I
still bash the back of the drill to do the engineering -no I use a
different approach to doing the job.?
>  i.e., the DNS, than to
> build and rely upon a new one, e.g., X.500.  This is an IETF WG, so
> this
> ought not be surprising!
	As said we are providing X.500 back ends to ISPs for Radius,
DHCP/DNS services - and ISPs provide (wait for it) Internet Services !

	Also, another view is that the networking properties of the
Internet is used to support a distributed name based information system
that businesses operate with using natural business entity names like
Conference Room 3, etc
	. ie. the Internet just becomes the pipes for many directory
services supporting the business information model of specific vertical
markets.

	This strikes me as valid input to the IETF process.

> >	It strikes me that nailing, cryptographically, information in a
> >certificate that may or may not get used could be a hinderance not a
> >benefit..
> 
> I'm in favor of not putting too many attributes into a cert; remember
> Steve's Rule of Revocation.  (I never knew this to foget it - Gee Is
> this published ?)
> 
> But we're really talking about an alternate
> Subject name here, not an added piece of info.
> 
	Is an Alternate Subject Name  (that seems to have no purpose)
not an added piece of info?  author - a confused aussie :-)

> 	<corporate merger activity advertisement deleted>
	Its strange you deleted this when in fact it highlights the very
problem using mail addresses in certs.
	Its also odd that the very problems I describe in the real world
which face operational systems dealing with churn and change - that can
get resolved with directory systems - not mail systems with certificates
- seem to get passed over...
	However, this has a good side - It just means that directory
system suppliers get ahead of the suppliers with "email" /DB approaches
to PKIs.

> >	It also strikes me that the last place I want my mail address is
> >in my certificate - as this will create and compound any archive and
> >rekey issues.
> 
> Huh? If the e-mail address is the chosen name form, then learn to deal
> with it!
> 
> <typical Alan text about X.500 as a panacea deleted>
	Directories are not a panacea - they are an sound and validated
enginerring approach to distributed information systems that run
businesses over the Internet and other networks. They have solved
problems ten years ago - that are being discussed today.


> Steve


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id PAA23368 for ietf-pkix-bks; Tue, 6 Apr 1999 15:47:02 -0700 (PDT)
Received: from smtp.udac.net (smtp.udac.net [193.44.79.123]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id PAA23364 for <[e-mail]>; Tue, 6 Apr 1999 15:47:00 -0700 (PDT)
Received: from caesar.udac.se (caesar.udac.se [193.44.79.10]) by smtp.udac.net (8.9.1/8.9.1) with ESMTP id AAA04312 for <[e-mail]>; Wed, 7 Apr 1999 00:47:34 +0200
Received: from mega (t1o69p22.telia.com [62.20.144.22]) by caesar.udac.se (8.7.3/NetworkC-1) with SMTP id AAA67242; Wed, 7 Apr 1999 00:47:33 +0200
Message-ID: <00b501be8087$962bdd70$[e-mail]>
From: "Anders Rundgren" <[e-mail]>
To: "Stephen Kent" <[e-mail]>
Cc: <[e-mail]>, "'SEIS-List'" <[e-mail]>
Subject: Re: A $25,000,000,000 PKI   Was:Spec. on QC-low-fat & QC-heavy-bio
Date: Wed, 7 Apr 1999 00:45:43 +0100
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.2106.4
X-MimeOLE: Produced By Microsoft MimeOLE V4.72.2106.4
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by mail.proper.com id PAA23365
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Steve,

>>Of course, they are built on the fundamental principle that the
>>client always has the "final" cert and key.  CyberPhone is not.
>
>Yes, this is the assumption, and it is a widely held one.  To change it a
>lot of folks will need to be convinced otherwise.  You have a lot of work
>ahead :-)!


I know.  But its fun as well.

<snip>

>> Did you actually read the dynamic certs paper?

>Yes, and I don't buy all of it's premises.  The companies are the ones on
>the hook, as you say, but they also need individual accountability, hence
>the need for individual certs.

You got that in the CyberID.  Accountability is internal affaires is'nt it?

> Nobody has a lot of experience with large
>scale deployment of PKIs in these contexts, so a statement about the
>relative difficulties of deployment of certs to end users vs. the approach
>you propose is premature. Insecure servers are a growing problem for
>businesses, so I also challange your second assertion.

SET is an example of a large-scale PKI deployment that has _almost_
flopped due to some of the factors that CyberPhone solves. Like:

Certificate distribution
Thin client sw
Mobile universal usage

<large snip>
>Finally, your proposal is clearly focused on one particular deployment
>model, which may or may not be realized.  There are others, based on more
>computationally capable, mobile, personal devices, e.g., PDAs.

Computationally capable devices do not solve
client certificate or client software distribution.

The market for mobile phones is so much bigger than for other
devices (PDAs, PCs) etc. so IF this solution gets wide acceptance on
the mobile phone market - most other client PKI solutions MAY just die.
I.e. why pay additional money for certs, readers, software if your
employees already have a high-quality solution in their hands?

BTW, why do you think MSFT is so interested in the mobile phone market?
Because it is there the future of IT is happening!

> As I said
>before, you should pursue any implementation approach you think is
>fruitful, but don't ask this standards body to tailor parts of its work to
>facilitate your (decidely nont mainstream) approach to using certs.

It COULD  become mainstream...

Now we both know pretty well where we stand in this case so
could please somebody else comment on this? 

Anders




Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id OAA22799 for ietf-pkix-bks; Tue, 6 Apr 1999 14:46:59 -0700 (PDT)
Received: from po1.bbn.com (PO1.BBN.COM [192.1.50.38]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id OAA22795 for <[e-mail]>; Tue, 6 Apr 1999 14:46:58 -0700 (PDT)
Received: from [128.89.0.110] (COSMEC.BBN.COM [128.89.0.110]) by po1.bbn.com (8.9.1/8.9.1) with ESMTP id RAA23709; Tue, 6 Apr 1999 17:47:33 -0400 (EDT)
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
X-Sender: [e-mail]
Message-Id: <v04020a13b3302d9b9da4@[128.89.0.110]>
In-Reply-To: <009801be8079$d634b850$[e-mail]>
Date: Tue, 6 Apr 1999 17:47:31 -0400
To: "Anders Rundgren" <[e-mail]>
From: Stephen Kent <[e-mail]>
Subject: Re: A $25,000,000,000 PKI   Was:Spec. on QC-low-fat & QC-heavy-bio
Cc: <[e-mail]>, "'SEIS-List'" <[e-mail]>
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Anders,

>>As far as a relying party is concerned, applying the signature consistent
>>with the certificate associated with the transaction is the basis (though
>>not the whole story) for non-repudiation of the transaction. All of the
>>digital signature laws and guidelines embody this notion, as do all
>>technical standards with which I am familiar.
>
>Of course, they are built on the fundamental principle that the
>client always has the "final" cert and key.  CyberPhone is not.

Yes, this is the assumption, and it is a widely held one.  To change it a
lot of folks will need to be convinced otherwise.  You have a lot of work
ahead :-)!

>>If one has a security failure
>>at the server, it's not the relying party's problem, it is the client's
>>problem.
>>This sort of server design introduces a new component to the
>>system that must be trusted by the client
>
>The real "Client" in a business-to-business situation is the company (and
>their server)
>that have much more problems with their employees and certificate
>distribution than they have
>with unsecure servers.  By having the "person-client" sign a transaction
>as well you are technically on the safe side.   Did you actually read the
>dynamic certs paper?

Yes, and I don't buy all of it's premises.  The companies are the ones on
the hook, as you say, but they also need individual accountability, hence
the need for individual certs.  Nobody has a lot of experience with large
scale deployment of PKIs in these contexts, so a statement about the
relative difficulties of deployment of certs to end users vs. the approach
you propose is premature. Insecure servers are a growing problem for
businesses, so I also challange your second assertion.

>>and creates a higher value target if the server is shared by more than one
>>user.  I'd say that makes this type of approach, in your system or any
>>similar one,
>>potentially a lot less secure than systems in which the signing is
>>performed solely by the
>>client.
>
>You say: "You can't build a secure server".  I say: "Every Internet-bank
>system needs
>the same security level that a CyberPhone intermediary server requires"

Not necessarily.  The Internet banking we see today lacks non-repudiation,
for one thing.

>>While I can't prevent people from making a security implementation
>>tradeoff in favor of systems of this sort, I certainly would not endorse
>>any accommodations to a standard to facilitate system design approaches of
>>this sort, due to the adverse secruity implications.
>
>I would not be so sure about that since there are TONS of advantages to
>gain if you read carefully the around 25 pages of information on the site.

What I read was probably less than the full 25 pages, given that I printed
it and it didn't look that thick.  However, my tolerance for market
literature as a means of technical communication is limited ...

>And then there is the cost issue.  This is CHEAP, mass-produced stuff.
>
>Imagine a PKI that 2005 has 1 billion users (projected mobile phone
>deployment)
>where each user pays $25 to have his/hers CyberID.  That is
>
>    $25,000,000,000 / Year !!!!
>
>VeriSign, Thawte, are you listening?
>
>It is absolutely worth HUGE sums to create secure servers and even
>"adjust" laws on
>digital signatures.  Maybe BBN could be interested in the server business? :-)

Well, CyberTrust, the organization for which I am the CTO, is in the CA
business and we understand how hard it is to make CA systems secure,
despite the relatively restricted interfaces they exhibit.  I'm not saying
that one can't develop and manage such secure servers, but it is very hard.

Finally, your proposal is clearly focused on one particular deployment
model, which may or may not be realized.  There are others, based on more
computationally capable, mobile, personal devices, e.g., PDAs.  As I said
before, you should pursue any implementation approach you think is
fruitful, but don't ask this standards body to tailor parts of its work to
facilitate your (decidely nont mainstream) approach to using certs.

Steve


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id OAA22166 for ietf-pkix-bks; Tue, 6 Apr 1999 14:08:36 -0700 (PDT)
Received: from smtp.udac.net (smtp.udac.net [193.44.79.123]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id OAA22161 for <[e-mail]>; Tue, 6 Apr 1999 14:08:31 -0700 (PDT)
Received: from caesar.udac.se (caesar.udac.se [193.44.79.10]) by smtp.udac.net (8.9.1/8.9.1) with ESMTP id XAA03172 for <[e-mail]>; Tue, 6 Apr 1999 23:09:10 +0200
Received: from mega (t3o69p64.telia.com [62.20.145.64]) by caesar.udac.se (8.7.3/NetworkC-1) with SMTP id XAA67206; Tue, 6 Apr 1999 23:09:07 +0200
Message-ID: <009801be8079$d634b850$[e-mail]>
From: "Anders Rundgren" <[e-mail]>
To: "Stephen Kent" <[e-mail]>
Cc: <[e-mail]>, "'SEIS-List'" <[e-mail]>
Subject: A $25,000,000,000 PKI   Was:Spec. on QC-low-fat & QC-heavy-bio
Date: Tue, 6 Apr 1999 23:07:17 +0100
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.2106.4
X-MimeOLE: Produced By Microsoft MimeOLE V4.72.2106.4
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by mail.proper.com id OAA22162
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Steve,

>As far as a relying party is concerned, applying the signature consistent
>with the certificate associated with the transaction is the basis (though
>not the whole story) for non-repudiation of the transaction. All of the
>digital signature laws and guidelines embody this notion, as do all
>technical standards with which I am familiar.

Of course, they are built on the fundamental principle that the
client always has the "final" cert and key.  CyberPhone is not.

>If one has a security failure
>at the server, it's not the relying party's problem, it is the client's
>problem. 
>This sort of server design introduces a new component to the
>system that must be trusted by the client

The real "Client" in a business-to-business situation is the company (and their server)
that have much more problems with their employees and certificate distribution than they have
with unsecure servers.  By having the "person-client" sign a transaction
as well you are technically on the safe side.   Did you actually read the dynamic certs paper?

>and creates a higher value target if the server is shared by more than one
>user.  I'd say that makes this type of approach, in your system or any similar one, 
>potentially a lot less secure than systems in which the signing is performed solely by the
>client. 

You say: "You can't build a secure server".  I say: "Every Internet-bank system needs
the same security level that a CyberPhone intermediary server requires"

>While I can't prevent people from making a security implementation
>tradeoff in favor of systems of this sort, I certainly would not endorse
>any accommodations to a standard to facilitate system design approaches of
>this sort, due to the adverse secruity implications.

I would not be so sure about that since there are TONS of advantages to
gain if you read carefully the around 25 pages of information on the site.

And then there is the cost issue.  This is CHEAP, mass-produced stuff.

Imagine a PKI that 2005 has 1 billion users (projected mobile phone deployment)
where each user pays $25 to have his/hers CyberID.  That is

    $25,000,000,000 / Year !!!!

VeriSign, Thawte, are you listening?

It is absolutely worth HUGE sums to create secure servers and even "adjust" laws on
digital signatures.  Maybe BBN could be interested in the server business? :-)

Anders Rundgren
Senior Internet e-commerce Architect

http://www.mobilephones-tng.com





Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id NAA21608 for ietf-pkix-bks; Tue, 6 Apr 1999 13:12:49 -0700 (PDT)
Received: from aum (ip11.proper.com [165.227.249.11]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id NAA21604; Tue, 6 Apr 1999 13:12:47 -0700 (PDT)
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.32 (Beta)
Date: Tue, 06 Apr 1999 13:12:40 -0700
To: Stephen Kent <[e-mail]>, [e-mail]
From: Paul Hoffman / IMC <[e-mail]>
Subject: Re: CA vs. EE cert processing
In-Reply-To: <v04020a0ab3300fde9fbd@[128.89.0.110]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

This summary is great. However, I come to slightly different conclusions 
than you do, based on the same logic. My conclusion is that X.509 by itself 
is broken due to the (now glaring) ambiguity. RFC 2459, though no paragon 
of clarity, fixes the problem of X.509. Thus, *any* CA vendor or cert 
authority who doesn't follow RFC 2459, for at least this part of the cert, 
is using a broken protocol.

<gratuitous-swipe>
Folks who implement protocols that start with "X." are used to this kind of 
ambiguity. Let them figure out how to fix it.
</gratuitous-swipe>

Should we have added an "ConformsToRFC2459" attribute to RFC 2459?

--Paul Hoffman, Director
--Internet Mail Consortium


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id MAA21367 for ietf-pkix-bks; Tue, 6 Apr 1999 12:47:28 -0700 (PDT)
Received: from po1.bbn.com (PO1.BBN.COM [192.1.50.38]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id MAA21363 for <[e-mail]>; Tue, 6 Apr 1999 12:47:27 -0700 (PDT)
Received: from [128.89.0.110] (COSMEC.BBN.COM [128.89.0.110]) by po1.bbn.com (8.9.1/8.9.1) with ESMTP id PAA24819; Tue, 6 Apr 1999 15:47:57 -0400 (EDT)
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
X-Sender: [e-mail]
Message-Id: <v04020a0cb33011a50ae1@[128.89.0.110]>
In-Reply-To: <01BE8057.309231B0@HYDRA>
Date: Tue, 6 Apr 1999 15:38:18 -0400
To: Anders Rundgren <[e-mail]>
From: Stephen Kent <[e-mail]>
Subject: Re: SEIS:  RE: Spec. on QC-low-fat & QC-heavy-bio
Cc: "'[e-mail]'" <[e-mail]>, "'SEIS-List'" 	 <[e-mail]>
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Anders,

As far as a relying party is concerned, applying the signature consistent
with the certificate associated with the transaction is the basis (though
not the whole story) for non-repudiation of the transaction. All of the
digital signature laws and guidelines embody this notion, as do all
technical standards with which I am familiar. If one has a security failure
at the server, it's not the relying party's problem, it is the client's
problem. This sort of server design introduces a new component to the
system that must be trusted by the client, and creates a higher value
target if the server is shared by more than one user.  I'd say that makes
this type of approach, in your system or any similar one, potentially a lot
less secure than systems in which the signing is performed solely by the
client.  While I can't prevent people from making a security implementation
tradeoff in favor of systems of this sort, I certainly would not endorse
any accommodations to a standard to facilitate system design approaches of
this sort, due to the adverse secruity implications.

Steve


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id MAA21184 for ietf-pkix-bks; Tue, 6 Apr 1999 12:27:23 -0700 (PDT)
Received: from po1.bbn.com (PO1.BBN.COM [192.1.50.38]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id MAA21180 for <[e-mail]>; Tue, 6 Apr 1999 12:27:22 -0700 (PDT)
Received: from [128.89.0.110] (COSMEC.BBN.COM [128.89.0.110]) by po1.bbn.com (8.9.1/8.9.1) with ESMTP id PAA14748 for <[e-mail]>; Tue, 6 Apr 1999 15:28:00 -0400 (EDT)
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
X-Sender: [e-mail]
Message-Id: <v04020a0ab3300fde9fbd@[128.89.0.110]>
Date: Tue, 6 Apr 1999 15:25:10 -0400
To: [e-mail]
From: Stephen Kent <[e-mail]>
Subject: CA vs. EE cert processing
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Folks,

This memo examines certificate processing with regard to determining
whether a certificate is associated with a CA or an EE, to determine where
the ambiguity lies and thus help clarify this discussion. Upon further
analysis I discovered that the issue is more complex that I originally
realized, and so my simple algorithm was oversimplified. However the
suggestions put forth so far (as best I recall) also seem to miss the
point, as explained below.

First question: is this a v1 certificate or a v3 certificate?  If v1, there
was no way to mark the certificate as a CA or EE explicitly, so some other
information must be used. Nothing we say in 2459 is applicable here as we
deal only with v3 certs, and thus no changes in 2459 would change how an
implementation makes this determination for a v1 cert.  Whatever means an
implementation used to make this determination for v1 certs can still be
employed.  Thus v1 certs will not be addressed in the remainder of this
analysis, and I assume that software should be written to be sensitive to
whether it is dealing with v1 or v3 certificates.

Second question: is there a basicConstraints extension present in the
certificate? If not, then according to RFC 2459 this must be an EE cert,
since CA certs MUST contain this extension. But, according to X.509, if the
constraint is absent (or present but marked non-critical and not understood
by the implementation), then it is up to the implementation to use other
means of determining if the certificate is for a CA or an EE.  At this
point we have ambiguity, based on examining only the presence or absence of
this constraint in a v3 cert.  X.509 does not specify what else should be
done. So, not knowing if the certificate was issued by an RFC 2459
compliant CA, or an X.509 compliant CA, we have to go to "Plan B."  Note
that nothing we change in RFC 2459 can fix this problem as the ambiguity is
traceable to X.509.

If we have a basicConstraints extension, is it NULL or does it have the CA
flag set to TRUE.  If NULL, then it is an EE certificate according to both
RFC 2459 and X.509 (even though 2459 suggests that one not bother to
include the extension in this case). If the CA flag is TRUE, then it is a
CA certificate, according to both 2459 and X.509.  So, if we get to this
point, we have no ambiguity for either CA or EE certs.

Plan B:  We are here because we have a v3 certificate with no
basicConstraints extension and because we don't know if the CA that issued
the certificate was operating in compliance with either 2459 or X.509.  We
now have to examine other fields of the certificate, or have some out of
band mechanism to help.  X.509 provides no guidance on how to do this,
which leaves implementers wondering.  RFC 2459 provides no guidance because
a CA complying with the RFC would not have this problem.

So, how can we remove this residual ambiguity?  Well, it can't be removed
by a change only to RFC 2459, because that standard is not the source of
the ambiguity.  If one were to change X.509, to require that a compliant CA
include the basicConstraints extension (critical or not), when a
certificate was issued to a CA, then the ambiguity would be removed at its
source.  If this change were made to X.509, no change to 2459 would be
required.  Specifically, changing 2459 to call for inclusion of this
constraint for EE certificates (either as a SHOULD or MUST) would not
address the ambiguity encountered above.

Some have suggested that we should consider changes to 2459 to help
alleviate problems resulting from CAs that do not comply with 2459.  The
above analysis suggests that if the source of the certificate is an X.509
compliant CA, the solution lies with a change to X.509.  If the CA is not
assumed to comply with either 2459 or X.509, I do not see how fixing either
2459 or X.509 could possible help.


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id KAA20358 for ietf-pkix-bks; Tue, 6 Apr 1999 10:55:54 -0700 (PDT)
Received: from Sonnet.GSC.GTE.Com ([e-mail] [204.152.26.66]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id KAA20354 for <[e-mail]>; Tue, 6 Apr 1999 10:55:53 -0700 (PDT)
Received: from gscex01.gsc.gte.com ("port 2608"@gscex01.ndhm.gtegsc.com [155.95.162.170]) by Sonnet.GSC.GTE.Com (PMDF V5.2-30 #29038) with ESMTP id <[e-mail]> for [e-mail]; Tue, 6 Apr 1999 13:55:44 -0400 (EDT)
Received: by gscex01.ndhm.gtegsc.com with Internet Mail Service (5.5.2448.0) id <2L9MM44G>; Tue, 06 Apr 1999 13:55:44 -0400
Content-return: allowed
Date: Tue, 06 Apr 1999 13:55:43 -0400
From: "Meggison, Tim" <[e-mail]>
Subject: RE: Time-stamp server. TimePrecision info
To: Tony Bartoletti <[e-mail]>, Dan Geer <[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"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

I agree - we need to stop putting false limitations into
standards/protocols.

Rather than asking "What applications require microseconds today", let's
turn it around and ask "Provide proof that microseconds won't be necessary a
year from today."

Let the market determine if it needs timestamps with the greater
granularity.

-----Original Message-----
From: Tony Bartoletti [mailto:[e-mail]]
Sent: Tuesday, April 06, 1999 1:37 PM
To: Dan Geer; [e-mail]
Subject: Re: Time-stamp server. TimePrecision info


It may be true that, out of a sense of fairness, some events are
considered "simultaneous" if they occur within the same second,
or minute.  But 100 years ago, that may have been "days or weeks".

I see technology rocketing ahead so fast my head spins.  Try, if
you can, to imagine processor speeds and typical transmission
bandwidths 1000 times greater than the fastest today.  It will
not be too far off.  So I must concur with those who ask "What
harm in allowing microseconds, or even nanoseconds, to be
representable in the protocol?  We may not (yet) have many
applications where such resolution (in signatures, certs, and
authentication) is critical.  But can the same be said for
"hours"?  Generally, no.

Whatever you do, do not make a determination based upon saving
a few bytes.  Such a decision will appear laughable in 10 years.

___tony___


At 10:36 PM 4/2/99 -0500, Dan Geer wrote:
>
>We argue most about mechanism when we are least
>reconciled with respect to requirement.  Perhaps
>I can provide a succulent target:
>
>  The requirement for time is event serialization
>  sufficient to support an economic level of recourse.
>
>Unremarkably, two events within the error band are
>definitionally simultaneous -- the NYSE tick is
>not micro-seconds but rather macro- and many events
>are declared simultaneous in the interest of fairness,
>to take a central example from high-value commerce.
>
>Is there an economist in the house?
>
>--dan
>
>
>

Tony Bartoletti                                             LL
Center for Information Operations and Assurance          LL LL
Lawrence Livermore National Laboratory                LL LL LL
PO Box 808, L - 303                                   LL LL LL
Livermore, CA 94551-9900                              LL LL LLLLLLLL
phone: [phone]   fax: [phone]               LL LLLLLLLL
email: [e-mail]                                   LLLLLLLL


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id KAA20029 for ietf-pkix-bks; Tue, 6 Apr 1999 10:37:22 -0700 (PDT)
Received: from poptop.llnl.gov (poptop.llnl.gov [128.115.18.65]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id KAA20025 for <[e-mail]>; Tue, 6 Apr 1999 10:37:21 -0700 (PDT)
Received: from catalyst (catalyst.llnl.gov [128.115.223.10]) by poptop.llnl.gov (8.8.8/LLNL-3.0.2/pop.llnl.gov-5.1) with SMTP id KAA03435; Tue, 6 Apr 1999 10:37:01 -0700 (PDT)
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.3 (32)
Date: Tue, 06 Apr 1999 10:36:33 -0700
To: Dan Geer <[e-mail]>, [e-mail]
From: Tony Bartoletti <[e-mail]>
Subject: Re: Time-stamp server. TimePrecision info 
In-Reply-To: <[e-mail]>
References: <A blather of messages as of "Fri, 02 Apr 1999 13:46:17 EST." <003d01be7d52$3ecaf030$fa4bffd0@brick>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

It may be true that, out of a sense of fairness, some events are
considered "simultaneous" if they occur within the same second,
or minute.  But 100 years ago, that may have been "days or weeks".

I see technology rocketing ahead so fast my head spins.  Try, if
you can, to imagine processor speeds and typical transmission
bandwidths 1000 times greater than the fastest today.  It will
not be too far off.  So I must concur with those who ask "What
harm in allowing microseconds, or even nanoseconds, to be
representable in the protocol?  We may not (yet) have many
applications where such resolution (in signatures, certs, and
authentication) is critical.  But can the same be said for
"hours"?  Generally, no.

Whatever you do, do not make a determination based upon saving
a few bytes.  Such a decision will appear laughable in 10 years.

___tony___


At 10:36 PM 4/2/99 -0500, Dan Geer wrote:
>
>We argue most about mechanism when we are least
>reconciled with respect to requirement.  Perhaps
>I can provide a succulent target:
>
>  The requirement for time is event serialization
>  sufficient to support an economic level of recourse.
>
>Unremarkably, two events within the error band are
>definitionally simultaneous -- the NYSE tick is
>not micro-seconds but rather macro- and many events
>are declared simultaneous in the interest of fairness,
>to take a central example from high-value commerce.
>
>Is there an economist in the house?
>
>--dan
>
>
>

Tony Bartoletti                                             LL
Center for Information Operations and Assurance          LL LL
Lawrence Livermore National Laboratory                LL LL LL
PO Box 808, L - 303                                   LL LL LL
Livermore, CA 94551-9900                              LL LL LLLLLLLL
phone: [phone]   fax: [phone]               LL LLLLLLLL
email: [e-mail]                                   LLLLLLLL


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id IAA18702 for ietf-pkix-bks; Tue, 6 Apr 1999 08:59:05 -0700 (PDT)
Received: from smtp.udac.net (smtp.udac.net [193.44.79.123]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id IAA18693 for <[e-mail]>; Tue, 6 Apr 1999 08:58:41 -0700 (PDT)
Received: from caesar.udac.se (caesar.udac.se [193.44.79.10]) by smtp.udac.net (8.9.1/8.9.1) with ESMTP id RAA30261 for <[e-mail]>; Tue, 6 Apr 1999 17:59:18 +0200
Received: from HYDRA ([195.198.186.68]) by caesar.udac.se (8.7.3/NetworkC-1) with SMTP id RAA96900; Tue, 6 Apr 1999 17:59:04 +0200
Received: by HYDRA with Microsoft Mail id <01BE8057.309231B0@HYDRA>; Tue, 6 Apr 1999 17:59:17 +0200
Message-ID: <01BE8057.309231B0@HYDRA>
From: Anders Rundgren <[e-mail]>
To: "'Stephen Kent'" <[e-mail]>
Cc: "'[e-mail]'" <[e-mail]>, "'SEIS-List'" <[e-mail]>
Subject: RE: Spec. on QC-low-fat & QC-heavy-bio
Date: Tue, 6 Apr 1999 17:59:16 +0200
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Steve,
>I visit your web site and reviewed the marketing white papers there.

Thank you for taking some of your precious time to read this!
I hope that you do not only regard this as "marketing" material although
the language is of that kind.  By design so to say :-)

>One feature of the system you propose, but that has not been mentioned before,
>is that this proposal calls for users to cede control of certificates to a
>server, which acts on their behalf.  The user employs one (local) cert to
>authenticate himself to this server, and to direct it to act as his
>intermediary.

You got it!  This is a good description of CyberPhone when you use SET, OBI etc.

>This raises serious secruity issues, especially wrt non-repudiation.

Well, it does raise security issues, but (hopefully) not unsolvable such.

Actually there are commercial products like the GlobSet ServerWallet that
builds on the same basic principle.  Similar solutions have also been launched by
Brokat and BankGate.  The difference is that CyberPhone generalizes this
principle so that it becomes a "Universal Client PKI Platform" that though
requires some special hardware as well.  

But let's get back to the security issues wrt non-repudiation!

Client - IntermediaryServer(IS) - RP

When you use a "virtual" certificate (intermediary server with your terminology)
the non-repudiation issue for IS (that has the wanted resource) versus the RP is as today.

But then we have the relation between the client and the IS
that may or may not require a client-signed transaction.
This is a matter of trust between the client and the intermediary server.

I.e. you COULD require the client to sign a transaction and then
the Intermediary Server would save the signed transaction (in case
of disputes with the client), strip of the client's signature and add its
own signature (SET, OBI, or something). 

Regards
Anders





Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id IAA17779 for ietf-pkix-bks; Tue, 6 Apr 1999 08:06:03 -0700 (PDT)
Received: from Sonnet.GSC.GTE.Com ([e-mail] [131.131.251.1]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id IAA17773 for <[e-mail]>; Tue, 6 Apr 1999 08:05:57 -0700 (PDT)
Received: from gscex01.gsc.gte.com ("port 1711"@gscex01.ndhm.gtegsc.com [155.95.162.170]) by Sonnet.GSC.GTE.Com (PMDF V5.2-30 #29038) with ESMTP id <[e-mail]> for [e-mail]; Tue, 6 Apr 1999 11:06:26 -0400 (EDT)
Received: by gscex01.ndhm.gtegsc.com with Internet Mail Service (5.5.2448.0) id <2L9MM323>; Tue, 06 Apr 1999 11:06:26 -0400
Content-return: allowed
Date: Tue, 06 Apr 1999 11:06:25 -0400
From: "Meggison, Tim" <[e-mail]>
Subject: RE: Changes to RFC2459
To: "Kent, Steve-GTEI" <[e-mail]>, [e-mail]
Cc: [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"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

 

Steve,

Your algorithm works great as long as everyone is following the rules of the
RFC.  Unfortunately, this does not hold true in practice.  When one
processes a cert, there is no indicator that it was generated according to
the RFC.  

As an implementer of a CA, it would be desirable to remove all ambiguity to
improve interoperability.  It is very easy for a cert-generator already to
set the Basic Constraints for an EE cert - this is not new technology, and
in fact is necessary to support other profiles (eg. SET).

Besides saving a few bits in a certificate, what other benefits exist by not
using the Basic Constraints to indicate an EE cert?



Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id HAA17648 for ietf-pkix-bks; Tue, 6 Apr 1999 07:58:20 -0700 (PDT)
Received: from po1.bbn.com (PO1.BBN.COM [192.1.50.38]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id HAA17644 for <[e-mail]>; Tue, 6 Apr 1999 07:58:19 -0700 (PDT)
Received: from [128.89.0.110] (COSMEC.BBN.COM [128.89.0.110]) by po1.bbn.com (8.9.1/8.9.1) with ESMTP id KAA08044; Tue, 6 Apr 1999 10:58:50 -0400 (EDT)
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
X-Sender: [e-mail]
Message-Id: <v04020a05b32fd0bfc9bf@[128.89.0.110]>
In-Reply-To: <01BE8032.61FE52D0@HYDRA>
Date: Tue, 6 Apr 1999 10:58:20 -0400
To: Anders Rundgren <[e-mail]>
From: Stephen Kent <[e-mail]>
Subject: Re: SEIS:  Spec. on QC-low-fat & QC-heavy-bio
Cc: "'[e-mail]'" <[e-mail]>, "'SEIS-List'" 	 <[e-mail]>
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Anders,

I visit your web site and reviewed the marketing white papers there.  One
feature of the system you propose, but that has not been mentioned before,
is that this proposal calls for users to cede control of certificates to a
server, which acts on their behalf.  The user employs one (local) cert to
authenticate himself to this server, and to direct it to act as his
intermediary.  This raises serious secruity issues, especially wrt
non-repudiation.

Steve


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id HAA17536 for ietf-pkix-bks; Tue, 6 Apr 1999 07:48:32 -0700 (PDT)
Received: from po1.bbn.com (PO1.BBN.COM [192.1.50.38]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id HAA17532 for <[e-mail]>; Tue, 6 Apr 1999 07:48:30 -0700 (PDT)
Received: from [128.89.0.110] (COSMEC.BBN.COM [128.89.0.110]) by po1.bbn.com (8.9.1/8.9.1) with ESMTP id KAA03275; Tue, 6 Apr 1999 10:48:50 -0400 (EDT)
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
X-Sender: [e-mail]
Message-Id: <v04020a03b32fcbad9856@[128.89.0.110]>
In-Reply-To: <D1A949D4508DD1119C8100400533BEDC0BE960@DSG1>
Date: Tue, 6 Apr 1999 10:42:00 -0400
To: Alan Lloyd <[e-mail]>
From: Stephen Kent <[e-mail]>
Subject: RE: Certificates, Directories, and Distinguished Names
Cc: "''[e-mail] ' '" <[e-mail]>, "''[e-mail] ' '" <[e-mail]>
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Alan,

>	This can be agreed with or:
>
>	Say I get a cert/key from Honest John cert co - and its
>recognised by a few dozen traveller kiosks around the country and toll
>plazas on freeways.
>	 When I use it from the car, the email address of the
>transaction is toll booth 23@ Tullamaine -free way. roads and when I go
>bush... another one day  the email address is
>[e-mail]

Gee, you Aussies really like to send mail from out of the way places :-).

We agree that the message recipients care more about who you are than the
origin of a specific message.  However, in the e-mail world, the IDs people
are comfortable with, are e-mail addresses.  S/MIME decided to prefer that
form of ID for their application environment, and so it is appropriate for
PKIX to support it. It is also an ID form supported in IPsec for
individuals.  This is just another case of folks in the Internet choosing
to make use of an existing naming infrastructure, i.e., the DNS, than to
build and rely upon a new one, e.g., X.500.  This is an IETF WG, so this
ought not be surprising!

>	It strikes me that nailing, cryptographically, information in a
>certificate that may or may not get used could be a hinderance not a
>benefit..

I'm in favor of not putting too many attributes into a cert; remember
Steve's Rule of Revocation.  But we're really talking about an alternate
Subject name here, not an added piece of info.

	<corporate merger activity advertisement deleted>

>	It also strikes me that the last place I want my mail address is
>in my certificate - as this will create and compound any archive and
>rekey issues.

Huh? If the e-mail address is the chosen name form, then learn to deal with it!

<typical Alan text about X.500 as a panacea deleted>

Steve


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id HAA17369 for ietf-pkix-bks; Tue, 6 Apr 1999 07:38:34 -0700 (PDT)
Received: from po1.bbn.com (PO1.BBN.COM [192.1.50.38]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id HAA17365 for <[e-mail]>; Tue, 6 Apr 1999 07:38:33 -0700 (PDT)
Received: from [128.89.0.110] (COSMEC.BBN.COM [128.89.0.110]) by po1.bbn.com (8.9.1/8.9.1) with ESMTP id KAA28843; Tue, 6 Apr 1999 10:38:57 -0400 (EDT)
Mime-Version: 1.0
Content-Type: multipart/alternative; boundary="============_-1288712952==_ma============"
X-Sender: [e-mail]
Message-Id: <v04020a02b32fc79aa347@[128.89.0.110]>
In-Reply-To: <[e-mail]>
References: <v04020a1ab32eee1684e5@[128.89.0.110]>
Date: Tue, 6 Apr 1999 10:31:54 -0400
To: [e-mail]
From: Stephen Kent <[e-mail]>
Subject: Re: Changes to RFC2459
Cc: [e-mail]
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

--============_-1288712952==_ma============
Content-Type: text/plain; charset="us-ascii"

Terry,

>Even in a v3 environment there still needs to be a process defined (possibly
>involving user interaction) which approves the operation and defines other
>operational parameters that will be associated with the CA.  Just because the
>certificate looks like a valid v3 CA doesn't me I will always believe it.

I agree whole heartedly with this design principle when it applies to
self-seigned (root) CA certs.  I would not agree that user interaction is
needed for subordinate CA certs.
>>
>
>> However, since v3 certs are clearly identified as such, one could use a
>> different algorithm for CA determination for v1 vs. v3 certs. I don't
>> criticize Netscape for adopting the algorithm you have described prior to
>> development of the PKIX standards, I also don't think that PKIX v3 cert
>> standards should be constrained by existing implementations that could have
>> been coded to distinguish v3 vs. v1 certs.
>
>I believe you are suggesting that an application SHOULD (MUST?) disallow
>requests to install certificates as a CA if the certificate extensions do not
>allow this use.  This may be a good idea.  However (to bring us back to the
>original discussion on basicConstraints), if PKIX does not require a
>basicConstraints extension in EE certs, then an application would have to rely
>on the version field to tell  whether v3 rules (policies?) should be applied.

First, this is not always an application issue per se; it may be subsumed
by an API for cert management.  Second, other than "root CA" certs, there
is not a notion of "installing" a cert in the cert chain validation
algorithm, so I interpret your comments in that more narrow context.
Third, I am suggesting that it is approrpiate for the cert processing
software to first examine the version field prior to subsequent processing,
something that I would consider generally good software design practice.
Having examined the version field, then one might reasonably use different
rules for determining CA vs. EE certs.

>I'm not sure I've seen this use of the version field before.  In
>particular, if
>basicConstraints would have been the only extension in the certificate,
>section
>4.1.2.1 says that the version field should be set to version 1.  This would
>kick in v1 processing rules (for compatibility reasons).  To get the kind of
>processing you want, the version would have to be set to version 3 even though
>there are no extensions included in the certificate.

I don't understand how you are interpreting section 4.1.2.1 of RFC 2459.
The relevant text says:
   4.1.2.1  Version

   This field describes the version of the encoded certificate.  When
   extensions are used, as expected in this profile, use X.509 version 3
   (value is 2).  If no extensions are present, but a UniqueIdentifier
   is present, use version 2 (value is 1).  If only basic fields are
   present, use version 1 (the value is omitted from the certificate as
   the default value).


Are you confusing the term "basic fields" here with the "basicConstraints"
extension?  The former term refers only to the fields in a version 1
certificate.   So, even if basicConstraints is the only extention present,
the version number MUST be 3 to comply with 2459.

>A better solution would be to include the basicConstraints extensions in EE
>certificates.  In that case, the application could reject these v3
>certificates
>in CA management functions, while still supporting the v1 environment.  Of
>course the cost is extra room in the certificate to carry the extension data.

I still fail to see why the algorithm I described fails to work if one uses
EE vs. CA rules appropriate to the version type of the certificate, which
is consistent with 2459.

Steve
--============_-1288712952==_ma============
Content-Type: text/enriched; charset="us-ascii"

Terry,


>Even in a v3 environment there still needs to be a process defined
(possibly

>involving user interaction) which approves the operation and defines
other

>operational parameters that will be associated with the CA.  Just
because the

>certificate looks like a valid v3 CA doesn't me I will always believe
it.


I agree whole heartedly with this design principle when it applies to
self-seigned (root) CA certs.  I would not agree that user interaction
is needed for subordinate CA certs. 

>>

>

>> However, since v3 certs are clearly identified as such, one could
use a

>> different algorithm for CA determination for v1 vs. v3 certs. I
don't

>> criticize Netscape for adopting the algorithm you have described
prior to

>> development of the PKIX standards, I also don't think that PKIX v3
cert

>> standards should be constrained by existing implementations that
could have

>> been coded to distinguish v3 vs. v1 certs.

>

>I believe you are suggesting that an application SHOULD (MUST?)
disallow

>requests to install certificates as a CA if the certificate extensions
do not

>allow this use.  This may be a good idea.  However (to bring us back
to the

>original discussion on basicConstraints), if PKIX does not require a

>basicConstraints extension in EE certs, then an application would have
to rely

>on the version field to tell  whether v3 rules (policies?) should be
applied.


First, this is not always an application issue per se; it may be
subsumed by an API for cert management.  Second, other than "root CA"
certs, there is not a notion of "installing" a cert in the cert chain
validation algorithm, so I interpret your comments in that more narrow
context.  Third, I am suggesting that it is approrpiate for the cert
processing software to first examine the version field prior to
subsequent processing, something that I would consider generally good
software design practice.  Having examined the version field, then one
might reasonably use different rules for determining CA vs. EE certs.


>I'm not sure I've seen this use of the version field before.  In
particular, if

>basicConstraints would have been the only extension in the
certificate, section

>4.1.2.1 says that the version field should be set to version 1.  This
would

>kick in v1 processing rules (for compatibility reasons).  To get the
kind of

>processing you want, the version would have to be set to version 3
even though

>there are no extensions included in the certificate.


I don't understand how you are interpreting section 4.1.2.1 of RFC
2459.  The relevant text says:

   <fontfamily><param>Courier_New</param><bigger>4.1.2.1  Version


   This field describes the version of the encoded certificate.  When

   extensions are used, as expected in this profile, use X.509 version
3

   (value is 2).  If no extensions are present, but a UniqueIdentifier

   is present, use version 2 (value is 1).  If only basic fields are

   present, use version 1 (the value is omitted from the certificate
as

   the default value).



</bigger></fontfamily>Are you confusing the term "basic fields" here
with the "basicConstraints" extension?  The former term refers only to
the fields in a version 1 certificate.   So, even if basicConstraints
is the only extention present, the version number MUST be 3 to comply
with 2459.


>A better solution would be to include the basicConstraints extensions
in EE

>certificates.  In that case, the application could reject these v3
certificates

>in CA management functions, while still supporting the v1 environment.
 Of

>course the cost is extra room in the certificate to carry the
extension data.


I still fail to see why the algorithm I described fails to work if one
uses EE vs. CA rules appropriate to the version type of the
certificate, which is consistent with 2459.


Steve

--============_-1288712952==_ma============--


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id HAA17184 for ietf-pkix-bks; Tue, 6 Apr 1999 07:18:23 -0700 (PDT)
Received: from po1.bbn.com (PO1.BBN.COM [192.1.50.38]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id HAA17180 for <[e-mail]>; Tue, 6 Apr 1999 07:18:22 -0700 (PDT)
Received: from [128.89.0.110] (COSMEC.BBN.COM [128.89.0.110]) by po1.bbn.com (8.9.1/8.9.1) with ESMTP id KAA18735; Tue, 6 Apr 1999 10:18:52 -0400 (EDT)
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
X-Sender: [e-mail]
Message-Id: <v04020a01b32fc6415235@[128.89.0.110]>
In-Reply-To: <[e-mail]>
Date: Tue, 6 Apr 1999 10:15:33 -0400
To: [e-mail]
From: Stephen Kent <[e-mail]>
Subject: Re: Changes to RFC2459
Cc: [e-mail]
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Peter,

>>If that's the argument, then we need to consider such a change based on at
>>least these issues:
>>
>>       - under what circumstances would an EE use a self-signed cert? note
>>        that PKIX always describes self-signed certs in the context of CAs,
>>         not of EEs.  X.509 makes NO mention of self-signed certs
>
>Internal use within an organisation is quite popular.  Give a J.Random Luser a
>PKI toolkit and a "Get it going by the end of the week" and you'll end up with
>self-signed certs everywhere ("We tried all the options, when we clicked on
>this one everything started working.  We're doing X.509, right?").

Good example. I imagine such behavior will/does occur, but that does not
mean that our standards should encourage it via codification.

>>       - should PKIX change to accommodate current browser conventions that
>>       are still ambiguous with regard to strict adherence to X.509?
>
>I'd say we need to take current browser (and anything else) conventions into
>account.  Given the choice between working with existing implementations and
>claiming compliance to a standard, I'd say the majority of implementors will
>go with the former (I can't see too many implementors getting far telling
>their boss that "It breaks/exhibits undefined behaviour with any web browser,
>but it is compliant with <standard which boss has probably never heard
>of>").
>For an example of this thinking in action, look at the use of the
>email/rfc822Address in the DN vs the alt name - the major CA's are still
>putting it in the DN for compatibility with legacy stuff even though RFC 2459
>says you're not supposed to do this (I've had a report that one major vendors
>email software will crash when it finds a cert with the email address in the
>alt name instead of the DN, moving it into the DN fixes the problem.
>Needless
>to say the people working with this have decided to go for compatibility
>rather than compliance (and I had to hack my code to selectively transport
>the
>email address across furlongs of extensions into the DN where it's not even
>supposed to be)).
>
>(Insert at this point the can-of-worms argument about "do we need to track
> every broken implementation out there?" - this is why I've been trying to
> document all the known problems in the style guide).

There are legitimate, differing views of whether a standard should attempt
to encompass existing practice of the sort you note, or should focus on
what the standard developers believe is "the right thing to do."  We have
examples in the IETF of both sorts of standards.  My preference is for the
latter, and the authors of RFC 2459 have taken this path in several
instances; you noted the name for for e-mail addresses above. This document
went through WG and IETF last call, and IESG approval, before being
published as an RFC.  Thus, it's rather late in the process to be
questioning this philosophical orientation. So far, I see no compelling
reason to change our direction in this regard.

Steve


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id EAA15685 for ietf-pkix-bks; Tue, 6 Apr 1999 04:35:15 -0700 (PDT)
Received: from smtp.udac.net (smtp.udac.net [193.44.79.123]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id EAA15681 for <[e-mail]>; Tue, 6 Apr 1999 04:35:13 -0700 (PDT)
Received: from caesar.udac.se (caesar.udac.se [193.44.79.10]) by smtp.udac.net (8.9.1/8.9.1) with ESMTP id NAA32700 for <[e-mail]>; Tue, 6 Apr 1999 13:35:41 +0200
Received: from HYDRA ([195.198.186.68]) by caesar.udac.se (8.7.3/NetworkC-1) with SMTP id NAA53640; Tue, 6 Apr 1999 13:35:36 +0200
Received: by HYDRA with Microsoft Mail id <01BE8032.61FE52D0@HYDRA>; Tue, 6 Apr 1999 13:35:49 +0200
Message-ID: <01BE8032.61FE52D0@HYDRA>
From: Anders Rundgren <[e-mail]>
To: "'[e-mail]'" <[e-mail]>, "'SEIS-List'" <[e-mail]>
Subject: Spec. on QC-low-fat & QC-heavy-bio
Date: Tue, 6 Apr 1999 13:35:47 +0200
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Hi
on a considerably upgraded document (its predecessor has been floating
around before in this list) available at:

http://www.mobilephones-tng.com/papers/idcards.html

you will hopefully find some interesting stuff on how you in a practical way
can combine "low-fat" QCs  with their absolute opposite,
the "heavy" QCs with biometric information.

Note that the solution does NOT depend on
1) Out-of-band handling of biometric data (like mail attachments)
2) Directories holding biometric data  (with their associated privacy problems)
3) Cumbersome maintenance of local RP databases with biometric data.

And it keeps privacy in the hands of the user.  Where it should be.

Note that the specification targets an open environment rather than
the needs of an organizational PKI. 

This conceptual specification does not go into ASN.1 representations though.

[constructive] Criticism is welcomed!

Regards
Anders Rundgren




Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id DAA14382 for ietf-pkix-bks; Tue, 6 Apr 1999 03:21:17 -0700 (PDT)
Received: from mail.student.auckland.ac.nz (mail.student.auckland.ac.nz [130.216.35.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id DAA14376 for <[e-mail]>; Tue, 6 Apr 1999 03:21:14 -0700 (PDT)
Received: from cs26.cs.auckland.ac.nz ([e-mail] [130.216.36.9]) by mail.student.auckland.ac.nz (8.8.6/8.8.6/cs-master) with SMTP id WAA03203; Tue, 6 Apr 1999 22:21:40 +1200 (NZST) (sender [e-mail])
Received: by cs26.cs.auckland.ac.nz (relaymail v0.9) id <92339410003480>; Tue, 6 Apr 1999 22:21:40 (NZST)
From: [e-mail] (Peter Gutmann)
To: [e-mail], [e-mail]
Subject: Re: Changes to RFC2459
Reply-To: [e-mail]
X-Charge-To: pgut001
X-Authenticated: relaymail v0.9 on cs26.cs.auckland.ac.nz
Date: Tue, 6 Apr 1999 22:21:40 (NZST)
Message-ID: <[e-mail]>
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

[Slightly off-topic design philosophy comments follow]
 
>Even in a v3 environment there still needs to be a process defined (possibly
>involving user interaction) which approves the operation and defines other
>operational parameters that will be associated with the CA.  Just because the
>certificate looks like a valid v3 CA doesn't me I will always believe it.
 
I don't think this will work, because it assumes (and, in a worst-case
situation, absolutely requires) that users know what they're doing.  I've
always tried to design things so that they'll still work right if used by a
lobotomized flatworm, even if this means adding redundant or unnecessary
information to data to help sort things out (eg basicConstraints in EE certs).
For an example of where the "rely on user intervention" approach falls down,
the users manual for a recently-deployed nontrivial (>100K users) project which
uses certs and which will result in considerable pain to users if there are any
problems, contains in the manual a section which says something like "You'll
see some certificate warning dialogs pop up.  Click OK to get rid of them" (to
see why this is a problem, assume the text of the dialog says "Do you want to
install a new certificate for 'Verisign Class 1 Public Primary Certification
Authority'").
 
User education won't fix this.  Even if you were to add the several pages of
text needed to explain what a certification authority was and what the user was
doing by clicking OK, virtually noone would read it (I suspect most of them
won't even read the manual as it currently stands, they just see a box with an
OK button and click it because that's what they've done 1000 times before when
they were in a situation like that).
 
Do any vendors actually perform any testing with lobotom^H^H^H^Husers?  I know
that companies like Microsoft go to some effort to test various aspects of
their user interfaces with real users (rather than the UI designers or
programmers) to make sure they get them just right, does anyone do this with
PKI-related products?
 
Peter.
 



Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id AAA04679 for ietf-pkix-bks; Tue, 6 Apr 1999 00:22:47 -0700 (PDT)
Received: from natasha1. (natasha-gw.checkpoint.com [199.203.73.129]) by mail.proper.com (8.8.8/8.8.5) with SMTP id AAA04675 for <[e-mail]>; Tue, 6 Apr 1999 00:22:42 -0700 (PDT)
Received: from cale.checkpoint.com (gray.checkpoint.com [199.203.71.94]) by cale.checkpoint.com (8.9.1/8.9.1) with ESMTP id JAA00868; Tue, 6 Apr 1999 09:25:03 +0200 (IST)
Message-ID: <[e-mail]>
Date: Tue, 06 Apr 1999 10:21:54 +0300
From: Moshe Litvin <[e-mail]>
X-Mailer: Mozilla 4.51 [en] (WinNT; I)
X-Accept-Language: en
MIME-Version: 1.0
To: Stephen Kent <[e-mail]>
CC: [e-mail]
Subject: Re: Changes to RFC2459
References: <v04020a10b32ad27828c8@[128.89.0.110]> <v04020a0bb32ea83a186e@[128.89.0.110]>
Content-Type: multipart/mixed; boundary="------------247E866470FBFC5D40208D74"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

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

Steve,

Stephen Kent wrote:

> Moshe,
>
> >The problem is that the algorithm is actually:
> >
> >IF BasicConstraints PRESENT {
> >       IF BasicConstraints.cA is TRUE
> >                THEN certificate-is-ca
> >                ELSE certificate-is-ee
> >}
> >ELSE {
> >    IF issuing CA is fully PKIX compliant
> >        THEN certificate-is-ee
> >        ELSE undefind
> >}
> >
> >We cannot eliminate the undefined decision(*) but we can create certificates
> >that doesn't need that by encouraging CA to put a BasicConstraints that
> >contains BasicConstraints.cA=FALSE (It is encoded as NULL but this is just
> >encoding) rule).
>
> The test I defined applies equally well for X.509 compliant CAs as well as
> PKIX compliant CAs, as I stated.

How? X.509 compliant CA can issue a certificate without basicConstraints to end
entity. In regards to this situation it says:

 If this extension is not present or is flagged non-critical and is not
recognized by a certificate-using system, then that system should use other means
to determine if the certified public key may be used to verify certificate
signatures.

Which is the "undefined" situation in my case.


> Are you suggesting that we should change
> PKIX to somewhow better accommodate CAs that don't comply with it?

No. We should change PKIX such that PKIX CA will issue certificates that don't
require out of bound information to know if they are CA certificates or not.

>
>
> We can look at this from two perspectives:
>
>         - first, we're in chanrge of PKIX standards, so of course we're
> most interested in the situation where the CA is PKIX compliant.  if you
> assume otherwise, then there can be many ways in which processing will be
> adversely affected.
>         - second, since X.509 does not require the presence of this
> extension, but merely recommends its use for EE certs, your modification of
> my simple test also is deficient. why not include clauses for X.509
> compliant CAs who do not elect to include the extension?

Why my test includes it. It says that it can't reach a decision for those CA's.

>
>
> If one changed both PKIX and X.509 to mandate inclusion of this extension
> for both EE and CA certs, AND if all CAs were compliant with either
> standard, then life would, indeed, be easier.  But, if you use as an
> example, the ambiguity that may arise from CAs that comply with neither
> standard, why bother?
>
> Steve

Totally removing the ambiguity is now almost impossible. But creating a
certificate that contains no ambiguity is very easy and should be encouraged
instead of discouraged.

Moshe

--------------247E866470FBFC5D40208D74
Content-Type: text/x-vcard; charset=us-ascii;
 name="moshe.vcf"
Content-Transfer-Encoding: 7bit
Content-Description: Card for Moshe Litvin
Content-Disposition: attachment;
 filename="moshe.vcf"

begin:vcard 
n:Litvin;Moshe
tel;fax:[phone]
tel;work:[phone]
x-mozilla-html:TRUE
org:Check Point Software Technologies Ltd.
adr:;;;;;;
version:2.1
email;internet:[e-mail]
fn:Moshe Litvin
end:vcard

--------------247E866470FBFC5D40208D74--



Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id UAA18147 for ietf-pkix-bks; Mon, 5 Apr 1999 20:16:10 -0700 (PDT)
Received: from gmtsw.com (test.glassey.com [207.126.98.130] (may be forged)) by mail.proper.com (8.8.8/8.8.5) with SMTP id UAA18136 for <[e-mail]>; Mon, 5 Apr 1999 20:16:05 -0700 (PDT)
Received: from brick by gmtsw.com (SMI-8.6/SMI-SVR4) id UAA15316; Mon, 5 Apr 1999 20:16:51 -0700
Message-ID: <00b201be7fdb$34877310$90bffad0@brick>
From: "Todd S. Glassey" <[e-mail]>
To: "Robert Zuccherato" <[e-mail]>, "IETF PKIX" <[e-mail]>
Subject: Re: 3 Time Stamping issues
Date: Mon, 5 Apr 1999 20:11:44 -0700
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 V4.72.3110.3
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

SNIP ---


How about if I add the following text:

When issuing an error response with PKIFailureInfo having value
timeNotAvailable (14) then the TSA MAY place any random value in the tstTime
field of TSTInfo.  Upon receiving such an error response a client MUST not
trust the time contained in the tstTime field.

This seems like reasonable behaviour.

--> Why Not force a Null Response? This way if the value of the tstTime is
NULL then you know that there is an issue with the timesource...

--> Todd





Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id TAA16331 for ietf-pkix-bks; Mon, 5 Apr 1999 19:57:04 -0700 (PDT)
Received: from dsg1.OpenDirectory.com.au ([203.108.249.145]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id TAA16322 for <[e-mail]>; Mon, 5 Apr 1999 19:56:57 -0700 (PDT)
Received: by DSG1 with Internet Mail Service (5.0.1458.49) id <22ZNQLL0>; Tue, 6 Apr 1999 12:57:24 +1000
Message-ID: <D1A949D4508DD1119C8100400533BEDC0BE960@DSG1>
From: Alan Lloyd <[e-mail]>
To: "'Stephen Kent'" <[e-mail]>
Cc: "''[e-mail] ' '" <[e-mail]>, "''[e-mail] ' '" <[e-mail]>
Subject: RE: Certificates, Directories, and Distinguished Names
Date: Tue, 6 Apr 1999 12:57:23 +1000
X-Priority: 3
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.0.1458.49)
Content-Type: text/plain
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Some comments -

> -----Original Message-----
> From:	Stephen Kent 
> Sent:	Tuesday, April 06, 1999 3:49 AM
> To:	Alan Lloyd
> Cc:	''[e-mail] ' '; ''[e-mail] ' '
> Subject:	RE: Certificates, Directories, and Distinguished Names
> 
> Alan,
> 
> >My question was really aimed at the cert extensions subject - issuer
> alt
> >names.. I still dont understand what and why these are in the cert -
> if
> >its baggage for some obscure reason - then thats OK - but if its for
> >validation process issues - then they have to be spelled out. And if
> >they are just baggage, instead of making them  "alt name forms"- why
> not
> >call then subject and issuer additional info or in fact just make
> them
> >cert ext directory attributes?
> >
> >We seem to have in these extensions, a lot of form without content.
> 
> Alt names allow a PKI to use name forms most closely aligned to the
> application context with which the certs will be used. That, by
> itself, is
> sufficient reason to provide them. 
> 
	This can be agreed with or:

	Say I get a cert/key from Honest John cert co - and its
recognised by a few dozen traveller kiosks around the country and toll
plazas on freeways.
	 When I use it from the car, the email address of the
transaction is toll booth 23@ Tullamaine -free way. roads and when I go
bush... another one day  the email address is
[e-mail]

	It strikes me that nailing, cryptographically, information in a
certificate that may or may not get used could be a hinderance not a
benefit..

	As you are aware by now OpendDrectory - *(opendirectory.com) got
bought by Platinum Technologies (platinum.com) who have justy been
bought by CA (ca.com) -- so whats the key management issues eh! 

	It also strikes me that the last place I want my mail address is
in my certificate - as this will create and compound any archive and
rekey issues.

	I just dont believe in making a certficate a replacement for
directory entry (because the processes that use certificates dont have a
directy service) - when the certficate was designed to work within the
framework of processes that used directory services. Simply because -
its the human/operational side that will have to deal with the issues -
and companies - first and foremost want less operating costs and bigger
systems.

	To date - few have able to explain a real benefit of these alt
names - and even fewer have dealt with the dynamics of cert/key re
issuance and archive because of these extra attributes and their
implications with domain agile devices, working into multi domain
business environments..

	Oh well..

	regards alan
> Look at the messes created by shoe
> horning DNS names into DNs in SSL certs, or e-mail addresses into DNs
> in
> S/MIME.  We can't go back and change the Subject and Issuer to be
> GeneralNames due to backward compatability constraints, so ...
> 
> Steve


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id TAA12986 for ietf-pkix-bks; Mon, 5 Apr 1999 19:09:27 -0700 (PDT)
Received: from stargate.zergo.com.au ([e-mail] [203.2.208.130]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id TAA12973 for <[e-mail]>; Mon, 5 Apr 1999 19:09:17 -0700 (PDT)
Received: from michaelz (dhcp-64.ws.zergo.com.au [192.168.72.64]) by stargate.zergo.com.au (8.9.1/8.8.7) with SMTP id MAA32156; Tue, 6 Apr 1999 12:08:10 +1000
Received: by localhost with Microsoft MAPI; Tue, 6 Apr 1999 12:08:24 +1000
Message-ID: <[e-mail]>
From: Michael Zolotarev <[e-mail]>
Reply-To: "[e-mail]" <[e-mail]>
To: "'Stephen Kent'" <[e-mail]>, Paul Koning <[e-mail]>
Cc: "[e-mail]" <[e-mail]>, "[e-mail]" <[e-mail]>, "[e-mail]" <[e-mail]>, "'[e-mail]'" <[e-mail]>, "'[e-mail]'" <[e-mail]>
Subject: RE: Time-stamp server. TimePrecision info
Date: Tue, 6 Apr 1999 12:08:21 +1000
Organization: Baltimore Pty Ltd
X-Mailer: Microsoft Internet E-mail/MAPI - 8.0.0.4211
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Thank you, Stephen.
This looks like a very reasonable point.

Just think about it - aren't we are getting carried away from the main 
purpose of Time Stamping? Which is, of course, TIME STAMPING. Which is to 
define a TTP to provide "a proof-of-existence of a message at an instant of 
time". Old good PKIX, non-repudiation, etc, etc

Instead, what the discussion is now getting dragged into appears to have 
more to do with some kind of Real Time Mission Critical Globally 
Distributed Secure Ultimate Time Synchronization Service.

Yes, there are a lot of requirements which fall under the umbrella of the 
abovementioned RTMCGDSUTSS :), and there are solutions for this. And 
today's mail can serve as an excellent reference point for anybody who 
would like to find out about that class of systems. And the issue may well 
worth its own discussion thread.

But is it what has been originally set as a goal of Time Stamping?

If the answer is Yes, then we should change dramatically our original pa  
radigm. My own coordinate system would definitely have to undergo major 
tuning up.

Otherwise, should we concentrate on identifying the scope of the system, 
based on classical boring Use Case approach?

Once we are clear on the scope of the system, we would be much better off 
thinking about TS Token, precision and other unarguably important issues.

And of course, the fact that TSS may not happen to be exactly what NTP and 
other services are for, does not preclude borrowing solutions/approaches 
that are already out there.

Michael Z

Stephen wrote:
>in a realtime system, it is not clear that the audit trails need
>or could tolerate the overhead of signing every log entry.  They might 
need
>accurate local clocks for the logs, but do they need time stamps from
>network accessible servers?



Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id SAA11266 for ietf-pkix-bks; Mon, 5 Apr 1999 18:00:16 -0700 (PDT)
Received: from netscape.com (h-205-217-237-47.netscape.com [205.217.237.47]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id SAA11262 for <[e-mail]>; Mon, 5 Apr 1999 18:00:15 -0700 (PDT)
Received: from tintin.mcom.com (tintin.mcom.com [205.217.233.42]) by netscape.com (8.8.5/8.8.5) with ESMTP id SAA23944 for <[e-mail]>; Mon, 5 Apr 1999 18:00:16 -0700 (PDT)
Received: from netscape.com ([208.12.62.90]) by tintin.mcom.com (Netscape Messaging Server 4.03) with ESMTP id F9QTGT00.ABI; Mon, 5 Apr 1999 18:00:29 -0700 
Message-ID: <[e-mail]>
Date: Mon, 05 Apr 1999 18:00:08 -0700
From: [e-mail] (Terry Hayes)
Reply-To: [e-mail]
Organization: Netscape Communications, Inc.
X-Mailer: Mozilla 4.5 [en] (WinNT; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Stephen Kent <[e-mail]>
CC: [e-mail]
Subject: Re: Changes to RFC2459
References: <v04020a1ab32eee1684e5@[128.89.0.110]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Stephen,

  A comment on your response, and an attempt to bring the discussion back to
the basicConstraints issue.

Stephen Kent wrote:

> ... What you describe is an
> algorithm, including user interaction, for declaring a cert to be that of a
> CA in certain contexts, and subject to certain later processing constraints
> (analogous to use of nameConstraints), all of which is understandable in a
> pre-v3 environment.

Even in a v3 environment there still needs to be a process defined (possibly
involving user interaction) which approves the operation and defines other
operational parameters that will be associated with the CA.  Just because the
certificate looks like a valid v3 CA doesn't me I will always believe it.

>

> However, since v3 certs are clearly identified as such, one could use a
> different algorithm for CA determination for v1 vs. v3 certs. I don't
> criticize Netscape for adopting the algorithm you have described prior to
> development of the PKIX standards, I also don't think that PKIX v3 cert
> standards should be constrained by existing implementations that could have
> been coded to distinguish v3 vs. v1 certs.

I believe you are suggesting that an application SHOULD (MUST?) disallow
requests to install certificates as a CA if the certificate extensions do not
allow this use.  This may be a good idea.  However (to bring us back to the
original discussion on basicConstraints), if PKIX does not require a
basicConstraints extension in EE certs, then an application would have to rely
on the version field to tell  whether v3 rules (policies?) should be applied.

I'm not sure I've seen this use of the version field before.  In particular, if
basicConstraints would have been the only extension in the certificate, section
4.1.2.1 says that the version field should be set to version 1.  This would
kick in v1 processing rules (for compatibility reasons).  To get the kind of
processing you want, the version would have to be set to version 3 even though
there are no extensions included in the certificate.

A better solution would be to include the basicConstraints extensions in EE
certificates.  In that case, the application could reject these v3 certificates
in CA management functions, while still supporting the v1 environment.  Of
course the cost is extra room in the certificate to carry the extension data.


Terry Hayes
[e-mail]



Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id QAA09684 for ietf-pkix-bks; Mon, 5 Apr 1999 16:44:38 -0700 (PDT)
Received: from mail.student.auckland.ac.nz (mail.student.auckland.ac.nz [130.216.35.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id QAA09679 for <[e-mail]>; Mon, 5 Apr 1999 16:44:35 -0700 (PDT)
Received: from cs26.cs.auckland.ac.nz ([e-mail] [130.216.36.9]) by mail.student.auckland.ac.nz (8.8.6/8.8.6/cs-master) with SMTP id LAA23218; Tue, 6 Apr 1999 11:45:02 +1200 (NZST) (sender [e-mail])
Received: by cs26.cs.auckland.ac.nz (relaymail v0.9) id <92335590224415>; Tue, 6 Apr 1999 11:45:02 (NZST)
From: [e-mail] (Peter Gutmann)
To: [e-mail], [e-mail]
Subject: Re: Changes to RFC2459
Reply-To: [e-mail]
X-Charge-To: pgut001
X-Authenticated: relaymail v0.9 on cs26.cs.auckland.ac.nz
Date: Tue, 6 Apr 1999 11:45:02 (NZST)
Message-ID: <[e-mail]>
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Stephen Kent <[e-mail]>
 
>If that's the argument, then we need to consider such a change based on at
>least these issues:
>
>       - under what circumstances would an EE use a self-signed cert? note
>        that PKIX always describes self-signed certs in the context of CAs,
>         not of EEs.  X.509 makes NO mention of self-signed certs
 
Internal use within an organisation is quite popular.  Give a J.Random Luser a
PKI toolkit and a "Get it going by the end of the week" and you'll end up with
self-signed certs everywhere ("We tried all the options, when we clicked on
this one everything started working.  We're doing X.509, right?").
 
>       - should PKIX change to accommodate current browser conventions that
>       are still ambiguous with regard to strict adherence to X.509?
 
I'd say we need to take current browser (and anything else) conventions into 
account.  Given the choice between working with existing implementations and 
claiming compliance to a standard, I'd say the majority of implementors will 
go with the former (I can't see too many implementors getting far telling 
their boss that "It breaks/exhibits undefined behaviour with any web browser, 
but it is compliant with <standard which boss has probably never heard of>").  
For an example of this thinking in action, look at the use of the 
email/rfc822Address in the DN vs the alt name - the major CA's are still 
putting it in the DN for compatibility with legacy stuff even though RFC 2459 
says you're not supposed to do this (I've had a report that one major vendors 
email software will crash when it finds a cert with the email address in the 
alt name instead of the DN, moving it into the DN fixes the problem.  Needless 
to say the people working with this have decided to go for compatibility 
rather than compliance (and I had to hack my code to selectively transport the 
email address across furlongs of extensions into the DN where it's not even
supposed to be)).
 
(Insert at this point the can-of-worms argument about "do we need to track
 every broken implementation out there?" - this is why I've been trying to
 document all the known problems in the style guide).
 
Peter.
 



Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id QAA09179 for ietf-pkix-bks; Mon, 5 Apr 1999 16:05:44 -0700 (PDT)
Received: from po1.bbn.com (PO1.BBN.COM [192.1.50.38]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id QAA09175 for <[e-mail]>; Mon, 5 Apr 1999 16:05:43 -0700 (PDT)
Received: from [128.89.0.110] (COSMEC.BBN.COM [128.89.0.110]) by po1.bbn.com (8.9.1/8.9.1) with ESMTP id TAA01178; Mon, 5 Apr 1999 19:06:13 -0400 (EDT)
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
X-Sender: [e-mail]
Message-Id: <v04020a1ab32eee1684e5@[128.89.0.110]>
In-Reply-To: <[e-mail]>
Date: Mon, 5 Apr 1999 19:02:20 -0400
To: [e-mail]
From: Stephen Kent <[e-mail]>
Subject: Re: Changes to RFC2459
Cc: [e-mail]
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Terry,

Thanks for the additional clarification.  What you describe is an
algorithm, including user interaction, for declaring a cert to be that of a
CA in certain contexts, and subject to certain later processing constraints
(analogous to use of nameConstraints), all of which is understandable in a
pre-v3 environment.

However, since v3 certs are clearly identified as such, one could use a
different algorithm for CA determination for v1 vs. v3 certs. I don't
criticize Netscape for adopting the algorithm you have described prior to
development of the PKIX standards, I also don't think that PKIX v3 cert
standards should be constrained by existing implementations that could have
been coded to distinguish v3 vs. v1 certs.

Steve


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id PAA08869 for ietf-pkix-bks; Mon, 5 Apr 1999 15:33:48 -0700 (PDT)
Received: from netscape.com (h-205-217-237-47.netscape.com [205.217.237.47]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id PAA08865 for <[e-mail]>; Mon, 5 Apr 1999 15:33:44 -0700 (PDT)
Received: from tintin.mcom.com (tintin.mcom.com [205.217.233.42]) by netscape.com (8.8.5/8.8.5) with ESMTP id PAA10865 for <[e-mail]>; Mon, 5 Apr 1999 15:33:47 -0700 (PDT)
Received: from netscape.com ([208.12.62.90]) by tintin.mcom.com (Netscape Messaging Server 4.03) with ESMTP id F9QMOP00.18F for <[e-mail]>; Mon, 5 Apr 1999 15:34:01 -0700 
Message-ID: <[e-mail]>
Date: Mon, 05 Apr 1999 15:33:40 -0700
From: [e-mail] (Terry Hayes)
Reply-To: [e-mail]
Organization: Netscape Communications, Inc.
X-Mailer: Mozilla 4.5 [en] (WinNT; U)
X-Accept-Language: en
MIME-Version: 1.0
To: [e-mail]
Subject: Re: Changes to RFC2459
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

I would like to restate Michael Sierchio's description of what defines a
CA in
Netscape's products.  I would say that by installing the certificate in
question, the user of the application is asserting that the certificate
belongs
to a CA.

The MIME type "application/x-x509-ca-cert" begins the process of
installing the
CA, but it is up to the user to confirm that operation, and to set
various
trust (or policy) bits that are stored with the certificate.  The
installation
operation allowed, whether the certificate is self-signed (a common
case), or
is a certificate issued by some other entity.  The Netscape applications
do not
check extensions for these certificates, primarily for compatibility
with older
(V1-style) CA certificates.

If the user does install what appears to be an EE certificate as a CA,
Netscape
applications will allow that "EE" to issue certificates.  However these
certificates will only work as part of a certificate chain that ends
with this
"EE-CA".  The chain will never include the CA that issued the original
EE
certificate.  The policies that apply to the chain will be those
assigned by
the user to the "EE-CA" certificate when it was installed.  The same
effect
would have occurred if the "EE" had issued a self-signed certificate to
itself,
and the user had installed that instead.

Certificates at middle levels of a certification chain are required to
contain
an indication that it is a CA.  This can be done with the
basicConstraints
extension, or with private certificate type extensions which were
defined and
in-use to solve this problem before X.509 standard extensions were
available.

Terry Hayes
[e-mail]

Michael Sierchio wrote:

> Peter Gutmann wrote:
>
> > Both MSIE and Netscape treat self-signed certs without
basicConstraits as
> > CA's by default (in fact I don't know of any way to get them to
*not*
> > treat the cert owners as CA's).
>
> My impression is that, in the case of Netscape,  it's the MIME type
> that causes a cert to be treated as a CA:  application/x-x509-ca-cert,

> and not all of these are self-signed.





Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id NAA07686 for ietf-pkix-bks; Mon, 5 Apr 1999 13:08:29 -0700 (PDT)
Received: from popmail.inbox.se (popmail.inbox.se [193.12.72.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id NAA07682 for <[e-mail]>; Mon, 5 Apr 1999 13:08:27 -0700 (PDT)
Received: from stefan2 (accurata.inbox.se [193.12.72.24]) by popmail.inbox.se (8.8.7/8.8.7) with SMTP id WAA22299 for <[e-mail]>; Mon, 5 Apr 1999 22:09:00 +0200
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: Windows Eudora Pro Version 3.0 (32)
Date: Mon, 05 Apr 1999 22:09:41 +0200
To: [e-mail]
From: Stefan Santesson <[e-mail]>
Subject: EESSI - European Electronic Signature Standardization Initiative
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 mail.proper.com id NAA07683
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

For those interested in the progress in the field of electronic signature
standardization in Europe, EESSI (European Electronic Standardization
Initiative) have know opened their web site.

Further EESSI have just released meeting minutes from their first
Consultation meeting in Brussels, 24th February 1999.

On this meeting IETF activities was presented by Denis Pinkas, and the PKIX
Qualified Certificates work was presented by myself.

The Qualified Certificates web site URL: http://www.accurata.se/QC/ has
been updated with links to ESSI + meeting minutes. Look under "Related
Information" : "ESSI".

/Stefan   
-------------------------------------------------------------------
Stefan Santesson                <[e-mail]>
Accurata Systemsäkerhet AB      http://www.accurata.se
Slagthuset                      Tel. [phone]              
211 20  Malmö                   Fax. [phone]              
Sweden                        Mobile [phone]

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


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id MAA07448 for ietf-pkix-bks; Mon, 5 Apr 1999 12:44:26 -0700 (PDT)
Received: from gatekeeper.entrust.com (gatekeeper.entrust.com [204.101.128.170]) by mail.proper.com (8.8.8/8.8.5) with SMTP id MAA07444 for <[e-mail]>; Mon, 5 Apr 1999 12:44:22 -0700 (PDT)
Received: 	id PAA03094; Mon, 5 Apr 1999 15:41:32 -0400
Received: by gateway id <G4CAZMRC>; Mon, 5 Apr 1999 15:43:51 -0400
Message-ID: <01E1D01C12D7D211AFC70090273D20B112BD70@sothmxs06>
From: Robert Zuccherato <[e-mail]>
To: "'Denis Pinkas'" <[e-mail]>, Robert Zuccherato <[e-mail]>, "'Santoni Adriano'" <[e-mail]>
Cc: IETF-PXIX <[e-mail]>
Subject: RE: 3 Time Stamping issues
Date: Mon, 5 Apr 1999 15:37:59 -0400 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.1960.3)
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by mail.proper.com id MAA07445
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Adriano;

How about if I add the following text:

When issuing an error response with PKIFailureInfo having value
timeNotAvailable (14) then the TSA MAY place any random value in the tstTime
field of TSTInfo.  Upon receiving such an error response a client MUST not
trust the time contained in the tstTime field.    

This seems like reasonable behaviour.

	Robert.

> ----------
> From: 	Santoni Adriano[SMTP:[e-mail]]
> Sent: 	Friday, April 02, 1999 4:35 AM
> To: 	'Denis Pinkas'; 'Robert Zuccherato'
> Cc: 	IETF-PXIX
> Subject: 	R: 3 Time Stamping issues
> 
> I have a different doubt about the protocol:
> 
> the TSTInfo structure includes a status field with PKIStatusInfo syntax. I
> understand that the TSA could signal to the requestor (ie the client) the
> unavailability of a time source by using the valure 15 (tdaNotAvailable)
> for
> the failInfo field (with syntax PKIFailureInfo) of the TSTInfo status
> field.
> However, if the TSA has no reliable time source available, it should not
> issue a time value at all, right? Nontheless, the tstTime field of the
> TSTInfo structure is not OPTIONAL. So, it must carry some value, somehow.
> 
> The question, then, is: what time value should be put in the (mandatory)
> tstTime field when the TSA signals an error?
> 
> The same reasoning applies to other error condition which (should) prevent
> the TSA from issuing a time indication.
> 
> Adriano
> 
> > -----Messaggio originale-----
> > Da:	Denis Pinkas [SMTP:[e-mail]]
> > Inviato:	giovedì 1 aprile 1999 17.59
> > A:	IETF-PXIX
> > Oggetto:	3 Time Stamping issues
> > 
> > Since I am a co-editor of the Time Stamping document, I would like
> > to give my opinion on the various issues raised on the mailing list.
> > 
> > 1. There has been a suggestion to possibly improve the resolution to
> > microseconds from milliseconds.
> > 
> > Since the delay in the transmission is at least in the millisecond
> > order, having something more precise would give a false degree of
> > precision. I would not go under the millisesond.
> > 
> > 2. There has been a suggestion to possibly add a precision field.
> > 
> > I do not think this is absolutely necessary. So I am not supportive
> > of it since the policy can handle this.
> > 
> > 3. There has been a suggestion to possibly add a message information
> > field.
> > 
> > I have arguments *against* this idea. I would realy like to keep the
> > TSA as much ignorant as possible of the purpose of the Time
> > Stamping. If we add that information, the TSA could know "Invoice
> > from Alpha company to Delta company". Is
> > this way the TSA could learn that the Delta company is doing
> > commerce with the Delta company. This may that be a nice point to
> > spy. So I am against the inclusion of that aditional information.
> > 
> > However, ... I understand the concern of the linkeage and I would
> > propose an alternative:
> > 
> > Defining a Time Stamping Token (TST) that would be able to include
> > that information. Basically the TST would be the concatenation of
> > the "message information field" and of the signed portion of the
> > information received. The TST would be constructed locally instead
> > of being fully constructed by the TSA. We could define its structure
> > in a normative annex.
> > 
> > Regards,
> > 
> > Denis
> 


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id LAA03440 for ietf-pkix-bks; Mon, 5 Apr 1999 11:06:49 -0700 (PDT)
Received: from po1.bbn.com (PO1.BBN.COM [192.1.50.38]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id LAA03435 for <[e-mail]>; Mon, 5 Apr 1999 11:06:48 -0700 (PDT)
Received: from [128.89.0.110] (COSMEC.BBN.COM [128.89.0.110]) by po1.bbn.com (8.9.1/8.9.1) with ESMTP id OAA29364; Mon, 5 Apr 1999 14:06:57 -0400 (EDT)
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
X-Sender: [e-mail]
Message-Id: <v04020a0bb32ea83a186e@[128.89.0.110]>
In-Reply-To: <[e-mail]>
References: <v04020a10b32ad27828c8@[128.89.0.110]>
Date: Mon, 5 Apr 1999 14:00:37 -0400
To: Moshe Litvin <[e-mail]>
From: Stephen Kent <[e-mail]>
Subject: Re: Changes to RFC2459
Cc: [e-mail]
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Moshe,

>The problem is that the algorithm is actually:
>
>IF BasicConstraints PRESENT {
>       IF BasicConstraints.cA is TRUE
>                THEN certificate-is-ca
>                ELSE certificate-is-ee
>}
>ELSE {
>    IF issuing CA is fully PKIX compliant
>        THEN certificate-is-ee
>        ELSE undefind
>}
>
>We cannot eliminate the undefined decision(*) but we can create certificates
>that doesn't need that by encouraging CA to put a BasicConstraints that
>contains BasicConstraints.cA=FALSE (It is encoded as NULL but this is just
>encoding) rule).

The test I defined applies equally well for X.509 compliant CAs as well as
PKIX compliant CAs, as I stated.  Are you suggesting that we should change
PKIX to somewhow better accommodate CAs that don't comply with it?

We can look at this from two perspectives:

	- first, we're in chanrge of PKIX standards, so of course we're
most interested in the situation where the CA is PKIX compliant.  if you
assume otherwise, then there can be many ways in which processing will be
adversely affected.
	- second, since X.509 does not require the presence of this
extension, but merely recommends its use for EE certs, your modification of
my simple test also is deficient. why not include clauses for X.509
compliant CAs who do not elect to include the extension?

If one changed both PKIX and X.509 to mandate inclusion of this extension
for both EE and CA certs, AND if all CAs were compliant with either
standard, then life would, indeed, be easier.  But, if you use as an
example, the ambiguity that may arise from CAs that comply with neither
standard, why bother?

Steve


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id KAA02609 for ietf-pkix-bks; Mon, 5 Apr 1999 10:48:38 -0700 (PDT)
Received: from po1.bbn.com (PO1.BBN.COM [192.1.50.38]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id KAA02605 for <[e-mail]>; Mon, 5 Apr 1999 10:48:37 -0700 (PDT)
Received: from [128.89.0.110] (COSMEC.BBN.COM [128.89.0.110]) by po1.bbn.com (8.9.1/8.9.1) with ESMTP id NAA22205; Mon, 5 Apr 1999 13:48:58 -0400 (EDT)
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
X-Sender: [e-mail]
Message-Id: <v04020a09b32ea76ce803@[128.89.0.110]>
In-Reply-To: <D1A949D4508DD1119C8100400533BEDC0D7409@DSG1>
Date: Mon, 5 Apr 1999 13:49:03 -0400
To: Alan Lloyd <[e-mail]>
From: Stephen Kent <[e-mail]>
Subject: RE: Certificates, Directories, and Distinguished Names
Cc: "''[e-mail] ' '" <[e-mail]>, "''[e-mail] ' '" <[e-mail]>
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Alan,

>My question was really aimed at the cert extensions subject - issuer alt
>names.. I still dont understand what and why these are in the cert - if
>its baggage for some obscure reason - then thats OK - but if its for
>validation process issues - then they have to be spelled out. And if
>they are just baggage, instead of making them  "alt name forms"- why not
>call then subject and issuer additional info or in fact just make them
>cert ext directory attributes?
>
>We seem to have in these extensions, a lot of form without content.

Alt names allow a PKI to use name forms most closely aligned to the
application context with which the certs will be used. That, by itself, is
sufficient reason to provide them.  Look at the messes created by shoe
horning DNS names into DNs in SSL certs, or e-mail addresses into DNs in
S/MIME.  We can't go back and change the Subject and Issuer to be
GeneralNames due to backward compatability constraints, so ...

Steve


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id KAA02531 for ietf-pkix-bks; Mon, 5 Apr 1999 10:46:39 -0700 (PDT)
Received: from po1.bbn.com (PO1.BBN.COM [192.1.50.38]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id KAA02526 for <[e-mail]>; Mon, 5 Apr 1999 10:46:38 -0700 (PDT)
Received: from [128.89.0.110] (COSMEC.BBN.COM [128.89.0.110]) by po1.bbn.com (8.9.1/8.9.1) with ESMTP id NAA20475; Mon, 5 Apr 1999 13:47:03 -0400 (EDT)
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
X-Sender: [e-mail]
Message-Id: <v04020a08b32ea3aa05e0@[128.89.0.110]>
In-Reply-To: <[e-mail]>
References: <02a201be7cb2$dda47c80$c74bffd0@brick>	 <[e-mail]>		<v04020a08b32aa018521c@[128.89.0.110]>	 <[e-mail]>	 <v04020a12b32ad6da3056@[128.89.0.110]> <[e-mail]>
Date: Mon, 5 Apr 1999 13:45:47 -0400
To: Michael McNeil <[e-mail]>
From: Stephen Kent <[e-mail]>
Subject: Re: Time-stamp server. TimePrecision info
Cc: Paul Koning <[e-mail]>, [e-mail], [e-mail]
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Michael,

<snip>

>To answer your request for an example, Steve, I envision the widespread
>timestamping of system and network events, which may need to be audited
>in a post mortem following, say, a virus attack across many machines.
>If timestamps support a fine grained time resolution, then even events
>which propagate within and between systems at computer speeds might be
>identified and placed in their proper chronological sequence.

This identifies a need for distributed, perhaps secure, time servers, but
not necessarily time stamp servers.

<snip>

>>If you make assumptions that may be warranted in *some* cases, such as
>>roughly equal packet transit times each way, you can tighten this up
>>some.
>
>A number of probes of the time server will allow refinement of the
>average round-trip latency -- refining, once again, the estimated
>_precision_ of the time.  The timestamping server should then (I argue)
>use this in stating the overall precision of the time in its timestamps.
>The precision in timestamps must be kept in mind when comparing times
>from two different (or even two timestamps from the same) time server.

The time stamp server may serve a variety of folks, and the delays may well
differ for each of them.  Also, I'm confused by the suggestion that the
server  use feedback from the clients to provide more accurate estimates
for the delays. The clients are not trusted to provide such info.

With regard to the issue of providing syntax to represenet increased
precision vs. our need for it at this time, I reiterate the comments made
earlier, and in a recent message to Todd.  I agree that it is tempting to
provide room for additional precision, but I worry that the syntax may be
abused in two ways:

	- leading users to believe there is more significance than the
application context warrants
	- allowing some vendors to trumpet their ability to offer increased
precision as an important differentiator, when the system context makes
such differences moot.


Steve


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id KAA02420 for ietf-pkix-bks; Mon, 5 Apr 1999 10:44:34 -0700 (PDT)
Received: from relay7.UU.NET (relay7.UU.NET [192.48.96.17]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id KAA02416 for <[e-mail]>; Mon, 5 Apr 1999 10:44:33 -0700 (PDT)
Received: from xedia.com by relay7.UU.NET with SMTP  (peer crosschecked as: madway.xedia.com [198.202.232.199]) id QQgjqs29983; Mon, 5 Apr 1999 13:43:58 -0400 (EDT)
Received: from tonga.xedia.com by xedia.com (4.1/SMI-4.1) id AA12088; Mon, 5 Apr 99 13:43:55 EDT
Received: by tonga.xedia.com (SMI-8.6/SMI-SVR4) id NAA04385; Mon, 5 Apr 1999 13:43:56 -0400
Date: Mon, 5 Apr 1999 13:43:56 -0400
Message-Id: <[e-mail]>
From: Paul Koning <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
To: [e-mail]
Cc: [e-mail], [e-mail]
Subject: Re: Time-stamp server. TimePrecision info
X-Mailer: VM 6.34 under 20.3 "Vatican City" XEmacs  Lucid
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

>>>>> "Stephen" == Stephen Kent <[e-mail]> writes:

 Stephen> Paul,
 >> You can also apply the same sort of example to real time systems.
 >> Consider a distributed real time control system.  Suppose
 >> something goes wrong, and after the fires are put out and the bits
 >> of concrete have been bulldozed away, people start picking through
 >> the logs trying to figure out what sequence of events made things
 >> blow up.  You need fine grain timestamps so you can unambiguously
 >> follow the directed graph of cause and event.  For real time
 >> systems, sub-millisecond timestamps are perfectly meaningful.

 Stephen> That's more of what I had in mind when I asked for a
 Stephen> concrete example.  However, in a realtime system, it is not
 Stephen> clear that the audit trails need or could tolerate the
 Stephen> overhead of signing every log entry.  They might need
 Stephen> accurate local clocks for the logs, but do they need time
 Stephen> stamps from network accessible servers?

Quite possibly yes, since such analysis may end up being done in
court.  Whether the overhead is acceptable depends on how much is
riding on it, and how big the overhead actually is.  I'm suggesting
that with modern hardware it's not that high and dropping fast.

	paul


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id KAA02132 for ietf-pkix-bks; Mon, 5 Apr 1999 10:38:04 -0700 (PDT)
Received: from po1.bbn.com (PO1.BBN.COM [192.1.50.38]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id KAA02127 for <[e-mail]>; Mon, 5 Apr 1999 10:38:01 -0700 (PDT)
Received: from [128.89.0.110] (COSMEC.BBN.COM [128.89.0.110]) by po1.bbn.com (8.9.1/8.9.1) with ESMTP id NAA15731; Mon, 5 Apr 1999 13:37:24 -0400 (EDT)
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
X-Sender: [e-mail]
Message-Id: <v04020a07b32ea2e7d7db@[128.89.0.110]>
In-Reply-To: <[e-mail]>
References: <02a201be7cb2$dda47c80$c74bffd0@brick> <[e-mail]>	<v04020a08b32aa018521c@[128.89.0.110]> <[e-mail]> <v04020a12b32ad6da3056@[128.89.0.110]> <[e-mail]>	<[e-mail]>
Date: Mon, 5 Apr 1999 13:29:58 -0400
To: Paul Koning <[e-mail]>
From: Stephen Kent <[e-mail]>
Subject: Re: Time-stamp server. TimePrecision info
Cc: [e-mail], [e-mail], [e-mail]
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Paul,

>You can also apply the same sort of example to real time systems.
>Consider a distributed real time control system.  Suppose something
>goes wrong, and after the fires are put out and the bits of concrete
>have been bulldozed away, people start picking through the logs trying
>to figure out what sequence of events made things blow up.  You need
>fine grain timestamps so you can unambiguously follow the directed
>graph of cause and event.  For real time systems, sub-millisecond
>timestamps are perfectly meaningful.

That's more of what I had in mind when I asked for a concrete example.
However, in a realtime system, it is not clear that the audit trails need
or could tolerate the overhead of signing every log entry.  They might need
accurate local clocks for the logs, but do they need time stamps from
network accessible servers?


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id KAA01682 for ietf-pkix-bks; Mon, 5 Apr 1999 10:27:59 -0700 (PDT)
Received: from po1.bbn.com (PO1.BBN.COM [192.1.50.38]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id KAA01677 for <[e-mail]>; Mon, 5 Apr 1999 10:27:58 -0700 (PDT)
Received: from [128.89.0.110] (COSMEC.BBN.COM [128.89.0.110]) by po1.bbn.com (8.9.1/8.9.1) with ESMTP id NAA11311; Mon, 5 Apr 1999 13:27:37 -0400 (EDT)
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
X-Sender: [e-mail]
Message-Id: <v04020a05b32e945b6c88@[128.89.0.110]>
In-Reply-To: <[e-mail]>
Date: Mon, 5 Apr 1999 13:26:03 -0400
To: [e-mail]
From: Stephen Kent <[e-mail]>
Subject: Re: Changes to RFC2459
Cc: [e-mail]
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Peter,

>Both MSIE and Netscape treat self-signed certs without basicConstraits as
>CA's by default (in fact I don't know of any way to get them to *not*
>treat the cert owners as CA's).
>
>MSIE: "You have been offered a new site certificate to place in your list
>       of trusted issuers..."
>Netscape: "You are about to go through the process of accepting a
>           certificate authority..."
>
>Leaving out the basicConstraints makes the assumption that relying parties
>are using PKIX-compliant software, and that the software will DTRT when it
>finds one of these certs.  I think this is leaving what could be a critical
>security issue more or less to chance - all I need to do is find some
>software which happens to not follow PKIX's implied behaviour and I can go
>ahead and issue my own certs and let the entire world in the door.

I thought the debate we are having was focused on the differences between
compliance with X.509 and PKIX.  Since neither standard REQUIRES inclusion
of basic constraints for an EE, conformance to either standard does not
completely solve the problem of the browser vendors having made the
decision you cited, right?

Is the concern that an EE might provide a self-signed cert to one of these
browsers and have it interpreted as a CA vs. an EE cert?   Obviously, since
it is self-signed, an EE could elect to include a basic constraints
extension with a CA flag if the intent is to deceive the browser user.  So,
is the argument, that PKIX should require an EE cert to have a NULL basic
constraints extension so that an EE can be declared compliant with PKIX and
still not cause these browsers to misinterpret a self-signed cert under
these circumstances?

If that's the argument, then we need to consider such a change based on at
least these issues:
	- under what circumstances would an EE use a self-signed cert? note
	 that PKIX always describes self-signed certs in the context of CAs,
	  not of EEs.  X.509 makes NO mention of self-signed certs
	- should PKIX change to accommodate current browser conventions that
	are still ambiguous with regard to strict adherence to X.509?

Steve


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id JAA28333 for ietf-pkix-bks; Mon, 5 Apr 1999 09:16:56 -0700 (PDT)
Received: from po1.bbn.com (PO1.BBN.COM [192.1.50.38]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id JAA28328 for <[e-mail]>; Mon, 5 Apr 1999 09:16:55 -0700 (PDT)
Received: from [128.89.0.110] (COSMEC.BBN.COM [128.89.0.110]) by po1.bbn.com (8.9.1/8.9.1) with ESMTP id MAA11740; Mon, 5 Apr 1999 12:17:24 -0400 (EDT)
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
X-Sender: [e-mail]
Message-Id: <v04020a04b32e924bbe30@[128.89.0.110]>
In-Reply-To: <00d301be7d8e$68bff070$fa4bffd0@brick>
Date: Mon, 5 Apr 1999 11:18:30 -0500
To: "Todd S. Glassey" <[e-mail]>
From: Stephen Kent <[e-mail]>
Subject: Re: Time-stamp server. TimePrecision info
Cc: <[e-mail]>
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Todd,

>Steven, A policy Anchor is exactly what it sounds like. A mechanism used to
>anchor a point in the operational policy of some system making it
>referencable.

In PKIX we have certification policies and those are the policies that
first come to mind when we engage in discussions in this standards arena.
Your definition still does not allow me to relate your comment to the
general PKIX activities.  For CA policies, there is an element of time,
since we make use of time to determine validity intervals for certs,
timeliness for CRLs, etc.  But none of these functions require time with
the sort of precision that you were describing as critical.

Please try again,

Steve


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id JAA28325 for ietf-pkix-bks; Mon, 5 Apr 1999 09:16:54 -0700 (PDT)
Received: from po1.bbn.com (PO1.BBN.COM [192.1.50.38]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id JAA28321 for <[e-mail]>; Mon, 5 Apr 1999 09:16:53 -0700 (PDT)
Received: from [128.89.0.110] (COSMEC.BBN.COM [128.89.0.110]) by po1.bbn.com (8.9.1/8.9.1) with ESMTP id MAA11729; Mon, 5 Apr 1999 12:17:22 -0400 (EDT)
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
X-Sender: [e-mail]
Message-Id: <v04020a03b32e90c762ef@[128.89.0.110]>
In-Reply-To: <00b301be7d89$f763b190$fa4bffd0@brick>
Date: Mon, 5 Apr 1999 11:15:58 -0500
To: "Todd S. Glassey" <[e-mail]>
From: Stephen Kent <[e-mail]>
Subject: Re: Time-stamp server. TimePrecision info
Cc: <[e-mail]>
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Todd,

>off the top of my head here are four
>
>#1)    Telcom Backbone management systems, tightly coupled cluster systems
>maker up what are now virtual switches.

I work for a large telecom company, but I'll have to ask for more details
here, as this doesn't yet make sense to me.

>#2)    Event Simulation and Decision Support Management

Distributed simulation systems don't seem to need this, based on the work
I've seen re DoD simulators.

>#3)    Precision control of mechancial processes, like operating a high head
>water cam on a power plant or the like, or operating a vacume control
>sputtering system for semiconductor processing.

I see why these folks need precise time, but not time stamping.

>#4)    Market Trading and Control of trading processes. - Many systems are
>now tightly coupled fault tolerant clusters and these systems need this
>"ridiculous" level of precision in their timestamping since they are not
>connected in the same way we usually connect together (lan/wan/man etc).

Definately not true.

Perhaps I was not specific enough in my request.  I'd like to see examples
where someone actually explains the need, not just cites a topic.  And, as
Roberto points out, we're PKIX and so our initial focus was motivated by
the time scale that we use in certs and crls.  We might refine this to
support greater precision, but I am not inclined to do so based on what I
have heard so far.

What I dl NOT want to see is the creation of a standard with provision for
very precise time stamps that some vendor uses to tout the superiority of
his product vs. another due to increased precision, irrespective of the
significance of the extra digits or the relevance to the applciation
context.

Steve


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id HAA23254 for ietf-pkix-bks; Mon, 5 Apr 1999 07:18:11 -0700 (PDT)
Received: from relay5.UU.NET (relay5.UU.NET [192.48.96.15]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id HAA23249 for <[e-mail]>; Mon, 5 Apr 1999 07:18:10 -0700 (PDT)
Received: from xedia.com by relay5.UU.NET with SMTP  (peer crosschecked as: madway.xedia.com [198.202.232.199]) id QQgjqf09115; Mon, 5 Apr 1999 10:17:30 -0400 (EDT)
Received: from tonga.xedia.com by xedia.com (4.1/SMI-4.1) id AA08371; Mon, 5 Apr 99 10:17:24 EDT
Received: by tonga.xedia.com (SMI-8.6/SMI-SVR4) id KAA04240; Mon, 5 Apr 1999 10:17:25 -0400
Date: Mon, 5 Apr 1999 10:17:25 -0400
Message-Id: <[e-mail]>
From: Paul Koning <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
To: [e-mail]
Cc: [e-mail], [e-mail]
Subject: Re: Time-stamp server. TimePrecision info
References: <02a201be7cb2$dda47c80$c74bffd0@brick> <[e-mail]> <v04020a08b32aa018521c@[128.89.0.110]> <[e-mail]> <v04020a12b32ad6da3056@[128.89.0.110]> <[e-mail]> <[e-mail]>
X-Mailer: VM 6.34 under 20.3 "Vatican City" XEmacs  Lucid
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

>>>>> "Michael" == Michael McNeil <[e-mail]> writes:

 Michael> To answer your request for an example, Steve, I envision the
 Michael> widespread timestamping of system and network events, which
 Michael> may need to be audited in a post mortem following, say, a
 Michael> virus attack across many machines.  If timestamps support a
 Michael> fine grained time resolution, then even events which
 Michael> propagate within and between systems at computer speeds
 Michael> might be identified and placed in their proper chronological
 Michael> sequence.

That's a nice example.

It sounds like it describes a collection of general purpose systems.
That somewhat limits the meaningful precision of the timestamps
because of the sloppy schedulers used in such systems.

You can also apply the same sort of example to real time systems.
Consider a distributed real time control system.  Suppose something
goes wrong, and after the fires are put out and the bits of concrete
have been bulldozed away, people start picking through the logs trying 
to figure out what sequence of events made things blow up.  You need
fine grain timestamps so you can unambiguously follow the directed
graph of cause and event.  For real time systems, sub-millisecond
timestamps are perfectly meaningful.

	paul


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id WAA17121 for ietf-pkix-bks; Sun, 4 Apr 1999 22:47:22 -0700 (PDT)
Received: from natasha1. (natasha-gw.checkpoint.com [199.203.73.129]) by mail.proper.com (8.8.8/8.8.5) with SMTP id WAA17117 for <[e-mail]>; Sun, 4 Apr 1999 22:47:19 -0700 (PDT)
Received: from cale.checkpoint.com (gray.checkpoint.com [199.203.71.94]) by cale.checkpoint.com (8.9.1/8.9.1) with ESMTP id HAA14153; Mon, 5 Apr 1999 07:49:43 +0200 (IST)
Message-ID: <[e-mail]>
Date: Mon, 05 Apr 1999 07:46:42 +0200
From: Moshe Litvin <[e-mail]>
X-Mailer: Mozilla 4.51 [en] (WinNT; I)
X-Accept-Language: en
MIME-Version: 1.0
To: [e-mail]
CC: [e-mail], [e-mail]
Subject: Re: Changes to RFC2459
References: <[e-mail]>
Content-Type: multipart/mixed; boundary="------------C000C69FA7FD056D0D29893A"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

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


Peter Gutmann wrote:

-- Snip --

> Leading to the following entry in the X.509 style guide:
>
> -- Snip --
>
> PKIX
>
>   PKIX requires that end entity certificates not have a basicConstraints
>   extension, which leaves the handling of the CA status of the certificate to
>   chance.  Several popular applications treat these certificates as CA
>   certificates for backwards-compatibility with X.509v1 CA certificates which
>   didn't include basicConstraints, but in practice it's not really possible to
>   determine how these certificates will be treated.  Because of this, it's not
>   possible to issue a PKIX-compliant end entity certificate and know how it'll
>   be treated once it's in circulation.
>

-- Snip --

Since PKIX allows end entity certificates with basicConstraints - it is only SHOULD
NOT and not MUST NOT - it is possible to do it.

Moshe


--------------C000C69FA7FD056D0D29893A
Content-Type: text/x-vcard; charset=us-ascii;
 name="moshe.vcf"
Content-Transfer-Encoding: 7bit
Content-Description: Card for Moshe Litvin
Content-Disposition: attachment;
 filename="moshe.vcf"

begin:vcard 
n:Litvin;Moshe
tel;fax:[phone]
tel;work:[phone]
x-mozilla-html:TRUE
org:Check Point Software Technologies Ltd.
adr:;;;;;;
version:2.1
email;internet:[e-mail]
fn:Moshe Litvin
end:vcard

--------------C000C69FA7FD056D0D29893A--



Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id WAA17010 for ietf-pkix-bks; Sun, 4 Apr 1999 22:40:41 -0700 (PDT)
Received: from natasha1. (natasha-gw.checkpoint.com [199.203.73.129]) by mail.proper.com (8.8.8/8.8.5) with SMTP id WAA17006 for <[e-mail]>; Sun, 4 Apr 1999 22:40:38 -0700 (PDT)
Received: from cale.checkpoint.com (gray.checkpoint.com [199.203.71.94]) by cale.checkpoint.com (8.9.1/8.9.1) with ESMTP id HAA13887; Mon, 5 Apr 1999 07:43:01 +0200 (IST)
Message-ID: <[e-mail]>
Date: Mon, 05 Apr 1999 07:39:58 +0200
From: Moshe Litvin <[e-mail]>
X-Mailer: Mozilla 4.51 [en] (WinNT; I)
X-Accept-Language: en
MIME-Version: 1.0
To: Stephen Kent <[e-mail]>
CC: [e-mail]
Subject: Re: Changes to RFC2459
References: <v04020a10b32ad27828c8@[128.89.0.110]>
Content-Type: multipart/mixed; boundary="------------361EB29BAA07A0846431C5A2"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

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

Steve,

The problem is that the algorithm is actually:

IF BasicConstraints PRESENT {
       IF BasicConstraints.cA is TRUE
                THEN certificate-is-ca
                ELSE certificate-is-ee
}
ELSE {
    IF issuing CA is fully PKIX compliant
        THEN certificate-is-ee
        ELSE undefind
}

We cannot eliminate the undefined decision(*) but we can create certificates
that doesn't need that by encouraging CA to put a BasicConstraints that
contains BasicConstraints.cA=FALSE (It is encoded as NULL but this is just
encoding) rule).

Moshe

(*) We can complicate the algorithm so it will use keyUsage and reduce the
number of undefined answers but not eiliminate them.

Stephen Kent wrote:

> Jim & Moshe,
>
> I admit to being confused at this point.  My reading of PKIX and X.509
> suggests the folowing simple test, (coded in Kent++):
>
> - IF BasicConstraints PRESENT AND
>         IF BasicConstraints.cA PRESENT
>                 THEN certificate-is-ca
>                 ELSE certificate-is-ee
>         ELSE certificate-is-ee
>
> This is consistent with PKIX, which calls for the extension to be present
> and non-NULL for a CA cert, but recommends that it be absent for an EE
> cert.  It is consistent with X.509, which requires the extension to always
> be present and non-null for a CA, but suggests that it be present and NULL
> for an EE.  X.509 also suggests that if the extension is not present, then
> a system may choose to employ other means to determine if it is an EE or a
> CA cert.  But, in that case, you're back to looking at other fields ...
>
> What's the problem?
>
> Steve

--------------361EB29BAA07A0846431C5A2
Content-Type: text/x-vcard; charset=us-ascii;
 name="moshe.vcf"
Content-Transfer-Encoding: 7bit
Content-Description: Card for Moshe Litvin
Content-Disposition: attachment;
 filename="moshe.vcf"

begin:vcard 
n:Litvin;Moshe
tel;fax:[phone]
tel;work:[phone]
x-mozilla-html:TRUE
org:Check Point Software Technologies Ltd.
adr:;;;;;;
version:2.1
email;internet:[e-mail]
fn:Moshe Litvin
end:vcard

--------------361EB29BAA07A0846431C5A2--



Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id SAA02884 for ietf-pkix-bks; Sun, 4 Apr 1999 18:14:13 -0700 (PDT)
Received: from unknown (1Cust62.tnt1.atl2.da.uu.net [153.36.12.62]) by mail.proper.com (8.8.8/8.8.5) with SMTP id SAA02880 for <[e-mail]>; Sun, 4 Apr 1999 18:14:11 -0700 (PDT)
From: [e-mail]
Message-Id: <[e-mail]>
To: <[e-mail]>
Subject: toner sales advertising
Date: Mon, 5 Apr 1999 05:51:18
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

BENCHMARK PRINT SUPPLY
LASER PRINTER CARTRIDGES JUST FOR YOU AS 
 WELL AS FAX AND COPIER TONER 
 
   CHECK OUT THESE NEW PRINT CARTRIDGE PRICES :
 

APPLE 
 
  LASER WRITER  PRO 600 OR 16/600         $69
  LASER WRITER SELECT 300,310.360         $64
  LASER WRITER 300, 320, 360              $54 
  LASER WRITER LS,NT,2NTX,2F,2G & 2SC     $54 
  LASER WRITER 12/640                     $79 

HEWLETT PACKARD 

  LASERJET  SERIES 2,3 & 3D               $49 
  LASERJET  SERIES  2P AND 3P             $54 
  LASERJET SERIES 3SI AND 4SI             $75 
  LASERJET  SERIES 4L AND 4P              $49 
  LASERJET SERIES 4, 4M, 5, 5M            $59 
  LASERJET SERIES 4000 HIGH YIELD         $99 
  LASERJET SERIES 4V                      $95 
  LASERJET SERIES 5SI , 8000              $95 
  LASERJET SERIES 5L AND 6L               $49 
  LASERJET SERIES 5P, 5MP, 6P, 6MP        $59 
  LASERJET SERIES 5000                    $89 

HP LASERFAX 

  LASERFAX 500, 700, FX1,                 $59 
  LASERFAX 5000, 7000, FX2,               $59 
  LASERFAX  FX3                           $69 
  LASERFAX  FX4                           $79 
 

LEXMARK 

  OPTRA  4019, 4029  HIGH YIELD          $135 
  OPTRA R, 4039, 4049 HIGH YIELD         $135 
  OPTRA S 4059 HIGH YIELD                $135 
  OPTRA E                                 $59 
  OPTRA  N                               $115 
 

EPSON 

  EPL-70000, 8000                        $105 
  EPL-1000, 1500                         $105 
 

CANON 

  LBP-430                                 $49 
  LBP-460, 465                            $59 
  LBP-8 II                                $54 
  LBP-LX                                  $54 
  LBP-MX                                  $95 
  LBP-AX                                  $49 
  LBP-EX                                  $59 
  LBP-SX                                  $49 
  LBP-BX                                  $95 
  LBP-PX                                  $49 
  LBP-WX                                  $95 
  LBP-VX                                  $59 
  CANON FAX L700 THRU L790 FX1            $59 
  CANONFAX L5000 L70000  FX2              $59 
 

CANON COPIERS 

  PC 20, 25 ETC....                       $89 
  PC 3, 6RE, 7, 11  (A30)                 $69 
  PC 320 THRU 700  (E40)                  $89 
 

NEC 

  SERIES 2 LASER MODEL 95                $105 
 
 
 
 


PLACE YOUR ORDER BY :

   PHONE   [phone] 
   FAX:    [phone] 
   E-MAIL: [e-mail] WITH SUBJECTLINE: ORDER 
   MAIL:   1091 REDSTONE LANE, ATLANTA GA 30338 

MAKE SURE YOU INCLUDE THE FOLLOWING INFORMATION IN YOUR ORDER: 

             1)  PHONE NUMBER 
             2)  COMPANY NAME 
             3)  SHIPPING ADDRESS 
             4)  YOUR NAME 
             5)  ITEMS NEEDED WITH QUANTITIES 
             6)  METHOD OF PAYMENT. (COD OR CREDIT CARD) 
             7)  CREDIT CARD NUMBER WITH EXPIRATION DATE 
 
WE SHIP UPS GROUND STANDARD. ADD $4.5 FOR SHIPPING AND HANDLING. 
FOR ORDER QUESTIONS CALL 770-399-0953 
FOR CUSTOMER SERVICE  770-399-5505 


FOR E-MAIL REMOVAL USE:
    
         [e-mail]
         OR CALL 770-399-5614




NOTE: OWNERS OF E-MAIL DOMAINS USED IN THIS MESSAGE, WETHER IN 
THE HEADER OR THE BODY OF THIS MESSAGE, ARE IN NO WAY  ASSOCIATED 
WITH, PROMOTING, DISTRIBUTING OR ENDORSING ANY OF THE PRODUCTS 
ADVERTISED HEREIN AND ARE NOT LIABLE TO ANY CLAIMS THAT MAY ARISE 
THEREOF.

 
 
 
 
 
 
 


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id QAA02240 for ietf-pkix-bks; Sun, 4 Apr 1999 16:04:08 -0700 (PDT)
Received: from dsg1.OpenDirectory.com.au ([203.108.249.145]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id QAA02236 for <[e-mail]>; Sun, 4 Apr 1999 16:03:46 -0700 (PDT)
Received: by DSG1 with Internet Mail Service (5.0.1458.49) id <22ZNQL22>; Mon, 5 Apr 1999 09:03:57 +1000
Message-ID: <D1A949D4508DD1119C8100400533BEDC0D7409@DSG1>
From: Alan Lloyd <[e-mail]>
To: "'Stephen Kent '" <[e-mail]>
Cc: "''Bob Jueneman ' '" <[e-mail]>, "''[e-mail] ' '" <[e-mail]>, "''[e-mail] ' '" <[e-mail]>, "''[e-mail] ' '" <[e-mail]>
Subject: RE: Certificates, Directories, and Distinguished Names
Date: Mon, 5 Apr 1999 09:03:56 +1000
X-Priority: 3
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.0.1458.49)
Content-Type: text/plain
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

  Thanks for that steve. I understand DNS names - I have a few :-)

Its just that using this form of address (DNS) - just makes the PKI / CA
concerned very limited (operationally) and bespoke. ie. one cannot ring
the subject up in the event of errors - nor can one tie business rules
or other info to them (as one can do with a directory service based
system), one also must  supply the EE cert with the transaction as one
could scan the whole directory searching for dns type attrs.. small
issues..

My question was really aimed at the cert extensions subject - issuer alt
names.. I still dont understand what and why these are in the cert - if
its baggage for some obscure reason - then thats OK - but if its for
validation process issues - then they have to be spelled out. And if
they are just baggage, instead of making them  "alt name forms"- why not
call then subject and issuer additional info or in fact just make them
cert ext directory attributes?

We seem to have in these extensions, a lot of form without content.

regards alan

----------
From: Stephen Kent
To: Alan Lloyd
Cc: 'Bob Jueneman '; '[e-mail] '; '[e-mail] ';
'[e-mail] '
Sent: 3/30/99 6:24:18 AM
Subject: RE: Certificates, Directories, and Distinguished Names

Alan,


>I am not to sure what going to a DNS based name does does in terms of
>process - eg. validation process or things that use certificates - can
>someone please enlighten me.

DNS names are often native to the applications, e.g., IPsec, SSL/TLS,
and
S/MIME, and thus it is preferable to make use of them as a more direct
input to an access control decision.  For example, browsers using SSL
usually match the URL against a DNS name crudely encoded as a common
name.
It would be preferable (as 2459 points out) if the encoding were direct,
rather than kludged in this fashion.  Also, there are standards for
storing
certs in the DNS, which might allow one to take advantage of a very
large,
deployed repository infrastructure in the Internet.

>ie. if there are problems with Issuer DN (ie its an SMTP address in the
>extensions) and I am in the process of path validation - do I mail the
>Issuer with something?

That's not the motivation for use of DNS names here.

>What about CRLs - are they attached to these DNS indexed things.

Yes, there are provisions for storing CRLs, as well as certs, in DNS.

>I understand that AIAs are useful as they deal with explicit a cert
>based function such as OCSP.
>I just dont understand the process (that must be related to the
>certficate) if DNS type names are used for issuers, etc.

If a DNS name is used exclusively, we restrict it to the subject field
for
an end entity certificate.  Otherwise a DN must be present in the Issuer
and/or Subject fields.

>In addition - if one mixed name forms in a cert path - the process
rules
>can get messy. eg mail here, ldap there, OCSP over there, etc

As noted above, the simple case is to use DNS names only for end
entities.

Steve



Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id KAA26241 for ietf-pkix-bks; Sat, 3 Apr 1999 10:13:36 -0800 (PST)
Received: from always.got.net ([e-mail] [207.111.232.11]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id KAA26237 for <[e-mail]>; Sat, 3 Apr 1999 10:13:35 -0800 (PST)
Received: from got.net (SC-219.got.net [209.66.101.219]) by always.got.net (8.8.8/8.8.7/Debian/GNU) with ESMTP id KAA09410; Sat, 3 Apr 1999 10:13:52 -0800
Message-ID: <[e-mail]>
Date: Sat, 03 Apr 1999 10:13:35 -0800
From: Michael McNeil <[e-mail]>
Organization: GMT
X-Mailer: Mozilla 4.51 [en] (WinNT; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Paul Koning <[e-mail]>
CC: [e-mail], [e-mail]
Subject: Re: Time-stamp server. TimePrecision info
References: <[e-mail]> <[e-mail]> <[e-mail]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

My comments below.

>>Michael> == Michael McNeil <[e-mail]> writes:
>>Michael> A desirable solution ought to both maintain strict
>>Michael> monotonicity over leap seconds (without complicated
>>Michael> manipulations if possible) as well as not hinder comparisons
>>Michael> down to the fractional seconds, should that be desired.

Paul Koning wrote:
>Agreed.  But if by comparison you mean the operators <, =, and >, then
>what I described (which is what's in the current draft, once you make
>it clear that the ss field has 60 as a legal value) works.

I quite agree that for simple greater than comparisons, this method
works.  However, determining earlier-later than relationships are not
(only) what I'm talking about.  I believe it's desirable to be able to
compare timestamps for the exact time difference (in seconds + fraction)
between them, without convoluted computations and reference to tables.
The method I described (storing away leap seconds) accomplishes this.

Clearly, pegging specific timestamp times to the particular day, hour,
etc., that they took place in requires conversion to calendric formats.
The question is, which source format the time should be stored away in
in the timestamp.  I suggest a pure seconds count makes sense for this. 
Utility programs will be on hand to do what conversions are necessary.

>A strcmp operation on time strings in GeneralizedTime format yields
>the correct answer for all cases including leap seconds.  It's pretty
>clear why that is so: the characters in that string are in descending
>order of significance reading left to right...

Agreed.

>As I mentioned elsewhere, whether conversion to this format requires
>you to know about leap seconds depends on what you start from.  If you
>start from NTP format then I believe it does not.  In any case, that's
>an internal matter.

When comparing two NTP times (which are purely UTC and ignore leap
seconds), one first has ambiguity if the indicated UTC time happens to
be left adjacent to a leap second.  Second, one must refer to external
tables of historic leap seconds to correctly place a leap second (or
more) between two indicated dates.  If the count of leap seconds is
stored away in the timestamp along with the UTC time for that moment,
computing the difference between any two timestamp times becomes quite
simple, and any ambiguity in the vicinity of leap seconds is eliminated.

>paul

--
Michael McNeil
[e-mail]


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id JAA25985 for ietf-pkix-bks; Sat, 3 Apr 1999 09:30:34 -0800 (PST)
Received: from lux.tenebras.com (dnai-207-181-255-76.dialup.dnai.com [207.181.255.76]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id JAA25981 for <[e-mail]>; Sat, 3 Apr 1999 09:30:32 -0800 (PST)
Received: from dnai.com (windoze [192.168.100.122]) by lux.tenebras.com (8.8.8/8.8.8) with ESMTP id JAA08514; Sat, 3 Apr 1999 09:30:18 -0800 (PST) (envelope-from [e-mail])
Message-ID: <[e-mail]>
Date: Sat, 03 Apr 1999 09:30:01 -0800
From: Michael Sierchio <[e-mail]>
Reply-To: [e-mail]
Organization: Oversized Metaphysics
X-Mailer: Mozilla 4.51 [en] (Win95; U)
X-Accept-Language: en
MIME-Version: 1.0
To: [e-mail]
CC: [e-mail], [e-mail]
Subject: Re: Changes to RFC2459
References: <[e-mail]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Peter Gutmann wrote:

> Both MSIE and Netscape treat self-signed certs without basicConstraits as
> CA's by default (in fact I don't know of any way to get them to *not*
> treat the cert owners as CA's).

My impression is that, in the case of Netscape,  it's the MIME type
that causes a cert to be treated as a CA:  application/x-x509-ca-cert,
and not all of these are self-signed.


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id HAA25391 for ietf-pkix-bks; Sat, 3 Apr 1999 07:52:19 -0800 (PST)
Received: from always.got.net ([e-mail] [207.111.232.11]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id HAA25387 for <[e-mail]>; Sat, 3 Apr 1999 07:52:18 -0800 (PST)
Received: from got.net (SC-219.got.net [209.66.101.219]) by always.got.net (8.8.8/8.8.7/Debian/GNU) with ESMTP id HAA19155; Sat, 3 Apr 1999 07:52:27 -0800
Message-ID: <[e-mail]>
Date: Sat, 03 Apr 1999 07:52:11 -0800
From: Michael McNeil <[e-mail]>
Organization: GMT
X-Mailer: Mozilla 4.51 [en] (WinNT; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Paul Koning <[e-mail]>
CC: [e-mail], [e-mail], [e-mail]
Subject: Re: Time-stamp server. TimePrecision info
References: <02a201be7cb2$dda47c80$c74bffd0@brick> <[e-mail]> <v04020a08b32aa018521c@[128.89.0.110]> <[e-mail]> <v04020a12b32ad6da3056@[128.89.0.110]> <[e-mail]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

My comments below.

>>Stephen> == Stephen Kent <[e-mail]> writes:
>>>"Paul> == Paul Koning <[e-mail]> writes:

>>>>> Paul, Denis and Todd, Do we agree that the timestamp
>>>>> represents the point at which a signature was applied,
>>>>> independent of transmission delays and signing speed?

>>>Paul> It seems to me it can only possibly mean one thing: it is the
>>>Paul> time when the clock was read.  :-) That time is later than the
>>>Paul> generation of the request and earlier than the generation of
>>>Paul> the signature.

>>Stephen> A concise definition, but I think an unsatisfying one.  If
>>Stephen> the goal is to compare time stamps from two servers who have
>>Stephen> very pricesly synchronized clocks, as you note is easy to do
>>Stephen> with GPS, then internal processing delays at each server
>>Stephen> seem likely to vary so much that very fine grained time
>>Stephen> stamps cease being maeningful in many applications.  That's
>>Stephen> even before asking about network delays.  So, I'm back to
>>Stephen> the last part of my previous message.  Give us some examples
>>Stephen> where very fine grained time stamps from different
>>Stephen> (synchronized) servers are meaningful.

That's why every server's timestamps should include a precision field,
where these factors are taken into account in declaring how many bits of
the time data are significant.  This is basic scientific notation -- one
includes a statement of the precision to which the data are significant.

To answer your request for an example, Steve, I envision the widespread
timestamping of system and network events, which may need to be audited
in a post mortem following, say, a virus attack across many machines. 
If timestamps support a fine grained time resolution, then even events
which propagate within and between systems at computer speeds might be
identified and placed in their proper chronological sequence.

I say don't restrict timestamps to supporting only electronic analogues
of yesterday's paper processes (timestamping contracts, patents, etc.). 
It will be necessary to follow events operating at computer speeds.  The
potential (not mandatory!) resolution of timestamps should reflect this.

Paul Koning wrote:
>I suppose the definition I gave isn't terribly nourishing but it is, I
>think, the only possible honest one.  I suppose the question is "how
>does that relate to externally visible events?"  That's easy to answer
>but only in terms of bounds and ranges of values.
>
>Suppose I issue a request to a time stamp server at (local) time T1,
>and get a reply at time T2.  The reply contains a timestamp S and an
>error bound (precision, tolerance, whatever you call it) E.
>
>So we know that the actual time S +/- E occurred sometime between T1
>and T2 (with the assumption that both S and E are correctly
>supplied).  In other words, T1 < S + E and T2 > S - E (and, of course,
>T1 < T2).  And that's all you know for certain.
>
>If you make assumptions that may be warranted in *some* cases, such as
>roughly equal packet transit times each way, you can tighten this up
>some.

A number of probes of the time server will allow refinement of the
average round-trip latency -- refining, once again, the estimated
_precision_ of the time.  The timestamping server should then (I argue)
use this in stating the overall precision of the time in its timestamps.
The precision in timestamps must be kept in mind when comparing times
from two different (or even two timestamps from the same) time server.

This goes way beyond whether a microseconds or milliseconds field is
supported within timestamps.  Conceivably a timestamping server's time
might be off by seconds, perhaps many of them.  It could still issue
effective timestamps if it properly identifies how precise the time is.

>Incidentally, this is very reminiscent of how you analyze time
>synchronization protocols (not surprisingly).  Viewing things in terms
>of intervals is an approach you can find in the DEC Time Service
>protocol spec; NTP borrowed some of that judging by notes in RFC
>1305.
>
>As for examples where fine grained time stamps are meaningful...
>
>You can get time ticks accurate to a fraction of a microsecond today.
>Real-time kernels can offer thread response times in the 10s of
>microseconds or better (e.g., RT-Linux).  High end point to point
>datalinks running at moderate utilization (e.g., full duplex 100BaseT)
>can provide latencies way below a millisecond for moderate size
>packets.  And digital signature hardware can do decent size signatures
>in a millisecond or two.
>
>So millisecond-accuracy timestamps from sets of servers can clearly be
>meaningful today in some topologies, and sub-millisecond soon.
>
>Does that mean that it makes sense from me to request sub-millisecond
>resolution timestamps from ACME Timestamp Service, across the global
>Internet, from my Win95 laptop?  No, but not all applications are like
>that.  If you have a real-time environment in a well-designed LAN
>setting, fine grained timestamps are quite meaningful.  And, if you
>want fine resolution time stamps for your real time process logs,
>useful too.

I quite agree.  To my mind, some statements made in this discussion
suggesting there should be no microseconds or even milliseconds field
for time within timestamps are akin to suggestions that our numbering
system shouldn't contain a micro-th or pico-th digit.  Just because it's
possible in our numbering system to express a number down to the _nano_
level, say, doesn't mean anyone warrants that any particular number is
meaningful down to that level.  Instead, one identifies the degree to
which digits of the number are meaningful (with a + or - notation, say).

Let's not forget and have to relearn notational lessons which scientists
and (non-software) engineers have long since had -- in self defense --
to burn into their brain cells.  Let's also not create new "millennium"
problems where we might easily initially allow a wide enough field.

Especially, let's get off this idea that any number of bits of allowed
width for the time representation implies that is what's intended to be
meaningful.  In my view, NTP many years ago did it about right (for at
least the short-term foreseeable future) in allowing specification of
fractional time down to 2^(-32) second -- about 20% of a nanosecond.

I doubt that, even today, any time server approaches this resolution;
but the fact that the field width is set at this fine-grained level
allows any server to get as close as it possibly can.  And by NTP's
identifying how close (precise) it is, one knows what bits to trust.

I also like NTP's suggestion that bits beyond the limit of meaningful
precision in the fractional representation be filled in not with 0 but
by a random pattern.  This allows, for example, a client to identify its
echoed-back submitted time in the server's signed response as uniquely
its own most recent request (even when its own time precision is no
better than a second, say), helping defeat replay attacks and the like.

I suggest two possibilities:  1) use the NTP time format for seconds and
fractional seconds.  Or, 2) specify a nanoseconds subfield for the time
representation format in timestamps -- don't stop with microseconds.  As
an equally important requirement, include a statement of precision whose
format should cover the range from many seconds down to the nanosecond.

--
Michael McNeil
[e-mail]


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id FAA24140 for ietf-pkix-bks; Sat, 3 Apr 1999 05:34:09 -0800 (PST)
Received: from mail.student.auckland.ac.nz (mail.student.auckland.ac.nz [130.216.35.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id FAA24136 for <[e-mail]>; Sat, 3 Apr 1999 05:34:06 -0800 (PST)
Received: from cs26.cs.auckland.ac.nz ([e-mail] [130.216.36.9]) by mail.student.auckland.ac.nz (8.8.6/8.8.6/cs-master) with SMTP id BAA18696; Sun, 4 Apr 1999 01:34:24 +1200 (NZST) (sender [e-mail])
Received: by cs26.cs.auckland.ac.nz (relaymail v0.9) id <92314646331939>; Sun, 4 Apr 1999 01:34:23 (NZST)
From: [e-mail] (Peter Gutmann)
To: [e-mail], [e-mail]
Subject: Re: Changes to RFC2459
Reply-To: [e-mail]
X-Charge-To: pgut001
X-Authenticated: relaymail v0.9 on cs26.cs.auckland.ac.nz
Date: Sun, 4 Apr 1999 01:34:23 (NZST)
Message-ID: <[e-mail]>
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Stephen Kent <[e-mail]>
 
>This is consistent with PKIX, which calls for the extension to be present and
>non-NULL for a CA cert, but recommends that it be absent for an EE cert.  It
>is consistent with X.509, which requires the extension to always be present and
>non-null for a CA, but suggests that it be present and NULL for an EE.  X.509
>also suggests that if the extension is not present, then a system may choose
>to employ other means to determine if it is an EE or a CA cert.  But, in that
>case, you're back to looking at other fields ...
>
>What's the problem?
 
We went through this whole thing less than six months ago.  Here's what I 
posted the last time this came round:
 
-- Snip --
 
Both MSIE and Netscape treat self-signed certs without basicConstraits as 
CA's by default (in fact I don't know of any way to get them to *not* 
treat the cert owners as CA's).
 
MSIE: "You have been offered a new site certificate to place in your list
       of trusted issuers..."
Netscape: "You are about to go through the process of accepting a
           certificate authority..."
 
Leaving out the basicConstraints makes the assumption that relying parties
are using PKIX-compliant software, and that the software will DTRT when it
finds one of these certs.  I think this is leaving what could be a critical
security issue more or less to chance - all I need to do is find some
software which happens to not follow PKIX's implied behaviour and I can go
ahead and issue my own certs and let the entire world in the door.
 
-- Snip --
                              
Leading to the following entry in the X.509 style guide:
 
-- Snip --
 
PKIX
 
  PKIX requires that end entity certificates not have a basicConstraints
  extension, which leaves the handling of the CA status of the certificate to
  chance.  Several popular applications treat these certificates as CA
  certificates for backwards-compatibility with X.509v1 CA certificates which
  didn't include basicConstraints, but in practice it's not really possible to
  determine how these certificates will be treated.  Because of this, it's not
  possible to issue a PKIX-compliant end entity certificate and know how it'll
  be treated once it's in circulation.
 
  One use for this feature is that it may be used as a cryptographically strong
  random number generator.  For each crypto key an application would issue 128
  basicConstraint-less certificates, hand them out to different
  implementations/users, and use their CA/non-CA interpretation as one bit of a
  session key.  This should yield close to 128 bits of pure entropy in each
  key.
 
-- Snip --
 
Peter.
 



Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id VAA07849 for ietf-pkix-bks; Fri, 2 Apr 1999 21:03:15 -0800 (PST)
Received: from gmtsw.com (test.glassey.com [207.126.98.130] (may be forged)) by mail.proper.com (8.8.8/8.8.5) with SMTP id VAA07843 for <[e-mail]>; Fri, 2 Apr 1999 21:03:14 -0800 (PST)
Received: from brick by gmtsw.com (SMI-8.6/SMI-SVR4) id VAA13213; Fri, 2 Apr 1999 21:03:37 -0800
Message-ID: <00d401be7d8e$ac950d30$fa4bffd0@brick>
From: "Todd S. Glassey" <[e-mail]>
To: "Robert Zuccherato" <[e-mail]>, "Denis Pinkas" <[e-mail]>, "'Todd S. Glassey'" <[e-mail]>
Cc: <[e-mail]>, "'Paul Koning'" <[e-mail]>, <[e-mail]>, "Mike King" <[e-mail]>
Subject: Re: Time-stamp server. TimePrecision info
Date: Fri, 2 Apr 1999 20:58:52 -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 4.72.3110.5
X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Robert - this is a dodge. I am not looking for an exhaustive list, I am
looking for the one you designed it for. You built a suite of routines
here - so how and what did you intend to use them.

Todd

-----Original Message-----
From: Robert Zuccherato <[e-mail]>
To: Denis Pinkas <[e-mail]>; 'Todd S. Glassey'
<[e-mail]>
Cc: [e-mail] <[e-mail]>; 'Paul Koning'
<[e-mail]>; [e-mail] <[e-mail]>; Mike King
<[e-mail]>
Date: Friday, April 02, 1999 7:41 PM
Subject: RE: Time-stamp server. TimePrecision info


>Todd;
>
>> ----------
>> From: Todd S. Glassey[SMTP:[e-mail]]
>> Sent: Friday, April 02, 1999 4:46 PM
>> To: Denis Pinkas; Todd S. Glassey
>> Cc: Robert Zuccherato; [e-mail]; 'Paul Koning';
>> [e-mail]; Mike King
>> Subject: Re: Time-stamp server. TimePrecision info
>>
>> Denis, Robert , I totally disagree
>>
>> >> >That said, I agree with Denis.  I do not see the use of microseconds
>> to
>> be
>> >> >especially useful within this protocol.
>>
>> OK, so what exactly are the end uses of the protocol then? - I mean the
>> specific end use models. You must have them in mind if you can say that
>> Microseconds are not relevent. What I need to know is how am I going to
>> use
>> this protocol?
>>
>As the draft states, the main purpose of this service is "to verify that a
>digital signature was applied before the certificate was revoked thus
>allowing a revoked public key certificate to be used for verifying
>signatures created prior to the time of revocation".  Since CRLs only use
>either UTCTime or GeneralizedTime, even milliseconds may not be relevant
for
>this purpose.
>
>However, as the draft states "An exhaustive list of possible uses of a TSA
>is beyond the scope of this document."  Thus, we included millisecond
>accuracy.  I am not really opposed to including microsecond accuracy.  I
>just do not see the need for it.
>
> Robert.
>



Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id VAA07457 for ietf-pkix-bks; Fri, 2 Apr 1999 21:01:14 -0800 (PST)
Received: from gmtsw.com (test.glassey.com [207.126.98.130] (may be forged)) by mail.proper.com (8.8.8/8.8.5) with SMTP id VAA07451 for <[e-mail]>; Fri, 2 Apr 1999 21:01:13 -0800 (PST)
Received: from brick by gmtsw.com (SMI-8.6/SMI-SVR4) id VAA13210; Fri, 2 Apr 1999 21:01:45 -0800
Message-ID: <00d301be7d8e$68bff070$fa4bffd0@brick>
From: "Todd S. Glassey" <[e-mail]>
To: "Stephen Kent" <[e-mail]>
Cc: <[e-mail]>
Subject: Re: Time-stamp server. TimePrecision info
Date: Fri, 2 Apr 1999 20:56:58 -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 4.72.3110.5
X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Steven, A policy Anchor is exactly what it sounds like. A mechanism used to
anchor a point in the operational policy of some system making it
referencable.


-----Original Message-----
From: Stephen Kent <[e-mail]>
To: Todd S. Glassey <[e-mail]>
Cc: [e-mail] <[e-mail]>
Date: Friday, April 02, 1999 3:16 PM
Subject: Re: Time-stamp server. TimePrecision info


>Todd,
>
>I have no idea what the phrase "a policy anchor for a PKI" means.  As a
>provider of CA services and technology, I can assure you that none of my
>clients has ever felt the need for such a precise time base wrt certificate
>or CRL processing.

Becuase none of them or the auditors know its possible. Also most of the
world already believes that these issues are addressed. After all isn't the
OS trustable?

>So, I am puzzled by your terminology, insofar as it
>references PKIs, and suggest that you don't continue to use this phrease
>unless you can explain what it means and how it relates to the current
>discussion.

The phrase Policy Anchor is actually specific to an old IA concept with
regard to management policy for manufacturing and control applications.

>
>Separately, I am willing to believe that there may be applications that
>require the sort of precision you're suggesting, but I don't recall seeing
>them described here yet.


>
>Steve
>



Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id UAA01923 for ietf-pkix-bks; Fri, 2 Apr 1999 20:29:30 -0800 (PST)
Received: from gmtsw.com (test.glassey.com [207.126.98.130] (may be forged)) by mail.proper.com (8.8.8/8.8.5) with SMTP id UAA01915 for <[e-mail]>; Fri, 2 Apr 1999 20:29:28 -0800 (PST)
Received: from brick by gmtsw.com (SMI-8.6/SMI-SVR4) id UAA13192; Fri, 2 Apr 1999 20:29:56 -0800
Message-ID: <00b301be7d89$f763b190$fa4bffd0@brick>
From: "Todd S. Glassey" <[e-mail]>
To: "Paul Koning" <[e-mail]>, "Stephen Kent" <[e-mail]>
Cc: <[e-mail]>
Subject: Re: Time-stamp server. TimePrecision info
Date: Fri, 2 Apr 1999 20:25:10 -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 4.72.3110.5
X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

-----Original Message-----
From: Stephen Kent <[e-mail]>
To: Paul Koning <[e-mail]>
Cc: [e-mail] <[e-mail]>
Date: Friday, April 02, 1999 5:10 PM
Subject: Re: Time-stamp server. TimePrecision info


>Paul,
>
>> Stephen> Denis and Todd, Do we agree that the timestamp represents
>> Stephen> the point at which a signature was applied, independent of
>> Stephen> transmission delays and signing speed?
>>
>>It seems to me it can only possibly mean one thing: it is the time
>>when the clock was read.  :-)  That time is later than the generation
>>of the request and earlier than the generation of the signature.
>
>A concise definition, but I think an unsatisfying one.  If the goal is to
>compare time stamps from two servers who have very pricesly synchronized
>clocks, as you note is easy to do with GPS, then internal processing delays
>at each server seem likely to vary so much that very fine grained time
>stamps cease being maeningful in many applications.  That's even before
>asking about network delays.  So, I'm back to the last part of my previous
>message.  Give us some examples where very fine grained time stamps from
>different (synchronized) servers are meaningful.

off the top of my head here are four

#1)    Telcom Backbone management systems, tightly coupled cluster systems
maker up what are now virtual switches.

#2)    Event Simulation and Decision Support Management

#3)    Precision control of mechancial processes, like operating a high head
water cam on a power plant or the like, or operating a vacume control
sputtering system for semiconductor processing.

#4)    Market Trading and Control of trading processes. - Many systems are
now tightly coupled fault tolerant clusters and these systems need this
"ridiculous" level of precision in their timestamping since they are not
connected in the same way we usually connect together (lan/wan/man etc).

>>
> <snip>
>
>>
>>Given that it costs nothing to allow the extra digits, why is there
>>such a concern about doing that and future-proofing things?
>
>Just because we CAN do something syntactically, that does not mean that we
>should.  I'm a firm believer in trying to understand the implications of
>the protocols that we develop, not just working on the details of the
>protocols.

Then you have to answer the question "how is this thing going to be used" in
order to know what it needs to be able to do.

Todd




Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id UAA00480 for ietf-pkix-bks; Fri, 2 Apr 1999 20:07:04 -0800 (PST)
Received: from relay6.UU.NET (relay6.UU.NET [192.48.96.16]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id UAA00476 for <[e-mail]>; Fri, 2 Apr 1999 20:07:03 -0800 (PST)
Received: from xedia.com by relay6.UU.NET with SMTP  (peer crosschecked as: madway.xedia.com [198.202.232.199]) id QQgjgd17587; Fri, 2 Apr 1999 15:52:55 -0500 (EST)
Received: from tonga.xedia.com by xedia.com (4.1/SMI-4.1) id AA09107; Fri, 2 Apr 99 15:48:49 EST
Received: by tonga.xedia.com (SMI-8.6/SMI-SVR4) id PAA00608; Fri, 2 Apr 1999 15:52:48 -0500
Date: Fri, 2 Apr 1999 15:52:48 -0500
Message-Id: <[e-mail]>
From: Paul Koning <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
To: [e-mail]
Cc: [e-mail]
Subject: Re: Time-stamp server. TimePrecision info
References: <02a201be7cb2$dda47c80$c74bffd0@brick> <[e-mail]> <v04020a08b32aa018521c@[128.89.0.110]> <[e-mail]> <v04020a12b32ad6da3056@[128.89.0.110]>
X-Mailer: VM 6.34 under 20.3 "Vatican City" XEmacs  Lucid
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

>>>>> "Stephen" == Stephen Kent <[e-mail]> writes:

 >>>> Paul, Denis and Todd, Do we agree that the timestamp
 >>>> represents the point at which a signature was applied,
 >>>> independent of transmission delays and signing speed?
 >>  It seems to me it can only possibly mean one thing: it is the
 >> time when the clock was read.  :-) That time is later than the
 >> generation of the request and earlier than the generation of the
 >> signature.

 Stephen> A concise definition, but I think an unsatisfying one.  If
 Stephen> the goal is to compare time stamps from two servers who have
 Stephen> very pricesly synchronized clocks, as you note is easy to do
 Stephen> with GPS, then internal processing delays at each server
 Stephen> seem likely to vary so much that very fine grained time
 Stephen> stamps cease being maeningful in many applications.  That's
 Stephen> even before asking about network delays.  So, I'm back to
 Stephen> the last part of my previous message.  Give us some examples
 Stephen> where very fine grained time stamps from different
 Stephen> (synchronized) servers are meaningful.

I suppose the definition I gave isn't terribly nourishing but it is, I 
think, the only possible honest one.  I suppose the question is "how
does that relate to externally visible events?"  That's easy to answer 
but only in terms of bounds and ranges of values.

Suppose I issue a request to a time stamp server at (local) time T1,
and get a reply at time T2.  The reply contains a timestamp S and an
error bound (precision, tolerance, whatever you call it) E.

So we know that the actual time S +/- E occurred sometime between T1
and T2 (with the assumption that both S and E are correctly
supplied).  In other words, T1 < S + E and T2 > S - E (and, of course, 
T1 < T2).  And that's all you know for certain.

If you make assumptions that may be warranted in *some* cases, such as 
roughly equal packet transit times each way, you can tighten this up
some.

Incidentally, this is very reminiscent of how you analyze time
synchronization protocols (not surprisingly).  Viewing things in terms 
of intervals is an approach you can find in the DEC Time Service
protocol spec; NTP borrowed some of that judging by notes in RFC
1305.

As for examples where fine grained time stamps are meaningful...

You can get time ticks accurate to a fraction of a microsecond today.
Real-time kernels can offer thread response times in the 10s of
microseconds or better (e.g., RT-Linux).  High end point to point
datalinks running at moderate utilization (e.g., full duplex 100BaseT) 
can provide latencies way below a millisecond for moderate size
packets.  And digital signature hardware can do decent size signatures 
in a millisecond or two.

So millisecond-accuracy timestamps from sets of servers can clearly be
meaningful today in some topologies, and sub-millisecond soon.

Does that mean that it makes sense from me to request sub-millisecond
resolution timestamps from ACME Timestamp Service, across the global
Internet, from my Win95 laptop?  No, but not all applications are like 
that.  If you have a real-time environment in a well-designed LAN
setting, fine grained timestamps are quite meaningful.  And, if you
want fine resolution time stamps for your real time process logs,
useful too.

	paul


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id TAA25895 for ietf-pkix-bks; Fri, 2 Apr 1999 19:36:07 -0800 (PST)
Received: from europe.std.com (europe.std.com [199.172.62.20]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id TAA25882 for <[e-mail]>; Fri, 2 Apr 1999 19:36:03 -0800 (PST)
Received: from world.std.com by europe.std.com (STD1.2/BZS-8-1.0) id WAA25345; Fri, 2 Apr 1999 22:36:17 -0500 (EST)
Received: by world.std.com (TheWorld/Spike-2.0) id AA01098; Fri, 2 Apr 1999 22:36:17 -0500
Message-Id: <[e-mail]>
To: [e-mail]
Subject: Re: Time-stamp server. TimePrecision info 
In-Reply-To: A blather of messages as of "Fri, 02 Apr 1999 13:46:17 EST." <003d01be7d52$3ecaf030$fa4bffd0@brick> 
Date: Fri, 02 Apr 1999 22:36:17 -0500
From: Dan Geer <[e-mail]>
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

We argue most about mechanism when we are least
reconciled with respect to requirement.  Perhaps
I can provide a succulent target:

  The requirement for time is event serialization
  sufficient to support an economic level of recourse.

Unremarkably, two events within the error band are
definitionally simultaneous -- the NYSE tick is
not micro-seconds but rather macro- and many events
are declared simultaneous in the interest of fairness,
to take a central example from high-value commerce.

Is there an economist in the house?

--dan



Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id SAA18418 for ietf-pkix-bks; Fri, 2 Apr 1999 18:31:27 -0800 (PST)
Received: from gatekeeper.entrust.com (gatekeeper.entrust.com [204.101.128.170]) by mail.proper.com (8.8.8/8.8.5) with SMTP id SAA18409 for <[e-mail]>; Fri, 2 Apr 1999 18:31:25 -0800 (PST)
Received: 	id VAB01720; Fri, 2 Apr 1999 21:25:33 -0500
Received: by gateway id <G4CAZ18C>; Fri, 2 Apr 1999 21:00:28 -0500
Message-ID: <01E1D01C12D7D211AFC70090273D20B112BD6B@sothmxs06>
From: Robert Zuccherato <[e-mail]>
To: Denis Pinkas <[e-mail]>, "'Todd S. Glassey'" <[e-mail]>
Cc: [e-mail], "'Paul Koning'" <[e-mail]>, [e-mail], Mike King <[e-mail]>
Subject: RE: Time-stamp server. TimePrecision info
Date: Fri, 2 Apr 1999 20:54:51 -0500 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.1960.3)
Content-Type: text/plain
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Todd;

> ----------
> From: 	Todd S. Glassey[SMTP:[e-mail]]
> Sent: 	Friday, April 02, 1999 4:46 PM
> To: 	Denis Pinkas; Todd S. Glassey
> Cc: 	Robert Zuccherato; [e-mail]; 'Paul Koning';
> [e-mail]; Mike King
> Subject: 	Re: Time-stamp server. TimePrecision info
> 
> Denis, Robert , I totally disagree
> 
> >> >That said, I agree with Denis.  I do not see the use of microseconds
> to
> be
> >> >especially useful within this protocol.
> 
> OK, so what exactly are the end uses of the protocol then? - I mean the
> specific end use models. You must have them in mind if you can say that
> Microseconds are not relevent. What I need to know is how am I going to
> use
> this protocol?
> 
As the draft states, the main purpose of this service is "to verify that a
digital signature was applied before the certificate was revoked thus
allowing a revoked public key certificate to be used for verifying
signatures created prior to the time of revocation".  Since CRLs only use
either UTCTime or GeneralizedTime, even milliseconds may not be relevant for
this purpose.  

However, as the draft states "An exhaustive list of possible uses of a TSA
is beyond the scope of this document."  Thus, we included millisecond
accuracy.  I am not really opposed to including microsecond accuracy.  I
just do not see the need for it.

	Robert.


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id QAA15619 for ietf-pkix-bks; Fri, 2 Apr 1999 16:47:29 -0800 (PST)
Received: from lux.tenebras.com (dnai-207-181-255-74.dialup.dnai.com [207.181.255.74]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id QAA15615 for <[e-mail]>; Fri, 2 Apr 1999 16:47:28 -0800 (PST)
Received: from dnai.com (windoze [192.168.100.122]) by lux.tenebras.com (8.8.8/8.8.8) with ESMTP id QAA05596; Fri, 2 Apr 1999 16:47:04 -0800 (PST) (envelope-from [e-mail])
Message-ID: <[e-mail]>
Date: Fri, 02 Apr 1999 16:46:53 -0800
From: Michael Sierchio <[e-mail]>
Reply-To: [e-mail]
Organization: Oversized Metaphysics
X-Mailer: Mozilla 4.51 [en] (Win95; U)
X-Accept-Language: en
MIME-Version: 1.0
To: [e-mail]
Subject: Re: policy oid registration, and handling
References: <028001be7d32$7d7b1e10$[e-mail]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Peter Williams wrote:
> 
> "MISPC Reference Implementation (T. Polk-NIST)
> CDROM contains CA, RA, and client executable code. Represents a profile of
> 2459, CMP, and CRMF. Available via web site: http://crscnist.gov/pki/mispc/"

http://csrc.nist.gov/pki/mispc/

Minimum Interoperability   
Specifications for PKI Components
Cooperative Research and Development: Implementing an Interoperable PKI

NIST developed the Minimum Interoperability Specifications for PKI
Components (MISPC), Version 1 with the assistance of ten CRADA
partners:  AT&T, BBN, Certicom, Cylink, DynCorp, IRE, Motorola,
Nortel (Entrust), Spyrus, and Verisign. The specification includes
a certificate and CRL profile, message formats and basic transactions
for a PKI issuing signature certificates. The specification includes
support for multiple signature algorithms and transactions to 
support a broad range of security policies. This document has been
formally published as a NIST Special Publication 800-15; it is
available electronically in Microsoft Word (284K) or PostScript
(954K).


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id PAA14576 for ietf-pkix-bks; Fri, 2 Apr 1999 15:15:47 -0800 (PST)
Received: from po1.bbn.com (PO1.BBN.COM [192.1.50.38]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id PAA14572 for <[e-mail]>; Fri, 2 Apr 1999 15:15:46 -0800 (PST)
Received: from [128.89.0.110] (COSMEC.BBN.COM [128.89.0.110]) by po1.bbn.com (8.9.1/8.9.1) with ESMTP id SAA20952; Fri, 2 Apr 1999 18:16:02 -0500 (EST)
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
X-Sender: [e-mail]
Message-Id: <v04020a16b32af9d2680c@[128.89.0.110]>
In-Reply-To: <003d01be7d52$3ecaf030$fa4bffd0@brick>
Date: Fri, 2 Apr 1999 18:18:46 -0500
To: "Todd S. Glassey" <[e-mail]>
From: Stephen Kent <[e-mail]>
Subject: Re: Time-stamp server. TimePrecision info
Cc: <[e-mail]>
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Todd,

I have no idea what the phrase "a policy anchor for a PKI" means.  As a
provider of CA services and technology, I can assure you that none of my
clients has ever felt the need for such a precise time base wrt certificate
or CRL processing.  So, I am puzzled by your terminology, insofar as it
references PKIs, and suggest that you don't continue to use this phrease
unless you can explain what it means and how it relates to the current
discussion.

Separately, I am willing to believe that there may be applications that
require the sort of precision you're suggesting, but I don't recall seeing
them described here yet.

Steve


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id PAA14447 for ietf-pkix-bks; Fri, 2 Apr 1999 15:03:59 -0800 (PST)
Received: from po1.bbn.com (PO1.BBN.COM [192.1.50.38]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id PAA14443 for <[e-mail]>; Fri, 2 Apr 1999 15:03:58 -0800 (PST)
Received: from [128.89.0.110] (COSMEC.BBN.COM [128.89.0.110]) by po1.bbn.com (8.9.1/8.9.1) with ESMTP id PAA18122; Fri, 2 Apr 1999 15:16:21 -0500 (EST)
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
X-Sender: [e-mail]
Message-Id: <v04020a10b32ad27828c8@[128.89.0.110]>
In-Reply-To: <2FBF98FC7852CF11912A0000000000010ECB5E01@DINO>
Date: Fri, 2 Apr 1999 15:16:34 -0500
To: "Jim Schaad (Exchange)" <[e-mail]>
From: Stephen Kent <[e-mail]>
Subject: RE: Changes to RFC2459
Cc: [e-mail]
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Jim & Moshe,

I admit to being confused at this point.  My reading of PKIX and X.509
suggests the folowing simple test, (coded in Kent++):

- IF BasicConstraints PRESENT AND
	IF BasicConstraints.cA PRESENT
		THEN certificate-is-ca
		ELSE certificate-is-ee
	ELSE certificate-is-ee

This is consistent with PKIX, which calls for the extension to be present
and non-NULL for a CA cert, but recommends that it be absent for an EE
cert.  It is consistent with X.509, which requires the extension to always
be present and non-null for a CA, but suggests that it be present and NULL
for an EE.  X.509 also suggests that if the extension is not present, then
a system may choose to employ other means to determine if it is an EE or a
CA cert.  But, in that case, you're back to looking at other fields ...

What's the problem?

Steve


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id OAA14236 for ietf-pkix-bks; Fri, 2 Apr 1999 14:41:05 -0800 (PST)
Received: from prv-mail20.provo.novell.com (prv-mail20.Provo.Novell.COM [137.65.40.4]) by mail.proper.com (8.8.8/8.8.5) with SMTP id OAA14232 for <[e-mail]>; Fri, 2 Apr 1999 14:41:04 -0800 (PST)
Received: from INET-PRV-Message_Server by prv-mail20.provo.novell.com with Novell_GroupWise; Fri, 02 Apr 1999 15:19:02 -0700
Message-Id: <[e-mail]>
X-Mailer: Novell GroupWise 5.5
Date: Fri, 02 Apr 1999 15:18:56 -0700
From: "Bob Jueneman" <[e-mail]>
To: <[e-mail]>, <[e-mail]>, <[e-mail]>
Cc: <[e-mail]>
Subject: Re: Low-fat leaf 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 mail.proper.com id OAA14233
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Just an observation.

"Low fat leaf" (LFL) certificates may make great sense if the "fat contents"
are available for trusted lookup , say in a directory.

However, it is much more likely that the "fat" content is back in the originator's 
directory, rather than the relying party's directory.

That being the case, it probably takes a lot less bandwidth, and certainly less 
latency time, to go ahead and include the information in the certificate
itself, rather then fire up LDAP to the other directory to fetch it.

Obviously this depends on how often the information is needed.  If you 
are likely to need it often, you ought to pay the burden once, and then
cache it locally in the RP directory.

Assuming the infrastructure exists to do it either way, this becomes an 
engineering tradeoff.  The same is true for sending certificates over the 
wire repeatedly, as in SSL and S/MIME, rather than normally retrieving
them from the local cache or directory or going back to the originator
as required.

Bob


>>> Peter Sylvester <[e-mail]> 03/31/99 06:49AM >>>
> 
> 1)  "Name"  (an alias/friendly name [as you are allowed to change name without changing "e"-identity])
> 
> 2) "dnQualifier"  (a static [probably random] unique identifier in the domain)
> 
> It is hard to get much slimmer than that!
> 
No, you don't need 1. 

Actually 2 is 'the name' in the sense of a unique identifier to find a directory entry.



Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id OAA14077 for ietf-pkix-bks; Fri, 2 Apr 1999 14:25:30 -0800 (PST)
Received: from gmtsw.com (test.glassey.com [207.126.98.130] (may be forged)) by mail.proper.com (8.8.8/8.8.5) with SMTP id OAA14071 for <[e-mail]>; Fri, 2 Apr 1999 14:25:25 -0800 (PST)
Received: from brick by gmtsw.com (SMI-8.6/SMI-SVR4) id NAA12934; Fri, 2 Apr 1999 13:51:00 -0800
Message-ID: <003d01be7d52$3ecaf030$fa4bffd0@brick>
From: "Todd S. Glassey" <[e-mail]>
To: "Denis Pinkas" <[e-mail]>, "Todd S. Glassey" <[e-mail]>
Cc: "Robert Zuccherato" <[e-mail]>, <[e-mail]>, "'Paul Koning'" <[e-mail]>, <[e-mail]>, "Mike King" <[e-mail]>
Subject: Re: Time-stamp server. TimePrecision info
Date: Fri, 2 Apr 1999 13:46:17 -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 4.72.3110.5
X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Denis, Robert , I totally disagree

>> >That said, I agree with Denis.  I do not see the use of microseconds to
be
>> >especially useful within this protocol.

OK, so what exactly are the end uses of the protocol then? - I mean the
specific end use models. You must have them in mind if you can say that
Microseconds are not relevent. What I need to know is how am I going to use
this protocol?

>>Todd Responded: OK Fine, but humor me - what's the harm in being able to
represent them?
>
> Denis: The TSA gets the clock first and then signs. I do not know any
hardware
>capable of signature in the micro-second range.

Denis, The speed of the signature generation process today, has only a small
amount to do with the time the timestamp process generation model takes, so
this is not true. The signing process will be addressed by large signing
engines for bulk document processing and for end user or POS style
documents, the onesee twosee game - who cares how long it takes.

And as to the issue of microseconds or nanoseconds, the physicists, have had
time distribution networks with IRIG-B timecode protocol distribution
facilities and the like for some years now. We in the IETF standarized on
NTP and it supports 2 to the -32nd power resolution, so why is this argument
even happening?

We can commercially distribute time down to the nanosecond if we desire to.
Timebases to support these requirements are available commercially today
from Datum, HP, TrueTime, Odetics, Guide Technologies, and a  wealth of
others. Ay commercial operator could easily have their own Cesium reference
for between $40K to $60K. IBM and HP have both regularly included them as an
option with the mainframes they offer.

As an example of this technology availability, Datum and others have these
Cesium Heads with built in GPS Disciplining and all the drivers you need.
Datum calls their's the GPS+ and from my side, this is a no brianer, if I
need a certifiable timesource as a policy anchor for a PKI, I buy one of
these systems and put it under contract to NIST to calibrate.  POOF!!!, the
resulting system, coupled with a rigid BCP model provides a  truely credible
Local Timebase that will easily pass any SAS70 and/or CS2 Audit if operated
correctly.

>The transmission delay is also
>quite variable.

...and not directly relevent to the question at hand. While the transmission
delay is specific to the time it takes to get the event notification to the
stamping engine. The only relevency here is when the event actually reached
the stanmping agency itself. The amount of time of takes is a function of
the transport and its utilization... and these issues will change as
technology is evolved and the stamper is right sized for its loading.

As to the existance of the transmission delay issue, well this is the plight
of any distributed agency, the hysteresis and latency of the transport being
what it is, you build end user models that take this into account. [here we
are again, back to the end user models and how important they are...]

>The harm is giving false impression of precision.

No Sir - I really feel strongly here that the actual harm is in not building
a system that is insensitive to hiccups in the technological landscape.

Denis, let me know if I read you wrong, but the general tone of your retort
here leads me to believe that your model is specific to  SW only based
systems, layered on traditional clock chips and the OS  TOD Services. My
personal feeling is that this is one of those instances where SW only models
are limited, but that hybrid systems abound and they are not, and the SW
only ones will get better in time so in closing,  Gentlemen - the timebase
representation should mirror NTP 4.0's as a baseline.

Todd




Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id OAA14072 for ietf-pkix-bks; Fri, 2 Apr 1999 14:25:26 -0800 (PST)
Received: from gmtsw.com (test.glassey.com [207.126.98.130] (may be forged)) by mail.proper.com (8.8.8/8.8.5) with SMTP id OAA14066 for <[e-mail]>; Fri, 2 Apr 1999 14:25:25 -0800 (PST)
Received: from brick by gmtsw.com (SMI-8.6/SMI-SVR4) id OAA12944; Fri, 2 Apr 1999 14:05:26 -0800
Message-ID: <004801be7d54$425b7f10$fa4bffd0@brick>
From: "Todd S. Glassey" <[e-mail]>
To: "Paul Koning" <[e-mail]>, <[e-mail]>
Cc: <[e-mail]>
Subject: Re: Time-stamp server. TimePrecision info
Date: Fri, 2 Apr 1999 14:00:39 -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 4.72.3110.5
X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

-----Original Message-----
From: Paul Koning <[e-mail]>
To: [e-mail] <[e-mail]>
Cc: [e-mail] <[e-mail]>
Date: Friday, April 02, 1999 11:10 AM
Subject: Re: Time-stamp server. TimePrecision info


>>>>>> "Stephen" == Stephen Kent <[e-mail]> writes:
>
> Stephen> Denis and Todd, Do we agree that the timestamp represents
> Stephen> the point at which a signature was applied, independent of
> Stephen> transmission delays and signing speed?
>
>It seems to me it can only possibly mean one thing: it is the time
>when the clock was read.  :-)  That time is later than the generation
>of the request and earlier than the generation of the signature.

Within a few microseconds, assuming a vertical stamping model, yes it would
be the time when the agent got the event notification and responded.

>
> Stephen> If so, then I would
> Stephen> not agrue against very fine granularity time stamps on thae
> Stephen> basis of thise delays. Instead, I would argue that there is
> Stephen> a false sense of precision being implied, and that we're
> Stephen> better off just relying on the sequence number to serialize
> Stephen> time stamps issued by the same server within the same tick.

Don't limit the granularity of the timestamping facility by the OS
implementation today. They are all broken with regard to this, but that will
change when people come to realize how important "secureing their trust
anchors" is and how critical the timebase is part of that.

Certifiable timebases will become the metranome of the business to buisness
extranet and corporate audited infrastructure.

>
>It sounds like you're arguing that only significant digits should be
>present in the timestamp.  The problem with that is that the server
>has no way to do that, if you want to include network delays as part
>of the tolerance implied by the digit count.


This network delay weighting model then becomes the policy of what your
timestamp represents. The total end to end time, or the time the "reciever
agent" acknowledged the recepit of the event?, either way its specific to
the policy and services structure of your stamping process, i.e. the use
models...

>
>Better to indicate or document the various error sources explicitly.
>Those the server knows about it can report if a tolerance (precision)
>field is added.  Those relating to network latency the server cannot
>know but the client can (bounded by delay between request and
>response).
>
> Stephen> If one believes that the time stamps have to represent finer
> Stephen> granularity because they will be compared with time stamps
> Stephen> from other servers, then there's a lot of work to do to
> Stephen> convince me that the resulting synchronization is feasible,
> Stephen> and that there is a legitimate need for such.  Obviously the
> Stephen> world lives with rather coarse precision and accuracy for
> Stephen> lots of business time stamp operations today.  maybe we need
> Stephen> some additional, credible, motivating examples.
>
>Synchronization of two devices to within a fraction of a microsecond
>is perfectly feasible today.  Any GPS nav box does exactly that.

GPS based NTP servers are in the 2.5K range and you can get a high quality
one with a rubidium oscillator for an addition 5K or 6K. Cesiums is cheap
these days if you are a bank. These days a medium performance router is more
costly than an atomic clock setup for a network timebase. Since locally
operated Atomic sources can provide 1x10-12th accuracy over a year and if
they are audited by NIST. With a setup like this, you should be able to run
a local source that stays  provably, within a few nanoseconds of TAI/UTC.

>
>Given that it costs nothing to allow the extra digits, why is there
>such a concern about doing that and future-proofing things?

Amen!

Todd





Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id MAA13851 for ietf-pkix-bks; Fri, 2 Apr 1999 12:28:05 -0800 (PST)
Received: from po1.bbn.com ([192.1.50.38]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id MAA13846 for <[e-mail]>; Fri, 2 Apr 1999 12:27:24 -0800 (PST)
Received: from [128.89.0.110] (COSMEC.BBN.COM [128.89.0.110]) by po1.bbn.com (8.9.1/8.9.1) with ESMTP id PAA22889; Fri, 2 Apr 1999 15:26:31 -0500 (EST)
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
X-Sender: [e-mail]
Message-Id: <v04020a12b32ad6da3056@[128.89.0.110]>
In-Reply-To: <[e-mail]>
References: <02a201be7cb2$dda47c80$c74bffd0@brick> <[e-mail]>	<v04020a08b32aa018521c@[128.89.0.110]>
Date: Fri, 2 Apr 1999 15:25:27 -0500
To: Paul Koning <[e-mail]>
From: Stephen Kent <[e-mail]>
Subject: Re: Time-stamp server. TimePrecision info
Cc: [e-mail]
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Paul,

> Stephen> Denis and Todd, Do we agree that the timestamp represents
> Stephen> the point at which a signature was applied, independent of
> Stephen> transmission delays and signing speed?
>
>It seems to me it can only possibly mean one thing: it is the time
>when the clock was read.  :-)  That time is later than the generation
>of the request and earlier than the generation of the signature.

A concise definition, but I think an unsatisfying one.  If the goal is to
compare time stamps from two servers who have very pricesly synchronized
clocks, as you note is easy to do with GPS, then internal processing delays
at each server seem likely to vary so much that very fine grained time
stamps cease being maeningful in many applications.  That's even before
asking about network delays.  So, I'm back to the last part of my previous
message.  Give us some examples where very fine grained time stamps from
different (synchronized) servers are meaningful.
>
	<snip>

>
>Given that it costs nothing to allow the extra digits, why is there
>such a concern about doing that and future-proofing things?

Just because we CAN do something syntactically, that does not mean that we
should.  I'm a firm believer in trying to understand the implications of
the protocols that we develop, not just working on the details of the
protocols.

Steve


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id LAA13710 for ietf-pkix-bks; Fri, 2 Apr 1999 11:54:36 -0800 (PST)
Received: from ns1.dmz.valicert.com (ns1.valicert.com [209.185.6.11]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id LAA13706 for <[e-mail]>; Fri, 2 Apr 1999 11:54:35 -0800 (PST)
Received: from ns1.serverfarm.valicert.com (corporate-gw.valicert.com [209.185.6.5]) by ns1.dmz.valicert.com (8.9.2/8.9.2) with ESMTP id LAA28956 for <[e-mail]>; Fri, 2 Apr 1999 11:54:14 -0800 (PST)
Received: from peternt (static-3-26.engineering.valicert.com [192.168.3.26] (may be forged)) by ns1.serverfarm.valicert.com (8.9.2/8.9.2) with SMTP id LAA16334 for <[e-mail]>; Fri, 2 Apr 1999 11:54:16 -0800 (PST)
Message-ID: <028001be7d32$7d7b1e10$[e-mail]>
From: "Peter Williams" <[e-mail]>
To: <[e-mail]>
Subject: policy oid registration, and handling
Date: Fri, 2 Apr 1999 11:59:01 -0600
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 V4.72.3110.3
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

"MISPC Reference Implementation (T. Polk-NIST)
CDROM contains CA, RA, and client executable code. Represents a profile of
2459, CMP, and CRMF. Available via web site: http://crscnist.gov/pki/mispc/"



A. MISPC

Can PKIX assign a cert-policy oid for this "MISPC" profile of RFC 2459,
which is a profile of X.509 (1997). It is not a PKIX WG
sponsored process, and does not meet spirit of IETF openness
to individuals, but MISPC was  a public-spirited  effort designed to
spur this industry on. It is generally recognised as meaningfull.


B. PKIX-QC OID

We agreed to assign a cert-policy oid for the PKIX-QC profile of
RFC 2459, in the last meeting, note. Can we assign an oid,
so implementations today can code for it, in their profile
management dll-switching code? (Note X.509 v3 did prior
assignment of extension oids, to help implementors, so there
is clear and relevant precedent.)


C. Registration Procedures

Should  procedure be created to enable any party to
use the pkix arc to register a profile of 2459, providing it meets
requirements such as posting of the specification
as an RFC (as with the PEM PCA rules)?

D. NIST Registration

I note NIST is also running an policy-id object id arc, figuratively
on behalf of ITU-T. Should PKIX-1 compliance require
folks to recognise this arc as authoritative, in a spur
towards making PKIX more real?

This NIST security objects register has very formal
and due process-oriented procedures for object (policy id) registration.
It could complement the less formal Internet decision procedures used
by IETF, and Russ (as the PKIX arc registrar).

E. Individual-Centric Registration

We need a mechanism whereby "individuals" can register and thereby share
policy oids in the devolved extensibility and user experimentation framework
which IETF and Internet culture normally promotes in its Internet standards.
Just as folk can register (informally these days) mime types, so
they should be able to register/obtain policy oids which are 2459 profiles.

Peter.





Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id JAA12797 for ietf-pkix-bks; Fri, 2 Apr 1999 09:47:51 -0800 (PST)
Received: from relay3.UU.NET (relay3.UU.NET [192.48.96.8]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id JAA12793 for <[e-mail]>; Fri, 2 Apr 1999 09:47:50 -0800 (PST)
Received: from xedia.com by relay3.UU.NET with SMTP  (peer crosschecked as: madway.xedia.com [198.202.232.199]) id QQgjfr03658; Fri, 2 Apr 1999 12:47:09 -0500 (EST)
Received: from tonga.xedia.com by xedia.com (4.1/SMI-4.1) id AA05527; Fri, 2 Apr 99 12:43:06 EST
Received: by tonga.xedia.com (SMI-8.6/SMI-SVR4) id MAA05955; Fri, 2 Apr 1999 12:47:05 -0500
Date: Fri, 2 Apr 1999 12:47:05 -0500
Message-Id: <[e-mail]>
From: Paul Koning <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
To: [e-mail]
Cc: [e-mail]
Subject: Re: Time-stamp server. TimePrecision info
References: <02a201be7cb2$dda47c80$c74bffd0@brick> <[e-mail]> <v04020a08b32aa018521c@[128.89.0.110]>
X-Mailer: VM 6.34 under 20.3 "Vatican City" XEmacs  Lucid
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

>>>>> "Stephen" == Stephen Kent <[e-mail]> writes:

 Stephen> Denis and Todd, Do we agree that the timestamp represents
 Stephen> the point at which a signature was applied, independent of
 Stephen> transmission delays and signing speed?  

It seems to me it can only possibly mean one thing: it is the time
when the clock was read.  :-)  That time is later than the generation
of the request and earlier than the generation of the signature.

 Stephen> If so, then I would
 Stephen> not agrue against very fine granularity time stamps on thae
 Stephen> basis of thise delays. Instead, I would argue that there is
 Stephen> a false sense of precision being implied, and that we're
 Stephen> better off just relying on the sequence number to serialize
 Stephen> time stamps issued by the same server within the same tick.

It sounds like you're arguing that only significant digits should be
present in the timestamp.  The problem with that is that the server
has no way to do that, if you want to include network delays as part
of the tolerance implied by the digit count.

Better to indicate or document the various error sources explicitly.
Those the server knows about it can report if a tolerance (precision)
field is added.  Those relating to network latency the server cannot
know but the client can (bounded by delay between request and
response).

 Stephen> If one believes that the time stamps have to represent finer
 Stephen> granularity because they will be compared with time stamps
 Stephen> from other servers, then there's a lot of work to do to
 Stephen> convince me that the resulting synchronization is feasible,
 Stephen> and that there is a legitimate need for such.  Obviously the
 Stephen> world lives with rather coarse precision and accuracy for
 Stephen> lots of business time stamp operations today.  maybe we need
 Stephen> some additional, credible, motivating examples.

Synchronization of two devices to within a fraction of a microsecond
is perfectly feasible today.  Any GPS nav box does exactly that.

Given that it costs nothing to allow the extra digits, why is there
such a concern about doing that and future-proofing things?

	paul


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id IAA12199 for ietf-pkix-bks; Fri, 2 Apr 1999 08:35:14 -0800 (PST)
Received: from po1.bbn.com (PO1.BBN.COM [192.1.50.38]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id IAA12195 for <[e-mail]>; Fri, 2 Apr 1999 08:35:13 -0800 (PST)
Received: from [128.89.0.110] (COSMEC.BBN.COM [128.89.0.110]) by po1.bbn.com (8.9.1/8.9.1) with ESMTP id LAA06324; Fri, 2 Apr 1999 11:35:26 -0500 (EST)
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
X-Sender: [e-mail]
Message-Id: <v04020a08b32aa018521c@[128.89.0.110]>
In-Reply-To: <[e-mail]>
References: <02a201be7cb2$dda47c80$c74bffd0@brick>
Date: Fri, 2 Apr 1999 11:32:08 -0500
To: Denis Pinkas <[e-mail]>, "Todd S. Glassey" <[e-mail]>
From: Stephen Kent <[e-mail]>
Subject: Re: Time-stamp server. TimePrecision info
Cc: [e-mail]
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Denis and Todd,

Do we agree that the timestamp represents the point at which a signature
was applied, independent of transmission delays and signing speed?  If so,
then I would not agrue against very fine granularity time stamps on thae
basis of thise delays. Instead, I would argue that there is a false sense
of precision being implied, and that we're better off just relying on the
sequence number to serialize time stamps issued by the same server within
the same tick.

If one believes that the time stamps have to represent finer granularity
because they will be compared with time stamps from other servers, then
there's a lot of work to do to convince me that the resulting
synchronization is feasible, and that there is a legitimate need for such.
Obviously the world lives with rather coarse precision and accuracy for
lots of business time stamp operations today.  maybe we need some
additional, credible, motivating examples.

Steve


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id IAA12193 for ietf-pkix-bks; Fri, 2 Apr 1999 08:35:11 -0800 (PST)
Received: from po1.bbn.com (PO1.BBN.COM [192.1.50.38]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id IAA12189 for <[e-mail]>; Fri, 2 Apr 1999 08:35:08 -0800 (PST)
Received: from [128.89.0.110] (COSMEC.BBN.COM [128.89.0.110]) by po1.bbn.com (8.9.1/8.9.1) with ESMTP id LAA06313 for <[e-mail]>; Fri, 2 Apr 1999 11:35:25 -0500 (EST)
Mime-Version: 1.0
Content-Type: multipart/alternative; boundary="============_-1289051352==_ma============"
X-Sender: [e-mail]
Message-Id: <v04020a07b32a998cc875@[128.89.0.110]>
Date: Fri, 2 Apr 1999 11:38:59 -0500
To: <[e-mail]>
From: Stephen Kent <[e-mail]>
Subject: minutes and revised charter
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

--============_-1289051352==_ma============
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

I want to thank those who provided feedback for both the meeting minutes
and the WG charter.  Both have been revised in accordance with these
comments.

I am happy to report that Jeff Schiller has approved the new WG charter.  I
will see about having it posted to the IETF web site.  I also will be
submitting the minutes to the IETF secretariat.  Several speakers have
kindly provided me with their slides, and I will accept other slide sets
for a week, before sending them off to the secretariat as well.

Below are the final meeting minutes, and the revised charter. (The charter
still is awaiting a few RFC numbers to be assigned.)

Thanks,

Steve
--------------------------
PKIX WG Meeting 3/17/99
Edited by Steve Kent (WG co-chair)

The PKIX WG met only once during the 44rd IETF and a approximately 200
individuals participated in these meetings.

The meeting began with a review of the status of all of the WG document,
presented by Warwick Ford, WG co-chair. The following text summarizes the
status of the documents:

PKIX COMPLETED DOCUMENTS

PKIX Cert/CRL Profile (RFC 2459)
		Approved as Proposed Standard
KEA Algorithms for Profile (RFC 2528)
		Approved as Informational RFC
HTTP/FTP Operations (draft-ietf-pkix-opp-ftp-http-04.txt)
		Approved as Proposed Standard
LDAP V2 Operational Protocols (draft-ietf-pkix-ipki2opp-08.txt)
		Approved as Proposed Standard
LDAP V2 Schema (draft-ietf-pkix-ldapv2-schema-01.txt)
		Approved as Proposed Standard
OCSP (draft-ietf-pkix-ocsp-05.txt)
		Approved as Proposed Standard
CMP (RFC 2510)
		Approved as Proposed Standard
CRMF (RFC 2511)
		Approved as Proposed Standard
Certificate Policy/Practices Guideline (RFC 2527)
		Approved as Informational RFC

PKIX WORK IN PROGRESS

ECDSA Algorithms for Profile (draft-ietf-pkix-ipki-ecdsa-01.txt)
		New draft to be issued for WG last call shortly
CMC (draft-ietf-pkix-cmc-02.txt)
		Under WG review
Diffie-Hellman POP (draft-ietf-pkix-dhpop-00.txt)
		Under WG review
Qualified Certificates (draft-ietf-santesson-qc-01.txt)
		Under WG review
CMMF (draft-ietf-pkix-cmmf-02.txt)
		This item to be dropped from the program
Time Stamp (draft-ietf-pkix-time-stamp-00.txt)
		Under WG review
DCS (draft-ietf-pkix-dcs-00.txt)
		Under WG review
Web-Based Integrated CA Services Protocol (draft-sakurai-pkix-icap-01.txt)
	Submitted for WG consideration

Reports on Established Projects:

A new WG charter was presented, in draft form, which shortly will be posted =
to
the mailing list.  The expanded charter encompasses attribute certificates,
time stamping and notarization services, and qualified certificates.


CMC and Diffie-Hellman POP (J. Schaad-Microsoft)
The CMC draft did not meet submission deadline, but was made available to th=
e
list.  The D-H POP draft is undergoing revision.  CMC has been revised to
accommodate comments from Carlisle from the last meeting. Additional changes
are planned, including removal of the key archival and recovery features, an=
d
clarification of RA operations.

PKIX Roadmap (A. Arsenault-NSA)
Missed submission deadline.  Undergoing revision to deal with terminology
inconsistencies, POP, adding a history of PKIX, new work items (e.g.,
qualified certificates and time stamping), explanation of name constraints f=
or
alt name forms, path validation, etc.

Qualified Certificates (S. Santesson)
Goals of qualified certificates were reviewed. The fundamental thrust of thi=
s
work is the development of a new SubjectAltName type, for "unmistakable
identity" ID information. Attribute semantics represents the top-level
structure for the SubjectaltName, making it clear what form of ID is being
provided, e.g., national ID card or driver license. Also, this extension wil=
l
contain a registration authority field, as required by German law.  A pointe=
r
to a web site for additional info was provided (http://www.accurata.se/QC/).
Suggestion was made to consider splitting this work into two document: one f=
or
the new name form, and another (informational?) to explain the context for
which this new name form was devised. However, to the extent that a qualifie=
d
certificate imposes  constraints on other certificate fields, it is not clea=
r

Data Certification and Time Stamping (R. Zuccherato-Entrust)
Data certification server I-D not recently updated, but will be soon, to
respond to comments, e.g., ASN.1 corrections and more explanatory text.  The
time stamping document also has not been updated recently, but will undergo
minor revisions, e.g., to allow for issuance of a time stamp without
submission of a hash.  Unfortunately, the topics of time stamping and data
certification are rife with intellectual property claims, which may interfer=
e
with progression of these documents.  Specifically, a lawsuit has been filed
by patent holders against a company that has implemented a prior version of
this protocol. The WG chairs will work with the authors of the documents to
help resolve these issues.


Other Topics:

Progressing RFC 2459 to Draft Status (T. Polk-NIST)
Collecting inputs for (mostly) minor corrections and clarifications to this
document in anticipation of progressing this work.

OCSP Clarification (S. Kent-BBN)
Two sections of OCSP will be revised to clarify what is required of complian=
t
clients and servers with respect to what keys can be used to sign OCSP
responses. Specifically, an OCSP response must be signed by either the CA wh=
o
issued the certificate in question, by an entity who has been explicitly
delegated this authority by that CA (through direct issuance and inclusion o=
f
a specified EKU extension), or by an entity who has been selected as
authoritative by the client. Compliant OCSP servers and clients MUST be able
to support all three of these options.(Satisfying the third option is largel=
y
trivial for the server, but requires a configuration capability for clients.=
)

Will End-Entity Certificates be Fat or Low Fat? (D. Pinkas-Bull)
Proposal to minimize the addition of extensions to EE certificates, by movin=
g
as much of this sort of information to CA certificates, from EE certificates=
=2E
Examples of such extension data are pointers to OCSP responders and CRL
servers, where applicable to all certificates issued by a CA.

Attribute Certificates	(S. Farrell-SSE)
A kickoff announcement of this new work item. Providing pointers to work on
attribute certificates for use with TLS, as an example.

OCSP Interoperability Testing	(A. Malparni-ValiCert)
Reported on tests of seven independent implementations.  All made use of HTT=
P
and direct, DER encoding (not base 64).  Discovered some problems, e.g., in
hash computation.

Server-based Certificate Validation (A. Malparni-ValiCert)
A suggestion to explore "outsourcing" certificate validation to a server, fr=
om
a client. Proposal is to develop a protocol between a client and the
validation server, which might be attractive when the client is not
computationally capable, or to help by centralizing administration of
certificate validation management. There are security concerns here, because
of the centralization of security function in servers.

MISPC Reference Implementation (T. Polk-NIST)
CDROM contains CA, RA, and client executable code. Represents a profile of
2459, CMP, and CRMF.  Available via web site: http://crscnist.gov/pki/mispc/

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

Internet standards needed to support an X.509-based PKI. Several
informational and standards track documents in support of the original
goals of the WG have been approved by the IESG. The first of these
standards, RFC 2459, profiles the X.509 version 3 certificates and version
2 CRLs for use in the Internet.  The Certificate Management Protocol (CMP)
(RFC 2510), the Online Certificate Status Protocol (OCSP) (RFC 2xxx), and
the Certificate Management Request Format (CRMF) (RFC 2511)  have been
approved, as have profiles for the use of LDAP v2 for certificate and CRL
storage (RFC 2xxx) and the use of FTP and HTTP for transport of PKI
operations (RFC 2xxx).  RFC 2527, an informational RFC on guidelines for
certificate policies and practices also has been published, and the IESG
has approved publication of an information RFC on use of KEA (RFC 2528) and
ECDSA (RFC 2xxx).  Work continues on a second certificate management
protocol, CMC, closely aligned with the PKCS publications and with the
cryptographic message syntax (CMS) developed for S/MIME.  A roadmap,
providing a guide to the growing set of PKIX document, is also being
developed as an informational RFC.

The working group is now embarking on additional standards work to develop
protocols that are either integral to PKI management, or that are otherwise
closely related to PKI use. Work is ongoing on alternative certificate
revocation methods. There also is work defining conventions for certificate
name forms and extension usage for "qualified certificates," certificates
designed for use in (legally binding) non-repudiation contexts. Finally,
work is underway on protocols for time stamping and data certification.
These protocol are designed to support non-repudiation, making use of
certificates and CRLs, and are so tightly bound to PKI use that they
warrant coverage under this working group.

Additional work will be initiated on a profile for X.509 attribute
certificates, resulting in a new RFC and, perhaps,  in extensions to
existing certificate management standards to accommodate differences
between attribute certificates and public-key certificates.

New Goals and Milestones:

 July 99
            Update RFC 2459, in anticipation of progression from PROPOSED
to DRAFT
Complete approval of CMC, qualified certificates, and time-stamp documents
Initiate work on attribute certificate profile.

 Dec 99
	Update March/April RFCs, for progress from PROPOSED to DRAFT
	Complete approval of data notarization document
Publish I-D for attribute certificate profile

March 00
	Complete work on attribute certificate profile

July 00
	Continue RFC updating process, =8A

--============_-1289051352==_ma============
Content-Type: text/enriched; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

I want to thank those who provided feedback for both the meeting
minutes and the WG charter.  Both have been revised in accordance with
these comments.


I am happy to report that Jeff Schiller has approved the new WG
charter.  I will see about having it posted to the IETF web site.  I
also will be submitting the minutes to the IETF secretariat.  Several
speakers have kindly provided me with their slides, and I will accept
other slide sets for a week, before sending them off to the secretariat
as well. =20


Below are the final meeting minutes, and the revised charter. (The
charter still is awaiting a few RFC numbers to be assigned.)


Thanks,


Steve

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

PKIX WG Meeting 3/17/99=20

Edited by Steve Kent (WG co-chair)


The PKIX WG met only once during the 44rd IETF and a approximately 200
individuals participated in these meetings.=20


The meeting began with a review of the status of all of the WG
document,=20

presented by Warwick Ford, WG co-chair. The following text summarizes
the=20

status of the documents:


PKIX COMPLETED DOCUMENTS


PKIX Cert/CRL Profile (RFC 2459)

		Approved as Proposed Standard

KEA Algorithms for Profile (RFC 2528)

		Approved as Informational RFC

HTTP/FTP Operations (draft-ietf-pkix-opp-ftp-http-04.txt)=20

		Approved as Proposed Standard

LDAP V2 Operational Protocols (draft-ietf-pkix-ipki2opp-08.txt)

		Approved as Proposed Standard

LDAP V2 Schema (draft-ietf-pkix-ldapv2-schema-01.txt)

		Approved as Proposed Standard

OCSP (draft-ietf-pkix-ocsp-05.txt)

		Approved as Proposed Standard

CMP (RFC 2510)

		Approved as Proposed Standard

CRMF (RFC 2511)

		Approved as Proposed Standard

Certificate Policy/Practices Guideline (RFC 2527)

		Approved as Informational RFC


PKIX WORK IN PROGRESS


ECDSA Algorithms for Profile (draft-ietf-pkix-ipki-ecdsa-01.txt)

		New draft to be issued for WG last call shortly

CMC (draft-ietf-pkix-cmc-02.txt)

		Under WG review

Diffie-Hellman POP (draft-ietf-pkix-dhpop-00.txt)

		Under WG review

Qualified Certificates (draft-ietf-santesson-qc-01.txt)

		Under WG review

CMMF (draft-ietf-pkix-cmmf-02.txt)

		This item to be dropped from the program=20

Time Stamp (draft-ietf-pkix-time-stamp-00.txt)=20

		Under WG review

DCS (draft-ietf-pkix-dcs-00.txt)

		Under WG review

Web-Based Integrated CA Services Protocol
(draft-sakurai-pkix-icap-01.txt)

	Submitted for WG consideration


Reports on Established Projects:


A new WG charter was presented, in draft form, which shortly will be
posted to=20

the mailing list.  The expanded charter encompasses attribute
certificates,=20

time stamping and notarization services, and qualified certificates.



CMC and Diffie-Hellman POP (J. Schaad-Microsoft)

The CMC draft did not meet submission deadline, but was made available
to the=20

list.  The D-H POP draft is undergoing revision.  CMC has been revised
to=20

accommodate comments from Carlisle from the last meeting. Additional
changes=20

are planned, including removal of the key archival and recovery
features, and=20

clarification of RA operations.=20


PKIX Roadmap (A. Arsenault-NSA)

Missed submission deadline.  Undergoing revision to deal with
terminology=20

inconsistencies, POP, adding a history of PKIX, new work items (e.g.,=20

qualified certificates and time stamping), explanation of name
constraints for=20

alt name forms, path validation, etc.


Qualified Certificates (S. Santesson)

Goals of qualified certificates were reviewed. The fundamental thrust
of this=20

work is the development of a new SubjectAltName type, for "unmistakable

identity" ID information. Attribute semantics represents the top-level

structure for the SubjectaltName, making it clear what form of ID is
being=20

provided, e.g., national ID card or driver license. Also, this
extension will=20

contain a registration authority field, as required by German law.  A
pointer=20

to a web site for additional info was provided
(http://www.accurata.se/QC/).=20

Suggestion was made to consider splitting this work into two document:
one for=20

the new name form, and another (informational?) to explain the context
for=20

which this new name form was devised. However, to the extent that a
qualified=20

certificate imposes  constraints on other certificate fields, it is not
clear


Data Certification and Time Stamping (R. Zuccherato-Entrust)

Data certification server I-D not recently updated, but will be soon,
to=20

respond to comments, e.g., ASN.1 corrections and more explanatory text.
 The=20

time stamping document also has not been updated recently, but will
undergo=20

minor revisions, e.g., to allow for issuance of a time stamp without=20

submission of a hash.  Unfortunately, the topics of time stamping and
data=20

certification are rife with intellectual property claims, which may
interfere=20

with progression of these documents.  Specifically, a lawsuit has been
filed=20

by patent holders against a company that has implemented a prior
version of=20

this protocol. The WG chairs will work with the authors of the
documents to=20

help resolve these issues.



Other Topics:


Progressing RFC 2459 to Draft Status (T. Polk-NIST)

Collecting inputs for (mostly) minor corrections and clarifications to
this=20

document in anticipation of progressing this work.


OCSP Clarification (S. Kent-BBN)

Two sections of OCSP will be revised to clarify what is required of
compliant=20

clients and servers with respect to what keys can be used to sign OCSP

responses. Specifically, an OCSP response must be signed by either the
CA who=20

issued the certificate in question, by an entity who has been
explicitly=20

delegated this authority by that CA (through direct issuance and
inclusion of=20

a specified EKU extension), or by an entity who has been selected as=20

authoritative by the client. Compliant OCSP servers and clients MUST be
able=20

to support all three of these options.(Satisfying the third option is
largely=20

trivial for the server, but requires a configuration capability for
clients.)


Will End-Entity Certificates be Fat or Low Fat? (D. Pinkas-Bull)

Proposal to minimize the addition of extensions to EE certificates, by
moving=20

as much of this sort of information to CA certificates, from EE
certificates.=20

Examples of such extension data are pointers to OCSP responders and CRL

servers, where applicable to all certificates issued by a CA.


Attribute Certificates	(S. Farrell-SSE)

A kickoff announcement of this new work item. Providing pointers to
work on=20

attribute certificates for use with TLS, as an example.


OCSP Interoperability Testing	(A. Malparni-ValiCert)

Reported on tests of seven independent implementations.  All made use
of HTTP=20

and direct, DER encoding (not base 64).  Discovered some problems,
e.g., in=20

hash computation. =20


Server-based Certificate Validation (A. Malparni-ValiCert)

A suggestion to explore "outsourcing" certificate validation to a
server, from=20

a client. Proposal is to develop a protocol between a client and the=20

validation server, which might be attractive when the client is not=20

computationally capable, or to help by centralizing administration of=20

certificate validation management. There are security concerns here,
because=20

of the centralization of security function in servers.=20


MISPC Reference Implementation (T. Polk-NIST)

CDROM contains CA, RA, and client executable code. Represents a profile
of=20

2459, CMP, and CRMF.  Available via web site:
http://crscnist.gov/pki/mispc/


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


<fontfamily><param>Times</param><bigger><bigger>Internet standards
needed to support an X.509-based PKI. Several informational and
standards track documents in support of the original goals of the WG
have been approved by the IESG. The first of these standards, RFC 2459,
profiles the X.509 version 3 certificates and version 2 CRLs for use in
the Internet.  The Certificate Management Protocol (CMP) (RFC 2510),
the Online Certificate Status Protocol (OCSP) (RFC 2xxx), and the
Certificate Management Request Format (CRMF) (RFC 2511)  have been
approved, as have profiles for the use of LDAP v2 for certificate and
CRL storage (RFC 2xxx) and the use of FTP and HTTP for transport of PKI
operations (RFC 2xxx).  RFC 2527, an informational RFC on guidelines
for certificate policies and practices also has been published, and the
IESG has approved publication of an information RFC on use of KEA (RFC
2528) and ECDSA (RFC 2xxx).  Work continues on a second certificate
management protocol, CMC, closely aligned with the PKCS publications
and with the cryptographic message syntax (CMS) developed for S/MIME.=20
A roadmap, providing a guide to the growing set of PKIX document, is
also being developed as an informational RFC.


The working group is now embarking on additional standards work to
develop protocols that are either integral to PKI management, or that
are otherwise closely related to PKI use. Work is ongoing on
alternative certificate revocation methods. There also is work defining
conventions for certificate name forms and extension usage for
"qualified certificates," certificates designed for use in (legally
binding) non-repudiation contexts. Finally, work is underway on
protocols for time stamping and data certification. These protocol are
designed to support non-repudiation, making use of certificates and
CRLs, and are so tightly bound to PKI use that they warrant coverage
under this working group.=20


Additional work will be initiated on a profile for X.509 attribute
certificates, resulting in a new RFC and, perhaps,  in extensions to
existing certificate management standards to accommodate differences
between attribute certificates and public-key certificates.

=20

New Goals and Milestones:


 July 99

            Update RFC 2459, in anticipation of progression from
PROPOSED to DRAFT

Complete approval of CMC, qualified certificates, and time-stamp
documents

Initiate work on attribute certificate profile.

=20

 Dec 99

	Update March/April RFCs, for progress from PROPOSED to DRAFT

	Complete approval of data notarization document

Publish I-D for attribute certificate profile


March 00

	Complete work on attribute certificate profile


July 00

	Continue RFC updating process, =8A=20
</bigger></bigger></fontfamily>

--============_-1289051352==_ma============--


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id HAA11605 for ietf-pkix-bks; Fri, 2 Apr 1999 07:32:01 -0800 (PST)
Received: from relay2.UU.NET (relay2.UU.NET [192.48.96.7]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id HAA11601 for <[e-mail]>; Fri, 2 Apr 1999 07:32:00 -0800 (PST)
Received: from xedia.com by relay2.UU.NET with SMTP  (peer crosschecked as: madway.xedia.com [198.202.232.199]) id QQgjfi17285; Fri, 2 Apr 1999 10:31:17 -0500 (EST)
Received: from tonga.xedia.com by xedia.com (4.1/SMI-4.1) id AA03051; Fri, 2 Apr 99 10:27:13 EST
Received: by tonga.xedia.com (SMI-8.6/SMI-SVR4) id KAA05851; Fri, 2 Apr 1999 10:31:12 -0500
Date: Fri, 2 Apr 1999 10:31:12 -0500
Message-Id: <[e-mail]>
From: Paul Koning <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
To: [e-mail]
Cc: [e-mail]
Subject: Re: Time-stamp server. TimePrecision info
References: <02a201be7cb2$dda47c80$c74bffd0@brick> <[e-mail]>
X-Mailer: VM 6.34 under 20.3 "Vatican City" XEmacs  Lucid
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

>>>>> "Denis" == Denis Pinkas <[e-mail]> writes:

 Denis> Todd S. Glassey said:

 >>  >That said, I agree with Denis.  I do not see the use
 >> of microseconds to be >especially useful within this protocol.
 >> 
 >> OK Fine, but humor me - what's the harm in being able to represent
 >> them?

 Denis> The TSA gets the clock first and then signs. I do not know any
 Denis> hardware capable of signature in the micro-second range. The
 Denis> transmission delay is also quite variable. The harm is giving
 Denis> false impression of precision.

You just made an excellent argument for a precision field.  The
alternative is to infer it from the number of digits in the timestamp
itself, which is a kludge to say the least.  (For example, if you have 
a precision, or I would prefer to call it "tolerance" of +/- 10s,
would you omit the units digit of the seconds field?  That would be
correct but also very confusing.)

Transmission delay may or may not be variable depending on the channel 
used.  Signing may take more than a millisecond (or it may not; you
can buy chips today that will do it in 2 or 3, so you'll be able to do 
it in under a millisecond in a year or two).

But it's not a good idea to design the sizes of protocol fields so
they are just barely large enough for today's technology.  IPv4 at
least used 4 bytes rather than the 2 they would have used for host
addresses if they had used that approach.  A half dozen extra bytes
costs nothing, especially considering the size of a signature.  Better 
to future-proof the protocol by going AT LEAST down to microseconds,
or alternatively making the number of fractional seconds digits
unconstrained.

	paul


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id CAA06187 for ietf-pkix-bks; Fri, 2 Apr 1999 02:35:27 -0800 (PST)
Received: from edelweb.fr (edelweb.fr [193.51.12.16]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id CAA06182 for <[e-mail]>; Fri, 2 Apr 1999 02:35:25 -0800 (PST)
Received: from champagne.edelweb.fr (localhost.edelweb.fr [127.0.0.1]) by edelweb.fr with ESMTP id MAA11129; Fri, 2 Apr 1999 12:35:24 +0200 (MET DST)
Received: from champagne.edelweb.fr (champagne.edelweb.fr [193.51.14.161]) by edelweb.fr (nospam/1.1); Fri, 2 Apr 1999 12:35:23 +0200 (MET DST)
Received: from emeriau.edelweb.fr (emeriau.edelweb.fr [193.51.14.5]) by champagne.edelweb.fr (8.6.10/8.6.6) with ESMTP id MAA10405; Fri, 2 Apr 1999 12:35:22 +0200
From: Peter Sylvester <[e-mail]>
Received: (sylvest@localhost) by emeriau.edelweb.fr (8.6.10/8.6.6) id MAA00678; Fri, 2 Apr 1999 12:35:22 +0200
Date: Fri, 2 Apr 1999 12:35:22 +0200
Message-Id: <[e-mail]>
To: [e-mail], [e-mail], [e-mail]
Subject: Re: R: 3 Time Stamping issues
Cc: [e-mail]
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

A similar problem exists in dcs. 

And more: 

In dcs  
     dcsReqInfo                DCSReqInfo,
       --MUST be the same value as the dcsReqInfo field in DCSReqData
     messageImprint               MessageImprint,
       --if the data field in DCSReqData is MessageImprint, this
       --MUST contain that same value, otherwise it contains a hash of
       --the data field in DCSReqData using the hash algorithm
       --specified in the digestAlgorithm parameter of SignerInfo in 
       --the data certification token

are not optional, if the responder wants to signal some encoding error
in the request, there is a problem.

> 
> I have a different doubt about the protocol:
> 
> the TSTInfo structure includes a status field with PKIStatusInfo syntax. I
> understand that the TSA could signal to the requestor (ie the client) the
> unavailability of a time source by using the valure 15 (tdaNotAvailable) for
> the failInfo field (with syntax PKIFailureInfo) of the TSTInfo status field.
> However, if the TSA has no reliable time source available, it should not
> issue a time value at all, right? Nontheless, the tstTime field of the
> TSTInfo structure is not OPTIONAL. So, it must carry some value, somehow.
> 
> The question, then, is: what time value should be put in the (mandatory)
> tstTime field when the TSA signals an error?
> 
> The same reasoning applies to other error condition which (should) prevent
> the TSA from issuing a time indication.
> 
> Adriano
> 
> > -----Messaggio originale-----
> > Da:	Denis Pinkas [SMTP:[e-mail]]
> > Inviato:	giovedì 1 aprile 1999 17.59
> > A:	IETF-PXIX
> > Oggetto:	3 Time Stamping issues
> > 
> > Since I am a co-editor of the Time Stamping document, I would like
> > to give my opinion on the various issues raised on the mailing list.
> > 
> > 1. There has been a suggestion to possibly improve the resolution to
> > microseconds from milliseconds.
> > 
> > Since the delay in the transmission is at least in the millisecond
> > order, having something more precise would give a false degree of
> > precision. I would not go under the millisesond.
> > 
> > 2. There has been a suggestion to possibly add a precision field.
> > 
> > I do not think this is absolutely necessary. So I am not supportive
> > of it since the policy can handle this.
> > 
> > 3. There has been a suggestion to possibly add a message information
> > field.
> > 
> > I have arguments *against* this idea. I would realy like to keep the
> > TSA as much ignorant as possible of the purpose of the Time
> > Stamping. If we add that information, the TSA could know "Invoice
> > from Alpha company to Delta company". Is
> > this way the TSA could learn that the Delta company is doing
> > commerce with the Delta company. This may that be a nice point to
> > spy. So I am against the inclusion of that aditional information.
> > 
> > However, ... I understand the concern of the linkeage and I would
> > propose an alternative:
> > 
> > Defining a Time Stamping Token (TST) that would be able to include
> > that information. Basically the TST would be the concatenation of
> > the "message information field" and of the signed portion of the
> > information received. The TST would be constructed locally instead
> > of being fully constructed by the TSA. We could define its structure
> > in a normative annex.
> > 
> > Regards,
> > 
> > Denis
> 


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id BAA03701 for ietf-pkix-bks; Fri, 2 Apr 1999 01:44:54 -0800 (PST)
Received: from edelweb.fr (edelweb.fr [193.51.12.16]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id BAA03697 for <[e-mail]>; Fri, 2 Apr 1999 01:44:52 -0800 (PST)
Received: from champagne.edelweb.fr (localhost.edelweb.fr [127.0.0.1]) by edelweb.fr with ESMTP id LAA07985; Fri, 2 Apr 1999 11:45:07 +0200 (MET DST)
Received: from champagne.edelweb.fr (champagne.edelweb.fr [193.51.14.161]) by edelweb.fr (nospam/1.1); Fri, 2 Apr 1999 11:45:06 +0200 (MET DST)
Received: from emeriau.edelweb.fr (emeriau.edelweb.fr [193.51.14.5]) by champagne.edelweb.fr (8.6.10/8.6.6) with ESMTP id LAA09674; Fri, 2 Apr 1999 11:45:05 +0200
From: Peter Sylvester <[e-mail]>
Received: (sylvest@localhost) by emeriau.edelweb.fr (8.6.10/8.6.6) id LAA00659; Fri, 2 Apr 1999 11:45:05 +0200
Date: Fri, 2 Apr 1999 11:45:05 +0200
Message-Id: <[e-mail]>
To: [e-mail], [e-mail]
Subject: Re: 3 Time Stamping issues
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

It seems to me that we are handling different things:

- A requester of a time stamp may want to have an indication
  somewhere that allows to correlate a response with a request.

  For the actual time stamping proposal I do not see why the
  requester could not simply use the message imprint itself.
  (If the hash is not collision free, the requester already has
  another problem.)

  For the DCS draft there may be a problem because it is the
  DCS server that decides to create a messageImprint from the
  given data, and the current text proposes the DCS responder
  to choose the hash. One might change this and say, that the
  reponder takes (one of) the digest function used during signing
  the request. 

- A requester wants to carry whatever kind of pointer to the real
  data. One might debate about the usage, in any case I am not
  sure whether an opaque octet string is the right solution. 
  The type of the data should probably be indicated by an OID. 

> 
> 3. There has been a suggestion to possibly add a message information
> field.
> 
> I have arguments *against* this idea. I would realy like to keep the
> TSA as much ignorant as possible of the purpose of the Time
> Stamping. If we add that information, the TSA could know "Invoice
> from Alpha company to Delta company". Is
> this way the TSA could learn that the Delta company is doing
> commerce with the Delta company. This may that be a nice point to
> spy. So I am against the inclusion of that aditional information.

I agree (contrary to what I have said a few hours ago.)  ;-)

> 
> However, ... I understand the concern of the linkeage and I would
> propose an alternative:
> 
> Defining a Time Stamping Token (TST) that would be able to include
> that information. Basically the TST would be the concatenation of
> the "message information field" and of the signed portion of the
> information received. The TST would be constructed locally instead
> of being fully constructed by the TSA. We could define its structure
> in a normative annex.
The actual Timestamp token is a cms signed data object;
the requester always has the possibility to add an
unsignedattribute to the SignerInfo of the response. 



Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id AAA00793 for ietf-pkix-bks; Fri, 2 Apr 1999 00:40:10 -0800 (PST)
Received: from ntsiaexch.office (exchange.sia.it [192.106.192.201]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id AAA00665 for <[e-mail]>; Fri, 2 Apr 1999 00:36:25 -0800 (PST)
Received: by ntsiaexch.office with Internet Mail Service (5.5.2232.9) id <2DXF6XD9>; Fri, 2 Apr 1999 10:35:03 +0200
Message-ID: <[e-mail]>
From: Santoni Adriano <[e-mail]>
To: "'Denis Pinkas'" <[e-mail]>, "'Robert Zuccherato'" <[e-mail]>
Cc: IETF-PXIX <[e-mail]>
Subject: R: 3 Time Stamping issues
Date: Fri, 2 Apr 1999 10:35:02 +0200 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2232.9)
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by mail.proper.com id AAA00790
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

I have a different doubt about the protocol:

the TSTInfo structure includes a status field with PKIStatusInfo syntax. I
understand that the TSA could signal to the requestor (ie the client) the
unavailability of a time source by using the valure 15 (tdaNotAvailable) for
the failInfo field (with syntax PKIFailureInfo) of the TSTInfo status field.
However, if the TSA has no reliable time source available, it should not
issue a time value at all, right? Nontheless, the tstTime field of the
TSTInfo structure is not OPTIONAL. So, it must carry some value, somehow.

The question, then, is: what time value should be put in the (mandatory)
tstTime field when the TSA signals an error?

The same reasoning applies to other error condition which (should) prevent
the TSA from issuing a time indication.

Adriano

> -----Messaggio originale-----
> Da:	Denis Pinkas [SMTP:[e-mail]]
> Inviato:	giovedì 1 aprile 1999 17.59
> A:	IETF-PXIX
> Oggetto:	3 Time Stamping issues
> 
> Since I am a co-editor of the Time Stamping document, I would like
> to give my opinion on the various issues raised on the mailing list.
> 
> 1. There has been a suggestion to possibly improve the resolution to
> microseconds from milliseconds.
> 
> Since the delay in the transmission is at least in the millisecond
> order, having something more precise would give a false degree of
> precision. I would not go under the millisesond.
> 
> 2. There has been a suggestion to possibly add a precision field.
> 
> I do not think this is absolutely necessary. So I am not supportive
> of it since the policy can handle this.
> 
> 3. There has been a suggestion to possibly add a message information
> field.
> 
> I have arguments *against* this idea. I would realy like to keep the
> TSA as much ignorant as possible of the purpose of the Time
> Stamping. If we add that information, the TSA could know "Invoice
> from Alpha company to Delta company". Is
> this way the TSA could learn that the Delta company is doing
> commerce with the Delta company. This may that be a nice point to
> spy. So I am against the inclusion of that aditional information.
> 
> However, ... I understand the concern of the linkeage and I would
> propose an alternative:
> 
> Defining a Time Stamping Token (TST) that would be able to include
> that information. Basically the TST would be the concatenation of
> the "message information field" and of the signed portion of the
> information received. The TST would be constructed locally instead
> of being fully constructed by the TSA. We could define its structure
> in a normative annex.
> 
> Regards,
> 
> Denis


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id AAA00269 for ietf-pkix-bks; Fri, 2 Apr 1999 00:27:40 -0800 (PST)
Received: from clbull.frcl.bull.fr (clbull.frcl.bull.fr [129.182.1.20]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id AAA00253 for <[e-mail]>; Fri, 2 Apr 1999 00:27:35 -0800 (PST)
Received: from k2.frcl.bull.fr (k2.frcl.bull.fr [129.182.100.2]) by clbull.frcl.bull.fr (8.9.1a/8.9.1) with ESMTP id KAA15456; Fri, 2 Apr 1999 10:27:22 +0100
Received: from bull.net (frcls6118.frcl.bull.fr [129.182.109.213]) by k2.frcl.bull.fr (AIX4.2/UCB 8.7/8.7) with ESMTP id KAA25354; Fri, 2 Apr 1999 10:28:23 +0100 (NFT)
Message-ID: <[e-mail]>
Date: Fri, 02 Apr 1999 10:28:06 +0200
From: Denis Pinkas <[e-mail]>
Organization: Bull
X-Mailer: Mozilla 4.06 [fr] (Win95; I)
MIME-Version: 1.0
To: "Todd S. Glassey" <[e-mail]>
CC: Robert Zuccherato <[e-mail]>, [e-mail], "'Paul Koning'" <[e-mail]>, [e-mail]
Subject: Re: Time-stamp server. TimePrecision info
References: <02a201be7cb2$dda47c80$c74bffd0@brick>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Todd S. Glassey said:

> -----Original Message-----
> From: Robert Zuccherato <[e-mail]>
> To: [e-mail] <[e-mail]>; 'Paul Koning'
> <[e-mail]>
> Cc: [e-mail] <[e-mail]>
> Date: Thursday, April 01, 1999 10:59 AM
> Subject: RE: Time-stamp server. TimePrecision info
>
> >One point that I would like to clear up.  The present timestamping draft
> >does not consider resolution of hours to be sufficient.  The reference to
> >resolution of "less than a few hours" comes from an informative annex
> giving
> >an example of how the protocol could be used.  The resolution required by
> >any particular application is not considered in the main document.
> Remember
> >this document describes just the protocol to be used by the TSA.
> >
> >That said, I agree with Denis.  I do not see the use of microseconds to be
> >especially useful within this protocol.
>
> OK Fine, but humor me - what's the harm in being able to represent them?

 The TSA gets the clock first and then signs. I do not know any hardware
capable of signature in the micro-second range. The transmission delay is also
quite variable. The harm is giving false impression of precision.

Denis

>
> Todd
>
> SNIP---



Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id SAA07163 for ietf-pkix-bks; Thu, 1 Apr 1999 18:49:43 -0800 (PST)
Received: from gmtsw.com (test.glassey.com [207.126.98.130] (may be forged)) by mail.proper.com (8.8.8/8.8.5) with SMTP id SAA07159 for <[e-mail]>; Thu, 1 Apr 1999 18:49:42 -0800 (PST)
Received: from brick by gmtsw.com (SMI-8.6/SMI-SVR4) id SAA12379; Thu, 1 Apr 1999 18:50:02 -0800
Message-ID: <02a201be7cb2$dda47c80$c74bffd0@brick>
From: "Todd S. Glassey" <[e-mail]>
To: "Robert Zuccherato" <[e-mail]>, <[e-mail]>, "'Paul Koning'" <[e-mail]>
Cc: <[e-mail]>
Subject: Re: Time-stamp server. TimePrecision info
Date: Thu, 1 Apr 1999 18:45:25 -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 4.72.3110.5
X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

-----Original Message-----
From: Robert Zuccherato <[e-mail]>
To: [e-mail] <[e-mail]>; 'Paul Koning'
<[e-mail]>
Cc: [e-mail] <[e-mail]>
Date: Thursday, April 01, 1999 10:59 AM
Subject: RE: Time-stamp server. TimePrecision info


>One point that I would like to clear up.  The present timestamping draft
>does not consider resolution of hours to be sufficient.  The reference to
>resolution of "less than a few hours" comes from an informative annex
giving
>an example of how the protocol could be used.  The resolution required by
>any particular application is not considered in the main document.
Remember
>this document describes just the protocol to be used by the TSA.
>
>That said, I agree with Denis.  I do not see the use of microseconds to be
>especially useful within this protocol.

OK Fine, but humor me - what's the harm in being able to represent them?

Todd

SNIP---




Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id QAA05123 for ietf-pkix-bks; Thu, 1 Apr 1999 16:06:29 -0800 (PST)
Received: from gmtsw.com (test.glassey.com [207.126.98.130] (may be forged)) by mail.proper.com (8.8.8/8.8.5) with SMTP id QAA05119 for <[e-mail]>; Thu, 1 Apr 1999 16:06:28 -0800 (PST)
Received: from brick by gmtsw.com (SMI-8.6/SMI-SVR4) id QAA12318; Thu, 1 Apr 1999 16:06:52 -0800
Message-ID: <026201be7c9c$12b9c720$c74bffd0@brick>
From: "Todd S. Glassey" <[e-mail]>
To: "Denis Pinkas" <[e-mail]>, "IETF PKIX" <[e-mail]>
Subject: Re: 3 Time Stamping issues
Date: Thu, 1 Apr 1999 16:02:16 -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 4.72.3110.5
X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Denis, -


SNIP ---

>
>1. There has been a suggestion to possibly improve the resolution to
>microseconds from milliseconds.
>
>Since the delay in the transmission is at least in the millisecond
>order, having something more precise would give a false degree of
>precision. I would not go under the millisesond.

This assumes that you use a SW only model from today's commercially
available equipment at the PC level. Anyone that needs a more reliable or
finer granularity timesource can get a HW module from Datum or any of the
other time board providers. Commercial computing has used IRIG-B and other
timebase distribution protocols in time dependent networking apps for years.

Limiting ourselves to a millisecond is probably ok for the next year or two,
but microseconds are coming so why not use a large enough data structure to
handle these eventualities?

>
>2. There has been a suggestion to possibly add a precision field.
>
>I do not think this is absolutely necessary. So I am not supportive
>of it since the policy can handle this.

No - absolutely there needs to be a precision field for comparison purposes
and as part of the policy control infrastructure.

>
>3. There has been a suggestion to possibly add a message information
>field.
>
>I have arguments *against* this idea. I would realy like to keep the
>TSA as much ignorant as possible of the purpose of the Time
>Stamping. If we add that information, the TSA could know "Invoice
>from Alpha company to Delta company".

I agree that the current protocol tools are probably ok without the message
information *as long as we do the token strures*

>Is this way the TSA could learn that the Delta company is doing
>commerce with the Delta company. This may that be a nice point to
>spy. So I am against the inclusion of that aditional information.
>
>However, ... I understand the concern of the linkeage and I would
>propose an alternative:
>
>Defining a Time Stamping Token (TST) that would be able to include
>that information. Basically the TST would be the concatenation of
>the "message information field" and of the signed portion of the
>information received. The TST would be constructed locally instead
>of being fully constructed by the TSA. We could define its structure
>in a normative annex.

Yes, we should have a TST draft to submit on our GeoPositional Token by the
end of the weekend. Stay Tuned.


Todd




Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id NAA03614 for ietf-pkix-bks; Thu, 1 Apr 1999 13:34:16 -0800 (PST)
Received: from out2.ibm.net (out2.ibm.net [165.87.194.229]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id NAA03610 for <[e-mail]>; Thu, 1 Apr 1999 13:34:15 -0800 (PST)
Received: from dell-450-nt (slip-32-100-84-130.ny.us.ibm.net [32.100.84.130]) by out2.ibm.net (8.8.5/8.6.9) with SMTP id VAA59048; Thu, 1 Apr 1999 21:34:07 GMT
Message-ID: <006901be7c87$e9eb3e50$[e-mail]>
From: "Robert Klerer" <[e-mail]>
To: "Paul Halliden" <[e-mail]>, "'Paul Koning'" <[e-mail]>
Cc: <[e-mail]>
Subject: Re: Time-stamp server. TimePrecision info
Date: Thu, 1 Apr 1999 16:36:23 -0500
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 V4.72.3110.3
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Sequencing can be important.  It is correctly stated that establishing
precise sequencing across servers may not be achievable, but if a
non-arbitrary ordering needs to be established, the availability of
sequencing on a single server can be useful.  (Whose bid got in first at the
sellers choice of server).  If the loser losses because of latency, they
should buy a better network service.

-----Original Message-----
From: Paul Halliden <[e-mail]>
To: 'Paul Koning' <[e-mail]>
Cc: [e-mail] <[e-mail]>
Date: Thursday, April 01, 1999 1:15 PM
Subject: RE: Time-stamp server. TimePrecision info


>
>
>I quite agree that hours may not be close enough in some cases. The point
>is
>that the spec specifically talks about a range of communication techniques
>between requester and TSS including e-mail which has a notoriously variable
>transit time.  The timestamp gives no indication about how long the
>requester's message took to get to the timestamp authority.  Even if it
>did,
>I don't believe that the authority would be in any position to know
>reliably
>at what time the request was made.  Thus anyone who relies on a sequence of
>timestamps to indicate order is deluding themselves if they want precision
>anywhere near the transit time of the network(s) used. I would expect the
>timestamp authority's policy to say its service was unsuited for such
>precise sequencing and that some other technique for establishing the
>sequence of transactions should be used.
>
>Paul
>
>
>
>-----Original Message-----
>From: Paul Koning [mailto:[e-mail]]
>Sent: 01 April 1999 17:05
>To: [e-mail]
>Cc: [e-mail]
>Subject: RE: Time-stamp server. TimePrecision info
>
>
>I suspect that "close enough" may change over time, and hours may not
>be good enough.  For example, the required accuracy for timestamps on
>stock trading messages is more likely to be minutes rather than hours
>even today.
>
>In any case, it helps to be consistent.  If hours or even minutes is
>the outer limit of resolution needed, them milliseconds have no place
>in the timestamp format.
>
>As for establishing order by having a second document include the
>older timestamp of the first document, that's fine if I generate both
>documents.  If the dispute is on which of the two of us generated our
>document first, then we'll be dealing with two independent timestamps
>presumably from different servers.  If they aren't synchronized to UTC
>any better than hours, the service will not be useful in a number of
>interesting cases.
>
>Finally: it's a bad idea to make the specs tighter than what is
>achievable, but it also doesn't make a whole lot of sense to make them
>4 orders of magnitude looser.  Synchronizing to UTC to within a
>fraction of a second is easy, and network round trip times are in the
>range of seconds (actually, often way smaller than that).  Yes, that
>opens the question of how you handle leap seconds.  One solution is to
>loosen things up some more, but going from seconds to hours is really
>not necessary.
>
>        paul
>
> - att-1.htm



Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id JAA01219 for ietf-pkix-bks; Thu, 1 Apr 1999 09:30:35 -0800 (PST)
Received: from relay2.UU.NET (relay2.UU.NET [192.48.96.7]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id JAA01215 for <[e-mail]>; Thu, 1 Apr 1999 09:30:34 -0800 (PST)
Received: from xedia.com by relay2.UU.NET with SMTP  (peer crosschecked as: madway.xedia.com [198.202.232.199]) id QQgjby09683; Thu, 1 Apr 1999 12:30:10 -0500 (EST)
Received: from tonga.xedia.com by xedia.com (4.1/SMI-4.1) id AA18901; Thu, 1 Apr 99 12:26:03 EST
Received: by tonga.xedia.com (SMI-8.6/SMI-SVR4) id MAA04356; Thu, 1 Apr 1999 12:30:01 -0500
Date: Thu, 1 Apr 1999 12:30:01 -0500
Message-Id: <[e-mail]>
From: Paul Koning <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
To: [e-mail]
Cc: [e-mail]
Subject: Re: 3 Time Stamping issues
References: <[e-mail]>
X-Mailer: VM 6.34 under 20.3 "Vatican City" XEmacs  Lucid
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

>>>>> "Denis" == Denis Pinkas <[e-mail]> writes:

 Denis> 2. There has been a suggestion to possibly add a precision
 Denis> field.

 Denis> I do not think this is absolutely necessary. So I am not
 Denis> supportive of it since the policy can handle this.

I would think the policy describes things that are more or less
constant, certainly not things that are changing from hour to hour.
But the precision of the timestamp (how closely it agrees with UTC) is 
a dynamic variable.  If your authoritative time source (e.g., GPS) is
working, you're synchronized to a small fraction of a second.  If you
lose the signal, your precision degrades at, typically, about 10^-4,
i.e., 86 seconds per day.

If your policy reports a rather loose synchronization you can use the
policy approach (simply go off-line when sync has been lost for too
long).  But if you want to claim, say, 100 ms tolerance, but want to
be able to keep operating even if the external clock is lost for more
than 16 minutes, the precision field in the timestamp is useful.

	paul


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id JAA01199 for ietf-pkix-bks; Thu, 1 Apr 1999 09:29:00 -0800 (PST)
Received: from relay2.UU.NET (relay2.UU.NET [192.48.96.7]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id JAA01195 for <[e-mail]>; Thu, 1 Apr 1999 09:28:59 -0800 (PST)
Received: from xedia.com by relay2.UU.NET with SMTP  (peer crosschecked as: madway.xedia.com [198.202.232.199]) id QQgjbx07624; Thu, 1 Apr 1999 12:25:43 -0500 (EST)
Received: from tonga.xedia.com by xedia.com (4.1/SMI-4.1) id AA18837; Thu, 1 Apr 99 12:21:36 EST
Received: by tonga.xedia.com (SMI-8.6/SMI-SVR4) id MAA04354; Thu, 1 Apr 1999 12:25:34 -0500
Date: Thu, 1 Apr 1999 12:25:34 -0500
Message-Id: <[e-mail]>
From: Paul Koning <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
To: [e-mail]
Cc: [e-mail]
Subject: RE: Time-stamp server. TimePrecision info
References: <[e-mail]>
X-Mailer: VM 6.34 under 20.3 "Vatican City" XEmacs  Lucid
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

>> Paul Halliden wrote:
> I quite agree that hours may not be close enough in some cases. The point is
> that the spec specifically talks about a range of communication techniques
> between requester and TSS including e-mail which has a notoriously variable
> transit time.  The timestamp gives no indication about how long the
> requester's message took to get to the timestamp authority.  Even if it did,
> I don't believe that the authority would be in any position to know reliably
> at what time the request was made.  Thus anyone who relies on a sequence of
> timestamps to indicate order is deluding themselves if they want precision
> anywhere near the transit time of the network(s) used. I would expect the
> timestamp authority's policy to say its service was unsuited for such
> precise sequencing and that some other technique for establishing the
> sequence of transactions should be used.

I don't see that the transport matters.

No matter what transport you use, the only thing the timestamp tells
you is the time at which the server generated the stamp.  The
requester obviously issued the request before that, but you cannot
know how much before that.

Similarly, a sequence of timestamps shows sequence of timestamping,
not sequence of request generation.

If I need a timestamp to show that I did X by time Y, I'd use a
transport with low enough latency to meet my needs.  What that latency 
is, is a decision I have to make, but it doesn't matter to the server.

	paul


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id JAA01116 for ietf-pkix-bks; Thu, 1 Apr 1999 09:17:13 -0800 (PST)
Received: from gmtsw.com (test.glassey.com [207.126.98.130] (may be forged)) by mail.proper.com (8.8.8/8.8.5) with SMTP id JAA01112 for <[e-mail]>; Thu, 1 Apr 1999 09:17:12 -0800 (PST)
Received: from brick by gmtsw.com (SMI-8.6/SMI-SVR4) id JAA11973; Thu, 1 Apr 1999 09:17:36 -0800
Message-ID: <016d01be7c62$e81879f0$c74bffd0@brick>
From: "Todd S. Glassey" <[e-mail]>
To: "IETF PKIX" <[e-mail]>, <[e-mail]>
Subject: New Timestamping Tokens
Date: Thu, 1 Apr 1999 09:13:03 -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 4.72.3110.5
X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Hey Folks,
I have a serious concern that we are focusing on only half the battle
ere  - these issues, that is to say  about the structure of the Zuccheratto,
et al.  Timestamping Library, are really only half the puzzle for
timestamping and event tracking.

 As I was saying above, I suggest that the protocol, without adding a
recommended token structure is only half the battle. The protocol without a
token structure and format is just that, a means to cook a new end, nothing
more than core enablement.

Imagine if you will, that you are looking at all the pieces of a classic car
on the floor of your garage, Now take that image a step farther and imagine
that THERE IS NO INSTRUCTION BOOK for building the car and you've never seen
one assembled before... More importantly, that some auditor has to do a CS2
Audit on the completed car having never seen the instructions either, in
order for you to sell the car. No what do you do?

'Cause in my mind, that's what the current timestamping protocol draft
represents today - All the well manufactured infrastructure, but no
instructions or approved method for using them.

So, I suggest we help out the people who use these standards by giving them
a baseline set of digital tokens. My feeling is that to the industry and our
respective commercial endeavors, that this technology would be of
uncountable value to since we would have an anchor point to code to, the
Token.

Todd Glassey



Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id JAA01028 for ietf-pkix-bks; Thu, 1 Apr 1999 09:09:57 -0800 (PST)
Received: from gmtsw.com (test.glassey.com [207.126.98.130] (may be forged)) by mail.proper.com (8.8.8/8.8.5) with SMTP id JAA01024 for <[e-mail]>; Thu, 1 Apr 1999 09:09:56 -0800 (PST)
Received: from brick by gmtsw.com (SMI-8.6/SMI-SVR4) id JAA11958; Thu, 1 Apr 1999 09:09:36 -0800
Message-ID: <015d01be7c61$ca7b9040$c74bffd0@brick>
From: "Todd S. Glassey" <[e-mail]>
To: <[e-mail]>, <[e-mail]>
Cc: <[e-mail]>
Subject: Re: Time-stamp server. TimePrecision info
Date: Thu, 1 Apr 1999 09:05:03 -0800
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_015A_01BE7C1E.BAD11400"
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
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

This is a multi-part message in MIME format.

------=_NextPart_000_015A_01BE7C1E.BAD11400
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Thanks for the opening... I was wondering how to work this in...

There is an even bigger issue here for the use model. The actual end use =
of the system you are describing, the document timestamper/verifier is a =
end user application of timestamping only. There are many other uses of =
certifiable time than just adding non-repudiation. Certain IA control =
processes and other industrial control apps that are time based need =
this resolution as part of their control and messaging processes.

However the real issue is how to represent a timestamp in a manner =
conducive to the most general purpose use models. Also to make this same =
system work everywhere. That's why we need the token structure defined.

The bottomline is that subsecond accuracy is required for a growing =
number of industrial, commercial, and financial applications and because =
of the complexities of integrating certifiable timebases into processes =
and deliverable technologies, clean and reliable timebase services are =
better off being deployed everywhere.=20

Todd=20

    -----Original Message-----
    From: [e-mail] <[e-mail]>
    To: '[e-mail]' <[e-mail]>
    Cc: [e-mail] <[e-mail]>
    Date: Thursday, April 01, 1999 8:19 AM
    Subject: RE: Time-stamp server. TimePrecision info
   =20
   =20
    Are we missing a point here?  The use of a timestamp server is to =
resolve questions such as "At what time was a document signed?", "In =
what order were documents signed?" or "At what time was a document =
received?".  A timestamp server says "I issued a timestamp for the =
document at xxxx date and time".  In other words, there is not a precise =
time relationship between the event potentially in dispute and the =
generation of the timestamp.  Appendix B of the current draft recognises =
this by saying that, when subsequently verifying a document is =
consistent with its timestamp, the evidence should only be accepted if =
the times are "close enough (e.g. less than a few hours)".  Whilst hours =
may be a bit pessimistic for some systems, one only has to consider the =
likely method of communication between the requestor and the timestamp =
server to realise that a [leap] second either way is irrelevant.  =
Certainly, two requests issued at almost the same time will not =
necessarily arrive at the timestamp server in the same order as they =
were dispatched.  If we really are concerned about establishing =
completely unambiguously the order in which two documents are signed, a =
higher level protocol is required e.g. one in which the second document =
contains the timestamp of the first one.

   =20
   =20
    Paul Halliden=20
    Director for Strategic Technology=20
    =
______________________________________________________________________=20
    Baltimore, The Square, Basing View, Basingstoke, Hants, RG21 4EG, UK =

    Tel: [phone] Fax: [phone]=20
    http://www.baltimore.com=20
    Baltimore is the operating name of Zergo Holdings plc=20

   =20
   =20
   =20
    -----Original Message-----=20
    From: Michael Zolotarev [mailto:[e-mail]]=20
    Sent: 01 April 1999 09:00=20
    To: 'Tony Bartoletti'; Todd S. Glassey; Paul Koning;=20
    [e-mail]=20
    Cc: [e-mail]; '[e-mail]';=20
    '[e-mail]'=20
    Subject: RE: Time-stamp server. TimePrecision info=20

   =20
   =20
    Tony,=20

    I guess there is a neater solution to the 'gain a leap second' =
problem,=20
    using the serialNumber field of the response. If the serialNumebr is =

    properly maintained by the TSS, and returned to the client, a second =
can=20
    last as long as we want it:=20

    time:  0.21           0.22              0.23        0.23        0.23 =

          0.24=20
    S/N:  1,2,3,4...   x,x+1,x+2...    n,n+1,n+2,n+3, n+4, n+..      =
m,m+1...=20

    The issue is, the problem only exists when we COMPARE two stamps =
produced=20
    by THE SAME TSS. And this is exactly where the serialNumber will =
help us=20
    out.=20

    In a situation when you compare the stamps produced by different =
servers,=20
    or compare a stamp to a 'Golden Rolex' time, a one second difference =
should=20
    be tolerated, as the sources are not expected to be highly =
synchronised=20
    anyway.=20

    Michael Zolotarev=20
    Technical Architect, Baltimore Technologies Limited (Australia)=20

    Happy Easter!=20

    -----Original Message-----=20
    From:   Tony Bartoletti [SMTP:[e-mail]]=20
    Sent:   Thursday, April 01, 1999 4:31 AM=20
    To:     Todd S. Glassey; Paul Koning; [e-mail]=20
    Cc:     [e-mail]=20
    Subject:        Re: Time-stamp server. TimePrecision info=20

    At 07:44 PM 3/30/99 -0800, Todd S. Glassey wrote:=20
    >How will you deal with leap seconds?=20
    >=20

    The only solution I can think of would be UGLY, but would preserve=20
    the all-important monotonicity.  At least it would work when a=20
    leap-second is added. (Subtracting is another matter.  You would=20
    already have monotonicity, but differencing might be difficult.)=20

    Add another field to the "seconds", as little as one "bit", that=20
    is always zero except for a leap-second, when it is "one."=20

      E.G.   leap.seconds.milliseconds=20

    Now, if (say) the 23rd second of this minute had to be "repeated"=20
    (the clock is being set back 1 second, "gaining" a leap second,)=20
    then it would first occur as 0.23.ms, and then a second later=20
    as 1.23.ms.=20

    Thus, the sequence of timestamps of seconds from 21 to 25 might=20
    be recorded as 0.21, 0.22, 0.23, 1.23, 0.24, 0.25, with=20

        0.23 < 1.23, and 1.23 < 0.24=20

    Losing a leap-second (should that ever happen) is another matter.=20
    One could just drop the "missing" second as the clock advances.=20
    E.G.=20

        0.21, 0.22, 0.24, 0.25=20

    Monotonicity is preserved.  Differencing is a headache.=20

    I wonder how they will actually deal with this.=20

    ___tony___=20

    Tony Bartoletti                                             LL=20
    Center for Information Operations and Assurance          LL LL=20
    Lawrence Livermore National Laboratory                LL LL LL=20
    PO Box 808, L - 303                                   LL LL LL=20
    Livermore, CA 94551-9900                              LL LL LLLLLLLL =

    phone: [phone]   fax: [phone]               LL LLLLLLLL=20
    email: [e-mail]                                   LLLLLLLL=20


------=_NextPart_000_015A_01BE7C1E.BAD11400
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD W3 HTML//EN">
<HTML>
<HEAD>

<META content=3Dtext/html;charset=3Diso-8859-1 =
http-equiv=3DContent-Type><TITLE>RE: Time-stamp server. TimePrecision =
info</TITLE><!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<META content=3D'"MSHTML 4.72.3110.7"' name=3DGENERATOR>
</HEAD>
<BODY bgColor=3D#ffffff>
<DIV><FONT color=3D#000000 size=3D2>Thanks for the opening... I was =
wondering how to=20
work this in...</FONT></DIV>
<DIV><FONT color=3D#000000 size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT color=3D#000000 size=3D2>There is an even bigger issue here =
for the use=20
model. The actual end use of the system you are describing, the document =

timestamper/verifier is a end user application of timestamping only. =
There are=20
many other uses of certifiable time than just adding non-repudiation. =
Certain IA=20
control processes and other industrial control apps that are time based =
need=20
this resolution as part of their control and messaging =
processes.</FONT></DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT size=3D2>However the real issue is how to represent a =
timestamp in a=20
manner conducive to the most general purpose use models. Also to make =
this same=20
system work everywhere. That's why we need the token structure=20
defined.</FONT></DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT size=3D2>The bottomline is that subsecond accuracy is =
required for a=20
growing number of industrial, commercial, and financial applications and =
because=20
of the complexities of integrating certifiable timebases into processes =
and=20
deliverable technologies, clean and reliable timebase services are =
better off=20
being deployed everywhere. </FONT></DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT color=3D#000000 size=3D2>Todd </FONT></DIV>
<DIV>&nbsp;</DIV>
<BLOCKQUOTE=20
style=3D"BORDER-LEFT: #000000 solid 2px; MARGIN-LEFT: 5px; PADDING-LEFT: =
5px">
    <DIV><FONT face=3DArial size=3D2><B>-----Original =
Message-----</B></FONT><FONT=20
    face=3DArial size=3D2><BR><B>From: </B><A=20
    href=3D"mailto:[e-mail]">[e-mail]</A> &lt;<A=20
    =
href=3D"mailto:[e-mail]">[e-mail]</A>&gt;<BR><B>To:=
=20
    </B><A=20
    =
href=3D"mailto:'[e-mail]'">'[e-mail].a=
u'</A>=20
    &lt;<A=20
    =
href=3D"mailto:[e-mail]">[e-mail]</=
A>&gt;<BR><B>Cc:=20
    </B><A href=3D"mailto:[e-mail]">[e-mail]</A> =
&lt;<A=20
    =
href=3D"mailto:[e-mail]">[e-mail]</A>&gt;<BR><B>Date:=20
    </B>Thursday, April 01, 1999 8:19 AM<BR><B>Subject: </B>RE: =
Time-stamp=20
    server. TimePrecision info<BR><BR></DIV></FONT>
    <P><FONT size=3D2>Are we missing a point here?&nbsp; The use of a =
timestamp=20
    server is to resolve questions such as &quot;At what time was a =
document=20
    signed?&quot;, &quot;In what order were documents signed?&quot; or =
&quot;At=20
    what time was a document received?&quot;.&nbsp; A timestamp server =
says=20
    &quot;I issued a timestamp for the document at xxxx date and=20
    time&quot;.&nbsp; In other words, there is not a precise time =
relationship=20
    between the event potentially in dispute and the generation of the=20
    timestamp.&nbsp; Appendix B of the current draft recognises this by =
saying=20
    that, when subsequently verifying a document is consistent with its=20
    timestamp, the evidence should only be accepted if the times are =
&quot;close=20
    enough (e.g. less than a few hours)&quot;.&nbsp; Whilst hours may be =
a bit=20
    pessimistic for some systems, one only has to consider the likely =
method of=20
    communication between the requestor and the timestamp server to =
realise that=20
    a [leap] second either way is irrelevant.&nbsp; Certainly, two =
requests=20
    issued at almost the same time will not necessarily arrive at the =
timestamp=20
    server in the same order as they were dispatched.&nbsp; If we really =
are=20
    concerned about establishing completely unambiguously the order in =
which two=20
    documents are signed, a higher level protocol is required e.g. one =
in which=20
    the second document contains the timestamp of the first =
one.</FONT></P><BR>
    <P><FONT size=3D2>Paul Halliden</FONT> <BR><FONT size=3D2>Director =
for Strategic=20
    Technology</FONT> <BR><FONT=20
    =
size=3D2>________________________________________________________________=
______</FONT>=20
    <BR><FONT size=3D2>Baltimore, The Square, Basing View, Basingstoke, =
Hants,=20
    RG21 4EG, UK</FONT> <BR><FONT size=3D2>Tel: [phone] =
Fax: +44 (0)=20
    1256 812901</FONT> <BR><FONT size=3D2><A =
href=3D"http://www.baltimore.com"=20
    target=3D_blank>http://www.baltimore.com</A></FONT> <BR><FONT =
size=3D2>Baltimore=20
    is the operating name of Zergo Holdings plc </FONT></P><BR><BR>
    <P><FONT size=3D2>-----Original Message-----</FONT> <BR><FONT =
size=3D2>From:=20
    Michael Zolotarev [<A=20
    =
href=3D"mailto:[e-mail]">mailto:mzolotarev@baltimore.c=
om.au</A>]</FONT>=20
    <BR><FONT size=3D2>Sent: 01 April 1999 09:00</FONT> <BR><FONT =
size=3D2>To: 'Tony=20
    Bartoletti'; Todd S. Glassey; Paul Koning;</FONT> <BR><FONT=20
    size=3D2>[e-mail]</FONT> <BR><FONT size=3D2>Cc: =

    [e-mail]; '[e-mail]';</FONT> <BR><FONT=20
    size=3D2>'[e-mail]'</FONT> <BR><FONT =
size=3D2>Subject: RE:=20
    Time-stamp server. TimePrecision info</FONT> </P><BR>
    <P><FONT size=3D2>Tony,</FONT> </P>
    <P><FONT size=3D2>I guess there is a neater solution to the 'gain a =
leap=20
    second' problem, </FONT><BR><FONT size=3D2>using the serialNumber =
field of the=20
    response. If the serialNumebr is </FONT><BR><FONT size=3D2>properly =
maintained=20
    by the TSS, and returned to the client, a second can =
</FONT><BR><FONT=20
    size=3D2>last as long as we want it:</FONT> </P>
    <P><FONT size=3D2>time:&nbsp;=20
    0.21&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
    =
0.22&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;=20
    0.23&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
    0.23&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 0.23 </FONT><BR><FONT =

    size=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 0.24</FONT> <BR><FONT=20
    size=3D2>S/N:&nbsp; 1,2,3,4...&nbsp;&nbsp; =
x,x+1,x+2...&nbsp;&nbsp;&nbsp;=20
    n,n+1,n+2,n+3, n+4, n+..&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
m,m+1...</FONT> </P>
    <P><FONT size=3D2>The issue is, the problem only exists when we =
COMPARE two=20
    stamps produced </FONT><BR><FONT size=3D2>by THE SAME TSS. And this =
is exactly=20
    where the serialNumber will help us </FONT><BR><FONT =
size=3D2>out.</FONT> </P>
    <P><FONT size=3D2>In a situation when you compare the stamps =
produced by=20
    different servers, </FONT><BR><FONT size=3D2>or compare a stamp to a =
'Golden=20
    Rolex' time, a one second difference should </FONT><BR><FONT =
size=3D2>be=20
    tolerated, as the sources are not expected to be highly synchronised =

    </FONT><BR><FONT size=3D2>anyway.</FONT> </P>
    <P><FONT size=3D2>Michael Zolotarev</FONT> <BR><FONT =
size=3D2>Technical=20
    Architect, Baltimore Technologies Limited (Australia)</FONT> </P>
    <P><FONT size=3D2>Happy Easter!</FONT> </P>
    <P><FONT size=3D2>-----Original Message-----</FONT> <BR><FONT=20
    size=3D2>From:&nbsp;&nbsp; Tony Bartoletti =
[SMTP:[e-mail]]</FONT>=20
    <BR><FONT size=3D2>Sent:&nbsp;&nbsp; Thursday, April 01, 1999 4:31 =
AM</FONT>=20
    <BR><FONT size=3D2>To:&nbsp;&nbsp;&nbsp;&nbsp; Todd S. Glassey; Paul =
Koning;=20
    [e-mail]</FONT> <BR><FONT=20
    size=3D2>Cc:&nbsp;&nbsp;&nbsp;&nbsp; [e-mail]</FONT> =
<BR><FONT=20
    size=3D2>Subject:&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Re: =
Time-stamp=20
    server. TimePrecision info</FONT> </P>
    <P><FONT size=3D2>At 07:44 PM 3/30/99 -0800, Todd S. Glassey =
wrote:</FONT>=20
    <BR><FONT size=3D2>&gt;How will you deal with leap seconds?</FONT> =
<BR><FONT=20
    size=3D2>&gt;</FONT> </P>
    <P><FONT size=3D2>The only solution I can think of would be UGLY, =
but would=20
    preserve</FONT> <BR><FONT size=3D2>the all-important =
monotonicity.&nbsp; At=20
    least it would work when a</FONT> <BR><FONT size=3D2>leap-second is =
added.=20
    (Subtracting is another matter.&nbsp; You would</FONT> <BR><FONT=20
    size=3D2>already have monotonicity, but differencing might be=20
    difficult.)</FONT> </P>
    <P><FONT size=3D2>Add another field to the &quot;seconds&quot;, as =
little as=20
    one &quot;bit&quot;, that</FONT> <BR><FONT size=3D2>is always zero =
except for=20
    a leap-second, when it is &quot;one.&quot;</FONT> </P>
    <P><FONT size=3D2>&nbsp; E.G.&nbsp;&nbsp; =
leap.seconds.milliseconds</FONT>=20
</P>
    <P><FONT size=3D2>Now, if (say) the 23rd second of this minute had =
to be=20
    &quot;repeated&quot;</FONT> <BR><FONT size=3D2>(the clock is being =
set back 1=20
    second, &quot;gaining&quot; a leap second,)</FONT> <BR><FONT =
size=3D2>then it=20
    would first occur as 0.23.ms, and then a second later</FONT> =
<BR><FONT=20
    size=3D2>as 1.23.ms.</FONT> </P>
    <P><FONT size=3D2>Thus, the sequence of timestamps of seconds from =
21 to 25=20
    might</FONT> <BR><FONT size=3D2>be recorded as 0.21, 0.22, 0.23, =
1.23, 0.24,=20
    0.25, with</FONT> </P>
    <P><FONT size=3D2>&nbsp;&nbsp;&nbsp; 0.23 &lt; 1.23, and 1.23 &lt; =
0.24</FONT>=20
    </P>
    <P><FONT size=3D2>Losing a leap-second (should that ever happen) is =
another=20
    matter.</FONT> <BR><FONT size=3D2>One could just drop the =
&quot;missing&quot;=20
    second as the clock advances.</FONT> <BR><FONT size=3D2>E.G.</FONT> =
</P>
    <P><FONT size=3D2>&nbsp;&nbsp;&nbsp; 0.21, 0.22, 0.24, 0.25</FONT> =
</P>
    <P><FONT size=3D2>Monotonicity is preserved.&nbsp; Differencing is a =

    headache.</FONT> </P>
    <P><FONT size=3D2>I wonder how they will actually deal with =
this.</FONT> </P>
    <P><FONT size=3D2>___tony___</FONT> </P>
    <P><FONT size=3D2>Tony=20
    =
Bartoletti&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;&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;&nbsp;=20
    LL</FONT> <BR><FONT size=3D2>Center for Information Operations and=20
    Assurance&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; LL =
LL</FONT>=20
    <BR><FONT size=3D2>Lawrence Livermore National=20
    =
Laboratory&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp;&nbsp;&nbsp;=20
    LL LL LL</FONT> <BR><FONT size=3D2>PO Box 808, L -=20
    =
303&nbsp;&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;&nbsp;&nbsp;=20
    LL LL LL</FONT> <BR><FONT size=3D2>Livermore, CA=20
    =
94551-9900&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
    LL LL LLLLLLLL</FONT> <BR><FONT size=3D2>phone: =
925-422-3881&nbsp;&nbsp; fax:=20
    =
925-423-8002&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&=
nbsp;&nbsp;&nbsp;&nbsp;=20
    LL LLLLLLLL</FONT> <BR><FONT size=3D2>email:=20
    =
[e-mail]&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&=
nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
    LLLLLLLL</FONT> </P></BLOCKQUOTE></BODY></HTML>

------=_NextPart_000_015A_01BE7C1E.BAD11400--



Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id IAA00882 for ietf-pkix-bks; Thu, 1 Apr 1999 08:50:02 -0800 (PST)
Received: from relay1.mail.uk.psi.net (relay1.mail.uk.psi.net [154.32.105.6]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id IAA00878 for <[e-mail]>; Thu, 1 Apr 1999 08:50:01 -0800 (PST)
Received: from [195.152.140.4] (helo=stonewall.baltimore.com) by relay1.mail.uk.psi.net with smtp (Exim 2.02 #3) id 10SkfT-0003zb-00; Thu, 1 Apr 1999 17:50:11 +0100
To: "'Paul Koning'" <[e-mail]>
Cc: [e-mail]
Subject: RE: Time-stamp server. TimePrecision info
Date: Thu, 1 Apr 1999 17:51:49 +0100 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2232.9)
Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01BE7C5F.F15A3BB4"
From: Paul Halliden <[e-mail]>
Message-ID: <[e-mail]>
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
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_01BE7C5F.F15A3BB4
Content-Type: text/plain;
	charset="iso-8859-1"

I quite agree that hours may not be close enough in some cases. The point is
that the spec specifically talks about a range of communication techniques
between requester and TSS including e-mail which has a notoriously variable
transit time.  The timestamp gives no indication about how long the
requester's message took to get to the timestamp authority.  Even if it did,
I don't believe that the authority would be in any position to know reliably
at what time the request was made.  Thus anyone who relies on a sequence of
timestamps to indicate order is deluding themselves if they want precision
anywhere near the transit time of the network(s) used. I would expect the
timestamp authority's policy to say its service was unsuited for such
precise sequencing and that some other technique for establishing the
sequence of transactions should be used.

Paul



-----Original Message-----
From: Paul Koning [mailto:[e-mail]]
Sent: 01 April 1999 17:05
To: [e-mail]
Cc: [e-mail]
Subject: RE: Time-stamp server. TimePrecision info


I suspect that "close enough" may change over time, and hours may not
be good enough.  For example, the required accuracy for timestamps on
stock trading messages is more likely to be minutes rather than hours
even today.

In any case, it helps to be consistent.  If hours or even minutes is
the outer limit of resolution needed, them milliseconds have no place
in the timestamp format.

As for establishing order by having a second document include the
older timestamp of the first document, that's fine if I generate both
documents.  If the dispute is on which of the two of us generated our
document first, then we'll be dealing with two independent timestamps
presumably from different servers.  If they aren't synchronized to UTC 
any better than hours, the service will not be useful in a number of
interesting cases. 

Finally: it's a bad idea to make the specs tighter than what is
achievable, but it also doesn't make a whole lot of sense to make them
4 orders of magnitude looser.  Synchronizing to UTC to within a
fraction of a second is easy, and network round trip times are in the
range of seconds (actually, often way smaller than that).  Yes, that
opens the question of how you handle leap seconds.  One solution is to
loosen things up some more, but going from seconds to hours is really
not necessary.

	paul

------_=_NextPart_001_01BE7C5F.F15A3BB4
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.2410.0">
<TITLE>RE: Time-stamp server. TimePrecision info</TITLE>
</HEAD>
<BODY>

<P><FONT SIZE=3D2>I quite agree that hours may not be close enough in =
some cases. The point is that the spec specifically talks about a range =
of communication techniques between requester and TSS including e-mail =
which has a notoriously variable transit time.&nbsp; The timestamp =
gives no indication about how long the requester's message took to get =
to the timestamp authority.&nbsp; Even if it did, I don't believe that =
the authority would be in any position to know reliably at what time =
the request was made.&nbsp; Thus anyone who relies on a sequence of =
timestamps to indicate order is deluding themselves if they want =
precision anywhere near the transit time of the network(s) used. I =
would expect the timestamp authority's policy to say its service was =
unsuited for such precise sequencing and that some other technique for =
establishing the sequence of transactions should be used.</FONT></P>

<P><FONT SIZE=3D2>Paul</FONT>
</P>
<BR>
<BR>

<P><FONT SIZE=3D2>-----Original Message-----</FONT>
<BR><FONT SIZE=3D2>From: Paul Koning [<A =
HREF=3D"mailto:[e-mail]">mailto:[e-mail]</A>]</FONT>
<BR><FONT SIZE=3D2>Sent: 01 April 1999 17:05</FONT>
<BR><FONT SIZE=3D2>To: [e-mail]</FONT>
<BR><FONT SIZE=3D2>Cc: [e-mail]</FONT>
<BR><FONT SIZE=3D2>Subject: RE: Time-stamp server. TimePrecision =
info</FONT>
</P>
<BR>

<P><FONT SIZE=3D2>I suspect that &quot;close enough&quot; may change =
over time, and hours may not</FONT>
<BR><FONT SIZE=3D2>be good enough.&nbsp; For example, the required =
accuracy for timestamps on</FONT>
<BR><FONT SIZE=3D2>stock trading messages is more likely to be minutes =
rather than hours</FONT>
<BR><FONT SIZE=3D2>even today.</FONT>
</P>

<P><FONT SIZE=3D2>In any case, it helps to be consistent.&nbsp; If =
hours or even minutes is</FONT>
<BR><FONT SIZE=3D2>the outer limit of resolution needed, them =
milliseconds have no place</FONT>
<BR><FONT SIZE=3D2>in the timestamp format.</FONT>
</P>

<P><FONT SIZE=3D2>As for establishing order by having a second document =
include the</FONT>
<BR><FONT SIZE=3D2>older timestamp of the first document, that's fine =
if I generate both</FONT>
<BR><FONT SIZE=3D2>documents.&nbsp; If the dispute is on which of the =
two of us generated our</FONT>
<BR><FONT SIZE=3D2>document first, then we'll be dealing with two =
independent timestamps</FONT>
<BR><FONT SIZE=3D2>presumably from different servers.&nbsp; If they =
aren't synchronized to UTC </FONT>
<BR><FONT SIZE=3D2>any better than hours, the service will not be =
useful in a number of</FONT>
<BR><FONT SIZE=3D2>interesting cases. </FONT>
</P>

<P><FONT SIZE=3D2>Finally: it's a bad idea to make the specs tighter =
than what is</FONT>
<BR><FONT SIZE=3D2>achievable, but it also doesn't make a whole lot of =
sense to make them</FONT>
<BR><FONT SIZE=3D2>4 orders of magnitude looser.&nbsp; Synchronizing to =
UTC to within a</FONT>
<BR><FONT SIZE=3D2>fraction of a second is easy, and network round trip =
times are in the</FONT>
<BR><FONT SIZE=3D2>range of seconds (actually, often way smaller than =
that).&nbsp; Yes, that</FONT>
<BR><FONT SIZE=3D2>opens the question of how you handle leap =
seconds.&nbsp; One solution is to</FONT>
<BR><FONT SIZE=3D2>loosen things up some more, but going from seconds =
to hours is really</FONT>
<BR><FONT SIZE=3D2>not necessary.</FONT>
</P>

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

</BODY>
</HTML>
------_=_NextPart_001_01BE7C5F.F15A3BB4--


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id IAA00854 for ietf-pkix-bks; Thu, 1 Apr 1999 08:45:12 -0800 (PST)
Received: from relay1.UU.NET (relay1.UU.NET [192.48.96.5]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id IAA00850 for <[e-mail]>; Thu, 1 Apr 1999 08:45:11 -0800 (PST)
Received: from xedia.com by relay1.UU.NET with SMTP  (peer crosschecked as: madway.xedia.com [198.202.232.199]) id QQgjbu06397; Thu, 1 Apr 1999 11:44:24 -0500 (EST)
Received: from tonga.xedia.com by xedia.com (4.1/SMI-4.1) id AA18076; Thu, 1 Apr 99 11:40:19 EST
Received: by tonga.xedia.com (SMI-8.6/SMI-SVR4) id LAA04231; Thu, 1 Apr 1999 11:44:17 -0500
Date: Thu, 1 Apr 1999 11:44:17 -0500
Message-Id: <[e-mail]>
From: Paul Koning <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
To: [e-mail]
Cc: [e-mail]
Subject: Re: Time-stamp server. TimePrecision info
References: <[e-mail]> <[e-mail]>
X-Mailer: VM 6.34 under 20.3 "Vatican City" XEmacs  Lucid
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

>>>>> "Michael" == Michael McNeil <[e-mail]> writes:

 Michael> Paul Koning wrote:
 >> The NTP RFC (RFC 1305) has an excellent discussion on this and the
 >> approaches it describes would be good to use.  In particular, it
 >> suggests using a two part date/time coding (day separate from
 >> time-in-day).  That way the existence of leap seconds merely
 >> increases the range of the second field by one.  (Analogy: if you
 >> sent the timestamp as yyyymmddhhmmss.ssss the impact is merely
 >> that ss can be from 0 to 60, not 0 to 59.)

 Michael> This approach works, but has the disadvantage of requiring
 Michael> numerous conversions from one unit to another (i.e.,
 Michael> year-month-day hours- minutes-seconds-milliseconds, say),
 Michael> involving leap years and other calendric oddities, in order
 Michael> to compare the times in two timestamps.  As in Tony's
 Michael> proposal, it also requires looking up the history of leap
 Michael> seconds to find out whether one has occurred between any two
 Michael> dates.

 Michael> A desirable solution ought to both maintain strict
 Michael> monotonicity over leap seconds (without complicated
 Michael> manipulations if possible) as well as not hinder comparisons
 Michael> down to the fractional seconds, should that be desired. 

Agreed.  But if by comparison you mean the operators <, =, and >, then 
what I described (which is what's in the current draft, once you make
it clear that the ss field has 60 as a legal value) works.

A strcmp operation on time strings in GeneralizedTime format yields
the correct answer for all cases including leap seconds.  It's pretty
clear why that is so: the characters in that string are in descending
order of significance reading left to right...

As I mentioned elsewhere, whether conversion to this format requires
you to know about leap seconds depends on what you start from.  If you 
start from NTP format then I believe it does not.  In any case, that's 
an internal matter.

	paul


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id IAA00780 for ietf-pkix-bks; Thu, 1 Apr 1999 08:33:35 -0800 (PST)
Received: from gatekeeper.entrust.com (gatekeeper.entrust.com [204.101.128.170]) by mail.proper.com (8.8.8/8.8.5) with SMTP id IAA00776 for <[e-mail]>; Thu, 1 Apr 1999 08:33:33 -0800 (PST)
Received: 	id LAA09862; Thu, 1 Apr 1999 11:30:36 -0500
Received: by gateway id <G4CAY0RB>; Thu, 1 Apr 1999 11:32:55 -0500
Message-ID: <01E1D01C12D7D211AFC70090273D20B112BD67@sothmxs06>
From: Robert Zuccherato <[e-mail]>
To: [e-mail], "'Paul Koning'" <[e-mail]>
Cc: [e-mail]
Subject: RE: Time-stamp server. TimePrecision info
Date: Thu, 1 Apr 1999 11:27:17 -0500 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.1960.3)
Content-Type: text/plain
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

One point that I would like to clear up.  The present timestamping draft
does not consider resolution of hours to be sufficient.  The reference to
resolution of "less than a few hours" comes from an informative annex giving
an example of how the protocol could be used.  The resolution required by
any particular application is not considered in the main document.  Remember
this document describes just the protocol to be used by the TSA.  

That said, I agree with Denis.  I do not see the use of microseconds to be
especially useful within this protocol.

	Robert.

> ----------
> From: 	Paul Koning[SMTP:[e-mail]]
> Sent: 	Thursday, April 01, 1999 11:04 AM
> To: 	[e-mail]
> Cc: 	[e-mail]
> Subject: 	RE: Time-stamp server. TimePrecision info
> 
> I suspect that "close enough" may change over time, and hours may not
> be good enough.  For example, the required accuracy for timestamps on
> stock trading messages is more likely to be minutes rather than hours
> even today.
> 
> In any case, it helps to be consistent.  If hours or even minutes is
> the outer limit of resolution needed, them milliseconds have no place
> in the timestamp format.
> 
> As for establishing order by having a second document include the
> older timestamp of the first document, that's fine if I generate both
> documents.  If the dispute is on which of the two of us generated our
> document first, then we'll be dealing with two independent timestamps
> presumably from different servers.  If they aren't synchronized to UTC 
> any better than hours, the service will not be useful in a number of
> interesting cases. 
> 
> Finally: it's a bad idea to make the specs tighter than what is
> achievable, but it also doesn't make a whole lot of sense to make them
> 4 orders of magnitude looser.  Synchronizing to UTC to within a
> fraction of a second is easy, and network round trip times are in the
> range of seconds (actually, often way smaller than that).  Yes, that
> opens the question of how you handle leap seconds.  One solution is to
> loosen things up some more, but going from seconds to hours is really
> not necessary.
> 
> 	paul
> 


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id IAA00760 for ietf-pkix-bks; Thu, 1 Apr 1999 08:31:31 -0800 (PST)
Received: from always.got.net ([e-mail] [207.111.232.11]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id IAA00756 for <[e-mail]>; Thu, 1 Apr 1999 08:31:30 -0800 (PST)
Received: from got.net (SantaCruz67.got.net [209.66.100.67]) by always.got.net (8.8.8/8.8.7/Debian/GNU) with ESMTP id IAA19336; Thu, 1 Apr 1999 08:30:13 -0800
Message-ID: <[e-mail]>
Date: Thu, 01 Apr 1999 08:29:50 -0800
From: Michael McNeil <[e-mail]>
Organization: GMT
X-Mailer: Mozilla 4.51 [en] (WinNT; U)
X-Accept-Language: en
MIME-Version: 1.0
To: "[e-mail]" <[e-mail]>
CC: "'Tony Bartoletti'" <[e-mail]>, "Todd S. Glassey" <[e-mail]>, Paul Koning <[e-mail]>, "[e-mail]" <[e-mail]>, "[e-mail]" <[e-mail]>, "'[e-mail]'" <[e-mail]>, "'[e-mail]'" <[e-mail]>, [e-mail]
Subject: Re: Time-stamp server. TimePrecision info
References: <[e-mail]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Michael Zolotarev wrote:
>I guess there is a neater solution to the 'gain a leap second' problem,
>using the serialNumber field of the response. If the serialNumebr is
>properly maintained by the TSS, and returned to the client, a second
>can last as long as we want it:
>
>time:  0.21          0.22             0.23       0.23       0.23
>      0.24
>S/N: 1,2,3,4...  x,x+1,x+2...   n,n+1,n+2,n+3, n+4, n+..     m,m+1...
>
>The issue is, the problem only exists when we COMPARE two stamps
>produced by THE SAME TSS. And this is exactly where the serialNumber
>will help us out.

While tacking a serial number onto the seconds field of a UTC time count
would work in maintaining monotonicity for that server's timestamps (and
I am a supporter of including a serial number field in timestamps), I
hardly think it's "neater".  It works only if fractional seconds are not
included in the time, and while monotonically increasing (if fractional
seconds are left out), doesn't allow any comparison beyond seconds for
timestamps from a single server other than one is earlier than another.
One can't even determine that for timestamps from different servers.

Looking at Tony Bartoletti's proposed solution, on the other hand:

Tony Bartoletti wrote:
>The only solution I can think of would be UGLY, but would preserve
>the all-important monotonicity.  At least it would work when a
>leap-second is added. (Subtracting is another matter.  You would
>already have monotonicity, but differencing might be difficult.)
>
>Add another field to the "seconds", as little as one "bit", that
>is always zero except for a leap-second, when it is "one."

Tony proposed that a leap-second-in-progress flag bit be the logical
lowest-order bit of the seconds count.  This would allow monotonicity
without any special coding being required, but would fuzz taking a
difference between second counts (two timestamps) to simply indicating
which is earlier, seconds-wise.  Placing the leap second flag in another
location allows timestamps (which can now include fractional seconds) to
be compared, but would necessitate extra code to check the leap second
flag and alter the difference if a leap second is indicated as being in
progress.  It requires looking up the history of leap seconds in order
to determine whether one has occurred between any two dates and times.
This approach is also not a "neat" solution, as Tony says, but works.

Paul Koning mentioned the method of simply adding a 61st second to a
year-month-day hours:minutes:seconds.fractional time representation:

Paul Koning wrote:
>The NTP RFC (RFC 1305) has an excellent discussion on this and the
>approaches it describes would be good to use.  In particular, it
>suggests using a two part date/time coding (day separate from
>time-in-day).  That way the existence of leap seconds merely increases 
>the range of the second field by one.  (Analogy: if you sent the
>timestamp as yyyymmddhhmmss.ssss the impact is merely that ss can be
>from 0 to 60, not 0 to 59.)

This approach works, but has the disadvantage of requiring numerous
conversions from one unit to another (i.e., year-month-day hours-
minutes-seconds-milliseconds, say), involving leap years and other
calendric oddities, in order to compare the times in two timestamps.
As in Tony's proposal, it also requires looking up the history of leap
seconds to find out whether one has occurred between any two dates.

A desirable solution ought to both maintain strict monotonicity over
leap seconds (without complicated manipulations if possible) as well
as not hinder comparisons down to the fractional seconds, should that be
desired.  In my view, the easiest response to these requirements is to
maintain two counters, both of whose values get emplaced in generated
timestamps -- one the usual NTP UTC seconds count, including 32-bits of
fractional seconds information; the other a leap seconds count field.

During ordinary seconds, the UTC seconds (and fractional) count would
increment as usual, but not the leap second counter.  During a leap
second, on the other hand, the UTC seconds count would not increment
(though fractional seconds would indicate its proper value), while the
leap-second count would increment.  To perform comparisons between two
dates and times, each UTC seconds count would first be added to the leap
second count -- thus producing essentially TAI (International Atomic)
time -- following which the two dates/times can be directly subtracted
in a single 64-bit subtract operation.  This method will work across
leap seconds, including all the 32-bit fractional second information.

Michael Zolotarev goes on to say:
>In a situation when you compare the stamps produced by different
>servers, or compare a stamp to a 'Golden Rolex' time, a one second
>difference should be tolerated, as the sources are not expected to be
>highly synchronised anyway.

I disagree that fractional second resolution will not be important in
the future.  The present primitive time synchronization situation is not
likely to last, in my opinion, when better and more secure time becomes
widely available and a required component of secure systems.  In
particular, timestamping servers will be expected to issue good time.

>Michael Zolotarev
>Technical Architect, Baltimore Technologies Limited (Australia)
>
>Happy Easter!

Thanks!  And thanks for posting.

Michael McNeil
[e-mail]
1-831-335-2069

IETF Secure Time Working Group: http://www.stime.org


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id IAA00494 for ietf-pkix-bks; Thu, 1 Apr 1999 08:05:35 -0800 (PST)
Received: from relay5.UU.NET (relay5.UU.NET [192.48.96.15]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id IAA00490 for <[e-mail]>; Thu, 1 Apr 1999 08:05:34 -0800 (PST)
Received: from xedia.com by relay5.UU.NET with SMTP  (peer crosschecked as: madway.xedia.com [198.202.232.199]) id QQgjbs04761; Thu, 1 Apr 1999 11:04:49 -0500 (EST)
Received: from tonga.xedia.com by xedia.com (4.1/SMI-4.1) id AA17199; Thu, 1 Apr 99 11:00:44 EST
Received: by tonga.xedia.com (SMI-8.6/SMI-SVR4) id LAA04187; Thu, 1 Apr 1999 11:04:42 -0500
Date: Thu, 1 Apr 1999 11:04:42 -0500
Message-Id: <[e-mail]>
From: Paul Koning <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
To: [e-mail]
Cc: [e-mail]
Subject: RE: Time-stamp server. TimePrecision info
References: <[e-mail]>
X-Mailer: VM 6.34 under 20.3 "Vatican City" XEmacs  Lucid
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

I suspect that "close enough" may change over time, and hours may not
be good enough.  For example, the required accuracy for timestamps on
stock trading messages is more likely to be minutes rather than hours
even today.

In any case, it helps to be consistent.  If hours or even minutes is
the outer limit of resolution needed, them milliseconds have no place
in the timestamp format.

As for establishing order by having a second document include the
older timestamp of the first document, that's fine if I generate both
documents.  If the dispute is on which of the two of us generated our
document first, then we'll be dealing with two independent timestamps
presumably from different servers.  If they aren't synchronized to UTC 
any better than hours, the service will not be useful in a number of
interesting cases. 

Finally: it's a bad idea to make the specs tighter than what is
achievable, but it also doesn't make a whole lot of sense to make them
4 orders of magnitude looser.  Synchronizing to UTC to within a
fraction of a second is easy, and network round trip times are in the
range of seconds (actually, often way smaller than that).  Yes, that
opens the question of how you handle leap seconds.  One solution is to
loosen things up some more, but going from seconds to hours is really
not necessary.

	paul


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id HAA00418 for ietf-pkix-bks; Thu, 1 Apr 1999 07:59:01 -0800 (PST)
Received: from clbull.frcl.bull.fr (clbull.frcl.bull.fr [129.182.1.20]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id HAA00414 for <[e-mail]>; Thu, 1 Apr 1999 07:58:59 -0800 (PST)
Received: from k2.frcl.bull.fr (k2.frcl.bull.fr [129.182.100.2]) by clbull.frcl.bull.fr (8.9.1a/8.9.1) with ESMTP id RAA17140 for <[e-mail]>; Thu, 1 Apr 1999 17:58:45 +0100
Received: from bull.net (frcls6118.frcl.bull.fr [129.182.109.213]) by k2.frcl.bull.fr (AIX4.2/UCB 8.7/8.7) with ESMTP id RAA24884 for <[e-mail]>; Thu, 1 Apr 1999 17:59:46 +0100 (NFT)
Message-ID: <[e-mail]>
Date: Thu, 01 Apr 1999 17:59:28 +0200
From: Denis Pinkas <[e-mail]>
Organization: Bull
X-Mailer: Mozilla 4.06 [fr] (Win95; I)
MIME-Version: 1.0
To: IETF-PXIX <[e-mail]>
Subject: 3 Time Stamping issues
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Since I am a co-editor of the Time Stamping document, I would like
to give my opinion on the various issues raised on the mailing list.

1. There has been a suggestion to possibly improve the resolution to
microseconds from milliseconds.

Since the delay in the transmission is at least in the millisecond
order, having something more precise would give a false degree of
precision. I would not go under the millisesond.

2. There has been a suggestion to possibly add a precision field.

I do not think this is absolutely necessary. So I am not supportive
of it since the policy can handle this.

3. There has been a suggestion to possibly add a message information
field.

I have arguments *against* this idea. I would realy like to keep the
TSA as much ignorant as possible of the purpose of the Time
Stamping. If we add that information, the TSA could know "Invoice
from Alpha company to Delta company". Is
this way the TSA could learn that the Delta company is doing
commerce with the Delta company. This may that be a nice point to
spy. So I am against the inclusion of that aditional information.

However, ... I understand the concern of the linkeage and I would
propose an alternative:

Defining a Time Stamping Token (TST) that would be able to include
that information. Basically the TST would be the concatenation of
the "message information field" and of the signed portion of the
information received. The TST would be constructed locally instead
of being fully constructed by the TSA. We could define its structure
in a normative annex.

Regards,

Denis



Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id HAA00345 for ietf-pkix-bks; Thu, 1 Apr 1999 07:53:06 -0800 (PST)
Received: from relay4.UU.NET (relay4.UU.NET [192.48.96.14]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id HAA00341 for <[e-mail]>; Thu, 1 Apr 1999 07:53:05 -0800 (PST)
Received: from xedia.com by relay4.UU.NET with SMTP  (peer crosschecked as: madway.xedia.com [198.202.232.199]) id QQgjbr19686; Thu, 1 Apr 1999 10:50:02 -0500 (EST)
Received: from tonga.xedia.com by xedia.com (4.1/SMI-4.1) id AA16898; Thu, 1 Apr 99 10:44:40 EST
Received: by tonga.xedia.com (SMI-8.6/SMI-SVR4) id KAA04168; Thu, 1 Apr 1999 10:48:38 -0500
Date: Thu, 1 Apr 1999 10:48:38 -0500
Message-Id: <[e-mail]>
From: Paul Koning <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
To: [e-mail]
Cc: [e-mail]
Subject: RE: Time-stamp server. TimePrecision info
References: <[e-mail]>
X-Mailer: VM 6.34 under 20.3 "Vatican City" XEmacs  Lucid
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

>>>>> "Michael" == Michael Zolotarev <[e-mail]> writes:

 Michael> In a situation when you compare the stamps produced by
 Michael> different servers, or compare a stamp to a 'Golden Rolex'
 Michael> time, a one second difference should be tolerated, as the
 Michael> sources are not expected to be highly synchronised anyway.

I guess that works perfectly well if the inaccuracy (i.e., difference
between timestamp and actual UTC) is large enough.  In particular, if
you ignore leap seconds then you have to report that value as one
larger than the nominal amount.  By the way, if that's your
expectation it probably should be mentioned explicitly, because it's
not obvious otherwise that it would be expected.  Also, if you don't
expect to be accurate to better than a second, it would be logical to
remove the fractional seconds information since it is meaningless.

As far as I can see you have time represented as ...hhmmss and
fractional seconds.  So you can clearly represent leap seconds
directly.  The only issue is a local implementation one: can you
reliably convert internal time format to that representation?

If you use NTP, then that's no problem.  If you use an external time
source that either uses a similar date/time format (e.g., WWV) again
no problem.  

If you have an internal time format encoded as seconds since X, then
you have several possible cases:

a. If "seconds since X" really means "seconds ignoring leap seconds"
then you can convert that easily to the other format but you should
probably add a second to the inaccuracy to account for the possibility 
that there was a leap second recently that hasn't been reflected yet
in the local time.

b. If you really have seconds since X including leap seconds, then to
convert to hhmmss... format you either need to know the number of leap 
seconds that have been inserted between X and now, or you have to
assume the worst case (two per year) and increase the inaccuracy by
that worst case.


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id HAA28085 for ietf-pkix-bks; Thu, 1 Apr 1999 07:18:26 -0800 (PST)
Received: from gmtsw.com (test.glassey.com [207.126.98.130] (may be forged)) by mail.proper.com (8.8.8/8.8.5) with SMTP id HAA28080 for <[e-mail]>; Thu, 1 Apr 1999 07:18:25 -0800 (PST)
Received: from brick by gmtsw.com (SMI-8.6/SMI-SVR4) id HAA11879; Thu, 1 Apr 1999 07:18:49 -0800
Message-ID: <010201be7c52$502224d0$c74bffd0@brick>
From: "Todd S. Glassey" <[e-mail]>
To: "IETF PKIX" <[e-mail]>
Subject: Re: Time-stamp server. TimePrecision info
Date: Thu, 1 Apr 1999 07:14:17 -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 4.72.3110.5
X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Hey all, Sorry about the "Know Idea" pun - I thought the typo was funny

-----Original Message-----
From: Todd S. Glassey <[e-mail]>
To: Paul Koning <[e-mail]>
Cc: [e-mail] <[e-mail]>
Date: Wednesday, March 31, 1999 1:29 PM
Subject: Re: Time-stamp server. TimePrecision info


>Hey Paul -
>Does this mean that we are going to use NTP for timestamping? (This is not
>such a bad idea and Michael McNeil and i suggested just this with the two
>drafts on PKI extended NTP we did with Dave Mills),
>
>The real issue is how timestamps are derived from a local timebase and that
>the local timebase has to deal with Leap Seconds somehow... The current
>Entrust protocol toolkit assumes that the time data it is handed by the
>underlying OS is "legally sufficient" to use as core for timestamping-  but
>the problem here is that NO COMMERCIAL OS's know about Leap Seconds and so
>using the TOD clock is a gamble... that the BCP addresses these and that
the
>timebase services are managed out of band.
>
>BTW, as a simple example of how most people just believe this has already
>been handled, there is a paragraph in the TimeServe addition to the NT
>resource kit (timeserve.txt file) that states the accuracy of the NT clock
>is at best .45S/day. That in and of itself is an issue since the PC and
>Server manufacturers are all worried about the bottom line so they use the
>most "cost effective" (from their $$$ viewpoint) clock chips and the like.
>
>My personal feeling is that without some BCP that has one dialing into the
>ACTS servers at NIST on a once daily or twice daily model, we have know
idea
>what time it really is.
>
>There are no secure NTP servers out there yet but we are woking on this
and,
>well - Stay tuned for the first one's announcement in the next 45 days.
>
>Todd
>
>
>-----Original Message-----
>From: Paul Koning <[e-mail]>
>To: [e-mail] <[e-mail]>
>Cc: [e-mail] <[e-mail]>
>Date: Wednesday, March 31, 1999 10:03 AM
>Subject: Re: Time-stamp server. TimePrecision info
>
>
>>>>>>> "Todd" == Todd S Glassey <[e-mail]> writes:
>>
>> Todd> How will you deal with leap seconds?  T.
>>
>>The NTP RFC (RFC 1305) has an excellent discussion on this and the
>>approaches it describes would be good to use.  In particular, it
>>suggests using a two part date/time coding (day separate from
>>time-in-day).  That way the existence of leap seconds merely increases
>>the range of the second field by one.  (Analogy: if you sent the
>>timestamp as yyyymmddhhmmss.ssss the impact is merely that ss can be
>>from 0 to 60, not 0 to 59.)
>>
>> paul
>>
>
>



Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id GAA24765 for ietf-pkix-bks; Thu, 1 Apr 1999 06:29:55 -0800 (PST)
Received: from relay1.mail.uk.psi.net (relay1.mail.uk.psi.net [154.32.105.6]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id GAA24760 for <[e-mail]>; Thu, 1 Apr 1999 06:29:53 -0800 (PST)
From: [e-mail]
Received: from [195.152.140.4] (helo=stonewall.baltimore.com) by relay1.mail.uk.psi.net with smtp (Exim 2.02 #3) id 10SiTb-000323-00; Thu, 1 Apr 1999 15:29:47 +0100
To: "'[e-mail]'" <[e-mail]>
Cc: [e-mail]
Subject: RE: Time-stamp server. TimePrecision info
Date: Thu, 1 Apr 1999 13:03:50 +0100 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2232.9)
Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01BE7C37.B4D0235C"
Message-ID: <[e-mail]>
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
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_01BE7C37.B4D0235C
Content-Type: text/plain;
	charset="iso-8859-1"

Are we missing a point here?  The use of a timestamp server is to resolve
questions such as "At what time was a document signed?", "In what order were
documents signed?" or "At what time was a document received?".  A timestamp
server says "I issued a timestamp for the document at xxxx date and time".
In other words, there is not a precise time relationship between the event
potentially in dispute and the generation of the timestamp.  Appendix B of
the current draft recognises this by saying that, when subsequently
verifying a document is consistent with its timestamp, the evidence should
only be accepted if the times are "close enough (e.g. less than a few
hours)".  Whilst hours may be a bit pessimistic for some systems, one only
has to consider the likely method of communication between the requestor and
the timestamp server to realise that a [leap] second either way is
irrelevant.  Certainly, two requests issued at almost the same time will not
necessarily arrive at the timestamp server in the same order as they were
dispatched.  If we really are concerned about establishing completely
unambiguously the order in which two documents are signed, a higher level
protocol is required e.g. one in which the second document contains the
timestamp of the first one.


Paul Halliden
Director for Strategic Technology
______________________________________________________________________
Baltimore, The Square, Basing View, Basingstoke, Hants, RG21 4EG, UK
Tel: [phone] Fax: [phone]
http://www.baltimore.com
Baltimore is the operating name of Zergo Holdings plc 



-----Original Message-----
From: Michael Zolotarev [mailto:[e-mail]]
Sent: 01 April 1999 09:00
To: 'Tony Bartoletti'; Todd S. Glassey; Paul Koning;
[e-mail]
Cc: [e-mail]; '[e-mail]';
'[e-mail]'
Subject: RE: Time-stamp server. TimePrecision info


Tony,

I guess there is a neater solution to the 'gain a leap second' problem, 
using the serialNumber field of the response. If the serialNumebr is 
properly maintained by the TSS, and returned to the client, a second can 
last as long as we want it:

time:  0.21           0.22              0.23        0.23        0.23 
      0.24
S/N:  1,2,3,4...   x,x+1,x+2...    n,n+1,n+2,n+3, n+4, n+..      m,m+1...

The issue is, the problem only exists when we COMPARE two stamps produced 
by THE SAME TSS. And this is exactly where the serialNumber will help us 
out.

In a situation when you compare the stamps produced by different servers, 
or compare a stamp to a 'Golden Rolex' time, a one second difference should 
be tolerated, as the sources are not expected to be highly synchronised 
anyway.

Michael Zolotarev
Technical Architect, Baltimore Technologies Limited (Australia)

Happy Easter!

-----Original Message-----
From:	Tony Bartoletti [SMTP:[e-mail]]
Sent:	Thursday, April 01, 1999 4:31 AM
To:	Todd S. Glassey; Paul Koning; [e-mail]
Cc:	[e-mail]
Subject:	Re: Time-stamp server. TimePrecision info

At 07:44 PM 3/30/99 -0800, Todd S. Glassey wrote:
>How will you deal with leap seconds?
>

The only solution I can think of would be UGLY, but would preserve
the all-important monotonicity.  At least it would work when a
leap-second is added. (Subtracting is another matter.  You would
already have monotonicity, but differencing might be difficult.)

Add another field to the "seconds", as little as one "bit", that
is always zero except for a leap-second, when it is "one."

  E.G.   leap.seconds.milliseconds

Now, if (say) the 23rd second of this minute had to be "repeated"
(the clock is being set back 1 second, "gaining" a leap second,)
then it would first occur as 0.23.ms, and then a second later
as 1.23.ms.

Thus, the sequence of timestamps of seconds from 21 to 25 might
be recorded as 0.21, 0.22, 0.23, 1.23, 0.24, 0.25, with

    0.23 < 1.23, and 1.23 < 0.24

Losing a leap-second (should that ever happen) is another matter.
One could just drop the "missing" second as the clock advances.
E.G.

    0.21, 0.22, 0.24, 0.25

Monotonicity is preserved.  Differencing is a headache.

I wonder how they will actually deal with this.

___tony___

Tony Bartoletti                                             LL
Center for Information Operations and Assurance          LL LL
Lawrence Livermore National Laboratory                LL LL LL
PO Box 808, L - 303                                   LL LL LL
Livermore, CA 94551-9900                              LL LL LLLLLLLL
phone: [phone]   fax: [phone]               LL LLLLLLLL
email: [e-mail]                                   LLLLLLLL

------_=_NextPart_001_01BE7C37.B4D0235C
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.2410.0">
<TITLE>RE: Time-stamp server. TimePrecision info</TITLE>
</HEAD>
<BODY>

<P><FONT SIZE=3D2>Are we missing a point here?&nbsp; The use of a =
timestamp server is to resolve questions such as &quot;At what time was =
a document signed?&quot;, &quot;In what order were documents =
signed?&quot; or &quot;At what time was a document =
received?&quot;.&nbsp; A timestamp server says &quot;I issued a =
timestamp for the document at xxxx date and time&quot;.&nbsp; In other =
words, there is not a precise time relationship between the event =
potentially in dispute and the generation of the timestamp.&nbsp; =
Appendix B of the current draft recognises this by saying that, when =
subsequently verifying a document is consistent with its timestamp, the =
evidence should only be accepted if the times are &quot;close enough =
(e.g. less than a few hours)&quot;.&nbsp; Whilst hours may be a bit =
pessimistic for some systems, one only has to consider the likely =
method of communication between the requestor and the timestamp server =
to realise that a [leap] second either way is irrelevant.&nbsp; =
Certainly, two requests issued at almost the same time will not =
necessarily arrive at the timestamp server in the same order as they =
were dispatched.&nbsp; If we really are concerned about establishing =
completely unambiguously the order in which two documents are signed, a =
higher level protocol is required e.g. one in which the second document =
contains the timestamp of the first one.</FONT></P>
<BR>

<P><FONT SIZE=3D2>Paul Halliden</FONT>
<BR><FONT SIZE=3D2>Director for Strategic Technology</FONT>
<BR><FONT =
SIZE=3D2>_______________________________________________________________=
_______</FONT>
<BR><FONT SIZE=3D2>Baltimore, The Square, Basing View, Basingstoke, =
Hants, RG21 4EG, UK</FONT>
<BR><FONT SIZE=3D2>Tel: [phone] Fax: [phone] =
812901</FONT>
<BR><FONT SIZE=3D2><A HREF=3D"http://www.baltimore.com" =
TARGET=3D"_blank">http://www.baltimore.com</A></FONT>
<BR><FONT SIZE=3D2>Baltimore is the operating name of Zergo Holdings =
plc </FONT>
</P>
<BR>
<BR>

<P><FONT SIZE=3D2>-----Original Message-----</FONT>
<BR><FONT SIZE=3D2>From: Michael Zolotarev [<A =
HREF=3D"mailto:[e-mail]">mailto:mzolotarev@baltimore.=
com.au</A>]</FONT>
<BR><FONT SIZE=3D2>Sent: 01 April 1999 09:00</FONT>
<BR><FONT SIZE=3D2>To: 'Tony Bartoletti'; Todd S. Glassey; Paul =
Koning;</FONT>
<BR><FONT SIZE=3D2>[e-mail]</FONT>
<BR><FONT SIZE=3D2>Cc: [e-mail]; =
'[e-mail]';</FONT>
<BR><FONT SIZE=3D2>'[e-mail]'</FONT>
<BR><FONT SIZE=3D2>Subject: RE: Time-stamp server. TimePrecision =
info</FONT>
</P>
<BR>

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

<P><FONT SIZE=3D2>I guess there is a neater solution to the 'gain a =
leap second' problem, </FONT>
<BR><FONT SIZE=3D2>using the serialNumber field of the response. If the =
serialNumebr is </FONT>
<BR><FONT SIZE=3D2>properly maintained by the TSS, and returned to the =
client, a second can </FONT>
<BR><FONT SIZE=3D2>last as long as we want it:</FONT>
</P>

<P><FONT SIZE=3D2>time:&nbsp; =
0.21&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
0.22&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp; 0.23&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
0.23&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 0.23 </FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 0.24</FONT>
<BR><FONT SIZE=3D2>S/N:&nbsp; 1,2,3,4...&nbsp;&nbsp; =
x,x+1,x+2...&nbsp;&nbsp;&nbsp; n,n+1,n+2,n+3, n+4, =
n+..&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; m,m+1...</FONT>
</P>

<P><FONT SIZE=3D2>The issue is, the problem only exists when we COMPARE =
two stamps produced </FONT>
<BR><FONT SIZE=3D2>by THE SAME TSS. And this is exactly where the =
serialNumber will help us </FONT>
<BR><FONT SIZE=3D2>out.</FONT>
</P>

<P><FONT SIZE=3D2>In a situation when you compare the stamps produced =
by different servers, </FONT>
<BR><FONT SIZE=3D2>or compare a stamp to a 'Golden Rolex' time, a one =
second difference should </FONT>
<BR><FONT SIZE=3D2>be tolerated, as the sources are not expected to be =
highly synchronised </FONT>
<BR><FONT SIZE=3D2>anyway.</FONT>
</P>

<P><FONT SIZE=3D2>Michael Zolotarev</FONT>
<BR><FONT SIZE=3D2>Technical Architect, Baltimore Technologies Limited =
(Australia)</FONT>
</P>

<P><FONT SIZE=3D2>Happy Easter!</FONT>
</P>

<P><FONT SIZE=3D2>-----Original Message-----</FONT>
<BR><FONT SIZE=3D2>From:&nbsp;&nbsp; Tony Bartoletti =
[SMTP:[e-mail]]</FONT>
<BR><FONT SIZE=3D2>Sent:&nbsp;&nbsp; Thursday, April 01, 1999 4:31 =
AM</FONT>
<BR><FONT SIZE=3D2>To:&nbsp;&nbsp;&nbsp;&nbsp; Todd S. Glassey; Paul =
Koning; [e-mail]</FONT>
<BR><FONT SIZE=3D2>Cc:&nbsp;&nbsp;&nbsp;&nbsp; [e-mail]</FONT>
<BR><FONT SIZE=3D2>Subject:&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
Re: Time-stamp server. TimePrecision info</FONT>
</P>

<P><FONT SIZE=3D2>At 07:44 PM 3/30/99 -0800, Todd S. Glassey =
wrote:</FONT>
<BR><FONT SIZE=3D2>&gt;How will you deal with leap seconds?</FONT>
<BR><FONT SIZE=3D2>&gt;</FONT>
</P>

<P><FONT SIZE=3D2>The only solution I can think of would be UGLY, but =
would preserve</FONT>
<BR><FONT SIZE=3D2>the all-important monotonicity.&nbsp; At least it =
would work when a</FONT>
<BR><FONT SIZE=3D2>leap-second is added. (Subtracting is another =
matter.&nbsp; You would</FONT>
<BR><FONT SIZE=3D2>already have monotonicity, but differencing might be =
difficult.)</FONT>
</P>

<P><FONT SIZE=3D2>Add another field to the &quot;seconds&quot;, as =
little as one &quot;bit&quot;, that</FONT>
<BR><FONT SIZE=3D2>is always zero except for a leap-second, when it is =
&quot;one.&quot;</FONT>
</P>

<P><FONT SIZE=3D2>&nbsp; E.G.&nbsp;&nbsp; =
leap.seconds.milliseconds</FONT>
</P>

<P><FONT SIZE=3D2>Now, if (say) the 23rd second of this minute had to =
be &quot;repeated&quot;</FONT>
<BR><FONT SIZE=3D2>(the clock is being set back 1 second, =
&quot;gaining&quot; a leap second,)</FONT>
<BR><FONT SIZE=3D2>then it would first occur as 0.23.ms, and then a =
second later</FONT>
<BR><FONT SIZE=3D2>as 1.23.ms.</FONT>
</P>

<P><FONT SIZE=3D2>Thus, the sequence of timestamps of seconds from 21 =
to 25 might</FONT>
<BR><FONT SIZE=3D2>be recorded as 0.21, 0.22, 0.23, 1.23, 0.24, 0.25, =
with</FONT>
</P>

<P><FONT SIZE=3D2>&nbsp;&nbsp;&nbsp; 0.23 &lt; 1.23, and 1.23 &lt; =
0.24</FONT>
</P>

<P><FONT SIZE=3D2>Losing a leap-second (should that ever happen) is =
another matter.</FONT>
<BR><FONT SIZE=3D2>One could just drop the &quot;missing&quot; second =
as the clock advances.</FONT>
<BR><FONT SIZE=3D2>E.G.</FONT>
</P>

<P><FONT SIZE=3D2>&nbsp;&nbsp;&nbsp; 0.21, 0.22, 0.24, 0.25</FONT>
</P>

<P><FONT SIZE=3D2>Monotonicity is preserved.&nbsp; Differencing is a =
headache.</FONT>
</P>

<P><FONT SIZE=3D2>I wonder how they will actually deal with =
this.</FONT>
</P>

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

<P><FONT SIZE=3D2>Tony =
Bartoletti&nbsp;&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;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; LL</FONT>
<BR><FONT SIZE=3D2>Center for Information Operations and =
Assurance&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; LL =
LL</FONT>
<BR><FONT SIZE=3D2>Lawrence Livermore National =
Laboratory&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp; LL LL LL</FONT>
<BR><FONT SIZE=3D2>PO Box 808, L - =
303&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; LL LL =
LL</FONT>
<BR><FONT SIZE=3D2>Livermore, CA 94551-9900&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=
; LL LL LLLLLLLL</FONT>
<BR><FONT SIZE=3D2>phone: [phone]&nbsp;&nbsp; fax: =
925-423-8002&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
&nbsp;&nbsp;&nbsp;&nbsp; LL LLLLLLLL</FONT>
<BR><FONT SIZE=3D2>email: =
[e-mail]&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;=
 LLLLLLLL</FONT>
</P>

</BODY>
</HTML>
------_=_NextPart_001_01BE7C37.B4D0235C--


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id EAA20712 for ietf-pkix-bks; Thu, 1 Apr 1999 04:11:06 -0800 (PST)
Received: from svlcapop1.ins.com (svlcapop1.ins.com [199.0.193.49]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id EAA20708 for <[e-mail]>; Thu, 1 Apr 1999 04:11:04 -0800 (PST)
Received: (from youngl_r@localhost) by svlcapop1.ins.com (8.8.8+Sun/8.8.8) id EAA18210; Thu, 1 Apr 1999 04:11:16 -0800 (PST)
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1 
Date: Thu, 01 Apr 1999 07:11:12 -0500
To: "Peter Williams" <[e-mail]>
From: Roger Younglove <[e-mail]>
Subject: Re: Changes to RFC2459
Cc: "[e-mail]" <[e-mail]>
In-Reply-To: <006301be7baf$2bb70320$[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

I agree, when an unknown certificate is introduced into your PKI the only
safe way to accept it would be to check the Certificate Policy identified
in cert policy id. 
At 02:46 PM 3/31/99 , you wrote:
>
>-----Original Message-----
>From: Jim Schaad (Exchange) <[e-mail]>
>To: 'Stephen Kent' <[e-mail]>; Moshe Litvin <[e-mail]>
>Cc: [e-mail] <[e-mail]>
>Date: Wednesday, March 31, 1999 3:04 PM
>Subject: RE: Changes to RFC2459
>
>
>>Steve,
>>
>I think it is important to note that
>>there is nothing in a certificate that says I am PKIX compliant.  This
>>certificate could have been issued by somebody following the boondogle X509
>>certificate profile,:) and we are interpreting it under a different
>profile.
>>If we make sure the profile can make explicit statements then we don't have
>>this issue.
>
>
>
>The cert policy id field is surely usable as a CA-signal that a profile is
>in use,
>and its assurances enable one to trust that a cert conforms to a
>profile. relying parties require particular extension schemas etc, by
>requiring
>particular cert policy ids, or local policy id mappings.
>

--
TTFN

Roger W. Younglove                            Blue Cross Blue Shield Michigan
Network Systems Consultant                313-225-0637 on site
International Network Services
100 Galleria Officentre Ste. 220
Southfield, MI 48034
E-mail page:
[e-mail]
Numeric page: 888.935.6755


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id AAA10335 for ietf-pkix-bks; Thu, 1 Apr 1999 00:00:38 -0800 (PST)
Received: from stargate.zergo.com.au ([e-mail] [203.2.208.130]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id AAA10331 for <[e-mail]>; Thu, 1 Apr 1999 00:00:34 -0800 (PST)
Received: from michaelz (dhcp-64.ws.zergo.com.au [192.168.72.64]) by stargate.zergo.com.au (8.9.1/8.8.7) with SMTP id RAA16093; Thu, 1 Apr 1999 17:59:40 +1000
Received: by localhost with Microsoft MAPI; Thu, 1 Apr 1999 17:59:41 +1000
Message-ID: <[e-mail]>
From: Michael Zolotarev <[e-mail]>
Reply-To: "[e-mail]" <[e-mail]>
To: "'Tony Bartoletti'" <[e-mail]>, "Todd S. Glassey" <[e-mail]>, Paul Koning <[e-mail]>, "[e-mail]" <[e-mail]>
Cc: "[e-mail]" <[e-mail]>, "'[e-mail]'" <[e-mail]>, "'[e-mail]'" <[e-mail]>
Subject: RE: Time-stamp server. TimePrecision info
Date: Thu, 1 Apr 1999 17:59:39 +1000
Organization: Baltimore Pty Ltd
X-Mailer: Microsoft Internet E-mail/MAPI - 8.0.0.4211
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Tony,

I guess there is a neater solution to the 'gain a leap second' problem, 
using the serialNumber field of the response. If the serialNumebr is 
properly maintained by the TSS, and returned to the client, a second can 
last as long as we want it:

time:  0.21           0.22              0.23        0.23        0.23 
      0.24
S/N:  1,2,3,4...   x,x+1,x+2...    n,n+1,n+2,n+3, n+4, n+..      m,m+1...

The issue is, the problem only exists when we COMPARE two stamps produced 
by THE SAME TSS. And this is exactly where the serialNumber will help us 
out.

In a situation when you compare the stamps produced by different servers, 
or compare a stamp to a 'Golden Rolex' time, a one second difference should 
be tolerated, as the sources are not expected to be highly synchronised 
anyway.

Michael Zolotarev
Technical Architect, Baltimore Technologies Limited (Australia)

Happy Easter!

-----Original Message-----
From:	Tony Bartoletti [SMTP:[e-mail]]
Sent:	Thursday, April 01, 1999 4:31 AM
To:	Todd S. Glassey; Paul Koning; [e-mail]
Cc:	[e-mail]
Subject:	Re: Time-stamp server. TimePrecision info

At 07:44 PM 3/30/99 -0800, Todd S. Glassey wrote:
>How will you deal with leap seconds?
>

The only solution I can think of would be UGLY, but would preserve
the all-important monotonicity.  At least it would work when a
leap-second is added. (Subtracting is another matter.  You would
already have monotonicity, but differencing might be difficult.)

Add another field to the "seconds", as little as one "bit", that
is always zero except for a leap-second, when it is "one."

  E.G.   leap.seconds.milliseconds

Now, if (say) the 23rd second of this minute had to be "repeated"
(the clock is being set back 1 second, "gaining" a leap second,)
then it would first occur as 0.23.ms, and then a second later
as 1.23.ms.

Thus, the sequence of timestamps of seconds from 21 to 25 might
be recorded as 0.21, 0.22, 0.23, 1.23, 0.24, 0.25, with

    0.23 < 1.23, and 1.23 < 0.24

Losing a leap-second (should that ever happen) is another matter.
One could just drop the "missing" second as the clock advances.
E.G.

    0.21, 0.22, 0.24, 0.25

Monotonicity is preserved.  Differencing is a headache.

I wonder how they will actually deal with this.

___tony___

Tony Bartoletti                                             LL
Center for Information Operations and Assurance          LL LL
Lawrence Livermore National Laboratory                LL LL LL
PO Box 808, L - 303                                   LL LL LL
Livermore, CA 94551-9900                              LL LL LLLLLLLL
phone: [phone]   fax: [phone]               LL LLLLLLLL
email: [e-mail]                                   LLLLLLLL