RE: X9.42 and RFC2459 inconsistency?

["John Hughes" <[e-mail]>]

Andrew,

we had some discussion within Entegrity back in March on this whole issue -
and as we wanted to get D-H support out into the market with the Entegrity
SDP we had to make some decisions.  As I'm about to go on vacation
unfortunately I've not the time to detail what we did.  Hopefully some of my
colleagues who are also on the list can provide the input on what we did.


John


> -----Original Message-----
> From: Andrew Farrell [mailto:[e-mail]]
> Sent: 31 July 1999 15:23
> To: John Hughes
> Cc: [e-mail]; [e-mail]
> Subject: Re: X9.42 and RFC2459 inconsistency?
>
>
> In message <002701bedade$9c1f10138d90a@joh-laptop>you write:
> >We can generate D-H certificates - and we use the rfc 2459 dhpublicnumber
> >OID.
>
> You mean the X9.42 oid with the pfc 2459 semantics? Do you have serious
> "Permanent root for paying customer" certs using this out there? And if
> so, why? :)
>
> >John
>
> Andrew.
>




Received: from tantalum.btinternet.com (tantalum.btinternet.com [194.73.73.80]) by mail.proper.com (8.9.3/8.9.3) with ESMTP id NAA18184; Sat, 31 Jul 1999 13:28:12 -0700 (PDT)
Received: from [195.99.52.9] (helo=joh-laptop) by tantalum.btinternet.com with smtp (Exim 2.05 #1) id 11AfmG-0002E1-00; Sat, 31 Jul 1999 21:30:44 +0100
From: "John Hughes" <[e-mail]>
To: "Andrew Farrell" <[e-mail]>
Cc: "Sinisa Cicovic" <[e-mail]>, "Peter Siklosi" <[e-mail]>, <[e-mail]>, <[e-mail]>
Subject: RE: X9.42 and RFC2459 inconsistency? 
Date: Sat, 31 Jul 1999 21:34:15 +0100
Message-ID: <000a01bedb94$0e50ed60$0138d90a@joh-laptop>
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
In-Reply-To: <[e-mail]>
X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3

Andrew,

we had some discussion within Entegrity back in March on this whole issue -
and as we wanted to get D-H support out into the market with the Entegrity
SDP we had to make some decisions.  As I'm about to go on vacation
unfortunately I've not the time to detail what we did.  Hopefully some of my
colleagues who are also on the list can provide the input on what we did.


John


> -----Original Message-----
> From: Andrew Farrell [mailto:[e-mail]]
> Sent: 31 July 1999 15:23
> To: John Hughes
> Cc: [e-mail]; [e-mail]
> Subject: Re: X9.42 and RFC2459 inconsistency?
>
>
> In message <002701bedade$9c1f10138d90a@joh-laptop>you write:
> >We can generate D-H certificates - and we use the rfc 2459 dhpublicnumber
> >OID.
>
> You mean the X9.42 oid with the pfc 2459 semantics? Do you have serious
> "Permanent root for paying customer" certs using this out there? And if
> so, why? :)
>
> >John
>
> Andrew.
>



Received: from puma.baltimore.ie ([e-mail] [194.125.215.8]) by mail.proper.com (8.9.3/8.9.3) with ESMTP id HAA14924; Sat, 31 Jul 1999 07:20:09 -0700 (PDT)
Received: by puma.baltimore.ie; id QAA18095; Sat, 31 Jul 1999 16:17:00 +0100 (GMT/IST)
Received: from bobcat.baltimore.ie(192.168.20.10) by puma.baltimore.ie via smap (4.1) id xma018090; Sat, 31 Jul 99 16:16:54 +0100
Received: from ocelot.baltimore.ie (IDENT:[e-mail] [192.168.21.10]) by bobcat.baltimore.ie (8.9.3/8.9.3) with ESMTP id PAA19736; Sat, 31 Jul 1999 15:24:18 +0100
Received: from ocelot.baltimore.ie (afarrell@localhost [127.0.0.1]) by ocelot.baltimore.ie (8.8.7/8.8.7) with ESMTP id PAA08136; Sat, 31 Jul 1999 15:22:59 +0100
Message-Id: <[e-mail]>
To: "John Hughes" <[e-mail]>
Cc: [e-mail], [e-mail]
Subject: Re: X9.42 and RFC2459 inconsistency? 
In-Reply-To: Your message of "Fri, 30 Jul 1999 23:55:24 BST." <002701bedade$9c1f1470$0138d90a@joh-laptop> 
Date: Sat, 31 Jul 1999 15:22:59 +0100
From: Andrew Farrell <[e-mail]>

In message <002701bedade$9c1f1470$0138d90a@joh-laptop>you write:
>We can generate D-H certificates - and we use the rfc 2459 dhpublicnumber
>OID.

You mean the X9.42 oid with the pfc 2459 semantics? Do you have serious
"Permanent root for paying customer" certs using this out there? And if
so, why? :) 

>John

Andrew.


Received: from carbon.btinternet.com (carbon.btinternet.com [194.73.73.92]) by mail.proper.com (8.9.3/8.9.3) with ESMTP id PAA16178; Fri, 30 Jul 1999 15:49:28 -0700 (PDT)
Received: from [195.99.53.18] (helo=joh-laptop) by carbon.btinternet.com with smtp (Exim 2.05 #1) id 11ALVP-0007ZQ-00; Fri, 30 Jul 1999 23:51:59 +0100
From: "John Hughes" <[e-mail]>
To: <[e-mail]>, <[e-mail]>, <[e-mail]>
Subject: RE: X9.42 and RFC2459 inconsistency?
Date: Fri, 30 Jul 1999 23:55:24 +0100
Message-ID: <002701bedade$9c1f1470$0138d90a@joh-laptop>
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.3110.3
In-Reply-To: <[e-mail]>

We can generate D-H certificates - and we use the rfc 2459 dhpublicnumber
OID.

John

(Entegrity Solutions)

> -----Original Message-----
> From: [e-mail] [mailto:[e-mail]]
> Sent: 31 July 1999 03:47
> To: [e-mail]; [e-mail]
> Subject: Re: X9.42 and RFC2459 inconsistency?
>
>
> Andrew Farrell <[e-mail]> writes:
>
> >(1) Are there any deployed codebases which would object to changing the
> >Diffie-Hellman OID in rfc2459 to reflect the fact that it has different
> >semantics than in X9.42?
> >
> >I know that John Pawling has stated that Van Dyke's S/MIME
> Freeware Library
> >has no issues, and as far as I know Microsoft haven't shipped
> anything with
> >Diffie-Hellman, so that S/MIME would appear to be in the clear on this.
>
> Some of the OpenSSL people have complained in the past that they
> haven't been
> able to find any examples of DH certs to test, and I've never
> seen one either,
> so if anyone has implemented this they're keeping it very well hidden.
>
> Actually the solution to this problem is easy, just switch back
> to the PKCS #3
> OID which was the one which noone was using before they switched
> to not using
> X9.42.  This is far more sensible:
>
> DHPublicKey ::= INTEGER
>
> Parameters ::= SEQUENCE {
>     prime INTEGER,      -- p
>     base  INTEGER,      -- g
>     privateValueLength INTEGER OPTIONAL
>     }
>
> You can't get the parameters for that wrong (well, not without a lot of
> effort).
>
> (A problem with this is that it doesn't accommodate X9.42's q and
> j.  If PKIX
>  is going to define a new OID without the asking-for-trouble
> X9.42 semantics,
>  it'd be good to have q and j OPTIONAL to allow key generation techniques
>  other than the FIPS 186 kosherizer, which is both unnecessarily
> inefficient
>  (when used to generate DH keys) and generates unsafe keys,
> requiring further
>  band-aids - draft-ietf-smime-small-subgroup.txt - to make their
> use safe.  In
>  contrast key generation techniques like Lim-Lee are both faster
> and generate
>  keys which are immune to this problem, but are excluded from use
> by the need
>  to provide a q value in the AlgorithmIdentifier).
>
> Peter.
>
>



Received: from mailbox1.appliedtheory.com (mailbox1.appliedtheory.com [204.168.16.14]) by mail.proper.com (8.9.3/8.9.3) with ESMTP id PAA15605 for <[e-mail]>; Fri, 30 Jul 1999 15:01:45 -0700 (PDT)
From: [e-mail]
Received: from eaglei-internet.ssg.bny.com (bk01.bankofny.com [160.254.115.80]) by mailbox1.appliedtheory.com (8.8.8/8.8.8) with SMTP id SAA11984; Fri, 30 Jul 1999 18:03:56 -0400 (EDT)
Received: from Hermes.bankofny.com by eaglei-internet.ssg.bny.com via smtpd (for mailbox1.appliedtheory.com [204.168.16.14]) with SMTP; 30 Jul 1999 22:03:56 UT
Received: from LNOTES5 by HERMES via SMTP with TCP; Fri, 30 Jul 99 10:48:28-EDT
Received: from LNOTES5 by HERMES via SMTP with TCP; Fri, 30 Jul 99 10:48:30-EDT
Received: by LNOTES5(Lotus SMTP MTA v1.2  (600.1 3-26-1998))  id 852567BE.00516877 ; Fri, 30 Jul 1999 10:49:11 -0400
X-Lotus-FromDomain: BNY
To: Russ Housley <[e-mail]>
cc: Ed Gerck <[e-mail]>, "'[e-mail]'" <[e-mail]>
Message-ID: <852567BE.004E1239.00@LNOTES5>
Date: Fri, 30 Jul 1999 10:48:46 -0400
Subject: Re: Common misconceptions, was Re: KISS for PKIX. (Was: RE: ASN .1vs XML (used to be RE: I-D ACTION :draft-ietf-pkix-scvp- 00.txt ))
Mime-Version: 1.0
Content-type: text/plain; charset=us-ascii
Content-Disposition: inline

I believe a prompt (challenge) for a password to enable use of the private
key for signing purposes is necessary in some instances. Automatic signing
of a message by software always creates the potential for a repudiation
claim by the sender, either because the software was accessed by an
unauthorized party to effect an unauthorized transaction or because the
authorized party is attempting to defraud by claiming the transaction was
not authorized. In either case, the burden is on the recipient to prove
otherwise.

The need for the challenge depends on how strongly the receiving party
wants to preclude repudiation claims based on the significance of the
transmitted message. A bank receiving a message to transfer funds could
require the challenge for every message. Of course, it could reduce the
risk by requiring verification of the instructions by a second party, but
is unlikely to do this for consumer accounts. A merchant processing a sales
order might not care, since it will process the payment first.

regards,
eric







Challenge-response protocols are not needed for non-repudiation.  Such a
protocol might be used, but it is not required.  For example, a digitally
signed S/MIME message might provide non-repudiation and no
challenge-response protocol is involved.

Russ


At 10:54 AM 7/23/99 -0700, Ed Gerck wrote:


>Jan Nielsen wrote:
>
> > Hi Ed,
> >
> > > which may explain your off-the-point remark.
> >
> > No...I simply skimmed the thread instead of r-e-a-d-i-n-g it.  Sorry
> about that.
>
>;-) short postings cannot reflect content, long postings tend to be unread
>and thus also
>not reflect content -- but, at least, content is there.
>
> > My comments were actually addressing the non-repudiation of a user's
> actions, not digital
> > signatures, in systems which rely on SSL client authentication for user
> authentication as opposed to
> > password authentication.  My point is simply that because of poor key
> management facilities on the
> > client and poor physical security of the device that repudiation of the
> user authentication is more
> > likely with SSL client authentication than with a password system.
>
>Perhaps you still skimmed the thread too much. A password system such as
>what is called
>"weak authentication" in X.509 is not able to provide NR at all, as I
>wrote before:
>
>} ...basically, the reason is that  passwords have no challenge-response
>mechanism.
>} Since a password can be replayed at will, the authenticating party (ie,
>the verifier)
>} is barred from presenting an argument of non-repudiation when passwords
>are used
>} because the verifier could have generated any message all by itself --
>the data is
>} intrinsically corrupted.
>
>So, any client authentication SSL system can provide more *evidences* (and
>I can't
>overstress the importance of this word here) of NR than any weak
>authentication
>(ie, password) system is ever capable of -- in other words, any NR
>evidence is more
>than zilch ;-)
>
>Cheers,
>
>Ed Gerck







Received: from rbhub100.chamb.disa.mil (rbhub100.chamb.disa.mil [209.22.120.23]) by mail.proper.com (8.9.3/8.9.3) with ESMTP id LAA13146 for <[e-mail]>; Fri, 30 Jul 1999 11:57:09 -0700 (PDT)
Received: by rbhub100.chamb.disa.mil with Internet Mail Service (5.5.2448.0) id <P53DGPDP>; Fri, 30 Jul 1999 14:59:51 -0400
Message-ID: <[e-mail]>
From: "Flanigan, Bill" <[e-mail]>
To: "'Robert Moskowitz'" <[e-mail]>
Cc: [e-mail]
Subject: RE: LAST CALL: draft-ietf-pkix-cmc-05.txt
Date: Fri, 30 Jul 1999 15:03:16 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2448.0)
Content-Type: text/plain

Robert,

	Wow!  You have surfaced something I have long worried about, and I
bet a lot of other folks have also.  
	Are we sliding down the slippery ISO slope or are we already at the
bottom with em?!  *Interoperability* aggressively not defined; I-Ds
progressed to Proposed RFC with the hope that they might turn out to work in
an *interoperable environment*; implementers that say *trust us, it's
interoperable* so progress to Draft RFC, then to Standard; no formal peer
review of interoperability claims prior to standards-track advancement; no
formal, independent, third-party evaluation of interoperability claims prior
to standards-track advancement ... .  
	And, like you ask, does any of this matter?  But, Bob, it simply
MUST matter to someone.  Hmm, let me think now, there must be someone it
matters to, er...oh yes, I've got it:  it's the customer!

Bill

> ----------
> From: 	Robert Moskowitz[SMTP:[e-mail]]
> Sent: 	Friday, July 30, 1999 10:15 AM
> To: 	Flanigan, Bill; [e-mail]
> Subject: 	RE: LAST CALL: draft-ietf-pkix-cmc-05.txt
> 
[snip]

Steve, rightly pointed out
that the IETF/IESG have historically NOT defined what interop means; they
leave it to the vendors.

[snip]

> Now no cheating here.  
> 
[snip]

> Now put on a co-chair and/or AD hat.  How do you tell when a handful of
> vendors come to you and say "we interop", that they did.  Or does any of
> this really matter?
> 
> 
> 
> Robert Moskowitz
> ICSA
> Security Interest EMail: [e-mail]
> 


Received: from arista.iris.com (arista.iris.com [198.112.211.22]) by mail.proper.com (8.9.3/8.9.3) with ESMTP id LAA12867 for <[e-mail]>; Fri, 30 Jul 1999 11:36:10 -0700 (PDT)
From: [e-mail]
Subject: RE: LAST CALL: draft-ietf-pkix-cmc-05.txt
To: [e-mail]
Cc: 
X-Mailer: Lotus Notes PVCS Build (based on 165)  "Mar 12 1999"
Message-ID: <[e-mail]>
Date: Fri, 30 Jul 1999 14:39:58 -0400
X-Priority: 3 (Normal)
X-MIMETrack: Serialize by Router on Arista/Iris(Build V5010621|June 21, 1999) at 07/30/99 02:38:48 PM
MIME-Version: 1.0
Content-type: text/plain; charset=us-ascii

As someone who was at both of the workshops I can honestly say that
nightmare and dismal  do not accuratly describe the
results we have been seeing.  By the end of the second workshop most of the
participants were exchanging cert requests
and responses with most of the other participants. This was accomplished
with out having to make any changes from what is
in the current RFC.

Unfortunatly a poor choice of words has caused this discussion to turn from
a suggestion of a possible better way to
do things to a perceived roasting of CMP.



                              Mike




Received: from prv-mail20.provo.novell.com (prv-mail20.provo.novell.com [137.65.82.195]) by mail.proper.com (8.9.3/8.9.3) with SMTP id IAA10823; Fri, 30 Jul 1999 08:47:40 -0700 (PDT)
Received: from INET-PRV-Message_Server by prv-mail20.provo.novell.com with Novell_GroupWise; Fri, 30 Jul 1999 09:50:01 -0600
Message-Id: <[e-mail]>
X-Mailer: Novell GroupWise 5.5.2
Date: Fri, 30 Jul 1999 09:49:53 -0600
From: "Tolga Acar" <[e-mail]>
To: <[e-mail]>, <[e-mail]>, <[e-mail]>
Subject: Re: X9.42 and RFC2459 inconsistency?
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 IAB10825

A note to consider:
"DHPublicKey" has an implied meaning that the Diffie-Hellman algorithm is the discrete logarithm version based on unsigned integer operations. However, this is not the only version of DH. There is an integer version with cofactor exponentiation, and similarly there are elliptic curve versions, with and without cofactor multiplication. 
In the search of a "standard" OID and its associated parameters, these should be considered as well, including the naming, which may be misleading.
One place to look at would be the IEEE P1363 effort on public-key standards.

- Tolga

>>> Peter Gutmann <[e-mail]> 7/31/99 2:47:28 >>>
Andrew Farrell <[e-mail]> writes:

>(1) Are there any deployed codebases which would object to changing the
>Diffie-Hellman OID in rfc2459 to reflect the fact that it has different
>semantics than in X9.42?
>
>I know that John Pawling has stated that Van Dyke's S/MIME Freeware Library 
>has no issues, and as far as I know Microsoft haven't shipped anything with 
>Diffie-Hellman, so that S/MIME would appear to be in the clear on this.

Some of the OpenSSL people have complained in the past that they haven't been 
able to find any examples of DH certs to test, and I've never seen one either,
so if anyone has implemented this they're keeping it very well hidden.

Actually the solution to this problem is easy, just switch back to the PKCS #3
OID which was the one which noone was using before they switched to not using
X9.42.  This is far more sensible:

DHPublicKey ::= INTEGER

Parameters ::= SEQUENCE {
    prime INTEGER,      -- p
    base  INTEGER,      -- g
    privateValueLength INTEGER OPTIONAL
    }

You can't get the parameters for that wrong (well, not without a lot of 
effort).

(A problem with this is that it doesn't accommodate X9.42's q and j.  If PKIX
 is going to define a new OID without the asking-for-trouble X9.42 semantics,
 it'd be good to have q and j OPTIONAL to allow key generation techniques 
 other than the FIPS 186 kosherizer, which is both unnecessarily inefficient 
 (when used to generate DH keys) and generates unsafe keys, requiring further 
 band-aids - draft-ietf-smime-small-subgroup.txt - to make their use safe.  In
 contrast key generation techniques like Lim-Lee are both faster and generate 
 keys which are immune to this problem, but are excluded from use by the need 
 to provide a q value in the AlgorithmIdentifier).

Peter.




Received: from mail.student.auckland.ac.nz (mail.student.auckland.ac.nz [130.216.35.101]) by mail.proper.com (8.9.3/8.9.3) with ESMTP id HAA09935; Fri, 30 Jul 1999 07:51:38 -0700 (PDT)
Received: from kahu.cs.auckland.ac.nz ([e-mail] [130.216.36.13]) by mail.student.auckland.ac.nz (8.8.6/8.8.6/cs-master) with SMTP id CAA19988; Sat, 31 Jul 1999 02:54:09 +1200 (NZST) (sender [e-mail])
Received: by kahu.cs.auckland.ac.nz (relaymail v0.9) id <93334604825242>; Sat, 31 Jul 1999 02:47:28 (NZST)
From: [e-mail] (Peter Gutmann)
To: [e-mail], [e-mail]
Subject: Re: X9.42 and RFC2459 inconsistency?
Sender: [e-mail]
Reply-To: [e-mail]
X-Charge-To: pgut001
X-Authenticated: relaymail v0.9 on kahu.cs.auckland.ac.nz
Date: Sat, 31 Jul 1999 02:47:28 (NZST)
Message-ID: <[e-mail]>

Andrew Farrell <[e-mail]> writes:

>(1) Are there any deployed codebases which would object to changing the
>Diffie-Hellman OID in rfc2459 to reflect the fact that it has different
>semantics than in X9.42?
>
>I know that John Pawling has stated that Van Dyke's S/MIME Freeware Library 
>has no issues, and as far as I know Microsoft haven't shipped anything with 
>Diffie-Hellman, so that S/MIME would appear to be in the clear on this.

Some of the OpenSSL people have complained in the past that they haven't been 
able to find any examples of DH certs to test, and I've never seen one either,
so if anyone has implemented this they're keeping it very well hidden.

Actually the solution to this problem is easy, just switch back to the PKCS #3
OID which was the one which noone was using before they switched to not using
X9.42.  This is far more sensible:

DHPublicKey ::= INTEGER

Parameters ::= SEQUENCE {
    prime INTEGER,      -- p
    base  INTEGER,      -- g
    privateValueLength INTEGER OPTIONAL
    }

You can't get the parameters for that wrong (well, not without a lot of 
effort).

(A problem with this is that it doesn't accommodate X9.42's q and j.  If PKIX
 is going to define a new OID without the asking-for-trouble X9.42 semantics,
 it'd be good to have q and j OPTIONAL to allow key generation techniques 
 other than the FIPS 186 kosherizer, which is both unnecessarily inefficient 
 (when used to generate DH keys) and generates unsafe keys, requiring further 
 band-aids - draft-ietf-smime-small-subgroup.txt - to make their use safe.  In
 contrast key generation techniques like Lim-Lee are both faster and generate 
 keys which are immune to this problem, but are excluded from use by the need 
 to provide a q value in the AlgorithmIdentifier).

Peter.



Received: from homebase.htt-consult.com (homebase.htt-consult.com [208.235.169.130]) by mail.proper.com (8.9.3/8.9.3) with SMTP id HAA08849 for <[e-mail]>; Fri, 30 Jul 1999 07:13:50 -0700 (PDT)
Received: from rgm ([208.235.169.131]) by homebase.htt-consult.com ; Fri, 30 Jul 1999 10:16:28 -0500
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1 
Date: Fri, 30 Jul 1999 10:15:55 -0400
To: "Flanigan, Bill" <[e-mail]>, [e-mail]
From: Robert Moskowitz <[e-mail]>
Subject: RE: LAST CALL: draft-ietf-pkix-cmc-05.txt
In-Reply-To: <[e-mail].d isa.mil>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"

At 04:17 PM 7/28/99 -0400, Flanigan, Bill wrote:

>(or better yet, proactively resist the temptation
>and pressure to move on to the standards track until two implementers
>swear--and digitally sign it--they have achieved interop)

Now figure out what that means for 2549, Bill.  Steve, rightly pointed out
that the IETF/IESG have historically NOT defined what interop means; they
leave it to the vendors.

Now no cheating here.  We can't have everyone use the same ANS.1 parser
library.  Got to have 2 independent implementations of those (remember what
happened with AH and ESP with the RSA and Cylink libraries; actually it was
SHA1 and D-H).  We also cannot have everyone use same RSA algorithm library.  

Now put on a co-chair and/or AD hat.  How do you tell when a handful of
vendors come to you and say "we interop", that they did.  Or does any of
this really matter?



Robert Moskowitz
ICSA
Security Interest EMail: [e-mail]


Received: from homebase.htt-consult.com (homebase.htt-consult.com [208.235.169.130]) by mail.proper.com (8.9.3/8.9.3) with SMTP id HAA08843 for <[e-mail]>; Fri, 30 Jul 1999 07:13:49 -0700 (PDT)
Received: from rgm ([208.235.169.131]) by homebase.htt-consult.com ; Fri, 30 Jul 1999 10:16:27 -0500
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1 
Date: Fri, 30 Jul 1999 10:08:47 -0400
To: "David P. Kemp" <[e-mail]>, [e-mail]
From: Robert Moskowitz <[e-mail]>
Subject: RE: LAST CALL: draft-ietf-pkix-cmc-05.txt
In-Reply-To: <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"

At 02:05 PM 7/28/99 -0400, David P. Kemp wrote:

I think David captures much of our current standards/implement/deploy
philosophy today in the IETF.  If we could just get those pesty reporters
and users to leave us alone while we shake out the bugs.....  :)

What this means to me, however, is now that CMC IS in last call, there had
better be vendors committed to developing against it and THEY can estimate
time to testable code and thus plan for their workshops and we MIGHT expect
to see a report on CMC at DC.


>> From: "Flanigan, Bill" <[e-mail]>
>> 
>> Slapping an RFC number on half-baked protocols is indeed experimental.  So
>> why not make it so (pro-actively for CMC and retro-actively for CMP)?  And
>> what's wrong with progressing from Experimental to new I-D to Proposed when
>> the darn thing finally works?  I believe that vendors and early adopters
>> striving to be open-standards compliant are growing weary of being PKIX
>> guinea pigs (which seems tantamount to being played for suckers).
>> 
>> Bill
>
>
>"Half-baked protocols" is pretty strong language.  The CMP interoperability
>status could be the result of:
>1) errors in the protocol, which would prevent a single compliant
>    implementation from functioning correctly,
>2) ambiguities in the protocol, in which two compliant implementations
>    would not necessarily interoperate, and
>3) errors or omissions in the implementations which cause them to be
>    non-compliant with the protocol specifications as written.
>
>Identifying and correcting instances of 2) is clearly one of the functions
>of the IETF standards track.
>
>Early adopters should probably refer to RFC2026:
>
>   "Implementors should treat Proposed Standards as immature
>   specifications.  It is desirable to implement them in order to gain
>   experience and to validate, test, and clarify the specification.
>                                         ^^^^^^^
>   However, since the content of Proposed Standards may be changed if
>   problems are found or better solutions are identified, deploying
>   implementations of such standards into a disruption-sensitive
>   environment is not recommended."
>
>One can only strive to be standards-compliant when there is a Standard
>(not a Proposed or Draft Standard) to comply with.  How would
>designating CMC or CMP as Experimental or I-D assist early adopters in
>not feeling like guinea pigs?  If your boss tells you to implement a
>prototype (as a vendor) or pilot (as a user), your choice is to ignore
>him and do nothing until there is a Standard, or implement the
>specifications that are available.  If you are an early adopter, you
>are a guinea pig, whether you adopt an Experimental RFC or a Proposed
>Standard RFC.
>
>We in the DMS and now DoD PKI arena are very much guinea pigs, and
>there is nothing constructive we can do about it except continue to
>design, implement and test.  Other PKIX constituents are in the same
>boat.  There's nothing wrong with that; it's part of being in an Open
>process (or a democracy, or a free-market economy, or whatever).

Robert Moskowitz
ICSA
Security Interest EMail: [e-mail]


Received: from homebase.htt-consult.com (homebase.htt-consult.com [208.235.169.130]) by mail.proper.com (8.9.3/8.9.3) with SMTP id HAA08537; Fri, 30 Jul 1999 07:02:18 -0700 (PDT)
Received: from rgm ([208.235.169.131]) by homebase.htt-consult.com ; Fri, 30 Jul 1999 10:04:54 -0500
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1 
Date: Fri, 30 Jul 1999 09:59:48 -0400
To: Paul Hoffman / IMC <[e-mail]>, [e-mail]
From: Robert Moskowitz <[e-mail]>
Subject: Re: LAST CALL: draft-ietf-pkix-cmc-05.txt
In-Reply-To: <[e-mail]>
References: <[e-mail] >
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"

At 01:59 PM 7/27/99 -0700, Paul Hoffman / IMC wrote:
>At 01:12 PM 7/27/1999 -0700, Warwick Ford wrote:
>>This document is hereby issued for 14-day WG last call.
>
>OK, here's a tricky question: has anyone actually implemented the current 
>draft? If not, should we try to move it forwards?

The IETF has long since moved away for those days where it documented what
engineers got to work to now where it documents what engneers THINK they
can get to work.  We all know that and try to get on with our lives.  Of
course we have sold the media the original bill of goods...

>I ask this because of the dismal track record of CMP. Many months after it 
>was put on standards track, interoperability testing began, and it was 
>found to be a nightmare that will almost assuredly cause the spec to be 
>rewritten for clarification, and possibly to change bits on the wire. (See 
>draft-moskowitz-cmpinterop for more information on the testing.)

Well, the RFC is dated Mar '99 and the first interop testing was in May
'99.  As you have indicated, you have run workshops.  I would think that 2
months from first planing meeting to engineers with code in a room is
pretty good.

Now for perhaps the first time we actually capture the lessons learned in
the workshop for all of those that are tuning up their programming engines.
 Specs often are sparse, and authors sometimes loose the forest for the
trees.  So when you get two minds (and sometimes two cultures, Canadian and
Irish :) actually we had much of the english flavor there:  American,
Canadian, English, Irish; all we needed where the OpenSSL Austrialians :) )
together you can learn ways to improve on spec clarity.  Most of the items
raised at the wrokshops center on spec clarity.

The sooner spec clarity is addressed the sooner newcomers will Do It Right
The First Time  (DIRTFoot, a business culture we cultivated back at
Chrysler).  Now I am NOT taking shots at any author.  We can all improve
our writing, and spec writing is NOT easy.  I know that IPsec gained a lot
when the SSH fellows read the specs.

>If no one has what they think of as a full implementation of CMC, I propose 
>that we wait until at least one person does. If we have only one 
>implementation of CMC, I suggest that we ask for it to be made an 
>Experimental Standard instead of a Proposed Standard. If we have two 
>implementations that can at least talk to each other a little bit, let's 
>try to get it to become a Proposed Standard.

Boy I would LOVE to get changes like this through POISSON.  But business
reality blocks us.  We had many IAB/IESG debates on this and got no where.

HOWEVER, a community that can go to their consumers with strong statements
that "we worked these specs through REAL code and REAL WORLD scenarios"
will get faster acceptance IMHO.

>I realize that these are *not* the rules as defined in RFC 2026, but due to 
>our lack of attention on CMP, I think we have to be more careful with CMC.

Gee it would be nice, and I am willing (though my 4 cyclinder is perhaps
not able) to pitch in.


Robert Moskowitz
ICSA
Security Interest EMail: [e-mail]


Received: from puma.baltimore.ie ([e-mail] [194.125.215.8]) by mail.proper.com (8.9.3/8.9.3) with ESMTP id GAA07956; Fri, 30 Jul 1999 06:18:55 -0700 (PDT)
Received: by puma.baltimore.ie; id PAA00195; Fri, 30 Jul 1999 15:15:21 +0100 (GMT/IST)
Received: from bobcat.baltimore.ie(192.168.20.10) by puma.baltimore.ie via smap (4.1) id xma000140; Fri, 30 Jul 99 15:14:56 +0100
Received: from ocelot.baltimore.ie (IDENT:[e-mail] [192.168.21.10]) by bobcat.baltimore.ie (8.9.3/8.9.3) with ESMTP id OAA21158; Fri, 30 Jul 1999 14:22:45 +0100
Received: from ocelot.baltimore.ie (afarrell@localhost [127.0.0.1]) by ocelot.baltimore.ie (8.8.7/8.8.7) with ESMTP id OAA06949; Fri, 30 Jul 1999 14:21:35 +0100
Message-Id: <[e-mail]>
To: [e-mail], [e-mail]
Subject: Re: X9.42 and RFC2459 inconsistency? 
In-Reply-To: Your message of "Wed, 28 Jul 1999 18:36:56 BST." <[e-mail]> 
Date: Fri, 30 Jul 1999 14:21:35 +0100
From: Andrew Farrell <[e-mail]>

I wrote:

>Cool (and a welcome gesture towards fixing broken stuff). So why do we
>use their OID?

Sine there's been a deafing silence on this topic, I have two further
questions:

(1) Are there any deployed codebases which would object to changing the
Diffie-Hellman OID in rfc2459 to reflect the fact that it has different
semantics than in X9.42? 

I know that John Pawling has stated that Van Dyke's S/MIME Freeware
Library has no issues, and as far as I know Microsoft haven't shipped
anything with Diffie-Hellman, so that S/MIME would appear to be in the
clear on this.

(2) Are there any other groups that profile 2459 that we should ask
about this?.

Andrew


Received: from tomcat.sac.verio.net ([e-mail] [209.162.64.15]) by mail.proper.com (8.9.3/8.9.3) with ESMTP id KAA19814 for <[e-mail]>; Thu, 29 Jul 1999 10:48:53 -0700 (PDT)
Received: from nma.com (pm09-16.sac.verio.net [209.162.65.129]) by tomcat.sac.verio.net (8.9.1a/8.9.1) with ESMTP id KAA19440; Thu, 29 Jul 1999 10:51:05 -0700 (PDT)
Message-ID: <[e-mail]>
Date: Thu, 29 Jul 1999 10:50:56 -0700
From: Ed Gerck <[e-mail]>
X-Mailer: Mozilla 4.51 [en] (Win98; I)
X-Accept-Language: en
MIME-Version: 1.0
To: Russ Housley <[e-mail]>
CC: "'[e-mail]'" <[e-mail]>
Subject: Re: Common misconceptions, was Re: KISS for PKIX. (Was: RE:ASN.1vs  XML  (used to be RE: I-D ACTION :draft-ietf-pkix-scvp- 00.txt))
References: <v04020a02b3b3e54bc992@[128.33.238.108]> <v04020a00b3b56b6383a7@[128.33.238.45]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Russ Housley wrote:

> Challenge-response protocols are not needed for non-repudiation.  Such a
> protocol might be used, but it is not required.  For example, a digitally
> signed S/MIME message might provide non-repudiation and no
> challenge-response protocol is involved.
>

No, it does not provide for legal NR unless there is some mechanism of
challenge-response involved (which does not need to be cryptographic).
Please see my last msg with the subject "non-repudiation" for an analysis
which also deals with non-legal NR.

Cheers,

 Ed Gerck



Received: from mail.spyrus.com (mail.spyrus.com [207.212.34.20]) by mail.proper.com (8.9.3/8.9.3) with ESMTP id HAA16024 for <[e-mail]>; Thu, 29 Jul 1999 07:41:43 -0700 (PDT)
Received: from rhousley_laptop.spyrus.com (dial07.spyrus.com [207.212.34.127]) by mail.spyrus.com (8.9.3/8.9.3) with ESMTP id HAA05730; Thu, 29 Jul 1999 07:38:16 -0700 (PDT)
Message-Id: <[e-mail]>
X-Sender: [e-mail] (Unverified)
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58 
Date: Thu, 29 Jul 1999 10:31:45 -0400
To: Ed Gerck <[e-mail]>
From: Russ Housley <[e-mail]>
Subject: Re: Common misconceptions, was Re: KISS for PKIX. (Was: RE: ASN.1vs  XML (used to be RE: I-D ACTION :draft-ietf-pkix-scvp- 00.txt))
Cc: "'[e-mail]'" <[e-mail]>
In-Reply-To: <[e-mail]>
References: <v04020a02b3b3e54bc992@[128.33.238.108]> <v04020a00b3b56b6383a7@[128.33.238.45]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed

Challenge-response protocols are not needed for non-repudiation.  Such a 
protocol might be used, but it is not required.  For example, a digitally 
signed S/MIME message might provide non-repudiation and no 
challenge-response protocol is involved.

Russ


At 10:54 AM 7/23/99 -0700, Ed Gerck wrote:


>Jan Nielsen wrote:
>
> > Hi Ed,
> >
> > > which may explain your off-the-point remark.
> >
> > No...I simply skimmed the thread instead of r-e-a-d-i-n-g it.  Sorry 
> about that.
>
>;-) short postings cannot reflect content, long postings tend to be unread 
>and thus also
>not reflect content -- but, at least, content is there.
>
> > My comments were actually addressing the non-repudiation of a user's 
> actions, not digital
> > signatures, in systems which rely on SSL client authentication for user 
> authentication as opposed to
> > password authentication.  My point is simply that because of poor key 
> management facilities on the
> > client and poor physical security of the device that repudiation of the 
> user authentication is more
> > likely with SSL client authentication than with a password system.
>
>Perhaps you still skimmed the thread too much. A password system such as 
>what is called
>"weak authentication" in X.509 is not able to provide NR at all, as I 
>wrote before:
>
>} ...basically, the reason is that  passwords have no challenge-response 
>mechanism.
>} Since a password can be replayed at will, the authenticating party (ie, 
>the verifier)
>} is barred from presenting an argument of non-repudiation when passwords 
>are used
>} because the verifier could have generated any message all by itself -- 
>the data is
>} intrinsically corrupted.
>
>So, any client authentication SSL system can provide more *evidences* (and 
>I can't
>overstress the importance of this word here) of NR than any weak 
>authentication
>(ie, password) system is ever capable of -- in other words, any NR 
>evidence is more
>than zilch ;-)
>
>Cheers,
>
>Ed Gerck



Received: from puma.baltimore.ie ([e-mail] [194.125.215.8]) by mail.proper.com (8.9.3/8.9.3) with ESMTP id QAA26172 for <[e-mail]>; Wed, 28 Jul 1999 16:13:51 -0700 (PDT)
Received: by puma.baltimore.ie; id UAA01184; Wed, 28 Jul 1999 20:27:15 +0100 (GMT/IST)
Received: from unknown(192.168.20.10) by puma.baltimore.ie via smap (4.1) id xma001179; Wed, 28 Jul 99 20:26:33 +0100
Received: from sage.baltimore.ie (IDENT:[e-mail] [192.168.21.125]) by bobcat.baltimore.ie (8.9.3/8.9.3) with ESMTP id TAA16789 for <[e-mail]>; Wed, 28 Jul 1999 19:34:44 +0100
Received: from sage.baltimore.ie (IDENT:keith@localhost [127.0.0.1]) by sage.baltimore.ie (8.9.3/8.9.3) with ESMTP id TAA18691 for <[e-mail]>; Wed, 28 Jul 1999 19:34:08 +0100
Message-Id: <[e-mail]>
To: [e-mail]
Subject: Re: LAST CALL: draft-ietf-pkix-cmc-05.txt 
Date: Wed, 28 Jul 1999 19:34:08 +0100
From: Keith Brady <[e-mail]>

David> "Half-baked protocols" is pretty strong language. The CMP

Indeed, this is certainly not the case with CMP as the interop has shown.

David> 1) errors in the protocol, which would prevent a single compliant
    implementation from functioning correctly,

The only one we have come across is the one John Wray identified and I
posted to the list about the CMP over TCP protocol. This is a trivial
change and an implementation may not even notice a problem. In any case
the other transports are fine (we think).

David> 2) ambiguities in the protocol, in which two compliant
    implementations would not necessarily interoperate, and

There are certainly some ambiguities but I'm not even sure we need to rev
the RFC for these (I may be wrong). A BCP might be in order, I'm not sure.

David> 3) errors or omissions in the implementations which cause
    them to be non-compliant with the protocol specifications as written.

There were, of course, a few of these. IMPLICIT/EXPLICIT, so it goes.

David> Identifying and correcting instances of 2) is clearly one of the
David> functions of the IETF standards track.

I believe we are taking the approach in the interops that corrections go
into 2510 (there aren't many) and clarifications go into an informational
or BCP RFC which will be the final version of Bob's ID.

David> adopters in not feeling like guinea pigs? If your boss tells you to
David> implement a prototype (as a vendor) or pilot (as a user), your
David> choice is to ignore him and do nothing until there is a Standard,
David> or implement the specifications that are available. If you are an
David> early adopter, you are a guinea pig, whether you adopt an
David> Experimental RFC or a Proposed Standard RFC.

I strongly agree with this. This is reinforced by the fact that it is
harder (though not impossible) to rev a PS than an ID. It means that
implementors can be reasonably sure of keeping most of their code base and
still have something ready then full standard status is reached.

cheers,

Keith


Received: from rbhub101.chamb.disa.mil (rbhub101.chamb.disa.mil [209.22.120.24]) by mail.proper.com (8.9.3/8.9.3) with ESMTP id NAA20083 for <[e-mail]>; Wed, 28 Jul 1999 13:12:15 -0700 (PDT)
Received: by rbhub101.chamb.disa.mil with Internet Mail Service (5.5.2448.0) id <P4Q0YTND>; Wed, 28 Jul 1999 16:15:01 -0400
Message-ID: <[e-mail]>
From: "Flanigan, Bill" <[e-mail]>
To: [e-mail]
Subject: RE: LAST CALL: draft-ietf-pkix-cmc-05.txt
Date: Wed, 28 Jul 1999 16:17:46 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2448.0)
Content-Type: text/plain

Well said, Dave, as usual.  The underlying problem (as I think we would
likely agree) is the dynamic (and the monetary/political fall out when
things don't work well or at all) of the PKI *business.*  (Yeah, I know, we
all over hyped it to get things moving!)  Vendors now implement the I-D (or
the pre I-D--see other emails) or the Proposed RFC (but only if they have
been away on Mars!).  Never mind the Draft RFC, and who the heck even
bothers to download the Standard RFC--the world has moved gigacycles by
then--since it is likely to be de facto depreciated to Historical status.
Furthermore, who reads 2026 (much less dares to tell management what it
actually says).  But if we toss the words *experimental* or *pilot* or *use
at management's risk* or *use at the risk of your NASDAQ price dropping by
half* into the RFC title (or better yet, proactively resist the temptation
and pressure to move on to the standards track until two implementers
swear--and digitally sign it--they have achieved interop), now we have a
counter to that magic anagram *RFC*.  I would venture to guess that 95
percent of the folks who sign the checks in early-adopter organizations (and
to whom you have to answer to when things fall apart) believe that once an
RFC number has been issued, it's now an IETF STANDARD SO WHY SHOULD THERE BE
A PROBLEM?!  This is why I like the sound of *Experimental RFC* or
*Pilot-Only RFC*, etc.

Bill
> ----------
> From: 	David P. Kemp[SMTP:[e-mail]]
> Reply To: 	David P. Kemp
> Sent: 	Wednesday, July 28, 1999 2:05 PM
> To: 	[e-mail]
> Subject: 	RE: LAST CALL: draft-ietf-pkix-cmc-05.txt
> 
[snip]

> Early adopters should probably refer to RFC2026:
> 
>    "Implementors should treat Proposed Standards as immature
>    specifications.  It is desirable to implement them in order to gain
>    experience and to validate, test, and clarify the specification.
>                                          ^^^^^^^
>    However, since the content of Proposed Standards may be changed if
>    problems are found or better solutions are identified, deploying
>    implementations of such standards into a disruption-sensitive
>    environment is not recommended."
> 
> One can only strive to be standards-compliant when there is a Standard
> (not a Proposed or Draft Standard) to comply with.  How would
> designating CMC or CMP as Experimental or I-D assist early adopters in
> not feeling like guinea pigs?  If your boss tells you to implement a
> prototype (as a vendor) or pilot (as a user), your choice is to ignore
> him and do nothing until there is a Standard, or implement the
> specifications that are available.  If you are an early adopter, you
> are a guinea pig, whether you adopt an Experimental RFC or a Proposed
> Standard RFC.
> 
> We in the DMS and now DoD PKI arena are very much guinea pigs, and
> there is nothing constructive we can do about it except continue to
> design, implement and test.  Other PKIX constituents are in the same
> boat.  There's nothing wrong with that; it's part of being in an Open
> process (or a democracy, or a free-market economy, or whatever).
> 


Received: from www.meridianus.com (209.249.223.14.has.no.reverse [209.249.223.14] (may be forged)) by mail.proper.com (8.9.3/8.9.3) with ESMTP id MAA18442 for <[e-mail]>; Wed, 28 Jul 1999 12:34:01 -0700 (PDT)
Received: from PC1 by www.meridianus.com (8.8.8+Sun/SMI-SVR4) id NAA13309; Wed, 28 Jul 1999 13:30:48 -0700 (PDT)
Message-ID: <02c501bed932$6bda3f90$[e-mail]>
From: "tog" <[e-mail]>
To: "Warwick Ford" <[e-mail]>, "'tog'" <[e-mail]>, <[e-mail]>
References: <[e-mail]>
Subject: Re: LAST CALL: draft-ietf-pkix-cmc-05.txt
Date: Wed, 28 Jul 1999 12:50:19 -0700
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.00.2918.2701
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2918.2701

I'm sorry, your right. So then what is the issue regarding advancing this
particular effort.

----- Original Message -----
From: Warwick Ford <[e-mail]>
To: 'tog' <[e-mail]>; <[e-mail]>
Sent: Wednesday, July 28, 1999 9:34 AM
Subject: RE: LAST CALL: draft-ietf-pkix-cmc-05.txt


> Todd:
>
> RFC 2026 says of Proposed Standard:
>
>    Usually, neither implementation nor operational experience is
>    required for the designation of a specification as a Proposed
>    Standard.
>
> The requirement for 2 implementations is for Draft Standard - the next
> stage.
>
> Warwick
>
> > -----Original Message-----
> > From: tog [mailto:[e-mail]]
> > Sent: Tuesday, July 27, 1999 6:15 PM
> > To: [e-mail]; Paul Hoffman / IMC
> > Cc: POISED-WG
> > Subject: Re: LAST CALL: draft-ietf-pkix-cmc-05.txt
> > My feeling is that the protocol model is robust enough so
> > that it deserves
> > to get advanced, however we have these POISED requirements,
> > so maybe if we
> > do not advance it then we should at least mark it as "automatically
> > advanced" as soon as the advancement criteria is met -poof its done.
> >
> > This leaves it up to the sponsors to actually make sure that
> > their efforts
> > are successful and that they have two impliementations of
> > their beast as per
> > the RFC2026 requirements. But it also enables that any technology
> > specification should fast track through approval if it
> > satisfies the staging
> > requirements in 2026. I think this is a really good idea, myself.
> >
> > This effort might actually take a change to RFC2026, but is
> > likely that also
> > that the WG Chairs can agree that within PKIX such a status exists. Yo
> > Warwick and Stephen, does this work for the groups purposes?.
>




Received: from gatekeeper.entrust.com (gatekeeper.entrust.com [204.101.128.170]) by mail.proper.com (8.9.3/8.9.3) with SMTP id LAA16196; Wed, 28 Jul 1999 11:41:47 -0700 (PDT)
Received: 	id OAA26549; Wed, 28 Jul 1999 14:39:21 -0400
Received: by gateway id <NP652AZ2>; Wed, 28 Jul 1999 14:41:58 -0400
Message-ID: <[e-mail]>
From: Carlisle Adams <[e-mail]>
To: "'Paul Hoffman / IMC'" <[e-mail]>
Cc: [e-mail]
Subject: RE: LAST CALL: draft-ietf-pkix-cmc-05.txt 
Date: Wed, 28 Jul 1999 14:41:52 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2448.0)
Content-Type: text/plain

Hi Paul,

> ----------
> From: 	Paul Hoffman / IMC[SMTP:[e-mail]]
> Sent: 	Wednesday, July 28, 1999 12:54 PM
> To: 	[e-mail]
> Subject: 	Re: LAST CALL: draft-ietf-pkix-cmc-05.txt 
> 
> At 01:47 PM 7/28/1999 +0100, Keith Brady wrote:
> >I'm not sure we're actually that far from having working interop. Not all
> >of Bob's report is doom and gloom and we expect better results at the
> next
> >one.
> 
> This is good to hear. However, I understand that the issues are not bad 
> implementations, but lack of clarity in the RFC. The reason I brought this
> 
> up with respect to CMC is that we now have a track record of lack of 
> clarity getting in the way of interoperability. We should take the 
> opportunity to fix it (if it exists in CMC) before it goes on standards 
> track. We as a Working Group owe that to the developer and user
> communities.
> 
> Having run many interop events, I can assure you that if you didn't
> achieve 
> interoperability after two concerted efforts, the spec has problems.
> That's 
> why I queried about current implementors of CMC. If there are any, they
> can 
> attest to whether or not the spec is implementable from. If there are more
> 
> than one, and even informal testing has happened, they can attest to 
> whether or not the spec is clear.
 
The following is my understanding of what happened at the CMP interop trials
(from discussion with someone who was there).  In a number of cases (not
all, by any means, but quite a few), Party1 and Party2 would be trying to
interoperate and the conversation would go something like this:

   Party1:  Here's the problem.  You're doing it like this and we're doing
it like that.  Why in the world are you doing it this way?

   Party2:  Because the spec says to do it this way.  Look here on page xxx.

   Party1:  Oh.  I guess I hadn't seen that part.  O.K., we'll fix it.

Many times, when people actually looked at what the spec mandated
(especially in Appendix B), problems were resolved.  I think Bob's document
did not reflect much of this and the result was that others (who weren't at
the trials) ended up with the impression that the specification was the
source of all the problems.

Reading the spec can actually go a long way toward getting an implementation
right.  :-)  At the first interop trial a number of people had not read all
of it, or had not read it carefully enough, or whatever.  By the second
interop trial the situation had improved and much progress was made.  So,
while I would be the first to admit that the specification is not perfect
(it's hard to find one that is!), I think we need to be a little bit careful
with off-the-cuff statements like "lack of clarity" and "the spec has
problems".


In any case, all of this points out the importance of interoperability
testing and I'm glad that Bob has made the effort to organize these events.
He has suggested doing the same with other PKIX protocols, which is a great
idea.  Does this have to happen before an I-D can go to Proposed Standard?
It would definitely be nice, but I don't think it's a requirement.

Carlisle.



Received: from stingray.missi.ncsc.mil (stingray.missi.ncsc.mil [144.51.50.20]) by mail.proper.com (8.9.3/8.9.3) with ESMTP id LAA14145 for <[e-mail]>; Wed, 28 Jul 1999 11:03:33 -0700 (PDT)
Received: from stingray.missi.ncsc.mil (root@localhost) by stingray.missi.ncsc.mil with ESMTP id OAA15264 for <[e-mail]>; Wed, 28 Jul 1999 14:05:55 -0400 (EDT)
Received: from missi.ncsc.mil (depot.missi.ncsc.mil [144.51.60.1]) by stingray.missi.ncsc.mil with ESMTP id OAA15259 for <[e-mail]>; Wed, 28 Jul 1999 14:05:54 -0400 (EDT)
Received: from ara.missi.ncsc.mil (ara.missi.ncsc.mil [144.51.58.9]) by missi.ncsc.mil (8.8.8/8.8.8) with ESMTP id OAA22718 for <[e-mail]>; Wed, 28 Jul 1999 14:05:51 -0400 (EDT)
Received: from ara.missi.ncsc.mil (ara.missi.ncsc.mil [144.51.58.9]) by ara.missi.ncsc.mil (8.9.1b+Sun/8.9.1) with SMTP id OAA16304 for <[e-mail]>; Wed, 28 Jul 1999 14:05:18 -0400 (EDT)
Message-Id: <[e-mail]>
Date: Wed, 28 Jul 1999 14:05:18 -0400 (EDT)
From: "David P. Kemp" <[e-mail]>
Reply-To: "David P. Kemp" <[e-mail]>
Subject: RE: LAST CALL: draft-ietf-pkix-cmc-05.txt
To: [e-mail]
MIME-Version: 1.0
Content-Type: TEXT/plain; charset=us-ascii
Content-MD5: h+QiNmoNa8hb1ERyBMkB2w==
X-Mailer: dtmail 1.3.0 CDE Version 1.3 SunOS 5.7 sun4u sparc

> From: "Flanigan, Bill" <[e-mail]>
> 
> Slapping an RFC number on half-baked protocols is indeed experimental.  So
> why not make it so (pro-actively for CMC and retro-actively for CMP)?  And
> what's wrong with progressing from Experimental to new I-D to Proposed when
> the darn thing finally works?  I believe that vendors and early adopters
> striving to be open-standards compliant are growing weary of being PKIX
> guinea pigs (which seems tantamount to being played for suckers).
> 
> Bill


"Half-baked protocols" is pretty strong language.  The CMP interoperability
status could be the result of:
1) errors in the protocol, which would prevent a single compliant
    implementation from functioning correctly,
2) ambiguities in the protocol, in which two compliant implementations
    would not necessarily interoperate, and
3) errors or omissions in the implementations which cause them to be
    non-compliant with the protocol specifications as written.

Identifying and correcting instances of 2) is clearly one of the functions
of the IETF standards track.

Early adopters should probably refer to RFC2026:

   "Implementors should treat Proposed Standards as immature
   specifications.  It is desirable to implement them in order to gain
   experience and to validate, test, and clarify the specification.
                                         ^^^^^^^
   However, since the content of Proposed Standards may be changed if
   problems are found or better solutions are identified, deploying
   implementations of such standards into a disruption-sensitive
   environment is not recommended."

One can only strive to be standards-compliant when there is a Standard
(not a Proposed or Draft Standard) to comply with.  How would
designating CMC or CMP as Experimental or I-D assist early adopters in
not feeling like guinea pigs?  If your boss tells you to implement a
prototype (as a vendor) or pilot (as a user), your choice is to ignore
him and do nothing until there is a Standard, or implement the
specifications that are available.  If you are an early adopter, you
are a guinea pig, whether you adopt an Experimental RFC or a Proposed
Standard RFC.

We in the DMS and now DoD PKI arena are very much guinea pigs, and
there is nothing constructive we can do about it except continue to
design, implement and test.  Other PKIX constituents are in the same
boat.  There's nothing wrong with that; it's part of being in an Open
process (or a democracy, or a free-market economy, or whatever).



Received: from puma.baltimore.ie ([e-mail] [194.125.215.8]) by mail.proper.com (8.9.3/8.9.3) with ESMTP id KAA12913 for <[e-mail]>; Wed, 28 Jul 1999 10:34:33 -0700 (PDT)
Received: by puma.baltimore.ie; id TAA02686; Wed, 28 Jul 1999 19:30:18 +0100 (GMT/IST)
Received: from bobcat.baltimore.ie(192.168.20.10) by puma.baltimore.ie via smap (4.1) id xma002669; Wed, 28 Jul 99 19:29:39 +0100
Received: from ocelot.baltimore.ie (IDENT:[e-mail] [192.168.21.10]) by bobcat.baltimore.ie (8.9.3/8.9.3) with ESMTP id SAA15690 for <[e-mail]>; Wed, 28 Jul 1999 18:37:49 +0100
Received: from ocelot.baltimore.ie (afarrell@localhost [127.0.0.1]) by ocelot.baltimore.ie (8.8.7/8.8.7) with ESMTP id SAA03723 for <[e-mail]>; Wed, 28 Jul 1999 18:36:56 +0100
Message-Id: <[e-mail]>
To: [e-mail]
Subject: Re: X9.42 and RFC2459 inconsistency?
Date: Wed, 28 Jul 1999 18:36:56 +0100
From: Andrew Farrell <[e-mail]>

In message <[e-mail]>you write:
>"William Whyte" <[e-mail]> writes:

>>There seems to be an inconsistency between X9.42 and RFC 2459 about how to 
>>encode Diffie-Hellman public keys.

>During RFC 2459's draft stages this was changed to the current form when it
>was pointed out that the X9.42 version was essentially unworkable (it 
>required complicated and unnecessary processing of the value which is
>incompatible with the way any other subjectPublicKey is handled, and it's
>practically guaranteed that implementors will get it wrong in a variety of
>ways which will cause all sorts of headaches - the values will look right
>and even work properly, they just won't give the expected results when used
>with implementations which do it differently to however you're doing it).

Cool (and a welcome gesture towards fixing broken stuff). So why do we
use their OID?

>Peter.

Andrew.



Received: from mail.student.auckland.ac.nz (mail.student.auckland.ac.nz [130.216.35.101]) by mail.proper.com (8.9.3/8.9.3) with ESMTP id KAA12038 for <[e-mail]>; Wed, 28 Jul 1999 10:11:07 -0700 (PDT)
Received: from kahu.cs.auckland.ac.nz ([e-mail] [130.216.36.13]) by mail.student.auckland.ac.nz (8.8.6/8.8.6/cs-master) with SMTP id FAA10347 for <[e-mail]>; Thu, 29 Jul 1999 05:13:31 +1200 (NZST) (sender [e-mail])
Received: by kahu.cs.auckland.ac.nz (relaymail v0.9) id <93318161218767>; Thu, 29 Jul 1999 05:06:52 (NZST)
From: [e-mail] (Peter Gutmann)
To: [e-mail]
Subject: Re: X9.42 and RFC2459 inconsistency?
Sender: [e-mail]
Reply-To: [e-mail]
X-Charge-To: pgut001
X-Authenticated: relaymail v0.9 on kahu.cs.auckland.ac.nz
Date: Thu, 29 Jul 1999 05:06:52 (NZST)
Message-ID: <[e-mail]>

William Whyte <[e-mail]> wrote:

>On the other hand, X9.42 says 
>
>[...]
>
>which reads like you take the ASN.1 INTEGER, strip off the tag, left-shift
>it until the most significant bit is set, and then encode it as a BIT
>STRING with the appropriate number of unused bits, not containing an
>INTEGER at all.

Paul Koning <[e-mail]> commented:

>I don't read it quite that way.

William Whyte <[e-mail]> came back with:

>Fair enough, I suppose that's a possible interpretation. But it makes the 
>X9.42 spec even more ambiguous than before. It gives us eight different 
>possible encodings of the integer 1

I hereby rest my case about confusion and non-interoperability caused by 
going with the X9.42 version :-).

Peter.




Received: from doggate.exchange.microsoft.com (doggate.exchange.microsoft.com [131.107.88.55]) by mail.proper.com (8.9.3/8.9.3) with ESMTP id KAA11613; Wed, 28 Jul 1999 10:03:21 -0700 (PDT)
Received: by doggate.exchange.microsoft.com with Internet Mail Service (5.5.2232.9) id <PB77Y4YW>; Wed, 28 Jul 1999 10:03:13 -0700
Message-ID: <[e-mail]>
From: "Barb Fox (Exchange)" <[e-mail]>
To: "'Paul Hoffman / IMC'" <[e-mail]>, [e-mail]
Subject: RE: LAST CALL: draft-ietf-pkix-cmc-05.txt 
Date: Wed, 28 Jul 1999 10:03:11 -0700
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2232.9)
Content-Type: text/plain; charset="iso-8859-1"

Paul: 

We worked on CMC as an author group which represented four companies (MS,
Netscape, Verisign, and Cisco) who each intend to implement it. Here, we
vetted it with developers on the client and server sides and I'm pretty sure
that the others did as well BEFORE we published each version of the draft.
Therefore, I do not share your concern that CMC won't be implementable or
interoperable.

--Barbara Fox
Microsoft 


Received: from aum (ip11.proper.com [165.227.249.11]) by mail.proper.com (8.9.3/8.9.3) with ESMTP id JAA11174 for <[e-mail]>; Wed, 28 Jul 1999 09:52:21 -0700 (PDT)
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58 
Date: Wed, 28 Jul 1999 09:54:45 -0700
To: [e-mail]
From: Paul Hoffman / IMC <[e-mail]>
Subject: Re: LAST CALL: draft-ietf-pkix-cmc-05.txt 
In-Reply-To: <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed

At 01:47 PM 7/28/1999 +0100, Keith Brady wrote:
>I'm not sure we're actually that far from having working interop. Not all
>of Bob's report is doom and gloom and we expect better results at the next
>one.

This is good to hear. However, I understand that the issues are not bad 
implementations, but lack of clarity in the RFC. The reason I brought this 
up with respect to CMC is that we now have a track record of lack of 
clarity getting in the way of interoperability. We should take the 
opportunity to fix it (if it exists in CMC) before it goes on standards 
track. We as a Working Group owe that to the developer and user communities.

Having run many interop events, I can assure you that if you didn't achieve 
interoperability after two concerted efforts, the spec has problems. That's 
why I queried about current implementors of CMC. If there are any, they can 
attest to whether or not the spec is implementable from. If there are more 
than one, and even informal testing has happened, they can attest to 
whether or not the spec is clear.

--Paul Hoffman, Director
--Internet Mail Consortium


Received: from mail.student.auckland.ac.nz (mail.student.auckland.ac.nz [130.216.35.101]) by mail.proper.com (8.9.3/8.9.3) with ESMTP id JAA10876 for <[e-mail]>; Wed, 28 Jul 1999 09:43:32 -0700 (PDT)
Received: from kahu.cs.auckland.ac.nz ([e-mail] [130.216.36.13]) by mail.student.auckland.ac.nz (8.8.6/8.8.6/cs-master) with SMTP id EAA11704 for <[e-mail]>; Thu, 29 Jul 1999 04:45:56 +1200 (NZST) (sender [e-mail])
Received: by kahu.cs.auckland.ac.nz (relaymail v0.9) id <93317995720140>; Thu, 29 Jul 1999 04:39:17 (NZST)
From: [e-mail] (Peter Gutmann)
To: [e-mail]
Subject: Re: X9.42 and RFC2459 inconsistency?
Sender: [e-mail]
Reply-To: [e-mail]
X-Charge-To: pgut001
X-Authenticated: relaymail v0.9 on kahu.cs.auckland.ac.nz
Date: Thu, 29 Jul 1999 04:39:17 (NZST)
Message-ID: <[e-mail]>

"William Whyte" <[e-mail]> writes:

>There seems to be an inconsistency between X9.42 and RFC 2459 about how to 
>encode Diffie-Hellman public keys.

During RFC 2459's draft stages this was changed to the current form when it
was pointed out that the X9.42 version was essentially unworkable (it 
required complicated and unnecessary processing of the value which is
incompatible with the way any other subjectPublicKey is handled, and it's
practically guaranteed that implementors will get it wrong in a variety of
ways which will cause all sorts of headaches - the values will look right
and even work properly, they just won't give the expected results when used
with implementations which do it differently to however you're doing it).

Peter.



Received: from caladan.verisign.com (caladan.verisign.com [205.180.232.21]) by mail.proper.com (8.9.3/8.9.3) with ESMTP id JAA10588 for <[e-mail]>; Wed, 28 Jul 1999 09:32:20 -0700 (PDT)
Received: from mentat.verisign.com by caladan.verisign.com (8.8.5/BCH1.5) id JAA18843; Wed, 28 Jul 1999 09:32:59 -0700 (PDT)
Received: from newman.verisign.com by mentat.verisign.com (8.8.5/BCH1.0) id JAA12083; Wed, 28 Jul 1999 09:34:15 -0700 (PDT)
Received: by newman.verisign.com with Internet Mail Service (5.5.2448.0) id <PQHF0206>; Wed, 28 Jul 1999 09:34:17 -0700
Message-ID: <[e-mail]>
From: Warwick Ford <[e-mail]>
To: "'tog'" <[e-mail]>, [e-mail]
Subject: RE: LAST CALL: draft-ietf-pkix-cmc-05.txt
Date: Wed, 28 Jul 1999 09:34:13 -0700
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2448.0)
Content-Type: text/plain; charset="iso-8859-1"

Todd:

RFC 2026 says of Proposed Standard:

   Usually, neither implementation nor operational experience is
   required for the designation of a specification as a Proposed
   Standard. 

The requirement for 2 implementations is for Draft Standard - the next
stage.

Warwick

> -----Original Message-----
> From: tog [mailto:[e-mail]]
> Sent: Tuesday, July 27, 1999 6:15 PM
> To: [e-mail]; Paul Hoffman / IMC
> Cc: POISED-WG
> Subject: Re: LAST CALL: draft-ietf-pkix-cmc-05.txt
> My feeling is that the protocol model is robust enough so 
> that it deserves
> to get advanced, however we have these POISED requirements, 
> so maybe if we
> do not advance it then we should at least mark it as "automatically
> advanced" as soon as the advancement criteria is met -poof its done.
> 
> This leaves it up to the sponsors to actually make sure that 
> their efforts
> are successful and that they have two impliementations of 
> their beast as per
> the RFC2026 requirements. But it also enables that any technology
> specification should fast track through approval if it 
> satisfies the staging
> requirements in 2026. I think this is a really good idea, myself.
> 
> This effort might actually take a change to RFC2026, but is 
> likely that also
> that the WG Chairs can agree that within PKIX such a status exists. Yo
> Warwick and Stephen, does this work for the groups purposes?.


Received: from ns1.dmz.valicert.com (ns1.valicert.com [63.65.221.10]) by mail.proper.com (8.9.3/8.9.3) with ESMTP id JAA10368 for <[e-mail]>; Wed, 28 Jul 1999 09:29:33 -0700 (PDT)
Received: from ns1.serverfarm.valicert.com (corporate-gw.valicert.com [63.65.221.2]) by ns1.dmz.valicert.com (8.9.2/8.9.2) with ESMTP id JAA17021; Wed, 28 Jul 1999 09:30:01 -0700 (PDT)
Received: from rsalaptop (dhcp-3-230.engineering.valicert.com [192.168.3.230]) by ns1.serverfarm.valicert.com (8.9.2/8.9.2) with SMTP id JAA22620; Wed, 28 Jul 1999 09:31:30 -0700 (PDT)
From: "Peter Williams" <[e-mail]>
To: "Eamonn Maher" <[e-mail]>, <[e-mail]>
Subject: RE: Extended Key Usage for OCSP signing and IPSEC
Date: Wed, 28 Jul 1999 09:49:34 -0700
Message-ID: <000001bed919$2beee980$[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset="Windows-1252"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0
Importance: Normal
In-Reply-To: <[e-mail]>
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.0810.800

On (2) 

Warwick asked some people at the Memphis IETF
what key purposes relevant to IETF work should
be defined. I suggested those two represent
the controlled use of the (then) known sets of security 
services, optionally governed by certs, for IPSEC 
virtual network tunnelling and IPSEC user 
authentication to the network/VPN. The then
chair of IPSEC agreed, whilst drinking down
his beer. No-one objected during 2459 final call.

2459 is charged with addressing standard
internet apps/protocols (versus non IETF apps/protocols such
as secure media-based workflow, and web stuff.) IPSEC 
seemed to fit the bill, and therefore 
fell in the profile scope. There are other
application security contexts for IPSEC which
should probably have also been named. One can
use private oids, for these, however. Like
for certificate politicies, IETF NEED not be involved 
in the OID value assignment; vendors and user
organizations can do this outside the standard.
Should IPSEC WG desire to formalize oids for
securing different types of store-and-forward 
inter-network links (for secure routing and 
route selection, presumably),  this seems another 
perfectly reasonable use of the PKI technique.

> -----Original Message-----
> From: Eamonn Maher [mailto:[e-mail]]
> Sent: Wednesday, July 28, 1999 5:47 AM
> To: [e-mail]
> Subject: Extended Key Usage for OCSP signing and IPSEC
> 
> 
> 1. 
> If the ExtendedKeyUsages extension is critical then it must be 
> consistent with 
> the KeyUsage extension (if present and critical - which it SHOULD 
> be). Then 
> what KeyUsage bits should be set if the extension contains the 
> OCSP signing 
> OID? just digitalSignature?
> 
> 2.
> Why are the extended key purpose OIDs for IPSEC (id-kp-ipsecEndSystem,
> id-kp-ipsecTunnel and id-kp-ipsecUser) defined in rfc 2459?
> In 
> http://www.ietf.org/internet-drafts/draft-ietf-ipsec-pki-req-02.txt
> only iKEEnd and iKEIntermediate are defined.
> 
> 3.
> What valid combinations are there of KeyUsage and the above PKIX IPSEC 
> extendedKeyUsages and the IPSEC extendedKeyUsages?
> 
> Eamonn
> 
> 


Received: from puma.baltimore.ie ([e-mail] [194.125.215.8]) by mail.proper.com (8.9.3/8.9.3) with ESMTP id IAA09080 for <[e-mail]>; Wed, 28 Jul 1999 08:53:13 -0700 (PDT)
Received: by puma.baltimore.ie; id RAA15518; Wed, 28 Jul 1999 17:48:54 +0100 (GMT/IST)
Received: from bobcat.baltimore.ie(192.168.20.10) by puma.baltimore.ie via smap (4.1) id xma015475; Wed, 28 Jul 99 17:48:18 +0100
Received: from knuckle (knuckle.baltimore.ie [192.168.21.91]) by bobcat.baltimore.ie (8.9.3/8.9.3) with SMTP id QAA11554; Wed, 28 Jul 1999 16:56:28 +0100
From: "William Whyte" <[e-mail]>
To: "Paul Koning" <[e-mail]>
Cc: "Ietf-Pkix@Imc. Org" <[e-mail]>
Subject: RE: X9.42 and RFC2459 inconsistency?
Date: Wed, 28 Jul 1999 16:54:35 +0100
Message-ID: <002e01bed911$7d590510$[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook 8.5, Build 4.71.2377.0
X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3155.0
In-Reply-To: <[e-mail]>
Importance: Normal

>  William> 1) A BER-encoded integer doesn't have trailing unused bits
>  William> in the last byte. If you weren't expected to left-shift,
>  William> surely it would say something like "the BIT STRING encoding
>  William> should indicate zero unused bits in the last octet". And
>  William> note that it says "If the integer is not an integral number
>  William> of octets in length", not "If the INTEGER..."; the
>  William> implication is that we're dealing with the raw data.
> 
> Agreed that it's dealing with the raw integer, not an encoded
> integer.  But my point is that "7 bit integer" doesn't mean that the
> MSB is set.  You can have the value 1 in a 7 bit integer.  So that
> would say the shift count for that example is 1, and the unused bit
> count is 1, while your description says the shift count and unused bit 
> counts are 7.

Fair enough, I suppose that's a possible interpretation. But it
makes the X9.42 spec even more ambiguous than before. It gives us
eight different possible encodings of the integer 1, for example,
depending on whether you mean an eight-bit 1 or a one-bit 1. The
only unambiguous interpretation I can see is that you're intended
to left-shift it.

William


Received: from puma.baltimore.ie ([e-mail] [194.125.215.8]) by mail.proper.com (8.9.3/8.9.3) with ESMTP id IAA08175 for <[e-mail]>; Wed, 28 Jul 1999 08:34:22 -0700 (PDT)
Received: by puma.baltimore.ie; id RAA13770; Wed, 28 Jul 1999 17:29:50 +0100 (GMT/IST)
Received: from bobcat.baltimore.ie(192.168.20.10) by puma.baltimore.ie via smap (4.1) id xma013743; Wed, 28 Jul 99 17:29:29 +0100
Received: from knuckle (knuckle.baltimore.ie [192.168.21.91]) by bobcat.baltimore.ie (8.9.3/8.9.3) with SMTP id QAA10462; Wed, 28 Jul 1999 16:37:43 +0100
From: "William Whyte" <[e-mail]>
To: "Paul Koning" <[e-mail]>
Cc: <[e-mail]>
Subject: RE: X9.42 and RFC2459 inconsistency?
Date: Wed, 28 Jul 1999 16:35:49 +0100
Message-ID: <002801bed90e$de74f910$[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook 8.5, Build 4.71.2377.0
X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3155.0
In-Reply-To: <[e-mail]>
Importance: Normal

Hi,

> > On the other hand, X9.42 says this:
> > 
> >    The public key (an INTEGER) is mapped to a subjectPublicKey (a BIT 
> >    STRING) such that the most significant bit of the INTEGER becomes 
> >    the most significant bit of the BIT STRING and the least significant
> >    bit of the INTEGER becomes the least significant bit of the BIT STRING.
> >    The integer therefore remains encoded in "big-endian" format. If the 
> >    integer is not an integral number of octets in length, the BIT STRING 
> >    encoding indicates the number of unused bits in the last octet of the 
> >    encoding.
> > 
> > which reads like you take the ASN.1 INTEGER, strip off the tag, left-shift 
> > it until the most significant bit is set, and then encode it as a BIT
> > STRING with the appropriate number of unused bits, not containing an
> > INTEGER at all.
> 
> I don't read it quite that way.  It says "most significant bit", it
> does NOT say "most significant bit that is set".  If the key length is 
> K, regardless of whether there are leading zero bits, the shift is by
> (8-K) MOD 8.

Well, there's two things there:

1) A BER-encoded integer doesn't have trailing unused bits in the last
   byte. If you weren't expected to left-shift, surely it would say
   something like "the BIT STRING encoding should indicate zero unused
   bits in the last octet". And note that it says "If the integer is not 
   an integral number of octets in length", not "If the INTEGER..."; the
   implication is that we're dealing with the raw data.

2) Be that as it may, the X9.42 spec definitely seems to be telling us
   to throw away the INTEGER tag, and the PKIX spec definitely seems to
   be telling us to keep it. 

Like I say, I prefer the PKIX approach, but a resolution really depends
on the X9 folk.

Cheers,

William


Received: from chi6sosrv11.alter.net (chi6sosrv11.alter.net [208.204.150.57]) by mail.proper.com (8.9.3/8.9.3) with ESMTP id IAA07781 for <[e-mail]>; Wed, 28 Jul 1999 08:27:46 -0700 (PDT)
Received: from xedia.com by chi6sosrv11.alter.net with SMTP  (peer crosschecked as: madway.xedia.com [198.202.232.199]) id QQgzvh29799; Wed, 28 Jul 1999 15:29:52 GMT
Received: from tonga.xedia.com by xedia.com (4.1/SMI-4.1) id AA20610; Wed, 28 Jul 99 11:28:32 EDT
Received: by tonga.xedia.com (SMI-8.6/SMI-SVR4) id LAA25317; Wed, 28 Jul 1999 11:29:51 -0400
Date: Wed, 28 Jul 1999 11:29:51 -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: X9.42 and RFC2459 inconsistency?
References: <[e-mail]> <001901bed8f9$ea867810$[e-mail]>
X-Mailer: VM 6.34 under 20.3 "Vatican City" XEmacs  Lucid

>>>>> William Whyte <[e-mail]> writes:

> And in a good day for questions from Baltimore...
> 
> There seems to be an inconsistency between X9.42 and RFC 2459 about
> how to encode Diffie-Hellman public keys. RFC 2459 says this:
> ...
> On the other hand, X9.42 says this:
> 
>    The public key (an INTEGER) is mapped to a subjectPublicKey (a BIT 
>    STRING) such that the most significant bit of the INTEGER becomes 
>    the most significant bit of the BIT STRING and the least significant
>    bit of the INTEGER becomes the least significant bit of the BIT STRING.
>    The integer therefore remains encoded in "big-endian" format. If the 
>    integer is not an integral number of octets in length, the BIT STRING 
>    encoding indicates the number of unused bits in the last octet of the 
>    encoding.
> 
> which reads like you take the ASN.1 INTEGER, strip off the tag, left-shift 
> it until the most significant bit is set, and then encode it as a BIT
> STRING with the appropriate number of unused bits, not containing an
> INTEGER at all.

I don't read it quite that way.  It says "most significant bit", it
does NOT say "most significant bit that is set".  If the key length is 
K, regardless of whether there are leading zero bits, the shift is by
(8-K) MOD 8.

	paul
 


Received: from gatekeeper.entrust.com (gatekeeper.entrust.com [204.101.128.170]) by mail.proper.com (8.9.3/8.9.3) with SMTP id HAA05690 for <[e-mail]>; Wed, 28 Jul 1999 07:30:58 -0700 (PDT)
Received: 	id KAB13162; Wed, 28 Jul 1999 10:28:15 -0400
Received: by gateway id <NP65H96G>; Wed, 28 Jul 1999 10:30:52 -0400
Message-ID: <[e-mail]>
From: Ron Chittaro <[e-mail]>
To: [e-mail], "'Keith Brady'" <[e-mail]>
Subject: RE: LAST CALL: draft-ietf-pkix-cmc-05.txt 
Date: Wed, 28 Jul 1999 10:30:35 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2448.0)
Content-Type: text/plain

I agree. We are not that far off from a working interop and it is not as bad
as the document seems to suggest. Significant progress has been made in only
2 sessions and as Keith mentions better results are expected in the near
future. 

Ron

__________________
Ron Chittaro,                                        Phone - [phone]
Entrust Technologies Ltd.
750 Heron Rd, Suite E080
Ottawa, Ontario, K1V 1A7  Canada


> ----------
> From: 	Keith Brady[SMTP:[e-mail]]
> Sent: 	Wednesday, July 28, 1999 8:47 AM
> To: 	[e-mail]
> Subject: 	Re: LAST CALL: draft-ietf-pkix-cmc-05.txt 
> 
>  "Flanigan," == Flanigan, Bill <[e-mail]> writes:
> 
> Flanigan,> Slapping an RFC number on half-baked protocols is indeed
> Flanigan,> experimental. So why not make it so (pro-actively for CMC and
> Flanigan,> retro-actively for CMP)? And what's wrong with progressing from
> 
> I'm not sure we're actually that far from having working interop. Not all
> of Bob's report is doom and gloom and we expect better results at the next
> one. Granted, we maybe should have started an interop before it hit RFC
> (though Entrust and ourselves did do a CCR/CCP) but sometimes we want to
> avoid the dev effort in interop'ing standards that are going to change
> incompatibly anyway (remember the message body renumbering?)
> 
> my 2p's worth,
> 
> Keith
> --
> Keith Brady,                                    Phone: [phone] 
> Baltimore Technologies,                           Fax: [phone]
> IFSC House, Custom House Quay,                <http://www.baltimore.ie>
> Dublin 1, Ireland
> 


Received: from www.meridianus.com (209.249.223.11.has.no.reverse [209.249.223.11] (may be forged)) by mail.proper.com (8.9.3/8.9.3) with ESMTP id HAA05332 for <[e-mail]>; Wed, 28 Jul 1999 07:24:49 -0700 (PDT)
Received: from PC1 by www.meridianus.com (8.8.8+Sun/SMI-SVR4) id IAA12940; Wed, 28 Jul 1999 08:21:10 -0700 (PDT)
Message-ID: <021301bed907$29c3aa40$[e-mail]>
From: "tog" <[e-mail]>
To: "Flanigan, Bill" <[e-mail]>, <[e-mail]>
References: <[e-mail]>
Subject: Re: LAST CALL: draft-ietf-pkix-cmc-05.txt
Date: Wed, 28 Jul 1999 07:40:36 -0700
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.00.2918.2701
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2918.2701

Bill -
----- Original Message -----
From: Flanigan, Bill <[e-mail]>
To: <[e-mail]>
Sent: Wednesday, July 28, 1999 5:24 AM
Subject: RE: LAST CALL: draft-ietf-pkix-cmc-05.txt


> Slapping an RFC number on half-baked protocols is indeed experimental.  So
> why not make it so (pro-actively for CMC and retro-actively for CMP)?  And
> what's wrong with progressing from Experimental to new I-D to Proposed
when
> the darn thing finally works?

This implies that there might need to be a re-straifitcation of the concept
I-D into several working class documents, proposal, in-discussion-process,
RFC Candidate, etc... probably not a bad idea.

>I believe that vendors and early adopters
> striving to be open-standards compliant are growing weary of being PKIX
> guinea pigs (which seems tantamount to being played for suckers).
>

This is in and of itself a really important concept since what it says is
that the "Industry wants End-Use Solutions" and not complex "you figure out
how to use it yourself" stuff that  we have to put together so far per say.

My feeling is that you are exactly right on here. What this group needs more
than anything now in my opinion is the completion of the PKIX4
recommendation and also the creation of some use-model recommendations to go
with the core enablement we have already developed.

Todd





Received: from mongoose.slip.net (mongoose.slip.net [207.171.193.14]) by mail.proper.com (8.9.3/8.9.3) with ESMTP id HAA02591 for <[e-mail]>; Wed, 28 Jul 1999 07:00:54 -0700 (PDT)
Received: from [38.30.144.213] (helo=sn2545454) by mongoose.slip.net with smtp (Exim 2.12 #4) id 119UIX-0007K9-00 for [e-mail]; Wed, 28 Jul 1999 07:03:10 -0700
From: "Eric Greenberg" <[e-mail]>
To: <[e-mail]>
Subject: 
Date: Wed, 28 Jul 1999 09:58:30 -0400
Message-ID: <000001bed901$46763820$[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.3110.3

subscribe



Received: from puma.baltimore.ie ([e-mail] [194.125.215.8]) by mail.proper.com (8.9.3/8.9.3) with ESMTP id GAA25756 for <[e-mail]>; Wed, 28 Jul 1999 06:03:58 -0700 (PDT)
Received: by puma.baltimore.ie; id OAA02553; Wed, 28 Jul 1999 14:59:38 +0100 (GMT/IST)
Received: from bobcat.baltimore.ie(192.168.20.10) by puma.baltimore.ie via smap (4.1) id xma002540; Wed, 28 Jul 99 14:59:29 +0100
Received: from knuckle (knuckle.baltimore.ie [192.168.21.91]) by bobcat.baltimore.ie (8.9.3/8.9.3) with SMTP id OAA02225 for <[e-mail]>; Wed, 28 Jul 1999 14:07:43 +0100
From: "William Whyte" <[e-mail]>
To: <[e-mail]>
Subject: X9.42 and RFC2459 inconsistency?
Date: Wed, 28 Jul 1999 14:05:50 +0100
Message-ID: <001901bed8f9$ea867810$[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook 8.5, Build 4.71.2377.0
X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3155.0
In-Reply-To: <[e-mail]>
Importance: Normal

And in a good day for questions from Baltimore...

There seems to be an inconsistency between X9.42 and RFC 2459 about
how to encode Diffie-Hellman public keys. RFC 2459 says this:

   The Diffie-Hellman public key shall be ASN.1 encoded as an INTEGER;
   this encoding shall be used as the contents (i.e., the value) of the
   subjectPublicKey component (a BIT STRING) of the subjectPublicKeyInfo
   data element.

which, to me, reads like you end up with a BIT STRING, containing an
INTEGER, containing the data. On the other hand, X9.42 says this:

   The public key (an INTEGER) is mapped to a subjectPublicKey (a BIT 
   STRING) such that the most significant bit of the INTEGER becomes 
   the most significant bit of the BIT STRING and the least significant
   bit of the INTEGER becomes the least significant bit of the BIT STRING.
   The integer therefore remains encoded in "big-endian" format. If the 
   integer is not an integral number of octets in length, the BIT STRING 
   encoding indicates the number of unused bits in the last octet of the 
   encoding.

which reads like you take the ASN.1 INTEGER, strip off the tag, left-shift 
it until the most significant bit is set, and then encode it as a BIT
STRING with the appropriate number of unused bits, not containing an
INTEGER at all.

The PKIX version is consistent with the treatment of DSA (BIT STRING
wrapping INTEGER) and RSA (BIT STRING wrapping SEQUENCE). The X9.42
version saves up to four bytes, but is very annoying to implement because
of the left-shifting. But they definitely seem to be saying different
things.

Am I reading both standards right? My copy of X9.42 dates from October
last year -- is that the source of the problem?

Cheers,

William



Received: from puma.baltimore.ie ([e-mail] [194.125.215.8]) by mail.proper.com (8.9.3/8.9.3) with ESMTP id FAA24878 for <[e-mail]>; Wed, 28 Jul 1999 05:44:48 -0700 (PDT)
Received: by puma.baltimore.ie; id OAA00687; Wed, 28 Jul 1999 14:40:28 +0100 (GMT/IST)
Received: from bobcat.baltimore.ie(192.168.20.10) by puma.baltimore.ie via smap (4.1) id xma000662; Wed, 28 Jul 99 14:39:38 +0100
Received: from sage.baltimore.ie (IDENT:[e-mail] [192.168.21.125]) by bobcat.baltimore.ie (8.9.3/8.9.3) with ESMTP id NAA01119 for <[e-mail]>; Wed, 28 Jul 1999 13:47:53 +0100
Received: from sage.baltimore.ie (IDENT:keith@localhost [127.0.0.1]) by sage.baltimore.ie (8.9.3/8.9.3) with ESMTP id NAA17917 for <[e-mail]>; Wed, 28 Jul 1999 13:47:18 +0100
Message-Id: <[e-mail]>
To: [e-mail]
Subject: Re: LAST CALL: draft-ietf-pkix-cmc-05.txt 
Date: Wed, 28 Jul 1999 13:47:18 +0100
From: Keith Brady <[e-mail]>

 "Flanigan," == Flanigan, Bill <[e-mail]> writes:

Flanigan,> Slapping an RFC number on half-baked protocols is indeed
Flanigan,> experimental. So why not make it so (pro-actively for CMC and
Flanigan,> retro-actively for CMP)? And what's wrong with progressing from

I'm not sure we're actually that far from having working interop. Not all
of Bob's report is doom and gloom and we expect better results at the next
one. Granted, we maybe should have started an interop before it hit RFC
(though Entrust and ourselves did do a CCR/CCP) but sometimes we want to
avoid the dev effort in interop'ing standards that are going to change
incompatibly anyway (remember the message body renumbering?)

my 2p's worth,

Keith
--
Keith Brady,                                    Phone: [phone] 
Baltimore Technologies,                           Fax: [phone]
IFSC House, Custom House Quay,                <http://www.baltimore.ie>
Dublin 1, Ireland


Received: from puma.baltimore.ie ([e-mail] [194.125.215.8]) by mail.proper.com (8.9.3/8.9.3) with ESMTP id FAA24706 for <[e-mail]>; Wed, 28 Jul 1999 05:42:46 -0700 (PDT)
Received: by puma.baltimore.ie; id OAA00517; Wed, 28 Jul 1999 14:38:26 +0100 (GMT/IST)
Received: from bobcat.baltimore.ie(192.168.20.10) by puma.baltimore.ie via smap (4.1) id xma000504; Wed, 28 Jul 99 14:38:05 +0100
Received: from skull (skull.baltimore.ie [192.168.21.83]) by bobcat.baltimore.ie (8.9.3/8.9.3) with SMTP id NAA01002 for <[e-mail]>; Wed, 28 Jul 1999 13:46:19 +0100
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Light Version 3.0.5 (32)
Date: Wed, 28 Jul 1999 13:46:35 +0100
To: [e-mail]
From: Eamonn Maher <[e-mail]>
Subject: Extended Key Usage for OCSP signing and IPSEC
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"

1. 
If the ExtendedKeyUsages extension is critical then it must be consistent with 
the KeyUsage extension (if present and critical - which it SHOULD be). Then 
what KeyUsage bits should be set if the extension contains the OCSP signing 
OID? just digitalSignature?

2.
Why are the extended key purpose OIDs for IPSEC (id-kp-ipsecEndSystem,
id-kp-ipsecTunnel and id-kp-ipsecUser) defined in rfc 2459?
In 
http://www.ietf.org/internet-drafts/draft-ietf-ipsec-pki-req-02.txt
only iKEEnd and iKEIntermediate are defined.

3.
What valid combinations are there of KeyUsage and the above PKIX IPSEC 
extendedKeyUsages and the IPSEC extendedKeyUsages?

Eamonn


Received: from rbhub100.chamb.disa.mil (rbhub100.chamb.disa.mil [209.22.120.23]) by mail.proper.com (8.9.3/8.9.3) with ESMTP id FAA23607 for <[e-mail]>; Wed, 28 Jul 1999 05:19:00 -0700 (PDT)
Received: by rbhub100.chamb.disa.mil with Internet Mail Service (5.5.2448.0) id <PY5LKYCK>; Wed, 28 Jul 1999 08:21:31 -0400
Message-ID: <[e-mail]>
From: "Flanigan, Bill" <[e-mail]>
To: [e-mail]
Subject: RE: LAST CALL: draft-ietf-pkix-cmc-05.txt
Date: Wed, 28 Jul 1999 08:24:53 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2448.0)
Content-Type: text/plain

Slapping an RFC number on half-baked protocols is indeed experimental.  So
why not make it so (pro-actively for CMC and retro-actively for CMP)?  And
what's wrong with progressing from Experimental to new I-D to Proposed when
the darn thing finally works?  I believe that vendors and early adopters
striving to be open-standards compliant are growing weary of being PKIX
guinea pigs (which seems tantamount to being played for suckers).

Bill

> ----------
> From: 	Paul Hoffman / IMC[SMTP:[e-mail]]
> Sent: 	Tuesday, July 27, 1999 8:28 PM
> To: 	[e-mail]
> Subject: 	RE: LAST CALL: draft-ietf-pkix-cmc-05.txt
> 
> At 02:37 PM 7/27/1999 -0700, Warwick Ford wrote:
> >      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...
> 
> This doesn't prevent someone from doing an implementation; it prevents
> them 
> (or should prevent them) from shipping it as a product. There is a huge 
> difference. The reasons for CMC existing at all are needs that are stated 
> in the document. If these are real needs, there are probably developers
> who 
> would like to meet those needs.
> 
> >I think any I-D implementation requirement would be highly dubious.
> 
> We disagree here. I think I-D implementations help decide whether complex 
> protocols like CMC and CMP will possibly work.
> 
> >   I can
> >imagine that many implementors are awaiting stabilization of the spec.
> >(i.e., progression to Proposed Standard status) before even starting to
> >implement.
> 
> That may be true, and in general that's OK. However, CMC and CMP attack
> the 
> same problem and use many of the same technologies. Because we now know 
> that there are probable flaws in CMP, it might be wise to make sure that 
> similar problems are fixed in CMC before putting it on standards track.
> The 
> way the flaws were found was with interoperability testing, not by reading
> 
> the spec, as many of us did with CMP.
> 
> If you are correct in saying that developers aren't going to start 
> implementing until they see an RFC, then we should definitely put it out. 
> On the other hand, if there is already one or two developers with at least
> 
> partial implementations, testing could help avoid problems that have been 
> found with CMP.
> 
> >   Given the lengthy review this document has received (over at
> >least 2 years), I see no good reason for changing the usual procedures.
> 
> The "usual procedures" for complex protocols for which there are no known 
> implementations are often Experimental RFCs.
> 
> If you feel that CMC has absolutely none of the flaws found in the CMP 
> interoperability testing, that's fine, but I would want to know why you 
> feel that way. None of us thought that CMP would test as badly as it did, 
> given all the review that was done on it.
> 
> --Paul Hoffman, Director
> --Internet Mail Consortium
> 


Received: from mail02-ewr.pilot.net (mail-ewr-2.pilot.net [206.98.230.16]) by mail.proper.com (8.9.3/8.9.3) with ESMTP id UAA08501 for <[e-mail]>; Tue, 27 Jul 1999 20:36:51 -0700 (PDT)
From: [e-mail]
Received: from mailgw.firstdata.com (unknown-27-166.firstdata.com [204.48.27.166] (may be forged)) by mail02-ewr.pilot.net with ESMTP id XAA10106; Tue, 27 Jul 1999 23:34:58 -0400 (EDT)
Received: from lnsunr02.firstdata.com (lnsunr02.firstdata.com [192.168.247.16]) by mailgw.firstdata.com with SMTP id XAA28734; Tue, 27 Jul 1999 23:34:57 -0400 (EDT)
Received: by lnsunr02.firstdata.com(Lotus SMTP MTA v4.6.4  (830.2 3-23-1999))  id 852567BC.00134986 ; Tue, 27 Jul 1999 23:30:40 -0400
X-Lotus-FromDomain: FDC
To: Stephen Kent <[e-mail]>
cc: "David P. Kemp" <[e-mail]>, [e-mail]
Message-ID: <[e-mail]>
Date: Tue, 27 Jul 1999 16:40:48 -0700
Subject: RE: KISS for PKIX. (authentication/authorization seperation)
Mime-Version: 1.0
Content-type: text/plain; charset=us-ascii
Content-Disposition: inline

re: authentication/authorization seperation

we seem to be dealing with two different issues ... possible analogy is
gravitational force distances vis-a-vis sub-atomic partical force distances.

seperation of authentication and authorization between different random
organizations ... where critical business dependancies falls to competitors with
different goals, objectives and policies I consider not a good thing.

however, it is reasonable to consider consistent & controlled checks & balances
within a business unit desirable. in some situations, finance industry will have
critical approval personal on mandated vacation ... so others are foced to
participate in approval process. there can also be sophisticated controls to
preclude collusion between collections of people attempting to bypass
organizational checks and balances. such operations tend to have consistent
policies and practives and capable of enforcing checks & balances consistency
within a business operating unit.

such considerations is far different from seperating authentication and
authorization by such wide margins that various operations may actually randomly
& uncontrollably be undertaken by direct competitors.

as such, i considered that i've been making statements regarding
(authenticaqtion & authorization) seperation guidelines operating from fthe
context of gravatational distances vis-a-vis other statements about guidelines
applied at sub-atomic particle distances.

within business context, creating a very high integrity security perimeter and
operating practices ... and then allowing critical operations to occur outside
of that perimeter (and at a much lower &/or unknown integrity level) is foolish
seperation of function. that is a totally seperate issue from sophisticated
anti-collusion practices that might occur within known security perimeter and
operating practices.

from a business practices standpoint there is also an issue of infrastructure
complexity ... creating multiple independent security perimeters and operating
practifces ... solely to address the anti-collusion problem is frequently not
justified ... i.e. anti-collusion tends to play at some of the higher integrity
levels .... and multiple independent secruity perimeters and their required
interaction not only drives up the cost significantly ... but can also
contribute to infrastructure degradation because of increase complexity of
interactions and unforeseen failure modes
(i.e. directly related to violating KISS).

At least some major consideration for looking at account authority solution was
to "cost-share"
existing security perimeter & operating practices w/o necessarily having to
create new ones ... especially when it can be shown that such leveraging at
least increases the integrity of the environment at the optimal
price/performance ... resulting in maximum ROI.




Received: from www.meridianus.com (209.249.223.10.has.no.reverse [209.249.223.10] (may be forged)) by mail.proper.com (8.9.3/8.9.3) with ESMTP id RAA06146; Tue, 27 Jul 1999 17:59:22 -0700 (PDT)
Received: from PC1 by www.meridianus.com (8.8.8+Sun/SMI-SVR4) id SAA11626; Tue, 27 Jul 1999 18:56:06 -0700 (PDT)
Message-ID: <018601bed896$adb18960$[e-mail]>
From: "tog" <[e-mail]>
To: <[e-mail]>, "Paul Hoffman / IMC" <[e-mail]>
Cc: "POISED-WG" <[e-mail]>
References: <[e-mail]>
Subject: Re: LAST CALL: draft-ietf-pkix-cmc-05.txt
Date: Tue, 27 Jul 1999 18:15:28 -0700
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.00.2918.2701
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2918.2701

All
----- Original Message -----
From: Paul Hoffman / IMC <[e-mail]>
To: <[e-mail]>
Sent: Tuesday, July 27, 1999 1:59 PM
Subject: Re: LAST CALL: draft-ietf-pkix-cmc-05.txt


> At 01:12 PM 7/27/1999 -0700, Warwick Ford wrote:
> >This document is hereby issued for 14-day WG last call.
>
> OK, here's a tricky question: has anyone actually implemented the current
> draft? If not, should we try to move it forwards?

My feeling is that the protocol model is robust enough so that it deserves
to get advanced, however we have these POISED requirements, so maybe if we
do not advance it then we should at least mark it as "automatically
advanced" as soon as the advancement criteria is met -poof its done.

This leaves it up to the sponsors to actually make sure that their efforts
are successful and that they have two impliementations of their beast as per
the RFC2026 requirements. But it also enables that any technology
specification should fast track through approval if it satisfies the staging
requirements in 2026. I think this is a really good idea, myself.

This effort might actually take a change to RFC2026, but is likely that also
that the WG Chairs can agree that within PKIX such a status exists. Yo
Warwick and Stephen, does this work for the groups purposes?.

>
> I ask this because of the dismal track record of CMP. Many months after it
> was put on standards track, interoperability testing began, and it was

--- SNIP ---




Received: from aum (ip11.proper.com [165.227.249.11]) by mail.proper.com (8.9.3/8.9.3) with ESMTP id RAA05606 for <[e-mail]>; Tue, 27 Jul 1999 17:28:00 -0700 (PDT)
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58 
Date: Tue, 27 Jul 1999 17:28:46 -0700
To: [e-mail]
From: Paul Hoffman / IMC <[e-mail]>
Subject: RE: LAST CALL: draft-ietf-pkix-cmc-05.txt
In-Reply-To: <[e-mail] >
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed

At 02:37 PM 7/27/1999 -0700, Warwick Ford wrote:
>      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...

This doesn't prevent someone from doing an implementation; it prevents them 
(or should prevent them) from shipping it as a product. There is a huge 
difference. The reasons for CMC existing at all are needs that are stated 
in the document. If these are real needs, there are probably developers who 
would like to meet those needs.

>I think any I-D implementation requirement would be highly dubious.

We disagree here. I think I-D implementations help decide whether complex 
protocols like CMC and CMP will possibly work.

>   I can
>imagine that many implementors are awaiting stabilization of the spec.
>(i.e., progression to Proposed Standard status) before even starting to
>implement.

That may be true, and in general that's OK. However, CMC and CMP attack the 
same problem and use many of the same technologies. Because we now know 
that there are probable flaws in CMP, it might be wise to make sure that 
similar problems are fixed in CMC before putting it on standards track. The 
way the flaws were found was with interoperability testing, not by reading 
the spec, as many of us did with CMP.

If you are correct in saying that developers aren't going to start 
implementing until they see an RFC, then we should definitely put it out. 
On the other hand, if there is already one or two developers with at least 
partial implementations, testing could help avoid problems that have been 
found with CMP.

>   Given the lengthy review this document has received (over at
>least 2 years), I see no good reason for changing the usual procedures.

The "usual procedures" for complex protocols for which there are no known 
implementations are often Experimental RFCs.

If you feel that CMC has absolutely none of the flaws found in the CMP 
interoperability testing, that's fine, but I would want to know why you 
feel that way. None of us thought that CMP would test as badly as it did, 
given all the review that was done on it.

--Paul Hoffman, Director
--Internet Mail Consortium


Received: from caladan.verisign.com (caladan.verisign.com [205.180.232.21]) by mail.proper.com (8.9.3/8.9.3) with ESMTP id OAA02755; Tue, 27 Jul 1999 14:35:36 -0700 (PDT)
Received: from mentat.verisign.com by caladan.verisign.com (8.8.5/BCH1.5) id OAA27392; Tue, 27 Jul 1999 14:36:11 -0700 (PDT)
Received: from newman.verisign.com by mentat.verisign.com (8.8.5/BCH1.0) id OAA14452; Tue, 27 Jul 1999 14:37:27 -0700 (PDT)
Received: by newman.verisign.com with Internet Mail Service (5.5.2448.0) id <PQHF0123>; Tue, 27 Jul 1999 14:37:29 -0700
Message-ID: <[e-mail]>
From: Warwick Ford <[e-mail]>
To: "'Paul Hoffman / IMC'" <[e-mail]>, [e-mail]
Subject: RE: LAST CALL: draft-ietf-pkix-cmc-05.txt
Date: Tue, 27 Jul 1999 14:37:27 -0700
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2448.0)
Content-Type: text/plain; charset="iso-8859-1"

Paul:

     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...

I think any I-D implementation requirement would be highly dubious.  I can
imagine that many implementors are awaiting stabilization of the spec.
(i.e., progression to Proposed Standard status) before even starting to
implement.  Given the lengthy review this document has received (over at
least 2 years), I see no good reason for changing the usual procedures. 

Warwick

> -----Original Message-----
> From: Paul Hoffman / IMC [mailto:[e-mail]]
> Sent: Tuesday, July 27, 1999 2:00 PM
> To: [e-mail]
> Subject: Re: LAST CALL: draft-ietf-pkix-cmc-05.txt
> 
> 
> At 01:12 PM 7/27/1999 -0700, Warwick Ford wrote:
> >This document is hereby issued for 14-day WG last call.
> 
> OK, here's a tricky question: has anyone actually implemented 
> the current 
> draft? If not, should we try to move it forwards?
> 
> I ask this because of the dismal track record of CMP. Many 
> months after it 
> was put on standards track, interoperability testing began, 
> and it was 
> found to be a nightmare that will almost assuredly cause the 
> spec to be 
> rewritten for clarification, and possibly to change bits on 
> the wire. (See 
> draft-moskowitz-cmpinterop for more information on the testing.)
> 
> If no one has what they think of as a full implementation of 
> CMC, I propose 
> that we wait until at least one person does. If we have only one 
> implementation of CMC, I suggest that we ask for it to be made an 
> Experimental Standard instead of a Proposed Standard. If we have two 
> implementations that can at least talk to each other a little 
> bit, let's 
> try to get it to become a Proposed Standard.
> 
> I realize that these are *not* the rules as defined in RFC 
> 2026, but due to 
> our lack of attention on CMP, I think we have to be more 
> careful with CMC.
> 
> --Paul Hoffman, Director
> --Internet Mail Consortium


Received: from aum (ip11.proper.com [165.227.249.11]) by mail.proper.com (8.9.3/8.9.3) with ESMTP id NAA01916 for <[e-mail]>; Tue, 27 Jul 1999 13:58:00 -0700 (PDT)
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58 
Date: Tue, 27 Jul 1999 13:59:59 -0700
To: [e-mail]
From: Paul Hoffman / IMC <[e-mail]>
Subject: Re: LAST CALL: draft-ietf-pkix-cmc-05.txt
In-Reply-To: <[e-mail] >
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed

At 01:12 PM 7/27/1999 -0700, Warwick Ford wrote:
>This document is hereby issued for 14-day WG last call.

OK, here's a tricky question: has anyone actually implemented the current 
draft? If not, should we try to move it forwards?

I ask this because of the dismal track record of CMP. Many months after it 
was put on standards track, interoperability testing began, and it was 
found to be a nightmare that will almost assuredly cause the spec to be 
rewritten for clarification, and possibly to change bits on the wire. (See 
draft-moskowitz-cmpinterop for more information on the testing.)

If no one has what they think of as a full implementation of CMC, I propose 
that we wait until at least one person does. If we have only one 
implementation of CMC, I suggest that we ask for it to be made an 
Experimental Standard instead of a Proposed Standard. If we have two 
implementations that can at least talk to each other a little bit, let's 
try to get it to become a Proposed Standard.

I realize that these are *not* the rules as defined in RFC 2026, but due to 
our lack of attention on CMP, I think we have to be more careful with CMC.

--Paul Hoffman, Director
--Internet Mail Consortium


Received: from chi6sosrv11.alter.net (chi6sosrv11.alter.net [208.204.150.57]) by mail.proper.com (8.9.3/8.9.3) with ESMTP id NAA01310 for <[e-mail]>; Tue, 27 Jul 1999 13:16:04 -0700 (PDT)
Received: from xedia.com by chi6sosrv11.alter.net with SMTP  (peer crosschecked as: madway.xedia.com [198.202.232.199]) id QQgzsj27611; Tue, 27 Jul 1999 20:18:19 GMT
Received: from tonga.xedia.com by xedia.com (4.1/SMI-4.1) id AA08056; Tue, 27 Jul 99 16:16:58 EDT
Received: by tonga.xedia.com (SMI-8.6/SMI-SVR4) id QAA17226; Tue, 27 Jul 1999 16:18:18 -0400
Date: Tue, 27 Jul 1999 16:18:18 -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: humo[u]r in law
References: <000301bed86d$fa8493a0$[e-mail]>
X-Mailer: VM 6.34 under 20.3 "Vatican City" XEmacs  Lucid

>>>>> "Peter" == Peter Williams <[e-mail]> writes:

 Peter> If an certificate-bearing, encrypted S/MIME message
 Peter> (BER-encoded) is encrypted under an S/MIME process, and a
 Peter> party hands over the keying material necessary to decrypt the
 Peter> payload to ANY court (including an International court
 Peter> presumably), is the result "readable and comprehensible" -
 Peter> being BER-encoded?

 Peter> The corollary of this, if true, is that it would define all
 Peter> BER-encoded data (such as certificates) as having a readable
 Peter> and comprehensible format. This has relevance to that debate
 Peter> which demands that consumers have obtained "readable and
 Peter> comprensible" certificates before they can be held to have
 Peter> truly accepted a certificate.

I don't see a problem.  "Readable and comprehensible" doesn't have to
apply to the raw data; it's perfectly reasonable to rely on a tool.
For example, a tape recording of someone speaking in plain language
should be considered to meet those criteria, yet without a tape player 
it is a useless bit of plastic.

A somewhat related topic appears in US FCC regulations, part 97:
Amateur radio transmissions may not be encrypted (with a very small
limited exception).  For purposes of that rule, encodings that are
defined by readily accessible specifications and aren't intended to
obscure the contents are not considered "encryption"; the fact that
such an encoding may be complex and may require special decoding
apparatus to convert the signal into humanly-intellegible form is no
object. 

	paul


Received: from caladan.verisign.com (caladan.verisign.com [205.180.232.21]) by mail.proper.com (8.9.3/8.9.3) with ESMTP id NAA01088 for <[e-mail]>; Tue, 27 Jul 1999 13:10:55 -0700 (PDT)
Received: from mentat.verisign.com by caladan.verisign.com (8.8.5/BCH1.5) id NAA24005; Tue, 27 Jul 1999 13:11:29 -0700 (PDT)
Received: from newman.verisign.com by mentat.verisign.com (8.8.5/BCH1.0) id NAA09977; Tue, 27 Jul 1999 13:12:46 -0700 (PDT)
Received: by newman.verisign.com with Internet Mail Service (5.5.2448.0) id <PQHF0DP6>; Tue, 27 Jul 1999 13:12:47 -0700
Message-ID: <[e-mail]>
From: Warwick Ford <[e-mail]>
To: "'[e-mail]'" <[e-mail]>
Cc: "'Jim Schaad (Exchange)'" <[e-mail]>
Subject: LAST CALL: draft-ietf-pkix-cmc-05.txt
Date: Tue, 27 Jul 1999 13:12:45 -0700
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2448.0)
Content-Type: text/plain; charset="iso-8859-1"

This document is hereby issued for 14-day WG last call.


-----Original Message-----
From: [e-mail] [mailto:[e-mail]] 
Sent: Monday, July 19, 1999 4:34 AM
To: IETF-Announce; @imc.org
Cc: [e-mail]
Subject: I-D ACTION:draft-ietf-pkix-cmc-05.txt


A New Internet-Draft is available from the on-line Internet-Drafts
directories.
This draft is a work item of the Public-Key Infrastructure (X.509) Working
Group of the IETF.

	Title		: Certificate Management Messages over CMS
	Author(s)	: M. Myers, X. Liu,  J. Schaad, J. Weinstein	
        Filename	: draft-ietf-pkix-cmc-05.txt
	Pages		: 39
	Date		: 16-Jul-99
	
This document defines a Certificate Management protocol using CMS (CMC).
This protocol addresses two immediate needs within the Internet PKI
community:
 
1. The need for an interface to public key certification products and
   services based on [CMS] and [PKCS10], and
2. The need in [SMIMEV3] for a certificate enrollment protocol for DSA-
   signed certificates with Diffie-Hellman public keys.
 
A small number of additional services are defined to supplement the core
certificate request service.
 
Throughout this specification the term CMS is used to refer to both [CMS]
and [PKCS7].  For signedData the two specifications are equivalent.  For
envelopedData CMS is a superset of the PKCS7. In general, the use of
PKCS7 in this document is aligned to the Cryptographic Message Syntax
[CMS] that provides a superset of the PKCS7 syntax. The term CMC refers
to this specification.
 
The key words 'MUST', 'REQUIRED', 'SHOULD', 'RECOMMENDED', and 'MAY' in
this document are to be interpreted as described in [RFC 2119].

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-pkix-cmc-05.txt

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-ietf-pkix-cmc-05.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt


Internet-Drafts can also be obtained by e-mail.

Send a message to:
	[e-mail].
In the body type:
	"FILE /internet-drafts/draft-ietf-pkix-cmc-05.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.
		
		
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.


Received: from ns1.dmz.valicert.com (ns1.valicert.com [63.65.221.10]) by mail.proper.com (8.9.3/8.9.3) with ESMTP id NAA00810 for <[e-mail]>; Tue, 27 Jul 1999 13:04:04 -0700 (PDT)
Received: from ns1.serverfarm.valicert.com (corporate-gw.valicert.com [63.65.221.2]) by ns1.dmz.valicert.com (8.9.2/8.9.2) with ESMTP id NAA10350 for <[e-mail]>; Tue, 27 Jul 1999 13:04:27 -0700 (PDT)
Received: from rsalaptop (dhcp-3-230.engineering.valicert.com [192.168.3.230]) by ns1.serverfarm.valicert.com (8.9.2/8.9.2) with SMTP id NAA09008 for <[e-mail]>; Tue, 27 Jul 1999 13:05:55 -0700 (PDT)
From: "Peter Williams" <[e-mail]>
To: "Pkix" <[e-mail]>
Subject: humo[u]r in law
Date: Tue, 27 Jul 1999 13:24:07 -0700
Message-ID: <000301bed86d$fa8493a0$[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset="Windows-1252"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.0810.800

"SEC. 14. FAILURE TO DECRYPT INFORMATION OBTAINED UNDER COURT ORDER. Whoever
is required by an order of any court to provide to the court or any other
party any information in such person's possession which has been encrypted
and who, having possession of the key or such other capability to decrypt
such information into the readable or comprehensible format of such
information prior to its encryption, fails to provide such information in
accordance with the order in such readable or comprehensible form"

If an certificate-bearing, encrypted S/MIME message
(BER-encoded) is encrypted under an S/MIME process,
and a party hands over the keying material necessary to
decrypt the payload to ANY court (including an International
court presumably), is the result "readable and comprehensible" - being
BER-encoded?

The corollary of this, if true, is that it would
define all BER-encoded data (such as certificates)
as having a readable and comprehensible format. This
has relevance to that debate which demands that consumers
have obtained "readable and comprensible" certificates
before they can be held to have truly accepted
a certificate.

Only following acceptance, in many law environments nowadays,
is the certificate valid, and only then can one
establish the validity of a certificate, and/or
the validity of a particular certificate chain.










Received: from mail-out1.apple.com (mail-out1.apple.com [17.254.0.52]) by mail.proper.com (8.9.3/8.9.3) with ESMTP id IAA27533 for <[e-mail]>; Tue, 27 Jul 1999 08:49:12 -0700 (PDT)
Received: from mailgate2.apple.com ([17.129.100.225]) by mail-out1.apple.com (8.8.5/8.8.5) with ESMTP id IAA38694 for <[e-mail]>; Tue, 27 Jul 1999 08:51:34 -0700
Received: from scv4.apple.com (scv4.apple.com) by mailgate2.apple.com (Content Technologies SMTPRS 2.0.15) with ESMTP id <[e-mail]> for <[e-mail]>; Tue, 27 Jul 1999 09:51:31 -0700
Received: from [17.205.41.210] (aram4.apple.com [17.205.41.210]) by scv4.apple.com (8.9.3/8.9.3) with ESMTP id IAA43170 for <[e-mail]>; Tue, 27 Jul 1999 08:51:30 -0700
Message-Id: <[e-mail]>
X-Mailer: Microsoft Outlook Express Macintosh Edition - 4.5 (0410)
Date: Tue, 27 Jul 1999 08:51:24 -0700
Subject: Re: KISS for PKIX
From: "Aram Perez" <[e-mail]>
To: [e-mail]
MIME-Version: 1.0
X-Priority: 3
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: 7bit

Bill Flanigan wrote:

> Comments to comments to comments in CAPITALS below.
>
[snip]
>> What if AOL issued X.509 certificates to all of its subscribers, and used
>> those certificates solely as a replacement for passwords: the identity
>> proofing is no more and no less than that required to get an AOL password
>> today; no third-party issuers; no PKIX-specific policy statements other
>> than statements which currently exist (acceptable-use, data privacy, etc).
>> Please explain why these PKIX AOL login certs become any more unmanageable
>> if the number of AOL subscribers grows from 100K to 5,000K?
>>
> HMM, YOU'VE LOST ME HERE, DAVE.  I HAVE NO IDEA HOW AOL OPERATES.  BUT IF A
> CERT IS USED SOLELY AS A REPLACEMENT FOR A PASSWORD, WHY BOTHER?  (YOU WOULD
> PROBABLY HAVE TO TYPE IN A PASSWORD ANYWAY TO ACCESS THE CERT IN THE CLIENT
> (OR TOKEN) AND ENABLE IT TO BE SENT TO THE SERVER.)

There are many reasons why using certificates are better than passwords. In
case of AOL, since they are an "open system" providing thousands of access
points, they are subject to thousands of simultaneous password attacks.
Whereas, if I have a password to protect the private key that corresponds to
my AOL certificate, the attacker would have to have access to my private key
storage medium (which is generally NOT an "open system").

[snip]

Regards,
Aram Perez


Received: from mail-ewr-3.pilot.net (mail-ewr-3.pilot.net [206.98.230.17]) by mail.proper.com (8.9.3/8.9.3) with ESMTP id HAA24983 for <[e-mail]>; Tue, 27 Jul 1999 07:31:58 -0700 (PDT)
From: [e-mail]
Received: from mailgw.firstdata.com (unknown-27-166.firstdata.com [204.48.27.166] (may be forged)) by mail-ewr-3.pilot.net (Pilot/8.8.8) with ESMTP id KAA27104; Tue, 27 Jul 1999 10:34:19 -0400 (EDT)
Received: from lnsunr02.firstdata.com (lnsunr02.firstdata.com [192.168.247.16]) by mailgw.firstdata.com with SMTP id KAA17383; Tue, 27 Jul 1999 10:34:18 -0400 (EDT)
Received: by lnsunr02.firstdata.com(Lotus SMTP MTA v4.6.4  (830.2 3-23-1999))  id 852567BB.004FA5B0 ; Tue, 27 Jul 1999 10:29:57 -0400
X-Lotus-FromDomain: FDC
To: "Flanigan, Bill" <[e-mail]>
cc: "'David P. Kemp'" <[e-mail]>, [e-mail]
Message-ID: <[e-mail]>
Date: Tue, 27 Jul 1999 07:32:23 -0700
Subject: RE: KISS for PKIX .... password/digital signature
Mime-Version: 1.0
Content-type: text/plain; charset=us-ascii
Content-Disposition: inline

another characteristic (again applies to both aads as well as cads deployments)

is that protocol and authentication process can be common across a wide variety
of
integrity implementations for the source ... i.e. software protected private
key, hardware tokens for private key, pin activated token w/key, biometric
activated token w/key, assurance level of the token, assurance level of whether
dealing with known chip or possibly copy-chip.

somewhat not be encumbered with figuring out the meaning of a certificate ...
we've had little more luxary to look at other critical areas ... things like can
we parameterize the infrastructure and use the same infrastructure for very high
value things (possibly billions of dollars) as well as relatively low value
things (tens of cents) ... and leverage the infrastructure parameterization to
adapt of periods in the 50+ year scale. The result is that risk managers can
look at the infrastructure and make informed decisions regarding components
necessary for specific risk levels.

This is a avenue that could also be applied to certificate/offline
infrastructures ... although the perceived incremental value proposition would
be different ....  i.e. high value transaction risk assesement is not only
looking at integrity levels of the components but also various real time and
aggregated information

in that sense the certificate/account analogy is somewhat like badge entry
systems
... their are both online (aka account, presumably even DOD has at least some
online badge
entry systems) implemenations as well as offline (aka certificate) solutions for
badge entry systems. Offline/online choice can be combination of cost, risk and
liability. the liability one can be tortured trail  ... i.e. if something
adverse is learned then can a person be instantaneously fired and all access
revoked (liability can shift based on when something is known ... and business
processes like liability insurance can dictate how something is handled).




Received: from edelweb.fr (edelweb.fr [193.51.12.16]) by mail.proper.com (8.9.3/8.9.3) with ESMTP id HAA24349 for <[e-mail]>; Tue, 27 Jul 1999 07:14:49 -0700 (PDT)
Received: from champagne.edelweb.fr (localhost.edelweb.fr [127.0.0.1]) by edelweb.fr with ESMTP id QAA11687; Tue, 27 Jul 1999 16:17:05 +0200 (MET DST)
Received: from champagne.edelweb.fr (champagne.edelweb.fr [193.51.14.161]) by edelweb.fr (nospam/1.1); Tue, 27 Jul 1999 16:17:05 +0200 (MET DST)
Received: from emeriau.edelweb.fr (emeriau.edelweb.fr [193.51.14.5]) by champagne.edelweb.fr (8.7.6/8.6.6) with ESMTP id QAA11775; Tue, 27 Jul 1999 16:17:04 +0200 (MET DST)
From: Peter Sylvester <[e-mail]>
Received: (sylvest@localhost) by emeriau.edelweb.fr (8.7.6/8.6.6) id QAA22035; Tue, 27 Jul 1999 16:17:03 +0200 (MET DST)
Date: Tue, 27 Jul 1999 16:17:03 +0200 (MET DST)
Message-Id: <[e-mail]>
To: [e-mail]
Subject: Re: DRAFT PKIX WG Meeting Minutes
Cc: [e-mail]

Hi,

I would like to comment one item on the minutes (the content, not the minute item)

> Data Certification Server Protocol (C. Adams-Entrust)
> Peter Sylvester is the new lead editor and a new I-D has been published as
> of this week. Scope has been pretty broad, encompassing features of
> notarization OCSP, SCVP, TSP, etc. So, this is an example of the question
> raised on the list with regard to different protocols for different
> services, or a grand unified protocol approach. Possible options include
> freezing this spec now as an experimental protocol, reduce scope to avoid
> conflicts with other work items and continue as a standard track protocol,
> or keep broad scope and kill other protocols. Denis notes that, from a
> conformance standpoint, bundling would create the need to allow subset
> compliance, since not all clients or servers will need all of the features
> offered by a unified protocol. Discussion explored the dimensions in which
> one may choose to partition protocols, e.g., mandatory use of a server for
> non-repudiation vs. optional use of a server for operations that could be
> performed by a client.

The issue of bundling had been addresses in the initial draft:
A server can provide one or more of the services. 

"A DCS MAY support any subset of the following services: 
Certify Possession of Data, Certify Signature, Certify Public Key Certificate"

A client that desires a specific service need to be configured locally
anyway in order to reach the desired services. The protocol description
is open regarding operational scenarios where different servers 
are used by clients. 

Is local configuration (selection of a an appropriate server) part of
what should be described? There is already a hint in the draft that
explains how to publish the URL of a server in a certificate.

On of the problems that may occur is that a client may just be
configurable to use ONE server (and one transport) for all services.
Poor client, and there are people who are able to write little
proxies to relay requests (a DCS server itself can be such a relay).

Using an identical syntax for requests and tokens of the
different service has an implementation advantadge, you have one common
coder/decoder.  

Besides that, there is a small problem in the syntaxes of DCS and TSP:
They are not compatible with the syntax of CMS SignedData
(the EncapsulatedContent).


Peter Sylvester  



 


 


Received: from stingray.missi.ncsc.mil (stingray.missi.ncsc.mil [144.51.50.20]) by mail.proper.com (8.9.3/8.9.3) with ESMTP id FAA21048 for <[e-mail]>; Tue, 27 Jul 1999 05:22:23 -0700 (PDT)
Received: from stingray.missi.ncsc.mil (root@localhost) by stingray.missi.ncsc.mil with ESMTP id IAA03873 for <[e-mail]>; Tue, 27 Jul 1999 08:24:31 -0400 (EDT)
Received: from missi.ncsc.mil (depot.missi.ncsc.mil [144.51.60.1]) by stingray.missi.ncsc.mil with ESMTP id IAA03869 for <[e-mail]>; Tue, 27 Jul 1999 08:24:30 -0400 (EDT)
Received: from mimesweeper.missi.ncsc.mil (mimesweeper.missi.ncsc.mil [144.51.60.2]) by missi.ncsc.mil (8.8.8/8.8.8) with ESMTP id IAA07317 for <[e-mail]>; Tue, 27 Jul 1999 08:24:28 -0400 (EDT)
Received: from avenger.missi.ncsc.mil (avenger58.missi.ncsc.mil) by mimesweeper.missi.ncsc.mil (Content Technologies SMTPRS 2.0.15) with ESMTP id <[e-mail]>; Tue, 27 Jul 1999 08:22:57 -0400
Received: by avenger54.missi.ncsc.mil with Internet Mail Service (5.5.2232.9) id <NNT26VB1>; Tue, 27 Jul 1999 08:23:46 -0400
Message-Id: <[e-mail]>
From: "Miklos, Sue A." <[e-mail]>
To: "Kemp, David P." <[e-mail]>, [e-mail]
Subject: RE: KISS for PKIX
Date: Tue, 27 Jul 1999 08:23:38 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2232.9)
Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01BED82A.DEFB43EC"

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_01BED82A.DEFB43EC
Content-Type: text/plain;
	charset="iso-8859-1"

Dave, 

I believe that there is reference to the 'clearance' attribute ('97 X.501)
in the Attribute certificates w/TLS work.  Note that the clearance attribute
is one of three critical security information objects associated with prbac
(essLabel and security policy info. file being the other two critical SIOs).

My suggestion for the use of the nationality attribute was ONLY in the event
that the granularity of access control is constrained to a nationality,
which is not the most common event in the military community.

Sandi

-----Original Message-----
From: Kemp, David P. 
Sent: Tuesday, July 20, 1999 4:27 PM
To: [e-mail]
Subject: RE: KISS for PKIX


Russ Housley already provided an answer to this, under the message
thread "Showing Nationality in Cert".  I agree with Russ' answer:

  > I recommend SubjectDirectoryAttribute.
  >
  > Russ

as amplified by Bill Burr (the SDN.801 'prbacInfo' attribute for
structured privileges) and Sandi Miklos (the ACP133 'nationality'
attribute for nationality). See:
  http://www.armadillo.huntsville.al.us/Fortezza_docs/missi2.html
  http://csrc.nist.gov/pki/twg/dir_docs/ACP133.zip

I would also quote from The Open Group's proposed authorization API:

     4.2 Authorization Credentials
   
     ... We understand that a standardized credential format is on
     the most wanted list of many vendors, organizations, and end users.
     However, even though intimately connected to the actual implementation
     of the decision functions, we believe that we can hide the internal
     credentials structure from the calling resource manager.

which suggests that in the absence of an International Standard or
IETF-standard credential structure, the best that we can hope for
is that commercial applications will be written to a standardized API,
enabling the use of authorization plug-ins to handle community-specific
credential formats.

Does anyone believe that the IETF can or should standardize an
authorization credential format?




> From: "Flanigan, Bill" <[e-mail]>
> 
> > Certificates
> > allow users to be aggregated (by nationality, by clearance, by explicit
> > privilege, etc) 
>
> Dave,
> 
> 	Interesting.  Which PKIX/X.509 extensions do you recommend for these
> attributes?  Especially for "nationality".
> 
> Bill


------_=_NextPart_001_01BED82A.DEFB43EC
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.2232.0">
<TITLE>RE: KISS for PKIX</TITLE>
</HEAD>
<BODY>

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

<P><FONT SIZE=3D2>I believe that there is reference to the 'clearance' =
attribute ('97 X.501) in the Attribute certificates w/TLS work.&nbsp; =
Note that the clearance attribute is one of three critical security =
information objects associated with prbac (essLabel and security policy =
info. file being the other two critical SIOs).</FONT></P>

<P><FONT SIZE=3D2>My suggestion for the use of the nationality =
attribute was ONLY in the event that the granularity of access control =
is constrained to a nationality, which is not the most common event in =
the military community.</FONT></P>

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

<P><FONT SIZE=3D2>-----Original Message-----</FONT>
<BR><FONT SIZE=3D2>From: Kemp, David P. </FONT>
<BR><FONT SIZE=3D2>Sent: Tuesday, July 20, 1999 4:27 PM</FONT>
<BR><FONT SIZE=3D2>To: [e-mail]</FONT>
<BR><FONT SIZE=3D2>Subject: RE: KISS for PKIX</FONT>
</P>
<BR>

<P><FONT SIZE=3D2>Russ Housley already provided an answer to this, =
under the message</FONT>
<BR><FONT SIZE=3D2>thread &quot;Showing Nationality in =
Cert&quot;.&nbsp; I agree with Russ' answer:</FONT>
</P>

<P><FONT SIZE=3D2>&nbsp; &gt; I recommend =
SubjectDirectoryAttribute.</FONT>
<BR><FONT SIZE=3D2>&nbsp; &gt;</FONT>
<BR><FONT SIZE=3D2>&nbsp; &gt; Russ</FONT>
</P>

<P><FONT SIZE=3D2>as amplified by Bill Burr (the SDN.801 'prbacInfo' =
attribute for</FONT>
<BR><FONT SIZE=3D2>structured privileges) and Sandi Miklos (the ACP133 =
'nationality'</FONT>
<BR><FONT SIZE=3D2>attribute for nationality). See:</FONT>
<BR><FONT SIZE=3D2>&nbsp; <A =
HREF=3D"http://www.armadillo.huntsville.al.us/Fortezza_docs/missi2.html"=
 =
TARGET=3D"_blank">http://www.armadillo.huntsville.al.us/Fortezza_docs/mi=
ssi2.html</A></FONT>
<BR><FONT SIZE=3D2>&nbsp; <A =
HREF=3D"http://csrc.nist.gov/pki/twg/dir_docs/ACP133.zip" =
TARGET=3D"_blank">http://csrc.nist.gov/pki/twg/dir_docs/ACP133.zip</A></=
FONT>
</P>

<P><FONT SIZE=3D2>I would also quote from The Open Group's proposed =
authorization API:</FONT>
</P>

<P><FONT SIZE=3D2>&nbsp;&nbsp;&nbsp;&nbsp; 4.2 Authorization =
Credentials</FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp; </FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp;&nbsp;&nbsp; ... We understand that a =
standardized credential format is on</FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp;&nbsp;&nbsp; the most wanted list of =
many vendors, organizations, and end users.</FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp;&nbsp;&nbsp; However, even though =
intimately connected to the actual implementation</FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp;&nbsp;&nbsp; of the decision functions, =
we believe that we can hide the internal</FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp;&nbsp;&nbsp; credentials structure from =
the calling resource manager.</FONT>
</P>

<P><FONT SIZE=3D2>which suggests that in the absence of an =
International Standard or</FONT>
<BR><FONT SIZE=3D2>IETF-standard credential structure, the best that we =
can hope for</FONT>
<BR><FONT SIZE=3D2>is that commercial applications will be written to a =
standardized API,</FONT>
<BR><FONT SIZE=3D2>enabling the use of authorization plug-ins to handle =
community-specific</FONT>
<BR><FONT SIZE=3D2>credential formats.</FONT>
</P>

<P><FONT SIZE=3D2>Does anyone believe that the IETF can or should =
standardize an</FONT>
<BR><FONT SIZE=3D2>authorization credential format?</FONT>
</P>
<BR>
<BR>
<BR>

<P><FONT SIZE=3D2>&gt; From: &quot;Flanigan, Bill&quot; =
&lt;[e-mail]&gt;</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; Certificates</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; allow users to be aggregated (by =
nationality, by clearance, by explicit</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; privilege, etc) </FONT>
<BR><FONT SIZE=3D2>&gt;</FONT>
<BR><FONT SIZE=3D2>&gt; Dave,</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; &nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
Interesting.&nbsp; Which PKIX/X.509 extensions do you recommend for =
these</FONT>
<BR><FONT SIZE=3D2>&gt; attributes?&nbsp; Especially for =
&quot;nationality&quot;.</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; Bill</FONT>
</P>

</BODY>
</HTML>
------_=_NextPart_001_01BED82A.DEFB43EC--


Received: from wfhqex05.wangfed.com (netva01.wangfed.com [206.137.100.2]) by mail.proper.com (8.9.3/8.9.3) with ESMTP id MAA01540; Mon, 26 Jul 1999 12:37:40 -0700 (PDT)
Received: by wfhqex05.wangfed.com with Internet Mail Service (5.5.2448.0) id <PFHWKH7J>; Mon, 26 Jul 1999 15:40:17 -0400
Message-ID: <33BD629222C0D211B6DB0060085ACF313608DA@WFHQEX03>
From: "Pawling, John" <[e-mail]>
To: "'[e-mail]'" <[e-mail]>, [e-mail], [e-mail]
Subject: RE: Whither DSA+KEA certificates?
Date: Mon, 26 Jul 1999 15:40:16 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2448.0)
Content-Type: text/plain; charset="iso-8859-1"

Peter,

To my knowledge, there are no plans to use the combined DSA+KEA Fortezza v1
X.509 certs with S/MIME v3.  We are implementing the S/MIME Freeware Library
(SFL) to use standard X.509 certificates only.  I will send you more info
and sample certs in a separate message.

============================================
John Pawling, Director - Systems Engineering
J.G. Van Dyke & Associates, Inc.
[e-mail]
============================================


Received: from mail.student.auckland.ac.nz (mail.student.auckland.ac.nz [130.216.35.101]) by mail.proper.com (8.9.3/8.9.3) with ESMTP id LAA00624; Mon, 26 Jul 1999 11:36:54 -0700 (PDT)
Received: from kahu.cs.auckland.ac.nz ([e-mail] [130.216.36.13]) by mail.student.auckland.ac.nz (8.8.6/8.8.6/cs-master) with SMTP id GAA27473; Tue, 27 Jul 1999 06:38:50 +1200 (NZST) (sender [e-mail])
Received: by kahu.cs.auckland.ac.nz (relaymail v0.9) id <93301393403720>; Tue, 27 Jul 1999 06:32:14 (NZST)
From: [e-mail] (Peter Gutmann)
To: [e-mail], [e-mail]
Subject: Whither DSA+KEA certificates?
Sender: [e-mail]
Reply-To: [e-mail]
X-Charge-To: pgut001
X-Authenticated: relaymail v0.9 on kahu.cs.auckland.ac.nz
Date: Tue, 27 Jul 1999 06:32:14 (NZST)
Message-ID: <[e-mail]>

Does anyone know whether there's any need to try to support the combined DSA+
KEA certs which were going to be used with Fortezza?  Is anyone still using
these (characteristics: weird OID's, shared DSA parameters, combined DSA+KEA
keys in the cert)?  Are the post-declassification Fortezza cards using 
standard DSA and standard KEA certs, or still using the combined certs (can
anyone send me some samples)?  Are shared-parameter DSA certs still being
generated?  Apart from the fact that this allows cert signatures to be forged,
it's also a pain to check the certs... if these are still used, are things 
like root certs for them published anywhere?  SDN.706 specifies an algorithm 
to work with them, but doesn't say whether it's just for legacy support or 
not.

Related questions: Is MSP still alive?  Is Fortezza still alive?.  After 
brushing aside the cobwebs and dust on some MISSI-related sites I saw that the
standards are still being updated from time to time, but that doesn't really 
provide much indication of whether they're still live or not (feel free to 
reply in private/anonymously if answering questions about the viability of MSP
is a career-limiting move for you :-).

I haven't been able to find anything about whether the weird combined-key/
shared parameter certs are still being produced by anything and/or whether I 
need to support them.  Apparently they're covered in SDN.604, but this isn't
available online, draft-ietf-smime-cmskea.txt covers the use of the 
(declassified) KEA and Skipjack but doesn't touch on other legacies of MISSI.

Peter.



Received: from mail-ewr-3.pilot.net (mail-ewr-3.pilot.net [206.98.230.17]) by mail.proper.com (8.9.3/8.9.3) with ESMTP id LAA00104 for <[e-mail]>; Mon, 26 Jul 1999 11:17:02 -0700 (PDT)
From: [e-mail]
Received: from mailgw.firstdata.com (unknown-27-166.firstdata.com [204.48.27.166] (may be forged)) by mail-ewr-3.pilot.net (Pilot/8.8.8) with ESMTP id OAA25776; Mon, 26 Jul 1999 14:19:19 -0400 (EDT)
Received: from lnsunr02.firstdata.com (lnsunr02.firstdata.com [192.168.247.16]) by mailgw.firstdata.com with SMTP id OAA07610; Mon, 26 Jul 1999 14:19:18 -0400 (EDT)
Received: by lnsunr02.firstdata.com(Lotus SMTP MTA v4.6.4  (830.2 3-23-1999))  id 852567BA.00642EA4 ; Mon, 26 Jul 1999 14:14:15 -0400
X-Lotus-FromDomain: FDC
To: "David P. Kemp" <[e-mail]>
cc: [e-mail]
Message-ID: <[e-mail]>
Date: Mon, 26 Jul 1999 11:14:51 -0700
Subject: Re: KISS for PKIX
Mime-Version: 1.0
Content-type: text/plain; charset=us-ascii
Content-Disposition: inline

while DOD doesn't have that luxary ... and may have lots of infrastructures that
require distributed ... and effectively self-describing and self-authenticating
credentials ... most service providers ... including banks, internet service
providers and other types of businesses do hit account records as integral to
service provision ... and as such self-describing and self-authenticating
credentials can be viewed as superfulous and redundant.




Received: from mail-ewr-3.pilot.net (mail-ewr-3.pilot.net [206.98.230.17]) by mail.proper.com (8.9.3/8.9.3) with ESMTP id LAA29986 for <[e-mail]>; Mon, 26 Jul 1999 11:16:27 -0700 (PDT)
From: [e-mail]
Received: from mailgw.firstdata.com (unknown-27-166.firstdata.com [204.48.27.166] (may be forged)) by mail-ewr-3.pilot.net (Pilot/8.8.8) with ESMTP id OAA25579; Mon, 26 Jul 1999 14:18:36 -0400 (EDT)
Received: from lnsunr02.firstdata.com (lnsunr02.firstdata.com [192.168.247.16]) by mailgw.firstdata.com with SMTP id OAA07544; Mon, 26 Jul 1999 14:18:35 -0400 (EDT)
Received: by lnsunr02.firstdata.com(Lotus SMTP MTA v4.6.4  (830.2 3-23-1999))  id 852567BA.00642E14 ; Mon, 26 Jul 1999 14:14:13 -0400
X-Lotus-FromDomain: FDC
To: "Flanigan, Bill" <[e-mail]>
cc: "'David P. Kemp'" <[e-mail]>, [e-mail]
Message-ID: <[e-mail]>
Date: Mon, 26 Jul 1999 11:10:18 -0700
Subject: RE: KISS for PKIX
Mime-Version: 1.0
Content-type: text/plain; charset=us-ascii
Content-Disposition: inline

HMM, YOU'VE LOST ME HERE, DAVE.  I HAVE NO IDEA HOW AOL OPERATES.  BUT IF A CERT
IS USED SOLELY AS A REPLACEMENT FOR A PASSWORD, WHY BOTHER?  (YOU WOULD PROBABLY
HAVE TO TYPE IN A PASSWORD ANYWAY TO ACCESS THE CERT IN THE CLIENT (OR TOKEN)
AND ENABLE IT TO BE SENT TO THE SERVER.)  THIS SEEMS TO ME TO BE A NEXT-TO-ZERO
LEVEL OF ASSURANCE, WHICH IS NOT, I HOPE, WHAT PKIX IS ABOUT (WHY USE HDTV TO
VIEW TRANSPARENCIES MEANT TO BE USED WITH A MAGIC LANTERN?) AGAIN, DAVE, IT'S
SMART FOLKS LIKE YOURSELF WHO CAN HELP MAKE THE *RIGHT* MODIFICATIONS OR
ENGINEER AN OVERHAUL/ REPLACEMENT AND THEREBY GREATLY AID EARLY (AND LATER?)
ADOPTERS.  ONE WAY OR THE OTHER, I FEEL THAT THIS *CHASM OF COMPLEXITY* BETWEEN
PROTOCOL DEVELOPERS AND ADOPTERS MUST BE BRIDGED FOR PKIX/X.509 TO BECOME THE
PKI FLAVOR OF CHOICE FOR THE PLANET.


........................................................................................................................................................................

password is shared secret .... shared with the organization that is
authenticating you.

digital signature ... & public key in place of password has lots of appeal ...
especially
coupled with hardware token (applies to both CADS and AADS implemenations)

even if the hardware token is pin/password protected ... current password
compromise
can be done in number of ways (thru the network, social engineering, etc)  ...
and then just knowing the password, compromises the integrity of the service. In
the hardware token case, service
is only compromised if the hardware token is also stolen (something you have and
something
you know).

at recent presenation there were claims that password exploits were trivial in
great majority of cases because either 1) person used same password for all
their services (security exposure in itself) or 2) used all different passwords
... but had to write them all down and keep them in convenient place.

If #1 ... do various knowledge guessing &/or go after one of the lower security
systems to
 gather a copy and then exploit all systems

if #2 ... hire janitors to search in & around keyboards for password list.


integrity of hardware token is such that it is realistic to use same hardware
token for multiplicity of authentication purposes.




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 UAA12709 for <[e-mail]>; Fri, 23 Jul 1999 20:34:42 -0700 (PDT)
Received: from nma.com (pm04-17.sac.verio.net [209.162.64.130]) by tomcat.sac.verio.net (8.9.1a/8.9.1) with ESMTP id UAA26530 for <[e-mail]>; Fri, 23 Jul 1999 20:36:40 -0700 (PDT)
Message-ID: <[e-mail]>
Date: Fri, 23 Jul 1999 20:36:23 -0700
From: Ed Gerck <[e-mail]>
X-Mailer: Mozilla 4.51 [en] (Win98; I)
X-Accept-Language: en
MIME-Version: 1.0
CC: "'[e-mail]'" <[e-mail]>
Subject: Non-Repudiation, was Re: Common misconceptions, was Re: KISS for PKIX.  (Was: RE:ASN.1vs   XML   (used to be RE: I-D 	ACTION  :draft-ietf-pkix-scvp-00.txt))
References: <v04020a02b3b3e54bc992@[128.33.238.108]> <v04020a00b3b56b6383a7@[128.33.238.45]> <v04020a03b3be21dccc3c@[128.33.238.37]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Stephen Kent wrote:

> I said it was oversimplified because I interpreted your comments as
> indicating that passwords fail to provide a basis for NR because of a lack
> of challenge-response functionality.  Such functionality is not the central
> issue for NR and so I felt that you were confusing two separate topics.

Ok, then we seem to disagree -- since positive challenge-response (not
necessarily cryptographic, of course) is what distinguishes live from dead
data and is IMO a sine qua non condition in legal NR.  However, what you
say can also be NR, though not legal.  In order to preclude further
interpretation problems, let me present a NR model that classifies what I
consider to be the major aspects that any system wishing to provide
non-repudiation at any given level should include, also naming each of a
series of levels and providing for a division between Variables (which I
can't control) and Modifiers (which I can control to some extent):

A. Variables -- involves only "you", where "you" is the one that authenticates

A1. syntatic form (Is the authentication yours?),

A2. semantic form (Did you understand what you were authenticating?),

A3. trust form (Did you yourself willfully authenticate it?),

A4. identification form (Are you the authenticator you claim to be?),

A5. temporal form (When did you authenticate it?),

A6. local form (Where did you authenticate it?),

A7. etc.


B. Modifiers -- involves also "me" (ie, "I", the verifier)

B1. legal form (Can I legally prove it?)

B2. liability form (Can you back and idemnify it to me?)

B3. extent form (What is the temporal and legal extent of the authentication, for you
                         towards me and me towards you?

B4. policy form (Is that allowed by the applicable policies, for you towards me
                         and me towards you?)

B5. etc.

Where I prefer to divide the issues of non-repudiation according to a
state-space where one has a FIRST set of clear variables which I do not
control, but measure:

 Variables: syntatic, semantic, trust, identification, temporal, local, etc.

and a SECOND set of clear modifiers which I can control at least to
some extent:

 Modifiers:  legal, liability, extent, policy, etc.

As needed, one combines the components for a specific
"law/policy non-repudiation system" as a logical function that uses
A1, A2,... and B1, B2, ...  above as functional inputs, but in
each respective classification.

So,  weak authentication (as provided by passwords) fails to
provide values for *ALL* variables when viewed under B.1
since any such value could be replayed at will by the verifier
(for example, or by an attacker) and there is nothing that the
password holder could do to avoid it. Thus, as a legal principle
valid in law theory in general (between power and liability),  since
the password holder has no power to deny weak authentication it
also has no derived liability from it, including non-repudiation.

However, it is possible that some A variables could provide
non-repudiation for passwords when viewed under the B4 modifier,
for example --  such as when an ISP uses A.1 and B.4 in order to
put an user's account on hold when two succesfull logins occur at a
given time (indicating either two persons using the same account or
a password compromise).  But, this is not legal NR -- which is what
we are focusing here.

So, to avoid further confusions whenever I mention NR, I mean legal
NR unless otherwise noted.

> I'm uncomfortable with the phrase "deny NR" and so maybe I don't know what
> your intention is in choosing that phrase.  Simply stated, passwords are
> not sufficient as a basis for NR, while certificates do proivide such a
> basis.  However, certs do not, by themselves, ensure NR.

I would phrase it differently -- simply stated, passwords are not necessary as
a basis for NR, while certificates may be necessary. Further, certificates are
not sufficient as basis for NR.  So, passwords are neither necessary nor sufficient
for NR, while certificates may be necessary but not sufficient.

That is why I wrote that passwords "deny NR" -- because if I exclusively
use a password when authenticating myself to a site, then I am one-sidedly denying
NR capability to that site over my authentication, try as the site may.

OTOH, if I use a certificate then I may be faced with NR *evidences*
against myself which I may find difficult to deny -- so, certificates cannot
deny NR capability (ie, I am at the mercy of the other side will or ineptitude).

> We may disagree here.  there is no technical requirement for a CA to store
> certs in support of NR.

This is a simple confusion -- we were talking about private-key certs and
the cert storage liability that is borne by the *user* (ie, the private-key
holder), not the CA.

But, the same does not occur with passwords, so with certificates the user
must not only be liable for keeping the password but also the private-key
cert itself (otherwise, someone may off-line break its password and then
use it).  This is also in accord with the concept that more security comes at a
"hassle price".

> if the certs used to authentication are not used for NR, by explicit
> marking and CA policy, then theft of private keys associated with certs
> should have no NR implications.

I am usually wary of forecasting judicial decisions. But, suppose we
agree that "explicit marking" is a function of the software that reads it
while CA policy is a function of what you can read at a URL if you
use reasonable reliance and go there and check it.

However, in the majority of US states and in US Federal courts I
am not required by law to use reasonable reliance in order to perform
due diligence -- I may justifiedly rely on what you affirm if  it looks
right without further checking.  Thus, theft or even use of NON-NR
private keys can have NR implications by justified reliance in all cases
so allowed by law already -- for example, if the private-key holder
commits a tort (in the verifier's jurisdiction, which may not be a tort in
the keyholder's jurisdiction).

> I have yet to see a technical basis for distinguishing cert-based
> authentication from cert-based authentication, in terms of liability.

Do you mean password-based vs. cert-based? See the Munden case in the
UK for the former. See the Utah legislation for the later.

> The rationale for the NR bit is to signal the intent of the cert user that
> data signed with the cert is intended as evidence in support of NR, vs.
> authentication, key exchange, etc.

The intent is IMO fine, the problem is calling it a "non-repudiation bit".
But, names are simply names .. perhaps law should change what it calls
non-repudiation ;-)

> I do employ SSL access from hotels, and I am not too concerned about the
> security risk posed by having a private key, encrypted by just a password,
> in my laptop. The reason is that I am fairly careful about physical
> security for my laptop (probably better than my desktop, given occasional
> theft within our facility) and I don't see the TH risk as any greater for
> the laptop than the desktop.  besides, the certs I use in both cases are
> not for NR (a security service that is not provided by SSL due to the layer
> at which SSL operates).

Yes, and the fact that you are "fairly careful about physical security for my
laptop" stems also from your storage of private-key certs in it -- if you would
be satisfied with the security level provided by a password you would not
even need to carry your laptop for that reason or to have anything valuable in
it.  So, your explanation seems to confirm what I was trying to explain -- that
different authentication procedures carry different legal consequences for both
parties (eg, in yourcase, the bad karma of client cert theft) .

> We disagree. Using client certs for SSL user auth is more convenient for me
> as a user, and offers better security than use of a password for
> authentication.  The  security examples you cite are more along the lines
> of access control, rather than authentication.  Once one decides that
> authenication is a requirement (for access control and accountability),
> then one can choose from among different mechanisms with different security
> properties and different user inconveniece levels.

Requirements are usually chosen as a compromise between cost and risk. And,
choosing authentication as a requirement still needs a further analysis between
"weak authentication" (passwords) and "strong authentication" (certificates).
I understand that you tend to use the word authentication in the later sense,
exclusively, but "weak authentication" can be more secure than "strong
authentication" as we all know -- so there is no reason to exclude passwords
from a choice "among different mechanisms with different security properties
and different user inconveniece levels".  And, where passwords will, almost
always, correspond to much lesser inconvenience levels -- and, most importantly,
much lesser liability levels.

> No, it is not clearer. Software is ALWAYS between people and hardware, or
> between people, trying to perform user authentication.  We don't see what
> operations are performed on our behalf, what is transmitted down the wire,
> etc.  What people mean when they use the word "trust" is not the same as
> what you are referring to when you say that software "trusts ... a
> certificate" so the notion of associativity is not applicable here; the
> operators are different.  I don't think your use of symbology helps at all.

Yes, many different people may mean different things by that pesky word "trust"
and that is why I was careful enough to note:

  ... if the User knows that the Software trusts (ie, relies upon for its actions)
  some aspect that the Software can exploit in the Certificate ...

where I consistently use the word ttrust o mean "that which I rely upon for my
decisions" -- which is trust in the subjective sense. I can also use the word "trust"
to mean a "license" or "authorization" as a trusted user in a network, who is a
user authorized to access some services -- but this is using the word "trust" in an
objective sense.

The symbology helps to show that a certificate binds to a system, not to a user --
for many reasons, for example because a certificate can be read by a system
without any intervention *from* a user and because a certificate can be created
by a system without any connection *from* a user. If a certificate would bind to
a user, then one would have (U*S)*C = U*(S*C) because this would be equivalent
to (U*S)*U == U*(S*U) -- and not (U*S)*C <> U*(S*C); where '*' means
"trusts" and the parentheses mean precedence order as usual.

> Trust is almost always the wrong word to use here.  It is not transitive,
> it is not readily quantifiable, it is a human emotion not a characteristic
> of software, hardware, or PKI.  As Tina Turner might have said, "What's
> trust got to do with it?"

Go with Tina Turner then to quantify trust in IETF protocols ;-) If we all
find a need to talk about "trusted systems", "trusted third-parties", "trusted
certificates", "trusted user" then the least we can do is define it in a coherent
way that we can all use. And, this is not so hard if we consult the dictionary,
for example. Yes, sure, trust can be a human emotion -- but this is not all that
trust can be, or is.

The concept of trust in communication systems must have nothing to do with
friendship, acquaintances, employee-employer relationships, loyalty, betrayal
and other overly-variable concepts.  Here, trust is not to be taken  in the
purely subjective sense either,  nor as a feeling or something purely personal or
psychological -- trust is to be understood as something potentially communicable.
Further, if trust must bridge different instances and observers, otherwise
communication would be isolated in domains, then all different subjective and
intersubjective realizations of trust must depend on some common, basic and
abstract idea -- an archetype in some terminologies.  As used in the context of
Generalized Certification Theory [see the relevant URLs, pls.] trust is, simply:

 "trust is that which is essential to a communication channel but which cannot be
 transferred from a source to a destination using that channel".

and from this definition more than 30 different definitions can be *derived*, including
the linguistic meanings and the following:

 "trust is that which an observer has estimated with high-reliance at epoch T,
 about an entity's behavior on matters of x",

> if a cert carries a policy OID, the implication is that a relying party can
> fetch the policy governing cert issuance and make a decision to rely on the
> cert or not, based on that policy.  If the RP does not accept the language,
> jursidiciton, etc. of the policy, then the RP should not accept the cert,
> period.

This is OK as long as it is not the only choice to continue the transaction --
but for which a CA policy does not provide. Of course, one may say, but
the point was that the same does not apply to passwords (as we were
comparing both for "nuisance levels").

> You assert that a user cannot associate a policy with a cert, but I provide
> examples of how to do this. we clearly are not speaking the same language,
> and so it is not clear that we ought to pursue this line of discussion.
> besides, my company works with a number of large CA service providers, as
> well as being one, who believe that they have adequately addressed this
> problem, in practice.  So, I'm willing to go with the opinions of our
> counsel, and the counsels of half a dozen CA services providers in an equal
> number of countries, rather than continue the debate.

Let me carefully re-state what I asserted:

 Of course, the issuer may associate whatever it wants -- but not in
 relationship to a party (eg, the r-p) that is NOT privy to the contract
 and that has other rights from the law regime of its jurisdiction (the
 right to deny an electronic contract being just one of them).

and I am sure your counsels have carefully made such policies exactly so
that users remain not privy to the contract -- thus, they have also denied
a user any power to even demand that the policy be kept unchanged, not
to mention to demand suitability of purpose (which, the CA policies do
not have, for users).   Of course, there are reasons for this and a CA would
be on to a fast-finish without this -- but, again, the point is that passwords
do not include this "hassle".

> Ed Gerck wrote:
> >Take the case of two policies (eg, two different CAs) that have been accepted
> >in separate based on value judgements by a sysadmin.  Suppose these two
> >policies require the user to check any cert with a CRL (eg, as CA policies do)
> >at the respective CA's site before relying on a cert.  However, the user's browser
> >cannot check CRLs (eg, as current browsers do not check).  Now, one of these
> >policies includes insurance coverage against the use of revoked certs when the
> >browser is barred by design to check CRLs.
> >
> >Now, can you tell me where is this meaning accessible to the application?
> >I.e., accesible to the user -- after the sysadmin has acepted the policies? Or,
> >will the browser simply ignore this and readily accept any cert signed by
> >either CA?
> >
> >Of course, the above example can be made with other attributes.  And, that is
> >why I wrote that policy extensions are not infused with meaning, they are
> >simply pointers to a meaning -- which meaning can be  inacessible to the
> >application.
>
> Your model assume a set of constraints that prejudice the outcome.  For
> example, you assert that a sysadmin has "accepted" policies, and imply that
> a user is now bound to rely on certs based on the sysadmin's acceptance of
> these policies.

This is what companies do, perhaps even yours. Or, do you recommend to
a company that their employees can accept any CA policy at will? In the
praxis, what I observe is that some CA policies are acceptable to a company
(perhaps, only two or three) as defined by their security officer or whatever,
while  the others are unacceptable.

> however, the cert validation application cited is unable
> to comply with at least one aspect of a policy, making reliance by the
> user, in the context of that application, unwise.  The technical term here
> is "broken."

No, I differ. The technical term is "non-existent". No application today AFAIK
tests for this -- but this is just one purposeful example of the notion that no
application, ever,  can test for everything, so that there must always be
untestable features of certs and policies. Thus, my example concretely brings
to light one case of what  I described before -- that there may be policy meanings
unacessible to the application, outdated, wrong, etc.  BTW, just look at the
OID list ;-)

> it would be a mistake for the sys admin to accept policies on
> behalf of users if the sysadmin does not know what apps will process certs
> under these policies.

No, the case here is simpler and decidable -- current browsers. All very
well known --  so the sysadmin certainly knows what apps will process certs
under the two CA policies.

>  if acceptance is to be enforced, the sys admin needs
> a way to distribute this info to user apps, but your example (current
> browsers) does not have such a mechanism, so the whole scenario is a bad
> example.

;-) not a bad example, I am afraid, but a good example of a bad case in
regard to your previous argument line. As I wanted it to be, in order to explain
by examples and not only in theory.

Cheers,

Ed Gerck



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 NAA01831 for <[e-mail]>; Fri, 23 Jul 1999 13:52:05 -0700 (PDT)
Received: from [128.33.238.37] (YAKOV.BBN.COM [128.89.0.111]) by po1.bbn.com (8.9.1/8.9.1) with ESMTP id QAA28336; Fri, 23 Jul 1999 16:54:01 -0400 (EDT)
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Message-Id: <v04020a04b3be5213ca84@[128.33.238.37]>
In-Reply-To: <[e-mail]>
References: <v04020a02b3b3e54bc992@[128.33.238.108]> <v04020a00b3b56b6383a7@[128.33.238.45]> <[e-mail]>
Date: Fri, 23 Jul 1999 13:14:39 -0400
To: "Jan Nielsen" <[e-mail]>
From: Stephen Kent <[e-mail]>
Subject: Re: Common misconceptions, was Re: KISS for PKIX. (Was: RE: ASN.1vs   XML   (used to be RE: I-D 	ACTION :draft-ietf-pkix-scvp- 00.txt))
Cc: Ed Gerck <[e-mail]>, "'[e-mail]'" <[e-mail]>

jan,

>I believe a discussion the non-repudiation characteristics of secret key
>versus private/public
>key systems requires more than a discussion of key type.  The
>authentication protocol, the
>specific implementation of that protocol, the characteristics of the core
>cryptographic
>service, and the characteristics of the key management are all more
>important technical
>characteristics w.r.t. non-repudiation than the actual key type.

I agree.  My point to Ed was that his focus on challenge-response protocols
also does not get at the core features for NR.  One can build NR systems
based on secret key use; such designs were presented by Rabin and others in
the early 80s.  Nobody implements them because they place signnificant
communication and security requirements on TTPs that mjust be online for
transactions, instead of allowing most of the process to be effected via
communication only between the communicating parties.  Also, (user)
authentication protocols generally do not support NR, since a primary goal
of NR is to establish the integrity and authenticity of transactions, not
of a user login. I mentioned key marking only because it is standardized in
X.509 certs, for when one wants to declare that the corresponding private
key is to be used for NR.

>> To rephrase, my point was very simple -- passwords strongly deny NR;
>>certificates
>> do no necessarily deny NR and thus certificate authentication can be
>>misused by the
>> verifier in order to provide grounds for NR even when the certificate
>>holder denies it.
>
>This is generally incorrect.  Secure authentication protocols implemented
>by trusted clients
>generally have better key management characteristics than today "PKI
>systems", e.g., browsers,
>and therefore have better non-repudiation characteristics.  Until the key
>management aspect of
>NR is resolved technically (and to the satisfaction of a particular legal
>system), the NR
>characteristics of a system will not be quantifiable; rather, it will be
>in the eye of the
>beholder.

Again, user authentication protocols are not, in general, a basis for NR,
because they fail to link the user, in a technically non-repudiable way, to
subsequent transactions.

Steve


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 NAA01815 for <[e-mail]>; Fri, 23 Jul 1999 13:52:03 -0700 (PDT)
Received: from [128.33.238.37] (YAKOV.BBN.COM [128.89.0.111]) by po1.bbn.com (8.9.1/8.9.1) with ESMTP id QAA28332; Fri, 23 Jul 1999 16:54:00 -0400 (EDT)
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Message-Id: <v04020a03b3be21dccc3c@[128.33.238.37]>
In-Reply-To: <[e-mail]>
References: <v04020a02b3b3e54bc992@[128.33.238.108]> <v04020a00b3b56b6383a7@[128.33.238.45]>
Date: Fri, 23 Jul 1999 13:07:41 -0400
To: Ed Gerck <[e-mail]>
From: Stephen Kent <[e-mail]>
Subject: Re: Common misconceptions, was Re: KISS for PKIX. (Was: RE: ASN.1vs   XML   (used to be RE: I-D 	ACTION :draft-ietf-pkix-scvp- 00.txt))
Cc: "'[e-mail]'" <[e-mail]>

Ed,

>Why would my "characterization of  why passwords don't provide NR" be
>"a bit over simplified" as you say? -- what have I left out, regarding
>passwords?
>
>And, why would this have anything to do with your assertion that
>"challenge-response technologies also don't provide a basis for NR in most
>instances either"?  -- I fail to see why my observation that passwords
>deny NR  (which passwords do strongly deny ) would be made more difficult by
>challenge-response technologies also denying it in most instances.  I see no
>connection -- and certainly none that would make passwords provide NR.

I said it was oversimplified because I interpreted your comments as
indicating that passwords fail to provide a basis for NR because of a lack
of challenge-response functionality.  Such functionality is not the central
issue for NR and so I felt that you were confusing two separate topics.

>To rephrase, my point was very simple -- passwords strongly deny NR;
>certificates
>do no necessarily deny NR and thus certificate authentication can be
>misused by the
>verifier in order to provide grounds for NR even when the certificate
>holder denies it.
>
>This answers your original question, saying that this is absolutely NOT a
>red herring:

I'm uncomfortable with the phrase "deny NR" and so maybe I don't know what
your intention is in choosing that phrase.  Simply stated, passwords are
not sufficient as a basis for NR, while certificates do proivide such a
basis.  However, certs do not, by themselves, ensure NR.

>>>> I agree that these are precieved problems that hinder PKI deployment,
>>>>but I
>>>> also think that many of these are red herrings.  If I use certificates to
>>>> authenticate users, in lieu of passwords, why are there any new legal
>>>> issues?
>
>as yes, indeed, there are new legal issues. One of them is not strongly
>denying NR.
>Another is certificate storage liability.

We may disagree here.  there is no technical requirement for a CA to store
certs in support of NR.  A perfectly valid alternative model is for relying
parties to retain the certs and CRLs needed for NR, appropriately time
stamped by a third party time stamper, to establish the time at which this
evidence was acquired.

<snip>

>
>>  Although the observation about the opportunity for theft is accurate,
>>it seems a bit
>> far afield of this discission.
>
>No, not far afield but is indeed a new legal issue introduced by
>certificates -- as you
>asked for in your question  -- "If I use certificates to authenticate
>users, in lieu of
>passwords, why are there any new legal issues?"

if the certs used to authentication are not used for NR, by explicit
marking and CA policy, then theft of private keys associated with certs
should have no NR implications.

>> >So, this one is not a red herring at all but a red sign of warning. It is
>> >a common misconception, though, to assume that all authentication
>>procedures are
>> >legally equivalent -- but, they simply aren't and for several legal
>>reasons.
>>
>> What you said above does not seem to support this conclusion.
>
>As above, it is 100% supported -- certs introduce at least two new legal
>issues
>that simply do not exist for passwords. This discussion also seems to
>support my
>opinion that it is common to think that all authentication procedures are
>legally
>equivalent, albeit incorrect.

I have yet to see a technical basis for distinguishing cert-based
authentication from cert-based authentication, in terms of liability.
Lacking case law precedent, we'll just have to agree to disagree on the
possibility that there are such differences.

>> >> Part of the problem is that people have been led to believe that a
>> >> PKI must support non-repudiation, which generates a large number of
>>valid,
>> >> legal concerns.
>> >
>> >Part of the problem is that PKIX also has a so-called non-repudiation
>>bit ;-)
>>
>> Yes, and it is used to allow a CA to distinguish between a cert issued for
>> signing data for auth vs. signing data for NR.  What's wrong with that?
>
>Nothing but the fact that it does not provide for non-repudiation, so it
>is IMO
>a misnomer. At most, it could provide for "cooperative non-repudiation" in
>which the signer declares it will not repudiate and then willfully abides
>by such
>declaration as long as it suits its purposes -- but which declaration,
>arguably, could
>be better placed and substantiated  for context in the document itself,
>never in the
>PKIX certificate.

The rationale for the NR bit is to signal the intent of the cert user that
data signed with the cert is intended as evidence in support of NR, vs.
authentication, key exchange, etc.

>
>> >>  However, use of a PKI to support SSL, IPsec, and S/MIME
>> >> (at least on an intranet basis) does not raise such issues, yet
>>promises to
>> >> improve security and to make life easier for users.
>> >
>> >"improve security" and "make life easy for users" seem to be antinomies
>>in all
>> >systems -- security is counter to functionality, as a general principle.
>> >So, I believe that last phrase is an empty promise though it may look
>>good in
>> >marketing materials.
>>
>> One example comes to mind in the context of SSL client certs.  They are
>> much preferable to use vs. remembering different names and passwords for
>> each web site that requires a login, and the security afforded by client
>> certs is much better than passwords, even if the corresponding private keys
>> are stored on my disk.
>
>Take my previous example, but with SSL client certs -- go to a hotel and
>try to
>use it. Either you can't (the SSL client cert is in the desktop machine at
>your
>office) or you have to take it with you... and your laptop also (since
>hotel machines
>cannot be relied either to be compatible or to be free from malicious
>software).
>Thus, you now have added certificate storage liability and laptop theft
>liability.
>Which hassles a password (less secure) does not have.  And, no authentication
>(even less secure) has even less hassle.

I do employ SSL access from hotels, and I am not too concerned about the
security risk posed by having a private key, encrypted by just a password,
in my laptop. The reason is that I am fairly careful about physical
security for my laptop (probably better than my desktop, given occasional
theft within our facility) and I don't see the TH risk as any greater for
the laptop than the desktop.  besides, the certs I use in both cases are
not for NR (a security service that is not provided by SSL due to the layer
at which SSL operates).


>What I am saying is not that passwords are "better" than certificates --
>such comparison
>would be even senseless. But, simply, that adding security implies
>decreasing functionality
>to some extent -- so that to "improve security" and to "make life easy for
>users" seem to
>be antinomies in all current systems.  Further, it is IMO very close to a
>true antinomy
>like "slavery" and "freedom".  A secure system must include some amount of
>hassle to a
>user-- the point is to make it bearable for what it provides, not to deny
>that the hassle
>exists or, even, that it is less.

We disagree. Using client certs for SSL user auth is more convenient for me
as a user, and offers better security than use of a password for
authentication.  The  security examples you cite are more along the lines
of access control, rather than authentication.  Once one decides that
authenication is a requirement (for access control and accountability),
then one can choose from among different mechanisms with different security
properties and different user inconveniece levels.

>So, facing this issue might be a better strategy -- as I commented in
>another reply,
>marketing materials notwithstanding.
>
>> >Another common misconception.
>> >
>> >> I disagree with your statement that a certificate in software binds a
>> >> system, vs. a user.
>> >
>> >I fail to see how you can possibly disagree with Eric's statement.  Trust
>> >is not distributive in the social sense (ie, not associative in the
>>mathematical
>> >sense),..
>> >..
>> >So, you cannot affirm that a cert binds a user -- which user?  At most,
>> >you can affirm that your challenge-response logs, traceroute,
>>timestamps and
>> >whatever may indeed point to a system that  you believe  has
>>authenticated it --
>> >but only as an evidence, not as a fact.
>>
>> I have no idea what are you talking about? The statement I questioned was
>> an assertion that a cert with a privcate key protected via software did not
>> provide a suitabel basis for user, vs. system, authentication.  Your
>> argument above does not seem to bear on that at all.
>
>Your statement was correctly perceived (you replied to Eric: "I disagree
>with your
>statement that a certificate in software binds a system, vs. a user.").
>And, I pointed
>out that, as Eric mentioned, I also have the view that a cert with a
>private key
>protected via software does NOT provide a suitable basis for user, vs. system,
>authentication.  Clearly, if the cert with a private-key is "protected via
>software"
>then breaking such protection only involves breaking the verifier's trust
>on that
>software/system without the verifier knowing it, not the verifier's trust
>on the user.

The comments above are rather vague.  Try to use more technical terms, and
maybe exmaples, to explain your point.

>And, I explained this conclusion by noting that trust on a private-key
>certificate is
>not distributive (ie, not associative in the mathematical sense) to trust
>in the software.
>So, you cannot affirm that a cert in software binds a user -- which user?
>At most,
>you can produce evidence that  the system has authenticated a transaction
>-- but
>since the software (S) is between the certificate (C) and the user (U) ,
>you have:
>
>   (U*S)*C <> U*(S*C)
>
>which means that the User can first trust the Software and then trust the
>Certificate to
>correctly either authenticate or deny authentication according to the
>password transmitted
>from the User by the Software, but if the User knows that the Software
>trusts (ie, relies
>upon for its actions) some aspect that the Software can exploit in the
>Certificate (for
>example, the Certificate always requires the same password) then the User
>may no longer
>trust the Certificate.  I hope it is clearer.

No, it is not clearer. Software is ALWAYS between people and hardware, or
between people, trying to perform user authentication.  We don't see what
operations are performed on our behalf, what is transmitted down the wire,
etc.  What people mean when they use the word "trust" is not the same as
what you are referring to when you say that software "trusts ... a
certificate" so the notion of associativity is not applicable here; the
operators are different.  I don't think your use of symbology helps at all.

>> >> Yes, smart cards are preferable, but if the choice is
>> >> between a password and a certificate (and private key) with software
>> >> cryptography, I see no reason not to adopt the latter,
>> >
>> >One reason is to deny unwanted non-repudiation.  Another is to reduce
>> >cert storage liability. Etc.
>>
>> I was talking about certs used for auth, not NR, making the comparison to
>> passwords meaningful.
>
>I understood you were talking about choices. To be clear -- if the choice
>is between
>a password and a certificate (and private key) with software cryptography,
>then I
>see several reasons NOT to adopt the latter; unwanted NR and cert storage
>liability
>being just two examples.

You continue to assert these as problems, but I don't accept the assertion.

>> >> and I certainly see
>> >> no reason to declare that the latter is not a user (vs. system)
>> >> authentication mechanism.
>> >
>> >as above, trust is not distributive (socially).
>>
>> Again, your argument seems orthogonal to the issue I was addressing.
>
>Perhaps, it is clearer now -- see above. Because trust is not distributive,
>there are several reasons to declare that the latter is not a user (vs.
>system)
>authentication mechanism.

Trust is almost always the wrong word to use here.  It is not transitive,
it is not readily quantifiable, it is a human emotion not a characteristic
of software, hardware, or PKI.  As Tina Turner might have said, "What's
trust got to do with it?"

>> >> Finally, why do you say that an issuer cann[ot]
>> >> associate a security policy with a certificate?  We have the syntactic
>> >> means to do so as part of the standard.
>> >
>> >In which language? In which legal system? In which jurisdiction?
>> >Syntax does not answer these (and other) questions at all -- and yet,
>> >any of them makes the problem overly-variable in comparison to the
>> >given syntax.  All security policies (eg, CPS) need to call themselves
>> >"mutually exclusive" (otherwise I could just devise a security policy that
>> >would render yours ineffective) and yet they can all be different since
>> >security policies per se are not defined as part of the standard, just
>> >referred in the standard as we all know.
>>
>> Hard copy contracts specify the language and jursidiction of
>> interpretation, and cert policies can do the same.
>
>But, the relying-parties are NOT privy to the contract between a CA
>and a subscriber.  So, r-ps may completely disagree with the language,
>the legal system and the jurisdiction for the contract's interpretation --
>and yet,
>this has no bearing either on the CA or on the subscriber.

if a cert carries a policy OID, the implication is that a relying party can
fetch the policy governing cert issuance and make a decision to rely on the
cert or not, based on that policy.  If the RP does not accept the language,
jursidiciton, etc. of the policy, then the RP should not accept the cert,
period.

>> The fact that the policy is incorporated by use of an OID does not
>>affect this.
>> Again, I fail to see the point of your comments.
>
>The point is that (answering your question above, to Eric, "why do you say
>that an issuer
>cann[ot] associate a security policy with a certificate? "),  an issuer
>cannot strongly
>associate a security policy with a certificate and such association must
>be overly-
>variable in several aspects because such association would have to be valid
>in first line to r-ps -- who are not privy to the contract between the
>issuer and the
>subscriber.
>
>Of course, the issuer may associate whatever it wants -- but not in
>relationship to
>a party (eg, the r-p) that is NOT privy to the contract and that has other
>rights from
>the law regime of its jurisdiction (the right to deny an electronic
>contract being
>just one of them).

You assert that a user cannot associate a policy with a cert, but I provide
examples of how to do this. we clearly are not speaking the same language,
and so it is not clear that we ought to pursue this line of discussion.
besides, my company works with a number of large CA service providers, as
well as being one, who believe that they have adequately addressed this
problem, in practice.  So, I'm willing to go with the opinions of our
counsel, and the counsels of half a dozen CA services providers in an equal
number of countries, rather than continue the debate.

>> >> Do you mean that we don't have
>> >> appplications that pay attention to the policy extension?
>> >
>> >Policy extensions are not infused with meaning, they are simply pointers
>> >to a meaning -- which meaning can be  inacessible to the application,
>> >outdated, invalid in that jurisdiction, etc.
>>
>> But one configures an application to accept of rejects certs based on
>> policy IDs, based on a human being having read the policy and made a value
>> judgement.  We dopn't expect applications to make these decisions, but
>> rather to enforce the decisions already made by users or system
>> administrators.
>
>Take the case of two policies (eg, two different CAs) that have been accepted
>in separate based on value judgements by a sysadmin.  Suppose these two
>policies
>require the user to check any cert with a CRL (eg, as CA policies do) at the
>respective CA's site before relying on a cert.  However, the user's browser
>cannot check CRLs (eg, as current browsers do not check).  Now, one of these
>policies includes insurance coverage against the use of revoked certs when the
>browser is barred by design to check CRLs.
>
>Now, can you tell me where is this meaning accessible to the application?
>I.e.,
>accesible to the user -- after the sysadmin has acepted the policies? Or, will
>the browser simply ignore this and readily accept any cert signed by
>either CA?
>
>Of course, the above example can be made with other attributes.  And, that is
>why I wrote that policy extensions are not infused with meaning, they are
>simply
>pointers to a meaning -- which meaning can be  inacessible to the application.

Your model assume a set of constraints that prejudice the outcome.  For
example, you assert that a sysadmin has "accepted" policies, and imply that
a user is now bound to rely on certs based on the sysadmin's acceptance of
these policies.  however, the cert validation application cited is unable
to comply with at least one aspect of a policy, making reliance by the
user, in the context of that application, unwise.  The technical term here
is "broken."  it would be a mistake for the sys admin to accept policies on
behalf of users if the sysadmin does not know what apps will process certs
under these policies.  if acceptance is to be enforced, the sys admin needs
a way to distribute this info to user apps, but your example (current
browsers) does not have such a mechanism, so the whole scenario is a bad
example.

Steve


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 NAA01395 for <[e-mail]>; Fri, 23 Jul 1999 13:36:45 -0700 (PDT)
Received: from nma.com (pm04-12.sac.verio.net [209.162.64.125]) by tomcat.sac.verio.net (8.9.1a/8.9.1) with ESMTP id NAA10202 for <[e-mail]>; Fri, 23 Jul 1999 13:38:43 -0700 (PDT)
Message-ID: <[e-mail]>
Date: Fri, 23 Jul 1999 13:38:29 -0700
From: Ed Gerck <[e-mail]>
X-Mailer: Mozilla 4.51 [en] (Win98; I)
X-Accept-Language: en
MIME-Version: 1.0
CC: "'[e-mail]'" <[e-mail]>
Subject: Design criteria, was Re: Common misconceptions, was Re: KISS for PKIX.  (Was: RE: ASN.1vs XML (used to be RE: I-D 	ACTION :draft-ietf-pkix-scvp-  00.txt))
References: <[e-mail]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

[e-mail] wrote:

> Ed Gerck <[e-mail]> on 07/22/99 02:45:21 PM wrote:
>
> What I am saying is not that passwords are "better" than certificates -- such
> comparison would be even senseless. But, simply, that adding security implies decreasing
> functionality to some extent -- so that to "improve security" and to "make life easy for
> users" seem to be antinomies in all current systems.  Further, it is IMO very close to a true
> antinomy like "slavery" and "freedom".  A secure system must include some amount of
> hassle to a user-- the point is to make it bearable for what it provides, not to deny that
> the hassle exists or, even, that it is less.
>
> [Tom Gindin]   Security and usability are not close to being an antinomy.  They
> are competing goods, and they are subject to a set of trade-offs.  It is true
> that for an optimally designed product one probably can't improve one of them
> without worsening the other, a condition like Pareto optimality in economics.
> However, not every product is on this optimal trade-off frontier, and the
> frontier moves outward over time.  I hope that this WG is doing some things to
> move it outward.

Your vision is IMO sufficiently close to mine for the purposes at hand in this WG. Further,
our visions do not seem to be antinomies themselves ;-) so we can talk about a common
ground, can't we?

Perhaps, the common ground in both visions is to realize the following:

1. More security is not necessarily beneficial to the user.
2. More security will, more often than not, be a hassle for the user; or
2'. Any amount of security will tend to make life harder for users.
3. The purpose of a security protocol is to make security tolerable to users in regard to what it delivers.

What we may still disagree on (but perhaps, just as a matter of degree) is in the fourth item:

4. "Security" and "easier life for users" are simply opposites.

Now, rather than use the "Pareto model" (and its faults), when I want to be more precise I
use in this case the mathematical concept of "conjugate variables" and say that the product
(1/S) .(1/F) > = K describes the relationship between S = "security" and F = "functionality"
in relationship to a constant K>0  valid for a system (of course, in average terms), such that
any increase in S above the limit of S <= (1/F.K) *within that  system* (i.e., for a given K)
must imply a decrease in F, and vice versa .  Moreover, I have reasons to believe that K
is very large in most systems we have today -- so that any amount of S strongly decreases F.

One criteria of "best design" in this formalism is attained when S = F (i.e., when  security and
functionality jointly have their maximum values) -- and which I call a "compact design".
Working with compact designs, one can easily see that decreasing K (with a new system)
directly results in improving *both* security and functionality -- and, is the only  way to do
so above the limit of S <= (1/F.K). The "moving  frontier" you describe is simply given by
decreasing K to K' -- as the system improves to a  new system, but where, likewise, the
"law" (1/S) .(1/ F) > = K' will still hold.

In order to achieve qualitative reductions in K, the design criteria for a new system should be
one (pls. see the relevant URLs) where the concept of Internet security needs to evolve
from "confinement" to "understanding" --  i.e., where security is a mode of understanding and
confinement is but a tool to security.  Indeed, confinement can be useful -- and that is why I
call it a "tool to security" in a design.  "Chinese wall", or "Maginot line" policies are all useful
tools, but if they become the  goal of security then it becomes quite easy to circumvent them
as their historical counterparts showed.  Current fire-walls are also useful, but reliance on
them has actually brought to the front the need for intrusion detection tools -- which is much
more in line with "understanding" than with "confinement".

Because I perceive K to be very large in current systems, I perceive that security and
functionality are close antinomies in current designs -- however, if K would be reduced
then security and functionality would no longer be close antinomies. Let me exemplify.  I
have applied the same mathematical concept here and elsewhere before, for example to
describe the relationship between security (S) and privacy (P) --  which I also consider to
be conjugate  variables,  but such that (1/S) .(1/P) >= Q where Q << K, as I can perceive
in the systems we currently have.  Thus, security is (currently) much closer to be an antinomy
 to functionality than to be an antinomy to privacy, since Q << K.

That is why, today and IMO, "security" and "easier life for users" are simply opposites. Of
course, as a generalization -- but which seems to be very well reflected in actual systems. And,
perhaps this is the main (though largely unspoken by both sides) reason why users say that
"security is not for me yet" (when they reject the hassle) while providers switch into marketing
modes and talk about "non-repudiation" or even "true non-repudiation" (when they try to
overvalue the hassle).  In this regard, my suggestion was that it is better to face the problem,
straight. "Security" and "easier  life for users" are simply opposites, to a large extent. Thus, let's
design methods with this in mind -- and, yes, try to decrease K.

BTW, I found much resonance for these ideas in my talk two weeks ago at the Black Hat
Briefings in LV (slides available), including in talks by other speakers (contact the site).
Bruce Schneier was especially keen on what he described as security being "orthogonal"
to functionality, meaning that just because a security product functions properly does not
mean that it is secure (in my words, the difference between correct and effective); mentioning
also that users do not have the training to follow a "secure" procedure instead of  just choosing
a procedure that works (i.e., users tend to favor functionality over security).  Of course, from
the viewpoint of conjugate variables, security is not orthogonal to functionality and that is why
maximizing one tends to minimize the other -- but both views are just paradoxical terminologies
to describe the same thing, that security and functionality are independent though interrelated
variables.

(BTW, this is nothing out of the ordinary and there are many examples where two variables
are independent but interrelated, as first observed by Fourier in regard to frequency spread
versus time spread for a signal. And, by Heisenberg.)

Cheers,

Ed Gerck



Received: from drawbridge.ascend.com (drawbridge.ascend.com [198.4.92.1]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id LAA29410 for <[e-mail]>; Fri, 23 Jul 1999 11:16:18 -0700 (PDT)
Received: from fw-ext.ascend.com (fw-ext [198.4.92.5]) by drawbridge.ascend.com (8.9.1a/8.9.1) with SMTP id LAA23996 for <[e-mail]>; Fri, 23 Jul 1999 11:11:42 -0700 (PDT)
Received: from russet.ascend.com by fw-ext.ascend.com via smtpd (for drawbridge.ascend.com [198.4.92.1]) with SMTP; 23 Jul 1999 18:16:03 UT
Received: from porky (porky.ascend.com [192.207.23.83]) by russet.ascend.com (8.9.1a/8.9.1) with ESMTP id LAA11728 for <[e-mail]>; Fri, 23 Jul 1999 11:16:02 -0700 (PDT)
Received: from ascend.com by ascend.com
Reply-To: <[e-mail]>
From: "Kirby Russell" <[e-mail]>
To: <[e-mail]>
Date: Fri, 23 Jul 1999 11:15:20 -0700
Message-ID: <[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset="Windows-1252"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2212 (4.71.2419.0)
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.0810.800

unsubscribe


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 KAA29006 for <[e-mail]>; Fri, 23 Jul 1999 10:52:43 -0700 (PDT)
Received: from nma.com (pm02-14.sac.verio.net [209.162.64.33]) by tomcat.sac.verio.net (8.9.1a/8.9.1) with ESMTP id KAA02356 for <[e-mail]>; Fri, 23 Jul 1999 10:54:35 -0700 (PDT)
Message-ID: <[e-mail]>
Date: Fri, 23 Jul 1999 10:54:21 -0700
From: Ed Gerck <[e-mail]>
X-Mailer: Mozilla 4.51 [en] (Win98; I)
X-Accept-Language: en
MIME-Version: 1.0
CC: "'[e-mail]'" <[e-mail]>
Subject: Re: Common misconceptions, was Re: KISS for PKIX. (Was: RE: ASN.1vs  XML   (used to be RE: I-D 	ACTION :draft-ietf-pkix-scvp- 00.txt))
References: <v04020a02b3b3e54bc992@[128.33.238.108]> <v04020a00b3b56b6383a7@[128.33.238.45]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Jan Nielsen wrote:

> Hi Ed,
>
> > which may explain your off-the-point remark.
>
> No...I simply skimmed the thread instead of r-e-a-d-i-n-g it.  Sorry about that.

;-) short postings cannot reflect content, long postings tend to be unread and thus also
not reflect content -- but, at least, content is there.

> My comments were actually addressing the non-repudiation of a user's actions, not digital
> signatures, in systems which rely on SSL client authentication for user authentication as opposed to
> password authentication.  My point is simply that because of poor key management facilities on the
> client and poor physical security of the device that repudiation of the user authentication is more
> likely with SSL client authentication than with a password system.

Perhaps you still skimmed the thread too much. A password system such as what is called
"weak authentication" in X.509 is not able to provide NR at all, as I wrote before:

} ...basically, the reason is that  passwords have no challenge-response mechanism.
} Since a password can be replayed at will, the authenticating party (ie, the verifier)
} is barred from presenting an argument of non-repudiation when passwords are used
} because the verifier could have generated any message all by itself -- the data is
} intrinsically corrupted.

So, any client authentication SSL system can provide more *evidences* (and I can't
overstress the importance of this word here) of NR than any weak authentication
(ie, password) system is ever capable of -- in other words, any NR evidence is more
than zilch ;-)

Cheers,

Ed Gerck



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 FAA25000 for <[e-mail]>; Fri, 23 Jul 1999 05:03:39 -0700 (PDT)
Received: 	id IAA15689; Fri, 23 Jul 1999 08:00:17 -0400
Received: by gateway id <NP65H210>; Fri, 23 Jul 1999 08:02:56 -0400
Message-ID: <[e-mail]>
From: Sharon Boeyen <[e-mail]>
To: "'[e-mail]'" <[e-mail]>, "'Santosh Chokhani'" <[e-mail]>, "'Sean Turner'" <[e-mail]>, "'PKIX'" <[e-mail]>
Cc: "'Steve Kent'" <[e-mail]>, "'Warwick Ford'" <[e-mail]>, "'Hoyt Kesterson'" <[e-mail]>
Subject: RE:Pointer to X.509 FPDAM and defect report documents
Date: Fri, 23 Jul 1999 08:02:54 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2448.0)
Content-Type: text/plain; charset="iso-8859-1"

Here is the pointer to the FPDAM. You'll only find approved and published
documents on 
the ITU site. This one is currently out for ISO ballot and still under ITU
study. The 
Annex M Santosh refers to is in this document. 

Hoyt Kesterson was planning to send a message to the PKIX list alerting to
the fact that
the FPDAM is under ballot, hoping that PKIX review will result in an IETF
ballot response 
containing a consolidated set of comments on the FPDAM. Hoyt is on vacation
and has also 
had some computer hardware problems, so I'm not sure if he sent the message
or not.

Here's the reference to the FPDAM text:

ftp://ftp.bull.com/pub/OSIdirectory/documentsForBallot/CertExtFPDAM.doc

Also here is a pointer to the outstanding defect reports against X.509:
ftp://ftp.bull.com/pub/OSIdirectory/DefectResolution/DefectReports/X.509/

and to the resolutions for those defects, also currently (I believe) out for
ballot
ftp://ftp.bull.com/pub/OSIdirectory/DefectResolution/DraftTechnicalCorrigend
a/X.509/

I haven't checked each defect document to make sure they're all there, but I
believe they are.

An IETF PKIX response to the DTC ballots can also be submitted.

Sharon 

-----Original Message-----
From: Khaja E. Ahmed [mailto:[e-mail]]
Sent: Thursday, July 22, 1999 7:55 PM
To: 'Santosh Chokhani'; 'Sean Turner'; 'PKIX'
Subject: RE: CRL Checking Text


Santosh,

The only X.509 recommendation I am able to find on the ITU web site is the
08/97 version which does not have Annex M.  Can you send the Annex or the
pointer to this group so we can review it.  Thanks.

Khaja


-----Original Message-----
From: Santosh Chokhani [mailto:[e-mail]]
Sent: Thursday, July 22, 1999 2:56 PM
To: 'Sean Turner'; PKIX
Subject: RE: CRL Checking Text


We have done detailed work on this topic and Annex M of the latest X.509
FPDAM has the pertinent language/rules.  I think PKIX should start with
Annex M and revise it if and only if necessary.

> -----Original Message-----
> From:	Sean Turner [SMTP:[e-mail]]
> Sent:	Thursday, July 22, 1999 5:45 PM
> To:	PKIX
> Subject:	CRL Checking Text
>
> All,
>
> I asked a few weeks ago where the explicit requirements were to
> check/verify CRLs in RFC 2459.  The is some text in section 6.1 that
> says:
>
>          Verify ... the certificate had not been revoked at time T and
> is not
>          currently on hold status that commenced before time T, (this
>          may be determined by obtaining the appropriate CRL or status
>          information, or by out-of-band mechanisms),
>
> I think we need a little more information that explicitly states what
> the verification steps are for CRLs.  Attached is some suggested text:
>
> Prior to trusting an issuer's CRL, the signature across the CRL must
> itself be validated.  When required to validate a CRL during
> certificate
> path verification, CRL verification requires the following checks:
>
> 1. Verify the signature on the CRL, distribution point CRL, or delta
> CRL
> by employing the public key from the CRL issuer's certificate. If the
> signature across the CRL is invalid, the user shall be notified that
> the
> signature was invalid and instructed to obtain a new CRL from the
> repository. If a valid CRL cannot be obtained, then the user will be
> given the option to proceed without a valid CRL and without using the
> invalid CRL.
>
> 2. Verify the certification path (see clause 6 of RFC2459) of the CRL
> issuer's signature certificate.
>
> 3. Verify that the present time, T, falls between thisUpdate and
> nextUpdate.  If time T is later than the nextUpdate value, the user
> shall receive guidance to obtain a later CRL from the repository, and
> be
> given the option to proceed with the out-of-date CRL (signature must
> still be checked).
>
> 4. Verify that the cRLNumber is greater than that of the last CRL that
> the user possesses.
>
> 5. Verify that the name in the CRL's issuer field or the
> certificateIssuer extension is the issuer of the certificate.
>
> 6. If the keyUsage extension is present in the CRL issuer's
> certificate
> and is flagged critical, verify that the cRLSign bit is set to 1.
>
> 7. Check whether the certificate's serialNumber appears on the CRL,
> distribution point CRL, or delta CRL.  If the certificate's serial
> number is present, and if no reasonCode exists, or a reasonCode exists
> and is either unspecified, affiliationChanged, superseded, or
> cessationOfOperation, notify the user of which certificate is on the
> CRL, distribution point CRL, or delta CRL and allow the option to
> proceed with data processing.  If the reasonCode is keyCompromise or
> certificateHold, the user shall be notified and the certificate shall
> be
> rejected thereby halting all associated processing.  If a certificate
> that appears on the CRL, distribution point CRL, or delta CRL is a CA
> certificate, regardless of the reasonCode, the user shall be notified
> and the certificate shall be rejected thereby halting all associated
> processing.  If the revoked certificate is the user's certificate, the
> user will be directed to notify the associated CA.
>
> The notification returned to the user at the end of the CRL check
> shall
> at a minimum shall:
>
> - List all expired certificates in the certificate chain.
>
> - Explicitly state that the certificate(s) is/are expired.
>
> - Explicitly state that the certificate(s) may have been revoked, and
> that the certificate will not appear on current CRLs even if the
> certificate has been revoked.
>
> - Explicitly state that the signature applied to the entity being
> verified may not be valid. Verification of signatures using expired
> certificates requires the assistance of the originator's CA.
>
> - Require positive user action to acknowledge the warning message
> (i.e.
> clicking an on-screen OK button) before data processing
> continues.
>
> Thoughts?  Too restrictive or not enough info?
>
> spt



Received: from mail.campuspipeline.com ([209.160.196.105]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id XAA11752 for <[e-mail]>; Thu, 22 Jul 1999 23:07:08 -0700 (PDT)
Received: from campuspipeline.com ([209.160.196.100]) by mail.campuspipeline.com (Netscape Messaging Server 3.54) with ESMTP id 326 for <[e-mail]>; Fri, 23 Jul 1999 00:12:26 -0600
Message-ID: <[e-mail]>
Date: Fri, 23 Jul 1999 00:09:08 -0600
From: "Jan Nielsen" <[e-mail]>
Organization: Campus Pipeline, Inc.
X-Mailer: Mozilla 4.5 [en] (WinNT; U)
X-Accept-Language: en
MIME-Version: 1.0
CC: "'[e-mail]'" <[e-mail]>
Subject: Re: Common misconceptions, was Re: KISS for PKIX. (Was: RE: ASN.1vs  XML   (used to be RE: I-D 	ACTION :draft-ietf-pkix-scvp- 00.txt))
References: <v04020a02b3b3e54bc992@[128.33.238.108]> <v04020a00b3b56b6383a7@[128.33.238.45]> <[e-mail]> <[e-mail]> <[e-mail]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Hi Ed,


> which may explain your off-the-point remark.

No...I simply skimmed the thread instead of r-e-a-d-i-n-g it.  Sorry about that.

My comments were actually addressing the non-repudiation of a user's actions, not digital
signatures, in systems which rely on SSL client authentication for user authentication as opposed to
password authentication.  My point is simply that because of poor key management facilities on the
client and poor physical security of the device that repudiation of the user authentication is more
likely with SSL client authentication than with a password system.


Regards,

jsn

--
Jan Nielsen
Campus Pipeline, Inc.
--------------------------------------
[e-mail]
801.485.6000 x155 (voice)
801.485.6606      (facimile)
http://www.campuspipeline.com
--------------------------------------




Received: from e1.ny.us.ibm.com (e2.ny.us.ibm.com [32.97.182.102]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id VAA07684 for <[e-mail]>; Thu, 22 Jul 1999 21:08:30 -0700 (PDT)
From: [e-mail]
Received: from northrelay02.pok.ibm.com (northrelay02.pok.ibm.com [9.117.200.22]) by e1.ny.us.ibm.com (8.9.3/8.9.3) with ESMTP id AAA134900; Fri, 23 Jul 1999 00:10:05 -0400
Received: from D51MTA05.pok.ibm.com (d51mta05.pok.ibm.com [9.117.200.33]) by northrelay02.pok.ibm.com (8.8.8m2/NCO v2.04) with SMTP id AAA266392; Fri, 23 Jul 1999 00:10:18 -0400
Received: by D51MTA05.pok.ibm.com(Lotus SMTP MTA v4.6.4  (830.2 3-23-1999))  id 852567B7.00152A04 ; Thu, 22 Jul 1999 23:51:10 -0400
X-Lotus-FromDomain: IBMUS
To: Ed Gerck <[e-mail]>
cc: Stephen Kent <[e-mail]>, "'[e-mail]'" <[e-mail]>
Message-ID: <[e-mail]>
Date: Thu, 22 Jul 1999 23:49:56 -0400
Subject: Re: Common misconceptions, was Re: KISS for PKIX. (Was: RE: ASN .1vs XML (used to be RE: I-D 	ACTION :draft-ietf-pkix-scvp- 00.txt ))
Mime-Version: 1.0
Content-type: text/plain; charset=us-ascii
Content-Disposition: inline

Ed Gerck <[e-mail]> on 07/22/99 02:45:21 PM

To:   Stephen Kent <[e-mail]>
cc:   "'[e-mail]'" <[e-mail]>
Subject:  Re: Common misconceptions, was Re: KISS for PKIX. (Was: RE: ASN.1vs
      XML   (used to be RE: I-D    ACTION :draft-ietf-pkix-scvp- 00.txt))

Ed Gerck wrote:
(snip)

No, not far afield but is indeed a new legal issue introduced by certificates --
as you
asked for in your question  -- "If I use certificates to authenticate users, in
lieu of
passwords, why are there any new legal issues?"

> >So, this one is not a red herring at all but a red sign of warning. It is
> >a common misconception, though, to assume that all authentication procedures
are
> >legally equivalent -- but, they simply aren't and for several legal reasons.
>
> What you said above does not seem to support this conclusion.

As above, it is 100% supported -- certs introduce at least two new legal issues
that simply do not exist for passwords. This discussion also seems to support my
opinion that it is common to think that all authentication procedures are
legally
equivalent, albeit incorrect.

> >> Part of the problem is that people have been led to believe that a
> >> PKI must support non-repudiation, which generates a large number of valid,
> >> legal concerns.
> >
> >Part of the problem is that PKIX also has a so-called non-repudiation bit ;-)
>
> Yes, and it is used to allow a CA to distinguish between a cert issued for
> signing data for auth vs. signing data for NR.  What's wrong with that?

Nothing but the fact that it does not provide for non-repudiation, so it is IMO
a misnomer. At most, it could provide for "cooperative non-repudiation" in
which the signer declares it will not repudiate and then willfully abides by
such
declaration as long as it suits its purposes -- but which declaration, arguably,
could
be better placed and substantiated  for context in the document itself, never in
the
PKIX certificate.

[Tom Gindin]   A court could, and might well, take notice of the presence of the
non-repudiation bit in a certificate to help determine whether an attempt to
repudiate an electronically signed contract (especially one for which a
consideration was received) could succeed.  Of course, there are no real
guarantees on what a court will do with hardly any precedent or legislation.

> >>  However, use of a PKI to support SSL, IPsec, and S/MIME
> >> (at least on an intranet basis) does not raise such issues, yet promises to
> >> improve security and to make life easier for users.
> >
> >"improve security" and "make life easy for users" seem to be antinomies in
all
> >systems -- security is counter to functionality, as a general principle.
> >So, I believe that last phrase is an empty promise though it may look good in
> >marketing materials.
>
> One example comes to mind in the context of SSL client certs.  They are
> much preferable to use vs. remembering different names and passwords for
> each web site that requires a login, and the security afforded by client
> certs is much better than passwords, even if the corresponding private keys
> are stored on my disk.

Take my previous example, but with SSL client certs -- go to a hotel and try to
use it. Either you can't (the SSL client cert is in the desktop machine at your
office) or you have to take it with you... and your laptop also (since hotel
machines
cannot be relied either to be compatible or to be free from malicious software).
Thus, you now have added certificate storage liability and laptop theft
liability.
Which hassles a password (less secure) does not have.  And, no authentication
(even less secure) has even less hassle.

What I am saying is not that passwords are "better" than certificates -- such
comparison
would be even senseless. But, simply, that adding security implies decreasing
functionality
to some extent -- so that to "improve security" and to "make life easy for
users" seem to
be antinomies in all current systems.  Further, it is IMO very close to a true
antinomy
like "slavery" and "freedom".  A secure system must include some amount of
hassle to a
user-- the point is to make it bearable for what it provides, not to deny that
the hassle
exists or, even, that it is less.

[Tom Gindin]   Security and usability are not close to being an antinomy.  They
are competing goods, and they are subject to a set of trade-offs.  It is true
that for an optimally designed product one probably can't improve one of them
without worsening the other, a condition like Pareto optimality in economics.
However, not every product is on this optimal trade-off frontier, and the
frontier moves outward over time.  I hope that this WG is doing some things to
move it outward.

So, facing this issue might be a better strategy -- as I commented in another
reply,
marketing materials notwithstanding.

> >Another common misconception.
> >
> >> I disagree with your statement that a certificate in software binds a
> >> system, vs. a user.
> >
> >I fail to see how you can possibly disagree with Eric's statement.  Trust
> >is not distributive in the social sense (ie, not associative in the
mathematical
> >sense),..
> >..
> >So, you cannot affirm that a cert binds a user -- which user?  At most,
> >you can affirm that your challenge-response logs, traceroute, timestamps and
> >whatever may indeed point to a system that  you believe  has authenticated it
--
> >but only as an evidence, not as a fact.
>
> I have no idea what are you talking about? The statement I questioned was
> an assertion that a cert with a privcate key protected via software did not
> provide a suitabel basis for user, vs. system, authentication.  Your
> argument above does not seem to bear on that at all.

Your statement was correctly perceived (you replied to Eric: "I disagree with
your
statement that a certificate in software binds a system, vs. a user.").  And, I
pointed
out that, as Eric mentioned, I also have the view that a cert with a private key
protected via software does NOT provide a suitable basis for user, vs. system,
authentication.  Clearly, if the cert with a private-key is "protected via
software"
then breaking such protection only involves breaking the verifier's trust on
that
software/system without the verifier knowing it, not the verifier's trust on the
user.

And, I explained this conclusion by noting that trust on a private-key
certificate is
not distributive (ie, not associative in the mathematical sense) to trust in the
software.
So, you cannot affirm that a cert in software binds a user -- which user?  At
most,
you can produce evidence that  the system has authenticated a transaction -- but
since the software (S) is between the certificate (C) and the user (U) ,  you
have:

   (U*S)*C <> U*(S*C)

which means that the User can first trust the Software and then trust the
Certificate to
correctly either authenticate or deny authentication according to the password
transmitted
from the User by the Software, but if the User knows that the Software trusts
(ie, relies
upon for its actions) some aspect that the Software can exploit in the
Certificate (for
example, the Certificate always requires the same password) then the User may no
longer
trust the Certificate.  I hope it is clearer.

> >> Yes, smart cards are preferable, but if the choice is
> >> between a password and a certificate (and private key) with software
> >> cryptography, I see no reason not to adopt the latter,
> >
> >One reason is to deny unwanted non-repudiation.  Another is to reduce
> >cert storage liability. Etc.
>
> I was talking about certs used for auth, not NR, making the comparison to
> passwords meaningful.

I understood you were talking about choices. To be clear -- if the choice is
between
a password and a certificate (and private key) with software cryptography, then
I
see several reasons NOT to adopt the latter; unwanted NR and cert storage
liability
being just two examples.

> >> and I certainly see
> >> no reason to declare that the latter is not a user (vs. system)
> >> authentication mechanism.
> >
> >as above, trust is not distributive (socially).
>
> Again, your argument seems orthogonal to the issue I was addressing.

Perhaps, it is clearer now -- see above. Because trust is not distributive,
there are several reasons to declare that the latter is not a user (vs. system)
authentication mechanism.

> >> Finally, why do you say that an issuer cann[ot]
> >> associate a security policy with a certificate?  We have the syntactic
> >> means to do so as part of the standard.
> >
> >In which language? In which legal system? In which jurisdiction?
> >Syntax does not answer these (and other) questions at all -- and yet,
> >any of them makes the problem overly-variable in comparison to the
> >given syntax.  All security policies (eg, CPS) need to call themselves
> >"mutually exclusive" (otherwise I could just devise a security policy that
> >would render yours ineffective) and yet they can all be different since
> >security policies per se are not defined as part of the standard, just
> >referred in the standard as we all know.
>
> Hard copy contracts specify the language and jursidiction of
> interpretation, and cert policies can do the same.

But, the relying-parties are NOT privy to the contract between a CA
and a subscriber.  So, r-ps may completely disagree with the language,
the legal system and the jurisdiction for the contract's interpretation -- and
yet,
this has no bearing either on the CA or on the subscriber.

[Tom Gindin]   While the relying parties are not a party to the contract between
a CA and its subscriber (and perhaps not even privy to it), the CA's Certificate
Policy Statement is public and a relying party might some day be able to use it
in deciding whether to rely on a certificate.  Greater standardization in the
language would be a great help, of course.  The CA-subscriber contract, as
opposed to the CPS, ought to have no effect on the RP's rights.


> The fact that the policy is incorporated by use of an OID does not affect
this.
> Again, I fail to see the point of your comments.

The point is that (answering your question above, to Eric, "why do you say that
an issuer
cann[ot] associate a security policy with a certificate? "),  an issuer cannot
strongly
associate a security policy with a certificate and such association must be
overly-
variable in several aspects because such association would have to be valid
in first line to r-ps -- who are not privy to the contract between the issuer
and the
subscriber.

Of course, the issuer may associate whatever it wants -- but not in relationship
to
a party (eg, the r-p) that is NOT privy to the contract and that has other
rights from
the law regime of its jurisdiction (the right to deny an electronic contract
being
just one of them).

[Tom Gindin]   The relying party is not privy to that contract, but it has been
notified of the CPS - which gives the CPS similar legal standing to a
disclaimer, although probably less such standing because it isn't usually read
by a human.  Many jurisdictions limit the scope of disclaimers, too.

> >> Do you mean that we don't have
> >> appplications that pay attention to the policy extension?
> >
> >Policy extensions are not infused with meaning, they are simply pointers
> >to a meaning -- which meaning can be  inacessible to the application,
> >outdated, invalid in that jurisdiction, etc.
>
> But one configures an application to accept of rejects certs based on
> policy IDs, based on a human being having read the policy and made a value
> judgement.  We dopn't expect applications to make these decisions, but
> rather to enforce the decisions already made by users or system
> administrators.

Take the case of two policies (eg, two different CAs) that have been accepted
in separate based on value judgements by a sysadmin.  Suppose these two policies
require the user to check any cert with a CRL (eg, as CA policies do) at the
respective CA's site before relying on a cert.  However, the user's browser
cannot check CRLs (eg, as current browsers do not check).  Now, one of these
policies includes insurance coverage against the use of revoked certs when the
browser is barred by design to check CRLs.

Now, can you tell me where is this meaning accessible to the application?  I.e.,
accesible to the user -- after the sysadmin has acepted the policies? Or, will
the browser simply ignore this and readily accept any cert signed by either CA?

Of course, the above example can be made with other attributes.  And, that is
why I wrote that policy extensions are not infused with meaning, they are simply
pointers to a meaning -- which meaning can be  inacessible to the application.

Cheers,

Ed Gerck






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 UAA04421 for <[e-mail]>; Thu, 22 Jul 1999 20:36:56 -0700 (PDT)
Received: from nma.com (pm05-25.sac.verio.net [209.162.64.185]) by tomcat.sac.verio.net (8.9.1a/8.9.1) with ESMTP id UAA02336; Thu, 22 Jul 1999 20:35:27 -0700 (PDT)
Message-ID: <[e-mail]>
Date: Thu, 22 Jul 1999 20:35:18 -0700
From: Ed Gerck <[e-mail]>
X-Mailer: Mozilla 4.51 [en] (Win98; I)
X-Accept-Language: en
MIME-Version: 1.0
To: Jan Nielsen <[e-mail]>
CC: Stephen Kent <[e-mail]>, "'[e-mail]'" <[e-mail]>
Subject: Re: Common misconceptions, was Re: KISS for PKIX. (Was: RE: ASN.1vs  XML   (used to be RE: I-D 	ACTION :draft-ietf-pkix-scvp- 00.txt))
References: <v04020a02b3b3e54bc992@[128.33.238.108]> <v04020a00b3b56b6383a7@[128.33.238.45]> <[e-mail]> <[e-mail]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Jan Nielsen wrote:

> Hi Stephen and Ed, et. al.
>
> I believe a discussion the non-repudiation characteristics of secret key versus private/public
> key systems requires more than a discussion of key type.

Secret key systems are in discussion here -- though they may be ;-)
The discussion was between passwords and private-key certificates.

> > To rephrase, my point was very simple -- passwords strongly deny NR; certificates
> > do no necessarily deny NR and thus certificate authentication can be misused by the
> > verifier in order to provide grounds for NR even when the certificate holder denies it.
>
> This is generally incorrect.

;-) no.

> Secure authentication protocols implemented by trusted clients
> generally have better key management characteristics than today "PKI systems", e.g., browsers,
> and therefore have better non-repudiation characteristics.

This has nothing to do with what I discussed -- what you seem to believe to be "generally
incorrect" is actually common wisdom and has nothing to do with what you mention,
which may explain your off-the-point remark.

>  Until the key management aspect of
> NR is resolved technically (and to the satisfaction of a particular legal system), the NR
> characteristics of a system will not be quantifiable; rather, it will be in the eye of the
> beholder.

See it this way -- for private/public key certs, the NR characteristics may vary. However,
for passwords NR simply does not exist (as I commented before).  That is why I also
commented that passwords and certificates are certainly not the same in regard to the
legal significance of their respective authentication acts.  With a certificate, a  verifier
may maliciously build a non-repudiaton case even if the signer does not want it -- but,
with a password this is simply not possible at all.

A large difference, even though generally misunderstood.  But, there are other differences,
for example the "Radar O'Reilly attack" -- to which passwords are also immune.  Again,
just to make sure it is dead clear, I am not predicating that passwords are "better" than
certificates -- just that they are different and such cannot be ignored in authentication
acts as Steve predicated.

Vive la difference!

Cheers,

Ed Gerck



>

>
>
> Regards,
>
> jsn
>
> --
> Jan Nielsen
> Campus Pipeline, Inc.
> --------------------------------------
> [e-mail]
> 801.485.6000 x155 (voice)
> 801.485.6606      (facimile)
> http://www.campuspipeline.com
> --------------------------------------



Received: from mail.campuspipeline.com ([209.160.196.105]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id SAA16212 for <[e-mail]>; Thu, 22 Jul 1999 18:13:49 -0700 (PDT)
Received: from campuspipeline.com ([209.160.196.100]) by mail.campuspipeline.com (Netscape Messaging Server 3.54) with ESMTP id 465; Thu, 22 Jul 1999 19:19:06 -0600
Message-ID: <[e-mail]>
Date: Thu, 22 Jul 1999 19:15:55 -0600
From: "Jan Nielsen" <[e-mail]>
Organization: Campus Pipeline, Inc.
X-Mailer: Mozilla 4.5 [en] (WinNT; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Ed Gerck <[e-mail]>
CC: Stephen Kent <[e-mail]>, "'[e-mail]'" <[e-mail]>
Subject: Re: Common misconceptions, was Re: KISS for PKIX. (Was: RE: ASN.1vs  XML   (used to be RE: I-D 	ACTION :draft-ietf-pkix-scvp- 00.txt))
References: <v04020a02b3b3e54bc992@[128.33.238.108]> <v04020a00b3b56b6383a7@[128.33.238.45]> <[e-mail]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Hi Stephen and Ed, et. al.

I believe a discussion the non-repudiation characteristics of secret key versus private/public
key systems requires more than a discussion of key type.  The authentication protocol, the
specific implementation of that protocol, the characteristics of the core cryptographic
service, and the characteristics of the key management are all more important technical
characteristics w.r.t. non-repudiation than the actual key type.

> To rephrase, my point was very simple -- passwords strongly deny NR; certificates
> do no necessarily deny NR and thus certificate authentication can be misused by the
> verifier in order to provide grounds for NR even when the certificate holder denies it.

This is generally incorrect.  Secure authentication protocols implemented by trusted clients
generally have better key management characteristics than today "PKI systems", e.g., browsers,
and therefore have better non-repudiation characteristics.  Until the key management aspect of
NR is resolved technically (and to the satisfaction of a particular legal system), the NR
characteristics of a system will not be quantifiable; rather, it will be in the eye of the
beholder.

Regards,

jsn

--
Jan Nielsen
Campus Pipeline, Inc.
--------------------------------------
[e-mail]
801.485.6000 x155 (voice)
801.485.6606      (facimile)
http://www.campuspipeline.com
--------------------------------------




Received: from e1.ny.us.ibm.com (e1.ny.us.ibm.com [32.97.182.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id QAA12266 for <[e-mail]>; Thu, 22 Jul 1999 16:42:46 -0700 (PDT)
From: [e-mail]
Received: from northrelay02.pok.ibm.com (northrelay02.pok.ibm.com [9.117.200.22]) by e1.ny.us.ibm.com (8.9.3/8.9.3) with ESMTP id TAA77892; Thu, 22 Jul 1999 19:44:29 -0400
Received: from D51MTA05.pok.ibm.com (d51mta05.pok.ibm.com [9.117.200.33]) by northrelay02.pok.ibm.com (8.8.8m2/NCO v2.03) with SMTP id TAA267106; Thu, 22 Jul 1999 19:44:42 -0400
Received: by D51MTA05.pok.ibm.com(Lotus SMTP MTA v4.6.4  (830.2 3-23-1999))  id 852567B6.008266DF ; Thu, 22 Jul 1999 19:44:20 -0400
X-Lotus-FromDomain: IBMUS
To: Keith Brady <[e-mail]>
cc: [e-mail]
Message-ID: <[e-mail]>
Date: Thu, 22 Jul 1999 19:44:18 -0400
Subject: Re: Two questions about 2510 from interop trials
Mime-Version: 1.0
Content-type: text/plain; charset=us-ascii
Content-Disposition: inline

     If the sender name is there as a check, why not allow a hash of the sender
name as an option in these cases (see below)?

          Tom Gindin

Keith Brady <[e-mail]> on 07/22/99 04:58:47 PM

To:   [e-mail]
cc:
Subject:  Two questions about 2510 from interop trials






As I mentioned in Oslo there are a couple of additional questions about
rfc2510 that have come up as we prepare for the next CMP interop workshops.

1) Polling Time

In section 5.2 (TCP direct protocol), the time-to-check-back is in epoch
seconds. Since there is no guarantee that the CA/RA and end-entity have
properly synchronised clocks and since we want to avoid the Y2038 issue it
was the opinion of the last workshop attendees that this should be changed
to be a delta from when the CA/RA issues the pollRep partialMsgRep.

Is this a good idea and should it be in a rev of 2510?

[I believe this point was first raised by John Wray of Iris]

2) Proof of Possession of Encryption Key

[Note: I do not query the need for this and have no wish to reactivate the
       rather tired argument about it]

It will be a goal of future interops to handle POP on encryption keys.
There appears to be an odd quirk in section 3.2.8 option 3 where the input
to the encryption process -- Challenge.Rand -- is reasonably likely to be
larger than the block size of the key in question (for example, if
Challenge.Rand.sender is a distinguished name of reasonable depth and the
key is a 1024-bit one).

[Tom Gindin]   How about making sender in Challenge.Rand the following:

sender    CHOICE    {
     name      GeneralName,   -- must match PKIHeader.sender
     hash      SenderHash
}

SenderHash     ::=  SEQUENCE  {
     algorithm AlgorithmIdentifier,
     hashValue OCTET STRING   -- taken on PKIHeader.sender
}

[Tom Gindin]   Naturally, sender.hash (whose normal size would be about 35
bytes) would be used whenever the length of Rand using the name format would
exceed one encryption block.


Clearly this has performancce implications and since PKCS-1 ('93) does not
explain how to do RSA encryption where more than one block is required
there is some chance (however slim) that implementations will do this
incorrectly.

Should we deprecate this option or amend Challenge to use EncryptedValue
(for example)?


cheers,

Keith





Received: from ns1.dmz.valicert.com (ns1.valicert.com [63.65.221.10]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id QAA11967 for <[e-mail]>; Thu, 22 Jul 1999 16:36:01 -0700 (PDT)
Received: from ns1.serverfarm.valicert.com (corporate-gw.valicert.com [63.65.221.2]) by ns1.dmz.valicert.com (8.9.2/8.9.2) with ESMTP id QAA13729; Thu, 22 Jul 1999 16:35:54 -0700 (PDT)
Received: from thor (static-4-51.corporate.valicert.com [192.168.4.51]) by ns1.serverfarm.valicert.com (8.9.2/8.9.2) with SMTP id QAA03830; Thu, 22 Jul 1999 16:37:20 -0700 (PDT)
Reply-To: <[e-mail]>
From: "Khaja E. Ahmed" <[e-mail]>
To: "'Santosh Chokhani'" <[e-mail]>, "'Sean Turner'" <[e-mail]>, "'PKIX'" <[e-mail]>
Subject: RE: CRL Checking Text
Date: Thu, 22 Jul 1999 16:55:15 -0700
Message-ID: <002601bed49d$a5845620$[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 8bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V4.72.2106.4
In-Reply-To: <51BF55C30B4FD1118B4900207812701E403BCE@WUHER>

Santosh,

The only X.509 recommendation I am able to find on the ITU web site is the
08/97 version which does not have Annex M.  Can you send the Annex or the
pointer to this group so we can review it.  Thanks.

Khaja


-----Original Message-----
From: Santosh Chokhani [mailto:[e-mail]]
Sent: Thursday, July 22, 1999 2:56 PM
To: 'Sean Turner'; PKIX
Subject: RE: CRL Checking Text


We have done detailed work on this topic and Annex M of the latest X.509
FPDAM has the pertinent language/rules.  I think PKIX should start with
Annex M and revise it if and only if necessary.

> -----Original Message-----
> From:	Sean Turner [SMTP:[e-mail]]
> Sent:	Thursday, July 22, 1999 5:45 PM
> To:	PKIX
> Subject:	CRL Checking Text
>
> All,
>
> I asked a few weeks ago where the explicit requirements were to
> check/verify CRLs in RFC 2459.  The is some text in section 6.1 that
> says:
>
>          Verify ... the certificate had not been revoked at time T and
> is not
>          currently on hold status that commenced before time T, (this
>          may be determined by obtaining the appropriate CRL or status
>          information, or by out-of-band mechanisms),
>
> I think we need a little more information that explicitly states what
> the verification steps are for CRLs.  Attached is some suggested text:
>
> Prior to trusting an issuer’s CRL, the signature across the CRL must
> itself be validated.  When required to validate a CRL during
> certificate
> path verification, CRL verification requires the following checks:
>
> 1. Verify the signature on the CRL, distribution point CRL, or delta
> CRL
> by employing the public key from the CRL issuer’s certificate. If the
> signature across the CRL is invalid, the user shall be notified that
> the
> signature was invalid and instructed to obtain a new CRL from the
> repository. If a valid CRL cannot be obtained, then the user will be
> given the option to proceed without a valid CRL and without using the
> invalid CRL.
>
> 2. Verify the certification path (see clause 6 of RFC2459) of the CRL
> issuer’s signature certificate.
>
> 3. Verify that the present time, T, falls between thisUpdate and
> nextUpdate.  If time T is later than the nextUpdate value, the user
> shall receive guidance to obtain a later CRL from the repository, and
> be
> given the option to proceed with the out-of-date CRL (signature must
> still be checked).
>
> 4. Verify that the cRLNumber is greater than that of the last CRL that
> the user possesses.
>
> 5. Verify that the name in the CRL's issuer field or the
> certificateIssuer extension is the issuer of the certificate.
>
> 6. If the keyUsage extension is present in the CRL issuer’s
> certificate
> and is flagged critical, verify that the cRLSign bit is set to 1.
>
> 7. Check whether the certificate’s serialNumber appears on the CRL,
> distribution point CRL, or delta CRL.  If the certificate's serial
> number is present, and if no reasonCode exists, or a reasonCode exists
> and is either unspecified, affiliationChanged, superseded, or
> cessationOfOperation, notify the user of which certificate is on the
> CRL, distribution point CRL, or delta CRL and allow the option to
> proceed with data processing.  If the reasonCode is keyCompromise or
> certificateHold, the user shall be notified and the certificate shall
> be
> rejected thereby halting all associated processing.  If a certificate
> that appears on the CRL, distribution point CRL, or delta CRL is a CA
> certificate, regardless of the reasonCode, the user shall be notified
> and the certificate shall be rejected thereby halting all associated
> processing.  If the revoked certificate is the user’s certificate, the
> user will be directed to notify the associated CA.
>
> The notification returned to the user at the end of the CRL check
> shall
> at a minimum shall:
>
> - List all expired certificates in the certificate chain.
>
> - Explicitly state that the certificate(s) is/are expired.
>
> - Explicitly state that the certificate(s) may have been revoked, and
> that the certificate will not appear on current CRLs even if the
> certificate has been revoked.
>
> - Explicitly state that the signature applied to the entity being
> verified may not be valid. Verification of signatures using expired
> certificates requires the assistance of the originator’s CA.
>
> - Require positive user action to acknowledge the warning message
> (i.e.
> clicking an on-screen OK button) before data processing
> continues.
>
> Thoughts?  Too restrictive or not enough info?
>
> spt




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 PAA10951 for <[e-mail]>; Thu, 22 Jul 1999 15:23:34 -0700 (PDT)
Received: by WUHER with Internet Mail Service (5.0.1458.49) id <LSH86C07>; Thu, 22 Jul 1999 18:24:39 -0400
Message-ID: <51BF55C30B4FD1118B4900207812701E403BD2@WUHER>
From: Santosh Chokhani <[e-mail]>
To: "'Sean Turner'" <[e-mail]>, Santosh Chokhani <[e-mail]>
Cc: PKIX <[e-mail]>
Subject: RE: CRL Checking Text
Date: Thu, 22 Jul 1999 18:24:38 -0400
X-Priority: 3
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.0.1458.49)
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 PAA10952

I think either there should be a reference or the text should be taken
from X.509 and revised for pkix as applicable.  I will be glad to take
the lead on revising it.

> -----Original Message-----
> From:	Sean Turner [SMTP:[e-mail]]
> Sent:	Thursday, July 22, 1999 6:11 PM
> To:	Santosh Chokhani
> Cc:	PKIX
> Subject:	Re: CRL Checking Text
> 
> Santosh,
> 
> Is the plan then to put a reference in the update to RFC2459 to point
> to
> Annex M of X.509 for CRL checking?
> 
> spt
> 
> Santosh Chokhani wrote:
> 
> > We have done detailed work on this topic and Annex M of the latest
> X.509
> > FPDAM has the pertinent language/rules.  I think PKIX should start
> with
> > Annex M and revise it if and only if necessary.
> >
> > > -----Original Message-----
> > > From: Sean Turner [SMTP:[e-mail]]
> > > Sent: Thursday, July 22, 1999 5:45 PM
> > > To:   PKIX
> > > Subject:      CRL Checking Text
> > >
> > > All,
> > >
> > > I asked a few weeks ago where the explicit requirements were to
> > > check/verify CRLs in RFC 2459.  The is some text in section 6.1
> that
> > > says:
> > >
> > >          Verify ... the certificate had not been revoked at time T
> and
> > > is not
> > >          currently on hold status that commenced before time T,
> (this
> > >          may be determined by obtaining the appropriate CRL or
> status
> > >          information, or by out-of-band mechanisms),
> > >
> > > I think we need a little more information that explicitly states
> what
> > > the verification steps are for CRLs.  Attached is some suggested
> text:
> > >
> > > Prior to trusting an issuer’s CRL, the signature across the CRL
> must
> > > itself be validated.  When required to validate a CRL during
> > > certificate
> > > path verification, CRL verification requires the following checks:
> > >
> > > 1. Verify the signature on the CRL, distribution point CRL, or
> delta
> > > CRL
> > > by employing the public key from the CRL issuer’s certificate. If
> the
> > > signature across the CRL is invalid, the user shall be notified
> that
> > > the
> > > signature was invalid and instructed to obtain a new CRL from the
> > > repository. If a valid CRL cannot be obtained, then the user will
> be
> > > given the option to proceed without a valid CRL and without using
> the
> > > invalid CRL.
> > >
> > > 2. Verify the certification path (see clause 6 of RFC2459) of the
> CRL
> > > issuer’s signature certificate.
> > >
> > > 3. Verify that the present time, T, falls between thisUpdate and
> > > nextUpdate.  If time T is later than the nextUpdate value, the
> user
> > > shall receive guidance to obtain a later CRL from the repository,
> and
> > > be
> > > given the option to proceed with the out-of-date CRL (signature
> must
> > > still be checked).
> > >
> > > 4. Verify that the cRLNumber is greater than that of the last CRL
> that
> > > the user possesses.
> > >
> > > 5. Verify that the name in the CRL's issuer field or the
> > > certificateIssuer extension is the issuer of the certificate.
> > >
> > > 6. If the keyUsage extension is present in the CRL issuer’s
> > > certificate
> > > and is flagged critical, verify that the cRLSign bit is set to 1.
> > >
> > > 7. Check whether the certificate’s serialNumber appears on the
> CRL,
> > > distribution point CRL, or delta CRL.  If the certificate's serial
> > > number is present, and if no reasonCode exists, or a reasonCode
> exists
> > > and is either unspecified, affiliationChanged, superseded, or
> > > cessationOfOperation, notify the user of which certificate is on
> the
> > > CRL, distribution point CRL, or delta CRL and allow the option to
> > > proceed with data processing.  If the reasonCode is keyCompromise
> or
> > > certificateHold, the user shall be notified and the certificate
> shall
> > > be
> > > rejected thereby halting all associated processing.  If a
> certificate
> > > that appears on the CRL, distribution point CRL, or delta CRL is a
> CA
> > > certificate, regardless of the reasonCode, the user shall be
> notified
> > > and the certificate shall be rejected thereby halting all
> associated
> > > processing.  If the revoked certificate is the user’s certificate,
> the
> > > user will be directed to notify the associated CA.
> > >
> > > The notification returned to the user at the end of the CRL check
> > > shall
> > > at a minimum shall:
> > >
> > > - List all expired certificates in the certificate chain.
> > >
> > > - Explicitly state that the certificate(s) is/are expired.
> > >
> > > - Explicitly state that the certificate(s) may have been revoked,
> and
> > > that the certificate will not appear on current CRLs even if the
> > > certificate has been revoked.
> > >
> > > - Explicitly state that the signature applied to the entity being
> > > verified may not be valid. Verification of signatures using
> expired
> > > certificates requires the assistance of the originator’s CA.
> > >
> > > - Require positive user action to acknowledge the warning message
> > > (i.e.
> > > clicking an on-screen OK button) before data processing
> > > continues.
> > >
> > > Thoughts?  Too restrictive or not enough info?
> > >
> > > spt


Received: from smtp-out1.bellatlantic.net (smtp-out1.bellatlantic.net [199.45.39.156]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id PAA10715 for <[e-mail]>; Thu, 22 Jul 1999 15:17:13 -0700 (PDT)
Received: from ieca.com (adsl-151-200-26-46.bellatlantic.net [151.200.26.46]) by smtp-out1.bellatlantic.net (8.9.1/8.9.1) with ESMTP id SAA19953; Thu, 22 Jul 1999 18:18:00 -0400 (EDT)
Message-ID: <[e-mail]>
Date: Thu, 22 Jul 1999 18:10:31 -0400
From: Sean Turner <[e-mail]>
Organization: IECA, Inc.
X-Mailer: Mozilla 4.61 [en] (Win98; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Santosh Chokhani <[e-mail]>
CC: PKIX <[e-mail]>
Subject: Re: CRL Checking Text
References: <51BF55C30B4FD1118B4900207812701E403BCE@WUHER>
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 8bit

Santosh,

Is the plan then to put a reference in the update to RFC2459 to point to
Annex M of X.509 for CRL checking?

spt

Santosh Chokhani wrote:

> We have done detailed work on this topic and Annex M of the latest X.509
> FPDAM has the pertinent language/rules.  I think PKIX should start with
> Annex M and revise it if and only if necessary.
>
> > -----Original Message-----
> > From: Sean Turner [SMTP:[e-mail]]
> > Sent: Thursday, July 22, 1999 5:45 PM
> > To:   PKIX
> > Subject:      CRL Checking Text
> >
> > All,
> >
> > I asked a few weeks ago where the explicit requirements were to
> > check/verify CRLs in RFC 2459.  The is some text in section 6.1 that
> > says:
> >
> >          Verify ... the certificate had not been revoked at time T and
> > is not
> >          currently on hold status that commenced before time T, (this
> >          may be determined by obtaining the appropriate CRL or status
> >          information, or by out-of-band mechanisms),
> >
> > I think we need a little more information that explicitly states what
> > the verification steps are for CRLs.  Attached is some suggested text:
> >
> > Prior to trusting an issuer’s CRL, the signature across the CRL must
> > itself be validated.  When required to validate a CRL during
> > certificate
> > path verification, CRL verification requires the following checks:
> >
> > 1. Verify the signature on the CRL, distribution point CRL, or delta
> > CRL
> > by employing the public key from the CRL issuer’s certificate. If the
> > signature across the CRL is invalid, the user shall be notified that
> > the
> > signature was invalid and instructed to obtain a new CRL from the
> > repository. If a valid CRL cannot be obtained, then the user will be
> > given the option to proceed without a valid CRL and without using the
> > invalid CRL.
> >
> > 2. Verify the certification path (see clause 6 of RFC2459) of the CRL
> > issuer’s signature certificate.
> >
> > 3. Verify that the present time, T, falls between thisUpdate and
> > nextUpdate.  If time T is later than the nextUpdate value, the user
> > shall receive guidance to obtain a later CRL from the repository, and
> > be
> > given the option to proceed with the out-of-date CRL (signature must
> > still be checked).
> >
> > 4. Verify that the cRLNumber is greater than that of the last CRL that
> > the user possesses.
> >
> > 5. Verify that the name in the CRL's issuer field or the
> > certificateIssuer extension is the issuer of the certificate.
> >
> > 6. If the keyUsage extension is present in the CRL issuer’s
> > certificate
> > and is flagged critical, verify that the cRLSign bit is set to 1.
> >
> > 7. Check whether the certificate’s serialNumber appears on the CRL,
> > distribution point CRL, or delta CRL.  If the certificate's serial
> > number is present, and if no reasonCode exists, or a reasonCode exists
> > and is either unspecified, affiliationChanged, superseded, or
> > cessationOfOperation, notify the user of which certificate is on the
> > CRL, distribution point CRL, or delta CRL and allow the option to
> > proceed with data processing.  If the reasonCode is keyCompromise or
> > certificateHold, the user shall be notified and the certificate shall
> > be
> > rejected thereby halting all associated processing.  If a certificate
> > that appears on the CRL, distribution point CRL, or delta CRL is a CA
> > certificate, regardless of the reasonCode, the user shall be notified
> > and the certificate shall be rejected thereby halting all associated
> > processing.  If the revoked certificate is the user’s certificate, the
> > user will be directed to notify the associated CA.
> >
> > The notification returned to the user at the end of the CRL check
> > shall
> > at a minimum shall:
> >
> > - List all expired certificates in the certificate chain.
> >
> > - Explicitly state that the certificate(s) is/are expired.
> >
> > - Explicitly state that the certificate(s) may have been revoked, and
> > that the certificate will not appear on current CRLs even if the
> > certificate has been revoked.
> >
> > - Explicitly state that the signature applied to the entity being
> > verified may not be valid. Verification of signatures using expired
> > certificates requires the assistance of the originator’s CA.
> >
> > - Require positive user action to acknowledge the warning message
> > (i.e.
> > clicking an on-screen OK button) before data processing
> > continues.
> >
> > Thoughts?  Too restrictive or not enough info?
> >
> > spt



Received: from puma.baltimore.ie ([e-mail] [194.125.215.8]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id PAA10497 for <[e-mail]>; Thu, 22 Jul 1999 15:12:10 -0700 (PDT)
Received: by puma.baltimore.ie; id AAA03881; Fri, 23 Jul 1999 00:05:47 +0100 (GMT/IST)
Received: from bobcat.baltimore.ie(192.168.20.10) by puma.baltimore.ie via smap (4.1) id xma003879; Fri, 23 Jul 99 00:05:46 +0100
Received: from sage.baltimore.ie (IDENT:[e-mail] [192.168.21.125]) by bobcat.baltimore.ie (8.9.3/8.9.3) with ESMTP id XAA09521 for <[e-mail]>; Thu, 22 Jul 1999 23:15:06 +0100
Received: from sage.baltimore.ie (IDENT:keith@localhost [127.0.0.1]) by sage.baltimore.ie (8.9.3/8.9.3) with ESMTP id XAA08981 for <[e-mail]>; Thu, 22 Jul 1999 23:15:08 +0100
Message-Id: <[e-mail]>
To: [e-mail]
Subject: Re: Ptr to doc on "how end-entity authenticates cert_req to CA" 
Date: Thu, 22 Jul 1999 23:15:08 +0100
From: Keith Brady <[e-mail]>

 "Bill" == Bill Doster <[e-mail]> writes:

Bill> After looking through all the IETF PKIX drafts, I'm still in the
Bill> dark as to what information is provided by the end-entity to
Bill> authenticate itself as the entity named in the cert req (as opposed
Bill> to demonstrating possession of the cert's associated private key).

Have a look at Bob Moskowitz's summary of the CMP interop workshops
"draft-moskowitz-cmpinterop". 

Basically, we assume (following the commentary in 2510) that the CA/RA has
agreed a passphrase and reference ID with the requester. The requester
then submits an IR containing it's signature key (and usual POP) MAC'ed
under the passphrase with the signer_kid set to the reference ID. The
CA/RA may choose to ignore the requesters dname choice and use one that
was previously agreed. The requester can trust the response and contained
cert path (if any) since it is MAC'ed by the CA/RA.

The requester signs all subsequent CR's with their signing key.

cheers,

Keith


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 OAA10110 for <[e-mail]>; Thu, 22 Jul 1999 14:55:01 -0700 (PDT)
Received: by WUHER with Internet Mail Service (5.0.1458.49) id <LSH86C92>; Thu, 22 Jul 1999 17:56:05 -0400
Message-ID: <51BF55C30B4FD1118B4900207812701E403BCE@WUHER>
From: Santosh Chokhani <[e-mail]>
To: "'Sean Turner'" <[e-mail]>, PKIX <[e-mail]>
Subject: RE: CRL Checking Text
Date: Thu, 22 Jul 1999 17:56:04 -0400
X-Priority: 3
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.0.1458.49)
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 OAA10111

We have done detailed work on this topic and Annex M of the latest X.509
FPDAM has the pertinent language/rules.  I think PKIX should start with
Annex M and revise it if and only if necessary.

> -----Original Message-----
> From:	Sean Turner [SMTP:[e-mail]]
> Sent:	Thursday, July 22, 1999 5:45 PM
> To:	PKIX
> Subject:	CRL Checking Text
> 
> All,
> 
> I asked a few weeks ago where the explicit requirements were to
> check/verify CRLs in RFC 2459.  The is some text in section 6.1 that
> says:
> 
>          Verify ... the certificate had not been revoked at time T and
> is not
>          currently on hold status that commenced before time T, (this
>          may be determined by obtaining the appropriate CRL or status
>          information, or by out-of-band mechanisms),
> 
> I think we need a little more information that explicitly states what
> the verification steps are for CRLs.  Attached is some suggested text:
> 
> Prior to trusting an issuer’s CRL, the signature across the CRL must
> itself be validated.  When required to validate a CRL during
> certificate
> path verification, CRL verification requires the following checks:
> 
> 1. Verify the signature on the CRL, distribution point CRL, or delta
> CRL
> by employing the public key from the CRL issuer’s certificate. If the
> signature across the CRL is invalid, the user shall be notified that
> the
> signature was invalid and instructed to obtain a new CRL from the
> repository. If a valid CRL cannot be obtained, then the user will be
> given the option to proceed without a valid CRL and without using the
> invalid CRL.
> 
> 2. Verify the certification path (see clause 6 of RFC2459) of the CRL
> issuer’s signature certificate.
> 
> 3. Verify that the present time, T, falls between thisUpdate and
> nextUpdate.  If time T is later than the nextUpdate value, the user
> shall receive guidance to obtain a later CRL from the repository, and
> be
> given the option to proceed with the out-of-date CRL (signature must
> still be checked).
> 
> 4. Verify that the cRLNumber is greater than that of the last CRL that
> the user possesses.
> 
> 5. Verify that the name in the CRL's issuer field or the
> certificateIssuer extension is the issuer of the certificate.
> 
> 6. If the keyUsage extension is present in the CRL issuer’s
> certificate
> and is flagged critical, verify that the cRLSign bit is set to 1.
> 
> 7. Check whether the certificate’s serialNumber appears on the CRL,
> distribution point CRL, or delta CRL.  If the certificate's serial
> number is present, and if no reasonCode exists, or a reasonCode exists
> and is either unspecified, affiliationChanged, superseded, or
> cessationOfOperation, notify the user of which certificate is on the
> CRL, distribution point CRL, or delta CRL and allow the option to
> proceed with data processing.  If the reasonCode is keyCompromise or
> certificateHold, the user shall be notified and the certificate shall
> be
> rejected thereby halting all associated processing.  If a certificate
> that appears on the CRL, distribution point CRL, or delta CRL is a CA
> certificate, regardless of the reasonCode, the user shall be notified
> and the certificate shall be rejected thereby halting all associated
> processing.  If the revoked certificate is the user’s certificate, the
> user will be directed to notify the associated CA.
> 
> The notification returned to the user at the end of the CRL check
> shall
> at a minimum shall:
> 
> - List all expired certificates in the certificate chain.
> 
> - Explicitly state that the certificate(s) is/are expired.
> 
> - Explicitly state that the certificate(s) may have been revoked, and
> that the certificate will not appear on current CRLs even if the
> certificate has been revoked.
> 
> - Explicitly state that the signature applied to the entity being
> verified may not be valid. Verification of signatures using expired
> certificates requires the assistance of the originator’s CA.
> 
> - Require positive user action to acknowledge the warning message
> (i.e.
> clicking an on-screen OK button) before data processing
> continues.
> 
> Thoughts?  Too restrictive or not enough info?
> 
> spt


Received: from quince.ifs.umich.edu (quince.ifs.umich.edu [141.211.168.138]) by mail.proper.com (8.8.8/8.8.5) with SMTP id OAA09958 for <[e-mail]>; Thu, 22 Jul 1999 14:54:49 -0700 (PDT)
Received: from boring (boring.citi.umich.edu [141.211.92.145]) by quince.ifs.umich.edu (8.6.13/8.6.12) with SMTP id RAA10158 for <[e-mail]>; Thu, 22 Jul 1999 17:56:47 -0400
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.0
Date: Thu, 22 Jul 1999 17:57:47 -0400
To: [e-mail]
From: Bill Doster <[e-mail]>
Subject: Ptr to doc on "how end-entity authenticates cert_req to CA"
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"

After looking through all the IETF PKIX drafts, I'm still in the dark as to what information is provided by the end-entity to authenticate itself as the entity named in the cert req
(as opposed to demonstrating possession of the cert's associated private key).

Perhaps my question is malformed to begin with?

Pointers anyone?



Received: from smtp-out2.bellatlantic.net (smtp-out2.bellatlantic.net [199.45.39.157]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id OAA09767 for <[e-mail]>; Thu, 22 Jul 1999 14:51:37 -0700 (PDT)
Received: from ieca.com (adsl-151-200-26-46.bellatlantic.net [151.200.26.46]) by smtp-out2.bellatlantic.net (8.9.1/8.9.1) with ESMTP id RAA26361 for <[e-mail]>; Thu, 22 Jul 1999 17:57:27 -0400 (EDT)
Message-ID: <[e-mail]>
Date: Thu, 22 Jul 1999 17:44:56 -0400
From: Sean Turner <[e-mail]>
Organization: IECA, Inc.
X-Mailer: Mozilla 4.61 [en] (Win98; U)
X-Accept-Language: en
MIME-Version: 1.0
To: PKIX <[e-mail]>
Subject: CRL Checking Text
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 8bit

All,

I asked a few weeks ago where the explicit requirements were to
check/verify CRLs in RFC 2459.  The is some text in section 6.1 that
says:

         Verify ... the certificate had not been revoked at time T and
is not
         currently on hold status that commenced before time T, (this
         may be determined by obtaining the appropriate CRL or status
         information, or by out-of-band mechanisms),

I think we need a little more information that explicitly states what
the verification steps are for CRLs.  Attached is some suggested text:

Prior to trusting an issuer’s CRL, the signature across the CRL must
itself be validated.  When required to validate a CRL during certificate
path verification, CRL verification requires the following checks:

1. Verify the signature on the CRL, distribution point CRL, or delta CRL
by employing the public key from the CRL issuer’s certificate. If the
signature across the CRL is invalid, the user shall be notified that the
signature was invalid and instructed to obtain a new CRL from the
repository. If a valid CRL cannot be obtained, then the user will be
given the option to proceed without a valid CRL and without using the
invalid CRL.

2. Verify the certification path (see clause 6 of RFC2459) of the CRL
issuer’s signature certificate.

3. Verify that the present time, T, falls between thisUpdate and
nextUpdate.  If time T is later than the nextUpdate value, the user
shall receive guidance to obtain a later CRL from the repository, and be
given the option to proceed with the out-of-date CRL (signature must
still be checked).

4. Verify that the cRLNumber is greater than that of the last CRL that
the user possesses.

5. Verify that the name in the CRL's issuer field or the
certificateIssuer extension is the issuer of the certificate.

6. If the keyUsage extension is present in the CRL issuer’s certificate
and is flagged critical, verify that the cRLSign bit is set to 1.

7. Check whether the certificate’s serialNumber appears on the CRL,
distribution point CRL, or delta CRL.  If the certificate's serial
number is present, and if no reasonCode exists, or a reasonCode exists
and is either unspecified, affiliationChanged, superseded, or
cessationOfOperation, notify the user of which certificate is on the
CRL, distribution point CRL, or delta CRL and allow the option to
proceed with data processing.  If the reasonCode is keyCompromise or
certificateHold, the user shall be notified and the certificate shall be
rejected thereby halting all associated processing.  If a certificate
that appears on the CRL, distribution point CRL, or delta CRL is a CA
certificate, regardless of the reasonCode, the user shall be notified
and the certificate shall be rejected thereby halting all associated
processing.  If the revoked certificate is the user’s certificate, the
user will be directed to notify the associated CA.

The notification returned to the user at the end of the CRL check shall
at a minimum shall:

- List all expired certificates in the certificate chain.

- Explicitly state that the certificate(s) is/are expired.

- Explicitly state that the certificate(s) may have been revoked, and
that the certificate will not appear on current CRLs even if the
certificate has been revoked.

- Explicitly state that the signature applied to the entity being
verified may not be valid. Verification of signatures using expired
certificates requires the assistance of the originator’s CA.

- Require positive user action to acknowledge the warning message (i.e.
clicking an on-screen OK button) before data processing
continues.

Thoughts?  Too restrictive or not enough info?

spt



Received: from puma.baltimore.ie ([e-mail] [194.125.215.8]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id NAA08732 for <[e-mail]>; Thu, 22 Jul 1999 13:56:11 -0700 (PDT)
Received: by puma.baltimore.ie; id WAA02886; Thu, 22 Jul 1999 22:49:47 +0100 (GMT/IST)
Received: from bobcat.baltimore.ie(192.168.20.10) by puma.baltimore.ie via smap (4.1) id xma002883; Thu, 22 Jul 99 22:49:36 +0100
Received: from sage.baltimore.ie (IDENT:[e-mail] [192.168.21.125]) by bobcat.baltimore.ie (8.9.3/8.9.3) with ESMTP id VAA07939 for <[e-mail]>; Thu, 22 Jul 1999 21:58:45 +0100
Received: from sage.baltimore.ie (IDENT:keith@localhost [127.0.0.1]) by sage.baltimore.ie (8.9.3/8.9.3) with ESMTP id VAA08842 for <[e-mail]>; Thu, 22 Jul 1999 21:58:47 +0100
Message-Id: <[e-mail]>
To: [e-mail]
Subject: Two questions about 2510 from interop trials
Date: Thu, 22 Jul 1999 21:58:47 +0100
From: Keith Brady <[e-mail]>

As I mentioned in Oslo there are a couple of additional questions about
rfc2510 that have come up as we prepare for the next CMP interop workshops.

1) Polling Time

In section 5.2 (TCP direct protocol), the time-to-check-back is in epoch
seconds. Since there is no guarantee that the CA/RA and end-entity have
properly synchronised clocks and since we want to avoid the Y2038 issue it
was the opinion of the last workshop attendees that this should be changed
to be a delta from when the CA/RA issues the pollRep partialMsgRep.

Is this a good idea and should it be in a rev of 2510?

[I believe this point was first raised by John Wray of Iris]

2) Proof of Possession of Encryption Key

[Note: I do not query the need for this and have no wish to reactivate the
       rather tired argument about it]

It will be a goal of future interops to handle POP on encryption keys.
There appears to be an odd quirk in section 3.2.8 option 3 where the input
to the encryption process -- Challenge.Rand -- is reasonably likely to be
larger than the block size of the key in question (for example, if
Challenge.Rand.sender is a distinguished name of reasonable depth and the
key is a 1024-bit one).

Clearly this has performancce implications and since PKCS-1 ('93) does not
explain how to do RSA encryption where more than one block is required
there is some chance (however slim) that implementations will do this
incorrectly.

Should we deprecate this option or amend Challenge to use EncryptedValue
(for example)?


cheers,

Keith


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 LAA07280 for <[e-mail]>; Thu, 22 Jul 1999 11:47:04 -0700 (PDT)
Received: from nma.com (pm07-16.sac.verio.net [209.162.65.35]) by tomcat.sac.verio.net (8.9.1a/8.9.1) with ESMTP id LAA05346; Thu, 22 Jul 1999 11:45:29 -0700 (PDT)
Message-ID: <[e-mail]>
Date: Thu, 22 Jul 1999 11:45:21 -0700
From: Ed Gerck <[e-mail]>
X-Mailer: Mozilla 4.51 [en] (Win98; I)
X-Accept-Language: en
MIME-Version: 1.0
To: Stephen Kent <[e-mail]>
CC: "'[e-mail]'" <[e-mail]>
Subject: Re: Common misconceptions, was Re: KISS for PKIX. (Was: RE: ASN.1vs  XML   (used to be RE: I-D 	ACTION :draft-ietf-pkix-scvp- 00.txt))
References: <v04020a02b3b3e54bc992@[128.33.238.108]> <v04020a00b3b56b6383a7@[128.33.238.45]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Stephen Kent wrote:

> Ed Gerck wrote:
> >This is often a source of confusion. But, basically, the reason is that
> >passwords have no challenge-response mechanism.  Since a password can be
> >replayed at will, the authenticating party (ie, the verifier) is barred from
> >presenting an argument of non-repudiation when passwords are used because the
> >verifier could have generated any message all by itself -- the data is intrinsically
> >corrupted. OTOH, if certificates are used then non-repudiation data may be built
> >by the verifier *notwithstanding* the desire of the authenticated party to refuse it.
> >...
> >But, there are other legal issues and cert storage liability is certainly one that also
> >comes to mind -- a user cannot so easily take his private cert with him when he
> >travels (just try it in NS browsers at some hotels for example) unless he takes his
> >laptop...  which can then be stolen or searched.
>
> Huh? Your characterization of why passwords don't provide NR is a bit over
> simplified, as challenge-response technologies also don't provide a basis
> for NR in most instances either.

Steve:

Why would my "characterization of  why passwords don't provide NR" be
"a bit over simplified" as you say? -- what have I left out, regarding passwords?

And, why would this have anything to do with your assertion that
"challenge-response technologies also don't provide a basis for NR in most
instances either"?  -- I fail to see why my observation that passwords
deny NR  (which passwords do strongly deny ) would be made more difficult by
challenge-response technologies also denying it in most instances.  I see no
connection -- and certainly none that would make passwords provide NR.

To rephrase, my point was very simple -- passwords strongly deny NR; certificates
do no necessarily deny NR and thus certificate authentication can be misused by the
verifier in order to provide grounds for NR even when the certificate holder denies it.

This answers your original question, saying that this is absolutely NOT a red herring:

>>> I agree that these are precieved problems that hinder PKI deployment, but I
>>> also think that many of these are red herrings.  If I use certificates to
>>> authenticate users, in lieu of passwords, why are there any new legal
>>> issues?

as yes, indeed, there are new legal issues. One of them is not strongly denying NR.
Another is certificate storage liability.

> Moreover, many of the ways in which we
> use certificates for authentication do not confer non-repudaition, hence my
> point.

This has nothing to with the possibility of confering NR -- which exists for certificates
(even unwillingly to the cert holder) but does NOT exist at all for passwords. Hence,
paswords do NOT have this legal issue... by construction.

> I do have some certs polyinstantiated on my laptop, desktop, and
> home machines, in Netscape.  It's doable.

Never said otherwise, on the contrary.

>  Although the observation about the opportunity for theft is accurate, it seems a bit
> far afield of this discission.

No, not far afield but is indeed a new legal issue introduced by certificates -- as you
asked for in your question  -- "If I use certificates to authenticate users, in lieu of
passwords, why are there any new legal issues?"

> >So, this one is not a red herring at all but a red sign of warning. It is
> >a common misconception, though, to assume that all authentication procedures are
> >legally equivalent -- but, they simply aren't and for several legal reasons.
>
> What you said above does not seem to support this conclusion.

As above, it is 100% supported -- certs introduce at least two new legal issues
that simply do not exist for passwords. This discussion also seems to support my
opinion that it is common to think that all authentication procedures are legally
equivalent, albeit incorrect.

> >> Part of the problem is that people have been led to believe that a
> >> PKI must support non-repudiation, which generates a large number of valid,
> >> legal concerns.
> >
> >Part of the problem is that PKIX also has a so-called non-repudiation bit ;-)
>
> Yes, and it is used to allow a CA to distinguish between a cert issued for
> signing data for auth vs. signing data for NR.  What's wrong with that?

Nothing but the fact that it does not provide for non-repudiation, so it is IMO
a misnomer. At most, it could provide for "cooperative non-repudiation" in
which the signer declares it will not repudiate and then willfully abides by such
declaration as long as it suits its purposes -- but which declaration, arguably, could
be better placed and substantiated  for context in the document itself, never in the
PKIX certificate.


> >>  However, use of a PKI to support SSL, IPsec, and S/MIME
> >> (at least on an intranet basis) does not raise such issues, yet promises to
> >> improve security and to make life easier for users.
> >
> >"improve security" and "make life easy for users" seem to be antinomies in all
> >systems -- security is counter to functionality, as a general principle.
> >So, I believe that last phrase is an empty promise though it may look good in
> >marketing materials.
>
> One example comes to mind in the context of SSL client certs.  They are
> much preferable to use vs. remembering different names and passwords for
> each web site that requires a login, and the security afforded by client
> certs is much better than passwords, even if the corresponding private keys
> are stored on my disk.

Take my previous example, but with SSL client certs -- go to a hotel and try to
use it. Either you can't (the SSL client cert is in the desktop machine at your
office) or you have to take it with you... and your laptop also (since hotel machines
cannot be relied either to be compatible or to be free from malicious software).
Thus, you now have added certificate storage liability and laptop theft liability.
Which hassles a password (less secure) does not have.  And, no authentication
(even less secure) has even less hassle.

What I am saying is not that passwords are "better" than certificates -- such comparison
would be even senseless. But, simply, that adding security implies decreasing functionality
to some extent -- so that to "improve security" and to "make life easy for users" seem to
be antinomies in all current systems.  Further, it is IMO very close to a true antinomy
like "slavery" and "freedom".  A secure system must include some amount of hassle to a
user-- the point is to make it bearable for what it provides, not to deny that the hassle
exists or, even, that it is less.

So, facing this issue might be a better strategy -- as I commented in another reply,
marketing materials notwithstanding.

> >Another common misconception.
> >
> >> I disagree with your statement that a certificate in software binds a
> >> system, vs. a user.
> >
> >I fail to see how you can possibly disagree with Eric's statement.  Trust
> >is not distributive in the social sense (ie, not associative in the mathematical
> >sense),..
> >..
> >So, you cannot affirm that a cert binds a user -- which user?  At most,
> >you can affirm that your challenge-response logs, traceroute, timestamps and
> >whatever may indeed point to a system that  you believe  has authenticated it --
> >but only as an evidence, not as a fact.
>
> I have no idea what are you talking about? The statement I questioned was
> an assertion that a cert with a privcate key protected via software did not
> provide a suitabel basis for user, vs. system, authentication.  Your
> argument above does not seem to bear on that at all.

Your statement was correctly perceived (you replied to Eric: "I disagree with your
statement that a certificate in software binds a system, vs. a user.").  And, I pointed
out that, as Eric mentioned, I also have the view that a cert with a private key
protected via software does NOT provide a suitable basis for user, vs. system,
authentication.  Clearly, if the cert with a private-key is "protected via software"
then breaking such protection only involves breaking the verifier's trust on that
software/system without the verifier knowing it, not the verifier's trust on the user.

And, I explained this conclusion by noting that trust on a private-key certificate is
not distributive (ie, not associative in the mathematical sense) to trust in the software.
So, you cannot affirm that a cert in software binds a user -- which user?  At most,
you can produce evidence that  the system has authenticated a transaction -- but
since the software (S) is between the certificate (C) and the user (U) ,  you have:

   (U*S)*C <> U*(S*C)

which means that the User can first trust the Software and then trust the Certificate to
correctly either authenticate or deny authentication according to the password transmitted
from the User by the Software, but if the User knows that the Software trusts (ie, relies
upon for its actions) some aspect that the Software can exploit in the Certificate (for
example, the Certificate always requires the same password) then the User may no longer
trust the Certificate.  I hope it is clearer.

> >> Yes, smart cards are preferable, but if the choice is
> >> between a password and a certificate (and private key) with software
> >> cryptography, I see no reason not to adopt the latter,
> >
> >One reason is to deny unwanted non-repudiation.  Another is to reduce
> >cert storage liability. Etc.
>
> I was talking about certs used for auth, not NR, making the comparison to
> passwords meaningful.

I understood you were talking about choices. To be clear -- if the choice is between
a password and a certificate (and private key) with software cryptography, then I
see several reasons NOT to adopt the latter; unwanted NR and cert storage liability
being just two examples.

> >> and I certainly see
> >> no reason to declare that the latter is not a user (vs. system)
> >> authentication mechanism.
> >
> >as above, trust is not distributive (socially).
>
> Again, your argument seems orthogonal to the issue I was addressing.

Perhaps, it is clearer now -- see above. Because trust is not distributive,
there are several reasons to declare that the latter is not a user (vs. system)
authentication mechanism.

> >> Finally, why do you say that an issuer cann[ot]
> >> associate a security policy with a certificate?  We have the syntactic
> >> means to do so as part of the standard.
> >
> >In which language? In which legal system? In which jurisdiction?
> >Syntax does not answer these (and other) questions at all -- and yet,
> >any of them makes the problem overly-variable in comparison to the
> >given syntax.  All security policies (eg, CPS) need to call themselves
> >"mutually exclusive" (otherwise I could just devise a security policy that
> >would render yours ineffective) and yet they can all be different since
> >security policies per se are not defined as part of the standard, just
> >referred in the standard as we all know.
>
> Hard copy contracts specify the language and jursidiction of
> interpretation, and cert policies can do the same.

But, the relying-parties are NOT privy to the contract between a CA
and a subscriber.  So, r-ps may completely disagree with the language,
the legal system and the jurisdiction for the contract's interpretation -- and yet,
this has no bearing either on the CA or on the subscriber.

> The fact that the policy is incorporated by use of an OID does not affect this.
> Again, I fail to see the point of your comments.

The point is that (answering your question above, to Eric, "why do you say that an issuer
cann[ot] associate a security policy with a certificate? "),  an issuer cannot strongly
associate a security policy with a certificate and such association must be overly-
variable in several aspects because such association would have to be valid
in first line to r-ps -- who are not privy to the contract between the issuer and the
subscriber.

Of course, the issuer may associate whatever it wants -- but not in relationship to
a party (eg, the r-p) that is NOT privy to the contract and that has other rights from
the law regime of its jurisdiction (the right to deny an electronic contract being
just one of them).

> >> Do you mean that we don't have
> >> appplications that pay attention to the policy extension?
> >
> >Policy extensions are not infused with meaning, they are simply pointers
> >to a meaning -- which meaning can be  inacessible to the application,
> >outdated, invalid in that jurisdiction, etc.
>
> But one configures an application to accept of rejects certs based on
> policy IDs, based on a human being having read the policy and made a value
> judgement.  We dopn't expect applications to make these decisions, but
> rather to enforce the decisions already made by users or system
> administrators.

Take the case of two policies (eg, two different CAs) that have been accepted
in separate based on value judgements by a sysadmin.  Suppose these two policies
require the user to check any cert with a CRL (eg, as CA policies do) at the
respective CA's site before relying on a cert.  However, the user's browser
cannot check CRLs (eg, as current browsers do not check).  Now, one of these
policies includes insurance coverage against the use of revoked certs when the
browser is barred by design to check CRLs.

Now, can you tell me where is this meaning accessible to the application?  I.e.,
accesible to the user -- after the sysadmin has acepted the policies? Or, will
the browser simply ignore this and readily accept any cert signed by either CA?

Of course, the above example can be made with other attributes.  And, that is
why I wrote that policy extensions are not infused with meaning, they are simply
pointers to a meaning -- which meaning can be  inacessible to the application.

Cheers,

Ed Gerck



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 GAA01851 for <[e-mail]>; Thu, 22 Jul 1999 06:54:31 -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 JAA03168; Thu, 22 Jul 1999 09:56:19 -0400 (EDT)
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
X-Sender: [e-mail]
Message-Id: <v04020a03b3bcd1ecaa25@[128.89.0.110]>
In-Reply-To: <[e-mail]>
Date: Thu, 22 Jul 1999 09:50:48 -0400
To: "Waters, Stephen" <[e-mail]>
From: Stephen Kent <[e-mail]>
Subject: RE: KISS for PKIX. (Was: RE:Asymmetric authentication
Cc: [e-mail]

Steve,

>I think we should make things as hard as possible to access the private
>authentication information, but this approach doesn't (unless I
>misunderstand) offer a way to engage the central site.  It may take me
>longer, but I can still crack the sole authentication method 'off-line'.

Yes, if the public key is publically available, as would usualy be the case
for a cert-based system, this approach only increases the work factor
lineraly, as David pointed out.

Steve


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 EAA00368 for <[e-mail]>; Thu, 22 Jul 1999 04:46:15 -0700 (PDT)
Received: by aunt15.ausys.se with Internet Mail Service (5.5.2448.0) id <3YVYBMP3>; Thu, 22 Jul 1999 13:47:40 +0200
Message-ID: <[e-mail]>
From: Hans Nilsson <[e-mail]>
To: [e-mail]
Subject: EESSI Final report
Date: Thu, 22 Jul 1999 13:47:37 +0200
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2448.0)
Content-Type: text/plain

The final and approved expert team report of the European Electronic
Signature Standardization Initiative has now been published. Go to the
following address and click on EESSI in the lefthand frame. The report is
available both in Word7 and PDF format.

http://www.ict.etsi.org/

The expert team would like to express their sincere gratitude to everyone
who has contributed and commented on the work.

Regards

Hans Nilsson

iD2 Technologies
Stockholm, Sweden



Received: from ctron-dnm.ctron.com ([e-mail] [12.25.1.120]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id DAA26306 for <[e-mail]>; Thu, 22 Jul 1999 03:06:41 -0700 (PDT)
Received: (from uucp@localhost) by ctron-dnm.ctron.com (8.8.7/8.8.7) id GAA12482; Thu, 22 Jul 1999 06:10:26 -0400 (EDT)
Received: from roc-mail2.ctron.com(134.141.72.230) by ctron-dnm.ctron.com via smap (4.1) id xma012475; Thu, 22 Jul 99 06:09:48 -0400
Received: from new-exc1.ctron.com (NEW-EXC1 [134.141.200.123]) by roc-mail2.ctron.com (8.8.7/8.8.7) with ESMTP id GAA22607; Thu, 22 Jul 1999 06:13:29 -0400 (EDT)
Received: by new-exc1.ctron.com with Internet Mail Service (5.5.2448.0) id <38L8AFSR>; Thu, 22 Jul 1999 11:07:29 +0100
Message-ID: <[e-mail]>
From: "Waters, Stephen" <[e-mail]>
To: Stephen Kent <[e-mail]>
Cc: [e-mail]
Subject: RE: KISS for PKIX. (Was: RE:Asymmetric authentication
Date: Thu, 22 Jul 1999 11:07:24 +0100
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2448.0)
Content-Type: text/plain; charset="iso-8859-1"

Stephen,

I think we should make things as hard as possible to access the private
authentication information, but this approach doesn't (unless I
misunderstand) offer a way to engage the central site.  It may take me
longer, but I can still crack the sole authentication method 'off-line'. 

Cheers, Steve.

-----Original Message-----
From: Stephen Kent [mailto:[e-mail]]
Sent: Wednesday, July 21, 1999 3:38 PM
To: Waters, Stephen
Cc: [e-mail]
Subject: RE: KISS for PKIX. (Was: RE:Asymmetric authentication


Stephen and David,

There is another approach here, that I first heard suggested by Jeff
Schiller a number of years ago. One could remember a pass phrase and use it
as the seed for a PRNG, which then feeds into a key pair selection
algorithm, thus recreating one's private key, rather than storing it. It
occurs to me that some additonal entropy could be provided by a second seed
value, saved in encrypted form and decrypted with the pass phrase.  because
this second value would be random (preferavly from a non-deterministic
source) attempts to decrypt it do not yield quick confirmation of gusses.
Instead, one has to try to use the pair of values (the pass phrase guess
and the decrypted second seed), to genreate a key pair, and then check to
see if the result yields the public key for the user. This approach is
clearly much, much slower that just decrypting a stored key, but it allows
a greater degree of security vs. a stored private key encrypted with a
password, and makes offline guessing attacks more costly.  Also, because
one hash complete freedom in choosing the pass phrase, it should be easier
to remember than a string of words formed from the bit pattern of a private
key.

Just a thought,

Steve


Received: from prv-mail20.provo.novell.com (prv-mail20.provo.novell.com [137.65.82.195]) by mail.proper.com (8.8.8/8.8.5) with SMTP id NAA25702 for <[e-mail]>; Wed, 21 Jul 1999 13:58:49 -0700 (PDT)
Received: from INET-PRV-Message_Server by prv-mail20.provo.novell.com with Novell_GroupWise; Wed, 21 Jul 1999 15:00:11 -0600
Message-Id: <[e-mail]>
X-Mailer: Novell GroupWise 5.5.2
Date: Wed, 21 Jul 1999 15:00:01 -0600
From: "Bob Jueneman" <[e-mail]>
To: <[e-mail]>, <[e-mail]>, <[e-mail]>
Cc: <[e-mail]>, <[e-mail]>, <[e-mail]>, <[e-mail]>, <[e-mail]>
Subject: Re: Showing Nationality in Cert
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by mail.proper.com id NAA25705

As usual, the devil is in the details.

First, it would be helpful if (finally) someone would specify precisely what the 
semantics of "countryName" is supposed to be, either for a natural, living (presumably)
person or a corporation.  The following possibilities come to mind: Place of birth,
place of incorporation, location of headquarters, choice of tax and/or legal
jurisdictional issues, or (the original X.500 intent, presumably) name of
name registration authority. If there is one.

With respect to countryOfCitizenship, I assume that this value could be
null (for stateless persons, for any of a number of reasons), as well as
multivalued, since some people are citizens of more than one country.

Likewise, I assume that countryOfResidence can be multi-valued.  
Certainly I can own or rent, and occasionally occupy, properties
in multiple countries.  Whether I am therefore a "resident" of that
country  or merely a transient may depend on the vagaries of the various
tax codes, immigration laws, etc., in a number of countries -- it would 
not at all surprise me to learn that different jurisdictions might come to 
different conclusions as to the "facts" of such status -- who then decides?

In the US, at least, a person can be a resident of one state, yet be domiciled
yet another term with a tortuous definition, in another state.  This is typically,
but not exclusively, the case with people who are in the military -- they often
choose which state to call their official "residence" for tax purposes, yet
they don't have to own any property or even have a permanent address in that
state!

Now that I think about it, given name and surname may also have to be multi-valued,
as people may have multiple, even "official" names, due to differences in
alphabets and customs.  

When I was in college, I had a friend named George O'Clock. When I asked
him who he happened to have such an unusual name, he said that when his
grandfather immigrated from the old country, the immigration official at Ellis
Island asked him for his name.  He said something like "Ohklubsanski", but
that was too hard for the immigration official, who had just notices that it was
already past his quitting time.  So "O'Clock" is what he became.  (No, I don't know 
what first name he put down.  I just hope it wasn't "Five"!)

>>> Stefan Santesson <[e-mail]> 07/20/99 02:14PM >>>
This depends what you want to do.

If you just want to add citizenship as additional information to the
subject DN then I agree with Russ and Bill that you use
SubjectDirectoryAttribute.

If you, however wish to store a complete identity record, describing an
identity of a person, the Qualified Certificate draft has created a name
field placed in subjectAltName extension under OtherNames.

This field is named the PersonalData field and has defined attributes for
CountryOfCitizenship.

The complete list of defined attributes for this field is:

   countryName;
   givenName;
   surname;
   pseudonym;
   dNQualifier;
   dateOfBirth;
   placeOfBirth;
   gender;
   postalAddress;
   countryOfCitizenship; and
   countryOfResidence.

You can use any subset of these attributes. But in order to use this field,
the present attributes from this list must form a unique identity (in order
to satisfy overall requirements for the SubjAltName extension).

You can find the latest preliminary QC draft at:

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

A new draft will be submitted officially within 2 weeks.

After this the draft will got to last call (according to plan).


/Stefan



At 10:40 AM 7/17/99 -0400, Vickers, Randal R wrote:
>I work with the US DoD PKI engineers at the Defense Information Systems
>Agency. Requirements from the Assistant Secretary of Defense for C3I state
>that we must show citizenship or nationality (symantics) in the cert. My
>question is what extension  does anyone reccommend placing it in. We have
>looked at subjectDirectoryattribute and one of the extensions below
>subjectAlternatename. We are not locked into any one thing as long as it is
>standards based.
>	Thanks
>	Randal Vickers

-------------------------------------------------------------------
Stefan Santesson                <[e-mail]>
Accurata 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 po1.bbn.com (PO1.BBN.COM [192.1.50.38]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id NAA24740 for <[e-mail]>; Wed, 21 Jul 1999 13:33:40 -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 QAA22667; Wed, 21 Jul 1999 16:35:28 -0400 (EDT)
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
X-Sender: [e-mail]
Message-Id: <v04020a04b3bbdcb205ee@[128.89.0.110]>
In-Reply-To: <[e-mail]>
Date: Wed, 21 Jul 1999 16:29:18 -0400
To: "David P. Kemp" <[e-mail]>
From: Stephen Kent <[e-mail]>
Subject: RE: KISS for PKIX. (Was: RE:Asymmetric authentication
Cc: [e-mail]

David,

If one does not want to treat the public key as public info, then we can
certainly make life much harder for an attacker.  The measures I described
work even better under such circumstances, as the atacker has no reference
against which to compare guesses.

A company called Arcot has a patented approch to doing this, in which they
pass the public key as an encrypted extension in an X.509 cert, which would
allow continued use of the current mechanisms in IKE for cert exchange. A
paper on their approach was published in the 1999 IEEE Security and Privacy
Symposium.

Of course, Lynn's cert-less approach to using public key cryptography also
provides ways to avoid such attacks.

At this point, the discussion really seems more appropriate for the IPsec,
not PKIX, mailing list, don't you think?

Steve


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 IAA15369 for <[e-mail]>; Wed, 21 Jul 1999 08:47:42 -0700 (PDT)
Received: from stingray.missi.ncsc.mil (root@localhost) by stingray.missi.ncsc.mil with ESMTP id LAA14397 for <[e-mail]>; Wed, 21 Jul 1999 11:49:34 -0400 (EDT)
Received: from missi.ncsc.mil (depot.missi.ncsc.mil [144.51.60.1]) by stingray.missi.ncsc.mil with ESMTP id LAA14393 for <[e-mail]>; Wed, 21 Jul 1999 11:49:33 -0400 (EDT)
Received: from ara.missi.ncsc.mil (ara.missi.ncsc.mil [144.51.58.9]) by missi.ncsc.mil (8.8.8/8.8.8) with ESMTP id LAA20671 for <[e-mail]>; Wed, 21 Jul 1999 11:49:32 -0400 (EDT)
Received: from ara.missi.ncsc.mil (ara.missi.ncsc.mil [144.51.58.9]) by ara.missi.ncsc.mil (8.9.1b+Sun/8.9.1) with SMTP id LAA11905 for <[e-mail]>; Wed, 21 Jul 1999 11:49:14 -0400 (EDT)
Message-Id: <[e-mail]>
Date: Wed, 21 Jul 1999 11:49:14 -0400 (EDT)
From: "David P. Kemp" <[e-mail]>
Reply-To: "David P. Kemp" <[e-mail]>
Subject: RE: KISS for PKIX. (Was: RE:Asymmetric authentication
To: [e-mail]
MIME-Version: 1.0
Content-Type: TEXT/plain; charset=us-ascii
Content-MD5: jSbqZxSYlVcbPc4Dztf2OA==
X-Mailer: dtmail 1.3.0 CDE Version 1.3 SunOS 5.7 sun4u sparc

That sounds like an interesting approach when a user's public key is
public.

But I assume from the IKE/XAUTH discussion that:

1) the VPN server authenticates itself to the client and establishes
   confidentiality for a secondary authentication of the client to the server.

2) the VPN server has some unique secret knowledge about the user, established
   by some enrollment process, that allows it to determine if the user has
   typed the correct password/pin.  Otherwise, the thief could set up his
   own VPN server from public information, configure the stolen client to
   authenticate the bogus server, and start guessing passwords.

My suggestion is that if the VPN server must have some secret knowledge
of the user, then that secret might as well be the larger component of a
keypair generated during enrollment.  The client would get the smaller
component, a private key which can not be determined by offline trial
decryption.

This eliminates the need for a secondary XAUTH protocol, since the normal
IKE handshake provides the benefit claimed for XAUTH.  KISS.

Dave Kemp

(Why are we discussing IKE on the PKIX list?)



> From: Stephen Kent <[e-mail]>
> 
> Stephen and David,
> 
> There is another approach here, that I first heard suggested by Jeff
> Schiller a number of years ago. One could remember a pass phrase and use it
> as the seed for a PRNG, which then feeds into a key pair selection
> algorithm, thus recreating one's private key, rather than storing it. It
> occurs to me that some additonal entropy could be provided by a second seed
> value, saved in encrypted form and decrypted with the pass phrase.  because
> this second value would be random (preferavly from a non-deterministic
> source) attempts to decrypt it do not yield quick confirmation of gusses.
> Instead, one has to try to use the pair of values (the pass phrase guess
> and the decrypted second seed), to genreate a key pair, and then check to
> see if the result yields the public key for the user. This approach is
> clearly much, much slower that just decrypting a stored key, but it allows
> a greater degree of security vs. a stored private key encrypted with a
> password, and makes offline guessing attacks more costly.  Also, because
> one hash complete freedom in choosing the pass phrase, it should be easier
> to remember than a string of words formed from the bit pattern of a private
> key.
> 
> Just a thought,
> 
> Steve



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 HAA13347 for <[e-mail]>; Wed, 21 Jul 1999 07:36:32 -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 KAA01184; Wed, 21 Jul 1999 10:36:53 -0400 (EDT)
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
X-Sender: [e-mail]
Message-Id: <v04020a07b3bb8a1b99af@[128.89.0.110]>
In-Reply-To: <[e-mail]>
Date: Wed, 21 Jul 1999 10:38:24 -0400
To: "Waters, Stephen" <[e-mail]>
From: Stephen Kent <[e-mail]>
Subject: RE: KISS for PKIX. (Was: RE:Asymmetric authentication
Cc: [e-mail]

Stephen and David,

There is another approach here, that I first heard suggested by Jeff
Schiller a number of years ago. One could remember a pass phrase and use it
as the seed for a PRNG, which then feeds into a key pair selection
algorithm, thus recreating one's private key, rather than storing it. It
occurs to me that some additonal entropy could be provided by a second seed
value, saved in encrypted form and decrypted with the pass phrase.  because
this second value would be random (preferavly from a non-deterministic
source) attempts to decrypt it do not yield quick confirmation of gusses.
Instead, one has to try to use the pair of values (the pass phrase guess
and the decrypted second seed), to genreate a key pair, and then check to
see if the result yields the public key for the user. This approach is
clearly much, much slower that just decrypting a stored key, but it allows
a greater degree of security vs. a stored private key encrypted with a
password, and makes offline guessing attacks more costly.  Also, because
one hash complete freedom in choosing the pass phrase, it should be easier
to remember than a string of words formed from the bit pattern of a private
key.

Just a thought,

Steve


Received: from ctron-dnm.ctron.com ([e-mail] [12.25.1.120]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id HAA12488 for <[e-mail]>; Wed, 21 Jul 1999 07:06:17 -0700 (PDT)
Received: (from uucp@localhost) by ctron-dnm.ctron.com (8.8.7/8.8.7) id KAA27308; Wed, 21 Jul 1999 10:10:22 -0400 (EDT)
Received: from roc-mail2.ctron.com(134.141.72.230) by ctron-dnm.ctron.com via smap (4.1) id xma027224; Wed, 21 Jul 99 10:09:16 -0400
Received: from new-exc1.ctron.com (NEW-EXC1 [134.141.200.123]) by roc-mail2.ctron.com (8.8.7/8.8.7) with ESMTP id KAA08654; Wed, 21 Jul 1999 10:12:58 -0400 (EDT)
Received: by new-exc1.ctron.com with Internet Mail Service (5.5.2448.0) id <38L8ADJ5>; Wed, 21 Jul 1999 15:06:58 +0100
Message-ID: <[e-mail]>
From: "Waters, Stephen" <[e-mail]>
To: "David P. Kemp" <[e-mail]>
Cc: [e-mail]
Subject: RE: KISS for PKIX. (Was: RE:Asymmetric authentication
Date: Wed, 21 Jul 1999 15:06:52 +0100
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2448.0)
Content-Type: text/plain; charset="iso-8859-1"

>> From: "Waters, Stephen" <[e-mail]>
>> 
>> As you say, if the Phase1 authentication is based on a poorly kept shared
>> (group) key, anything can happen without the need to acquire a device. I
>> don't see that a well chosen, unique, well secured pre-shared secret is
much
>> worse than a certificate though.


>If the user is going to have to remember and enter a well chosen, unique
>shared secret, then why shouldn't he just remember his private key and
>do away with XAUTH?

>A private key doesn't have to be kept in a PSE on the pilferable
>laptop, it could be typed when the user establishes a connection.
>A 160 bit private key is (only) 15 S/KEY words, at 11 bits per word.

>1/2 :-)

Sorry, should have been clearer. I was assuming that the user remembers a
reasonably short password/pin that is used to access the pre-shared secret,
much in the same way as Smartcards can require pin numbers before you can
use the private key stored on them.

Pre-shared secrets can be quite long - 128 characters? - 1024bits. Easier to
remember than an RSA key maybe, but still, could be too long to remember
without writing it down.

Steve.


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 GAA11985 for <[e-mail]>; Wed, 21 Jul 1999 06:47:37 -0700 (PDT)
Received: from stingray.missi.ncsc.mil (root@localhost) by stingray.missi.ncsc.mil with ESMTP id JAA27987 for <[e-mail]>; Wed, 21 Jul 1999 09:49:28 -0400 (EDT)
Received: from missi.ncsc.mil (depot.missi.ncsc.mil [144.51.60.1]) by stingray.missi.ncsc.mil with ESMTP id JAA27981 for <[e-mail]>; Wed, 21 Jul 1999 09:49:27 -0400 (EDT)
Received: from ara.missi.ncsc.mil (ara.missi.ncsc.mil [144.51.58.9]) by missi.ncsc.mil (8.8.8/8.8.8) with ESMTP id JAA18916 for <[e-mail]>; Wed, 21 Jul 1999 09:49:25 -0400 (EDT)
Received: from ara.missi.ncsc.mil (ara.missi.ncsc.mil [144.51.58.9]) by ara.missi.ncsc.mil (8.9.1b+Sun/8.9.1) with SMTP id JAA11882 for <[e-mail]>; Wed, 21 Jul 1999 09:49:08 -0400 (EDT)
Message-Id: <[e-mail]>
Date: Wed, 21 Jul 1999 09:49:08 -0400 (EDT)
From: "David P. Kemp" <[e-mail]>
Reply-To: "David P. Kemp" <[e-mail]>
Subject: RE: KISS for PKIX. (Was: RE:Asymmetric authentication
To: [e-mail]
MIME-Version: 1.0
Content-Type: TEXT/plain; charset=us-ascii
Content-MD5: cL6PHWdI6UZ49lqf3TxWVA==
X-Mailer: dtmail 1.3.0 CDE Version 1.3 SunOS 5.7 sun4u sparc

> From: "Waters, Stephen" <[e-mail]>
> 
> As you say, if the Phase1 authentication is based on a poorly kept shared
> (group) key, anything can happen without the need to acquire a device. I
> don't see that a well chosen, unique, well secured pre-shared secret is much
> worse than a certificate though.


If the user is going to have to remember and enter a well chosen, unique
shared secret, then why shouldn't he just remember his private key and
do away with XAUTH?

A private key doesn't have to be kept in a PSE on the pilferable
laptop, it could be typed when the user establishes a connection.
A 160 bit private key is (only) 15 S/KEY words, at 11 bits per word.

1/2 :-)



Received: from ctron-dnm.ctron.com ([e-mail] [12.25.1.120]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id GAA11304 for <[e-mail]>; Wed, 21 Jul 1999 06:20:17 -0700 (PDT)
Received: (from uucp@localhost) by ctron-dnm.ctron.com (8.8.7/8.8.7) id JAA23328; Wed, 21 Jul 1999 09:24:20 -0400 (EDT)
Received: from roc-mail2.ctron.com(134.141.72.230) by ctron-dnm.ctron.com via smap (4.1) id xma023225; Wed, 21 Jul 99 09:24:00 -0400
Received: from new-exc1.ctron.com (NEW-EXC1 [134.141.200.123]) by roc-mail2.ctron.com (8.8.7/8.8.7) with ESMTP id JAA26943; Wed, 21 Jul 1999 09:27:36 -0400 (EDT)
Received: by new-exc1.ctron.com with Internet Mail Service (5.5.2448.0) id <38L8ADB6>; Wed, 21 Jul 1999 14:21:32 +0100
Message-ID: <[e-mail]>
From: "Waters, Stephen" <[e-mail]>
To: Dan Harkins <[e-mail]>
Cc: [e-mail], [e-mail]
Subject: RE: KISS for PKIX. (Was: RE:Asymmetric authentication (was ASN.1  vs XML which in turn was something else) 
Date: Wed, 21 Jul 1999 14:21:25 +0100
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2448.0)
Content-Type: text/plain; charset="iso-8859-1"

Dan,

This is a bag of 'if buts and maybes', but XAUTH may have some value if...

I agree that using XAUTH should be avoided if possible, and if I could
eliminate all possible uses, I'd be very happy not to add more state to our
already-busy IKE state machine.  At the moment, I think I'm interested in
using XAUTH as a way of forcing contact with the VPN server.

If may laptop is stolen with a individual pre-shared secret or certificate
loaded, there is a good chance that the security protecting that secret can
be cracked 'off-line' with no 'warning' given to the VPN server that that is
taking place. I would be relying on timely notification of the theft to plug
this hole.

Cases:
1) Thief does a runner with a device with no intention of returning it.

If I force VPN client to engage in a secondary authentication phase, then
that can not be cracked off-line: the hacker needs to attempt to break-in
with exchanges to the VPN server.  The VPN server can then log repeated
failures, and take action.

2) Thief borrows the device in order to steal the primary authentication
secret, then returns the device.

In the case, where the primary authentication method is a pre-shared secret,
and the stolen/borrowed device is returned without being missed/suspected,
then the attacker can then listen-in. They can also see the XAUTH phase, and
if it is weak, they can then impersonate the client. If the XAUTH phase is
secure (challenge-based), then it should be possible to prevent the
impersonation, but the listening-in....

I'm assuming listening-in is infeasible in the case of certificates, unless
I crack their server as well.


As you say, if the Phase1 authentication is based on a poorly kept shared
(group) key, anything can happen without the need to acquire a device. I
don't see that a well chosen, unique, well secured pre-shared secret is much
worse than a certificate though.

So, it seems that XAUTH may offer some protection from impersonation if the
secondary authentication method reasonably robust. 

If pre-shared secrets are used, make sure they are treated as unique secrets
per individual, and protect them with a password-derived key, and definitely
use a robust XAUTH mechanism. 

Smartcards seem to offer some hope, but there seems to be room for debate on
just secure they are.  They are probably more secure than most software key
stores, but until we get cards that can guarantee tamper resistance, there
would seem to be a job for XAUTH.

Steve. 


-----Original Message-----
From: Dan Harkins [mailto:[e-mail]]
Sent: Tuesday, July 20, 1999 9:58 PM
To: Vipul Gupta
Cc: [e-mail]; [e-mail]; [e-mail];
[e-mail]
Subject: Re: KISS for PKIX. (Was: RE:Asymmetric authentication (was
ASN.1 vs XML which in turn was something else) 


On Tue, 20 Jul 1999 10:48:48 PDT Vipul Gupta wrote
> 
>   I don't quite see the motivation behind XAUTH if it is used in
>   conjunction with regular Main/Aggressive mode since each of those
>   modes provides mutual authentication. If the client has already
>   been authenticated in Main/Aggressive mode, what is the additional
>   functionality provided by XAUTH? Or is it that the pre-shared key
>   used in Main/Aggressive mode common to *all* clients (e.g. all 
>   corporate employees) and XAUTH is used to identify a particular
>   client?

  Exactly! I brought this point up back in May. If the IKE SA has been
authenticated properly then XAUTH doesn't buy you anything. You have
the double burden of supporting a PKI and some legacy database and
the user gets yet another dialog box asking for yet another passphrase.
I find it very hard to believe that this is what people are doing when
I hear that "customers want XAUTH".

  For XAUTH to provide anything the IKE SA is authenticated with some
shared key and then the "client" authenticates himself to the "server"
with the legacy method. The problem with this is that the IKE SA and
all the SKEYID state is not authenticated. Therefore all the keys in
the IPSec SAs are not authenticated. Depending on the legacy method
this can be open to a man-in-the-middle attack too.

  draft-ietf-ipsec-internet-key-00.txt is an April Fool's draft but
the security considerations is right on in this respect.

  Dan.



Received: from www.meridianus.com (209.249.223.13.has.no.reverse [209.249.223.13] (may be forged)) by mail.proper.com (8.8.8/8.8.5) with ESMTP id OAA14833 for <[e-mail]>; Tue, 20 Jul 1999 14:29:54 -0700 (PDT)
Received: from PC1 by www.meridianus.com (8.8.8+Sun/SMI-SVR4) id PAA06746; Tue, 20 Jul 1999 15:26:11 -0700 (PDT)
Message-ID: <006701bed2f8$fdc60cd0$[e-mail]>
From: "Todd S. Glassey" <[e-mail]>
To: "Denis Pinkas" <[e-mail]>, "Todd S. Glassey" <[e-mail]>
Cc: <[e-mail]>
References: <[e-mail]>	<[e-mail]> <[e-mail]> <[e-mail]> <002a01bed2c3$b1a48f00$[e-mail]> <[e-mail]>
Subject: Re: When is Timestamp applied?
Date: Tue, 20 Jul 1999 14:44:06 -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 5.00.2918.2701
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2918.2701

Thanks Denis -
----- Original Message -----
From: Denis Pinkas <[e-mail]>
To: Todd S. Glassey <[e-mail]>
Cc: <[e-mail]>
Sent: Tuesday, July 20, 1999 8:56 AM
Subject: Re: When is Timestamp applied?


>
> Todd,
>
> You have more talkative than I am. :-)

Yes, I do tend to rant a bit -

>
> You missed the point that a policy is always included in the token. That
policy
> specifies among other things the meaning of the time. We only have a time
> relative to UTC and already have a way to indicate its accuracy when
compared to
> UTC, whether it is minutes, seconds or subseconds.

I understand, what you are saying and agree partially, at least - that what
we really need is a set of common ploicy statement OIDS and the like to
minimize the structure and size of the TST itself. Still then it is the TST
that becomes the point of Interoperability rather than the routines that
made it.

>
> The basic mechanism also allows to have the two systems co-resident  *even
if
> this is not needed for PKIX usage*. I will allow some comments -  from
others -
> before proposing the slight change I indicated at the IETF meeting: the
use of 4
> parameters instead of 3.

Thats good.

>
> Regards,
>
> Denis

Todd



Received: from potassium.network-alchemy.com (Potassium.Network-Alchemy.COM [199.46.17.146]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id NAA13970 for <[e-mail]>; Tue, 20 Jul 1999 13:56:04 -0700 (PDT)
Received: from sodium.network-alchemy.com (localhost.Network-Alchemy.COM [127.0.0.1]) by potassium.network-alchemy.com (8.8.7/8.8.8) with ESMTP id NAA11319; Tue, 20 Jul 1999 13:58:04 -0700 (PDT) (envelope-from [e-mail])
Message-Id: <[e-mail]>
To: Vipul Gupta <[e-mail]>
cc: [e-mail], [e-mail], [e-mail], [e-mail]
Subject: Re: KISS for PKIX. (Was: RE:Asymmetric authentication (was ASN.1 vs XML which in turn was something else) 
In-reply-to: Your message of "Tue, 20 Jul 1999 10:48:48 PDT." <libSDtMail.9907201048.15393.vgupta@hsmpka> 
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <[e-mail]>
Date: Tue, 20 Jul 1999 13:58:04 -0700
From: Dan Harkins <[e-mail]>

On Tue, 20 Jul 1999 10:48:48 PDT Vipul Gupta wrote
> 
>   I don't quite see the motivation behind XAUTH if it is used in
>   conjunction with regular Main/Aggressive mode since each of those
>   modes provides mutual authentication. If the client has already
>   been authenticated in Main/Aggressive mode, what is the additional
>   functionality provided by XAUTH? Or is it that the pre-shared key
>   used in Main/Aggressive mode common to *all* clients (e.g. all 
>   corporate employees) and XAUTH is used to identify a particular
>   client?

  Exactly! I brought this point up back in May. If the IKE SA has been
authenticated properly then XAUTH doesn't buy you anything. You have
the double burden of supporting a PKI and some legacy database and
the user gets yet another dialog box asking for yet another passphrase.
I find it very hard to believe that this is what people are doing when
I hear that "customers want XAUTH".

  For XAUTH to provide anything the IKE SA is authenticated with some
shared key and then the "client" authenticates himself to the "server"
with the legacy method. The problem with this is that the IKE SA and
all the SKEYID state is not authenticated. Therefore all the keys in
the IPSec SAs are not authenticated. Depending on the legacy method
this can be open to a man-in-the-middle attack too.

  draft-ietf-ipsec-internet-key-00.txt is an April Fool's draft but
the security considerations is right on in this respect.

  Dan.




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 NAA13217 for <[e-mail]>; Tue, 20 Jul 1999 13:25:56 -0700 (PDT)
Received: from stingray.missi.ncsc.mil (root@localhost) by stingray.missi.ncsc.mil with ESMTP id QAA25219 for <[e-mail]>; Tue, 20 Jul 1999 16:27:41 -0400 (EDT)
Received: from missi.ncsc.mil (depot.missi.ncsc.mil [144.51.60.1]) by stingray.missi.ncsc.mil with ESMTP id QAA25215 for <[e-mail]>; Tue, 20 Jul 1999 16:27:41 -0400 (EDT)
Received: from ara.missi.ncsc.mil (ara.missi.ncsc.mil [144.51.58.9]) by missi.ncsc.mil (8.8.8/8.8.8) with ESMTP id QAA13677 for <[e-mail]>; Tue, 20 Jul 1999 16:27:39 -0400 (EDT)
Received: from ara.missi.ncsc.mil (ara.missi.ncsc.mil [144.51.58.9]) by ara.missi.ncsc.mil (8.9.1b+Sun/8.9.1) with SMTP id QAA11549 for <[e-mail]>; Tue, 20 Jul 1999 16:27:22 -0400 (EDT)
Message-Id: <[e-mail]>
Date: Tue, 20 Jul 1999 16:27:22 -0400 (EDT)
From: "David P. Kemp" <[e-mail]>
Reply-To: "David P. Kemp" <[e-mail]>
Subject: RE: KISS for PKIX
To: [e-mail]
MIME-Version: 1.0
Content-Type: TEXT/plain; charset=us-ascii
Content-MD5: 3hWgWDQEg3G01Grp0ZpRVA==
X-Mailer: dtmail 1.3.0 CDE Version 1.3 SunOS 5.7 sun4u sparc

Russ Housley already provided an answer to this, under the message
thread "Showing Nationality in Cert".  I agree with Russ' answer:

  > I recommend SubjectDirectoryAttribute.
  >
  > Russ

as amplified by Bill Burr (the SDN.801 'prbacInfo' attribute for
structured privileges) and Sandi Miklos (the ACP133 'nationality'
attribute for nationality). See:
  http://www.armadillo.huntsville.al.us/Fortezza_docs/missi2.html
  http://csrc.nist.gov/pki/twg/dir_docs/ACP133.zip

I would also quote from The Open Group's proposed authorization API:

     4.2 Authorization Credentials
   
     ... We understand that a standardized credential format is on
     the most wanted list of many vendors, organizations, and end users.
     However, even though intimately connected to the actual implementation
     of the decision functions, we believe that we can hide the internal
     credentials structure from the calling resource manager.

which suggests that in the absence of an International Standard or
IETF-standard credential structure, the best that we can hope for
is that commercial applications will be written to a standardized API,
enabling the use of authorization plug-ins to handle community-specific
credential formats.

Does anyone believe that the IETF can or should standardize an
authorization credential format?




> From: "Flanigan, Bill" <[e-mail]>
> 
> > Certificates
> > allow users to be aggregated (by nationality, by clearance, by explicit
> > privilege, etc) 
>
> Dave,
> 
> 	Interesting.  Which PKIX/X.509 extensions do you recommend for these
> attributes?  Especially for "nationality".
> 
> Bill




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 NAA12773 for <[e-mail]>; Tue, 20 Jul 1999 13:12:27 -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 WAA17186; Tue, 20 Jul 1999 22:14:03 +0200
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1 
Date: Tue, 20 Jul 1999 22:14:17 +0200
To: "Vickers, Randal R" <[e-mail]>, "PKIX Mailing List (E-mail)" <[e-mail]>
From: Stefan Santesson <[e-mail]>
Subject: Re: Showing Nationality in Cert
Cc: "Flanigan, Bill" <[e-mail]>, "Friedrichs, Paul" <[e-mail]>, "Nelson, Lee" <[e-mail]>, "Sam Schaen (E-mail)" <[e-mail]>, "Jamil Nimeh (E-mail)" <[e-mail]>
In-Reply-To: <[e-mail].d isa.mil>
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 NAA12775

This depends what you want to do.

If you just want to add citizenship as additional information to the
subject DN then I agree with Russ and Bill that you use
SubjectDirectoryAttribute.

If you, however wish to store a complete identity record, describing an
identity of a person, the Qualified Certificate draft has created a name
field placed in subjectAltName extension under OtherNames.

This field is named the PersonalData field and has defined attributes for
CountryOfCitizenship.

The complete list of defined attributes for this field is:

   countryName;
   givenName;
   surname;
   pseudonym;
   dNQualifier;
   dateOfBirth;
   placeOfBirth;
   gender;
   postalAddress;
   countryOfCitizenship; and
   countryOfResidence.

You can use any subset of these attributes. But in order to use this field,
the present attributes from this list must form a unique identity (in order
to satisfy overall requirements for the SubjAltName extension).

You can find the latest preliminary QC draft at:

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

A new draft will be submitted officially within 2 weeks.

After this the draft will got to last call (according to plan).


/Stefan



At 10:40 AM 7/17/99 -0400, Vickers, Randal R wrote:
>I work with the US DoD PKI engineers at the Defense Information Systems
>Agency. Requirements from the Assistant Secretary of Defense for C3I state
>that we must show citizenship or nationality (symantics) in the cert. My
>question is what extension  does anyone reccommend placing it in. We have
>looked at subjectDirectoryattribute and one of the extensions below
>subjectAlternatename. We are not locked into any one thing as long as it is
>standards based.
>	Thanks
>	Randal Vickers

-------------------------------------------------------------------
Stefan Santesson                <[e-mail]>
Accurata 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 rbhub100.chamb.disa.mil (rbhub100.chamb.disa.mil [209.22.120.23]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id LAA11237 for <[e-mail]>; Tue, 20 Jul 1999 11:55:53 -0700 (PDT)
Received: by rbhub100.chamb.disa.mil with Internet Mail Service (5.5.2448.0) id <PHWTSWS9>; Tue, 20 Jul 1999 14:57:29 -0400
Message-ID: <[e-mail]>
From: "Flanigan, Bill" <[e-mail]>
To: [e-mail]
Subject: RE: KISS for PKIX
Date: Tue, 20 Jul 1999 15:00:46 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2448.0)
Content-Type: text/plain

> ----------
> From: 	David P. Kemp[SMTP:[e-mail]]
> Reply To: 	David P. Kemp
> Sent: 	Tuesday, July 20, 1999 1:49 PM
> To: 	[e-mail]
> Subject: 	Re: KISS for PKIX
> 
[snip]

> Certificates
> allow users to be aggregated (by nationality, by clearance, by explicit
> privilege, etc) 
> 
Dave,

	Interesting.  Which PKIX/X.509 extensions do you recommend for these
attributes?  Especially for "nationality".

Bill


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 LAA10942 for <[e-mail]>; Tue, 20 Jul 1999 11:49:37 -0700 (PDT)
Received: from nma.com (pm02-38.sac.verio.net [209.162.64.57]) by tomcat.sac.verio.net (8.9.1a/8.9.1) with ESMTP id LAA16086; Tue, 20 Jul 1999 11:51:13 -0700 (PDT)
Message-ID: <[e-mail]>
Date: Tue, 20 Jul 1999 11:50:59 -0700
From: Ed Gerck <[e-mail]>
X-Mailer: Mozilla 4.51 [en] (Win98; I)
X-Accept-Language: en
MIME-Version: 1.0
To: [e-mail]
CC: "'[e-mail]'" <[e-mail]>, Nicholas Bohm <[e-mail]>
Subject: Simple answers, was Re: KISS for PKIX. (Was: RE: ASN.1 vs XML (used to  be RE: I-DACTION :draft-ietf-pkix-scvp- 00.txt))
References: <852567B0.0051BDDF.00@LNOTES5>
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 8bit

[NOTE: some answers below are IMO indeed simple, which does not mean
that they are easy  -- it just means that they are already decidable.  The posting
is long in order to provide context.]

[e-mail] wrote:

> There are legal issues to be resolved regarding limitations of liability
> and responsibilities of issuers, certificate authorities, subscribers, and
> relying parties. There are legal issues to be resolved regarding digital
> signatures. Last time I checked, about thirty states had enacted or were in
> the process of enacting digital signature laws. The federal government has
> a digital signature law pending.

There are some often neglected issues around this -- and which may simplify
very much what you are concerned about.

First, let me recall that the law (especially common law) is not very demanding
about what a "signature" is -- any scribble will do, usually, and also gestures can be
legally binding (think of an auction for example), as well as a simple statement such
as "OK, done!" if this is customary in the trade.  So, a "digital signature" can probably
enjoy considerable latitude and still be considered as a legal signature.  Where a
digital signature fails miserably, though, is in its absence of 'ceremony' (a legal
term that describes the formalities of signing a document) since no one can say
what happened over the wire, if the signer really read the document, if the document's
language was really understood, if there was really intent to sign, etc.

However, these problems were already encountered much before the Internet.
Indeed, the law already supports digital signatures in some countries that are based
on common law (UK for example), and many years ago, already.  Since telegraph
came around, and telex -- with the first needs to accept contractual agreements
over the wire.

So, new laws actually run into the danger of vacating previous laws and thus right
conflicts may easily ensue. Besides, as many new law proposals do in regard to
Internet matters do (e.g., the Utah digital signature law and the so-called
"Anti-cybersquatting law" being proposed in the US Senate), they usually run over
the requirements of due process in the good name of providing a remedy -- which
may create other problems (e.g., constitutional rights or simply lack of use; do you
know of any CA in Utah?) then the ones such laws try to solve .  For civil law
countries the situation may be somewhat less extensible, also because judicial decisions (jurisprudence) are not binding to lower courts in many such countries.

But, still, in any country (whether governed by common law or civil law, with possible
exceptions, also those governed by islamic law), a contract is the governing law
between the parties and they can tune it to their needs -- and, that is what contracts
are good for.  Thus, if a contract recognizes a digital signature as a signature, then the
law will very probably recognize it also as a signature (e.g., unless the contract itself is
legally invalid) -- including all cases that release the signer (use of deceit or unlawful
force being just two examples).

So, yes, this is simpler than it might seem at first sight. Digital signatures such as provided
by X.509 or PKIX can be legally used already today and in almost all countries -- as they
are -- but much will depend on the contract between the parties, which is IMO a good
thing since the technology is new and one needs to empower the users to choose what
they are already willing to accept for each case and risk.  In some states (e.g., California)
there are legal restrictions being enacted in this area which will further empower users.
Thus, this may well be a trend towards more user's rights to choose what technology
they are willing to use -- where digital cannot be the only choice.

> I was not basing my comment solely on
> legal issues regarding authentication of users. What is the limitation of
> liability of an issuer when a third party effects a transaction based on a
> certificate the issuer has issued, after the subscriber repudiates the
> transaction?

This is simple -- and all commercial CAs have answered this. As given by their CPS,
which is included by reference in the contract.  This is not like the famous case of the
Carbolic Ball Company, when liability was assumed at large. This is also not like a
check warranty, where the bank warrants the check to a certain  amount to any
recipient. This is a case where all liability at large is specifically denied and also
rendered legally unreachable even under third-party rights or consumer laws -- for the
simple and effective reason that all content is denied since a certificate is supplied 'as is',
which in UK law is called "endorsement sans recourse" and carries no liability at all.
This is a case where the CA  CPS is also supported by the Uniform Commercial
Code (US), which  declares that suppliers of data processing service are not liable
for providing incorrect results but just for using incorrect methods.  And this is where
Internet standards such as X.509 or PKIX are dearly useful to CAs, because such
standards provide the metric  for "correct methods" and thus free whomever uses
them  (e.g., CAs) from any liability stemming from the method's eventual design
problems and flaws -- hence some of the intrinsic tension in these debates.

> What if all three parties are in three different states or,
> worse, countries? Whose law applies?

This is simple. Any court can decide if jurisdiction applies -- this is not something
that the defendant, you or me can decide.  Thus, a Canadian company can be sued
in the US even if it has no branch office in the US. This is very common in  Europe
and a related case in the UK (involving a "telex signature") for a contract between
a company in the UK and another in Switzerland also dealt with the case of
different time zones to decide when a contract starts to be effective -- a question also
often neglected in regard to digital signatures.

And, even though three different countries may indeed be involved, this is also not
unusual in today's global economy.  Again, using an example from Europe, a resident
of Germany driving a car rent in  Spain but now on a road in France, hits a truck registered
in Italy but driven by a Belgian (who has an insurance from a Belgium company) due
to a  road defect. Who pays what? Who sues whom? Where? Each party decides
and the courts verify jurisdiction.

> What happens when a CA closes shop?

This is simple. Law already defines, for each country, what are the business
responsibilities -- and this is another issue where "Internet rules" seem to desire
to run over law  (e.g., as ICANN that wishes to define what happens if a TLD
registrar closes shop, but, unfortunately seems to open more cans of worms than the
one it wants to deal with).  What happens when a hospital closes shop?  Who is
responsible for post-surgery complications due to a fault caused by that hospital?
What happens when a plane manufacturer closes shop? Who is responsible for
the warranties and maintenance?  What happens when a bank closes shop? What
happens when a software company closes shop -- and, for example, you use
WordPerfect?

> Are the certificates valid or invalid?

This is simple.  They can be valid as long as the parties involved so decide.
The only needed functionality from the CA would be CRLs but since no CAs
warrant CRLs and no browsers consult them, this is anyway something that
the parties themselves had to deal with -- even when the CA was active.

> Who will relying parties consult if
> they need to verify that a certificate issued by the defunct CA was valid
> at a previous point in time for a disputed transaction?

This is simple. Themselves (e.g., by a suitable revocation policy they may agree upon
and that may include periodic reconfirmation for a next period of validity, possibly
also with insurance coverage according to their risks) or any third-party VA
(verification authority) that does not issue certificates but only serves as a type
of clearing house for certificates  (possibly, with the added benefit of insurance).

> For how many years
> must a CA keep expired certificates?

This is simple. Law already provides for this in each country.  For example, in
Germany, for at least 30 years.  The business responsibility of a CA goes over the
lifetime of  a certificate, and  for several reasons.  I have discussed this elsewhere
in the context of allowing e-commerce deals to outlive the certificate used to sign
them -- as they must in order to comply with sellers, bankers and consumer's rights,
warranty, etc.

> What responsibility does a CA have for
> providing for cessation of activities?

This is simple. As with any business, a CA can be terminated as the owners decide
or in cases provided by in law -- from whence different responsibilities also ensue for
each situation.

In this regard, there is IMO a very mistaken tendency of some "interest groups" in
the Internet, to consider the Internet as some sort of "public good"  that needs
special regulation or a division between "user" and "provider". The Internet is however,
not a public good (like a park or the radio wave space) -- the Internet is a network
of *private*  networks that willfully decide to collaborate, or not (in fact, there is value
in both behaviors; the first one in providing worldwide connectivity and the second
one in denying it for security purposes).  To better qualify  the issues at play here,
I quote a segment from another msg I wrote elsewhere:

--------------------------------------------------
The Internet is a global network of millions of private networks that voluntarily use
the Internet Protocol (IP) and the Transmission Control Protocol (TCP), or similar,
in order to support worldwide communication and services [cf. the “Internet” term
definition by the US Federal Network Council, in
http://www.fnc.gov/Internet_res.html].  The Internet is thus not a single entity but it
is a highly diffuse and complex system with many administrative and legal boundaries,
over which no entity has authority or control.  Further, on the Internet there is no
static division of roles between information providing and information accessing (as
in the case of TV, for example), so that anyone can become an information provider,
or access information, at any time – where either is called an “Internet user” or,
simply a “user”.

The Internet gives a user an open-ended worldwide audience, both in providing
content as well as in replying to queries – which are both qualified as an act of
providing “services”.   Services may also include sales, purchases, auctions or
any commercial activity including the sales of products to be physically and
non-physically (i.e., by the Internet itself) delivered.  The Internet does not
follow a “push” model in order to supply sales information (e.g., as radio, TV,
newspaper, mail lists, telemarketing calls, etc.), rather, it uses a “pull” model.
Once an Internet provider makes a service available on the Internet, it is
available to all Internet users worldwide and the provider cannot prevent that
service from entering (i.e., being “pulled by”) any community, jurisdiction or
country – i.e., the provider cannot prevent that information to be accessed by
a potential customer anywhere at anytime.
---------------------------------------------------

> I initially was led to believe PKI supported non-repudiation because this
> was one of the claims being made for it by its proponents.

Yes, and in fact terminology has not been very precise in this regard. What many
considered "non-repudiation" was actually just "cooperative non-repudiation" in
which the signer itself declares it will not repudiate (e.g., PKIX itself has defined
a so-called "non-repudiation bit" for this purpose) -- but this works only if the signer
does not repudiate ;-) and ... if the signer is the signer, if the signer understood what
was being signed, and so on...

> It was only
> after I started examining it more closely that I realized the claims were
> unsubstantiated.

They are, to a large extent. But, they do provide IMO for the needed
experimentation in order to allow at least some measure of non-repudiation
to be widely discussed and better understood (as we are doing, btw). And, it is
IMO one of the happy circumstances of this WG as well as other discussion
groups to bring these issues to the front.

Legally, anything can be repudiated -- but, technically, our task is to provide
evidences *both* ways: evidences to support non-repudiation and evidences to
support repudiation (even of an act that the other party may consider
non-repudiable).

> As long as one party can reasonably deny a fact, it is up
> to the other party to prove otherwise. If I receive a transaction and act
> on it, and the initiator subsequently denies the transaction, what do I
> have to authenticate the user and the data? I can't claim in court that I
> received and acted on a message because my server accepted it since it came
> with a valid certificate,  and because the signature and the message digest
> were valid, based on the certificate. I need to to be able to produce the
> original message, the digest, the signature, and the certificate, and be
> able to show that the validity checks all passed. I also need to know what
> algoritms were used. I need logs and audit records to prove the transaction
> came in. And I need all this possibly months or years later. But, most of
> all, I need to be able to demonstrate that I based my decision on
> reasonable assurance that the originator was who they claimed to be.

Yes, I agree with this. But in the majority of US states it can be much simpler --
in the case of  a tort there is no need to prove reasonable reliance but just
justified reliance.  The US Supreme Court has also decided that justified reliance
is the metric to be used for such cases.  The difference is that in justified reliance
(to give an example also cited by the US Supreme Court and cited in tort law), if
a seller tells me that a property is free to be bought, I do not need to check with
any notary even if checking with the notary is as easy as crossing the street.

> Which brings me to userids and passwords, and why I must use an application
> password even if I have issued a certificate.

Here, I disagree. These are two different authentication methods and there is as much
sense in requiring a certificate and a password as there is to require two passwords
or two certificates -- if done well it can provide for increased reliance or less risk, but
if not done well it can be actually worse.  But, there is no need.  Specially, to require a
password if a certificate is also required since a certificate provides more assurance
than a password -- and much more information (more on this, below).

> Passwords provide reasonable
> assurance to me that the originator is who they say they are; as long as
> the password is kept securely.

 But you don't know that. And, in a channel that is either uncertified or unencrypted (i.e., it
needs to be both), a password can be easily snatched.

> Dynamic passwords (two-factor authentication) provide even stronger assurance
> that this is so.

I am not sure what you mean by "dynamic passwords" but if you mean the use of a
trusted third-party in order to provide passwords, this is worse for a series of reasons
similar to those that speak against private-key escrow.

> What do I, as a verifier, have when a certificate is used? I have no reasonable
> assurance about the originator because I have not done anything to
> authenticate them.

This is not correct. You have a fresh challenge-response exchange and you have
the willingness of the other party to engage in such strong authentication. Besides,
you also have certification verification, both statically (issuer's signature) and
dynamically (validity, CRL). Further, you also have the certificate's usage policy (e.g.,
do not use above $ 50.00). And, there is much more -- you have the certificate's  issuance
date (i.e., how stale is it?), the issuer's name and issuance policy, subject contact data, etc.
Nothing of the sort is present in a password. And, last but not least, you expect the
corresponding certificate to have been accessed by a ... password.

> I don't know how secure the originator's PC is.

Ditto with a single password with no certificate.

> I don't know if they have told the browser to cache the private key password,

Ditto with a password  -- screen cache, additional software, password written on
the keyboard underside (very common), password written in a post-it note on the
display, password written in a file called "password.txt", etc.

> nor the strength of it.

Ditto with a single password with no certificate.

> I don't know if their PC will lock itself after a
> certain amount of inactivity.

Ditto with a single password with no certificate.

> I don't know who has access to the PC.

Ditto with a single password with no certificate.

> It is not difficult to copy certificate files from one system to another.

Ditto with a single password with no certificate.

> If the password is not strong enough, it probably would not be too difficult to
> crack it.

Ditto with a single password with no certificate.

> The certificate would be more reliable, for user authentication
> purposes, if I, as an issuer, could control usage of the private key and
> user authentication, or, minimally, if It is stored on some external
> device.

No, it would not. This would be "private-key escrow" and there is already IMO
wide consensus (even among its original proponents) that it creates far more
problems than the few it perhaps solves.  For example, you would still have
unsecured access of the key owner to that external device, collusion problems
to solve, privacy concerns, etc.

> At least this provides two-factor authentication.

No, it does not.  It is actually "a bad idea" (as commented above)

> I can't control
> how software vendors utilize certificates in their browser products, but I
> am at their mercy if I allow my application to run from their browser. If
> risk assessment requires me to use password security anyway, I need to be
> able to show significant incremental value added by certificates, given
> that the certifcate process places a large administrative burden around all
> this.

Agreed, and this is what I commented before -- security is counter to functionality.
Indeed, users can accept the hassle of more security but this depends a lot on
what this extra burden will provide as a benefit.  But, usually, if there is any problem
coping with the added procedures (or, a software/certificate glitch that renders it
unusable) I would expect the vast majority of users to revert to less secure methods
in order to close a deal -- which might be well exploited by an attacker that does a
denial-of-service attack on the secure server in order to lure the user into a weaker
authentication procedure.

> Granted, all this is less confusing if an originator is executing a
> transaction with the issuer of the cetificate, because the issuer could
> control the user authentication process.

Yes.

> But it becomes more complex when
> the certificate is used to execute a transaction with a third party. How
> can a bank verify a certificate and, more importantly, vouch for a
> transaction, if it can't be reasonably assured the customer is who they
> claim to be?

I disagree in this case -- since this case can easily be the case where the bank
itself is the issuer, which you also agree is "less confusing" (just above).  This,
for the bank, is not very much different from giving the customer a check guarantee
card and checks -- for which use the customer is responsible and liable, and which
banks do all the time.

The main difference here is that the bank is of course privy to the contract with
the user, which does not happen if the user certificate were issued by a third-party.


> All it has is a request for validation from the third party
> (merchant) and a message.

As above, not so -- the bank has a contract with the user.

> I am sure this will all be resolved over time, but at this point, I don't
> feel we are close enough.

Perhaps it is closer in some points, and farther in others, as I commented before.
But, there is no way to move ahead than to experiment and to provide room for
interdisciplinary discussions.

What is lacking though (and this is my motivation) are engineering models that
would make Internet certification and security development less of a happenstance
search as it is mostly done today, where YAPKIs (Yet Another PKI) upon YAPKIs
are proposed out of older network security models (that do not apply to the Internet,
which is a network of networks).

IMO, and as exemplified in other cases in the Internet such as the current domain
name issues, it is clear that there is also a tension between "legal effectiveness" and
"technical effectiveness" that makes any current solution not very satisfactory
when viewed under a balanced perspective.

Thus, it is also a happy objective of these discussions, with examples and
counterexamples, to help discern where the differences are and where
new solutions might be found. Which will, necessarily IMO, involve
compromises and a middle ground (e.g., between the currently prevailing CA
perspective versus relying-party's needs in regard to PKI) in  order to even
begin to find solutions.  For example, with a verifier-centric PKI.

Where, likewise, to learn to respect the diversity of opinions is IMO
the first rule to be followed by those that want to use debates and
public discussions as useful tools to mine the gold of truth.

Cheers,

Ed Gerck



Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id KAA09773 for <[e-mail]>; Tue, 20 Jul 1999 10:56:18 -0700 (PDT)
Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id KAA02609; Tue, 20 Jul 1999 10:58:02 -0700 (PDT)
Received: from hsmpka.eng.sun.com (hsmpka.Eng.Sun.COM [129.146.53.47]) by engmail4.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with SMTP id KAA26376; Tue, 20 Jul 1999 10:58:01 -0700 (PDT)
Received: from nobel by hsmpka.eng.sun.com (SMI-8.6/SMI-SVR4) id KAA01574; Tue, 20 Jul 1999 10:57:59 -0700
Date: Tue, 20 Jul 1999 10:48:48 -0700 (PDT)
From: Vipul Gupta <[e-mail]>
Reply-To: Vipul Gupta <[e-mail]>
Subject: RE: KISS for PKIX. (Was: RE:Asymmetric authentication (was ASN.1 vs XML which in turn was something else)
To: [e-mail], [e-mail]
Cc: [e-mail], [e-mail]
Message-ID: <libSDtMail.9907201048.15393.vgupta@hsmpka>
MIME-Version: 1.0
Content-Type: TEXT/plain; charset=us-ascii
Content-MD5: NdTMbAmTW4dHZWpKUJA3jQ==
X-Mailer: dtmail 1.1.0 CDE Version 1.1 SunOS 5.5.1 sun4u sparc

> >>On a related point, since IKE XAUTH is typically one-way (server
> >>authenticating client), secondary authentication does leave the problem of
> >>the server being spoofed with a compromised key!
> 
> >I thought it was one way the other way, i.e., server is authenticated to
> >client via a cert, but client uses only "legacy" auth to server.  If it
> >were the other way around it would be awful, as it would open a variety of
> >attacks against the legacy systems which could diminish their
> >effectiveness.  For example, S/Key is very vulnerable to active server
> >spoofing attacks.
> 
> I think there has been a proposal along those lines (asymmetric
> authentication), but the XAUTH draft does not cover that (I don't think). A
> normal symmetric Phase-1 authentication
> (pre-shared,signature,encrypted-nonce) is followed by a one-way secondary
> authentication via XAUTH.
> 
> Cheers, Steve.

  The "Hybrid Authentication" draft:
  
      draft-ietf-ipsec-isakmp-hybrid-auth-02.txt
      
  discusses asymmetric authentication (server is authenticated via
  a digital signature and the client uses OTP/token card etc). The
  hybrid authentication draft uses a slight modification of Main/Aggressive
  mode in which only the responder (server) is authenticated --
  the initiator sends only a hash rather than a signature. This is 
  immediately followed by an XAUTH exchange in which the client
  authenticates to the server using a "legacy" mechanism. This 
  approach is very similar to how web-based banking works -- the
  bank's server is authenticated via a signature during SSL negotiation
  and the user is authenticated via a password sent over HTTPS.
  
  I don't quite see the motivation behind XAUTH if it is used in
  conjunction with regular Main/Aggressive mode since each of those
  modes provides mutual authentication. If the client has already
  been authenticated in Main/Aggressive mode, what is the additional
  functionality provided by XAUTH? Or is it that the pre-shared key
  used in Main/Aggressive mode common to *all* clients (e.g. all 
  corporate employees) and XAUTH is used to identify a particular
  client?
  
  thanks,
  
  vipul
  



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 KAA09511 for <[e-mail]>; Tue, 20 Jul 1999 10:48:04 -0700 (PDT)
Received: from stingray.missi.ncsc.mil (root@localhost) by stingray.missi.ncsc.mil with ESMTP id NAA06449 for <[e-mail]>; Tue, 20 Jul 1999 13:49:51 -0400 (EDT)
Received: from missi.ncsc.mil (depot.missi.ncsc.mil [144.51.60.1]) by stingray.missi.ncsc.mil with ESMTP id NAA06445 for <[e-mail]>; Tue, 20 Jul 1999 13:49:50 -0400 (EDT)
Received: from ara.missi.ncsc.mil (ara.missi.ncsc.mil [144.51.58.9]) by missi.ncsc.mil (8.8.8/8.8.8) with ESMTP id NAA11798 for <[e-mail]>; Tue, 20 Jul 1999 13:49:48 -0400 (EDT)
Received: from ara.missi.ncsc.mil (ara.missi.ncsc.mil [144.51.58.9]) by ara.missi.ncsc.mil (8.9.1b+Sun/8.9.1) with SMTP id NAA05201 for <[e-mail]>; Tue, 20 Jul 1999 13:49:32 -0400 (EDT)
Message-Id: <[e-mail]>
Date: Tue, 20 Jul 1999 13:49:32 -0400 (EDT)
From: "David P. Kemp" <[e-mail]>
Reply-To: "David P. Kemp" <[e-mail]>
Subject: Re: KISS for PKIX
To: [e-mail]
MIME-Version: 1.0
Content-Type: TEXT/plain; charset=us-ascii
Content-MD5: /ORA/6UevYxm1eWosxD6Bg==
X-Mailer: dtmail 1.3.0 CDE Version 1.3 SunOS 5.7 sun4u sparc

No, the U.S. DoD would not contract or delegate its message
authentication services to another country, although it may choose to
accept another country's authentication of that country's personnel.
DoD policy is made at a high, centralized, level and communicated to
the end applications through the use of certificates.  The end
applications are responsible for policy enforcement (displaying "OK" or
"Not Authenticated" or "Not Authorized" to the user on a per-message
basis), and I don't see how this function could possibly be made to
work using an account database and certificate-less PKI.  Certificates
allow users to be aggregated (by nationality, by clearance, by explicit
privilege, etc) and allow decisions to be made on a distributed basis
without distributing the account record for every user to every
application.  Banks are free to assume that their central servers are
100% available.  The DoD does not have that luxury - operations must
continue among peers (full mode, not a degraded disconnected mode) even
if a centralized server or the pipes to it become unavailable.

  "Everything should be made as simple as possible,
     and no simpler."
                         -- Albert Einstein




> From: [e-mail]
> 
> re: authorization/authentication seperation
> 
> this is not in terms of technolgy or security seperation ... this is in terms of
> business interest seperation .... i.e. would the US dod contract to a another
> contry's  military organization to do the preliminary authentication on all US
> military SBU and top secret messages ... allowing them to  decide which messages
> are flagged as correctly authenticated and which message are flagged as
> non-authenticated??? this is further exasberated by the fact the US
> would be in direct conflict with with the country that has the military
> organization that has been selected to preprocess and authenticate US military
> traffic on behalf ot the US military.
> 
> There is all sorts of opportunity for fraud when the business interests of the
> organization doing authentication is in conflict with the business interests of
> the organization authorizing and executing the transactions.
> 
> one of the reasons for reg. E is that it is readily recognized that the merchant
> interests and the consumer interests do not coincide 100% ... furthermore ...
> merchant banks representing merchants and consumer banks representing consumers
> ... are also representing conflicting interests.



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 KAA08947 for <[e-mail]>; Tue, 20 Jul 1999 10:23:10 -0700 (PDT)
Received: from catalyst (catalyst.llnl.gov [128.115.223.61]) by poptop.llnl.gov (8.8.8/LLNL-3.0.2/pop.llnl.gov-5.1) with SMTP id KAA09882; Tue, 20 Jul 1999 10:24:56 -0700 (PDT)
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.3 (32)
Date: Tue, 20 Jul 1999 10:24:17 -0700
To: "Flanigan, Bill" <[e-mail]>
From: Tony Bartoletti <[e-mail]>
Subject: RE: KISS for PKIX
Cc: [e-mail]
In-Reply-To: <[e-mail] a.mil>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"

At 12:52 PM 7/20/99 -0400, Flanigan, Bill wrote:

>PKIX/X.509 IS SORT OF LIKE *HIGH DEFINITION* TELEVISION.  ITS BEEN AROUND
>(OR JUST AROUND THE CORNER) FOR QUITE A WHILE; LOOKS BETTER (EVEN THE
>LOW-DEFINITION VERSION) THAN WHAT WE HAVE NOW; BUT IT WILL BE YEARS BEFORE
>WE WILL HAVE IT FULLY AVAILABLE AND CAN AFFORD IT.  IN THE MEANTIME, THERE
>IS THIS *HDTV VACUUM.*  AND WE ALL KNOW ABOUT NATURE AND VACUUMS.

Thanks Bill.  This is a good analogy.

Another is the market for video game machines.  Long dominated by the lesser-
powered Super Nintendo (16-bit) and Playstation, along comes a far more powerful
graphics/game machine (3DO or something) touted to blow everyone away.  The only
problem:  It was so complicated and unfriendly for developers to program on, and
so expensive to purchase, only a very few games were ever made for it.  R.I.P.

___tony___
  

Tony Bartoletti                                             LL
IOWA Center                                              LL LL
Lawrence Livermore National Laboratory                LL LL LL
PO Box 808, L - 089                                   LL LL LL
Livermore, CA 94551-9900                              LL LL LLLLLLLL
phone: [phone]   fax: [phone]               LL LLLLLLLL
email: [e-mail]                                   LLLLLLLL


Received: from e1.ny.us.ibm.com (e1.ny.us.ibm.com [32.97.182.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id KAA08458 for <[e-mail]>; Tue, 20 Jul 1999 10:06:14 -0700 (PDT)
From: [e-mail]
Received: from northrelay02.pok.ibm.com (northrelay02.pok.ibm.com [9.117.200.22]) by e1.ny.us.ibm.com (8.9.3/8.9.3) with ESMTP id NAA47904; Tue, 20 Jul 1999 13:07:43 -0400
Received: from D51MTA05.pok.ibm.com (d51mta05.pok.ibm.com [9.117.200.33]) by northrelay02.pok.ibm.com (8.8.8m2/NCO v2.03) with SMTP id NAA87346; Tue, 20 Jul 1999 13:07:55 -0400
Received: by D51MTA05.pok.ibm.com(Lotus SMTP MTA v4.6.4  (830.2 3-23-1999))  id 852567B4.005E14A5 ; Tue, 20 Jul 1999 13:07:36 -0400
X-Lotus-FromDomain: IBMUS
To: Paul Koning <[e-mail]>
cc: [e-mail], [e-mail], [e-mail]
Message-ID: <[e-mail]>
Date: Tue, 20 Jul 1999 13:07:19 -0400
Subject: RE: When is Timestamp applied?
Mime-Version: 1.0
Content-type: text/plain; charset=us-ascii
Content-Disposition: inline

     On just one point, while "guaranteed average" latency is a fairly strange
concept, "sampled average" or "observed 98%" latency (the second one would
probably be two standard deviations rather than 98%) might be useful to a
relying party.

          Tom Gindin




Received: from rbhub101.chamb.disa.mil (rbhub101.chamb.disa.mil [209.22.120.24]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id JAA07642 for <[e-mail]>; Tue, 20 Jul 1999 09:47:06 -0700 (PDT)
Received: by rbhub101.chamb.disa.mil with Internet Mail Service (5.5.2448.0) id <PG2MC7Z6>; Tue, 20 Jul 1999 12:49:21 -0400
Message-ID: <[e-mail]>
From: "Flanigan, Bill" <[e-mail]>
To: "'David P. Kemp'" <[e-mail]>
Cc: [e-mail]
Subject: RE: KISS for PKIX
Date: Tue, 20 Jul 1999 12:52:06 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2448.0)
Content-Type: text/plain; charset="iso-8859-1"

Comments to comments to comments in CAPITALS below.

> ----------
> From: 	David P. Kemp[SMTP:[e-mail]]
> Reply To: 	David P. Kemp
> Sent: 	Friday, July 16, 1999 11:05 AM
> To: 	[e-mail]
> Subject: 	RE: KISS for PKIX
> 
> > From: "Flanigan, Bill" <[e-mail]>
> >
> > > I agree that these are precieved problems that hinder PKI deployment,
> but I
> > > also think that many of these are red herrings.  If I use certificates
> to
> > > authenticate users, in lieu of passwords, why are there any new legal
> > > issues?  Part of the problem is that people have been led to believe
> that a
> > > PKI must support non-repudiation, which generates a large number of
> valid,
> > > legal concerns. 
> > > 
> > BF:  Yes, Steve, and these legal issues go way beyond those related to a
> > password (in part because now there are a whole bunch of additional
> entities
> > involved).  They include the end entity (human and
> > human-responsible-for-machine), the registration agents (RA, LRA,
> > out-of-band delivery person/service), the CA (both the cert-server side
> and
> > the directory/repository side), the PKI administrators, etc.  Then there
> are
> > validity issues, CRL issues, repository time-and-security issues (e.g.,
> how
> > long must a cert or CRL remain in secure storage?  50 years?  150
> years?)
> > Aside from the CP and CPS, there are also Privacy Act issues.  Then
> there is
> > key escrow and recovery (yes, they are completely different and involve
> > different processes and entities).  I sometimes wonder if there are
> enough
> > lawyers on the planet to support all these up-and-coming PKI!
> >
> >    <snip>
> >
> > BF:  Steve, very few humans will read (or be able to understand if they
> > read) the CP.  The number of extensions in PKIX for machine-readable
> policy
> > is miniscule compared to what is needed--I would hazard a guess of 30-50
> for
> > the "typical" CP (and, of course, we still have the CPS which may or may
> not
> > have policy-related items not explicit in the CP plus CA cross
> certification
> > where policy mapping is a MUST).
> > 
> > BF:  P.S.  Being an early adopter of a PKI striving to be based on PKIX
> (and
> > commercial products) that goes beyond the pilot level is not fun.  It
> almost
> > seems like the standards were designed to make sure that early adopters
> > don't progress beyond the pilot stage!  The same could be said of
> commercial
> > products.  You must have very deep pockets to progress a PKI from
> > supporting, say, 100K certs to 5,000K certs.  And I am rapidly coming to
> the
> > conclusion (a conclusion I don't at all like) that if PKIX is to the PKI
> > flavor of choice for the planet, it must be substantially overhauled (or
> > replaced).
> 
> 
> Bill,
> 
> I must say I'm totally confused by this conclusion.  Of all the issues
> you list (the number of PKI entities, validity, archiving, Privacy Act,
> KR, CP and CPS), what single issue would be affected by a modification
> to the certificate structures defined by PKIX/X.509?
> 
DAVE, I CAN'T THINK OF A SINGLE ISSUE--THEY SEEM TOO INTER-RELATED.

> How would a change in the X.509 certificate format affect the number of
> CAs, RAs, etc required to run a non-pilot PKI?  How would it affect
> archive requirements?  How would a change in the syntax of the X.509
> CertificatePolicies extension affect (for the better) the legal/policy
> requirements of operating a large-scale PKI?  In short, what single
> modification to X.509, or what substantial overhaul or complete
> replacement, would make any of these issues the slightest bit easier to
> manage or resolve?
> 
AGAIN, I CAN'T THINK OF A SINGLE MODIFICATION THAT WOULD DO IT, BUT I
CAN--IF YOU FORCE ME TO-- THINK OF POTENTIAL REPLACEMENT CANDIDATES.  A
COMPLETE OVERHAUL IS WAY BEYOND THE SCOPE OF THIS THREAD--SO FAR.
PKIX/X.509 IS SORT OF LIKE *HIGH DEFINITION* TELEVISION.  ITS BEEN AROUND
(OR JUST AROUND THE CORNER) FOR QUITE A WHILE; LOOKS BETTER (EVEN THE
LOW-DEFINITION VERSION) THAN WHAT WE HAVE NOW; BUT IT WILL BE YEARS BEFORE
WE WILL HAVE IT FULLY AVAILABLE AND CAN AFFORD IT.  IN THE MEANTIME, THERE
IS THIS *HDTV VACUUM.*  AND WE ALL KNOW ABOUT NATURE AND VACUUMS.

> In other words, if PKIX needs replacement, what are the business
> requirements for whatever you would replace it with, and how would
> your new certificate structure satisfy those requirements to any
> greater extent than do PKIX certs?
> 
I THINK I'VE OUTLINED SOME OF THE *BUSINESS REQUIREMENTS* ALREADY.  I DON'T
HAVE A NEW CERT STRUCTURE PER SE.  STILL HOPING THAT PKIX/X.509 CAN BE MADE
SIMPLER SO THAT THE *I* IN PKI CAN BE TAMED BEFORE IT DEVOURS ALL RESOURCES
ON THE PLANET!  DAVE, IT'S FOLKS LIKE YOU WHO CAN HELP MAKE THIS
SIMPLIFICATION HAPPEN--IF YOU SO DESIRE. 

> > BF:  Yes, Steve, and these legal issues go way beyond those related to a
> > password (in part because now there are a whole bunch of additional
> entities
> > involved).
> 
> You are postulating a large-scale general-purpose PKI, and then arguing
> that the legal issues related to operating a PKI are caused by a set of
> data structures defined in X.509/PKIX.
> 
THESE *DATA STRUCTURES* ARE NOT HELPING TO IMPLEMENT BEYOND THE PILOT/DEMO
STAGE.  JUST LIKE HDTV--THE INFRASTRUCTURE NEEDED TO SUPPORT IT MAY RESULT
IN SELF-IMPOSED EXTINCTION.

> That does not address Steve's
> point that if you are *not* using PKIX to implement a PKI (with support
> for NR, archiving, etc), then these issues do not arise.
> 
WELL IF I AM NOT, LET ME TRY IT AGAIN:  QUITE SO.

> What if AOL issued X.509 certificates to all of its subscribers, and used
> those certificates solely as a replacement for passwords: the identity
> proofing is no more and no less than that required to get an AOL password
> today; no third-party issuers; no PKIX-specific policy statements other
> than statements which currently exist (acceptable-use, data privacy, etc).
> Please explain why these PKIX AOL login certs become any more unmanageable
> if the number of AOL subscribers grows from 100K to 5,000K?
> 
HMM, YOU'VE LOST ME HERE, DAVE.  I HAVE NO IDEA HOW AOL OPERATES.  BUT IF A
CERT IS USED SOLELY AS A REPLACEMENT FOR A PASSWORD, WHY BOTHER?  (YOU WOULD
PROBABLY HAVE TO TYPE IN A PASSWORD ANYWAY TO ACCESS THE CERT IN THE CLIENT
(OR TOKEN) AND ENABLE IT TO BE SENT TO THE SERVER.)  THIS SEEMS TO ME TO BE
A NEXT-TO-ZERO LEVEL OF ASSURANCE, WHICH IS NOT, I HOPE, WHAT PKIX IS ABOUT.
(WHY USE HDTV TO VIEW TRANSPARENCIES MEANT TO BE USED WITH A MAGIC LANTERN?)
AGAIN, DAVE, IT'S SMART FOLKS LIKE YOURSELF WHO CAN HELP MAKE THE *RIGHT*
MODIFICATIONS OR ENGINEER AN OVERHAUL/
REPLACEMENT AND THEREBY GREATLY AID EARLY (AND LATER?) ADOPTERS.  ONE WAY OR
THE OTHER, I FEEL THAT THIS *CHASM OF COMPLEXITY* BETWEEN PROTOCOL
DEVELOPERS AND ADOPTERS MUST BE BRIDGED FOR PKIX/X.509 TO BECOME THE PKI
FLAVOR OF CHOICE FOR THE PLANET.


Received: from mailgate.symbian.com (mailgate.symbian.com [194.129.1.246]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id JAA07325 for <[e-mail]>; Tue, 20 Jul 1999 09:41:17 -0700 (PDT)
From: [e-mail]
Received: from ccsmtpgate.symbian.com ([10.151.2.112] (may be forged)) by mailgate.symbian.com (2.5 Build 2640 (Berkeley 8.8.6)/8.8.4) with SMTP id RAA00261 for <[e-mail]>; Tue, 20 Jul 1999 17:38:57 +0100
Received: from ccMail by ccsmtpgate.symbian.com (ccMail Link to SMTP R8.20.00.25) id AA932489462; Tue, 20 Jul 1999 17:51:13 GMT
Message-Id: <[e-mail]>
X-Mailer: ccMail Link to SMTP R8.20.00.25
Date: Tue, 20 Jul 1999 17:37:12 GMT
To: <[e-mail]>
Subject: Name constraints questions
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Content-Description: "cc:Mail Note Part"

I'd be very grateful if someone could answer a couple of questions I have 
concerning the interpretation of the section of RFC 2459 which discusses 
name constraints (section 4.2.1.11).

My original understanding of name constraints was that for each of the possible 
name forms, we have a name in a certificate being constrained, and a constraint,
*of the same form*, being applied. This is reinforced by the statement that 
'Restrictions apply only when the specified name form is present'.

If the name being constrained is a URI, section 4.2.1.7 of RFC 2459 says 
that the URI must 'include a fully qualified domain name or IP Address as 
the host'. 

Can I safely assume that this domain name/IP address will be represented 
according to RFC 1738, section 3.1 (Common Internet Scheme Syntax)? If so, 
is there a reason why the spec does not say so (or even, specify that the 
whole URI should be in the form described in RFC 1738 section 3.1), and if 
not, how else might it be represented? 

Going back to section 4.2.1.11, it says that 'For URIs, the constraint 
applies to the host part of the name. The contraint may specify a host or a 
domain', and gives examples of constraints as 'foo.bar.com' and '.xyz.com'. 

These examples are obviously not URIs represented as per RFC 1738; they 
look a lot more like DNS names. Can I taken this to mean that constraints 
on URIs should be represented as DNS names as per RFC 1034 section 3.5 
(preferred name syntax) or IP address subnet masks as per RFC 1519 (though 
it says nothing at all about the latter here)? Again, if so, is there a reason 
why the spec doesn't say so, and if not, what are the possibilities for their 
representation?

Sorry if this stuff sounds really picky, but I'm keen to get it right. 

Thanks very much for any help

Will




Received: from dfw7-1.relay.mail.uu.net (dfw7-1.relay.mail.uu.net [199.171.54.106]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id IAA03678 for <[e-mail]>; Tue, 20 Jul 1999 08:59:53 -0700 (PDT)
Received: from xedia.com by dfw7sosrv11.alter.net with SMTP  (peer crosschecked as: madway.xedia.com [198.202.232.199]) id QQgyrw15464; Tue, 20 Jul 1999 16:01:11 GMT
Received: from tonga.xedia.com by xedia.com (4.1/SMI-4.1) id AA04594; Tue, 20 Jul 99 11:59:52 EDT
Received: by tonga.xedia.com (SMI-8.6/SMI-SVR4) id MAA19580; Tue, 20 Jul 1999 12:01:02 -0400
Date: Tue, 20 Jul 1999 12:01:02 -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: When is Timestamp applied?
References: <[e-mail]>
X-Mailer: VM 6.34 under 20.3 "Vatican City" XEmacs  Lucid

>>>>> "Michael" == Michael Zolotarev <[e-mail]> writes:

 >> So no additional information is needed INSIDE the
 >> token. ... However, the *security policy* of the TSA may be to
 >> indicate that the time that will be placed inside the TST is the
 >> time of arrival in the FIFO or the time associated with the crypto
 >> operation. This may make a few seconds of difference. When the
 >> time is critical, some users may choose to use a TSA using the
 >> time of arrival rather than the time of time stamping.

 Michael> How about a more generic qualifier: Guaranteed Maximum
 Michael> Latency (GML). Or may be a GAL (Average).  Independent of
 Michael> any particular crypto technology, scheduling and other
 Michael> 'why-would-a-user-care' implementation details.  It is just
 Michael> a value (millis?) - easy to change when a TSA changes its
 Michael> implementation (from FIFO to LIFO, for instance).

"Guaranteed average" doesn't seem terribly meaningful, but "guaranteed 
maximum" makes sense.

Denis, it doesn't matter whether you want to put "time of arrival
rather than time of stamping" into a policy.  It isn't a testable
property.  Putting it into a policy doesn't make it a testable
property.  It is flat out improper for a protocol spec to mandate
properties that are not observable on the external interfaces of an
implementation. 

To put it differently: if I build a TSA, and there is a requirement
that the TSA must timestamp packets on arrival, how would you build a
conformance test that verifies this?  I say it cannot be done.  You
have no way to disprove my assertion that it conforms unless I stamp a 
time earlier than arrival on the wire, or later than departure on the
wire of the reply.  But that property proves "time of signing" just as 
well.

I'd have no problem with a statement like "since the purpose of the
time stamp is to demonstrate existence of data before a certain time,
it is recommended that a TSA apply a time stamp that is close to (but
not earlier than) the arrival time of the request".  Or you could
introduce Michael's GML and recommend that GML should be minimized.

	paul


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 IAA03368 for <[e-mail]>; Tue, 20 Jul 1999 08:55:11 -0700 (PDT)
Received: from bull.net (frcls6118.frcl.bull.fr [129.182.109.213]) by clbull.frcl.bull.fr (8.9.1a/8.9.1) with ESMTP id RAA20652; Tue, 20 Jul 1999 17:48:13 +0200
Message-ID: <[e-mail]>
Date: Tue, 20 Jul 1999 17:56:49 +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: [e-mail]
Subject: Re: When is Timestamp applied?
References: <[e-mail]>	<[e-mail]> <[e-mail]> <[e-mail]> <002a01bed2c3$b1a48f00$[e-mail]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit

Todd,

You have more talkative than I am. :-)

You missed the point that a policy is always included in the token. That policy
specifies among other things the meaning of the time. We only have a time
relative to UTC and already have a way to indicate its accuracy when compared to
UTC, whether it is minutes, seconds or subseconds.

The basic mechanism also allows to have the two systems co-resident  *even if
this is not needed for PKIX usage*. I will allow some comments -  from others -
before proposing the slight change I indicated at the IETF meeting: the use of 4
parameters instead of 3.

Regards,

Denis



> Actually Denis,
>
> ----- Original Message -----
> From: Denis Pinkas <[e-mail]>
> To: Paul Koning <[e-mail]>
> Cc: <[e-mail]>
> Sent: Tuesday, July 20, 1999 12:57 AM
> Subject: Re: When is Timestamp applied?
>
> > Paul,
> >
> > The token provides an evidence that a datum existed AT LEAST at the time
> > included in the token.
>
> So which "time" is this. The "time" that the source_system says the event
> occured, the time the event reached this TSA or what? - and if the token
> (TST) is totally free-form and there is no standard as to what the event is
> supposed to look like, why then would I need a standard for the process of
> making something that was as such, a moving target?
>
> Why would I care about the protocol of creating a mark if the mark itself is
> not the standardized entity?
>
> >
> > So no additional information is needed INSIDE the token...
>
> My problem here is that there is no published end use model for the
> services - to my knowledge, so how do you know what is actually needed in
> the token structure itself? - The answer is that you dont. It seems to me
> that what I am hearing is that the process is what is being standardized
> here, and that is not the right goal in my book.
>
> >However, the
> > *security policy* of the TSA may be to indicate that the time that will be
> > placed inside the TST is the time of arrival in the FIFO or the time
> > associated with the crypto operation.
>
> You're still arguing here about what or which time to stick in the token and
> the policy that attaches to it.
>
> Yes, the security policy about the system and how it works must be available
> to the person using the system or the person(s) validating events through
> it. Depending on the Token Size constraints, this data may or may not want
> to be included in the token itself, likewise if not included in the token
> structure, it will need to be available by reference externally through some
> facility.
>
> > This may make a few seconds of
> > difference. When the time is critical,
>
> Ah Ha, here we are talking about "when time is crititical" which gets us
> back to that we need better precision or at least user definable precision
> in the token structure itself. And by the way, it sounds like there are
> several different token structures now by your comments, So where then is
> the interoperability between the different methods and how is it
> accomplished?
>
> >some users may choose to use a TSA
> > using the time of arrival rather than the time of time stamping.
>
> Much to everyone's chagrin I am sure, let me reiterate that the keys to
> timestamping are the token structure that is provided, the method of getting
> the "time data" into the process, and the system that applies the
> "timesense" to the event structure in question to create the token itself.
> The system should be built around proving the business issues of the
> "proofing models" not the technical ones. This, IMHO, is clearly a system
> where PKI has experienced too much streroidial input. The system that has
> been developed is a very elegent mechanism that applies limited resolution
> time to an event and stamps it remotely.
>
> My feeling is that the big win here in timestamping is that we standardize
> tokens and the mechanisms/processes to get secure time into systems. Let the
> auditors prove that the tools we build actually build and manage the tokens
> as we intend them too. This is the win here.
>
> >
> > We may need to indicate this in the draft.
>
> What the draft really needs is a new edition that takes into account that
> the actual system producing the timestamps could easily be either SW or HW
> in nature, and that it can run in the same context as the server that is
> dependant on its auditing. It needs at the very least a mechanism to specify
> whether the event in question is marked with absolute or relative time, and
> what the timebase resolution is, if its absolute. It also needs to policy of
> the event etched into the token so that it can be freerenced externally or
> later as a stand-alone event proof or atleast referencable. Perhaps a
> standard set of POLICY OIDS would work here for that.
>
> If we don't take into account the end use models, then what "it" is, is a
> distributed, network segragated, model for applying a limited resolution
> timestamp, from an undefined timesource to an object that its trust model
> cannot prove. What is usually referred to as the qunitiessential Trusted
> Third Party System -  ala "It works becuase I said it did - nee-ner,
> nee-ner, nee-ner".
>
> Am I wrong or what have I missed here?
>
> >
> > Denis
> >
> >
>
> You know - from my perspective - the reality is that more and more of what
> we work on here in PKIX is not "network" or distributed computing dependant
> and rather is OS Context dependant, or based in how and what trust and
> assurance models are, but since there is so little difference between the
> OS' of today and the underlying networking or virtual system environment, it
> is easy to see how the confusion occured.
>
> Todd



Received: from sjc3-1.relay.mail.uu.net (sjc3-1.relay.mail.uu.net [199.171.54.122]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id IAA02825 for <[e-mail]>; Tue, 20 Jul 1999 08:49:18 -0700 (PDT)
Received: from xedia.com by sjc3sosrv11.alter.net with SMTP  (peer crosschecked as: madway.xedia.com [198.202.232.199]) id QQgyrv06229; Tue, 20 Jul 1999 15:51:24 GMT
Received: from tonga.xedia.com by xedia.com (4.1/SMI-4.1) id AA04467; Tue, 20 Jul 99 11:49:42 EDT
Received: by tonga.xedia.com (SMI-8.6/SMI-SVR4) id LAA19574; Tue, 20 Jul 1999 11:50:58 -0400
Date: Tue, 20 Jul 1999 11:50:58 -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: When is Timestamp applied?
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <001801bed2bd$6eb748f0$[e-mail]>
X-Mailer: VM 6.34 under 20.3 "Vatican City" XEmacs  Lucid

>>>>> "Todd" == Todd S Glassey <[e-mail]> writes:

 Todd> Can we use another term besides Datum. It confuses the issue of
 Todd> Datum Corporation being a timing services supplier here in
 Todd> PKIX.

So?  Datum is the singular of data.  The fact that a company picks a
standard English language word as its corporate name is not a good
reason to avoid using that word.  Especially since hundreds or
thousands of company names or product trademarks are ordinary words,
it is neither desirable nor even possible to attempt to avoid using
those words.

	paul


Received: from www.meridianus.com (209.249.223.21.has.no.reverse [209.249.223.21] (may be forged)) by mail.proper.com (8.8.8/8.8.5) with ESMTP id IAA00517 for <[e-mail]>; Tue, 20 Jul 1999 08:11:50 -0700 (PDT)
Received: from PC1 by www.meridianus.com (8.8.8+Sun/SMI-SVR4) id JAA06494; Tue, 20 Jul 1999 09:04:44 -0700 (PDT)
Message-ID: <002a01bed2c3$b1a48f00$[e-mail]>
From: "Todd S. Glassey" <[e-mail]>
To: "Denis Pinkas" <[e-mail]>, "Paul Koning" <[e-mail]>
Cc: <[e-mail]>
References: <[e-mail]>	<[e-mail]> <[e-mail]> <[e-mail]>
Subject: Re: When is Timestamp applied?
Date: Tue, 20 Jul 1999 08:22:35 -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 5.00.2918.2701
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2918.2701

Actually Denis,

----- Original Message -----
From: Denis Pinkas <[e-mail]>
To: Paul Koning <[e-mail]>
Cc: <[e-mail]>
Sent: Tuesday, July 20, 1999 12:57 AM
Subject: Re: When is Timestamp applied?


> Paul,
>
> The token provides an evidence that a datum existed AT LEAST at the time
> included in the token.

So which "time" is this. The "time" that the source_system says the event
occured, the time the event reached this TSA or what? - and if the token
(TST) is totally free-form and there is no standard as to what the event is
supposed to look like, why then would I need a standard for the process of
making something that was as such, a moving target?

Why would I care about the protocol of creating a mark if the mark itself is
not the standardized entity?

>
> So no additional information is needed INSIDE the token...

My problem here is that there is no published end use model for the
services - to my knowledge, so how do you know what is actually needed in
the token structure itself? - The answer is that you dont. It seems to me
that what I am hearing is that the process is what is being standardized
here, and that is not the right goal in my book.

>However, the
> *security policy* of the TSA may be to indicate that the time that will be
> placed inside the TST is the time of arrival in the FIFO or the time
> associated with the crypto operation.

You're still arguing here about what or which time to stick in the token and
the policy that attaches to it.

Yes, the security policy about the system and how it works must be available
to the person using the system or the person(s) validating events through
it. Depending on the Token Size constraints, this data may or may not want
to be included in the token itself, likewise if not included in the token
structure, it will need to be available by reference externally through some
facility.

> This may make a few seconds of
> difference. When the time is critical,

Ah Ha, here we are talking about "when time is crititical" which gets us
back to that we need better precision or at least user definable precision
in the token structure itself. And by the way, it sounds like there are
several different token structures now by your comments, So where then is
the interoperability between the different methods and how is it
accomplished?

>some users may choose to use a TSA
> using the time of arrival rather than the time of time stamping.

Much to everyone's chagrin I am sure, let me reiterate that the keys to
timestamping are the token structure that is provided, the method of getting
the "time data" into the process, and the system that applies the
"timesense" to the event structure in question to create the token itself.
The system should be built around proving the business issues of the
"proofing models" not the technical ones. This, IMHO, is clearly a system
where PKI has experienced too much streroidial input. The system that has
been developed is a very elegent mechanism that applies limited resolution
time to an event and stamps it remotely.

My feeling is that the big win here in timestamping is that we standardize
tokens and the mechanisms/processes to get secure time into systems. Let the
auditors prove that the tools we build actually build and manage the tokens
as we intend them too. This is the win here.

>
> We may need to indicate this in the draft.

What the draft really needs is a new edition that takes into account that
the actual system producing the timestamps could easily be either SW or HW
in nature, and that it can run in the same context as the server that is
dependant on its auditing. It needs at the very least a mechanism to specify
whether the event in question is marked with absolute or relative time, and
what the timebase resolution is, if its absolute. It also needs to policy of
the event etched into the token so that it can be freerenced externally or
later as a stand-alone event proof or atleast referencable. Perhaps a
standard set of POLICY OIDS would work here for that.

If we don't take into account the end use models, then what "it" is, is a
distributed, network segragated, model for applying a limited resolution
timestamp, from an undefined timesource to an object that its trust model
cannot prove. What is usually referred to as the qunitiessential Trusted
Third Party System -  ala "It works becuase I said it did - nee-ner,
nee-ner, nee-ner".

Am I wrong or what have I missed here?

>
> Denis
>
>



You know - from my perspective - the reality is that more and more of what
we work on here in PKIX is not "network" or distributed computing dependant
and rather is OS Context dependant, or based in how and what trust and
assurance models are, but since there is so little difference between the
OS' of today and the underlying networking or virtual system environment, it
is easy to see how the confusion occured.

Todd




Received: from www.meridianus.com (209.249.223.22.has.no.reverse [209.249.223.22] (may be forged)) by mail.proper.com (8.8.8/8.8.5) with ESMTP id HAA28583 for <[e-mail]>; Tue, 20 Jul 1999 07:51:28 -0700 (PDT)
Received: from PC1 by www.meridianus.com (8.8.8+Sun/SMI-SVR4) id IAA06463; Tue, 20 Jul 1999 08:19:54 -0700 (PDT)
Message-ID: <001801bed2bd$6eb748f0$[e-mail]>
From: "Todd S. Glassey" <[e-mail]>
To: "Denis Pinkas" <[e-mail]>, "Paul Koning" <[e-mail]>
Cc: <[e-mail]>
References: <[e-mail]>	<[e-mail]> <[e-mail]> <[e-mail]>
Subject: Re: When is Timestamp applied?
Date: Tue, 20 Jul 1999 07:37:45 -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 5.00.2918.2701
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2918.2701

Can we use another term besides Datum. It confuses the issue of Datum
Corporation being a timing services supplier here in PKIX.

Todd

----- Original Message -----
From: Denis Pinkas <[e-mail]>
To: Paul Koning <[e-mail]>
Cc: <[e-mail]>
Sent: Tuesday, July 20, 1999 12:57 AM
Subject: Re: When is Timestamp applied?


> Paul,
>
> The token provides an evidence that a datum existed AT LEAST at the time
> included in the token.
>
> So no additional information is needed INSIDE the token. ... However, the
> *security policy* of the TSA may be to indicate that the time that will be
> placed inside the TST is the time of arrival in the FIFO or the time
> associated with the crypto operation. This may make a few seconds of
> difference. When the time is critical, some users may choose to use a TSA
> using the time of arrival rather than the time of time stamping.
>
> We may need to indicate this in the draft.
>
> Denis
>
>
> > >>>>> Sean Turner <[e-mail]> writes:
> >
> >  > Mike, I'd actually be in favor of just saying that the time
> >  > indicated in the timestamp should be when the TSA signed the
> >  > data.
> >
> >  > Michael Zolotarev wrote:
> >
> >  >> Denis, Sean,
> >  >>
> >  >> Does a person who is not currently in Oslo have a right to say :)?
> >  >>
> >  >> >From the practical point of view, I do not see much benefit in
> >  >> putting extra detail into the stamp. What the time stamp is for?
> >  >> To provide an evidence that a datum existed AT LEAST at certain
> >  >> time....
> >
> > I think Mike's argument implies that constraining it to be "when the
> > TSA signed the data" is not necessary.
> >
> > Another argument: protocol standards and protocol conformance
> > statements should be assertions about EXTERNALLY OBSERVABLE behavior.
> > This is a fundamental rule of standards design.
> >
> > The definition Mike proposed has that property.  The one Sean proposed
> > does not.
> >
> > If I put a black box containing a TSA implementation in a lab and
> > send requests at it, I can verify that the time stamps returned are
> > not earlier than the request arrival time, and not later than the
> > response transmit time, but I have no way of knowing more than that.
> > Therefore the spec cannot and must not imply any more than that.
> >
> >         paul
>
>



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 CAA10483 for <[e-mail]>; Tue, 20 Jul 1999 02:11:16 -0700 (PDT)
Received: from sydneymail1.baltimore.com.au (sydneymail1.jp.zergo.com.au [192.168.71.5]) by stargate.zergo.com.au (8.9.1/8.8.7) with ESMTP id TAA12552; Tue, 20 Jul 1999 19:14:50 +1000
Received: by sydneymail1.jp.zergo.com.au with Internet Mail Service (5.5.2448.0) id <P2YDLXRM>; Tue, 20 Jul 1999 19:09:23 +1000
Message-ID: <[e-mail]>
From: Michael Zolotarev <[e-mail]>
To: Denis Pinkas <[e-mail]>, Paul Koning <[e-mail]>
Cc: [e-mail]
Subject: RE: When is Timestamp applied?
Date: Tue, 20 Jul 1999 19:09:23 +1000
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2448.0)
Content-Type: text/plain; charset="iso-8859-1"

>So no additional information is needed INSIDE the token. ... However, the
>*security policy* of the TSA may be to indicate that the time that will be
>placed inside the TST is the time of arrival in the FIFO or the time
>associated with the crypto operation. This may make a few seconds of
>difference. When the time is critical, some users may choose to use a TSA
>using the time of arrival rather than the time of time stamping.

How about a more generic qualifier: Guaranteed Maximum Latency (GML). Or may be a GAL (Average).
Independent of any particular crypto technology, scheduling and other 'why-would-a-user-care' implementation details.
It is just a value (millis?) - easy to change when a TSA changes its implementation (from FIFO to LIFO, for instance).

cheers
MichaelZ


Received: from ctron-dnm.ctron.com ([e-mail] [12.25.1.120]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id BAA09499 for <[e-mail]>; Tue, 20 Jul 1999 01:35:07 -0700 (PDT)
Received: (from uucp@localhost) by ctron-dnm.ctron.com (8.8.7/8.8.7) id EAA08300; Tue, 20 Jul 1999 04:39:07 -0400 (EDT)
Received: from roc-mail2.ctron.com(134.141.72.230) by ctron-dnm.ctron.com via smap (4.1) id xma008286; Tue, 20 Jul 99 04:39:03 -0400
Received: from new-exc1.ctron.com (NEW-EXC1 [134.141.200.123]) by roc-mail2.ctron.com (8.8.7/8.8.7) with ESMTP id EAA18650; Tue, 20 Jul 1999 04:42:43 -0400 (EDT)
Received: by new-exc1.ctron.com with Internet Mail Service (5.5.2448.0) id <38L709LJ>; Tue, 20 Jul 1999 09:36:47 +0100
Message-ID: <[e-mail]>
From: "Waters, Stephen" <[e-mail]>
To: Stephen Kent <[e-mail]>
Cc: [e-mail], [e-mail]
Subject: RE: KISS for PKIX. (Was: RE: ASN.1 vs XML (used to be RE: I-D ACT ION :draft-ietf-pkix-scvp- 00.txt))
Date: Tue, 20 Jul 1999 09:36:44 +0100
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2448.0)
Content-Type: text/plain; charset="iso-8859-1"

>>On a related point, since IKE XAUTH is typically one-way (server
>>authenticating client), secondary authentication does leave the problem of
>>the server being spoofed with a compromised key!

>I thought it was one way the other way, i.e., server is authenticated to
>client via a cert, but client uses only "legacy" auth to server.  If it
>were the other way around it would be awful, as it would open a variety of
>attacks against the legacy systems which could diminish their
>effectiveness.  For example, S/Key is very vulnerable to active server
>spoofing attacks.

I think there has been a proposal along those lines (asymmetric
authentication), but the XAUTH draft does not cover that (I don't think). A
normal symmetric Phase-1 authentication
(pre-shared,signature,encrypted-nonce) is followed by a one-way secondary
authentication via XAUTH.

Cheers, Steve.


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 AAA08317 for <[e-mail]>; Tue, 20 Jul 1999 00:56:05 -0700 (PDT)
Received: from bull.net (frcls6118.frcl.bull.fr [129.182.109.213]) by clbull.frcl.bull.fr (8.9.1a/8.9.1) with ESMTP id JAA20286; Tue, 20 Jul 1999 09:49:01 +0200
Message-ID: <[e-mail]>
Date: Tue, 20 Jul 1999 09:57:37 +0200
From: Denis Pinkas <[e-mail]>
Organization: Bull
X-Mailer: Mozilla 4.06 [fr] (Win95; I)
MIME-Version: 1.0
To: Paul Koning <[e-mail]>
CC: [e-mail]
Subject: Re: When is Timestamp applied?
References: <[e-mail]> <[e-mail]> <[e-mail]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit

Paul,

The token provides an evidence that a datum existed AT LEAST at the time
included in the token.

So no additional information is needed INSIDE the token. ... However, the
*security policy* of the TSA may be to indicate that the time that will be
placed inside the TST is the time of arrival in the FIFO or the time
associated with the crypto operation. This may make a few seconds of
difference. When the time is critical, some users may choose to use a TSA
using the time of arrival rather than the time of time stamping.

We may need to indicate this in the draft.

Denis


> >>>>> Sean Turner <[e-mail]> writes:
>
>  > Mike, I'd actually be in favor of just saying that the time
>  > indicated in the timestamp should be when the TSA signed the
>  > data.
>
>  > Michael Zolotarev wrote:
>
>  >> Denis, Sean,
>  >>
>  >> Does a person who is not currently in Oslo have a right to say :)?
>  >>
>  >> >From the practical point of view, I do not see much benefit in
>  >> putting extra detail into the stamp. What the time stamp is for?
>  >> To provide an evidence that a datum existed AT LEAST at certain
>  >> time....
>
> I think Mike's argument implies that constraining it to be "when the
> TSA signed the data" is not necessary.
>
> Another argument: protocol standards and protocol conformance
> statements should be assertions about EXTERNALLY OBSERVABLE behavior.
> This is a fundamental rule of standards design.
>
> The definition Mike proposed has that property.  The one Sean proposed
> does not.
>
> If I put a black box containing a TSA implementation in a lab and
> send requests at it, I can verify that the time stamps returned are
> not earlier than the request arrival time, and not later than the
> response transmit time, but I have no way of knowing more than that.
> Therefore the spec cannot and must not imply any more than that.
>
>         paul



Received: from mail-ewr-3.pilot.net (mail-ewr-3.pilot.net [206.98.230.17]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id SAA19753 for <[e-mail]>; Mon, 19 Jul 1999 18:16:05 -0700 (PDT)
From: [e-mail]
Received: from mailgw.firstdata.com ([204.48.27.166]) by mail-ewr-3.pilot.net (Pilot/8.8.8) with ESMTP id VAA26190; Mon, 19 Jul 1999 21:17:49 -0400 (EDT)
Received: from lnsunr02.firstdata.com (lnsunr02.firstdata.com [192.168.247.16]) by mailgw.firstdata.com with SMTP id VAA13258; Mon, 19 Jul 1999 21:17:48 -0400 (EDT)
Received: by lnsunr02.firstdata.com(Lotus SMTP MTA v4.6.4  (830.2 3-23-1999))  id 852567B4.0006A885 ; Mon, 19 Jul 1999 21:12:43 -0400
X-Lotus-FromDomain: FDC
To: Stephen Kent <[e-mail]>
cc: [e-mail], [e-mail], [e-mail]
Message-ID: <[e-mail]>
Date: Mon, 19 Jul 1999 18:16:19 -0700
Subject: RE: KISS for PKIX. (Was: RE: ASN.1 vs XML (used to be RE: I-D 	 	 ACTION :draft-ietf-pkix-scvp- 00.txt))
Mime-Version: 1.0
Content-type: text/plain; charset=us-ascii
Content-Disposition: inline

re: subcontracting out authentication;

no, the example was to indicate that the seperation of authentication and
authorization isn't within the same business unit ... but totally different
organizations ... the characterization was that authentication and authorization
has been seperated so far into different factions where the authentication
function has actually was really (as silly as it may seem) subcontracted out to
the opposing forrce ... i.e. DOD didn't subcontract DOD certificate authorities
to USPS or some government agency ... but actually subcontracted out DOD
internal authentication function to a foreign government ... one that is even at
odds with the interests of the US government. The degree of the seperation of
authentication and authorization is to the extent totally differenent
business/company/country has been asked to do all of your authentication ...
even tho the agency in question doesn't have your best interests at heart (and
in fact may have interests that are improved if false authentication occurs).

It is like in the home business ... they typically recommend that a buyer get
their own lawyer and not expect the seller's lawyer and/or seller's real estate
agent to act in the buyer's interest ...


re: account records

while account records are frequently motivated by financially related matters
... they aren't unique to the financial industry. nearly every business interest
operates off account records. within the pervue of the IETF ... every ISP
offering internet service for sale operates off account records (amount of
service, quality of service, whether it is currently active or not, has this
month's bill been paid, etc). So I wouldn't want to characterize that only
financial institutions are uniquely motivated as having account record driven
business.




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 QAA15180 for <[e-mail]>; Mon, 19 Jul 1999 16:24: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 TAA25059; Mon, 19 Jul 1999 19:26:13 -0400 (EDT)
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
X-Sender: [e-mail]
Message-Id: <v04020a02b3b9648bbc3b@[128.89.0.110]>
In-Reply-To: <[e-mail]>
Date: Mon, 19 Jul 1999 19:28:41 -0400
To: [e-mail]
From: Stephen Kent <[e-mail]>
Subject: RE: KISS for PKIX. (Was: RE: ASN.1 vs XML (used to be RE: I-D 	 	 ACTION :draft-ietf-pkix-scvp- 00.txt))
Cc: [e-mail]

Lynn,

>.... there are actually well-studied scenerios where if merchants
>&/or merchant representatives turn on certain flags claiming that
>they have done various authentication processes ... they pay
>less money .... and they turn on the flag on all transactions
>regardless of whether they performed the authentication function.
>
>that is also one of the scenerios that contribute to merchant fraud
>
>substitute the word relationship for trust ... and talk about relationship
>propogation/representation and relationship context. for simple minded
>relationship/trust contexts that are relatively static ... letter's of
>introduction, certificates, etc ... can attest to the relationship/trust
>on each
>transaction w/o having to resort to any additional information
>
>trust/relationships that have a more complex context in the business world
>tends
>to resort to account records to represent real-time and/or information
>aggregation regarding the relationship/trust.
>
>in a relying-party-only certificate ... there is no propogation and/or
>external
>representation of that relationship/trust-factor. it typically reflects the
>account number. if the transaction is signed and the account number has to be
>hit in any case ... then a certificate is redundant and superfulous for those
>transactions. The account record represents the complex relationship/trust
>context that is needed to span multiple transactions.

As I described in a recent message, there are ways to preserve the account
number ID model and to carry a capability that confers authorization, thus
avoiding the need to check the ACL.  Now, if we worry only about financial
applications where an account record must be touched because we need to
check current balances, etc., your argument may be better, but the IETF has
a broader application concern than the ANSI X9 committee, which does focus
on finance.

Steve


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 QAA15003 for <[e-mail]>; Mon, 19 Jul 1999 16:22:24 -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 TAA24951; Mon, 19 Jul 1999 19:24:03 -0400 (EDT)
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
X-Sender: [e-mail]
Message-Id: <v04020a01b3b962a84a59@[128.89.0.110]>
In-Reply-To: <[e-mail]>
Date: Mon, 19 Jul 1999 19:25:44 -0400
To: "Waters, Stephen" <[e-mail]>
From: Stephen Kent <[e-mail]>
Subject: RE: KISS for PKIX. (Was: RE: ASN.1 vs XML (used to be RE: I-D ACT ION :draft-ietf-pkix-scvp- 00.txt))
Cc: [e-mail], [e-mail]

Stephen,

>>>5) My PC uses one of the approaches above, but once authentication via the
>>>certificate is complete, enforces a secondary authentication. This
>>>authentication is under the control of the server, and so can't be cracked
>>>off-line. If an attack is mounted, the VPN server will receive 'warnings'
>in
>>>the form of authentication failures (I hope).  The authentication
>>>information provided in this secondary phase MUST NOT be part of the VPN
>>>client's automatic function.
>
>>What exaclty is an example fo the second phase authentication here?  If one
>>assumes use of a SecurID card, for example, why not postulate that it was
>>tolen at the same time as the smart card?  If a password is used, then we
>>have all the usual password-related problems that make guessing possible.
>
>I like 'guessing possible', provided that the guessing can only be done
>on-line. If I am using a SecureID card, for example, the card itself can not
>help you know when you have the right pin number, only the server in the
>head office knows which pin number goes with which card.  To crack-in using
>IKE XAUTH, I need to go on-line and interface directly with the server. If
>the server get suspicious that I'm guessing, it can take action.  I agree
>that badly chosen passwords/pin-numbers will be a problem, but apart from
>that, it does give the server a way of keeping a secret that is not (should
>not) be recorded in any place other than the users head, and the server's
>database.

Depends on what form of SecurID card you are talking about.  Most of these
cards do not require a PIN to actuve them; the PIN is just used as a static
password to help counter the threat posed by theft of a card.  Under that
model there are various ways I may have acquired the PIN, especially if I
can spoof the server (which would not happen if one authenticated the
server prior to transmitting the PIN).  In more traditional SecurID usage,
the passive wiretapper has access to valid challenge/response pairs and
would be able to search the PIN space even when the PIN is entered into the
card as part of activation.  So, under the best circumstances, yes, the use
of a card like SecuID and a full fledged 2-way authenticated IPsec SA is an
improvement, as you noted.

>If 'normal' smartcards can be dismantled and interrogated as you suggest,
>then that is a worry that secondary authentication seems to help with.
>Maybe 'normal' Smartcards are not enough?  We need super, FIP-140 level-4
>type devices that can defend themselves against all manor of creepy
>crawlies?  Fortezza?

Fortezza is not evaluated vs. 140-1, but it would not meet level 4, or
probably even level 3 criteria, for a variety of reasons, some of which are
orthogonal to the discussion here.

>On a related point, since IKE XAUTH is typically one-way (server
>authenticating client), secondary authentication does leave the problem of
>the server being spoofed with a compromised key!

I thought it was one way the other way, i.e., server is authenticated to
client via a cert, but client uses only "legacy" auth to server.  If it
were the other way around it would be awful, as it would open a variety of
attacks against the legacy systems which could diminish their
effectiveness.  For example, S/Key is very vulnerable to active server
spoofing attacks.

Steve


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 QAA14652 for <[e-mail]>; Mon, 19 Jul 1999 16:05: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 TAA24069; Mon, 19 Jul 1999 19:07:38 -0400 (EDT)
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
X-Sender: [e-mail]
Message-Id: <v04020a04b3b95eebe104@[128.89.0.110]>
In-Reply-To: <[e-mail]>
Date: Mon, 19 Jul 1999 19:06:21 -0400
To: [e-mail]
From: Stephen Kent <[e-mail]>
Subject: Re: KISS for PKIX. (Was: RE: ASN.1 vs XML (used to be RE: I-D 	 	 ACTION :draft-ietf-pkix-scvp- 00.txt))
Cc: "'[e-mail]'" <[e-mail]>

Lynn,

>I've talked to a number of people that have deployed IPSEC &/or VPN in various
>business critical environments and view IPSEC as not fullfilling their
>needs ...
>but are using it because the software is easily available at the moment
>... and
>then cribbing code in behind the IPSEC handshake
>to do real-time account lookup as the final arbirtrator.

OK.  I know lots of folks who do not do that, based on our experience as a
provider of managed VPN services.  Perhaps we just deal with different sets
of folks :-).

>as to previous comments as to "open" versis "closed" ... most of these are
>looking at "open" in the sense that they have a drive towards industry
>standards, ISO, IETF, ANSI, etc ... but they are closed in the current
>certificate scenerios in that a series of transactions all occur within the
>context of a global trust infrastructure typically represented by a number of
>real-time status, information, and/or aggregations embodied in an account
>record
>(as opposed to a trust infrastructure that is atomic on a transaction by
>transaction basis and covered within the context of information
>represented by a
>certificate manufactored at some point in the past).

I think that the persistant use of the phrase "account record" is telling
here.  Not all users of this technology are financial institutions, or
folks doing anything with financial accounts per se.  I tend to look at
these technologies from an application neutral perspective.

>it isn't that the cert-less transactions are lacking in trust parameters
>... it
>is that the atomic nature of cert trust propogation may not represent the
>business requirements of a series of transactions (although may be entirely
>appropriate for trust propogation in these environments involving sign-up &/or
>enrollment transactions).

As I said in one of my other messages, I think the phrase "trust
propogation" is generally a misnomer here.

Steve


Received: from mail-ewr-3.pilot.net (mail-ewr-3.pilot.net [206.98.230.17]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id PAA14016 for <[e-mail]>; Mon, 19 Jul 1999 15:28:35 -0700 (PDT)
From: [e-mail]
Received: from mailgw.firstdata.com ([204.48.27.166]) by mail-ewr-3.pilot.net (Pilot/8.8.8) with ESMTP id SAA13233; Mon, 19 Jul 1999 18:30:19 -0400 (EDT)
Received: from lnsunr02.firstdata.com (lnsunr02.firstdata.com [192.168.247.16]) by mailgw.firstdata.com with SMTP id SAA09700; Mon, 19 Jul 1999 18:30:17 -0400 (EDT)
Received: by lnsunr02.firstdata.com(Lotus SMTP MTA v4.6.4  (830.2 3-23-1999))  id 852567B3.007B29EB ; Mon, 19 Jul 1999 18:25:16 -0400
X-Lotus-FromDomain: FDC
To: Stephen Kent <[e-mail]>
cc: [e-mail], [e-mail], [e-mail]
Message-ID: <[e-mail]>
Date: Mon, 19 Jul 1999 15:29:04 -0700
Subject: RE: KISS for PKIX. (Was: RE: ASN.1 vs XML (used to be RE: I-D 	 	 ACTION :draft-ietf-pkix-scvp- 00.txt))
Mime-Version: 1.0
Content-type: text/plain; charset=us-ascii
Content-Disposition: inline

.... there are actually well-studied scenerios where if merchants
&/or merchant representatives turn on certain flags claiming that
they have done various authentication processes ... they pay
less money .... and they turn on the flag on all transactions
regardless of whether they performed the authentication function.

that is also one of the scenerios that contribute to merchant fraud

substitute the word relationship for trust ... and talk about relationship
propogation/representation and relationship context. for simple minded
relationship/trust contexts that are relatively static ... letter's of
introduction, certificates, etc ... can attest to the relationship/trust on each
transaction w/o having to resort to any additional information

trust/relationships that have a more complex context in the business world tends
to resort to account records to represent real-time and/or information
aggregation regarding the relationship/trust.

in a relying-party-only certificate ... there is no propogation and/or external
representation of that relationship/trust-factor. it typically reflects the
account number. if the transaction is signed and the account number has to be
hit in any case ... then a certificate is redundant and superfulous for those
transactions. The account record represents the complex relationship/trust
context that is needed to span multiple transactions.




Received: from ctron-dnm.ctron.com ([e-mail] [12.25.1.120]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id PAA13537 for <[e-mail]>; Mon, 19 Jul 1999 15:16:03 -0700 (PDT)
Received: (from uucp@localhost) by ctron-dnm.ctron.com (8.8.7/8.8.7) id SAA00543; Mon, 19 Jul 1999 18:19:59 -0400 (EDT)
Received: from roc-mail2.ctron.com(134.141.72.230) by ctron-dnm.ctron.com via smap (4.1) id xma000534; Mon, 19 Jul 99 18:19:39 -0400
Received: from new-exc1.ctron.com (NEW-EXC1 [134.141.200.123]) by roc-mail2.ctron.com (8.8.7/8.8.7) with ESMTP id SAA11137; Mon, 19 Jul 1999 18:23:19 -0400 (EDT)
Received: by new-exc1.ctron.com with Internet Mail Service (5.5.2448.0) id <38L7084A>; Mon, 19 Jul 1999 23:17:24 +0100
Message-ID: <[e-mail]>
From: "Waters, Stephen" <[e-mail]>
To: Stephen Kent <[e-mail]>
Cc: [e-mail], [e-mail]
Subject: RE: KISS for PKIX. (Was: RE: ASN.1 vs XML (used to be RE: I-D ACT ION :draft-ietf-pkix-scvp- 00.txt))
Date: Mon, 19 Jul 1999 23:17:23 +0100
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2448.0)
Content-Type: text/plain; charset="iso-8859-1"

>>5) My PC uses one of the approaches above, but once authentication via the
>>certificate is complete, enforces a secondary authentication. This
>>authentication is under the control of the server, and so can't be cracked
>>off-line. If an attack is mounted, the VPN server will receive 'warnings'
in
>>the form of authentication failures (I hope).  The authentication
>>information provided in this secondary phase MUST NOT be part of the VPN
>>client's automatic function.

>What exaclty is an example fo the second phase authentication here?  If one
>assumes use of a SecurID card, for example, why not postulate that it was
>tolen at the same time as the smart card?  If a password is used, then we
>have all the usual password-related problems that make guessing possible.

I like 'guessing possible', provided that the guessing can only be done
on-line. If I am using a SecureID card, for example, the card itself can not
help you know when you have the right pin number, only the server in the
head office knows which pin number goes with which card.  To crack-in using
IKE XAUTH, I need to go on-line and interface directly with the server. If
the server get suspicious that I'm guessing, it can take action.  I agree
that badly chosen passwords/pin-numbers will be a problem, but apart from
that, it does give the server a way of keeping a secret that is not (should
not) be recorded in any place other than the users head, and the server's
database.

If 'normal' smartcards can be dismantled and interrogated as you suggest,
then that is a worry that secondary authentication seems to help with.
Maybe 'normal' Smartcards are not enough?  We need super, FIP-140 level-4
type devices that can defend themselves against all manor of creepy
crawlies?  Fortezza?

On a related point, since IKE XAUTH is typically one-way (server
authenticating client), secondary authentication does leave the problem of
the server being spoofed with a compromised key!



Steve. 


Received: from mail-ewr-3.pilot.net (mail-ewr-3.pilot.net [206.98.230.17]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id PAA13161 for <[e-mail]>; Mon, 19 Jul 1999 15:15:26 -0700 (PDT)
From: [e-mail]
Received: from mailgw.firstdata.com ([204.48.27.166]) by mail-ewr-3.pilot.net (Pilot/8.8.8) with ESMTP id SAA11620; Mon, 19 Jul 1999 18:17:07 -0400 (EDT)
Received: from lnsunr02.firstdata.com (lnsunr02.firstdata.com [192.168.247.16]) by mailgw.firstdata.com with SMTP id SAA09268; Mon, 19 Jul 1999 18:16:33 -0400 (EDT)
Received: by lnsunr02.firstdata.com(Lotus SMTP MTA v4.6.4  (830.2 3-23-1999))  id 852567B3.0079E778 ; Mon, 19 Jul 1999 18:11:31 -0400
X-Lotus-FromDomain: FDC
To: Stephen Kent <[e-mail]>
cc: "'[e-mail]'" <[e-mail]>
Message-ID: <[e-mail]>
Date: Mon, 19 Jul 1999 14:29:16 -0700
Subject: Re: KISS for PKIX. (Was: RE: ASN.1 vs XML (used to be RE: I-D 	 	 ACTION :draft-ietf-pkix-scvp- 00.txt))
Mime-Version: 1.0
Content-type: text/plain; charset=us-ascii
Content-Disposition: inline

I've talked to a number of people that have deployed IPSEC &/or VPN in various
business critical environments and view IPSEC as not fullfilling their needs ...
but are using it because the software is easily available at the moment ... and
then cribbing code in behind the IPSEC handshake
to do real-time account lookup as the final arbirtrator.

as to previous comments as to "open" versis "closed" ... most of these are
looking at "open" in the sense that they have a drive towards industry
standards, ISO, IETF, ANSI, etc ... but they are closed in the current
certificate scenerios in that a series of transactions all occur within the
context of a global trust infrastructure typically represented by a number of
real-time status, information, and/or aggregations embodied in an account record
(as opposed to a trust infrastructure that is atomic on a transaction by
transaction basis and covered within the context of information represented by a
certificate manufactored at some point in the past).

it isn't that the cert-less transactions are lacking in trust parameters ... it
is that the atomic nature of cert trust propogation may not represent the
business requirements of a series of transactions (although may be entirely
appropriate for trust propogation in these environments involving sign-up &/or
enrollment transactions).







Stephen Kent <[e-mail]> on 07/19/99 01:16:02 PM

To:   Lynn Wheeler/CA/FDMS/FDC@FDC
cc:   "'[e-mail]'" <[e-mail]>
Subject:  Re: KISS for PKIX. (Was: RE: ASN.1 vs XML (used to be RE: I-D
           ACTION :draft-ietf-pkix-scvp- 00.txt))




Lynn,

>a cert-less approach is relatively trivial to apply across the
>corporate electronic environment. register the employees public
>key in a RADIUS administrative data-base (i.e. RA by any other
>name) and use RADIUS protocol for all corporate authentications
>i.e. existing RADIUS based authentication and straight forward
>apply RADIUS protocol to future applications.

How exactly does this match with the details of existing, standard
protocols, such as IPsec, SSL, and S/MIME?  I can imagine a scheme by which
this could be made to work, but since these protocols have explicit
provisions for cert (usually X.509 cert) transfer or retrieval., I suspect
that the suggestion you make here is not really compatible with standards
compliant protocols of this sort.  I agree that one might choose to build a
custom application on the basis of cert-less operation.

>This even works in SSL and other types of environments. Consumer's
>authentication at the server is done with RADIUS account-base.

SSL has a specific mechanism for using a client cert for authentication as
part of the SSL handshake.  I don't see how this matches your example,
above.  I think that a browser and server, without modification, will not
be able to take advantage of a client private key based on your description.

>This doesn't say anything about eliminating web server comfort
>certificates ... for setting up SSL sessions ... just addresses issue
>of authenticating individuals in environments that are really account-base
>operation.

We agree that server certs are not the issue here.  But, the standard way
for a cleint to use a public key for auth is as part of the SSL exchange.
Are you proposing a new, independent user auth operation?  If so, then I
agree one could do that, perhaps with a plug-in, but we already have a
means of using a client cert for authentication in SSL, and we have tens of
millions of browsers that are capable of generating key pairs, requesting
certs, and passing certs to servers in a standard fashion.  So, why change?

<snip>

>as alwas choice is:
>
>1) fully defined, identity certificate

What is this, exactly?

>2) relying-party-only certificate where the transaction has to
>hit the account record.
>
>either all the necessary information is in the certificate or the
>certificate contains only enuf information to be able to get
>to the account record. if the operation has to hit the accound
>record anyway ... then it is trivial to show that the certificate
>is redundant and superfulous.
>
>it wasn't intended to be a red herring statement ... it was a
>statement that is was one or the other ... either all the necessary
>information is in the certificate (in which case the certificate can
>represent a privacy and/or security issue) or the information is
>in an account record (in which case the certificate is superfulous
>and redundant).
>
>this of course, doesn't apply to saying that the merchant comfort
>certificates (using for setting up SSL sessions) are unnecessary
>... but that almost all cases that the certificates for employees
>and individuals ... tend to either 1) divulge privacy/confidential
>information or 2) have to hit an account record.

A third choice is to send along an attribute cert (or to embed
authorization data in the public key cert), which is how capability system
is supposed to work (as per the last 25 years of infosec).  This avoids the
need to "hit the account" record, unless access is based on a dynamic
parameter, e.g., for credit card transactions, which is not characteristic
of most intra=net access controls.  In this fashion the organization can
include whetever form of )local) ID it deems appropriate, and the user can
pass in whatever form of authorization credentials are appropriate for the
resource being accessed, avoiding the need for an account record access.
The resource manager does need to check for revocation of the certs in
question, but that may be a cacheable list not requiring the same sort of
off-server access that folks may be envisioning.

Another observation is that the databases for public key management and
authorization management may differ.  If so, a cert-less design might
require two different accesses, one for the public key and one for the
authorization data.  Also, one needs to protect the public key while in
storage and, if the server for the public key is not local to the resource
being access, during  transmission, which is just what a certificate does!
So, cert-less use of public keys does have some possible downsides,
depending on the context.

Steve






Received: from mail-ewr-3.pilot.net (mail-ewr-3.pilot.net [206.98.230.17]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id PAA13166 for <[e-mail]>; Mon, 19 Jul 1999 15:15:26 -0700 (PDT)
From: [e-mail]
Received: from mailgw.firstdata.com ([204.48.27.166]) by mail-ewr-3.pilot.net (Pilot/8.8.8) with ESMTP id SAA11619; Mon, 19 Jul 1999 18:17:07 -0400 (EDT)
Received: from lnsunr02.firstdata.com (lnsunr02.firstdata.com [192.168.247.16]) by mailgw.firstdata.com with SMTP id SAA09276; Mon, 19 Jul 1999 18:16:44 -0400 (EDT)
Received: by lnsunr02.firstdata.com(Lotus SMTP MTA v4.6.4  (830.2 3-23-1999))  id 852567B3.0079ECE8 ; Mon, 19 Jul 1999 18:11:45 -0400
X-Lotus-FromDomain: FDC
To: Stephen Kent <[e-mail]>
cc: "'[e-mail]'" <[e-mail]>
Message-ID: <[e-mail]>
Date: Mon, 19 Jul 1999 14:50:33 -0700
Subject: Re: KISS for PKIX. (Was: RE: ASN.1 vs XML (used to be RE: I-D 	 	 ACTION :draft-ietf-pkix-scvp- 00.txt))
Mime-Version: 1.0
Content-type: text/plain; charset=us-ascii
Content-Disposition: inline

re: authorization/authentication seperation

this is not in terms of technolgy or security seperation ... this is in terms of
business interest seperation .... i.e. would the US dod contract to a another
contry's  military organization to do the preliminary authentication on all US
military SBU and top secret messages ... allowing them to  decide which messages
are flagged as correctly authenticated and which message are flagged as
non-authenticated??? this is further exasberated by the fact the US
would be in direct conflict with with the country that has the military
organization that has been selected to preprocess and authenticate US military
traffic on behalf ot the US military.

There is all sorts of opportunity for fraud when the business interests of the
organization doing authentication is in conflict with the business interests of
the organization authorizing and executing the transactions.

one of the reasons for reg. E is that it is readily recognized that the merchant
interests and the consumer interests do not coincide 100% ... furthermore ...
merchant banks representing merchants and consumer banks representing consumers
... are also representing conflicting interests.




Received: from mail-ewr-3.pilot.net (mail-ewr-3.pilot.net [206.98.230.17]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id PAA13140 for <[e-mail]>; Mon, 19 Jul 1999 15:15:25 -0700 (PDT)
From: [e-mail]
Received: from mailgw.firstdata.com ([204.48.27.166]) by mail-ewr-3.pilot.net (Pilot/8.8.8) with ESMTP id SAA11616; Mon, 19 Jul 1999 18:17:07 -0400 (EDT)
Received: from lnsunr02.firstdata.com (lnsunr02.firstdata.com [192.168.247.16]) by mailgw.firstdata.com with SMTP id SAA09282; Mon, 19 Jul 1999 18:16:46 -0400 (EDT)
Received: by lnsunr02.firstdata.com(Lotus SMTP MTA v4.6.4  (830.2 3-23-1999))  id 852567B3.0079EA48 ; Mon, 19 Jul 1999 18:11:38 -0400
X-Lotus-FromDomain: FDC
To: Stephen Kent <[e-mail]>
cc: "'[e-mail]'" <[e-mail]>
Message-ID: <[e-mail]>
Date: Mon, 19 Jul 1999 14:32:24 -0700
Subject: Re: KISS for PKIX. (Was: RE: ASN.1 vs XML (used to be RE: I-D 	 	 ACTION :draft-ietf-pkix-scvp- 00.txt))
Mime-Version: 1.0
Content-type: text/plain; charset=us-ascii
Content-Disposition: inline

I've talked to a number of people that have deployed IPSEC &/or VPN in various
business critical environments and view IPSEC as not fullfilling their needs ...
but are using it because the software is easily available at the moment ... and
then cribbing code in behind the IPSEC handshake
to do real-time account lookup as the real arbritrator. If I was asked the
question (about how it fits within existing standards) at the fall, '94 IETF
meeting when the VPN/IPSEC work item was introduce to the router work group ...
I would say that it requires enhancement/development of standards to meet
business requirements.

as to previous comments as to "open" versis "closed" ... most of these are
looking at "open" in the sense that they have a drive towards industry
standards, ISO, IETF, ANSI, etc ... but they are closed in the current
certificate scenerios in that a series of transactions all occur within the
context of a global trust infrastructure typically represented by a number of
real-time status, information, and/or aggregations embodied in an account record
(as opposed to a trust infrastructure that is atomic on a transaction by
transaction basis and covered within the context of information represented by a
certificate manufactored at some point in the past).

it isn't that the cert-less transactions are lacking in trust parameters ... it
is that the atomic nature of cert trust propogation may not represent the
business requirements of a series of transactions (although may be entirely
appropriate for trust propogation in these environments involving sign-up &/or
enrollment transactions).







Stephen Kent <[e-mail]> on 07/19/99 01:16:02 PM

To:   Lynn Wheeler/CA/FDMS/FDC@FDC
cc:   "'[e-mail]'" <[e-mail]>
Subject:  Re: KISS for PKIX. (Was: RE: ASN.1 vs XML (used to be RE: I-D
           ACTION :draft-ietf-pkix-scvp- 00.txt))




Lynn,

>a cert-less approach is relatively trivial to apply across the
>corporate electronic environment. register the employees public
>key in a RADIUS administrative data-base (i.e. RA by any other
>name) and use RADIUS protocol for all corporate authentications
>i.e. existing RADIUS based authentication and straight forward
>apply RADIUS protocol to future applications.

How exactly does this match with the details of existing, standard
protocols, such as IPsec, SSL, and S/MIME?  I can imagine a scheme by which
this could be made to work, but since these protocols have explicit
provisions for cert (usually X.509 cert) transfer or retrieval., I suspect
that the suggestion you make here is not really compatible with standards
compliant protocols of this sort.  I agree that one might choose to build a
custom application on the basis of cert-less operation.

>This even works in SSL and other types of environments. Consumer's
>authentication at the server is done with RADIUS account-base.

SSL has a specific mechanism for using a client cert for authentication as
part of the SSL handshake.  I don't see how this matches your example,
above.  I think that a browser and server, without modification, will not
be able to take advantage of a client private key based on your description.

>This doesn't say anything about eliminating web server comfort
>certificates ... for setting up SSL sessions ... just addresses issue
>of authenticating individuals in environments that are really account-base
>operation.

We agree that server certs are not the issue here.  But, the standard way
for a cleint to use a public key for auth is as part of the SSL exchange.
Are you proposing a new, independent user auth operation?  If so, then I
agree one could do that, perhaps with a plug-in, but we already have a
means of using a client cert for authentication in SSL, and we have tens of
millions of browsers that are capable of generating key pairs, requesting
certs, and passing certs to servers in a standard fashion.  So, why change?

<snip>

>as alwas choice is:
>
>1) fully defined, identity certificate

What is this, exactly?

>2) relying-party-only certificate where the transaction has to
>hit the account record.
>
>either all the necessary information is in the certificate or the
>certificate contains only enuf information to be able to get
>to the account record. if the operation has to hit the accound
>record anyway ... then it is trivial to show that the certificate
>is redundant and superfulous.
>
>it wasn't intended to be a red herring statement ... it was a
>statement that is was one or the other ... either all the necessary
>information is in the certificate (in which case the certificate can
>represent a privacy and/or security issue) or the information is
>in an account record (in which case the certificate is superfulous
>and redundant).
>
>this of course, doesn't apply to saying that the merchant comfort
>certificates (using for setting up SSL sessions) are unnecessary
>... but that almost all cases that the certificates for employees
>and individuals ... tend to either 1) divulge privacy/confidential
>information or 2) have to hit an account record.

A third choice is to send along an attribute cert (or to embed
authorization data in the public key cert), which is how capability system
is supposed to work (as per the last 25 years of infosec).  This avoids the
need to "hit the account" record, unless access is based on a dynamic
parameter, e.g., for credit card transactions, which is not characteristic
of most intra=net access controls.  In this fashion the organization can
include whetever form of )local) ID it deems appropriate, and the user can
pass in whatever form of authorization credentials are appropriate for the
resource being accessed, avoiding the need for an account record access.
The resource manager does need to check for revocation of the certs in
question, but that may be a cacheable list not requiring the same sort of
off-server access that folks may be envisioning.

Another observation is that the databases for public key management and
authorization management may differ.  If so, a cert-less design might
require two different accesses, one for the public key and one for the
authorization data.  Also, one needs to protect the public key while in
storage and, if the server for the public key is not local to the resource
being access, during  transmission, which is just what a certificate does!
So, cert-less use of public keys does have some possible downsides,
depending on the context.

Steve






Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id PAA12886 for <[e-mail]>; Mon, 19 Jul 1999 15:10:44 -0700 (PDT)
Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id PAA29628; Mon, 19 Jul 1999 15:12:22 -0700 (PDT)
Received: from hsmpka.eng.sun.com (hsmpka.Eng.Sun.COM [129.146.65.47]) by engmail2.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with SMTP id PAA21225; Mon, 19 Jul 1999 15:12:22 -0700 (PDT)
Received: from mordor by hsmpka.eng.sun.com (SMI-8.6/SMI-SVR4) id PAA05651; Mon, 19 Jul 1999 15:12:19 -0700
Date: Mon, 19 Jul 1999 15:12:19 -0700 (PDT)
From: "[e-mail]" <[e-mail]>
Reply-To: "[e-mail]" <[e-mail]>
Subject: RE: KISS for PKIX. (Was: RE: ASN.1 vs XML (used to be RE: I-D ACT  ION :draft-ietf-pkix-scvp- 00.txt))
To: Stephen Kent <[e-mail]>
Cc: "Waters, Stephen" <[e-mail]>, [e-mail], [e-mail], [e-mail], "Holland, Gary" <[e-mail]>, "Bassett, John Robert" <[e-mail]>
In-Reply-To: "Your message with ID" <v04020a10b3b93c7db955@[128.89.0.110]>
Message-ID: <Roam.SIMC.2.0.6.932422339.22484.pcalhoun@hsmpka>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; CHARSET=US-ASCII

> 
> >4) As for 3), but the Smartcard uses biometrics - thumb-print, signature,
> >eye-scan. I guess this is much safer - provided you don't get gory!
> 
> As noted in another message, if one admits the ability to open up the card,
> then the biometric protection is probably not very interesting.  Note that
> the average college physical lab has all one needs to successfully open up
> almost all of these cards and extract private keys, these days, and the
> info on how to do this is being published, removing that barries as well.
> 
Furthermore, one has to implicitely trust the biometric reader. biometric
authentication only really works if the reader is owned by the user.
Otherwise, the authentication is subject to replay.

PatC



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 PAA12597 for <[e-mail]>; Mon, 19 Jul 1999 15:06:05 -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 SAA20210; Mon, 19 Jul 1999 18:07:43 -0400 (EDT)
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
X-Sender: [e-mail]
Message-Id: <v04020a01b3b9505372ef@[128.89.0.110]>
In-Reply-To: <[e-mail]>
Date: Mon, 19 Jul 1999 18:05:50 -0400
To: [e-mail]
From: Stephen Kent <[e-mail]>
Subject: RE: KISS for PKIX. (Was: RE: ASN.1 vs XML (used to be RE: I-D 	 	 ACTION :draft-ietf-pkix-scvp- 00.txt))
Cc: [e-mail], [e-mail], [e-mail]

Lynn,

>It isn't so much that it is applicable to "closed-systems" ... it is
>applicable
>to systems that create some front-end sign-up/trust relationship and then
>perform on-going transactions based on more global trust equation that isn't
>atomic & self-containable on a per transaction basis (like information
>aggregation ... i.e. account balance which is the combination of all deposits
>minus all debits/withdrawals)
>
>certificates are useful in situation for providing "on-the-fly" trust
>where none
>previously existed. for random interactions this basically combines both the
>transaction and the trust information into a single operation (where the scope
>of the trust propogation can be transaction atomic and self-contained
>within the
>definition of a certificate authorities policy and practices).

I'm of the school that says that certs don't establish trust at all.  They
represent relationships, often paralleling physical world relationships,
and allow users to make authorization decisions bases on the authentication
identities represented by the certs.  In the best cases, they parallel real
world authoritative relationships, not TTP "trus me" relationships.

<snip>

>in the x9.59 scenerio ... while the bank card transactions appear to operate
>between the consumer and the merchant ... in reality the merchant is
>acting as a
>transaction conduit to the consumer's financial institution ... where the
>consumer is instructing their financial institution to transfer funds from
>the consumer's account to the merchant's account
>
>possible objective for certificates is being useful for trust propogation in
>environments currently lacking existing trust infrastructures. webserver
>comfort
>certificates are useful in providing such trust ... even without certification
>authority infrastructures (i.e. simple certificate manufactoring processes).
>
>so looking at banking ... the issue for certificates is looking at the part of
>the business process where trust establishment enters into the equation
>... and
>being able to leverage the trust propogation characteristic of certificates.
>
>It isn't so much whether there is an open or closed characteristic ... it is
>whether the trust establishment occurs on every transaction or if there is an
>business infrastructure that has a setup/sign-up phase for establihing trust
>(i.e. setting up a bank account and maintaining the existing bank account
>balance).
>
>So, to the extent, that certificate authority policy and practices covers
>areas
>of trust propogation that coincides with trust attributes needed in the
>signup/setup process ... then specific certificate trust propogation is useful
>at that setup/signup point.

I agree with your characterization of how merchants, consumers, and issuing
banks relate to one another in bank card tranactions, something well
modeled by SET.  But the word "trust" appears in your later text way too
many times :-). I  don't beleive that trust is generally transitive, not
being a PGP kinda guy, so the phrase "trust propagation" also worries me.
Delegation of authorization might be more appropriate, in many instances,
but transitive trust is an awfully squishy notion that is hard to process
in an algorithmic fashion.  Most of the atetmpts we see to do this yield
counterexamples.

Steve


Received: from prv-mail20.provo.novell.com (prv-mail20.provo.novell.com [137.65.82.195]) by mail.proper.com (8.8.8/8.8.5) with SMTP id OAA12134 for <[e-mail]>; Mon, 19 Jul 1999 14:47:49 -0700 (PDT)
Received: from INET-PRV-Message_Server by prv-mail20.provo.novell.com with Novell_GroupWise; Mon, 19 Jul 1999 15:48:55 -0600
Message-Id: <[e-mail]>
X-Mailer: Novell GroupWise 5.5.2
Date: Mon, 19 Jul 1999 15:48:48 -0600
From: "Bob Jueneman" <[e-mail]>
To: <[e-mail]>
Cc: <[e-mail]>
Subject: Roadmap issues
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 OAA12135

Well said, Al.  I can't even keep up with reading all of the various drafts, 
many of which seem like the minor differences between various religious
sects, rather than being something really substantial.  

I'm not trying to stop progress, but I'd like to see some of the existing protocols
widely implemented, and their pros and cons clearly evaluated, prior to 
launching into the YAP ( Yet Another Protocol).

For example,  am still far from convinced of the utility of OCSP, when compared to
multiple CRL distribution points and delta CRLs. Based on the problems
we've had trying to improve the performance of SSL, I don't
relish the overhead of having to sign every individual validation request, 
when the information may not have changed since the last time it was 
requested.

And so far, I haven't seen the legal community come to any kind of 
agreement with respect to the need for, or value of "non-repudiation",
even though I still think it is important.  But that being the case, I can't get
too excited about rushing to support timestamping, etc.

It seems to me that a lot of the recent activity has ben a solution in search of 
a problem, or someone trying to invent and get buy-in to a protocol that will
give them a niche advantage.

To date, the only wide-spread use of PKI is for SSL to authenticate Amazon.com, etc.
Even SSL mutual authentication is not at all wide spread, and S/MIME is 
just beginning to attract some use. 

Various pilots are underway, but real conclusions are still a long way away.

I'd like to propose about a one year moratorium on new protocol developments in this
space, until we can figure out what works, what is interoperable (novel concept!),
and what is actually going to be used.  Then we can address some of the gaps.

"If it ain't broke, don't fix it."

"If it ain't even being used yet, it ain't broke."

Bob






>>> Al Arsenault <[e-mail]> 07/06/99 08:09AM >>>


[e-mail] wrote:

> OCSP, SCVP, and now DCS. It appears that there is more commonality between
> the various protocol's goals, then there is difference. Even the authors of
> the drafts are apparently perplexed when trying to substantiate the work and
> to outline the distinction of one protocol from the others. Writing a [rough
> cut of a] road map would be a nightmare, I'm imagining. Or could it be a
> good, probably even a necessary thing to do at this stage, to see for
> ourselves where we are heading?

Actually, stuff like this (CRS/CMC, CMP, etc.) was what led to the initial cut
at a PKIX roadmap in the first place.  Some of us were tired and frustrated at
having to explain what all the alphabet soup in PKIX was in the first place.

Right now, it seems like we're adopting a "got a problem, get a protocol"
approach.  That is:

    - if you want to communicate between an end-entity and a CA/RA, use CMP
    - if you want to do that using CMS formats, use CMC
    - if you want proof that bits existed at a certain time, use Timestamp
    - if you want proof that bits existed at a certain time, AND that they
possessed certain qualities, use DCS
    - if you don't want to process CRLs yourself, but want to know if a
certificate is valid at a given time, use OCSP
    - if you want to have a server do most of the PKI stuff, and let "thin
clients" just ask servers for the answers, use SCVP
    - ad infinitum, ad nauseum

The problem to me is that each time we introduce a new protocol, we introduce
new overhead, much of which is going to be redundant.

So, the question I ask is, does this working group believe that the right
approach should be:

    (a) continue along the current path of building a "large" number of "simple"
protocols; or
    (b) redesign the architecture somewhat so that there is a small number of
protocols, with options and extensions to handle all of the different services.

To me, the advantage to (a) is that it lets designers have lots of flexibility
in putting together their own PKI structures.  If I don't want OCSP, I leave it
out completely.  If I have a lightweight client, SCVP may be the only protocol
it needs; everything else can be off-loaded.  If I just want timestamp services,
I implement Timestamp and ignore DCS.  et cetera, et cetera.

The disadvantage, though, is that for somebody who's going to do a lot of the
protocols in a "heavyweight" PKI, there's a lot of redundancy.  If I have DCS,
what does Timestamp truly buy me - and is this something that couldn't be better
handled by a slight modification to DCS?  Similarly, if I do SCVP, what does
OCSP buy me?  Would I be better served by defining SCVP to have a mandatory part
that's the moral equivalent of OCSP, with extensions to handle the rest of the
stuff?

Similarly, the disadvantage to (b) is that, if we're not careful, we're going to
force somebody with only a small subset of "the PKI problem" to implement a
large protocol with lots of overhead, potentially causing them to drop out of
the PKIX arena altogether.  The advantage is that my gut feeling tells me we've
got a better chance of getting an interoperable PKI with a small number of
protocols that everybody implements.  (It's bad enough now listening to vendors
pitching me "we implement PKIX", and having to go through exactly which parts of
PKIX they mean, and whether that has a snowball's chance in the Sahara of
actually interoperating with the stuff I've already got.  The problem is going
to grow exponentially very soon, with all the additional protocols we keep
defining.)

So - I'm soliciting feedback from the group on  this issue.  The resolution has
already been reached for CMP vs CMC (approve them both and let the market
decide), and to an extent for OCSP (its scope was tightly constrained to be
certificate status, rightly or wrongly).  But, I don't think we're that far
along with any of the other protocols, and I'd really like to get a sense for
the group's views now, while there's still a chance to do something about it.

We'll put whatever the "right" answer is in the Roadmap, and figure out how to
say it correctly.  Sean did an outstanding job putting together draft -02 of the
Roadmap (I'm afraid I haven't been much help lately :-).  However, it's getting
close to time to advance this turkey to informational RFC (most likely, after
CMC has advanced to Proposed Standard).  So, the sooner decisions can be made
about "approach" the better.

                        Al Arsenault

-- this represents my personal opinion, and may or may not represent the
opinions of my employer, or of any other organization with which I have a
relationship





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 OAA11450 for <[e-mail]>; Mon, 19 Jul 1999 14:10:42 -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 RAA14898; Mon, 19 Jul 1999 17:12:11 -0400 (EDT)
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
X-Sender: [e-mail]
Message-Id: <v04020a11b3b9430441f0@[128.89.0.110]>
In-Reply-To: <[e-mail]>
Date: Mon, 19 Jul 1999 17:08:27 -0400
To: "Waters, Stephen" <[e-mail]>
From: Stephen Kent <[e-mail]>
Subject: RE: KISS for PKIX. (Was: RE: ASN.1 vs XML (used to be RE: I-D 	 A CTION :draft-ietf-pkix-scvp- 00.txt))
Cc: Stephen Kent <[e-mail]>, [e-mail]

Stephen,

>I think there is some exposure expressed here.  Apart from biometric
>Smartcards, most certificate safes on laptops could be cracked 'off-line',
>and then used to 'connect'.

Yes.

>With 'legacy authentication' such as password, SecureID, CHAP, etc.; there
>is no way to crack the password off-line since the laptop does not know if
>you got the answer right; only the server knows that.

Maybe if theft is the only concern, but if implamtation of TH software is a
concern, that we have other issues to address. Even for theft of the
laptop, if the software that takes a password for CHAP, S/KEY, etc., does
not explicitly erase it, I might be able to glean the necsaary data from a
stolen PC.

>As an example, I am using a certificate Smartcard with a pin-number
>protected private key for VPN access to my head office.  If the laptop and
>smartcard are stolen, the thief can play with them until he has cracked the
>pin number. The thief can do this off-line with no contact with the VPN
>server. Once cracked, they can connect to the Internet, and contact the VPN
>server.
>
>To help this situation, if the smartcard authentication was backed with a
>password/SecurID challenge via IKE XAUTH, the server can at least log the
>failure attempts, and could even cancel the related certificate if
>sufficient failures are counted.

Yes, but is the added inconvenience to the user's, and the added cost of
both a PKI and the "rented" SecurID card worth the likelihood of the sort
of attack being discussed?  Still, your point is a valid one, i.e., there
are attack scenarios where the combination of user auth mechanisms is
better than use of any of the individual mechanisms alone.

>To me, secondary password based authentication COULD be better than
>biometric smartcards. Assuming the hackers goal was to give no 'warnings' to
>the server in the form of access failures:
>
>1) Biometric thumb-print smartcard break-in:  Hold a gun to the owner of the
>thumb, or chop their thumb off and use it latter (yuk!)
>
>2) Well-chosen password break-in:  Hold a gun to the owner until he tells
>you the password/pin number.
>
>
>Hell, I prefer 2) !  O.K, joshing aside, it seems that until we have
>biometric smartcards, secondary 'legacy' authentication seems useful in
>preventing off-line hacking.

As noted in another response from me, biometric smart cards don't offer
significant protection against someone with reasonable technical capability.

Steve


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 OAA11445 for <[e-mail]>; Mon, 19 Jul 1999 14:10:36 -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 RAA14901; Mon, 19 Jul 1999 17:12:11 -0400 (EDT)
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
X-Sender: [e-mail]
Message-Id: <v04020a12b3b944509021@[128.89.0.110]>
In-Reply-To:  <[e-mail]>
Date: Mon, 19 Jul 1999 17:11:13 -0400
To: [e-mail]
From: Stephen Kent <[e-mail]>
Subject: RE: KISS for PKIX. (Was: RE: ASN.1 vs XML (used to be RE: I-D 	 	 ACTION :draft-ietf-pkix-scvp- 00.txt))
Cc: [e-mail]

Frank,

>Lynn Wheeler is correct. In a closed system (e.g., a home banking system),
>it is possible to compress all certificates to zero bytes (i.e., just use
>public keys).

yes, but one still needs top protect the integrity of the public keys, and
bind them to the access control database entries, and certs provide one way
of doing that, though not the only way.

>Certificates can be used to construct trust hierarchies. Public keys can
>not.

Good point.

>The reason SSL is primarily used for comfort is not because there is
>something wrong with certificates, it is because the necessary certificate
>management infrastructure does not exist. Imagine today's use of SSL without
>certificates -- system administrators would be installing large numbers of
>raw public keys into browsers, not a few CA certificates.

One must distinguish between server certs, as used today with SSL, vs.
client certs, which are rarely used today.  Your comment above is directed
at the former use, and is quite correct.

Steve


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 OAA11173 for <[e-mail]>; Mon, 19 Jul 1999 14:02:00 -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 RAA13790; Mon, 19 Jul 1999 17:02:27 -0400 (EDT)
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
X-Sender: [e-mail]
Message-Id: <v04020a10b3b93c7db955@[128.89.0.110]>
In-Reply-To: <[e-mail]>
Date: Mon, 19 Jul 1999 17:02:23 -0400
To: "Waters, Stephen" <[e-mail]>
From: Stephen Kent <[e-mail]>
Subject: RE: KISS for PKIX. (Was: RE: ASN.1 vs XML (used to be RE: I-D ACT ION :draft-ietf-pkix-scvp- 00.txt))
Cc: [e-mail], [e-mail], [e-mail], "Holland, Gary" 	 <[e-mail]>, "Bassett, John Robert" 	 <[e-mail]>

Stephen,

>Some very useful comments here, thanks.  From an IPSEC VPN point of view (my
>current concern), I would say that it looks like password/pin-protected
>certificates AND some secondary user-based authentication need to be
>implemented.
>
>Since it is easy to imagine a password-protected device/certificate being
>cracked off-line (i.e. in a dark room somewhere) before an attack is mounted
>on the VPN server, then secondary authentication becomes
>necessary/essential?
>
>Some examples:
>
>1) My PC has a certificate loaded that is not password protected. The PC, if
>stolen, could be used to authenticate itself against a VPN server.  This is
>clearly a problem that must be fixed without relying on notification of the
>theft to fix it.

Presumably you mean the private key is not password protected, not that the
certificate is not.  This would be a poor design, so I'm not sure it's
relevant to the discussion.

>2) My PC has a password-protected certificate. Each time I attempt to
>connect to the VPN server, the VPN application prompts the user for the
>password to unlock the certificate. My concern here is that, if the PC is
>stolen, then the password could be cracked by trial-and-error without any
>actual connection attempts (warnings) reaching the VPN server.

True, unless one uses the Arcot approach to protecting private keys.  (See
their paper in the 1999 IEEE Security and Privacy Symposium proceedings. I
don't necessarily endorse the technique by mentioning it here, but point it
out for completeness.)

>3) My PC uses a Smartcard with a pin-protected private-key/certificate.
>Again, if the Smartcard is stolen, how long would it take to crack the pin
>number off-line and use the authentication information on a different PC
>with a VPN client kit installed. This would require the attacker to know the
>address and security requirements of the VPN servers willing to accept the
>certificate.  If the PC and Smartcard are stolen together, it is probably
>worse than case 2).

I think that one should assume that whoever steals the smart card has
collateral intelligence about where to use it, unless it just happens to be
in your wallet and the goal of the theft is the credit cards and cash.  In
that latter case, the theft of the smart card is probably not a security
problem so much as it is an inconvenience for the user.

>4) As for 3), but the Smartcard uses biometrics - thumb-print, signature,
>eye-scan. I guess this is much safer - provided you don't get gory!

As noted in another message, if one admits the ability to open up the card,
then the biometric protection is probably not very interesting.  Note that
the average college physical lab has all one needs to successfully open up
almost all of these cards and extract private keys, these days, and the
info on how to do this is being published, removing that barries as well.

>5) My PC uses one of the approaches above, but once authentication via the
>certificate is complete, enforces a secondary authentication. This
>authentication is under the control of the server, and so can't be cracked
>off-line. If an attack is mounted, the VPN server will receive 'warnings' in
>the form of authentication failures (I hope).  The authentication
>information provided in this secondary phase MUST NOT be part of the VPN
>client's automatic function.

What exaclty is an example fo the second phase authentication here?  If one
assumes use of a SecurID card, for example, why not postulate that it was
tolen at the same time as the smart card?  If a password is used, then we
have all the usual password-related problems that make guessing possible.

>The advantages of 5) seem to be:
>1) two-way authentication between the devices based on certificates.
>2) secondary, independent authentication that can't be cracked 'off-line'.
>3) an 'way out' for the non-repudiation legality.
>4) continued use of existing remote access authentication methods.
>
>I have not covered the case where a stolen PC/certificate is used to spoof a
>VPN server. Mainly because I can't think of a solution!

I don't think that #3 is a real issue here, but the rest of the points are
well taken.  However, one is making the user do through more hoops, and the
result also may still vulnerable to Trojan Horse attacks.  What you didn't
mention explicity here is that your analysis focuses on the threat posed by
physical theft of the PC and/or authentication token.  That's not a bad
model, but it's not the only one to consider, and today many folks would
rate it much lower than software-based attacks against the server or the
client.

Steve


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 NAA10672 for <[e-mail]>; Mon, 19 Jul 1999 13:30:50 -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 QAA10118; Mon, 19 Jul 1999 16:32:28 -0400 (EDT)
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
X-Sender: [e-mail]
Message-Id: <v04020a0fb3b93a3c31bc@[128.89.0.110]>
In-Reply-To: <[e-mail]>
Date: Mon, 19 Jul 1999 16:34:54 -0400
To: [e-mail]
From: Stephen Kent <[e-mail]>
Subject: Re: KISS for PKIX. (Was: RE: ASN.1 vs XML (used to be RE: I-D 	 	 ACTION :draft-ietf-pkix-scvp- 00.txt))
Cc: "'[e-mail]'" <[e-mail]>

Lynn,

>oh yes ... and to some extent the cert-less work, in fact grew out of working
>on various SET projects (or lets say that the size of the certificate was
>compressed
>to zero bytes).
>
>1) first off, set doesn't provide end-to-end authentication ... the digital
>signature/cert is verified at (essentially) and internet boundary and then the
>digital signature and cert is stripped off the transaction before
>forwarding to
>the customers bank for final authentication, authorization, and execution. The
>forwarded request does have a flag turned on saying whether the sender
>succesfully performed a digital signature authentication. Two years ago, visa
>presented some number at a ISO meeting in europe on the number of transactions
>coming thru which had the digital signature validated turned on ... and for
>which they could proove there was no digital signature capability (one of the
>simple hazards of not having end-to-end security). Furthermore, the digital
>signature authentication was just a preliminary screening and the consumer's
>backend actually performed the real authentication, authorization and
>execution
>using account record information.

I am certainly willing to believe that merchants said they were validating
SET transaction sigs when they were not, but certainly the rationale for
carrying a cert with the transaction, as far as the merchant, was to permit
such validation.  So, let's not confuse what the architecture was desigend
to do vs. what people may be doing right now.  If we did that with
cert-full systems, and used current browsers as examples, we'd get a
terrible model of how X.509 certificate validation is done, for example :-).

>
>2) while not part of the SET specification ... every institution that I
>know of
>that looked at doing SET generated a work request to add the
>certificate/public
>key to the consumer's account record.

Presumably the issuing bank has access to these certs, in whatever format,
and how they access them is a purely local matter, hence not a subject of
standardization. Thus I am not surprised that this would not become part of
the SET spec.

<snip>

>
>so back to the question in the thread about the  issue of of  certificate PKIs
>costs being a downside inhibitor .... it may not only be the raw costs of the
>certificate PKIs that is in question ... but also the fact that in several
>environments that they may represent redundant and superfulous costs. The
>issue
>then is that for such environments ... either the redudant and superfulous
>costs
>are not appropriate and/or certificate PKIs need to find a way of leveraging
>their characteristics for eliminating other costs.
>
>And to re-iterate ... fully qualified identity certificates carrying full
>permissions can be used to eliminate use of  account records (which can in
>turn
>raise privacy and security concerns) ... or they just carry a pointer to the
>account records ... which makes it harder to show that they aren't
>redundant and
>superfulous.

What you describe is a traditional ACL vs. capability model, but with a
blurring of authentication vs. authorization.  The cert-less approach you
describe argues that authentication and authorization must always be tied
together, whereas the infosec community (as well as all the standards I
know of) have always felt the two are independent.  For exmaple, one can
authenticate a user for audit purposes independent of any authorization
decisions.  Also, in rule-based access control systems, one can grant
access independent of knowing the identity of the user, allthough some part
of the system usually does have authentication data available for
accountability.  Because systems may distribute authorization data
separately from authentication data, it is generally attractive to be able
to support these two distinct services via separable mechanisms, separate
databases, etc.

Steve


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 NAA10133 for <[e-mail]>; Mon, 19 Jul 1999 13:20:45 -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 QAA08813; Mon, 19 Jul 1999 16:22:22 -0400 (EDT)
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
X-Sender: [e-mail]
Message-Id: <v04020a0cb3b93816b093@[128.89.0.110]>
In-Reply-To: <[e-mail]>
Date: Mon, 19 Jul 1999 16:19:14 -0400
To: [e-mail]
From: Stephen Kent <[e-mail]>
Subject: RE: Common misconceptions, ... 	.txt))
Cc: "'[e-mail]'" <[e-mail]>

Lynn,

>i believe the context of the reply was within the statement of what are the
>reasons why cert PKIs are having hard time. One of the issues raised was
>cost ... part of that scenerio is that digital signature authentication can be
>seperated from the question of cert infrastructure costs ... i.e. semantic
>confusion that the digital signature authenticates the transaction (not
>the certificate) and that the certificate is one method of authenticating
>the public key. The digital signature business case can actually be
>seperated from the certificate business case (they don't have to
>be synonomous) ... leaving the certificate business case to show
>that it can eliminate/reduce cost of existing account-based operations.
>
>One way  is to show identity certificates carrying all information
>and permissions can eliminate the accounts ... but that introduces
>privacy and security exposures. The other way is to show relying-party-only
>certificates ... with no information but an account number .... which then
>have to hit the account record ... at which point the certificate can be
>shown to be redundant and superfulous.
>
>So examining the parameters and operational regions for certificate
>business cases .... it is useful to understand where they provide
>significant benefit like in the webserver comfort certificate case.

We disagree that "relying-party-only" certs are redundant, as I have
discussed in a recent response.

However, I agree that your comments about cert-less use of PKIs were
relevant to the discussion of why PKIs have been hard to deploy, and so, in
that context, the comments were appropriate for this list.

Steve


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 NAA10098 for <[e-mail]>; Mon, 19 Jul 1999 13:20:42 -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 QAA08803; Mon, 19 Jul 1999 16:22:19 -0400 (EDT)
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
X-Sender: [e-mail]
Message-Id: <v04020a0bb3b93485d9d3@[128.89.0.110]>
In-Reply-To: <[e-mail]>
Date: Mon, 19 Jul 1999 16:16:02 -0400
To: [e-mail]
From: Stephen Kent <[e-mail]>
Subject: Re: KISS for PKIX. (Was: RE: ASN.1 vs XML (used to be RE: I-D 	 	 ACTION :draft-ietf-pkix-scvp- 00.txt))
Cc: "'[e-mail]'" <[e-mail]>

Lynn,

>a cert-less approach is relatively trivial to apply across the
>corporate electronic environment. register the employees public
>key in a RADIUS administrative data-base (i.e. RA by any other
>name) and use RADIUS protocol for all corporate authentications
>i.e. existing RADIUS based authentication and straight forward
>apply RADIUS protocol to future applications.

How exactly does this match with the details of existing, standard
protocols, such as IPsec, SSL, and S/MIME?  I can imagine a scheme by which
this could be made to work, but since these protocols have explicit
provisions for cert (usually X.509 cert) transfer or retrieval., I suspect
that the suggestion you make here is not really compatible with standards
compliant protocols of this sort.  I agree that one might choose to build a
custom application on the basis of cert-less operation.

>This even works in SSL and other types of environments. Consumer's
>authentication at the server is done with RADIUS account-base.

SSL has a specific mechanism for using a client cert for authentication as
part of the SSL handshake.  I don't see how this matches your example,
above.  I think that a browser and server, without modification, will not
be able to take advantage of a client private key based on your description.

>This doesn't say anything about eliminating web server comfort
>certificates ... for setting up SSL sessions ... just addresses issue
>of authenticating individuals in environments that are really account-base
>operation.

We agree that server certs are not the issue here.  But, the standard way
for a cleint to use a public key for auth is as part of the SSL exchange.
Are you proposing a new, independent user auth operation?  If so, then I
agree one could do that, perhaps with a plug-in, but we already have a
means of using a client cert for authentication in SSL, and we have tens of
millions of browsers that are capable of generating key pairs, requesting
certs, and passing certs to servers in a standard fashion.  So, why change?

<snip>

>as alwas choice is:
>
>1) fully defined, identity certificate

What is this, exactly?

>2) relying-party-only certificate where the transaction has to
>hit the account record.
>
>either all the necessary information is in the certificate or the
>certificate contains only enuf information to be able to get
>to the account record. if the operation has to hit the accound
>record anyway ... then it is trivial to show that the certificate
>is redundant and superfulous.
>
>it wasn't intended to be a red herring statement ... it was a
>statement that is was one or the other ... either all the necessary
>information is in the certificate (in which case the certificate can
>represent a privacy and/or security issue) or the information is
>in an account record (in which case the certificate is superfulous
>and redundant).
>
>this of course, doesn't apply to saying that the merchant comfort
>certificates (using for setting up SSL sessions) are unnecessary
>... but that almost all cases that the certificates for employees
>and individuals ... tend to either 1) divulge privacy/confidential
>information or 2) have to hit an account record.

A third choice is to send along an attribute cert (or to embed
authorization data in the public key cert), which is how capability system
is supposed to work (as per the last 25 years of infosec).  This avoids the
need to "hit the account" record, unless access is based on a dynamic
parameter, e.g., for credit card transactions, which is not characteristic
of most intra=net access controls.  In this fashion the organization can
include whetever form of )local) ID it deems appropriate, and the user can
pass in whatever form of authorization credentials are appropriate for the
resource being accessed, avoiding the need for an account record access.
The resource manager does need to check for revocation of the certs in
question, but that may be a cacheable list not requiring the same sort of
off-server access that folks may be envisioning.

Another observation is that the databases for public key management and
authorization management may differ.  If so, a cert-less design might
require two different accesses, one for the public key and one for the
authorization data.  Also, one needs to protect the public key while in
storage and, if the server for the public key is not local to the resource
being access, during  transmission, which is just what a certificate does!
So, cert-less use of public keys does have some possible downsides,
depending on the context.

Steve


Received: from www.meridianus.com (209.249.223.18.has.no.reverse [209.249.223.18] (may be forged)) by mail.proper.com (8.8.8/8.8.5) with ESMTP id MAA09615 for <[e-mail]>; Mon, 19 Jul 1999 12:58:38 -0700 (PDT)
Received: from PC1 by www.meridianus.com (8.8.8+Sun/SMI-SVR4) id NAA05893; Mon, 19 Jul 1999 13:54:54 -0700 (PDT)
Message-ID: <015e01bed223$0a52cf00$[e-mail]>
From: "Todd S. Glassey" <[e-mail]>
To: <[e-mail]>
Subject: The PKIX meeting...
Date: Mon, 19 Jul 1999 13:12:34 -0700
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_015B_01BED1E8.5D8C0D70"
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.00.2918.2701
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2918.2701

This is a multi-part message in MIME format.

------=_NextPart_000_015B_01BED1E8.5D8C0D70
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Stephen,=20
I am sorry that I missed the Oslo meeting now more than ever when I read =
your report on the BERT session in the Meeting. We perhaps didn't make =
the value of vision of the BERT effort clear enough or convey its use =
properly, again my profound apologies, with that in mind, perhaps I can =
correct some of the micconceptions cited in your report.

The BERT Token and API Effort is borne from that McNeil and I wanted to =
create a common event auditing token that would give the App Designers =
and their users as much flexibility as possible. We have come to realize =
that for many application domains the audit trail itself "is the event =
token stream" and that it should stand separately from the system that =
produced it.=20

The overall BERT Architecture provides just such a token structure to =
modularly represent events as per their proofing requirements. The idea =
is that there are a tremendous number of diverse PKI applications and =
use models and a number of them really need common points of =
interchange. We see this as the perfect use of the timestamp or =
watermark.=20

Thankfully, the experiences of such development forums as the PKIX WG, =
the X.509 Groups and the ANSI X.9 efforts have all rolled some pretty =
good working infrastructure tools our way, and the missing pieces in the =
big PKI picture are now pretty much just the glue and studs to hold the =
systems together. However, as more and more business comes online so to =
speak, we see these in and of themselves are of more and more import.

For these 'glue and studs' we propose commercial users are more likley =
to want simple stand-alone timestamps rather than fully blown certs or =
any other complex PKI enabled structures - especially if the run closed =
network infrastuctures and their audit models are all internal. That is =
why we are focused directly on representing the event and then designing =
the method and process of securely creating the event token. We were =
sure that with relaible sources of time like the new secured NTP =
channels and Secured ACTS coming online, that BCP models that include =
securely setting the local timebase will be more likely to stand =
scurtiny, so with the timebase and its validity addressed in technical =
process, then the token structure becomes the point of exchange so to =
speak.

With regard to the BERT token and what it is, BERT is a data-blob that =
allows one to specificy events in time and 3-D space with an excellant =
level of precision.  The BERT token is extensible so that it can be =
adjusted to various size and proofing use models. The BERT Token is =
interoperable and can be represented in a number of formats including =
ASN.1, S/MIME, XML, and Binary. Not only that, we see no reason why a =
BERT token could not be a TST in the current TS Drafts. This is a basic =
design philosophy divergence from the current timestamping protocol =
drafts and that the timestamping system must allow for the token to =
contain time and jurisdicitional or intent conveyance payloads.

As to the delivery of the Protocol Spec to accompany the Token Structure =
Draft, the current Protocol/API Spec is still in a state of flux but =
should be out within the next 30 days I would hope.=20

As to Datum's involvement and the IP issues, Datum is building a =
solution that we (McNeil and I) understand is based on their evolving =
some of McNeil's and my earlier work, and it is an excellent solution =
for an embedded timebase, but it is not BERT, lets be very clear on =
that. Lets also address the IP issues here. BERT's structure is =
available to use Gratis, under an GNU style license for commercial and =
noncommercial uses aleady up on the site at =
http://www.gmtsw.com/ietf/bert . Our API code is also to be available to =
non-commercial users under a similar license, but the BERT structure and =
its proofing models are very simple to use so rolling your own solution =
around BERT is a snap.

The point is that BERT is a good working solution for adding a common =
point of reference into legacy and new computing application models.

Todd Glassey
-----------------

Basic Event Representation Token (M. McNeil-GMT)
The author notes that this proposal relates to the TSP work, but uses =
what
is believed a more compact format so that it may be used in environments
where the size of the response from a TSA is too big.(1) The primary use =
model
provided here is rather implementation-specific, i.e., tamper-evident
hardware in a local context, vs. a TSA accessible via a network (2).  A
Security AD raised questions about any intellectual property claims
associated with this model, as this may affect whether the proposal is
appropriate for an IETF WG(**). The speaker stated that he is aware of =
no IP
with regard to the proposed formats, etc. A PKIX WG chair expressed =
concern
over the apparent product-specific nature of the proposed model (1).  =
The
author acknowledges that only one vendor (Datum) offers the sort of
hardware cited as the primary use example. The WG chairs and the =
Security
ADs will discuss whether this work is appropriate for PKIX, given the
issues cited above.


------=_NextPart_000_015B_01BED1E8.5D8C0D70
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META content=3D"text/html; charset=3Diso-8859-1" =
http-equiv=3DContent-Type>
<META content=3D"MSHTML 5.00.2919.800" name=3DGENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=3D#ffffff>
<DIV><FONT face=3DArial size=3D2>Stephen, </FONT></DIV>
<DIV><FONT face=3DArial size=3D2>I am sorry that I missed the Oslo =
meeting now more=20
than ever when I read your report on the BERT session in the=20
Meeting.&nbsp;We&nbsp;perhaps didn't make the value of vision of the =
BERT effort=20
clear enough or convey its use properly, again my profound apologies, =
with that=20
in mind, perhaps I can correct some of the micconceptions cited in your=20
report.</FONT></DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>The BERT Token and API Effort is borne=20
from&nbsp;that McNeil and I wanted to create a common event auditing =
token that=20
would&nbsp;give the App Designers and their users as much flexibility as =

possible. We have come to realize that for many application domains the =
audit=20
trail itself "is the event token stream" and that it should stand =
separately=20
from the system that produced it. </FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>The overall BERT =
Architecture&nbsp;provides just=20
such a&nbsp;token structure to modularly represent events as per their =
proofing=20
requirements. The idea is that there are a tremendous number of diverse =
PKI=20
applications and use models and a number of them really need common =
points of=20
interchange. We see this as the perfect use of the timestamp or =
watermark.=20
</FONT></DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>Thankfully, the experiences of such =
development=20
forums as the PKIX WG, the X.509 Groups and the ANSI X.9 efforts have =
all rolled=20
some pretty good working infrastructure tools our way, and the missing =
pieces in=20
the big PKI picture are now pretty much just&nbsp;the glue and studs to =
hold the=20
systems together. However, as more and more business comes online so to =
speak,=20
we see these in and of themselves are of more and more =
import.</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>For these 'glue and studs' we propose =
</FONT><FONT=20
face=3DArial size=3D2>commercial users are more likley to want simple =
stand-alone=20
timestamps rather than fully blown certs or any other complex PKI =
enabled=20
structures - especially if the run closed network infrastuctures and =
their audit=20
models are all internal. That is why we are focused directly on =
representing the=20
event and then designing the method and process of securely creating the =
event=20
token. We were sure that with relaible sources of time like the new =
secured NTP=20
channels and Secured ACTS coming online, that BCP models that include =
securely=20
setting the local timebase will be more likely to stand scurtiny, so =
with the=20
timebase and its validity addressed in technical process, then the token =

structure becomes the point of exchange so to speak.</FONT></DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>With regard to the BERT token and what =
it is, BERT=20
is a data-blob that allows one to specificy events in&nbsp;time and 3-D =
space=20
with an excellant level of precision.&nbsp; The BERT token =
is&nbsp;extensible so=20
that it can be adjusted to various size and proofing use models. The =
BERT Token=20
is interoperable and can be represented in a number of formats including =
ASN.1,=20
S/MIME, XML, and Binary. Not only that, we see no reason why a BERT =
token could=20
not be a TST in the current TS Drafts. This is a basic design philosophy =

divergence&nbsp;from the current timestamping protocol drafts and that =
the=20
timestamping system must allow for the token to contain time and =
jurisdicitional=20
or intent conveyance payloads.</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>As to the delivery of the Protocol Spec =
to=20
accompany the <FONT face=3DArial size=3D2>Token Structure Draft, the =
current=20
Protocol/API Spec is still in a state of flux but should be out within =
the next=20
30 days I would hope. </FONT></FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>As to Datum's involvement and the IP =
issues, Datum=20
is building a solution that we (McNeil and I) understand is based on =
their=20
evolving some of McNeil's and my earlier work, and it is an excellent =
solution=20
for an embedded timebase, but it is not BERT, lets be very clear on=20
that.</FONT><FONT face=3DArial size=3D2> Lets also address the IP issues =
here.=20
BERT's structure is available to use Gratis, under an GNU style license =
for=20
commercial and noncommercial uses aleady up on the site at <A=20
href=3D"http://www.gmtsw.com/ietf/bert">http://www.gmtsw.com/ietf/bert</A=
> . Our=20
API code is also&nbsp;to be available to non-commercial users under a=20
similar&nbsp;license, but the BERT structure and its proofing models are =
very=20
simple to use so rolling your own solution around BERT is a =
snap.</FONT></DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>The point is that BERT is a good =
working solution=20
for adding a common point of reference into legacy and new computing =
application=20
models.</FONT></DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>Todd Glassey</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>-----------------</FONT></DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>Basic Event Representation Token (M.=20
McNeil-GMT)<BR>The author notes that this proposal relates to the TSP =
work, but=20
uses what<BR>is believed a more compact format so that it may be used in =

environments<BR>where the size of the response from a TSA is too big.(1) =
The=20
primary use model<BR>provided here is rather implementation-specific, =
i.e.,=20
tamper-evident<BR>hardware in a local context, vs. a TSA accessible via =
a=20
network (2).&nbsp; A<BR>Security AD raised questions about any =
intellectual=20
property claims<BR>associated with this model, as this may affect =
whether the=20
proposal is<BR>appropriate for an IETF WG(**). The speaker stated that =
he is=20
aware of no IP<BR>with regard to the proposed formats, etc. A PKIX WG =
chair=20
expressed concern<BR>over the apparent product-specific nature of the =
proposed=20
model (1).&nbsp; The<BR>author acknowledges that only one vendor (Datum) =
offers=20
the sort of<BR>hardware cited as the primary use example. The WG chairs =
and the=20
Security<BR>ADs will discuss whether this work is appropriate for PKIX, =
given=20
the<BR>issues cited above.</FONT></DIV>
<DIV>&nbsp;</DIV></BODY></HTML>

------=_NextPart_000_015B_01BED1E8.5D8C0D70--



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 LAA08648 for <[e-mail]>; Mon, 19 Jul 1999 11:51:12 -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 OAA25845; Mon, 19 Jul 1999 14:52:45 -0400 (EDT)
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
X-Sender: [e-mail]
Message-Id: <v04020a07b3b923c1e8d1@[128.89.0.110]>
In-Reply-To: <007001bed205$392a1040$[e-mail]>
References: <v04020a06b3b578a725fe@[128.33.238.45]>
Date: Mon, 19 Jul 1999 14:53:53 -0400
To: "Peter Williams" <[e-mail]>
From: Stephen Kent <[e-mail]>
Subject: RE: KISS for PKIX. (Was: RE: ASN.1 vs XML (used to be RE: I-D  ACTION :draft-ietf-pkix-scvp- 00.txt))
Cc: "Stephen Kent" <[e-mail]>, <[e-mail]>

Peter,

>Commercial certificate validation is a risk-based procedure. It depends
>on the risk associated with the accuracy of the status and compromise
>data, the trustworthiness of the source of the status and
>compromise information, the reliability of the inputs
>on status and compromise, the security of the user
>platform, and the appropriateness of the user's X.509
>policy-configuration for the transaction type.
>
>One can do issuer-independent "validation-reliance" velocity
>measurements, much like the credit-card industry does for transaction
>handling during credit-card validation, to manage the overall
>risk curve for a community relying upon or merely using PKI
>validation. Trusted commercial TTP networks have been doing
>security validation for years, one can note, and have well
>established procedures which transfer directly to
>commercial-oriented PKI based on the network validation model.

What you have described is a list of many of the factors that affect the
assurance of the cert validation process, as well as of the cert issuance
process.  I think it is useful to make the discintion that I did between
the algorithmic aspects of cert validation vs. the assurance that results
from the various factors cited above.  Hence I stand by my distinction. I
am not familar with Ed's papers on the topic, but I hope they don't cloud
the distinction cited here, as it is an important one.  Note that the scope
of PKIX is limited primarily to the protocols and algorithms used for
validation, as the assurance aspects of implementations, external
authentication procedures, etc.  Our one foray into the other arena, PKIX
Part 4, is an informational, not standards track, document.

Steve


Received: from ns1.dmz.valicert.com (ns1.valicert.com [63.65.221.10]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id LAA08198 for <[e-mail]>; Mon, 19 Jul 1999 11:28:41 -0700 (PDT)
Received: from ns1.serverfarm.valicert.com (corporate-gw.valicert.com [63.65.221.2]) by ns1.dmz.valicert.com (8.9.2/8.9.2) with ESMTP id LAA12636; Mon, 19 Jul 1999 11:28:21 -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 LAA18239; Mon, 19 Jul 1999 11:29:44 -0700 (PDT)
From: "Peter Williams" <[e-mail]>
To: "Stephen Kent" <[e-mail]>, <[e-mail]>
Cc: <[e-mail]>
Subject: RE: KISS for PKIX. (Was: RE: ASN.1 vs XML (used to be RE: I-D 	ACTION :draft-ietf-pkix-scvp- 00.txt))
Date: Mon, 19 Jul 1999 11:39:08 -0500
Message-ID: <007001bed205$392a1040$[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
In-Reply-To: <v04020a06b3b578a725fe@[128.33.238.45]>
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300

> -----Original Message-----
> From: Stephen Kent [mailto:[e-mail]]
> Sent: Saturday, July 17, 1999 2:02 PM
> To: [e-mail]
> Cc: '[e-mail]'
> Subject: Re: KISS for PKIX. (Was: RE: ASN.1 vs XML (used to be RE: I-D
> ACTION :draft-ietf-pkix-scvp- 00.txt))

> I think you are confusing cert validation with cert issuance assurance
> procedures, etc.  Cert validation is an algorithmic process.  The level of
> confidence one has that the holder of the corresponding private key is the
> entity specified in the Subject field is a separate matter.
>
> Steve
>


Commercial certificate validation is a risk-based procedure. It depends
on the risk associated with the accuracy of the status and compromise
data, the trustworthiness of the source of the status and
compromise information, the reliability of the inputs
on status and compromise, the security of the user
platform, and the appropriateness of the user's X.509
policy-configuration for the transaction type.

One can do issuer-independent "validation-reliance" velocity
measurements, much like the credit-card industry does for transaction
handling during credit-card validation, to manage the overall
risk curve for a community relying upon or merely using PKI
validation. Trusted commercial TTP networks have been doing
security validation for years, one can note, and have well
established procedures which transfer directly to
commercial-oriented PKI based on the network validation model.

Ed Gerck published seminal papers on this general
way of thinking, for PKI, a year or two ago.

Peter.



Received: from chi6sosrv11.alter.net (chi6sosrv11.alter.net [208.204.150.57]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id LAA07909 for <[e-mail]>; Mon, 19 Jul 1999 11:19:41 -0700 (PDT)
Received: from xedia.com by chi6sosrv11.alter.net with SMTP  (peer crosschecked as: madway.xedia.com [198.202.232.199]) id QQgyon00057; Mon, 19 Jul 1999 18:20:57 GMT
Received: from tonga.xedia.com by xedia.com (4.1/SMI-4.1) id AA21732; Mon, 19 Jul 99 14:19:40 EDT
Received: by tonga.xedia.com (SMI-8.6/SMI-SVR4) id OAA17721; Mon, 19 Jul 1999 14:20:56 -0400
Date: Mon, 19 Jul 1999 14:20: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: When is Timestamp applied?
References: <[e-mail]> <[e-mail]>
X-Mailer: VM 6.34 under 20.3 "Vatican City" XEmacs  Lucid

>>>>> Sean Turner <[e-mail]> writes:

 > Mike, I'd actually be in favor of just saying that the time
 > indicated in the timestamp should be when the TSA signed the
 > data.

 > Michael Zolotarev wrote:

 >> Denis, Sean,
 >> 
 >> Does a person who is not currently in Oslo have a right to say :)?
 >> 
 >> >From the practical point of view, I do not see much benefit in
 >> putting extra detail into the stamp. What the time stamp is for?
 >> To provide an evidence that a datum existed AT LEAST at certain
 >> time....

I think Mike's argument implies that constraining it to be "when the
TSA signed the data" is not necessary.

Another argument: protocol standards and protocol conformance
statements should be assertions about EXTERNALLY OBSERVABLE behavior.
This is a fundamental rule of standards design.

The definition Mike proposed has that property.  The one Sean proposed 
does not.

If I put a black box containing a TSA implementation in a lab and
send requests at it, I can verify that the time stamps returned are
not earlier than the request arrival time, and not later than the
response transmit time, but I have no way of knowing more than that.
Therefore the spec cannot and must not imply any more than that.

	paul


Received: from mail-ewr-3.pilot.net (mail-ewr-3.pilot.net [206.98.230.17]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id KAA07403 for <[e-mail]>; Mon, 19 Jul 1999 10:49:30 -0700 (PDT)
From: [e-mail]
Received: from mailgw.firstdata.com ([204.48.27.166]) by mail-ewr-3.pilot.net (Pilot/8.8.8) with ESMTP id NAA09852; Mon, 19 Jul 1999 13:51:09 -0400 (EDT)
Received: from lnsunr02.firstdata.com (lnsunr02.firstdata.com [192.168.247.16]) by mailgw.firstdata.com with SMTP id NAA20450; Mon, 19 Jul 1999 13:51:04 -0400 (EDT)
Received: by lnsunr02.firstdata.com(Lotus SMTP MTA v4.6.4  (830.2 3-23-1999))  id 852567B3.006197ED ; Mon, 19 Jul 1999 13:45:58 -0400
X-Lotus-FromDomain: FDC
To: [e-mail]
cc: [e-mail], [e-mail]
Message-ID: <[e-mail]>
Date: Mon, 19 Jul 1999 10:49:16 -0700
Subject: RE: KISS for PKIX. (Was: RE: ASN.1 vs XML (used to be RE: I-D 	 	 ACTION :draft-ietf-pkix-scvp- 00.txt))
Mime-Version: 1.0
Content-type: text/plain; charset=us-ascii
Content-Disposition: inline

It isn't so much that it is applicable to "closed-systems" ... it is applicable
to systems that create some front-end sign-up/trust relationship and then
perform on-going transactions based on more global trust equation that isn't
atomic & self-containable on a per transaction basis (like information
aggregation ... i.e. account balance which is the combination of all deposits
minus all debits/withdrawals)

certificates are useful in situation for providing "on-the-fly" trust where none
previously existed. for random interactions this basically combines both the
transaction and the trust information into a single operation (where the scope
of the trust propogation can be transaction atomic and self-contained within the
definition of a certificate authorities policy and practices).

For instances where setup/sign-up trust operations are part of  the business
process ... certificates may or may not represent a mechanism for establishing
the initial trust environment (potentially replacing existing trust
establishment procedures). Part of the issue of transaction trust in a financial
environment includes aggregation information ... like current account balance).
As such, financial institutions establishes a more complex trust environment
including sign-up/setup that brackets large set of individual transactions
(instead of repeatedly doing all of the trust establishment on each
transaction).

in the x9.59 scenerio ... while the bank card transactions appear to operate
between the consumer and the merchant ... in reality the merchant is acting as a
transaction conduit to the consumer's financial institution ... where the
consumer is instructing their financial institution to transfer funds from
the consumer's account to the merchant's account

possible objective for certificates is being useful for trust propogation in
environments currently lacking existing trust infrastructures. webserver comfort
certificates are useful in providing such trust ... even without certification
authority infrastructures (i.e. simple certificate manufactoring processes).

so looking at banking ... the issue for certificates is looking at the part of
the business process where trust establishment enters into the equation ... and
being able to leverage the trust propogation characteristic of certificates.

It isn't so much whether there is an open or closed characteristic ... it is
whether the trust establishment occurs on every transaction or if there is an
business infrastructure that has a setup/sign-up phase for establihing trust
(i.e. setting up a bank account and maintaining the existing bank account
balance).

So, to the extent, that certificate authority policy and practices covers areas
of trust propogation that coincides with trust attributes needed in the
signup/setup process ... then specific certificate trust propogation is useful
at that setup/signup point.




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 KAA07168 for <[e-mail]>; Mon, 19 Jul 1999 10:41: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 NAA16248; Mon, 19 Jul 1999 13:42:53 -0400 (EDT)
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
X-Sender: [e-mail]
Message-Id: <v04020a01b3b8f6824668@[128.89.0.110]>
In-Reply-To: <[e-mail]>
Date: Mon, 19 Jul 1999 13:39:49 -0400
To: Theo PAGTZIS <[e-mail]>
From: Stephen Kent <[e-mail]>
Subject: DRAFT PKIX WG Meeting Minutes
Cc: [e-mail]

Theo,

Thanks for the reminder.  Below are the draft meeting minutes from last
week. I will accept comments, corrections, etc. until Saturday, 7/31,
before publishing the final form for the IETF Secretariat.

I want to thank Russ and Denis, who share the award for fastest submission
of slides.  All other speakers from the PKIX sessions should send me their
slides for inclusion in the IETF archives, in PPT format.

Steve Kent
Co-chair, PKIX WG

-----

PKIX WG Meeting 7/14/99
Edited by Steve Kent (WG co-chair)

The PKIX WG met only once during the 45th IETF and a approximately 180
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 (RFC 2585)
		Approved as Proposed Standard
LDAP V2 Operational Protocols (RFC 2559)
		Approved as Proposed Standard
LDAP V2 Schema (RFC 2587)
		Approved as Proposed Standard
OCSP (RFC 2560)
		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)

Diffie-Hellman POP (draft-ietf-pkix-dhpop-00.txt)
		Ready for WG last call
Qualified Certificates (draft-ietf-pkix-qualified-qc-03.txt)
		Ready for WG last call
CMMF (draft-ietf-pkix-cmmf-02.txt)
		This item to be dropped from the program
Time Stamp (draft-ietf-pkix-time-stamp-00.txt)
		Near to WG last call
DCS (draft-ietf-pkix-dcs-00.txt)
		Under WG review
PKIX Rodamap (draftietf-pkix-roadmap-??.txt)
		Under WG review.
Others??


Reports on Established Projects:


Progressing RFC 2459 to Draft Status (R. Housley-Spyrus)
Russ described the requirements for progression to draft standard status
and solicited inputs from the PKIX community in support of this
progression. He also solicited edits to 2459 and noted that a defect report
on policy mapping in certificate validation processing has been filed. This
defect is expected to be resolved in a meeting in September, and the
results will be reflected in the revisions to 2459. Depending on the
resolution of this defect, it may be necessary for 2459 to "cycle in
grade," or it may be possible to progress to draft standard status. A straw
poll on a technical detail of delta CRL management was conducted, and the
consensus was to allow delta CRLs to be based on any specified base (vs.
only the most recently issued base).

Revision of RFC 2527 Certificate Policy Practice Guidelines (J. Rodriguez-IBM)
An activity on revising this informational RFC, based on operational
experience in the CA realm, and inputs from the legal community (ABA) has
been initiated. A small group has been created, with a corresponding
mailing list ([e-mail]), to pursue this revision.

CMC and Diffie-Hellman POP (J. Schaad-Microsoft)
Final draft for CMC will be published in about one week, and then go to WG
last call.  The D-H POP draft will follow shortly.


PKIX Roadmap (S. Turner-IECSA)
Updated QC discussion, and added a number of items (not all of which are
accepted as work items for the WG). A comparison of PKIX vs. other
certificate profiles will be the subject of a separate document, as per the
recommendation of the WG chairs.

Time Stamping Protocol (D. Pinkas-Bull)
Denis has taken over as editor for this work, from R. Zuccherato.  A new
draft (version 2) was posted just prior to the IETF. Major revisions
include the scope of the protocol, removal of TDA support, moving status
outside of the signed token per se, removal of support for sequence of
hashes, format of TST time, etc.  Choice of TST format uses GeneralisedTime
plus sub-second granularity as a separate component, taken directly from
NTP. But this second component is primarily used as a means to serialize
time stamps within a one-second interval, not specifically to offer highly
precise time stamps. The question was raised whether it is appropriate to
make dual use of this field, i.e., for sub-second accuracy and for
serialization. Alternative is to use GeneralizedTime to millisecond
accuracy, and then use serial number for further serialization. This needs
to be resolved on the list.

Denis observed that time stamping is an area rife with intellectual
property claims.  A list of patents in this area, provided by Denis,
illustrates the recent history in this area (back to 1989).  It is noted
that a submission to ISO in April 1989, in part of work on a
non-repudiation framework, constitutes early published work in this area,
perhaps calling into question some of the most general patents on time
stamping.  Work will continue to resolve the cloud that hangs over this
work item. (See slides for additional details.)

Data Certification Server Protocol (C. Adams-Entrust)
Peter Sylvester is the new lead editor and a new I-D has been published as
of this week. Scope has been pretty broad, encompassing features of
notarization OCSP, SCVP, TSP, etc. So, this is an example of the question
raised on the list with regard to different protocols for different
services, or a grand unified protocol approach. Possible options include
freezing this spec now as an experimental protocol, reduce scope to avoid
conflicts with other work items and continue as a standard track protocol,
or keep broad scope and kill other protocols. Denis notes that, from a
conformance standpoint, bundling would create the need to allow subset
compliance, since not all clients or servers will need all of the features
offered by a unified protocol. Discussion explored the dimensions in which
one may choose to partition protocols, e.g., mandatory use of a server for
non-repudiation vs. optional use of a server for operations that could be
performed by a client.

Simple Certificate Validation Protocol (P. Hoffman-VPN & A. Malparni-Valicert)
Questions arise about many different parts of this proposal, including use
of the "tiny" syntax, choice of higher level encapsulation formats, support
for non-X.509 (OPGP) certificates, etc.  The authors agreed to delete the
tiny syntax for now, due its controversy. (One WG chair pointed out that
support for other than X.509 certificates is not within scope for PKIX.
Members of the OPGP WG question this position, asserting that the IESG
precluded OPGP from pursuing its own PKI work. This needs to be addressed
via discussion with the security ADs.) Denis and others provided more
detailed criticism. A straw poll of attendees shows did not show clear
consensus for or against the general notion of offloading certificate
processing from a client. Discussion of this topic will continue on the
list, and a new draft (minus the tiny syntax) will be published.

Qualified Certificates (S. Santesson)
A new draft will be posted in the next two weeks, reflecting the latest set
of changes based on mailing list discussions.  Highlights of this new draft
include: "de-legalization" of scope of the document, explicit syntax for
representing pseudonyms, an extension for inclusion of a hash of biometric
data (for human verification), and a new extension for marking a
certificate as qualified (via reference to an OID) and for expressing
reliance limits, separate from the use of the policy extension.  The author
requested that a WG last call be issued, after the list has had a chance to
review this latest version.


Other Topics:

LDAPv3 Profile (D. Chadwick- University of Salford)
Description of what features of LDAP v3 are relevant to PKIX and thus why a
profile is needed. This is especially important because LDAP v2 is being
phased out as an IETF standard and PKIX must migrate to v3.  The author is
soliciting comments from the list, and will co-ordinate with the LDAP WG as
well.

Attribute Certificates	(S. Farrell-SSE)
Stephen briefly reviewed the document, which profiles the X.509 AC.
Several WG members discussed appropriate forms of linkage between the AC
and the PKC, i.e., name vs. certificate or key hash, vs. issuer and serial
#, revisiting a debate on the list. This discussion did not resolve the
debate. General agreement to include a standard attribute set, but still
need to resolve details of these attributes, and must require support for
creation of new AC extensions. Questions were raised whether a new,
lightweight protocol is needed pull ACs, vs. use of LDAP, as an adjunct to
the push model that now underlies the AC use model.  Straw poll showed
overwhelming support to remove the retrieval protocol from the document.
This document defines the base profile, plus extensions that are optional.
The WG needs to work out details of what is base vs. extension. Do we need
an extension in the AC authority's public key certificate to characterize
what the authority is authorized to issue what ACs, or should this be done
via an attribute certificate itself?

Basic Event Representation Token (M. McNeil-GMT)
The author notes that this proposal relates to the TSP work, but uses what
is believed a more compact format so that it may be used in environments
where the size of the response from a TSA is too big. The primary use model
provided here is rather implementation-specific, i.e., tamper-evident
hardware in a local context, vs. a TSA accessible via a network.  A
Security AD raised questions about any intellectual property claims
associated with this model, as this may affect whether the proposal is
appropriate for an IETF WG. The speaker stated that he is aware of no IP
with regard to the proposed formats, etc. A PKIX WG chair expressed concern
over the apparent product-specific nature of the proposed model.  The
author acknowledges that only one vendor (Datum) offers the sort of
hardware cited as the primary use example. The WG chairs and the Security
ADs will discuss whether this work is appropriate for PKIX, given the
issues cited above.

CMP Interoperability Testing	(R. Moskowitz-ISSA)
Bob reported results of four classes of testing for 5 CMP implementations,
conducted by ICSA and NIST. The next workshop will continue and expand
testing.  One lesson from this work is that the CMP RFC fails to mandate
defaults in many instances, which reduces interoperability.  Bob's analysis
of this testing is that we need more MUSTs in this standard!  One security
concern arose, with regard to the size of the salt used in registration.

Temporal Data Token (M. Duren-WetStone)
Presentation focused on format for TDT (in the TSA) that helps attest to
the integrity of the time source, i.e., providing a link to a trusted time
source. This approach pushes evidence of time source into a token, vs.
other, external measures that a TSA takes to ensure the accuracy and
integrity of its time source. A claimed feature of this approach is that it
allows a client to be able to verify the utility (for non-repudiation) of
the returned token immediately, vs. the deferred verification more typical
of TSA operation. As with the BERT presentation, the speaker was asked
about possible intellectual property claims and about the breadth of vendor
support for the propose TDT format.  The speaker asserted that he was aware
of no IP claims, and that he was aware of at least two vendors who had
expressed interest in this format, although no more than one was building
products to this spec at this time.  The WG Chairs and the Security ADs
also will need to discuss whether this is within the scope of PKIX, before
this item progresses.



Received: from mail.spyrus.com (mail.spyrus.com [207.212.34.30]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id KAA06590 for <[e-mail]>; Mon, 19 Jul 1999 10:03:03 -0700 (PDT)
Received: from rhousley_laptop.spyrus.com ([209.172.119.101]) by mail.spyrus.com (8.9.3/8.9.3) with ESMTP id KAA20299; Mon, 19 Jul 1999 10:00:01 -0700 (PDT)
Message-Id: <[e-mail]>
X-Sender: [e-mail] (Unverified)
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58 
Date: Mon, 19 Jul 1999 13:01:25 -0400
To: "Vickers, Randal R" <[e-mail]>
From: Russ Housley <[e-mail]>
Subject: Re: Showing Nationality in Cert
Cc: "PKIX Mailing List (E-mail)" <[e-mail]>, "Flanigan, Bill" <[e-mail]>, "Friedrichs, Paul" <[e-mail]>, "Nelson, Lee" <[e-mail]>, "Sam Schaen (E-mail)" <[e-mail]>, "Jamil Nimeh (E-mail)" <[e-mail]>
In-Reply-To: <[e-mail].d isa.mil>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed

I recommend SubjectDirectoryAttribute.

Russ


At 10:40 AM 7/17/99 -0400, Vickers, Randal R wrote:
>I work with the US DoD PKI engineers at the Defense Information Systems
>Agency. Requirements from the Assistant Secretary of Defense for C3I state
>that we must show citizenship or nationality (symantics) in the cert. My
>question is what extension  does anyone reccommend placing it in. We have
>looked at subjectDirectoryattribute and one of the extensions below
>subjectAlternatename. We are not locked into any one thing as long as it is
>standards based.
>         Thanks
>         Randal Vickers



Received: from ctron-dnm.ctron.com ([e-mail] [12.25.1.120]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id JAA06078 for <[e-mail]>; Mon, 19 Jul 1999 09:31:23 -0700 (PDT)
Received: (from uucp@localhost) by ctron-dnm.ctron.com (8.8.7/8.8.7) id MAA06938; Mon, 19 Jul 1999 12:35:12 -0400 (EDT)
Received: from roc-mail2.ctron.com(134.141.72.230) by ctron-dnm.ctron.com via smap (4.1) id xma006911; Mon, 19 Jul 99 12:35:09 -0400
Received: from new-exc1.ctron.com (NEW-EXC1 [134.141.200.123]) by roc-mail2.ctron.com (8.8.7/8.8.7) with ESMTP id MAA27921; Mon, 19 Jul 1999 12:38:49 -0400 (EDT)
Received: by new-exc1.ctron.com with Internet Mail Service (5.5.2448.0) id <38L708B9>; Mon, 19 Jul 1999 17:32:54 +0100
Message-ID: <[e-mail]>
From: "Waters, Stephen" <[e-mail]>
To: Anders Rundgren <[e-mail]>
Cc: [e-mail]
Subject: RE: KISS for PKIX. (Was: RE: ASN.1 vs XML (used to be RE: I-D 	 A CTION :draft-ietf-pkix-scvp- 00.txt))
Date: Mon, 19 Jul 1999 17:32:53 +0100
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2448.0)
Content-Type: text/plain; charset="iso-8859-1"

That sounds hopeful. I have no experience of the self-defense mechanisms
available with Smartcards, but something like the self-block you mention
sounds the like the job.  I guess for VPN clients that generate/store
private keys on disk with password/pin protection (encrypted), things are
slightly more exposed.  The file could be worked on independently of the
client code.  The VPN client should support some sort of key crippling if it
gets the wrong answer too many times I guess, but Smartcards would be
better.

I think I'd be happy with self-crippling Smartcards. If I didn't have that,
I'd require secondary authentication to provide the VPN server with a chance
at spotting a break-in attempt.

This concern opens up an issue with SOHO VPN devices I feel. If I have a
SOHO router loaded with a certificate used to connect a LAN-LAN VPN tunnel,
and my home is burgled while I'm on holiday, the thief has all he needs to
break in. It would be a pain to have to access a console in order to unlock
the private key each time I powered up the router, but that seems to be a
possible security policy requirement.  I guess I wouldn't mind pressing my
thumb on a Smartcard each morning until 'the green light came on'.  

Thanks, Steve.


-----Original Message-----
From: Anders Rundgren [mailto:[e-mail]]
Sent: Monday, July 19, 1999 2:59 PM
To: Stephen Kent; 'Waters, Stephen'; '[e-mail]'
Subject: RE: KISS for PKIX. (Was: RE: ASN.1 vs XML (used to be RE: I-D
ACTION :draft-ietf-pkix-scvp- 00.txt))


Stephen W,
<snip>
>As an example, I am using a certificate Smartcard with a pin-number
>protected private key for VPN access to my head office.  If the laptop and
>smartcard are stolen, the thief can play with them until he has cracked the
>pin number. The thief can do this off-line with no contact with the VPN
>server. Once cracked, they can connect to the Internet, and contact the VPN
>server.

Is it that easy?
I doubt that a thief can "play" with the smart-card until he/she cracks the
PIN-code.

After lets say tree tries most smart-cards become  "neutralized" and
requires a
much harder PUK-code to be reactivated.  It is also easy for a smart-card
to introduce a for a human negligible delay that makes computerized attacks
less fruitful.

The only method I know of requires opening the chip and manipulations at
silicon-
level.  This is not for everybody.

Anders



Received: from netgate.csoft.bg ([e-mail] [193.68.191.129]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id IAA05169 for <[e-mail]>; Mon, 19 Jul 1999 08:22:56 -0700 (PDT)
Received: from DARKSTAR (darkstar.csoft.bg [193.68.191.130]) by netgate.csoft.bg (8.9.3/8.9.3) with SMTP id PAA18049; Mon, 19 Jul 1999 15:23:28 GMT
Message-ID: <029701bed1fb$6827d530$[e-mail]>
From: "Nedelcho Stanev" <[e-mail]>
To: "Sayeh Sadat" <[e-mail]>, <[e-mail]>
Subject: Re: Request For Help .
Date: Mon, 19 Jul 1999 18:28:52 +0300
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_0294_01BED214.8D5688B0"
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.00.0707.2700
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.0707.2700

This is a multi-part message in MIME format.

------=_NextPart_000_0294_01BED214.8D5688B0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Hya,

Some info you can get from
http://www.csoft.bg/int-docs/security.htm
http://www.csoft.bg/int-docs/internic.htm
http://www.csoft.bg/int-docs/security/ietf/pkix-charter.htm

Best wishes,
Nedelcho Stanev
-------------------------------------------------------------------------=
---------------------
CSoft Ltd
[e-mail]                            ICQ:188674
http://www.csoft.bg/decho                tel:++359-52-602-844=20
-------------------------------------------------------------------------=
---------------------
  -----Original Message-----
  From: Sayeh Sadat <[e-mail]>
  To: <[e-mail]>
  Date: 19 =DE=EB=E8 1999 =E3. 17:05
  Subject: Request For Help .
 =20
 =20
  Dear Sir/Madam ,
  =20
      I am writing to ask you for a help if possible . I study =
communication electronics in " Sharif University Of Technology " of Iran =
. My final project is about " Public Key Cryptography " and I am looking =
for any kind of information relative to this topic .
  =20
      Unfortunately , there is not enough source of information on this =
subject in my country , Iran . So , could you please possibly send me =
any relative information including articles , useful sites offering such =
informations and other useful sources .
  =20
      I would be very grateful if you help me . I am looking forward to =
receiveing any information from you .
  =20


------=_NextPart_000_0294_01BED214.8D5688B0
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"><HTML>
<META content=3D'"MSHTML 5.00.0707.2700"' name=3DGENERATOR>
</HEAD>
<BODY bgColor=3D#ffffff>
<DIV><FONT size=3D2>Hya,</FONT></DIV>

<DIV><FONT size=3D2></FONT>&nbsp;</DIV>

<DIV><FONT size=3D2>Some info you can get from</FONT></DIV>

<DIV><FONT size=3D2></FONT><FONT size=3D2><A=20
href=3D"http://www.csoft.bg/int-docs/security.htm">http://www.csoft.bg/in=
t-docs/security.htm</A></FONT></DIV>

<DIV><FONT size=3D2><A=20
href=3D"http://www.csoft.bg/int-docs/internic.htm">http://www.csoft.bg/in=
t-docs/internic.htm</A></FONT></DIV>

<DIV><FONT size=3D2><A=20
href=3D"http://www.csoft.bg/int-docs/security/ietf/pkix-charter.htm">http=
://www.csoft.bg/int-docs/security/ietf/pkix-charter.htm</A></FONT></DIV>

<DIV><FONT size=3D2></FONT>&nbsp;</DIV>

<DIV><FONT size=3D2>Best wishes,</FONT></DIV>

<DIV><FONT size=3D2>
<DIV><FONT color=3D#000000 size=3D2>Nedelcho=20
Stanev<BR>---------------------------------------------------------------=
-------------------------------<BR>CSoft=20
Ltd<BR><A=20
href=3D"mailto:[e-mail]">[e-mail]</A>&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;&nbsp;=20
ICQ:188674<BR><A=20
href=3D"http://www.csoft.bg/decho">http://www.csoft.bg/decho</A>&nbsp;&nb=
sp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;=20
tel:++359-52-602-844=20
<BR>---------------------------------------------------------------------=
-------------------------</FONT></DIV>
</FONT></DIV>

<BLOCKQUOTE=20
style=3D"BORDER-LEFT: #000000 2px solid; MARGIN-LEFT: 5px; PADDING-LEFT: =
5px">
  <DIV><FONT face=3DArial size=3D2><B>-----Original =
Message-----</B><BR><B>From:=20
  </B>Sayeh Sadat &lt;<A=20
  =
href=3D"mailto:[e-mail]">[e-mail]</A>&gt;<BR><B=
>To:=20
  </B>&lt;<A=20
  =
href=3D"mailto:[e-mail]">[e-mail]</A>&gt;<BR><B>Date: =
</B>19=20
  &THORN;&euml;&egrave; 1999 &atilde;. 17:05<BR><B>Subject: </B>Request =
For Help=20
  .<BR><BR></DIV>
  </FONT>
  <DIV>
  <DIV><FONT size=3D2>Dear Sir/Madam ,</FONT></DIV>

  <DIV><FONT size=3D2></FONT>&nbsp;</DIV>

  <DIV><FONT color=3D#000000 size=3D2>&nbsp;&nbsp;&nbsp; I am writing to =
ask you for=20
  a help if possible . </FONT><FONT color=3D#000000 size=3D2>I study =
communication=20
  electronics in &quot; Sharif University Of Technology &quot; of Iran . =

  </FONT><FONT color=3D#000000 size=3D2>My final project is about &quot; =

  <STRONG><EM><U>Public Key Cryptography</U></EM></STRONG> &quot; and I =
am=20
  looking for any kind of information relative to this topic =
.</FONT></DIV>

  <DIV><FONT color=3D#000000 size=3D2></FONT>&nbsp;</DIV>

  <DIV><FONT color=3D#000000 size=3D2>&nbsp;&nbsp;&nbsp; Unfortunately , =
there is=20
  not enough source of information on this subject in my country , Iran =
.=20
  </FONT><FONT color=3D#000000 size=3D2>So , could you please possibly =
send me any=20
  relative information including articles , useful sites offering such=20
  informations and other useful sources .</FONT></DIV>

  <DIV><FONT color=3D#000000 size=3D2></FONT>&nbsp;</DIV>

  <DIV><FONT color=3D#000000 size=3D2>&nbsp;&nbsp;&nbsp; I would be very =
grateful if=20
  you help me . I am looking forward to receiveing any information from =
you=20
  .</FONT></DIV>

  <DIV><FONT color=3D#000000 size=3D2></FONT>&nbsp;</DIV>

  <DIV>&nbsp;</DIV>
  </DIV>
</BLOCKQUOTE>
</BODY></HTML>

------=_NextPart_000_0294_01BED214.8D5688B0--



Received: from btec-fw.certco.com (btec-fw.certco.com [209.2.102.3]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id IAA04896 for <[e-mail]>; Mon, 19 Jul 1999 08:10:44 -0700 (PDT)
From: [e-mail]
Received: from panga.ny.certco.com (panga.ny.certco.com [192.168.69.21]) by btec-fw.certco.com (Postfix) with ESMTP id E303332DDE; Mon, 19 Jul 1999 11:11:57 -0400 (EDT)
Received: from nycertco-srv1.ny.certco.com (nycertco-srv1.ny.certco.com [192.168.69.12]) by panga.ny.certco.com (Postfix) with ESMTP id 8F25254001; Mon, 19 Jul 1999 11:11:57 -0400 (EDT)
Received: by nycertco-srv1.ny.certco.com with Internet Mail Service (5.5.2232.9) id <3X8ZL3SZ>; Mon, 19 Jul 1999 11:11:57 -0400
Message-ID: <[e-mail]>
To: [e-mail], [e-mail]
Cc: [e-mail]
Subject: RE: KISS for PKIX. (Was: RE: ASN.1 vs XML (used to be RE: I-D 	 	 ACTION :draft-ietf-pkix-scvp- 00.txt))
Date: Mon, 19 Jul 1999 11:11:55 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2232.9)
Content-Type: text/plain; charset="iso-8859-1"

Lynn Wheeler is correct. In a closed system (e.g., a home banking system),
it is possible to compress all certificates to zero bytes (i.e., just use
public keys).

Certificates can be used to construct trust hierarchies. Public keys can
not.

The reason SSL is primarily used for comfort is not because there is
something wrong with certificates, it is because the necessary certificate
management infrastructure does not exist. Imagine today's use of SSL without
certificates -- system administrators would be installing large numbers of
raw public keys into browsers, not a few CA certificates.

Frank Balluffi
CertCo

-----Original Message-----
From: [e-mail] [mailto:[e-mail]]
Sent: Saturday, July 17, 1999 4:27 PM
To: Stephen Kent
Cc: '[e-mail]'
Subject: Re: KISS for PKIX. (Was: RE: ASN.1 vs XML (used to be RE: I-D
ACTION :draft-ietf-pkix-scvp- 00.txt))


a cert-less approach is relatively trivial to apply across the
corporate electronic environment. register the employees public
key in a RADIUS administrative data-base (i.e. RA by any other
name) and use RADIUS protocol for all corporate authentications
i.e. existing RADIUS based authentication and straight forward
apply RADIUS protocol to future applications.

This even works in SSL and other types of environments. Consumer's
authentication at the server is done with RADIUS account-base.

This doesn't say anything about eliminating web server comfort
certificates ... for setting up SSL sessions ... just addresses issue
of authenticating individuals in environments that are really account-base
operation.

The RADIUS protocol also addresses things like permissions
... again not carrying sensitive individual information in credentials
like certificates ... but going to the account record to obtain the
permissions and operational characteristics.

as alwas choice is:

1) fully defined, identity certificate

2) relying-party-only certificate where the transaction has to
hit the account record.

either all the necessary information is in the certificate or the
certificate contains only enuf information to be able to get
to the account record. if the operation has to hit the accound
record anyway ... then it is trivial to show that the certificate
is redundant and superfulous.

it wasn't intended to be a red herring statement ... it was a
statement that is was one or the other ... either all the necessary
information is in the certificate (in which case the certificate can
represent a privacy and/or security issue) or the information is
in an account record (in which case the certificate is superfulous
and redundant).

this of course, doesn't apply to saying that the merchant comfort
certificates (using for setting up SSL sessions) are unnecessary
... but that almost all cases that the certificates for employees
and individuals ... tend to either 1) divulge privacy/confidential
information or 2) have to hit an account record.



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 HAA04495 for <[e-mail]>; Mon, 19 Jul 1999 07:52:36 -0700 (PDT)
Received: from mentat.verisign.com by caladan.verisign.com (8.8.5/BCH1.5) id HAA05860; Mon, 19 Jul 1999 07:52:34 -0700 (PDT)
Received: from newman.verisign.com by mentat.verisign.com (8.8.5/BCH1.0) id HAA05683; Mon, 19 Jul 1999 07:53:46 -0700 (PDT)
Received: by newman.verisign.com with Internet Mail Service (5.5.2448.0) id <N7XWGBLH>; Mon, 19 Jul 1999 07:53:47 -0700
Message-ID: <[e-mail]>
From: Michael Myers <[e-mail]>
To: [e-mail]
Subject: RE: SCVP Analysis
Date: Mon, 19 Jul 1999 07:53:43 -0700
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2448.0)
Content-Type: text/plain; charset="iso-8859-1"

Ambarish,

Responses embedded below, included text abbreviated for clarity.

> > > > All,
> > > >
> > > > The SCVP draft raises some interesting questions
> > > which deserve discussion
> > > on
> > > > the list.  Below are some thoughts to get that
> > > started.  Having gone
> > > through
> > > > this process, it's very clear to me at least that
> > > needs for delegated path
> > > > validation can more easily be met with a very
> > > simple extension to OCSP.
> > > The
> > > > work would be very minimal compared to
> > > implementing a totally different
> > > > protocol to do exactly the same thing.
> 
> Mike, I think we disagree about this topic. OCSP
> was designed to do cert status checking and it does that
> very well. It was never meant to take over the job
> of cert chain building or make trust decisions for the
> client.

I've already established a response to this position in my response to
Paul's comments.  The semantic definition of the "good" response clearly
reflects an intent for OCSP to address validation mechanisms using
extensions.  That the current RFC reads as it does reflected an intermediate
need to direct immediate attention at solving the revocation problem.   That
is a stop along the way, very much like defining a base certificate
structure first and then moving on to the more sophisticated extension
concepts.

To your second sentence, taking the entire set of trust decisions for
clients seems a bit out scope for PKIX.  I'm willing to be convinced
otherwise, but I wonder if that view is widely shared.  I'm thinking
specifically of IPSEC clients and their rich set of needs for security
policy enforcement.  Somewhere we have to draw the line at what is X.509 PKI
and what more legitimately within the scope of security applications.

> 
> Yes, you could merge the syntaxes of OCSP and SCVP, but
> I am not sure that would be a good approach. I actually
> see the OCSP server responding for the CA, while the
> SCVP responder, would normally sit in an organization
> and implement the security policy of the organization.
> 

You may recall that OCSP very early on established the concept of an
Authorized Responder.  This extension of then-accepted trust models enabled
OCSP to be used by trusted entities other than CAs to speak to the
reliability of a certificate.  For example, it enables banks to produce
digitally signed responses regarding the reliability of a certificate for a
given online transaction.  Indeed, this constituency was influential in
shaping the emergence of this architecture.

It's interesting however that you should characterize SCVP more as a
security policy enforcement solution.  I'll have to add that to my taxonomy
of problems the protocol is intending to solve.  That is:

1.  Delegated Path validation;
2.  Lightweight PKI data access;
3.  Remote certificate parsing; and now
4.  Security Policy enforcement

I can't dispute the existence of a need to establish a standard means of
facilitating security policy enforcement.  If this is indeed your objective,
which I assume it is now that you've mentioned it, then perhaps we can
collaborate on the clarifying the requirements implicit in an online
security policy enforcement protocol and in so doing reduce if not eliminate
the confusion that SCVP creates regarding online validation of digital
certificate reliability.

> 
> > > >
> > > > Mike
> > > >
> > > > REQUEST SYNTAX AND SEMANTICS
> > > >
> > > > 1.  Optional use of a RequestHash  in lieu of a
> > > digitally signed request.
> > > >
> > >
> > 
> ----------------------------------------------------------------------
> > > > The need to integrity-protect the request hasn't
> > > been established.  How is
> > > > this request-response protocol different from,
> > > say, LDAP?
> > > >
> > > > It seems that requestHash is actually presumed to
> > > be sufficient for the
> > > > non-repudiation needs of accountability in some
> > > environments.  If so, this
> > > > needs to be made explicit and-more
> > > importantly-discussed on the list as
> > > such
> > > > a resolution impacts assumptions underlying
> > > current trade in certificate
> > > > validation services.
> > > >
> > > > If however the authors assert that the requestHash
> > > field is unreliable for
> > > > service accountability and is meant rather simply
> > > as an integrity check,
> > > the
> > > > requirement for integrity protection equally
> > > merits discussion of the
> > > > security risks being addressed.  Perhaps the
> > > authors have some insight
> > > into
> > > > security risks that were overlooked in prior PKIX
> > > protocols now standing
> > > as
> > > > RFCs.
> > > >
> > > > Should that discussion conclude that the request
> > > syntaxes of PKIX
> > > protocols
> > > > need to be integrity protected, it seems we may
> > > need to amend the
> > > > request-response protocols PKIX has currently sent
> > > up to IESG which do not
> > > > provide such protection.
> > > >
> > > > Should that discussion otherwise conclude that
> > > certificate validation
> > > > protocols are unique among other protocols in
> > > their need for integrity
> > > > protected requests, at a minimum this may affect
> > > RFC 2560 (OCSP), which
> > > > bears a striking architectural similarity to the
> > > proposed protocol.
> > > >
> > > > In the absence of resolution of either of these
> > > positions, the
> > > functionality
> > > > seems superfluous.
> 
> No, the requstHash is not superfluous or arbitrary. And
> no, you don't need to add it to an OCSP request.
> 
> The purpose of the requestHash is to prevent a man
> in the middle from changing the request (if it is an
> unsigned request). The reason this is important for
> SCVP (and wasn't so for OCSP), is that we allow a client
> to specify the trusted roots and the usage he
> wants to trust a cert for.

So a note clarifying that the hash SHOULD NOT be taken as an authentication
mechanism for the purposes of service accountability would help to make this
point more clear.  To further enforce this, put the hash in the root
specification syntax.  It's otherwise predictable that the hash will be
taken as a de-facto request authentication mechanism regardless of the
content of the request.

> Also, if a client doesn't need
> the chain the responder built, it is very likely that it
> will *not* ask the responder to return this chain, or check
> it if it is returned. In this case, if a person could get
> in between the client and the server, he could arbitrarily
> change the request to get the client to server any set of
> roots - not something we would like to encourage :-)

Could you please try again to explain the above in different words?  It's
difficult to follow your line of reasoning.  I believe what you are claiming
is that use of a SHA-1 hash in and of itself enables detection of
modification of a request by a malicious third party.  Correct?

> 
> In OCSP, the client is expected to make sure that the
> response corresponds to the request, by making sure that the
Ø CertID in the response matches that of the request.

That's certainly one way of doing it.  One could also use the nonce
extension in OCSP to match received responses to prior requests.

> 
> Hope this clarifies things.

Not entirely.

> > > >
> > > > 3.  Optional inclusion of the subject certificate
> > > in the request.
> > > >
> > > ----------------------------------------------------------------
> > > > This seems to be a reasonable requirement.
> I don't think this is optional. The client *must* include the
Ø subject certificate. I think the text specifically states that.

I inferred the optionality from the following syntax:

FullRequest ::= SEQUENCE {
    . . . 
    certsQuery           CertsQuery,
    . . . 
}

CertsQuery ::= SEQUENCE {
    certBundle        CertBundle,
    . . . 
}

CertBundle ::= SEQUENCE OF CertItem

CertItem ::= CHOICE {
    fullCert      [0] Cert,
    certID        [1] CertID
}

So it appears that one has a choice of cert or certID.

> 
> Paul, I think we should make the text more obvious - I missed that
> the first time also.
> 
> > > >
> > > > 6.  Optional specification of intermediate
> > > certificates to use as a
> > > > supplement to the validation path of the subject
> > > certificate.
> > > >
> > > ----------------------------------------------------------------
> > > > In the context of the legal framework underpinning
> > > the use of certificates
> > > > for electronic commerce, the issuer of a
> > > certificate issued that
> > > certificate
> > > > with a very specific trust chain model in mind.
> > > >
> > > > The proposed functionality seems to suggest that
> > > the authors are asking
> > > PKIX
> > > > to support the notion of the "re-purposing" of
> > > certificates for uses
> > > beyond
> > > > those intended by the original issuer.
> > > >
> > > > Was this the authors' intent?  If not, then what
> > > problem is this proposed
> > > > functionality solving?
> 
> Nothing so deep or fundamental. It is quite possible that
> the client has obtained some intermediate certs as part
> of its communication with the cert holder (e.g. you can
> get a cert chain in SSL). These certs might not be easily
> accessible to the SCVP responder, since it might not know
> where to go for these intermediate certs. The purpose of
> passing these certs to the responder is to make its chain
> building task easier. There was no intent to subvert the
Ø issuer's intent.

As I noted in a response to Paul, addition clarity and precision would be
useful here.

> > > >
> > > > 7.  Optional specification of trusted roots the
> > > server must rely on.
> > > >
> > > ----------------------------------------------------------------
> > > > Same issue as above.
> > > >
> > > > Is it the authors' proposition that the issuer of
> > > a certificate is *not*
> > > the
> > > > final arbiter of the trustworthiness of that
> > > certificate?  (noting that
> > > > "issuer" could be an entity that directs another
> > > entity to manufacture and
> > > > distribute a certificate on its behalf).
> 
> Again Mike, nothing very deep and fundamental here. It is
> quite possible that the SCVP client has a set of roots/certs it
> trusts. It might want all chains built to that/those roots,
> rather than to any roots the responder might choose to trust.
> 

This makes sense in a cross-certified context, but other than that, a client
can't force a subject certificate to somehow validate under an arbitrary
root.  What entity signed the CA certificate needed to validate the
signature on the subject certificate, a process I presume is carried out at
the server?  And what entity signed that CA certificate, such that the
server can competently complete that signature validation?

I think this concept of clients sending in arbitrary roots needs a good deal
more clarity and precision against generally accepted PKI practices.  If you
say it was expected to be used in the context of cross certification, fine.
But that's not what I hear you saying quite yet.

> > > >
> > > > RESPONSE SYNTAX AND SEMANTICS
> > > >
> > > > 10.  "Unrecognized" error codes related to the
> > > above optional request
> > > > protocol elements.
> > > >
> > > ----------------------------------------------------------------
> > > > No issues, other than alignment with the prior
> > > analysis.
> > > >
> > > > 11.  Validation response values for "valid",
> > > "notValid",
> > > > "temporarilyUnknown" and "unknown".
> > > >
> > > ----------------------------------------------------------------
> > > > This seems to be a reasonable requirement.
> > > >
> > > > Except perhaps for "temporarilyUnknown".  What
> > > does a client do with that?
> 
> "temporarily unknown" is a way for a server to say
> that it does normally know about that particular cert, but can't
> provide an answer right now - for example if it can build the
> chain, but not obtain revocation proof. The client can infer
> that it can go back to the server at a later time with similar
> certs.
> 

In the case you cite, would not it be more accurate to identify that
particular state as "revocationProofUnavailable"?  That at least is a
reasonably unambiguous response for a client to represent in a UI.  In the
face of a response that makes it clear that the response isn't backed by
access to revocation data, the user of the client can make up her own mind
whether or not to trust the subject certificate anyway.

But I'm having a hard time trying to imagine what a client would present in
a UI to a user upon receipt of "temporarilyUnknown".  One thing is certain:
a literal translation of this state into a UI is not going to meet usability
concerns of PKI I hear about daily.  If anything, we need to work
aggressively to reduce this kind of UI noise.

> > > >
> > > > 16.  Optional use of a digital signature
> > > >
> > > ----------------------------------------------------------------
> > > > This is the same as OCSP: some error conditions
> > > don't need to be signed.
> > > > However, the proposed protocol goes on to assert
> > > that other types of
> > > > responses don't need to be signed if conveyed over
> > > a secure channel.
> > > >
> > > > An optional signature on an affirmative response
> > > is equivalent to an
> > > > unsigned CRL.  It can't be used to support
> > > non-repudiation.
> 
> Again, it depends on what the client is using SCVP for.
> If it is using SCVP in an intranet mainly for policy
> management, it might not care whether the response is
> signed or not. If non-repudiation is important, the
> client will need a signed response.

This specific principle was brought up very early on in the OCSP design.  
The fact is, unsigned responses so easily enable insider attacks against
other insiders that the security assurances claimed by the technology are
embarassingly baseless.  Remember, it's not just non-repudiation, but strong
authentication we also get from digital signatures.

We are responsible for engineering across the Internet.  As soon as one sets
an intranet context, there are numerous ways of addressing these
requirements, including the use of LDAP and its various authentication
schemes, signed attributes, etc.  That problem's been solved.  That dirt's
been dug.  It's the Internet problem we are chartered to deal with.



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 HAA04302 for <[e-mail]>; Mon, 19 Jul 1999 07:47:46 -0700 (PDT)
Received: from mentat.verisign.com by caladan.verisign.com (8.8.5/BCH1.5) id HAA05678; Mon, 19 Jul 1999 07:47:44 -0700 (PDT)
Received: from newman.verisign.com by mentat.verisign.com (8.8.5/BCH1.0) id HAA05495; Mon, 19 Jul 1999 07:48:55 -0700 (PDT)
Received: by newman.verisign.com with Internet Mail Service (5.5.2448.0) id <N7XWGBK1>; Mon, 19 Jul 1999 07:48:58 -0700
Message-ID: <[e-mail]>
From: Michael Myers <[e-mail]>
To: IETF PKIX list <[e-mail]>
Subject: RE: SCVP Analysis
Date: Mon, 19 Jul 1999 07:48:56 -0700
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2448.0)
Content-Type: text/plain; charset="iso-8859-1"

Paul,

To  your other points, you wrote:

>>4.  Optional support for PGP style public key management.
>>----------------------------------------------------------------
>>As discussed on the floor in Oslo, inclusion of this functionality would
>>require a revision to the PKIX charter.  PKIX was specifically established
>>to address X.509 certificates.
>
>I would have hoped you would have read the charter before making a 
>statement like this. In fact, the charter says nothing of the sort; if you 
>disagree, please quote the charter.
>
>In fact, the charter does say "This project will not preclude use of 
>non-infrastructural public-key distribution techniques nor of non-X.509 
>PKIs by such applications." That seems pretty clear. If you want to try to 
>revise the charter to remove this, go ahead, but don't claim it doesn't say

>it in the current charter.

Actually, I was just reflecting what I thought heard on the floor.  We'll
have to wait for the minutes to know for sure.

But for a fuller context, the charter also states:

"The task of the working group will be to develop Internet standards needed
to support an X.509-based PKI. The goal of this PKI will be to facilitate
the use of X.509 certificates in multiple applications which make use of the
Internet and to promote interoperability between different implementations
choosing to make use of X.509 certificates."

And, to provide more context to your excerpt:
"Candidate applications to be served by this PKI include, but are not
limited to, PEM, MOSS, GSS-API mechanisms (e.g., SPKM), ipsec protocols,
Internet payment protocols, and www protocols. This project will not
preclude use of non-infrastructural public-key distribution techniques nor
of non-X.509 PKIs by such applications.

So this issue might reduce down into answering the question "What does 'not
preclude' mean with respect to "such applications"?  A more restrictive
interpretation might infer that PKIX's existence should not be taken by
other WGs as the only means of dealing with public-key technology.  That is,
OpenPGP is free to do what they want, as is TLS, IPSEC, etc.  Thus PKIX was
chartered to ensure that those applications were well-equipped to use an
X.509-based PKI if they chose to.

I suspect this might have been the intent, but this is clearly an issue for
the chairs to resolve.

>>6.  Optional specification of intermediate certificates to use as a
>>supplement to the validation path of the subject certificate.
>>----------------------------------------------------------------
>>In the context of the legal framework underpinning the use of certificates
>>for electronic commerce, the issuer of a certificate issued that
certificate
>>with a very specific trust chain model in mind.
>>
>>The proposed functionality seems to suggest that the authors are asking
PKIX
>>to support the notion of the "re-purposing" of certificates for uses
beyond
>>those intended by the original issuer.
>
>It only "seems to suggest" this to you; no one else seems to have read it 
>this way.
>
>>Was this the authors' intent?  If not, then what problem is this proposed
>>functionality solving?
>
>Maybe we need to make this clearer in the draft. If a client has what it 
>thinks is a chain to the root (because the cert holder has said it is a 
>chain), the client can ask the simple question "Is this really a valid
chain?"

So yes, more clarity and precision in the problem statement this
functionality is solving would help.  I read the following:

"The IntermediateCerts item specifies to the server the intermediate
certificates that the server MAY use when forming a certificate chain in
addition to any other certificates that the server knows of."

to somehow enable a client to establish reliability of the certificate under
a chain other than the one it was issued under.   More specifically, the
phrase "in addition to any other certs the server may know of" seemed to
suggest a functionality whereby the server would ignore the subject
certificates' chain which it "may know of" in favor of the one the client
provided.  Which didn't make a lot of sense, but the lack of clarity in the
problem statement led me to speculate if this was the original intent,
details to be clarified later.

What I understand now from your response and Ambarish's is that this
functionality could be used by, say, an S/MIME client which just pulls the
cert blob from SignedData and throws it all at the server.  To the extent
this blob contains a chain, that makes sense.  But if that's the case, then
what's the meaning of the phrase "in addition to any other certificates that
the server knows of?"   Also, this usage scenario strongly suggests a
SEQUENCE of cert to simplify implementation of delegated path validation on
the client side.

>>7.  Optional specification of trusted roots the server must rely on.
>>----------------------------------------------------------------
>>Same issue as above.
>>
>>Is it the authors' proposition that the issuer of a certificate is *not*
the
>>final arbiter of the trustworthiness of that certificate?  (noting that
>>"issuer" could be an entity that directs another entity to manufacture and
>>distribute a certificate on its behalf).
>
>Boy, you seem almost masterful at misreading the draft. Of course not. The 
>optional specification of trusted roots is the client's way of saying to 
>the server "I don't care who you trust, here is who I trust." This is 
>precisely what is needed for the folks who trust the server with the 
>ability to process but not to know who is a trusted root.

I've read through this several times but I'm still having some problems
trying to understand how this is intended to be used within generally
accepted PKI practices.

How precisely does the phrase "I don't care who you trust, here is who I
trust"  relate to the root the subject certificate was originally issued
under?  Especially in the absence of any cross-certification between roots?
Or, is this functionality intended to be used in cross-certification
contexts.  For example, where the recipient of a certificate issued under a
PKI external to that recipient's trust domain wants to confirm that the
subject certificate is trustworthy due to the existence of a cross
certificate between recipient and originator domains?

I think this is really just an extension of the functionality discussed in
point 6, whereby the client is the seat of all trust, the server is just a
remotely "programmable" engine and the client just sends the entire cert
chain from root to subject cert.

Or maybe not.  But it's definitely difficult at this point to try and relate
the proposed functionality to generally accepted PKI practices.

>>9.  Extensions may be critical or non-critical.
>>----------------------------------------------------------------
>>Recent experience has shown that this is inadvisable.  The XML DigSig
group,
>>for example, has specifically deprecated proposed use of critical flags
for
>>well-known reasons.
>
>And here I'll disagree with Ambarish. We put it in to match the PKIX format

>draft. I, for one, am happy to take it out if the other folks in the WG 
>think it should be removed.

Well, at least we have arrived at one point of agreement!

Mike


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 HAA04147 for <[e-mail]>; Mon, 19 Jul 1999 07:46:27 -0700 (PDT)
Received: from mentat.verisign.com by caladan.verisign.com (8.8.5/BCH1.5) id HAA05661; Mon, 19 Jul 1999 07:46:25 -0700 (PDT)
Received: from newman.verisign.com by mentat.verisign.com (8.8.5/BCH1.0) id HAA05469; Mon, 19 Jul 1999 07:47:35 -0700 (PDT)
Received: by newman.verisign.com with Internet Mail Service (5.5.2448.0) id <N7XWGBKA>; Mon, 19 Jul 1999 07:47:38 -0700
Message-ID: <[e-mail]>
From: Michael Myers <[e-mail]>
To: IETF PKIX list <[e-mail]>
Subject: Is OCSP for validation?
Date: Mon, 19 Jul 1999 07:47:36 -0700
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2448.0)
Content-Type: text/plain; charset="iso-8859-1"

Paul,

I'm going to split off the "Is OCSP for validation?" issue from the others.

You wrote:

> 
> Mike, you didn't respond to my previous statement about this, 
> so please do 
> so now: how? The semantics in the OCSP standard explicitly 
> talk only about 
> status, and not about validation. Yet now you are talking 
> about validation 
> through the extension mechanism. This is a violation of the 
> standard. You 
> can change the semantics of OCSP to handle topics other than 
> status, if you 
> want, but then it is a different protocol.

RFC2560 states:

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

Note the last sentence.

I hope for the sake of those following this debate that we don't get into
debating shades of meaning, what is a "positive statement about . . .
validity" and what does the "etc." mean.

But in the end, the last sentence, along with the extensibility hooks in the
ASN.1, clearly establishes a basis for extension-based validation
mechanisms.  Yes, it might only be one sentence, but it reflects a great
deal of debate on the issue.  This resolution allowed the WG to solve the
revocation problem more quickly while positioning ourselves to incrementally
advance that framework forward to the more interesting validation problem,
should the group decide to take it on.  It's clear we do.

I believe what you might be reacting to is the fact that since the basic
response type is mostly about access to revocation information, alternative
response types must as well.  In fact, there is no such constraint asserted
in RFC2560 on this point, nor is such absence a defect.  The above sentence
reflects why.

Mike


Received: from csmes.ncsl.nist.gov (csmes.ncsl.nist.gov [129.6.54.2]) by mail.proper.com (8.8.8/8.8.5) with SMTP id HAA03744 for <[e-mail]>; Mon, 19 Jul 1999 07:31:22 -0700 (PDT)
Received: from thunderbolt.ncsl.nist.gov (thunderbolt.ncsl.nist.gov [129.6.54.130]) by csmes.ncsl.nist.gov (8.6.12/8.6.4jck0) with SMTP id KAA21084; Mon, 19 Jul 1999 10:32:50 -0400
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (32)
Date: Mon, 19 Jul 1999 10:35:08 -0400
To: "Vickers, Randal R" <[e-mail]>, "PKIX Mailing List (E-mail)" <[e-mail]>
From: Bill Burr <[e-mail]>
Subject: Re: Showing Nationality in Cert
Cc: "Flanigan, Bill" <[e-mail]>, "Friedrichs, Paul" <[e-mail]>, "Nelson, Lee" <[e-mail]>, "Sam Schaen (E-mail)" <[e-mail]>, "Jamil Nimeh (E-mail)" <[e-mail]>, [e-mail], [e-mail]
In-Reply-To: <[e-mail].d isa.mil>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"

Randall,

The recommendation of the Federal PKI Technical Working Group, embodied in
our Certificate and CRL profile is to use the subjectDirectoryAttributes
extension with a data structure called Partition Rule-Based Access Control
(PRBAC) to hold citizenship (and other possibly access control related
information such as security clearance).  The PRBAC structure was developed
for the MISSI program, and is defined, I believe, in the SDN 702, 706 and
801 documents. 

The logic for our recommendation was not particularly profound, but I think
it still holds:  it would be good if everybody put this information in the
same place, and the MISSI folks had already designed a structure for it.

The current Federal Profile draft is online at:
<http://csrc.nist.gov/pki/twg/papers/twg-99-01.pdf> 

Regards,

Bill Burr


At 10:40 AM 7/17/99 -0400, Vickers, Randal R wrote:
>I work with the US DoD PKI engineers at the Defense Information Systems
>Agency. Requirements from the Assistant Secretary of Defense for C3I state
>that we must show citizenship or nationality (symantics) in the cert. My
>question is what extension  does anyone reccommend placing it in. We have
>looked at subjectDirectoryattribute and one of the extensions below
>subjectAlternatename. We are not locked into any one thing as long as it is
>standards based.
>	Thanks
>	Randal Vickers
>
>
Regards,

Bill Burr


Received: from sina.tums.ac.ir ([194.225.91.46]) by mail.proper.com (8.8.8/8.8.5) with SMTP id HAA03074 for <[e-mail]>; Mon, 19 Jul 1999 07:00:47 -0700 (PDT)
Received: from remote-11.tums.ac.ir by sina.tums.ac.ir id aa28822; 19 Jul 99 18:31 IDT
Message-ID: <000d01bed1ef$2d5533a0$04000005@pentiumc>
From: Sayeh Sadat <[e-mail]>
To: [e-mail]
MMDF-Warning:  Parse error in original version of preceding line at sina.tums.ac.ir
Subject: Request For Help .
Date: Mon, 19 Jul 1999 18:31:17 +0430
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_000A_01BED214.E3A6F060"
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 4.72.3110.1
X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3

This is a multi-part message in MIME format.

------=_NextPart_000_000A_01BED214.E3A6F060
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Dear Sir/Madam ,
=20
    I am writing to ask you for a help if possible . I study =
communication electronics in " Sharif University Of Technology " of Iran =
. My final project is about " Public Key Cryptography " and I am looking =
for any kind of information relative to this topic .
=20
    Unfortunately , there is not enough source of information on this =
subject in my country , Iran . So , could you please possibly send me =
any relative information including articles , useful sites offering such =
informations and other useful sources .
=20
    I would be very grateful if you help me . I am looking forward to =
receiveing any information from you .
=20
Yours Faithfully ,
 --Sayeh Sadat--
=20
Sayeh Sadat , L.S.
Sharif University Of Technology .
Electrical Department .
=20
Phone :
            98-21-2547364
            98-21-2549378
=20
Email :
           [e-mail] ( Please use this one that is full =
graphic )
           [e-mail]
           [e-mail]
           [e-mail]
           [e-mail]

Mail Address :        =20
           Sayeh Sadat
           2ND FL #49
           GHOLAMREZA RAHMANI ST.
           DIBAJI JONUBI ST.
           DOLAT AVE.
           19598 TEHRAN=20
           IRAN=20



------=_NextPart_000_000A_01BED214.E3A6F060
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>Dear Sir/Madam ,</FONT></DIV>
<DIV><FONT size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT color=3D#000000 size=3D2>&nbsp;&nbsp;&nbsp; I am writing to =
ask you for a=20
help if possible . </FONT><FONT color=3D#000000 size=3D2>I study =
communication=20
electronics in &quot; Sharif University Of Technology &quot; of Iran .=20
</FONT><FONT color=3D#000000 size=3D2>My final project is about &quot;=20
<STRONG><EM><U>Public Key Cryptography</U></EM></STRONG> &quot; and I am =
looking=20
for any kind of information relative to this topic .</FONT></DIV>
<DIV><FONT color=3D#000000 size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT color=3D#000000 size=3D2>&nbsp;&nbsp;&nbsp; Unfortunately , =
there is not=20
enough source of information on this subject in my country , Iran . =
</FONT><FONT=20
color=3D#000000 size=3D2>So , could you please possibly send me any =
relative=20
information including articles , useful sites offering such informations =
and=20
other useful sources .</FONT></DIV>
<DIV><FONT color=3D#000000 size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT color=3D#000000 size=3D2>&nbsp;&nbsp;&nbsp; I would be very =
grateful if=20
you help me . I am looking forward to receiveing any information from =
you=20
.</FONT></DIV>
<DIV><FONT color=3D#000000 size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT color=3D#000000 size=3D2>Yours Faithfully ,</FONT></DIV>
<DIV><FONT color=3D#000000 size=3D2>&nbsp;--Sayeh Sadat--</FONT></DIV>
<DIV><FONT color=3D#000000 size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT size=3D2>Sayeh</FONT> <FONT size=3D2>Sadat , =
L.S.</FONT></DIV>
<DIV><FONT size=3D2>Sharif</FONT> <FONT size=3D2>University</FONT> <FONT =

size=3D2>Of</FONT> <FONT size=3D2>Technology .</FONT></DIV>
<DIV><FONT size=3D2>Electrical </FONT><FONT size=3D2>Department =
.</FONT></DIV>
<DIV><FONT size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT size=3D2>Phone :</FONT></DIV>
<DIV><FONT=20
size=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;=20
</FONT><FONT size=3D2>98-</FONT><FONT size=3D2>21-</FONT><FONT=20
size=3D2>2547364</FONT></DIV>
<DIV>&nbsp;<FONT color=3D#000000=20
size=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
98-21-2549378</FONT></DIV>
<DIV><FONT color=3D#000000 size=3D2></FONT><FONT =
size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT size=3D2>Email :</FONT></DIV>
<DIV><FONT =
size=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
<A href=3D"mailto:[e-mail]">[e-mail]</A> ( =
Please use=20
this one that is full graphic )</FONT></DIV>
<DIV><FONT size=3D2></FONT><FONT color=3D#000000=20
size=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <A =

href=3D"mailto:[e-mail]">[e-mail]</A></FONT=
></DIV>
<DIV><FONT color=3D#000000 size=3D2></FONT>
<DIV><FONT =
size=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
<A =
href=3D"mailto:[e-mail]">[e-mail]</A></FONT></DIV=
>
<DIV><FONT =
size=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
<A=20
href=3D"mailto:[e-mail]">[e-mail]</A></FO=
NT></DIV></DIV>
<DIV><FONT color=3D#000000=20
size=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <A =

href=3D"mailto:[e-mail]">[e-mail]</A></FONT=
></DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT color=3D#000000 size=3D2>Mail Address=20
:&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; </FONT></DIV>
<DIV><FONT color=3D#000000=20
size=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
Sayeh=20
Sadat</FONT></DIV>
<DIV><FONT color=3D#000000 size=3D2></FONT><FONT=20
size=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
2ND FL=20
#49</FONT></DIV>
<DIV><FONT =
size=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
GHOLAMREZA RAHMANI ST.</FONT></DIV>
<DIV><FONT =
size=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
DIBAJI JONUBI ST.</FONT></DIV>
<DIV><FONT =
size=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
DOLAT AVE.</FONT></DIV>
<DIV><FONT =
size=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
19598 TEHRAN&nbsp;</FONT></DIV>
<DIV><FONT size=3D2></FONT><FONT=20
size=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
IRAN&nbsp;</FONT></DIV>
<DIV><BR></DIV></DIV></BODY></HTML>

------=_NextPart_000_000A_01BED214.E3A6F060--



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 GAA02910 for <[e-mail]>; Mon, 19 Jul 1999 06:59: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 QAA24481 for <[e-mail]>; Mon, 19 Jul 1999 16:01:38 +0200
Received: from HYDRA ([195.198.186.74]) by caesar.udac.se (8.7.3/NetworkC-1) with SMTP id QAA94813; Mon, 19 Jul 1999 16:01:35 +0200
Received: by HYDRA with Microsoft Mail id <01BED1FF.984E0C30@HYDRA>; Mon, 19 Jul 1999 15:58:51 +0200
Message-ID: <01BED1FF.984E0C30@HYDRA>
From: Anders Rundgren <[e-mail]>
To: Stephen Kent <[e-mail]>, "'Waters, Stephen'" <[e-mail]>, "'[e-mail]'" <[e-mail]>
Subject: =?iso-8859-1?Q?RE=3A_KISS_for_PKIX=2E_=28Was=3A_RE=3A_ASN=2E1_?= =?iso-8859-1?Q?vs_XML_=28used_to_be_RE=3A_I=2DD_=09_ACTION_=3Adraft=2D?= =?iso-8859-1?Q?ietf=2Dpkix=2Dscvp=2D_00=2Etxt=29=29?=
Date: Mon, 19 Jul 1999 15:58:49 +0200
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit

Stephen W,
<snip>
>As an example, I am using a certificate Smartcard with a pin-number
>protected private key for VPN access to my head office.  If the laptop and
>smartcard are stolen, the thief can play with them until he has cracked the
>pin number. The thief can do this off-line with no contact with the VPN
>server. Once cracked, they can connect to the Internet, and contact the VPN
>server.

Is it that easy?
I doubt that a thief can "play" with the smart-card until he/she cracks the PIN-code.

After lets say tree tries most smart-cards become  "neutralized" and requires a
much harder PUK-code to be reactivated.  It is also easy for a smart-card
to introduce a for a human negligible delay that makes computerized attacks
less fruitful.

The only method I know of requires opening the chip and manipulations at silicon-
level.  This is not for everybody.

Anders




Received: from rbhub100.chamb.disa.mil (rbhub100.chamb.disa.mil [209.22.120.23]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id GAA02720 for <[e-mail]>; Mon, 19 Jul 1999 06:57:51 -0700 (PDT)
Message-Id: <[e-mail]>
Received: by rbhub100.chamb.disa.mil with Internet Mail Service (5.5.2448.0) id <PGHSTP1N>; Mon, 19 Jul 1999 09:59:18 -0400
From: "Zmudzinski, Tom" <[e-mail]>
To: [e-mail]
Cc: [e-mail], [e-mail], [e-mail], [e-mail]
Subject: Re[some tuple]: Digital Signature Laws (was Re: KISS for PKIX)
Date: Mon, 19 Jul 1999 09:59:05 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2448.0)
Content-Type: text/plain

			Kawika Daguio <[e-mail]> on 07/18/99 02:00
AM
			> Eric <[e-mail]>,
			> 
			> There are a number of bills that have been
introduced at the federal level 
			> that are interesting, but passage of any will be a
major challenge.  One of 
			> the problems that we face in passing a uniform
federal digital signature 
			> law is that those of us (interest groups and
lobbyists and their allies in 
			> the legislatures) who have significantly
overlapping common interests are 
			> constantly divided while focusing on disputing the
narrow issues that 
			> separate us.   I expect to see a bill of some kind
become law this year.   
			> A fully outlined legal infrastructure will develop
over the next few years, but 
			> those of us who have or represent business that
require industrial strength 
			> technical and legal infrastructures cannot wait
even a year for some measure 
			> of legal certainty to be attached to
electronically authenticated agreements.

			Delurking: Yes, and people in Heck want Gaitoraid.
You want a law, go ahead and write one.  Any reasonably clean, blank sheet
of paper will do.  It will have as much force as anything Congress passes
UNTIL THERE IS SOME CASE LAW TO BACK IT UP.  This is a point most people
never grasp: any law is nothing but a bunch of words until someone forces
the issue.  [Part of the reason Robert Morris (the Internet Worm case) was
tried under P.L. 100-235 (the Computer Security Act of 1987) vice the
earlier Computer Security Act of 1984 was that the Government's legal
beagles wanted to establish CASE LAW.  The case against Morris under the
earlier law was open & shut (no requirement to prove intent) but the 1987
law (which does require proof of intent) was much stronger.]  Once the issue
is forced, sometimes you win, sometimes you lose.  [Consider the Scopes
"Monkey Trial" wherein John Thomas Scopes volunteered to test Tennessee's
law against teaching Evolution and Tennessee obligingly found him guilty.]
But without case law, you're playing in a minefield where some of the mines
will go off if you touch them and some will go off if you don't.  It's not
that I'm disagreeing with you that we need "some measure of legal certainty"
(in fact I've been crying for that for nearly ten years!), but we're just
not going to get it soon.  The only mitigation I can suggest is for you to
make certain that YOUR legal beagles (1) are aware of what you're doing and
(2) participate in the ABA Information Security Committee.  Otherwise you're
back in that minefield but with a malfunctioning mine detector.

			[snip]


			v/r
			Tom Zmudzinski, CISSP
			[phone] [DSN 761]
			[e-mail]

Occasional grammatical or spelling variations are inherent to 
this thesis and should not be considered as defects, as they 
enhance the individuality and character of this document.




Received: from ctron-dnm.ctron.com ([e-mail] [12.25.1.120]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id GAA02226 for <[e-mail]>; Mon, 19 Jul 1999 06:29:48 -0700 (PDT)
Received: (from uucp@localhost) by ctron-dnm.ctron.com (8.8.7/8.8.7) id JAA21418; Mon, 19 Jul 1999 09:30:21 -0400 (EDT)
Received: from roc-mail2.ctron.com(134.141.72.230) by ctron-dnm.ctron.com via smap (4.1) id xma021389; Mon, 19 Jul 99 09:29:34 -0400
Received: from new-exc1.ctron.com (NEW-EXC1 [134.141.200.123]) by roc-mail2.ctron.com (8.8.7/8.8.7) with ESMTP id JAA13541; Mon, 19 Jul 1999 09:33:12 -0400 (EDT)
Received: by new-exc1.ctron.com with Internet Mail Service (5.5.2448.0) id <38L70714>; Mon, 19 Jul 1999 14:27:14 +0100
Message-ID: <[e-mail]>
From: "Waters, Stephen" <[e-mail]>
To: Stephen Kent <[e-mail]>
Cc: [e-mail]
Subject: RE: KISS for PKIX. (Was: RE: ASN.1 vs XML (used to be RE: I-D 	 A CTION :draft-ietf-pkix-scvp- 00.txt))
Date: Mon, 19 Jul 1999 14:27:12 +0100
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2448.0)
Content-Type: text/plain; charset="iso-8859-1"

Stephen,

I think there is some exposure expressed here.  Apart from biometric
Smartcards, most certificate safes on laptops could be cracked 'off-line',
and then used to 'connect'.

With 'legacy authentication' such as password, SecureID, CHAP, etc.; there
is no way to crack the password off-line since the laptop does not know if
you got the answer right; only the server knows that.

As an example, I am using a certificate Smartcard with a pin-number
protected private key for VPN access to my head office.  If the laptop and
smartcard are stolen, the thief can play with them until he has cracked the
pin number. The thief can do this off-line with no contact with the VPN
server. Once cracked, they can connect to the Internet, and contact the VPN
server.

To help this situation, if the smartcard authentication was backed with a
password/SecurID challenge via IKE XAUTH, the server can at least log the
failure attempts, and could even cancel the related certificate if
sufficient failures are counted. 

To me, secondary password based authentication COULD be better than
biometric smartcards. Assuming the hackers goal was to give no 'warnings' to
the server in the form of access failures:

1) Biometric thumb-print smartcard break-in:  Hold a gun to the owner of the
thumb, or chop their thumb off and use it latter (yuk!)

2) Well-chosen password break-in:  Hold a gun to the owner until he tells
you the password/pin number.


Hell, I prefer 2) !  O.K, joshing aside, it seems that until we have
biometric smartcards, secondary 'legacy' authentication seems useful in
preventing off-line hacking.

Steve.






[e-mail]
<snip>

>Which brings me to userids and passwords, and why I must use an application
>password even if I have issued a certificate.  Passwords provide reasonable
>assurance to me that the originator is who they say they are; as long as
>the password is kept securely. Dynamic passwords (two-factor
>authentication) provide even stronger assurance that this is so. What do I,
>as a verifier, have when a certificate is used? I have no reasonable
>assurance about the originator because I have not done anything to
>authenticate them. I don't know how secure the originator's PC is. I don't
>know if they have told the browser to cache the private key password, nor
>the strength of it. I don't know if their PC will lock itself after a
>certain amount of inactivity. I don't know who has access to the PC. It is
>not difficult to copy certificate files from one system to another. If the
>password is not strong enough, it probably would not be too difficult to
>crack it. The certificate would be more reliable, for user authentication
>purposes, if I, as an issuer, could control usage of the private key and
>user authentication, or, minimally, if It is stored on some external
>device. At least this provides two-factor authentication. I can't control
>how software vendors utilize certificates in their browser products, but I
>am at their mercy if I allow my application to run from their browser. If
>risk assessment requires me to use password security anyway, I need to be
>able to show significant incremental value added by certificates, given
>that the certifcate process places a large administrative burden around all
>this.

Passwords do not address the problem you claim, above, even though one may
argue that use of a password plus a certt adds some security to the user
authentication process.   But passwords are often guessable, and can be
compromised by the same sorts of attacks that can compromise private keys
stored on PCs, protected by a password.  So, the extent to which use of a
password increase the quality of authentication depends on a number of
factors, including the perceived threat. Yes, the preferable implementation
approach is use of a personal crypto engine token, e.g., a smart card or PC
card, which counters software-based attacks designed to extract private
keys.

I am not familiar with the phrase "dynamic passwords," in a technical
context.  Are you referring to use of hardware tokens like SecurID, used in
challange-response user authentication?  If so, then I agree that such
technology is a vast improvement over static passwords, but it is not
better than the use of certs protected by similar hardware technology,
e.g., smart cards or PC cards.  Depending on the threat model, and on the
rest of the security context on which they are employed, the relative
merits of user authentication tokens vs. certs based in software are
debatable.

Your criticism of certificates ("I have no reasonable assurance about the
originator because I have not done anything to authenticate them") seems to
assume a TTP model of issunace.  If an organization does its ownh
certificate issuance, this statement simply is not true.



Received: from ietf.org (odin.ietf.org [132.151.1.176]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id EAA00884 for <[e-mail]>; Mon, 19 Jul 1999 04:32:39 -0700 (PDT)
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA14237; Mon, 19 Jul 1999 07:33:48 -0400 (EDT)
Message-Id: <[e-mail]>
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
Cc: [e-mail]
From: [e-mail]
Reply-to: [e-mail]
Subject: I-D ACTION:draft-ietf-pkix-cmc-05.txt
Date: Mon, 19 Jul 1999 07:33:47 -0400
Sender: [e-mail]

--NextPart

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Public-Key Infrastructure (X.509) Working Group of the IETF.

	Title		: Certificate Management Messages over CMS
	Author(s)	: M. Myers, X. Liu,  J. Schaad, J. Weinstein	
        Filename	: draft-ietf-pkix-cmc-05.txt
	Pages		: 39
	Date		: 16-Jul-99
	
This document defines a Certificate Management protocol using CMS (CMC).
This protocol addresses two immediate needs within the Internet PKI
community:
 
1. The need for an interface to public key certification products and
   services based on [CMS] and [PKCS10], and
2. The need in [SMIMEV3] for a certificate enrollment protocol for DSA-
   signed certificates with Diffie-Hellman public keys.
 
A small number of additional services are defined to supplement the core
certificate request service.
 
Throughout this specification the term CMS is used to refer to both [CMS]
and [PKCS7].  For signedData the two specifications are equivalent.  For
envelopedData CMS is a superset of the PKCS7. In general, the use of
PKCS7 in this document is aligned to the Cryptographic Message Syntax
[CMS] that provides a superset of the PKCS7 syntax. The term CMC refers
to this specification.
 
The key words 'MUST', 'REQUIRED', 'SHOULD', 'RECOMMENDED', and 'MAY' in
this document are to be interpreted as described in [RFC 2119].

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-pkix-cmc-05.txt

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-ietf-pkix-cmc-05.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt


Internet-Drafts can also be obtained by e-mail.

Send a message to:
	[e-mail].
In the body type:
	"FILE /internet-drafts/draft-ietf-pkix-cmc-05.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.
		
		
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"

--OtherAccess
Content-Type: Message/External-body;
	access-type="mail-server";
	server="[e-mail]"

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

ENCODING mime
FILE /internet-drafts/draft-ietf-pkix-cmc-05.txt

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

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

--OtherAccess--

--NextPart--




Received: from ietf.org (odin.ietf.org [132.151.1.176]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id EAA00582 for <[e-mail]>; Mon, 19 Jul 1999 04:15:40 -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 HAA13654; Mon, 19 Jul 1999 07:16:44 -0400 (EDT)
Message-Id: <[e-mail]>
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
Cc: [e-mail]
From: [e-mail]
Reply-to: [e-mail]
Subject: I-D ACTION:draft-ietf-pkix-dcs-01.txt
Date: Mon, 19 Jul 1999 07:16:44 -0400
Sender: [e-mail]

--NextPart

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Public-Key Infrastructure (X.509) Working Group of the IETF.

	Title		: Internet X.509 Public Key Infrastructure Data 
                          Certification Server Protocols
	Author(s)	: C. Adams, P. Sylvester,  R. Zuccherato
	Filename	: draft-ietf-pkix-dcs-01.txt
	Pages		: 23
	Date		: 12-Jul-99
	
This document describes a general data certification service and the
protocols to be used when communicating with it.  The Data
Certification Server  is a Trusted Third Party (TTP) that can be used
as one component in building reliable non-repudiation services (see
[ISONR]).  Useful Data Certification Server responsibilities in a PKI
are to validate signatures and to provide up-to-date information
regarding the status of public key certificates.

   We give examples of how to use the Data Certification Server to
   extend the lifetime of a signature beyond key expiry or revocation
   and to query the Data Certification Server regarding the status of a
   public key certificate.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-pkix-dcs-01.txt

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-ietf-pkix-dcs-01.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt


Internet-Drafts can also be obtained by e-mail.

Send a message to:
	[e-mail].
In the body type:
	"FILE /internet-drafts/draft-ietf-pkix-dcs-01.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.
		
		
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"

--OtherAccess
Content-Type: Message/External-body;
	access-type="mail-server";
	server="[e-mail]"

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

ENCODING mime
FILE /internet-drafts/draft-ietf-pkix-dcs-01.txt

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

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

--OtherAccess--

--NextPart--




Received: from ctron-dnm.ctron.com ([e-mail] [12.25.1.120]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id DAA00101 for <[e-mail]>; Mon, 19 Jul 1999 03:30:39 -0700 (PDT)
Received: (from uucp@localhost) by ctron-dnm.ctron.com (8.8.7/8.8.7) id GAA12376; Mon, 19 Jul 1999 06:34:33 -0400 (EDT)
Received: from roc-mail2.ctron.com(134.141.72.230) by ctron-dnm.ctron.com via smap (4.1) id xma012371; Mon, 19 Jul 99 06:33:43 -0400
Received: from new-exc1.ctron.com (NEW-EXC1 [134.141.200.123]) by roc-mail2.ctron.com (8.8.7/8.8.7) with ESMTP id GAA14289; Mon, 19 Jul 1999 06:37:21 -0400 (EDT)
Received: by new-exc1.ctron.com with Internet Mail Service (5.5.2448.0) id <38L706P1>; Mon, 19 Jul 1999 11:31:26 +0100
Message-ID: <[e-mail]>
From: "Waters, Stephen" <[e-mail]>
To: [e-mail]
Cc: [e-mail], [e-mail], "Holland, Gary" <[e-mail]>, "Bassett, John Robert" <[e-mail]>
Subject: RE: KISS for PKIX. (Was: RE: ASN.1 vs XML (used to be RE: I-D ACT ION :draft-ietf-pkix-scvp- 00.txt))
Date: Mon, 19 Jul 1999 11:31:25 +0100
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2448.0)
Content-Type: text/plain; charset="iso-8859-1"

Hi Eric,

Some very useful comments here, thanks.  From an IPSEC VPN point of view (my
current concern), I would say that it looks like password/pin-protected
certificates AND some secondary user-based authentication need to be
implemented.

Since it is easy to imagine a password-protected device/certificate being
cracked off-line (i.e. in a dark room somewhere) before an attack is mounted
on the VPN server, then secondary authentication becomes
necessary/essential?

Some examples:

1) My PC has a certificate loaded that is not password protected. The PC, if
stolen, could be used to authenticate itself against a VPN server.  This is
clearly a problem that must be fixed without relying on notification of the
theft to fix it.

2) My PC has a password-protected certificate. Each time I attempt to
connect to the VPN server, the VPN application prompts the user for the
password to unlock the certificate. My concern here is that, if the PC is
stolen, then the password could be cracked by trial-and-error without any
actual connection attempts (warnings) reaching the VPN server.

3) My PC uses a Smartcard with a pin-protected private-key/certificate.
Again, if the Smartcard is stolen, how long would it take to crack the pin
number off-line and use the authentication information on a different PC
with a VPN client kit installed. This would require the attacker to know the
address and security requirements of the VPN servers willing to accept the
certificate.  If the PC and Smartcard are stolen together, it is probably
worse than case 2).

4) As for 3), but the Smartcard uses biometrics - thumb-print, signature,
eye-scan. I guess this is much safer - provided you don't get gory!

5) My PC uses one of the approaches above, but once authentication via the
certificate is complete, enforces a secondary authentication. This
authentication is under the control of the server, and so can't be cracked
off-line. If an attack is mounted, the VPN server will receive 'warnings' in
the form of authentication failures (I hope).  The authentication
information provided in this secondary phase MUST NOT be part of the VPN
client's automatic function.

The advantages of 5) seem to be:
1) two-way authentication between the devices based on certificates. 
2) secondary, independent authentication that can't be cracked 'off-line'.
3) an 'way out' for the non-repudiation legality. 
4) continued use of existing remote access authentication methods.

I have not covered the case where a stolen PC/certificate is used to spoof a
VPN server. Mainly because I can't think of a solution!

Steve.





-----Original Message-----
From: [e-mail]
[mailto:[e-mail]]
Sent: Friday, July 16, 1999 6:28 PM
To: Stephen Kent
Cc: '[e-mail]'
Subject: Re: KISS for PKIX. (Was: RE: ASN.1 vs XML (used to be RE: I-D
ACTION :draft-ietf-pkix-scvp- 00.txt))


There are legal issues to be resolved regarding limitations of liability
and responsibilities of issuers, certificate authorities, subscribers, and
relying parties. There are legal issues to be resolved regarding digital
signatures. Last time I checked, about thirty states had enacted or were in
the process of enacting digital signature laws. The federal government has
a digital signature law pending. I was not basing my comment solely on
legal issues regarding authentication of users. What is the limitation of
liability of an issuer when a third party effects a transaction based on a
certificate the issuer has issued, after the subscriber repudiates the
transaction? What if all three parties are in three different states or,
worse, countries? Whose law applies? What happens when a CA closes shop?
Are the certificates valid or invalid? Who will relying parties consult if
they need to verify that a certificate issued by the defunct CA was valid
at a previous point in time for a disputed transaction? For how many years
must a CA keep expired certificates? What responsibility does a CA have for
providing for cessation of activities?

I initially was led to believe PKI supported non-repudiation because this
was one of the claims being made for it by its proponents. It was only
after I started examining it more closely that I realized the claims were
unsubstantiated. As long as one party can reasonably deny a fact, it is up
to the other party to prove otherwise. If I receive a transaction and act
on it, and the initiator subsequently denies the transaction, what do I
have to authenticate the user and the data? I can't claim in court that I
received and acted on a message because my server accepted it since it came
with a valid certificate,  and because the signature and the message digest
were valid, based on the certificate. I need to to be able to produce the
original message, the digest, the signature, and the certificate, and be
able to show that the validity checks all passed. I also need to know what
algoritms were used. I need logs and audit records to prove the transaction
came in. And I need all this possibly months or years later. But, most of
all, I need to be able to demonstrate that I based my decision on
reasonable assurance that the originator was who they claimed to be.

Which brings me to userids and passwords, and why I must use an application
password even if I have issued a certificate.  Passwords provide reasonable
assurance to me that the originator is who they say they are; as long as
the password is kept securely. Dynamic passwords (two-factor
authentication) provide even stronger assurance that this is so. What do I,
as a verifier, have when a certificate is used? I have no reasonable
assurance about the originator because I have not done anything to
authenticate them. I don't know how secure the originator's PC is. I don't
know if they have told the browser to cache the private key password, nor
the strength of it. I don't know if their PC will lock itself after a
certain amount of inactivity. I don't know who has access to the PC. It is
not difficult to copy certificate files from one system to another. If the
password is not strong enough, it probably would not be too difficult to
crack it. The certificate would be more reliable, for user authentication
purposes, if I, as an issuer, could control usage of the private key and
user authentication, or, minimally, if It is stored on some external
device. At least this provides two-factor authentication. I can't control
how software vendors utilize certificates in their browser products, but I
am at their mercy if I allow my application to run from their browser. If
risk assessment requires me to use password security anyway, I need to be
able to show significant incremental value added by certificates, given
that the certifcate process places a large administrative burden around all
this.

Granted, all this is less confusing if an originator is executing a
transaction with the issuer of the cetificate, because the issuer could
control the user authentication process. But it becomes more complex when
the certificate is used to execute a transaction with a third party. How
can a bank verify a certificate and, more importantly, vouch for a
transaction, if it can't be reasonably assured the customer is who they
claim to be? All it has is a request for validation from the third party
(merchant) and a message.

I am sure this will all be resolved over time, but at this point, I don't
feel we are close enough.
eric





Stephen Kent <[e-mail]> on 07/16/99 03:04:48 AM

To:   Eric Guerrino
cc:   "'[e-mail]'" <[e-mail]>
Subject:  Re: KISS for PKIX. (Was: RE: ASN.1 vs XML (used to be RE: I-D
       ACTION :draft-ietf-pkix-scvp- 00.txt))




Date: Fri, 16 Jul 1999 03:04:48 -0400
To: Eric_Guerrino@LNOTES5
From: Stephen Kent <[e-mail]>
Subject: Re: KISS for PKIX. (Was: RE: ASN.1 vs XML (used to be RE: I-D
      ACTION :draft-ietf-pkix-scvp- 00.txt))
Cc: "'[e-mail]'" <[e-mail]>



Eric,

>I couldn't agree with you more. However, regarding acceptance of PKI
>technologies by large organizations, I believe there are many reasons
>organizations are not adopting PKI readily besides ease-of-use issues. Nor
>does it have anything to do with ASN.1 vs XML. This issue can't be
resolved
>with technology solutions because their lack of acceptance is not due
>solely to technical problems.
>
>The problems with PKI are numerous, from a corporate perspective, and many
>large organizations have not moved initial PKI efforts beyond the
>pilot/evaluation stage. Problems include outstanding legal liability
>issues, the lack of fraud protection laws, the need to address cessation
of
>activites of a CA and/or a registry, the inability to bind a certificate
>distinctly to a user (software certificates identify systems, not users),
>the inability of an issuer to associate a security policy with the
>certificate (issuers need to be able to dictate when to allow caching of
>passwords,as well as things like session timeout and password construction
>rules), undefined procedures and products to support records management
and
>archiving, as well as that non-repudiation claims for current PKI products
>may have no legal basis. Then there are all the technical problems.

I agree that these are precieved problems that hinder PKI deployment, but I
also think that many of these are red herrings.  If I use certificates to
authenticate users, in lieu of passwords, why are there any new legal
issues?  Part of the problem is that people have been led to believe that a
PKI must support non-repudiation, which generates a large number of valid,
legal concerns.  However, use of a PKI to support SSL, IPsec, and S/MIME
(at least on an intranet basis) does not raise such issues, yet promises to
improve security and to make life easier for users.

I disagree with your statement that a certificate in software binds a
system, vs. a user.  Yes, smart cards are preferable, but if the choice is
between a password and a certificate (and private key) with software
cryptography, I see no reason not to adopt the latter, and I certainly see
no reason to declare that the latter is not a user (vs. system)
authentication mechanism.  Finally, why do you say that an issuer cann
associate a security policy with a certificate?  We have the syntactic
means to do so as part of the standard.  Do you mean that we don't have
appplications that pay attention to the policy extension?

Steve





Received: from bells.cs.ucl.ac.uk (bells.cs.ucl.ac.uk [128.16.5.31]) by mail.proper.com (8.8.8/8.8.5) with SMTP id DAA28993 for <[e-mail]>; Mon, 19 Jul 1999 03:22:51 -0700 (PDT)
Received: from ginger.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP  id <[e-mail]>; Mon, 19 Jul 1999 11:24:28 +0100
X-Mailer: exmh version 2.0.2
To: [e-mail]
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Date: Mon, 19 Jul 1999 11:24:28 +0100
Message-ID: <[e-mail]>
From: Theo PAGTZIS <[e-mail]>

Hello all,

  Has anybody kept any minutes during the PKIX sessions? If so would it be 
possible to email them to me as I could not make it to these sessions?

Cheers


Theo



Received: from www.meridianus.com (209.249.223.18.has.no.reverse [209.249.223.18] (may be forged)) by mail.proper.com (8.8.8/8.8.5) with ESMTP id KAA23691 for <[e-mail]>; Sun, 18 Jul 1999 10:30:45 -0700 (PDT)
Received: from PC1 by www.meridianus.com (8.8.8+Sun/SMI-SVR4) id LAA05056; Sun, 18 Jul 1999 11:26:53 -0700 (PDT)
Message-ID: <04ee01bed145$3f466840$[e-mail]>
From: "Todd S. Glassey" <[e-mail]>
To: "Anders Rundgren" <[e-mail]>
Cc: <[e-mail]>
References: <002e01bed0a7$5ca22a80$[e-mail]>
Subject: Technological Neutrality of the Total PKI - Was Re: Common misconceptions, was Re: KISS for PKIX. 
Date: Sun, 18 Jul 1999 10:44:55 -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 5.00.2918.2701
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2918.2701

Anders

> >
> >But Biometrics only addressses the Retail POS style model, becuase once
the
> >Biometric data is captured, it takes on the same vulnerability as the
reast
> >of the sata used as the auth enablement.
>
> Hum, I don't really think we are talking about the same thing.

Actually we are, and I think thats the problem.

>Biometrics in this
> context is a tool for a CA to bind a physical person (body) to a
certificate.  Could
> use fingerprint or DNA fingerprints.  IMO physical person (body) is
stronger than
> identity as the latter can be forged much easier and is sometimes
impossible
> to verify (no papers available).

Yes this is true, but what does it have to do with the original question?
that's not the context of this effort. The intent is to create better
systems to prove the conveyance on "human intent" into a digital context.
And since the systems themselves have no cogniscent existence under any law
on this planet, we have a minor goochie to deal with here.

In closing, I think that Biometrics like any other ancillary or secondary
auth model are usually only good for proof for the question: "was the person
who this act is done by actually the participant in the act"? It does
nothing to deal with conveyance in the third person or provide the ability
to have an act somewhere down the line be proven to be one of the one's that
this particular person intended to have happen and that they happened when
and how they were supposed to.


Todd



Received: from fep4.post.tele.dk (fep4.post.tele.dk [195.41.46.139]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id JAA23122 for <[e-mail]>; Sun, 18 Jul 1999 09:07:40 -0700 (PDT)
Received: from aum ([194.239.186.7]) by fep4.post.tele.dk (InterMail v4.0 201-221) with ESMTP id <19990718160916.XYLU22847.fep4@aum>; Sun, 18 Jul 1999 18:09:16 +0200
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58 
Date: Sun, 18 Jul 1999 18:12:32 +0200
To: Michael Myers <[e-mail]>, IETF PKIX list <[e-mail]>
From: Paul Hoffman / IMC <[e-mail]>
Subject: Re: SCVP Analysis
In-Reply-To: <[e-mail].c om>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed

Ambarish has answered many of your misplaced assumptions and assertions. I 
can fill in on a few.

>Having gone through
>this process, it's very clear to me at least that needs for delegated path
>validation can more easily be met with a very simple extension to OCSP.

Mike, you didn't respond to my previous statement about this, so please do 
so now: how? The semantics in the OCSP standard explicitly talk only about 
status, and not about validation. Yet now you are talking about validation 
through the extension mechanism. This is a violation of the standard. You 
can change the semantics of OCSP to handle topics other than status, if you 
want, but then it is a different protocol.


>   The
>work would be very minimal compared to implementing a totally different
>protocol to do exactly the same thing.

Your definition of "exactly" differs from many people.

>4.  Optional support for PGP style public key management.
>----------------------------------------------------------------
>As discussed on the floor in Oslo, inclusion of this functionality would
>require a revision to the PKIX charter.  PKIX was specifically established
>to address X.509 certificates.

I would have hoped you would have read the charter before making a 
statement like this. In fact, the charter says nothing of the sort; if you 
disagree, please quote the charter.

In fact, the charter does say "This project will not preclude use of 
non-infrastructural public-key distribution techniques nor of non-X.509 
PKIs by such applications." That seems pretty clear. If you want to try to 
revise the charter to remove this, go ahead, but don't claim it doesn't say 
it in the current charter.


>6.  Optional specification of intermediate certificates to use as a
>supplement to the validation path of the subject certificate.
>----------------------------------------------------------------
>In the context of the legal framework underpinning the use of certificates
>for electronic commerce, the issuer of a certificate issued that certificate
>with a very specific trust chain model in mind.
>
>The proposed functionality seems to suggest that the authors are asking PKIX
>to support the notion of the "re-purposing" of certificates for uses beyond
>those intended by the original issuer.

It only "seems to suggest" this to you; no one else seems to have read it 
this way.

>Was this the authors' intent?  If not, then what problem is this proposed
>functionality solving?

Maybe we need to make this clearer in the draft. If a client has what it 
thinks is a chain to the root (because the cert holder has said it is a 
chain), the client can ask the simple question "Is this really a valid chain?"

>7.  Optional specification of trusted roots the server must rely on.
>----------------------------------------------------------------
>Same issue as above.
>
>Is it the authors' proposition that the issuer of a certificate is *not* the
>final arbiter of the trustworthiness of that certificate?  (noting that
>"issuer" could be an entity that directs another entity to manufacture and
>distribute a certificate on its behalf).

Boy, you seem almost masterful at misreading the draft. Of course not. The 
optional specification of trusted roots is the client's way of saying to 
the server "I don't care who you trust, here is who I trust." This is 
precisely what is needed for the folks who trust the server with the 
ability to process but not to know who is a trusted root.


>9.  Extensions may be critical or non-critical.
>----------------------------------------------------------------
>Recent experience has shown that this is inadvisable.  The XML DigSig group,
>for example, has specifically deprecated proposed use of critical flags for
>well-known reasons.

And here I'll disagree with Ambarish. We put it in to match the PKIX format 
draft. I, for one, am happy to take it out if the other folks in the WG 
think it should be removed.

If you have any further questions on the draft, please feel free to ask. We 
should have a new version out that covers the concerns raised in Oslo in 
about two weeks.

--Paul Hoffman, Director
--Internet Mail Consortium


Received: from imo27.mx.aol.com (imo27.mx.aol.com [198.81.17.71]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id XAA11053 for <[e-mail]>; Sat, 17 Jul 1999 23:00:51 -0700 (PDT)
From: [e-mail]
Received: from [e-mail] by imo27.mx.aol.com (IMOv20.21) id sLKKa06608 (526); Sun, 18 Jul 1999 02:00:07 -0400 (EDT)
Message-ID: <[e-mail]>
Date: Sun, 18 Jul 1999 02:00:07 EDT
Subject: Re: Digital Signature Laus (was Re: KISS for PKIX)
To: [e-mail], [e-mail], [e-mail]
CC: [e-mail]
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: AOL 4.0 for Windows 95 sub 13

Eric,

There are a number of bills that have been introduced at the federal level 
that are interesting, but passage of any will be a major challenge.  One of 
the problems that we face in passing a uniform federal digital signature law 
is that those of us (interest groups and lobbyists and their allies in the 
legislatures) who have significantly overlapping common interests are 
constantly divided while focusing on disputing the narrow issues that 
separate us.   I expect to see a bill of some kind become law this year.   A 
fully outlined legal infrastructure will develop over the next few years, but 
those of us who have or represent business that require industrial strength 
technical and legal infrastructures cannot wait even a year for some measure 
of legal certainty to be attached to electronically authenticated agreements.

I believe that the only type of bill that has a reasonable chance of passage 
is an incremental improvement taking a similar approach to that used 
successfully when we passed the Government Paperwork Elimination Act last 
year.

I believe that passing a law that supports uses of and enforces the validity 
of electronic authentication as agreed to by informed parties in traditional 
contracts is a significant step forward that everyone can agree to accept as 
a fallback to the bills that each interest group is sponsoring.

All of this can be reduced to a bumpersticker type argument that resonates:
Electronic Authentication Legislation Initiatives are about the freedom to 
contract &
the right to enforce contracts.

I don't think you will find many people who will oppose either the concept or 
a properly worded (short) bit of legislative language.

Good luck and have fun while trudging through the state stuff...I have more 
information if you need some...
X (signed)...Kawika Daguio
EVP, Financial Information Protection Association


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 QAA13818 for <[e-mail]>; Sat, 17 Jul 1999 16:27:09 -0700 (PDT)
Received: from rotek.com.au (d175-2.cpe.Melbourne.AONE.net.au [203.12.185.175]) by springfield.SIMPSONS with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2232.9) id 305DFWXQ; Sun, 18 Jul 1999 09:26:59 +1000
Message-ID: <[e-mail]>
Date: Sun, 18 Jul 1999 09:31:10 -0700
From: Andrew Probert <[e-mail]>
X-Mailer: Mozilla 4.05 [en] (Win95; I)
MIME-Version: 1.0
To: Stephen Kent <[e-mail]>
CC: [e-mail], "'[e-mail]'" <[e-mail]>
Subject: Re: KISS for PKIX. (Was: RE: ASN.1 vs XML (used to be RE: I-D 	 ACTION :draft-ietf-pkix-scvp- 00.txt))
References: <v04020a02b3b3e54bc992@[128.33.238.108]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

I agree with this stance.  EDI would not have got off the ground if they
didn't rely on Trading Partner Agreements, which explicitly stated the
relationships.

The real contractural complexity arises when the CA is not one of the
trading partners i.e. three party agreements are required

CA <-> Supplier
CA <-> Customer
Customer <-> Supplier

Also that the issues of integration of certifiate-based authentication
to host systems require construction e.g. mapping of security domains
such that certficate dnX == RACF UseridY, or is implicitly trusted as it
comes from a trusted gateway.

Stephen Kent wrote:
> 
> Eric,
> 
> >I couldn't agree with you more. However, regarding acceptance of PKI
> >technologies by large organizations, I believe there are many reasons
> >organizations are not adopting PKI readily besides ease-of-use issues. Nor
> >does it have anything to do with ASN.1 vs XML. This issue can't be resolved
> >with technology solutions because their lack of acceptance is not due
> >solely to technical problems.
> >
> >The problems with PKI are numerous, from a corporate perspective, and many
> >large organizations have not moved initial PKI efforts beyond the
> >pilot/evaluation stage. Problems include outstanding legal liability
> >issues, the lack of fraud protection laws, the need to address cessation of
> >activites of a CA and/or a registry, the inability to bind a certificate
> >distinctly to a user (software certificates identify systems, not users),
> >the inability of an issuer to associate a security policy with the
> >certificate (issuers need to be able to dictate when to allow caching of
> >passwords,as well as things like session timeout and password construction
> >rules), undefined procedures and products to support records management and
> >archiving, as well as that non-repudiation claims for current PKI products
> >may have no legal basis. Then there are all the technical problems.
> 
> I agree that these are precieved problems that hinder PKI deployment, but I
> also think that many of these are red herrings.  If I use certificates to
> authenticate users, in lieu of passwords, why are there any new legal
> issues?  Part of the problem is that people have been led to believe that a
> PKI must support non-repudiation, which generates a large number of valid,
> legal concerns.  However, use of a PKI to support SSL, IPsec, and S/MIME
> (at least on an intranet basis) does not raise such issues, yet promises to
> improve security and to make life easier for users.
> 
> I disagree with your statement that a certificate in software binds a
> system, vs. a user.  Yes, smart cards are preferable, but if the choice is
> between a password and a certificate (and private key) with software
> cryptography, I see no reason not to adopt the latter, and I certainly see
> no reason to declare that the latter is not a user (vs. system)
> authentication mechanism.  Finally, why do you say that an issuer cann
> associate a security policy with a certificate?  We have the syntactic
> means to do so as part of the standard.  Do you mean that we don't have
> appplications that pay attention to the policy extension?
> 
> Steve


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 OAA13056 for <[e-mail]>; Sat, 17 Jul 1999 14:55:36 -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 XAA16036 for <[e-mail]>; Sat, 17 Jul 1999 23:57:09 +0200
Received: from mega (t1o69p76.telia.com [62.20.144.76]) by caesar.udac.se (8.7.3/NetworkC-1) with SMTP id XAA112528; Sat, 17 Jul 1999 23:57:06 +0200
Message-ID: <002e01bed0a7$5ca22a80$[e-mail]>
From: "Anders Rundgren" <[e-mail]>
To: "Todd S. Glassey" <[e-mail]>, "PKIX-List" <[e-mail]>, "Ed Gerck" <[e-mail]>
Subject: Re: Common misconceptions, was Re: KISS for PKIX. (Was: RE: ASN.1 vs XML (used to beRE: I-D 	ACTION :draft-ietf-pkix-scvp-00.txt))
Date: Sat, 17 Jul 1999 23:54: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.3110.5
X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by mail.proper.com id OAA13058

Todd,
<snip>
>> Regarding the binding I believe that certificates and CAs make sense if
>the CA
>> can guarantee (with high but not unlimited probability) that an individual
>cannot
>> "borrow" another's identity.  This is certainly feasible, partly by using
>biometrics.
>> And is not terribly expensive either.
>> To nail down an individual's true TRUE identity is NOT a requirement for
>employers, banks
>> etc. as long as you perform according to their rules.  If an RP needs
>stronger proofs of
>> identity this may have to be carried out without the CA.
>
>But Biometrics only addressses the Retail POS style model, becuase once the
>Biometric data is captured, it takes on the same vulnerability as the reast
>of the sata used as the auth enablement.

Hum, I don't really think we are talking about the same thing.  Biometrics in this
context is a tool for a CA to bind a physical person (body) to a certificate.  Could
use fingerprint or DNA fingerprints.  IMO physical person (body) is stronger than
identity as the latter can be forged much easier and is sometimes impossible
to verify (no papers available).

Anders





Received: from mail02-ewr.pilot.net (mail-ewr-2.pilot.net [206.98.230.16]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id OAA12760 for <[e-mail]>; Sat, 17 Jul 1999 14:26:04 -0700 (PDT)
From: [e-mail]
Received: from mailgw.firstdata.com ([204.48.27.166]) by mail02-ewr.pilot.net with ESMTP id RAA10537; Sat, 17 Jul 1999 17:27:37 -0400 (EDT)
Received: from lnsunr02.firstdata.com (lnsunr02.firstdata.com [192.168.247.16]) by mailgw.firstdata.com with SMTP id RAA06419; Sat, 17 Jul 1999 17:27:36 -0400 (EDT)
Received: by lnsunr02.firstdata.com(Lotus SMTP MTA v4.6.4  (830.2 3-23-1999))  id 852567B1.00756810 ; Sat, 17 Jul 1999 17:22:23 -0400
X-Lotus-FromDomain: FDC
To: Stephen Kent <[e-mail]>
cc: "'[e-mail]'" <[e-mail]>
Message-ID: <[e-mail]>
Date: Sat, 17 Jul 1999 14:25:42 -0700
Subject: Re: KISS for PKIX. (Was: RE: ASN.1 vs XML (used to be RE: I-D 	 	 ACTION :draft-ietf-pkix-scvp- 00.txt))
Mime-Version: 1.0
Content-type: text/plain; charset=us-ascii
Content-Disposition: inline

oh yes ... and to some extent the cert-less work, in fact grew out of working
on various SET projects (or lets say that the size of the certificate was
compressed
to zero bytes).

1) first off, set doesn't provide end-to-end authentication ... the digital
signature/cert is verified at (essentially) and internet boundary and then the
digital signature and cert is stripped off the transaction before forwarding to
the customers bank for final authentication, authorization, and execution. The
forwarded request does have a flag turned on saying whether the sender
succesfully performed a digital signature authentication. Two years ago, visa
presented some number at a ISO meeting in europe on the number of transactions
coming thru which had the digital signature validated turned on ... and for
which they could proove there was no digital signature capability (one of the
simple hazards of not having end-to-end security). Furthermore, the digital
signature authentication was just a preliminary screening and the consumer's
backend actually performed the real authentication, authorization and execution
using account record information.


2) while not part of the SET specification ... every institution that I know of
that looked at doing SET generated a work request to add the certificate/public
key to the consumer's account record.

3) trying to achieve end-to-end security with transaction that hits the account
record anyway ... in an infrastructure where the base transaction is 60 bytes
and there may be thousands of these per second ... it was a significant task to
get the operational people's attention that they should let an extra 80bytes
pass thru the production infrastructure (digital signature plus a little bit
more) on each transaction.


So applying a little bit of knowledge-based compression on the data to pass thru
the infrastructure ... in order to meet guidelines for end-to-end security ...
started trying to throw out every byte that was absolutely not necessary.

that was when it started to dawn that a certificate contained either all the
information to do the transaction or had a pointer to an account record that
contained the necessary information. If the transaction has to hit an account
record anyway ... then a little bit of knowledge-based compression ...
compressed the size of the certificate to zero bytes.

this is also a result of a more precise definition where the digital signature
authenticates the transaction ... and any certificate is used to authenticate a
public key used in the digital signature ... but certificates doesn't have to be
the only method of authenticating a public key (account records have been used
by businesses for eons for validating various information ... like current
account balance). The certificate doesn't authenticate the transaction ... the
digital
signature authenticates the transaction ... and any certificate is used to
authenticate the public key.

so back to the question in the thread about the  issue of of  certificate PKIs
costs being a downside inhibitor .... it may not only be the raw costs of the
certificate PKIs that is in question ... but also the fact that in several
environments that they may represent redundant and superfulous costs. The issue
then is that for such environments ... either the redudant and superfulous costs
are not appropriate and/or certificate PKIs need to find a way of leveraging
their characteristics for eliminating other costs.

And to re-iterate ... fully qualified identity certificates carrying full
permissions can be used to eliminate use of  account records (which can in turn
raise privacy and security concerns) ... or they just carry a pointer to the
account records ... which makes it harder to show that they aren't redundant and
superfulous.




Received: from mail02-ewr.pilot.net (mail-ewr-2.pilot.net [206.98.230.16]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id NAA12165 for <[e-mail]>; Sat, 17 Jul 1999 13:37:53 -0700 (PDT)
From: [e-mail]
Received: from mailgw.firstdata.com ([204.48.27.166]) by mail02-ewr.pilot.net with ESMTP id QAA09227; Sat, 17 Jul 1999 16:39:26 -0400 (EDT)
Received: from lnsunr02.firstdata.com (lnsunr02.firstdata.com [192.168.247.16]) by mailgw.firstdata.com with SMTP id QAA06059; Sat, 17 Jul 1999 16:39:25 -0400 (EDT)
Received: by lnsunr02.firstdata.com(Lotus SMTP MTA v4.6.4  (830.2 3-23-1999))  id 852567B1.0070FEC2 ; Sat, 17 Jul 1999 16:34:12 -0400
X-Lotus-FromDomain: FDC
To: Stephen Kent <[e-mail]>
cc: "'[e-mail]'" <[e-mail]>
Message-ID: <[e-mail]>
Date: Sat, 17 Jul 1999 13:37:22 -0700
Subject: RE: Common misconceptions, was Re: KISS for PKIX. (Was: RE: ASN.1 vs XML (used to be RE: I-D 	ACTION :draft-ietf-pkix-scvp- 00 .txt))
Mime-Version: 1.0
Content-type: text/plain; charset=us-ascii
Content-Disposition: inline

i believe the context of the reply was within the statement of what are the
reasons why cert PKIs are having hard time. One of the issues raised was
cost ... part of that scenerio is that digital signature authentication can be
seperated from the question of cert infrastructure costs ... i.e. semantic
confusion that the digital signature authenticates the transaction (not
the certificate) and that the certificate is one method of authenticating
the public key. The digital signature business case can actually be
seperated from the certificate business case (they don't have to
be synonomous) ... leaving the certificate business case to show
that it can eliminate/reduce cost of existing account-based operations.

One way  is to show identity certificates carrying all information
and permissions can eliminate the accounts ... but that introduces
privacy and security exposures. The other way is to show relying-party-only
certificates ... with no information but an account number .... which then
have to hit the account record ... at which point the certificate can be
shown to be redundant and superfulous.

So examining the parameters and operational regions for certificate
business cases .... it is useful to understand where they provide
significant benefit like in the webserver comfort certificate case.
 .







Stephen Kent <[e-mail]> on 07/17/99 11:46:15 AM

To:   Lynn Wheeler/CA/FDMS/FDC@FDC
cc:   "'[e-mail]'" <[e-mail]>
Subject:  RE: Common misconceptions, was Re: KISS for PKIX. (Was: RE: ASN.1
       vs XML (used to be RE: I-D  ACTION :draft-ietf-pkix-scvp- 00.txt))




Lynn,

I appreciate your fondness for cert-less public key use; after all, the
model you are describing is yours, submitted to an ANSI X.9 committee.  And
a brief discussion of it is OK too, but since the charter of the PKIX WG
focuses on the use of X.509 certificates in the Internet, extended
discussion of your cert-less model is hardly within the scope of the WG
list.

Steve






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 NAA12177 for <[e-mail]>; Sat, 17 Jul 1999 13:37:54 -0700 (PDT)
From: [e-mail]
Received: from mailgw.firstdata.com ([204.48.27.166]) by mail01-ewr.pilot.net with ESMTP id QAA05066; Sat, 17 Jul 1999 16:39:27 -0400 (EDT)
Received: from lnsunr02.firstdata.com (lnsunr02.firstdata.com [192.168.247.16]) by mailgw.firstdata.com with SMTP id QAA06062; Sat, 17 Jul 1999 16:39:26 -0400 (EDT)
Received: by lnsunr02.firstdata.com(Lotus SMTP MTA v4.6.4  (830.2 3-23-1999))  id 852567B1.0070FC6E ; Sat, 17 Jul 1999 16:34:06 -0400
X-Lotus-FromDomain: FDC
To: Stephen Kent <[e-mail]>
cc: "'[e-mail]'" <[e-mail]>
Message-ID: <[e-mail]>
Date: Sat, 17 Jul 1999 13:27:16 -0700
Subject: Re: KISS for PKIX. (Was: RE: ASN.1 vs XML (used to be RE: I-D 	 	 ACTION :draft-ietf-pkix-scvp- 00.txt))
Mime-Version: 1.0
Content-type: text/plain; charset=us-ascii
Content-Disposition: inline

a cert-less approach is relatively trivial to apply across the
corporate electronic environment. register the employees public
key in a RADIUS administrative data-base (i.e. RA by any other
name) and use RADIUS protocol for all corporate authentications
i.e. existing RADIUS based authentication and straight forward
apply RADIUS protocol to future applications.

This even works in SSL and other types of environments. Consumer's
authentication at the server is done with RADIUS account-base.

This doesn't say anything about eliminating web server comfort
certificates ... for setting up SSL sessions ... just addresses issue
of authenticating individuals in environments that are really account-base
operation.

The RADIUS protocol also addresses things like permissions
... again not carrying sensitive individual information in credentials
like certificates ... but going to the account record to obtain the
permissions and operational characteristics.

as alwas choice is:

1) fully defined, identity certificate

2) relying-party-only certificate where the transaction has to
hit the account record.

either all the necessary information is in the certificate or the
certificate contains only enuf information to be able to get
to the account record. if the operation has to hit the accound
record anyway ... then it is trivial to show that the certificate
is redundant and superfulous.

it wasn't intended to be a red herring statement ... it was a
statement that is was one or the other ... either all the necessary
information is in the certificate (in which case the certificate can
represent a privacy and/or security issue) or the information is
in an account record (in which case the certificate is superfulous
and redundant).

this of course, doesn't apply to saying that the merchant comfort
certificates (using for setting up SSL sessions) are unnecessary
... but that almost all cases that the certificates for employees
and individuals ... tend to either 1) divulge privacy/confidential
information or 2) have to hit an account record.




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 MAA11517 for <[e-mail]>; Sat, 17 Jul 1999 12:06:47 -0700 (PDT)
Received: from [128.33.238.213] (tc238-215.bbn.com [128.33.238.215]) by po1.bbn.com (8.9.1/8.9.1) with ESMTP id PAA19513; Sat, 17 Jul 1999 15:08:12 -0400 (EDT)
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
X-Sender: [e-mail] (Unverified)
Message-Id: <v04020a06b3b578a725fe@[128.33.238.45]>
In-Reply-To: <852567B0.0051BDDF.00@LNOTES5>
Date: Sat, 17 Jul 1999 15:01:55 -0400
To: [e-mail]
From: Stephen Kent <[e-mail]>
Subject: Re: KISS for PKIX. (Was: RE: ASN.1 vs XML (used to be RE: I-D 	 ACTION :draft-ietf-pkix-scvp- 00.txt))
Cc: "'[e-mail]'" <[e-mail]>

Eric,

<snip>

>Which brings me to userids and passwords, and why I must use an application
>password even if I have issued a certificate.  Passwords provide reasonable
>assurance to me that the originator is who they say they are; as long as
>the password is kept securely. Dynamic passwords (two-factor
>authentication) provide even stronger assurance that this is so. What do I,
>as a verifier, have when a certificate is used? I have no reasonable
>assurance about the originator because I have not done anything to
>authenticate them. I don't know how secure the originator's PC is. I don't
>know if they have told the browser to cache the private key password, nor
>the strength of it. I don't know if their PC will lock itself after a
>certain amount of inactivity. I don't know who has access to the PC. It is
>not difficult to copy certificate files from one system to another. If the
>password is not strong enough, it probably would not be too difficult to
>crack it. The certificate would be more reliable, for user authentication
>purposes, if I, as an issuer, could control usage of the private key and
>user authentication, or, minimally, if It is stored on some external
>device. At least this provides two-factor authentication. I can't control
>how software vendors utilize certificates in their browser products, but I
>am at their mercy if I allow my application to run from their browser. If
>risk assessment requires me to use password security anyway, I need to be
>able to show significant incremental value added by certificates, given
>that the certifcate process places a large administrative burden around all
>this.

Passwords do not address the problem you claim, above, even though one may
argue that use of a password plus a certt adds some security to the user
authentication process.   But passwords are often guessable, and can be
compromised by the same sorts of attacks that can compromise private keys
stored on PCs, protected by a password.  So, the extent to which use of a
password increase the quality of authentication depends on a number of
factors, including the perceived threat. Yes, the preferable implementation
approach is use of a personal crypto engine token, e.g., a smart card or PC
card, which counters software-based attacks designed to extract private
keys.

I am not familiar with the phrase "dynamic passwords," in a technical
context.  Are you referring to use of hardware tokens like SecurID, used in
challange-response user authentication?  If so, then I agree that such
technology is a vast improvement over static passwords, but it is not
better than the use of certs protected by similar hardware technology,
e.g., smart cards or PC cards.  Depending on the threat model, and on the
rest of the security context on which they are employed, the relative
merits of user authentication tokens vs. certs based in software are
debatable.

Your criticism of certificates ("I have no reasonable assurance about the
originator because I have not done anything to authenticate them") seems to
assume a TTP model of issunace.  If an organization does its ownh
certificate issuance, this statement simply is not true.

>Granted, all this is less confusing if an originator is executing a
>transaction with the issuer of the cetificate, because the issuer could
>control the user authentication process. But it becomes more complex when
>the certificate is used to execute a transaction with a third party. How
>can a bank verify a certificate and, more importantly, vouch for a
>transaction, if it can't be reasonably assured the customer is who they
>claim to be? All it has is a request for validation from the third party
>(merchant) and a message.

I think you are confusing cert validation with cert issuance assurance
procedures, etc.  Cert validation is an algorithmic process.  The level of
confidence one has that the holder of the corresponding private key is the
entity specified in the Subject field is a separate matter.

Steve


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 MAA11438 for <[e-mail]>; Sat, 17 Jul 1999 12:06:43 -0700 (PDT)
Received: from [128.33.238.213] (tc238-215.bbn.com [128.33.238.215]) by po1.bbn.com (8.9.1/8.9.1) with ESMTP id PAA19510; Sat, 17 Jul 1999 15:08:10 -0400 (EDT)
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
X-Sender: [e-mail] (Unverified)
Message-Id: <v04020a05b3b5762a9042@[128.33.238.45]>
In-Reply-To: <[e-mail]>
References: <[e-mail]> <[e-mail]>
Date: Fri, 16 Jul 1999 20:01:02 -0400
To: Ed Gerck <[e-mail]>
From: Stephen Kent <[e-mail]>
Subject: Re: Common misconceptions, was Re: KISS for PKIX. (Was: RE: ASN.1 vs XML   (used to be RE: I-D 	ACTION :draft-ietf-pkix-scvp- 00.txt))
Cc: [e-mail]

Ed,

>
>> > Stephen Kent wrote:
>> > >  However, use of a PKI to support SSL, IPsec, and S/MIME
>> > > (at least on an intranet basis) does not raise such issues, yet
>>promises to
>> > > improve security and to make life easier for users.
>>
>> Ed Gerck wrote:
>> > "improve security" and "make life easy for users" seem to be
>>antinomies in all
>> > systems -- security is counter to functionality, as a general
>>principle. So, I believe
>> > that last phrase is an empty promise though it may look good in
>>marketing materials.
>> > Another common misconception.
>>
>> If PKIX  and certs do not "improve security" and "make life easy for
>>users" what is the point
>> of this WG and why would anyone want to use it ????
>
>Any amount of security will always make life harder for users. Ignoring
>this instead of
>recognizing it and then try to cope with it is one of the unseen problems
>of today. Why do
>you think only 5% of the emails (on average) are encrypted? Because
>security is a hassle
>and users will rather default to insecure methods than miss a deal. So,
>promising both
>is empty because they will never be delivered -- and, trying to make
>security "automatic"
>will just be another example of SKIP; perhaps useful in a closely watched
>network where
>you control all nodes. But, on the Internet, no one controls both ends of
>a connection,
>much less all nodes your packets may go through.

In another message I cited the instance of using client certs with SSL, vs.
remembering a name and password for each web site.  Most folks who have had
the opportunity to try client certs in this environment find that it does
make life easier, while improving security.

Steve


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 MAA11375 for <[e-mail]>; Sat, 17 Jul 1999 12:06:39 -0700 (PDT)
Received: from [128.33.238.213] (tc238-215.bbn.com [128.33.238.215]) by po1.bbn.com (8.9.1/8.9.1) with ESMTP id PAA19507; Sat, 17 Jul 1999 15:08:08 -0400 (EDT)
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
X-Sender: [e-mail] (Unverified)
Message-Id: <v04020a04b3b5737a3e9f@[128.33.238.45]>
In-Reply-To: <[e-mail]>
Date: Sat, 17 Jul 1999 14:46:15 -0400
To: [e-mail]
From: Stephen Kent <[e-mail]>
Subject: RE: Common misconceptions, was Re: KISS for PKIX. (Was: RE: ASN.1 vs XML (used to be RE: I-D 	ACTION :draft-ietf-pkix-scvp- 00.txt))
Cc: "'[e-mail]'" <[e-mail]>

Lynn,

I appreciate your fondness for cert-less public key use; after all, the
model you are describing is yours, submitted to an ANSI X.9 committee.  And
a brief discussion of it is OK too, but since the charter of the PKIX WG
focuses on the use of X.509 certificates in the Internet, extended
discussion of your cert-less model is hardly within the scope of the WG
list.

Steve


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 MAA11017 for <[e-mail]>; Sat, 17 Jul 1999 12:01:41 -0700 (PDT)
Received: from [128.33.238.213] (tc238-213.bbn.com [128.33.238.213]) by po1.bbn.com (8.9.1/8.9.1) with ESMTP id PAA19333; Sat, 17 Jul 1999 15:03:01 -0400 (EDT)
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
X-Sender: [e-mail] (Unverified)
Message-Id: <v04020a01b3b56ee8575e@[128.33.238.45]>
In-Reply-To:  <[e-mail]>
Date: Sat, 17 Jul 1999 14:22:31 -0400
To: "Flanigan, Bill" <[e-mail]>
From: Stephen Kent <[e-mail]>
Subject: RE: KISS for PKIX
Cc: [e-mail], "'[e-mail]'" <[e-mail]>

Bill,

>>
>BF:  Yes, Steve, and these legal issues go way beyond those related to a
>password (in part because now there are a whole bunch of additional entities
>involved).  They include the end entity (human and
>human-responsible-for-machine), the registration agents (RA, LRA,
>out-of-band delivery person/service), the CA (both the cert-server side and
>the directory/repository side), the PKI administrators, etc.  Then there are
>validity issues, CRL issues, repository time-and-security issues (e.g., how
>long must a cert or CRL remain in secure storage?  50 years?  150 years?)
>Aside from the CP and CPS, there are also Privacy Act issues.  Then there is
>key escrow and recovery (yes, they are completely different and involve
>different processes and entities).  I sometimes wonder if there are enough
>lawyers on the planet to support all these up-and-coming PKI!

In an intranet context, with certs used for authentication, and the
organization acting as RA and CA, I don't believe that any of these legal
issues apply.  Some may apply when one outsources the CA function, and even
more if one outsources the RA function, but that was not the example I was
trying to illustrate.

>>  However, use of a PKI to support SSL, IPsec, and S/MIME
>> (at least on an intranet basis) does not raise such issues, yet promises
>> to
>> improve security and to make life easier for users.
>>
>BF:  Whether the nonRepudiation bit is set is irrelevant from a legal
>perspective (e.g., check out the POV of S&T Subcommittee of the ABA plus
>what the States' attorneys and courts have been doing recently).

One might make a stronger assertion re certificate use and NR through a
cert policy ID, but until a trial takes place, no one of really know.

>> I disagree with your statement that a certificate in software binds a
>> system, vs. a user.  Yes, smart cards are preferable, but if the choice is
>> between a password and a certificate (and private key) with software
>> cryptography, I see no reason not to adopt the latter, and I certainly see
>> no reason to declare that the latter is not a user (vs. system)
>> authentication mechanism.
>>
>BF:  Not only do you have to physically protect the .p12 file on the floppy,
>you have to protect it from the OS(s), repeatedly.

True, but it's secure from guessing attacks whereas most passwords are not.
Trojan Horse attacks that can grab the encrypted private key file and
extract my key are also capable of grabbing passwords too, so I stand by my
assertion.

>>   Finally, why do you say that an issuer cann
>> associate a security policy with a certificate?  We have the syntactic
>> means to do so as part of the standard.  Do you mean that we don't have
>> appplications that pay attention to the policy extension?
>>
>BF:  Steve, very few humans will read (or be able to understand if they
>read) the CP.  The number of extensions in PKIX for machine-readable policy
>is miniscule compared to what is needed--I would hazard a guess of 30-50 for
>the "typical" CP (and, of course, we still have the CPS which may or may not
>have policy-related items not explicit in the CP plus CA cross certification
>where policy mapping is a MUST).

Many folks in the community make a strong distinction between a CA policy
and a CPS.  However, I agree that few users will read a CP, just like none
of us read the fine print on our rental car contracts, credti card
agreements, etc.  We still manage to get along.

>> Steve
>>
>BF:  P.S.  Being an early adopter of a PKI striving to be based on PKIX (and
>commercial products) that goes beyond the pilot level is not fun.  It almost
>seems like the standards were designed to make sure that early adopters
>don't progress beyond the pilot stage!  The same could be said of commercial
>products.  You must have very deep pockets to progress a PKI from
>supporting, say, 100K certs to 5,000K certs.  And I am rapidly coming to the
>conclusion (a conclusion I don't at all like) that if PKIX is to the PKI
>flavor of choice for the planet, it must be substantially overhauled (or
>replaced).

Sorry you feel that way.  What's your proposed alternative?  Why not
contribute more to the PKIX activities to address the concerns you have?

Steve


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 MAA11001 for <[e-mail]>; Sat, 17 Jul 1999 12:01:40 -0700 (PDT)
Received: from [128.33.238.213] (tc238-213.bbn.com [128.33.238.213]) by po1.bbn.com (8.9.1/8.9.1) with ESMTP id PAA19337; Sat, 17 Jul 1999 15:03:08 -0400 (EDT)
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
X-Sender: [e-mail] (Unverified)
Message-Id: <v04020a02b3b571c2d749@[128.33.238.45]>
In-Reply-To: <[e-mail]>
Date: Sat, 17 Jul 1999 14:31:51 -0400
To: [e-mail]
From: Stephen Kent <[e-mail]>
Subject: Re: KISS for PKIX. (Was: RE: ASN.1 vs XML (used to be RE: I-D 	 	 ACTION :draft-ietf-pkix-scvp- 00.txt))
Cc: "'[e-mail]'" <[e-mail]>

Lynn,

<snip>

>the dominate authentication application across the whole internet sphere is
>RADIUS (ISPs, corporate networks, intranets, extranets, etc). A simple upgrade
>method has been demonstrated for radius that registers the public key in place
>of the current business processes that register a password (selectively on an
>account by account basis) ... and then digital signature authentication is
>used
>in lieu of password authentication.

And some of us have also demonstrated and deployed RA's that work from an
existing password database to issue certs to users, over SSL-protected
connections, so that one can take advantage of standard, cert-based
authentication protocols, builti-in browser key and cert gen etc.

>One of the simplest issues is that a standard X.509 "identity" can represent
>privacy invasion and/or violation of privacy mandates if full name/details are
>available ... or if relying-party-only certificate is used .... it it is
>trivial
>to show that if the authenticated transaction has to hit an accound-record
>(like
>logging on to an ISP and the ISP wants to know if your account is still active
>... and hasn't been voided because of something like spam'ing) then having the
>certificate is superfulous and redundant since the public key can be extracted
>from the account. it also eliminates any question of legal issues that having
>been shroading certificates in the area of trust-propogation

This criticism of certificates is another red herring.  I assume you are
referring to a DN here, but DNs can be constructed to avoid giving away too
much info, if that's a concern.  For example SET certificates use a hash of
a clients credit card number as part of the ID, to avoid disclosing that
sentitive data.  Yes, one can adopt a cert-less approach, as you have
proposed in ANSI and articulated above, but it is not necessary, nor is it
sufficient, in many contexts, although it can work in others.

>The interesting thing is that certificate-less PKIs tend to preserve exactly
>existing authentication business processes .... while at the same time being
>able to utilize off-the-self digital signing protocols/technology (just
>forgetting to append the certificate when sending off the transaction, or
>if you
>will, using knowledge-base compression to compress the size of the certificate
>to zero bytes).
>
>In that sense, certificate-less PKIs are one of the most aggressive
>applications
>of KISS (elimination of redundant and/or superfulous business processes when
>there are perfectly good processes in place today).

Well, that's one way to look at them.  However, if a company wanted to
deploy a PKI for its employees, and wanted to be able to use it for SSL,
IPsec, and S/MIME, to better amortize the management costs, then a
cert-less approach would not be viable.

Steve


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 MAA10954 for <[e-mail]>; Sat, 17 Jul 1999 12:01:00 -0700 (PDT)
Received: from [128.33.238.213] (tc238-213.bbn.com [128.33.238.213]) by po1.bbn.com (8.9.1/8.9.1) with ESMTP id PAA19316; Sat, 17 Jul 1999 15:02:25 -0400 (EDT)
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
X-Sender: [e-mail] (Unverified)
Message-Id: <v04020a00b3b56b6383a7@[128.33.238.45]>
In-Reply-To: <[e-mail]>
References: <v04020a02b3b3e54bc992@[128.33.238.108]>
Date: Sat, 17 Jul 1999 14:18:02 -0400
To: Ed Gerck <[e-mail]>
From: Stephen Kent <[e-mail]>
Subject: Re: Common misconceptions, was Re: KISS for PKIX. (Was: RE: ASN.1 vs XML   (used to be RE: I-D 	ACTION :draft-ietf-pkix-scvp- 00.txt))
Cc: "'[e-mail]'" <[e-mail]>

Ed,

>This is often a source of confusion. But, basically, the reason is that
>passwords
>have no challenge-response mechanism.  Since a password can be replayed at
>will, the authenticating party (ie, the verifier) is barred from
>presenting an argument
>of non-repudiation when passwords are used because the verifier could have
>generated any message all by itself -- the data is intrinsically
>corrupted. OTOH,
>if certificates are used then non-repudiation data may be built by the
>verifier
>*notwithstanding* the desire of the authenticated party to refuse it.
>Which data
>can then be used in administrative (eg, within company boundaries) or legal
>or extra-legal (blackmail) procedures *against* the authenticated party and
>*against* its expressed will (since the decision to apply, accept or reject
>administrative, legal or extra-legal procedures will lie above the party,
>in general).
>But, there are other legal issues and cert storage liability is certainly
>one that also
>comes to mind -- a user cannot so easily take his private cert with him
>when he
>travels (just try it in NS browsers at some hotels for example) unless he
>takes his
>laptop...  which can then be stolen or searched.

Huh? Your characterization of why passwords don't provide NR is a bit over
simplified, as challenge-response technologies also don't provide a basis
for NR in most instances either.  Moreover, many of the ways in which we
use certificates for authentication do not confer non-repudaition, hence my
point. I do have some certs polyinstantiated on my laptop, desktop, and
home machines, in Netscape.  It's doable.  Although the observation about
the opportunity for theft is accurate, it seems a bit far afield of this
discission.

>So, this one is not a red herring at all but a red sign of warning. It is
>a common
>misconception, though, to assume that all authentication procedures are
>legally
>equivalent -- but, they simply aren't and for several legal reasons.

What you said above does not seem to support this conclusion.

>> Part of the problem is that people have been led to believe that a
>> PKI must support non-repudiation, which generates a large number of valid,
>> legal concerns.
>
>Part of the problem is that PKIX also has a so-called non-repudiation bit ;-)

Yes, and it is used to allow a CA to distinguish between a cert issued for
signing data for auth vs. signing data for NR.  What's wrong with that?

>>  However, use of a PKI to support SSL, IPsec, and S/MIME
>> (at least on an intranet basis) does not raise such issues, yet promises to
>> improve security and to make life easier for users.
>
>"improve security" and "make life easy for users" seem to be antinomies in all
>systems -- security is counter to functionality, as a general principle.
>So, I believe
>that last phrase is an empty promise though it may look good in marketing
>materials.

One example comes to mind in the context of SSL client certs.  They are
much preferable to use vs. remembering different names and passwords for
each web site that requires a login, and the security afforded by client
certs is much better than passwords, even if the corresponding private keys
are stored on my disk.

>Another common misconception.
>
>> I disagree with your statement that a certificate in software binds a
>> system, vs. a user.
>
>I fail to see how you can possibly disagree with Eric's statement.  Trust
>is not
>distributive in the social sense (ie, not associative in the mathematical
>sense),
>which alone opens the problem that (here, * is the trust operator):
>
> (A*B)*K <> A*(B*K)
>
>and thus, for example, Alice may trust that Bob's certificate binds to Bob
>(ie, A*B)
>before Alice knows that Bob trusts Khadaffi (ie, B*K), but not afterwards
>(ie, A*(B*K)).
>Or, as another example, I may trust my lawyer before I know  that he
>trusts my competitor
>but not afterwards. Or, Bill may trust Monica before Bill knows that
>Monica trusts
>Linda, but not afterwards. In summary, this is the "unfaithful proxy "
>problem as I call it
>-- you can never tell is there is an unfaithful proxy. However, to think
>otherwise and to
>believe that (A*B)*K = A*(B*K) is a common misconception that leads one to
>believe
>that Bob's certificate binds to Bob irrespective of Bob's trust on
>Khadaffi -- in fact, Bob
>may not even exist.
>
>So, you cannot affirm that a cert binds a user -- which user?  At most,
>you can
>affirm that your challenge-response logs, traceroute, timestamps and whatever
>may indeed point to a system that  you believe  has authenticated it --
>but only
>as an evidence, not as a fact.

I have no idea what are you talking about? The statement I questioned was
an assertion that a cert with a privcate key protected via software did not
provide a suitabel basis for user, vs. system, authentication.  Your
argument above does not seem to bear on that at all.

>> Yes, smart cards are preferable, but if the choice is
>> between a password and a certificate (and private key) with software
>> cryptography, I see no reason not to adopt the latter,
>
>One reason is to deny unwanted non-repudiation.  Another is to reduce
>cert storage liability. Etc.

I was talking about certs used for auth, not NR, making the comparison to
passwords meaningful.

>> and I certainly see
>> no reason to declare that the latter is not a user (vs. system)
>> authentication mechanism.
>
>as above, trust is not distributive (socially).

Again, your argument seems orthogonal to the issue I was addressing.

>> Finally, why do you say that an issuer cann[ot]
>> associate a security policy with a certificate?  We have the syntactic
>> means to do so as part of the standard.
>
>In which language? In which legal system? In which jurisdiction?
>Syntax does not answer these (and other) questions at all -- and yet,
>any of them makes the problem overly-variable in comparison to the
>given syntax.  All security policies (eg, CPS) need to call themselves
>"mutually exclusive" (otherwise I could just devise a security policy that
>would render yours ineffective) and yet they can all be different since
>security policies per se are not defined as part of the standard, just
>referred
>in the standard as we all know.

Hard copy contracts specify the language and jursidiction of
interpretation, and cert policies can do the same. The fact that the policy
is incorporated by use of an OID does not affect this.  Again, I fail to
see the point of your comments.

>> Do you mean that we don't have
>> appplications that pay attention to the policy extension?
>
>Policy extensions are not infused with meaning, they are simply pointers
>to a meaning -- which meaning can be  inacessible to the application,
>outdated,
>invalid in that jurisdiction, etc.

But one configures an application to accept of rejects certs based on
policy IDs, based on a human being having read the policy and made a value
judgement.  We dopn't expect applications to make these decisions, but
rather to enforce the decisions already made by users or system
administrators.

Steve


Received: from rbhub101.chamb.disa.mil (rbhub101.chamb.disa.mil [209.22.120.24]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id HAA09524 for <[e-mail]>; Sat, 17 Jul 1999 07:36:04 -0700 (PDT)
Received: by rbhub101.chamb.disa.mil with Internet Mail Service (5.5.2448.0) id <3XZYX72V>; Sat, 17 Jul 1999 10:38:12 -0400
Message-ID: <[e-mail]>
From: "Vickers, Randal R" <[e-mail]>
To: "PKIX Mailing List (E-mail)" <[e-mail]>
Cc: "Flanigan, Bill" <[e-mail]>, "Friedrichs, Paul" <[e-mail]>, "Nelson, Lee" <[e-mail]>, "Sam Schaen (E-mail)" <[e-mail]>, "Jamil Nimeh (E-mail)" <[e-mail]>
Subject: Showing Nationality in Cert
Date: Sat, 17 Jul 1999 10:40:52 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2448.0)
Content-Type: text/plain; charset="iso-8859-1"

I work with the US DoD PKI engineers at the Defense Information Systems
Agency. Requirements from the Assistant Secretary of Defense for C3I state
that we must show citizenship or nationality (symantics) in the cert. My
question is what extension  does anyone reccommend placing it in. We have
looked at subjectDirectoryattribute and one of the extensions below
subjectAlternatename. We are not locked into any one thing as long as it is
standards based.
	Thanks
	Randal Vickers


Received: from www.meridianus.com (209.249.223.15.has.no.reverse [209.249.223.15] (may be forged)) by mail.proper.com (8.8.8/8.8.5) with ESMTP id EAA08075 for <[e-mail]>; Sat, 17 Jul 1999 04:57:00 -0700 (PDT)
Received: from PC1 by www.meridianus.com (8.8.8+Sun/SMI-SVR4) id FAA04203; Sat, 17 Jul 1999 05:53:03 -0700 (PDT)
Message-ID: <032a01bed04d$67faee30$[e-mail]>
From: "Todd S. Glassey" <[e-mail]>
To: <[e-mail]>, "Joe Tardo" <[e-mail]>
Cc: <[e-mail]>
References: <852567B0.006E46F1.00@LNOTES5>
Subject: Re: Digital Signature Laus (was Re: KISS for PKIX)
Date: Sat, 17 Jul 1999 05:10:48 -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 5.00.2918.2701
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2918.2701

The Perkins Coie site is good as is Tom Smeddinghoff's site at
http://www.mbc.com We have pointers to most of these on out
http://www.gmtsw.com/partners.html page.

Todd
----- Original Message -----
From: <[e-mail]>
To: Joe Tardo <[e-mail]>
Cc: <[e-mail]>
Sent: Friday, July 16, 1999 1:06 PM
Subject: Re: Digital Signature Laus (was Re: KISS for PKIX)


> For summary info:
> See the Internet Law & Policy Forum site at
> http://www.ilpf.org/digsig/digsig2.htm
>
> for individual states see
> http://www.perkinscoie.com/resource/ecomm/digsig/state.htm, which the ILPF
> links to.
>
> eric
>
>
>
>
>
>
>
>
> Joe Tardo <[e-mail]> on 07/16/99 12:20:17 PM
>
> To:   Eric Guerrino, Stephen Kent <[e-mail]>
> cc:   "'[e-mail]'" <[e-mail]>
> Subject:  Digital Signature Laus (was Re: KISS for PKIX)
>
>
> Received: from EMAIL ([160.100.151.79]) by LNOTES5 (Lotus SMTP MTA v1.2
> (600.1 3-26-1998)) with SMTP id 852567B0.0065A3F4; Fri, 16 Jul 1999
> 14:30:11 -0400
> Received: from eagle.ssg.bny.com by EMAIL via SMTP with TCP; Fri,
>        16 Jul 99 14:29:46-EDT
> Received: from [208.226.86.1] by eagle.ssg.bny.com via smtpd (for
>        email.ssg.bny.com [160.100.151.79]) with SMTP; 16 Jul 1999 18:29:44
> UT
> Received: (qmail+freegate 2460 invoked by alias); 16 Jul 1999 18:29:39
>        -0000
> Received: from ws7-n0.hq.freegate.com (HELO tardo3.hq.freegate.com)
>        (208.226.86.135) by hq.freegate.com with SMTP; 16 Jul 1999
>        18:29:39 -0000
> Message-Id: <[e-mail]>
> X-Sender: [e-mail]
> X-Mailer: Windows Eudora Pro Version 3.0.1 (32)
> Date: Fri, 16 Jul 1999 09:20:17 -0700
> To: Eric_Guerrino@LNOTES5, Stephen Kent <[e-mail]>
> From: Joe Tardo <[e-mail]>
> Subject: Digital Signature Laus (was Re: KISS for PKIX)
> Cc: "'[e-mail]'" <[e-mail]>
> In-Reply-To: <852567B0.0051BDDF.00@LNOTES5>
> Mime-Version: 1.0
> Content-Type: text/plain; charset="us-ascii"
>
>
>
>
> At 01:28 PM 7/16/99 -0400, [e-mail] wrote:
>
> >There are legal issues to be resolved regarding limitations of liability
> >and responsibilities of issuers, certificate authorities, subscribers,
and
> >relying parties. There are legal issues to be resolved regarding digital
> >signatures. Last time I checked, about thirty states had enacted or were
> in
> >the process of enacting digital signature laws. The federal government
has
> >a digital signature law pending.
>
> Does anyone have the digital signature legislation URLs handy referencing
> the latest on what the 30 states and Federal Government are enacting?
>
> Thanks,
> Joe
>
>
>
>
>



Received: from www.meridianus.com (209.249.223.21.has.no.reverse [209.249.223.21] (may be forged)) by mail.proper.com (8.8.8/8.8.5) with ESMTP id EAA08033 for <[e-mail]>; Sat, 17 Jul 1999 04:54:49 -0700 (PDT)
Received: from PC1 by www.meridianus.com (8.8.8+Sun/SMI-SVR4) id FAA04199; Sat, 17 Jul 1999 05:50:34 -0700 (PDT)
Message-ID: <032301bed04d$1b93c1c0$[e-mail]>
From: "Todd S. Glassey" <[e-mail]>
To: "Anders Rundgren" <[e-mail]>, "PKIX-List" <[e-mail]>, "Ed Gerck" <[e-mail]>
References: <003401becfd8$52a456e0$[e-mail]>
Subject: Re: Common misconceptions, was Re: KISS for PKIX. (Was: RE: ASN.1 vs XML (used to beRE: I-D 	ACTION :draft-ietf-pkix-scvp-00.txt))
Date: Sat, 17 Jul 1999 05:08:20 -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 5.00.2918.2701
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2918.2701

----- Original Message -----
From: Anders Rundgren <[e-mail]>
To: PKIX-List <[e-mail]>; Ed Gerck <[e-mail]>
Sent: Friday, July 16, 1999 3:12 PM
Subject: Re: Common misconceptions, was Re: KISS for PKIX. (Was: RE: ASN.1
vs XML (used to beRE: I-D ACTION :draft-ietf-pkix-scvp-00.txt))


> Ed,
> >> Note: I deliberately excluded national ID-CAs who HAVE to verify
absolute identity (which is
> >> harder and harder to do with all paper-less refugees in Europe).
> >
> >The "harder and harder to do" is what makes a certificate not bind to a
user -- and even
> >if you have all proper papers in notarized copies you still do not know.
And, BTW, just
> >read any CA warranty and you will see they also do not know and they say
so -- "NO
> >WARRANTY, NO SUITABILITY OF PURPOSE".]

This is merely an effect of the uptake of global cert use. In 5 years or
better yet in 10 years you will laugh that you even said this. Certs and
CA's will be everywhere.

>
> Well, I don't (unlike most other PKI-folks) believe that it is absolutely
necessary
> for the success of PKIs, that CAs should be able to warrant and insure for
all kinds of problems.

This is definitielt true. But for the use models and the types of
transaction processes they do support, if the proper transaction critera and
auditing services are available  then this is no problem. One of these
things is a well defined and integrated audit or timestampig system, I would
think.

>
> To me certificates should be compared to mechanical locks. A lock
manufacturer usually
> only guarantees that a lock is manufactured to conform to a certain
industry-standard (CPS).
> Not that the lock is guaranteed to protect values up to $1000000. There
are exceptions but
> then we are not talking mainstream.
>
> Regarding the binding I believe that certificates and CAs make sense if
the CA
> can guarantee (with high but not unlimited probability) that an individual
cannot
> "borrow" another's identity.  This is certainly feasible, partly by using
biometrics.
> And is not terribly expensive either.
> To nail down an individual's true TRUE identity is NOT a requirement for
employers, banks
> etc. as long as you perform according to their rules.  If an RP needs
stronger proofs of
> identity this may have to be carried out without the CA.

But Biometrics only addressses the Retail POS style model, becuase once the
Biometric data is captured, it takes on the same vulnerability as the reast
of the sata used as the auth enablement.

This is a really important problem since most players are swinging for a
longer ball than just retail POS transactions that have a "direct conscious
human particpant". The idea is that the system should work when there are no
humans anywhere in the mix and that is why the liability or reliance
limitations are so important.

>
> National CAs are exceptions that probably never will be mainstream (except
MAYBE in countries
> like Sweden with a long ID-card tradition)

I disagree here too. I think it is likely that CA's at the national level
will be erected by all countries that offer automated or net based services
and access models, but it is likly that the CA itself will be buried inside
a larger process so as such it may not be "visible as a CA" per say.

>

Todd



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 OAA26042 for <[e-mail]>; Fri, 16 Jul 1999 14:13:38 -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 XAA07436 for <[e-mail]>; Fri, 16 Jul 1999 23:15:06 +0200
Received: from mega (t4o69p118.telia.com [62.20.145.238]) by caesar.udac.se (8.7.3/NetworkC-1) with SMTP id XAA46560; Fri, 16 Jul 1999 23:15:04 +0200
Message-ID: <003401becfd8$52a456e0$[e-mail]>
From: "Anders Rundgren" <[e-mail]>
To: "PKIX-List" <[e-mail]>, "Ed Gerck" <[e-mail]>
Subject: Re: Common misconceptions, was Re: KISS for PKIX. (Was: RE: ASN.1 vs XML (used to beRE: I-D 	ACTION :draft-ietf-pkix-scvp-00.txt))
Date: Fri, 16 Jul 1999 23:12:41 +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.3110.5
X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by mail.proper.com id OAA26043

Ed,
>> Note: I deliberately excluded national ID-CAs who HAVE to verify absolute identity (which is
>> harder and harder to do with all paper-less refugees in Europe).
>
>The "harder and harder to do" is what makes a certificate not bind to a user -- and even
>if you have all proper papers in notarized copies you still do not know. And, BTW, just
>read any CA warranty and you will see they also do not know and they say so -- "NO
>WARRANTY, NO SUITABILITY OF PURPOSE".

Well, I don’t (unlike most other PKI-folks) believe that it is absolutely necessary
for the success of PKIs, that CAs should be able to warrant and insure for all kinds of problems.

To me certificates should be compared to mechanical locks. A lock manufacturer usually
only guarantees that a lock is manufactured to conform to a certain industry-standard (CPS).
Not that the lock is guaranteed to protect values up to $1000000. There are exceptions but
then we are not talking mainstream. 

Regarding the binding I believe that certificates and CAs make sense if the CA 
can guarantee (with high but not unlimited probability) that an individual cannot
"borrow" another’s identity.  This is certainly feasible, partly by using biometrics.   And is not terribly expensive either.
To nail down an individual’s true TRUE identity is NOT a requirement for employers, banks 
etc. as long as you perform according to their rules.  If an RP needs stronger proofs of
identity this may have to be carried out without the CA.

National CAs are exceptions that probably never will be mainstream (except MAYBE in countries
like Sweden with a long ID-card tradition)

Anders




Received: from mtiwmhc03.worldnet.att.net (mtiwmhc03.worldnet.att.net [204.127.131.38]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id OAA25840 for <[e-mail]>; Fri, 16 Jul 1999 14:09:48 -0700 (PDT)
Received: from btw.btw.net ([12.72.37.111]) by mtiwmhc03.worldnet.att.net (InterMail v03.02.07.07 118-134) with SMTP id <[e-mail]> for <[e-mail]>; Fri, 16 Jul 1999 21:10:44 +0000
Received: by btw.btw.net with Microsoft Mail id <[e-mail]>; Fri, 16 Jul 1999 14:10:45 -0700
Message-ID: <[e-mail]>
From: Russ Savage <[e-mail]>
To: "'[e-mail]'" <[e-mail]>, "[e-mail]" <[e-mail]>
Subject: RE: Common misconceptions, was Re: KISS for PKIX, was ...
Date: Fri, 16 Jul 1999 14:10:22 -0700
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit

-----Original Message-----
From:	Peter Gutmann [SMTP:[e-mail]]
Sent:	Saturday, July 17, 1999 1:13 AM
To:	[e-mail]
Subject:	Re: Common misconceptions, was Re: KISS for PKIX, was ...

"David P. Kemp" <[e-mail]> writes:

>A proposed approach to allocating liability included a root CA operated by an
>organization with huge assets (such as a commercial bank) but with only two 
>warranted responsibilities: 1) ensuring name uniqueness across the certs 
>issued by that CA, and 2) protecting the CA's private key.  (A third, 
>unstated, requirement would be to use sufficiently conservative cryptography 
>for signatures on the issued certs).
>
>[...]
>
>You (as a relying party) can rely on a certificate to any extent you wish.  A
>CA may warrant that it follows certain practices; it may also warrant 
>results, as with the hypothetical root CA above, if the amount of loss and 
>the risk of loss can be quantified.  You, the relying party, assume all risk 
>not assumed by the CA.  You are the sole judge of whether the PKI provides a 
>benefit - whether profit from transactions enabled by the PKI minus expected 
>losses from risks not assumed by the PKI is positive.

You know, this would actually work (and it's effectively what organisations 
like Verisign are doing anyway through their CPS).  Apart from the obvious 
objection (<whine>but a PKI isn't supposed to work like that</whine>), is 
there any major reason why this is a bad thing?

Peter.

=======
Any signature use ("wet" or digital) is governed by various forms of contract law.

This is edging into the reason for my earlier message -
the risk an organization is willing to take is, as stated, related to reward.
But also to predictibility/stability of the context - do I really know what I'm liable for
when I sign or accept someone else's signature?
So, if the underlying rules of conduct are inconsistent/unpredictable then
that is risk as well. If there aren't consistent methods for assuring the validity, 
authenticity and _reasonable_ non-repudiation - then what is my risk?
Why should I take it? And if the methods vary over time - how do I know
I'll have recourse down the line when there is a dispute?

Wrapping all that into one package isn't realistic.
There will be change.
There will be many, many special cases and parsing through them
can be recipe for a disaster. I wonder is having a core PKI blob of a bit stream
that can then have adjacent blobs for whatever special case _some_ need
(e.g. additional timestamps or particular types of timestamps)
wouldn't work better than a constant debate about what can, should or
shouldn't be incorporated into the core bit stream and what the rules 
of parsing will be.

And I would put issues about policy (CA & others) outside it as well
what policy is needed will vary. And, I suspect, will morph dramatically
as we move toward cross-certifying an individual by their different
roles in different organizations with layers of trust depending on the
context and the role that's at the other end of the PKI exchange.
PK is simply public/private key exchange in a reliable way.
The infrastructure is going to morph until we get something
that matches the kinds of interactions we have in the brick&mortar world.
That won't fit in one standard. Is PKI simply public/private key exchange
or is it this entire infrastructure that edges into LDAP, privacy/identity, 
what have you?

I'd really like to know what this group sees its task to be.
I'm hearing a wide range of ambitions for the WG.

newbieRuss

btw - a good review from the legal/business practice perspective is
"Moving With Change: Electronic Signature Legislation As A Vehicle For Advancing E-Commerce" 
By Thomas J. Smedinghoff And Ruth Hill Bro of McBride Baker & Coles (www.mbc.com)




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 OAA25607 for <[e-mail]>; Fri, 16 Jul 1999 14:02:39 -0700 (PDT)
Received: from [128.33.238.45] (TC045.BBN.COM [128.33.238.45]) by po1.bbn.com (8.9.1/8.9.1) with ESMTP id RAA19209; Fri, 16 Jul 1999 17:04:02 -0400 (EDT)
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
X-Sender: [e-mail] (Unverified)
Message-Id: <v04020a00b3b548ef0731@[128.33.238.108]>
In-Reply-To: <002401beced0$d49d2360$[e-mail]>
References: <[e-mail]> <[e-mail]>
Date: Fri, 16 Jul 1999 16:43:07 -0400
To: "Todd S. Glassey" <[e-mail]>
From: Stephen Kent <[e-mail]>
Subject: Re: When is Timestamp applied?
Cc: <[e-mail]>

At 7:46 AM -0700 7/15/99, Todd S. Glassey wrote:
>I have a small question....

<deleted message from Denis>

>Why doesn't PKIX assign these efforts in a delegated manner to STime and
>make the STime folks produce a schedule for "it". It seems to me that PKIX
>is swelling to address the totality of the PKI enablement world, and you
>know - this is likely to be appropriate. However my feeling is that PKIX
>would be warrented in allowing other fledgling orgs like STime and its more
>developed bretheren like the XML DigSig groups to offload some of the core
>enablement at the application construct levels. PKI will be the forum where
>these all come together in the IETF and to my mind that reinforces the
>structure and the operations of the Security Area and its local Directorates
>actions in the furtherance of the marketplace.

Todd, the secure time WG has a well dfined charter, and it does not include
time stamping.  PKIX amended its charter to encompass time stamping, but
only to the extent that it relates to PKI.  We have adequate intra-WG
relationships among the groups you cite in your message.  XMLDigSig has
nothing to do with this topic, at least at this time.

>I see this as a big win potentially for the PKIX Chairs and the IETF as a
>whole since it will mandate putting in place something thast defines IntraWG
>processes to handle a "formal delegation" of responsibility.

If you feel that the process is not working, feel free to raise the
question with the Security ADs.

Steve


Received: from pub.siac.com (pub.siac.com [162.69.5.194]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id NAA25345 for <[e-mail]>; Fri, 16 Jul 1999 13:53:39 -0700 (PDT)
Received: from bigmouth.siac.com(162.69.5.8) by pub.siac.com via smap (4.1) id xma028019; Fri, 16 Jul 99 16:54:44 -0400
Received: from siac.com (dfinkels@localhost [127.0.0.1]) by orchid.wisdom.siac.com (8.8.6 (PHNE_17135)/8.8.6) with ESMTP id QAA21501 for <[e-mail]>; Fri, 16 Jul 1999 16:54:39 -0400 (EDT)
Sender: [e-mail]
Message-ID: <[e-mail]>
Date: Fri, 16 Jul 1999 16:54:39 -0400
From: Daniel Finkelstein <[e-mail]>
Organization: Securities Industry Automation Corporation
X-Mailer: Mozilla 4.61 [en] (X11; U; HP-UX B.10.20 9000/879)
X-Accept-Language: en
MIME-Version: 1.0
To: PKIX-List <[e-mail]>
Subject: Re: I-D ACTION:draft-ietf-pkix-scvp-00.txt
References: <[e-mail]>
Content-Type: text/html; charset=us-ascii
Content-Transfer-Encoding: 7bit

<!doctype html public "-//w3c//dtd html 4.0 transitional//en">
<html>
Michael Myers wrote:
<blockquote TYPE=CITE>Steve,
<p>Let us however lose sight of the fact that certificates provide a very
<br>convenient vehicle for the transport of application-independant attributes.
<br>One's purchasing authority or purchase authorization authority isn't
and
<br>shouldn't necessarily be restricted to a particular application context.&nbsp;
We
<br>run the risk otherwise of re-inventing the equivalent of a PKI for
each
<br>application.</blockquote>
Yes, this is true. But there is also the distinction to make between the
data that certificates via encryption of some kind protect, and the data
in the certificates themselves. All the data in the certificates can be
stored and retrieved elsewhere, such as SQL databases, LDAP and X.500 directory
services, and so on. But the <i>protected</i> data isn't so portable...yet.
Just to reiterate your point by logical extension.
<pre>--&nbsp;
Daniel Alex Finkelstein
New Technologies
phone&nbsp;&nbsp; 212-383-2951
pager&nbsp;&nbsp; 917-427-1630
fax&nbsp;&nbsp;&nbsp;&nbsp; 212-383-3289
Securities Industry Automation Corporation</pre>
&nbsp;</html>



Received: from pub.siac.com (pub.siac.com [162.69.5.194]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id NAA25002 for <[e-mail]>; Fri, 16 Jul 1999 13:38:38 -0700 (PDT)
Received: from bigmouth.siac.com(162.69.5.8) by pub.siac.com via smap (4.1) id xma027375; Fri, 16 Jul 99 16:39:33 -0400
Received: from siac.com (dfinkels@localhost [127.0.0.1]) by orchid.wisdom.siac.com (8.8.6 (PHNE_17135)/8.8.6) with ESMTP id QAA21116 for <[e-mail]>; Fri, 16 Jul 1999 16:39:28 -0400 (EDT)
Sender: [e-mail]
Message-ID: <[e-mail]>
Date: Fri, 16 Jul 1999 16:39:28 -0400
From: Daniel Finkelstein <[e-mail]>
Organization: Securities Industry Automation Corporation
X-Mailer: Mozilla 4.61 [en] (X11; U; HP-UX B.10.20 9000/879)
X-Accept-Language: en
MIME-Version: 1.0
To: "'[e-mail]'" <[e-mail]>
Subject: Re: The Average User  (Was: RE: ASN.1 vs XML (used to be RE:  I-DACTION:draft-ietf-pkix-scvp-00.txt))
References: <[e-mail]>
Content-Type: text/html; charset=us-ascii
Content-Transfer-Encoding: 7bit

<!doctype html public "-//w3c//dtd html 4.0 transitional//en">
<html>
"Flanigan, Bill" wrote:
<blockquote TYPE=CITE>Hello Steve,
<p>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Boy, have you ever got that
one right!&nbsp; The *average user* in a
<br>large organization's PKI is often just barely computer literate, and
doesn't
<br>know (or care) what a browser is much less how it works.&nbsp; It's
just
<br>point-and-click, point-and-click, etc.&nbsp; And this is how it should
be.&nbsp; If
<br>you don't "hide all technology from all life forms," it won't be used
(or
<br>used correctly).&nbsp; For those who are interested (less than five
percent of
<br>end users?), they can, of course, view the windows proffered by their
<br>favorite browser or download the binary from the repository.</blockquote>
I think this makes a strong case for centralized policy mechanisms, a la
Mission Control for Netscape (browsers), that users don't need to know
about nor maintain. But how about override?
<p>The balance between central control and user control shifts depending
on, as you mentioned, the knowledge/intelligence of the user, the requirements
of the application and environment, and the capabilities of the infrastructure.
<pre>--&nbsp;
Daniel Alex Finkelstein
New Technologies
phone&nbsp;&nbsp; 212-383-2951
pager&nbsp;&nbsp; 917-427-1630
fax&nbsp;&nbsp;&nbsp;&nbsp; 212-383-3289
Securities Industry Automation Corporation</pre>
&nbsp;</html>



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 NAA24539 for <[e-mail]>; Fri, 16 Jul 1999 13:11: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 IAA04219 for <[e-mail]>; Sat, 17 Jul 1999 08:12:43 +1200 (NZST) (sender [e-mail])
Received: by cs26.cs.auckland.ac.nz (relaymail v0.9) id <93215596327840>; Sat, 17 Jul 1999 08:12:43 (NZST)
From: [e-mail] (Peter Gutmann)
To: [e-mail]
Subject: Re: Common misconceptions, was Re: KISS for PKIX, was ...
Sender: [e-mail]
Reply-To: [e-mail]
X-Charge-To: pgut001
X-Authenticated: relaymail v0.9 on cs26.cs.auckland.ac.nz
Date: Sat, 17 Jul 1999 08:12:43 (NZST)
Message-ID: <[e-mail]>

"David P. Kemp" <[e-mail]> writes:

>A proposed approach to allocating liability included a root CA operated by an
>organization with huge assets (such as a commercial bank) but with only two 
>warranted responsibilities: 1) ensuring name uniqueness across the certs 
>issued by that CA, and 2) protecting the CA's private key.  (A third, 
>unstated, requirement would be to use sufficiently conservative cryptography 
>for signatures on the issued certs).
>
>[...]
>
>You (as a relying party) can rely on a certificate to any extent you wish.  A
>CA may warrant that it follows certain practices; it may also warrant 
>results, as with the hypothetical root CA above, if the amount of loss and 
>the risk of loss can be quantified.  You, the relying party, assume all risk 
>not assumed by the CA.  You are the sole judge of whether the PKI provides a 
>benefit - whether profit from transactions enabled by the PKI minus expected 
>losses from risks not assumed by the PKI is positive.

You know, this would actually work (and it's effectively what organisations 
like Verisign are doing anyway through their CPS).  Apart from the obvious 
objection (<whine>but a PKI isn't supposed to work like that</whine>), is 
there any major reason why this is a bad thing?

Peter.



Received: from svhw0001.statestreet.com (svhw0001.statestreet.com [205.181.240.21]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id NAA24332 for <[e-mail]>; Fri, 16 Jul 1999 13:08:36 -0700 (PDT)
Received: from statestreet.com (itdw2018.itd.ssb.com [155.108.150.43]) by svhw0001.statestreet.com (8.9.1/8.9.1) with ESMTP id QAA05472; Fri, 16 Jul 1999 16:09:11 -0400 (EDT)
Message-ID: <[e-mail]>
Date: Fri, 16 Jul 1999 16:08:08 -0400
From: David Slattery <[e-mail]>
Organization: State Street Bank and Trust
X-Mailer: Mozilla 4.5 [en] (WinNT; U)
X-Accept-Language: en
MIME-Version: 1.0
To: [e-mail]
CC: [e-mail]
Subject: Re: Common misconceptions, was Re: KISS for PKIX. (Was: RE: ASN.1 vs XML  (used to be RE: I-D 	ACTION :draft-ietf-pkix-scvp- 00.txt))
References: <[e-mail]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

[e-mail] wrote:

> David Slattery wrote:
>
> > > Stephen Kent wrote:
> > > >  However, use of a PKI to support SSL, IPsec, and S/MIME
> > > > (at least on an intranet basis) does not raise such issues, yet promises to
> > > > improve security and to make life easier for users.
> >
> > Ed Gerck wrote:
> > > "improve security" and "make life easy for users" seem to be antinomies in all
> > > systems -- security is counter to functionality, as a general principle. So, I believe
> > > that last phrase is an empty promise though it may look good in marketing materials.
> > > Another common misconception.
> >
> > If PKIX  and certs do not "improve security" and "make life easy for users" what is the point
> > of this WG and why would anyone want to use it ????
>
> Any amount of security will always make life harder for users. Ignoring this instead of
> recognizing it and then try to cope with it is one of the unseen problems of today. Why do
> you think only 5% of the emails (on average) are encrypted? Because security is a hassle
> and users will rather default to insecure methods than miss a deal. So, promising both
> is empty because they will never be delivered -- and, trying to make security "automatic"
> will just be another example of SKIP; perhaps useful in a closely watched network where
> you control all nodes. But, on the Internet, no one controls both ends of a connection,
> much less all nodes your packets may go through.
>
> So, what I am saying is that it is better to face the problem, straight. Security and "easier
> life for users" are simply opposites. Thus, let's design methods with this in mind -- users
> do not have the training to be trusted to follow the "secure" procedure instead of
> just choosing a simpler procedure.
>
> The purpose of this WG is then to make security tolerable to users in regard to what it
> delievers.

    I believe that only 5% of e-mail are encrypted because most of the e-mail people send
are not sensitive. The rest maybe sensitive but encrypted e-mail does not give them allot.
Yes they have encrypted mail. But is it secure?  Do they store their key properly?
Does the CA storage their key properly? Can I get my key back if I loose it?
Can my employer or gov. get my key? etc....etc... That is allot for a user to deal
with. Never mind that they have to create and mange keys maybe install e-mail
clients work with certs and then no one else is able to read there message. Why is
none of the e-mail sent to this group is encrypted or at least signed ? Is it because
"users do not have the training to be trusted to follow the "secure" procedure instead of
just choosing a simpler procedure."

I think the bottom line is it just is not worth all the effort for the rewards for 95%
of e-mail users.

I do agree with your statement: "The purpose of this WG is then to make security
tolerable to users in regard to what it delievers."
Well said.


>
> > I believe security is a form of understanding. Thus confinement can be a tool of security but
> > it is not the goal.
>
> Yes, this phrase is mine. I am glad you read the email or the paper -- but, next time, pls
> cite the (c) and source ;-)

    Sorry, I always liked that quote but I had forgotten where I read it. I guess if I am to be
corrected you are the best one to do it. I will be sure to quote your name.

>
>
> One point of the phrase is that confining users to procedures does not necessarily increase
> their security level -- also because the fraudsters are usually unconfined ;-)  and because
> users will then be lead to trust "the system" instead of  trusting their use of the system.

agreed.

>
>
> Cheers,
>
> Ed Gerck

Thanks
-Dave



--
  *************************************************************************
  This e-mail expresses my personal views and not those of State State.
  STATE STREET BANK                             Information Technology
  Telephone: [phone]                     Client-Server Technology
  *************************************************************************




Received: from mailbox1.appliedtheory.com (mailbox1.appliedtheory.com [204.168.16.14]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id NAA24209 for <[e-mail]>; Fri, 16 Jul 1999 13:06:54 -0700 (PDT)
From: [e-mail]
Received: from eaglei-internet.ssg.bny.com (bk01.bankofny.com [160.254.115.80]) by mailbox1.appliedtheory.com (8.8.8/8.8.8) with SMTP id QAA14932; Fri, 16 Jul 1999 16:07:45 -0400 (EDT)
Received: from Hermes.bankofny.com by eaglei-internet.ssg.bny.com via smtpd (for mailbox1.appliedtheory.com [204.168.16.14]) with SMTP; 16 Jul 1999 20:07:45 UT
Received: from LNOTES5 by HERMES via SMTP with TCP; Fri, 16 Jul 99 16:06:26-EDT
Received: from LNOTES5 by HERMES via SMTP with TCP; Fri, 16 Jul 99 16:06:34-EDT
Received: by LNOTES5(Lotus SMTP MTA v1.2  (600.1 3-26-1998))  id 852567B0.006E8216 ; Fri, 16 Jul 1999 16:07:02 -0400
X-Lotus-FromDomain: BNY
To: Joe Tardo <[e-mail]>
cc: "'[e-mail]'" <[e-mail]>
Message-ID: <852567B0.006E46F1.00@LNOTES5>
Date: Fri, 16 Jul 1999 16:06:58 -0400
Subject: Re: Digital Signature Laus (was Re: KISS for PKIX)
Mime-Version: 1.0
Content-type: text/plain; charset=us-ascii
Content-Disposition: inline

For summary info:
See the Internet Law & Policy Forum site at
http://www.ilpf.org/digsig/digsig2.htm

for individual states see
http://www.perkinscoie.com/resource/ecomm/digsig/state.htm, which the ILPF
links to.

eric








Joe Tardo <[e-mail]> on 07/16/99 12:20:17 PM

To:   Eric Guerrino, Stephen Kent <[e-mail]>
cc:   "'[e-mail]'" <[e-mail]>
Subject:  Digital Signature Laus (was Re: KISS for PKIX)


Received: from EMAIL ([160.100.151.79]) by LNOTES5 (Lotus SMTP MTA v1.2
(600.1 3-26-1998)) with SMTP id 852567B0.0065A3F4; Fri, 16 Jul 1999
14:30:11 -0400
Received: from eagle.ssg.bny.com by EMAIL via SMTP with TCP; Fri,
       16 Jul 99 14:29:46-EDT
Received: from [208.226.86.1] by eagle.ssg.bny.com via smtpd (for
       email.ssg.bny.com [160.100.151.79]) with SMTP; 16 Jul 1999 18:29:44
UT
Received: (qmail+freegate 2460 invoked by alias); 16 Jul 1999 18:29:39
       -0000
Received: from ws7-n0.hq.freegate.com (HELO tardo3.hq.freegate.com)
       (208.226.86.135) by hq.freegate.com with SMTP; 16 Jul 1999
       18:29:39 -0000
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: Windows Eudora Pro Version 3.0.1 (32)
Date: Fri, 16 Jul 1999 09:20:17 -0700
To: Eric_Guerrino@LNOTES5, Stephen Kent <[e-mail]>
From: Joe Tardo <[e-mail]>
Subject: Digital Signature Laus (was Re: KISS for PKIX)
Cc: "'[e-mail]'" <[e-mail]>
In-Reply-To: <852567B0.0051BDDF.00@LNOTES5>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"




At 01:28 PM 7/16/99 -0400, [e-mail] wrote:

>There are legal issues to be resolved regarding limitations of liability
>and responsibilities of issuers, certificate authorities, subscribers, and
>relying parties. There are legal issues to be resolved regarding digital
>signatures. Last time I checked, about thirty states had enacted or were
in
>the process of enacting digital signature laws. The federal government has
>a digital signature law pending.

Does anyone have the digital signature legislation URLs handy referencing
the latest on what the 30 states and Federal Government are enacting?

Thanks,
Joe






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 LAA22223 for <[e-mail]>; Fri, 16 Jul 1999 11:34:27 -0700 (PDT)
Received: from stingray.missi.ncsc.mil (root@localhost) by stingray.missi.ncsc.mil with ESMTP id OAA08697 for <[e-mail]>; Fri, 16 Jul 1999 14:35:54 -0400 (EDT)
Received: from missi.ncsc.mil (depot.missi.ncsc.mil [144.51.60.1]) by stingray.missi.ncsc.mil with ESMTP id OAA08692 for <[e-mail]>; Fri, 16 Jul 1999 14:35:53 -0400 (EDT)
Received: from ara.missi.ncsc.mil (ara.missi.ncsc.mil [144.51.58.9]) by missi.ncsc.mil (8.8.8/8.8.8) with ESMTP id OAA24063 for <[e-mail]>; Fri, 16 Jul 1999 14:35:52 -0400 (EDT)
Received: from ara.missi.ncsc.mil (ara.missi.ncsc.mil [144.51.58.9]) by ara.missi.ncsc.mil (8.9.1b+Sun/8.9.1) with SMTP id OAA04159 for <[e-mail]>; Fri, 16 Jul 1999 14:35:45 -0400 (EDT)
Message-Id: <[e-mail]>
Date: Fri, 16 Jul 1999 14:35:45 -0400 (EDT)
From: "David P. Kemp" <[e-mail]>
Reply-To: "David P. Kemp" <[e-mail]>
Subject: Re: Common misconceptions, was Re: KISS for PKIX, was ... 
To: [e-mail]
MIME-Version: 1.0
Content-Type: TEXT/plain; charset=us-ascii
Content-MD5: v/+7t0tRHF3vew/gteaE2g==
X-Mailer: dtmail 1.3.0 CDE Version 1.3 SunOS 5.7 sun4u sparc

> From: Ed Gerck <[e-mail]>
>
> The "harder and harder to do" is what makes a certificate not bind to a user 
-- and even
> if you have all proper papers in notarized copies you still do not know.  And, 
BTW, just
> read any CA warranty and you will see they also do not know and they say so -- 
"NO
> WARRANTY, NO SUITABILITY OF PURPOSE".


Novell recently briefed the Federal PKI Technical Working Group
(http://csrc.nist.gov/pki/twg/welcome.html) on the results of their
requirements discussions with business users.  One notable conclusion
is that PKIs will have "made it" when they become insurable (i.e. when
it becomes possible to quantify risk reliably enough to make meaningful
warranties).  Since business relying parties require a guarantor to have
deep enough pockets to make any judgements for breach of warranty
collectable, it follows that the only warranties that will be made by
any organization with substantial assets are against quantifiable,
controllable, insurable risks.  A proposed approach to allocating
liability included a root CA operated by an organization with huge
assets (such as a commercial bank) but with only two warranted
responsibilities: 1) ensuring name uniqueness across the certs issued
by that CA, and 2) protecting the CA's private key.  (A third,
unstated, requirement would be to use sufficiently conservative
cryptography for signatures on the issued certs).


> Surely, you can rely on a certificate but only to the extent that it is 
warranted by the issuer.
> But, you will not find a CA that does that without caveats that any fraudster 
case will fall
> into and thus invalidate the assurances.  And, the CAs are right -- it cannot 
be warranted
> that  a certificate binds to a user. This alone already shows in the practice 
what I tried to
> explain.

You (as a relying party) can rely on a certificate to any extent you
wish.  A CA may warrant that it follows certain practices; it may also
warrant results, as with the hypothetical root CA above, if the amount
of loss and the risk of loss can be quantified.  You, the relying party,
assume all risk not assumed by the CA.  You are the sole judge of whether
the PKI provides a benefit - whether profit from transactions enabled
by the PKI minus expected losses from risks not assumed by the PKI is
positive.

A CA cannot warrant that a certificate binds to a user any more than a
fire insurer can warrant that you won't have a fire.  No casualty
insurer will protect you from, or compensate you for, losses resulting
from thermonuclear war.  But insurance exists because it provides a
service that people and businesses are willing (or mandated) to pay
for.  PKIs are useful if their benefits exceed their costs, regardless
of whether it is possible for a CA to provide an unlimited guarantee
that a transaction signed with a particular public key was initiated by
a particular natural person.



Received: from freegate.com (freegate.com [208.226.86.1]) by mail.proper.com (8.8.8/8.8.5) with SMTP id LAA22039 for <[e-mail]>; Fri, 16 Jul 1999 11:28:12 -0700 (PDT)
Received: (qmail+freegate 2460 invoked by alias); 16 Jul 1999 18:29:39 -0000
Received: from ws7-n0.hq.freegate.com (HELO tardo3.hq.freegate.com) (208.226.86.135) by hq.freegate.com with SMTP; 16 Jul 1999 18:29:39 -0000
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: Windows Eudora Pro Version 3.0.1 (32)
Date: Fri, 16 Jul 1999 09:20:17 -0700
To: [e-mail], Stephen Kent <[e-mail]>
From: Joe Tardo <[e-mail]>
Subject: Digital Signature Laus (was Re: KISS for PKIX)
Cc: "'[e-mail]'" <[e-mail]>
In-Reply-To: <852567B0.0051BDDF.00@LNOTES5>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"

At 01:28 PM 7/16/99 -0400, [e-mail] wrote:

>There are legal issues to be resolved regarding limitations of liability
>and responsibilities of issuers, certificate authorities, subscribers, and
>relying parties. There are legal issues to be resolved regarding digital
>signatures. Last time I checked, about thirty states had enacted or were in
>the process of enacting digital signature laws. The federal government has
>a digital signature law pending.

Does anyone have the digital signature legislation URLs handy referencing
the latest on what the 30 states and Federal Government are enacting?

Thanks,
Joe


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 LAA21791 for <[e-mail]>; Fri, 16 Jul 1999 11:17:02 -0700 (PDT)
Received: from mailgate2.apple.com ([17.129.100.225]) by mail-out1.apple.com (8.8.5/8.8.5) with ESMTP id LAA34384 for <[e-mail]>; Fri, 16 Jul 1999 11:18:28 -0700
Received: from scv4.apple.com (scv4.apple.com) by mailgate2.apple.com (mailgate2.apple.com- SMTPRS 2.0.15) with ESMTP id <[e-mail]> for <[e-mail]>; Fri, 16 Jul 1999 11:17:50 -0700
Received: from [17.219.25.199] ([17.219.25.199]) by scv4.apple.com (8.9.3/8.9.3) with ESMTP id LAA26102 for <[e-mail]>; Fri, 16 Jul 1999 11:17:48 -0700
Message-Id: <[e-mail]>
X-Mailer: Microsoft Outlook Express Macintosh Edition - 4.5 (0410)
Date: Fri, 16 Jul 1999 11:17:33 -0700
Subject: Re: KISS for PKIX. (Was: RE: ASN.1 vs XML (used to be RE: I-D ACTION :draft-ietf-pkix-scvp- 00.txt))
From: "Aram Perez" <[e-mail]>
To: "'[e-mail]'" <[e-mail]>
MIME-Version: 1.0
X-Priority: 3
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: 7bit

Eric Guerrino wrote:

[snip]
> 
> I initially was led to believe PKI supported non-repudiation because this
> was one of the claims being made for it by its proponents. It was only
> after I started examining it more closely that I realized the claims were
> unsubstantiated. As long as one party can reasonably deny a fact, it is up
> to the other party to prove otherwise. If I receive a transaction and act
> on it, and the initiator subsequently denies the transaction, what do I
> have to authenticate the user and the data? I can't claim in court that I
> received and acted on a message because my server accepted it since it came
> with a valid certificate,  and because the signature and the message digest
> were valid, based on the certificate. I need to to be able to produce the
> original message, the digest, the signature, and the certificate, and be
> able to show that the validity checks all passed. I also need to know what
> algoritms were used. I need logs and audit records to prove the transaction
> came in. And I need all this possibly months or years later. But, most of
> all, I need to be able to demonstrate that I based my decision on
> reasonable assurance that the originator was who they claimed to be.

I'm glad you've come to this conclusion. I've stated numerous times that
digital signatures DO NOT provide non-repudiation. When you verify a digital
signature, all you can assert is that the data was not tampered with, and
that the private key (that corresponds to the public key in the certificate)
was used to generate the digital signature. Having said that, I do believe
that what digital signatures do provide is "strong evidence for the rebuttal
of a repudiation."

>
> Which brings me to userids and passwords, and why I must use an application
> password even if I have issued a certificate.  Passwords provide reasonable
> assurance to me that the originator is who they say they are; as long as
> the password is kept securely.

But this is the same assumption you make about a private key, that it is
kept securely.

> Dynamic passwords (two-factor
> authentication) provide even stronger assurance that this is so. What do I,
> as a verifier, have when a certificate is used? I have no reasonable
> assurance about the originator because I have not done anything to
> authenticate them.

It all depends on the protocol. A good PKI-based protocol would use a
challenge-response mechanism.

> I don't know how secure the originator's PC is.

You have this problem with passwords also.

> I don't
> know if they have told the browser to cache the private key password, nor
> the strength of it. I don't know if their PC will lock itself after a
> certain amount of inactivity. I don't know who has access to the PC. It is
> not difficult to copy certificate files from one system to another.

Copying certificates is not an issue. By definition, a certificate is
"public".

> If the
> password is not strong enough, it probably would not be too difficult to
> crack it.

There are numerous accounts of how to break MS passwords and key storage.

> The certificate would be more reliable, for user authentication
> purposes, if I, as an issuer, could control usage of the private key

But how can an issuer (I'm assuming you mean a certificate issuer) control
the use of the private key?

> and
> user authentication, or, minimally, if It is stored on some external
> device.

Hence the attractiveness of tokens like smart cards.

> At least this provides two-factor authentication. I can't control
> how software vendors utilize certificates in their browser products, but I
> am at their mercy if I allow my application to run from their browser. If
> risk assessment requires me to use password security anyway, I need to be
> able to show significant incremental value added by certificates, given
> that the certifcate process places a large administrative burden around all
> this.

The "significant incremental value" is the elimination of users having a
different password (a good security practice) for every system that have
access to.

>
> Granted, all this is less confusing if an originator is executing a
> transaction with the issuer of the cetificate, because the issuer could
> control the user authentication process. But it becomes more complex when
> the certificate is used to execute a transaction with a third party. How
> can a bank verify a certificate and, more importantly, vouch for a
> transaction, if it can't be reasonably assured the customer is who they
> claim to be? All it has is a request for validation from the third party
> (merchant) and a message.

If the bank does not trust the root CA (and its certificate), it will not
vouch for the transaction. This is one of the reasons the root certificates
have to be verified by an out-of-band mechanism. You are a great risk if you
accept a new root certificate blindly.

[snip]

Regards,
Aram Perez


Received: from xylan.com (postal.xylan.com [208.8.0.248]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id LAA21594 for <[e-mail]>; Fri, 16 Jul 1999 11:11:43 -0700 (PDT)
Received: from mailhub.xylan.com by xylan.com (8.8.7/SMI-SVR4 (xylan-mgw 2.2 [OUT])) id LAA19716; Fri, 16 Jul 1999 11:12:26 -0700 (PDT)
Received: from newman.xylan.com by mailhub.xylan.com (SMI-8.6/SMI-SVR4 (mailhub 2.1 [HUB])) id LAA00691; Fri, 16 Jul 1999 11:12:26 -0700
Received: from xylan.com ([127.0.0.1]) by newman.xylan.com (Netscape Messaging Server 3.5)  with ESMTP id AAA29FB; Fri, 16 Jul 1999 11:14:13 -0700
Message-ID: <[e-mail]>
Date: Fri, 16 Jul 1999 11:09:02 -0700
From: "Jeff Hayes" <[e-mail]>
Organization: Xylan Corp
X-Mailer: Mozilla 4.04 [en] (Win95; U)
MIME-Version: 1.0
To: [e-mail]
CC: Stephen Kent <[e-mail]>, [e-mail], "'[e-mail]'" <[e-mail]>
Subject: Re: KISS for PKIX. (Was: RE: ASN.1 vs XML (used to be RE: I-D 		 ACTION :draft-ietf-pkix-scvp- 00.txt))
References: <[e-mail]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

RADIUS is an important and worthy authentication server. Switch vendors are now or
will soon use RADIUS for port based network access. There is an approved PAR within
the IEEE 802.1 group (802.1x) that will give the adminrator the option of requiring
user authentication prior to opening up the switch port. Although the spec will
most like not specify an authentication server(s), RADIUS is one authentication
means that can be used to verify identity (and leverage its vendor specific
attribute #26).

--
[e-mail]          Phone: [phone]
Product Manager - Security, QoS, & L2/3/4 Switching
https://cosmo.xylan.com/x/users/jhayes/index.html




Received: from mailbox1.appliedtheory.com (mailbox1.appliedtheory.com [204.168.16.14]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id KAA20762 for <[e-mail]>; Fri, 16 Jul 1999 10:35:19 -0700 (PDT)
From: [e-mail]
Received: from eaglei-internet.ssg.bny.com (bk01.bankofny.com [160.254.115.80]) by mailbox1.appliedtheory.com (8.8.8/8.8.8) with SMTP id NAA02733; Fri, 16 Jul 1999 13:33:34 -0400 (EDT)
Received: from Hermes.bankofny.com by eaglei-internet.ssg.bny.com via smtpd (for mailbox1.appliedtheory.com [204.168.16.14]) with SMTP; 16 Jul 1999 17:33:34 UT
Received: from LNOTES5 by HERMES via SMTP with TCP; Fri, 16 Jul 99 13:28:02-EDT
Received: from LNOTES5 by HERMES via SMTP with TCP; Fri, 16 Jul 99 13:28:03-EDT
Received: by LNOTES5(Lotus SMTP MTA v1.2  (600.1 3-26-1998))  id 852567B0.005FFFCD ; Fri, 16 Jul 1999 13:28:34 -0400
X-Lotus-FromDomain: BNY
To: Stephen Kent <[e-mail]>
cc: "'[e-mail]'" <[e-mail]>
Message-ID: <852567B0.0051BDDF.00@LNOTES5>
Date: Fri, 16 Jul 1999 13:28:28 -0400
Subject: Re: KISS for PKIX. (Was: RE: ASN.1 vs XML (used to be RE: I-D ACTION :draft-ietf-pkix-scvp- 00.txt))
Mime-Version: 1.0
Content-type: text/plain; charset=us-ascii
Content-Disposition: inline

There are legal issues to be resolved regarding limitations of liability
and responsibilities of issuers, certificate authorities, subscribers, and
relying parties. There are legal issues to be resolved regarding digital
signatures. Last time I checked, about thirty states had enacted or were in
the process of enacting digital signature laws. The federal government has
a digital signature law pending. I was not basing my comment solely on
legal issues regarding authentication of users. What is the limitation of
liability of an issuer when a third party effects a transaction based on a
certificate the issuer has issued, after the subscriber repudiates the
transaction? What if all three parties are in three different states or,
worse, countries? Whose law applies? What happens when a CA closes shop?
Are the certificates valid or invalid? Who will relying parties consult if
they need to verify that a certificate issued by the defunct CA was valid
at a previous point in time for a disputed transaction? For how many years
must a CA keep expired certificates? What responsibility does a CA have for
providing for cessation of activities?

I initially was led to believe PKI supported non-repudiation because this
was one of the claims being made for it by its proponents. It was only
after I started examining it more closely that I realized the claims were
unsubstantiated. As long as one party can reasonably deny a fact, it is up
to the other party to prove otherwise. If I receive a transaction and act
on it, and the initiator subsequently denies the transaction, what do I
have to authenticate the user and the data? I can't claim in court that I
received and acted on a message because my server accepted it since it came
with a valid certificate,  and because the signature and the message digest
were valid, based on the certificate. I need to to be able to produce the
original message, the digest, the signature, and the certificate, and be
able to show that the validity checks all passed. I also need to know what
algoritms were used. I need logs and audit records to prove the transaction
came in. And I need all this possibly months or years later. But, most of
all, I need to be able to demonstrate that I based my decision on
reasonable assurance that the originator was who they claimed to be.

Which brings me to userids and passwords, and why I must use an application
password even if I have issued a certificate.  Passwords provide reasonable
assurance to me that the originator is who they say they are; as long as
the password is kept securely. Dynamic passwords (two-factor
authentication) provide even stronger assurance that this is so. What do I,
as a verifier, have when a certificate is used? I have no reasonable
assurance about the originator because I have not done anything to
authenticate them. I don't know how secure the originator's PC is. I don't
know if they have told the browser to cache the private key password, nor
the strength of it. I don't know if their PC will lock itself after a
certain amount of inactivity. I don't know who has access to the PC. It is
not difficult to copy certificate files from one system to another. If the
password is not strong enough, it probably would not be too difficult to
crack it. The certificate would be more reliable, for user authentication
purposes, if I, as an issuer, could control usage of the private key and
user authentication, or, minimally, if It is stored on some external
device. At least this provides two-factor authentication. I can't control
how software vendors utilize certificates in their browser products, but I
am at their mercy if I allow my application to run from their browser. If
risk assessment requires me to use password security anyway, I need to be
able to show significant incremental value added by certificates, given
that the certifcate process places a large administrative burden around all
this.

Granted, all this is less confusing if an originator is executing a
transaction with the issuer of the cetificate, because the issuer could
control the user authentication process. But it becomes more complex when
the certificate is used to execute a transaction with a third party. How
can a bank verify a certificate and, more importantly, vouch for a
transaction, if it can't be reasonably assured the customer is who they
claim to be? All it has is a request for validation from the third party
(merchant) and a message.

I am sure this will all be resolved over time, but at this point, I don't
feel we are close enough.
eric





Stephen Kent <[e-mail]> on 07/16/99 03:04:48 AM

To:   Eric Guerrino
cc:   "'[e-mail]'" <[e-mail]>
Subject:  Re: KISS for PKIX. (Was: RE: ASN.1 vs XML (used to be RE: I-D
       ACTION :draft-ietf-pkix-scvp- 00.txt))




Date: Fri, 16 Jul 1999 03:04:48 -0400
To: Eric_Guerrino@LNOTES5
From: Stephen Kent <[e-mail]>
Subject: Re: KISS for PKIX. (Was: RE: ASN.1 vs XML (used to be RE: I-D
      ACTION :draft-ietf-pkix-scvp- 00.txt))
Cc: "'[e-mail]'" <[e-mail]>



Eric,

>I couldn't agree with you more. However, regarding acceptance of PKI
>technologies by large organizations, I believe there are many reasons
>organizations are not adopting PKI readily besides ease-of-use issues. Nor
>does it have anything to do with ASN.1 vs XML. This issue can't be
resolved
>with technology solutions because their lack of acceptance is not due
>solely to technical problems.
>
>The problems with PKI are numerous, from a corporate perspective, and many
>large organizations have not moved initial PKI efforts beyond the
>pilot/evaluation stage. Problems include outstanding legal liability
>issues, the lack of fraud protection laws, the need to address cessation
of
>activites of a CA and/or a registry, the inability to bind a certificate
>distinctly to a user (software certificates identify systems, not users),
>the inability of an issuer to associate a security policy with the
>certificate (issuers need to be able to dictate when to allow caching of
>passwords,as well as things like session timeout and password construction
>rules), undefined procedures and products to support records management
and
>archiving, as well as that non-repudiation claims for current PKI products
>may have no legal basis. Then there are all the technical problems.

I agree that these are precieved problems that hinder PKI deployment, but I
also think that many of these are red herrings.  If I use certificates to
authenticate users, in lieu of passwords, why are there any new legal
issues?  Part of the problem is that people have been led to believe that a
PKI must support non-repudiation, which generates a large number of valid,
legal concerns.  However, use of a PKI to support SSL, IPsec, and S/MIME
(at least on an intranet basis) does not raise such issues, yet promises to
improve security and to make life easier for users.

I disagree with your statement that a certificate in software binds a
system, vs. a user.  Yes, smart cards are preferable, but if the choice is
between a password and a certificate (and private key) with software
cryptography, I see no reason not to adopt the latter, and I certainly see
no reason to declare that the latter is not a user (vs. system)
authentication mechanism.  Finally, why do you say that an issuer cann
associate a security policy with a certificate?  We have the syntactic
means to do so as part of the standard.  Do you mean that we don't have
appplications that pay attention to the policy extension?

Steve






Received: from mail-ewr-3.pilot.net (mail-ewr-3.pilot.net [206.98.230.17]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id KAA20549 for <[e-mail]>; Fri, 16 Jul 1999 10:32:20 -0700 (PDT)
From: [e-mail]
Received: from mailgw.firstdata.com ([204.48.27.166]) by mail-ewr-3.pilot.net (Pilot/8.8.8) with ESMTP id NAA00569; Fri, 16 Jul 1999 13:33:47 -0400 (EDT)
Received: from lnsunr02.firstdata.com (lnsunr02.firstdata.com [192.168.247.16]) by mailgw.firstdata.com with SMTP id NAA06632; Fri, 16 Jul 1999 13:33:44 -0400 (EDT)
Received: by lnsunr02.firstdata.com(Lotus SMTP MTA v4.6.4  (830.2 3-23-1999))  id 852567B0.005FFA8D ; Fri, 16 Jul 1999 13:28:20 -0400
X-Lotus-FromDomain: FDC
To: [e-mail]
cc: Stephen Kent <[e-mail]>, [e-mail], "'[e-mail]'" <[e-mail]>
Message-ID: <[e-mail]>
Date: Fri, 16 Jul 1999 10:31:33 -0700
Subject: Re: KISS for PKIX. (Was: RE: ASN.1 vs XML (used to be RE: I-D 		 ACTION :draft-ietf-pkix-scvp- 00.txt))
Mime-Version: 1.0
Content-type: text/plain; charset=us-ascii
Content-Disposition: inline

another interesting scenerio for RADIUS is that most webservers ship with stubs
for authentication and then sites frequently do roll-your-own userid/password
lookup processes. ... a straight-forward scenerio is to provide a RADIUS
protocol stub for web-servers ... then on an account-by-account basis the ISP
(&/or web operator) can use the same administrative interface for managing
account/userid authentication (for both internet/intranet/extranet
authentication and client-side web authentication).

futhermore ... on an account-by-account basis ... the site/operator then can
choose from a menu of RADIUS supported authentication mechanism at the
account/userid level (and in the straight-forward case, public key registration
is done in the same business process as password registration ... and digital
signature authentication becames a straight-forward alternative/option to
password authentication)




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 KAA20192 for <[e-mail]>; Fri, 16 Jul 1999 10:12:49 -0700 (PDT)
Received: from nma.com (pm03-30.sac.verio.net [209.162.64.96]) by tomcat.sac.verio.net (8.9.1a/8.9.1) with ESMTP id KAA20316 for <[e-mail]>; Fri, 16 Jul 1999 10:14:15 -0700 (PDT)
Message-ID: <[e-mail]>
Date: Fri, 16 Jul 1999 10:14:09 -0700
From: Ed Gerck <[e-mail]>
X-Mailer: Mozilla 4.51 [en] (Win98; I)
X-Accept-Language: en
MIME-Version: 1.0
CC: [e-mail]
Subject: Re: Common misconceptions, was Re: KISS for PKIX. (Was: RE: ASN.1 vs XML  (used to be RE: I-D 	ACTION :draft-ietf-pkix-scvp- 00.txt))
References: <[e-mail]> <[e-mail]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

David Slattery wrote:

> > Stephen Kent wrote:
> > >  However, use of a PKI to support SSL, IPsec, and S/MIME
> > > (at least on an intranet basis) does not raise such issues, yet promises to
> > > improve security and to make life easier for users.
>
> Ed Gerck wrote:
> > "improve security" and "make life easy for users" seem to be antinomies in all
> > systems -- security is counter to functionality, as a general principle. So, I believe
> > that last phrase is an empty promise though it may look good in marketing materials.
> > Another common misconception.
>
> If PKIX  and certs do not "improve security" and "make life easy for users" what is the point
> of this WG and why would anyone want to use it ????

Any amount of security will always make life harder for users. Ignoring this instead of
recognizing it and then try to cope with it is one of the unseen problems of today. Why do
you think only 5% of the emails (on average) are encrypted? Because security is a hassle
and users will rather default to insecure methods than miss a deal. So, promising both
is empty because they will never be delivered -- and, trying to make security "automatic"
will just be another example of SKIP; perhaps useful in a closely watched network where
you control all nodes. But, on the Internet, no one controls both ends of a connection,
much less all nodes your packets may go through.

So, what I am saying is that it is better to face the problem, straight. Security and "easier
life for users" are simply opposites. Thus, let's design methods with this in mind -- users
do not have the training to be trusted to follow the "secure" procedure instead of
just choosing a simpler procedure.

The purpose of this WG is then to make security tolerable to users in regard to what it
delievers.

> I believe security is a form of understanding. Thus confinement can be a tool of security but
> it is not the goal.

Yes, this phrase is mine. I am glad you read the email or the paper -- but, next time, pls
cite the (c) and source ;-)

One point of the phrase is that confining users to procedures does not necessarily increase
their security level -- also because the fraudsters are usually unconfined ;-)  and because
users will then be lead to trust "the system" instead of  trusting their use of the system.

Cheers,

Ed Gerck





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 JAA19539 for <[e-mail]>; Fri, 16 Jul 1999 09:31:32 -0700 (PDT)
Received: from nma.com (pm03-30.sac.verio.net [209.162.64.96]) by tomcat.sac.verio.net (8.9.1a/8.9.1) with ESMTP id JAA09931 for <[e-mail]>; Fri, 16 Jul 1999 09:32:58 -0700 (PDT)
Message-ID: <[e-mail]>
Date: Fri, 16 Jul 1999 09:32:52 -0700
From: Ed Gerck <[e-mail]>
X-Mailer: Mozilla 4.51 [en] (Win98; I)
X-Accept-Language: en
MIME-Version: 1.0
CC: "'[e-mail]'" <[e-mail]>
Subject: Re: Common misconceptions, was Re: KISS for PKIX. (Was: RE: ASN.1 vs XML  (used to beRE: I-D 	ACTION :draft-ietf-pkix-scvp-00.txt))
References: <01BECF90.38193950@HYDRA>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Anders Rundgren wrote:

> >Stephen Kent wrote:
> >> I disagree with your statement that a certificate in software binds a
> >> system, vs. a user.

> Ed Gerck wrote:
> >I fail to see how you can possibly disagree with Eric's statement.  Trust is not
> >distributive in the social sense ....
>
> > ... a common misconception that leads one to believe
> >that Bob's certificate binds to Bob irrespective of Bob's trust on Khadaffi -- in fact, Bob
> >may not even exist.
>
> Strange misconception between trust in certificates and bindings versus trust between people.
> The latter is not suitable for IETF to handle!  It is basically a manual, indescribable, out-of-band process :-)

If I understand what you are saying, you are saying that a certificate binds to a user
because it says so. This is not correct.

> Note: I deliberately excluded national ID-CAs who HAVE to verify absolute identity (which is
> harder and hander to do with all paper-less refugees in Europe).

The "harder and harder to do" is what makes a certificate not bind to a user -- and even
if you have all proper papers in notarized copies you still do not know.  And, BTW, just
read any CA warranty and you will see they also do not know and they say so -- "NO
WARRANTY, NO SUITABILITY OF PURPOSE".

Surely, you can rely on a certificate but only to the extent that it is warranted by the issuer.
But, you will not find a CA that does that without caveats that any fraudster case will fall
into and thus invalidate the assurances.  And, the CAs are right -- it cannot be warranted
that  a certificate binds to a user. This alone already shows in the practice what I tried to
explain.

Cheers,

Ed Gerck



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 IAA18999 for <[e-mail]>; Fri, 16 Jul 1999 08:58:48 -0700 (PDT)
From: [e-mail]
Received: from mailgw.firstdata.com ([204.48.27.166]) by mail01-ewr.pilot.net with ESMTP id MAA26884; Fri, 16 Jul 1999 12:00:04 -0400 (EDT)
Received: from lnsunr02.firstdata.com (lnsunr02.firstdata.com [192.168.247.16]) by mailgw.firstdata.com with SMTP id MAA00830; Fri, 16 Jul 1999 12:00:02 -0400 (EDT)
Received: by lnsunr02.firstdata.com(Lotus SMTP MTA v4.6.4  (830.2 3-23-1999))  id 852567B0.0057651A ; Fri, 16 Jul 1999 11:54:35 -0400
X-Lotus-FromDomain: FDC
To: Anders Rundgren <[e-mail]>
cc: Stephen Kent <[e-mail]>, "'Ed Gerck'" <[e-mail]>, "'[e-mail]'" <[e-mail]>, "[e-mail]" <[e-mail]>
Message-ID: <[e-mail]>
Date: Fri, 16 Jul 1999 08:30:59 -0700
Subject: RE: Common misconceptions, was Re: KISS for PKIX. (Was: RE: ASN.1 vs XML (used to be RE: I-D 	ACTION :draft-ietf-pkix-scvp- 00.txt))
Mime-Version: 1.0
Content-type: text/plain; charset=us-ascii
Content-Disposition: inline

from another standpoint (in part because of not having to worry about all the
extraneous issues raised with certificates) ... some of the certificate-less PKI
work is looking at the risk issues ... especially within the context of the
financial industry (financial operations are hot on calculating risk ... so they
can correctly price/predict business ... in large part finance is a risk
management business).

In the finance arena ... significant business processes exist that deal with
establishing the initial business (i.e. certification by any other name) as well
as validating transactions. On a transaction by transaction basis ... technology
is needed that improves the integrity of the transaction ... i.e. digital
signature in lieu of passwords/pins/names.

Assuming a digital signature authentication process ... it then is beneifical to
accurately calculate the risk & assurance level associated with that digital
signature .... i.e. is there an evidentiary, audit trail showing a hardware
token, the assurance level of the hardware token, whether the hardware token has
an activation process, whether any such activation process is PIN or biometric.

One of the interesting issues ... somewhat in line with the problems associated
with using identify certificates flowing over open networks on every transaction
... is flowing biometric information over open networks. Having a biometric
activated hardware token that the person "owns" ... means that the biometric
exchange is only between the person and their token (side-stepping the privacy
invasion and privacy mandates).

One could make the case, that in account-based business processes ... the
inhibitor to certificate-based PKIs is that they create redundant and
superfulous business processes and don't eliminate any processes (i.e.
increasing cost while not showing any corresponding benefit). Certificate-less
PKIs tend to leverage existing account-based business processes ... i.e. optimal
improvement of integrity at optimal increase in cost.

In the financial industry ... an area of opportunity for PKI registration and
audit trail (i.e. not duplicating existing business processes) is providing an
evidentary trail regarding the assurance level of the components used in a
transactions.

An example is providing at sign-up time additional information about the
integrity and characteristic of the hardware token (password/public-key and
person sign-up is already existing business process) with respect to integrity
of the crypto, integrity of the chip involved, what kind of token activation is
employed, etc. This is a new process, that doesn't duplicate existing processes
and is useful information for risk managers .... and provides the basis for
creating parameterized risk management.  The usefulness of this can then be
shown to have three benefits:

1) allows the risk manager to calculate the risk associated with specific
transaction

2) allows institutions to support a variety of price/performance authentication
methodologies appropriate to the risk involved in a wide range of different
valued transactions ... all with a single infrastructure

3) allows institutions to dynamically modify over time the types of
authentication methodologies in use without having to obsolete the
infrastructure

parameterized risk management of components involved in authentication
technology can be demonstrated business case for new business processes that
aren't covered/duplicated today.

As a working hypothesis ... business cases for new duplicate, superfulous
sign-up procedures are hard to make ... especially in account-based environments
... when they don't show a corresponding elimination/reduction in other sign-up
processes.








Anders Rundgren <[e-mail]> on 07/16/99 04:36:31 AM

To:   Stephen Kent <[e-mail]>, "'Ed Gerck'" <[e-mail]>,
      "'[e-mail]'" <[e-mail]>
cc:   "[e-mail]" <[e-mail]>
Subject:  RE: Common misconceptions, was Re: KISS for PKIX. (Was: RE: ASN.1 vs
      XML (used to be RE: I-D      ACTION :draft-ietf-pkix-scvp- 00.txt))




Ed,
<big snip>
>> I disagree with your statement that a certificate in software binds a
>> system, vs. a user.

>I fail to see how you can possibly disagree with Eric's statement.  Trust is
not
>distributive in the social sense (ie, not associative in the mathematical
sense),
>which alone opens the problem that (here, * is the trust operator):

 >(A*B)*K <> A*(B*K)

>and thus, for example, Alice may trust that Bob's certificate binds to Bob (ie,
A*B)
>before Alice knows that Bob trusts Khadaffi (ie, B*K), but not afterwards (ie,
A*(B*K)).
>Or, as another example, I may trust my lawyer before I know  that he trusts my
competitor
>but not afterwards. Or, Bill may trust Monica before Bill knows that Monica
trusts
>Linda, but not afterwards. In summary, this is the "unfaithful proxy " problem
as I call it
>-- you can never tell is there is an unfaithful proxy. However, to think
otherwise and to
>believe that (A*B)*K = A*(B*K) is a common misconception that leads one to
believe
>that Bob's certificate binds to Bob irrespective of Bob's trust on Khadaffi --
in fact, Bob
>may not even exist.

Strange misconception between trust in certificates and bindings versus trust
between people.
The latter is not suitable for IETF to handle!  It is basically a manual,
indescribable, out-of-band process :-)

That is why you in an large PKI-scenario (inside an organization legal issues
and non-repudian is
not that terribly interesting really), DESPERATELY NEED TTPs for issuing
identity-certificates.  Even
crooks (Khadaffi?) can get one!  It is not particularly hard for a CA to verify
that a person exists
(just by watching him/her) although an individual's "absolute identity"
(whatever that mean) may
not always be correct.  The latter is IMO not a stumbling factor for PKI
(particularly if biometrics
can be recorded and later verified) as you are unlikely to enter any serious
relationship (Employment,
Bank-account owner) without showing-up physically at least once.

The important thing that a TTP/CA must guarantee is that you must not be able to
"borrow" another
individual's identity.  A set of credentials and biometrics does the trick. To
certificate-wise get a NEW
identity is another thing which does not eliminate the value of PKI/TTPs/CAs as
the subject is back
to square one for all his/her certificate-based relationships.  I.e. they are
all gone.

No signs of rocket-science IMHO.  KISS?  Naah, maybe not.

Note: I deliberately excluded national ID-CAs who HAVE to verify absolute
identity (which is
harder and hander to do with all paper-less refugees in Europe).

Anders








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 IAA18403 for <[e-mail]>; Fri, 16 Jul 1999 08:03:47 -0700 (PDT)
Received: from stingray.missi.ncsc.mil (root@localhost) by stingray.missi.ncsc.mil with ESMTP id LAA26713 for <[e-mail]>; Fri, 16 Jul 1999 11:05:14 -0400 (EDT)
Received: from missi.ncsc.mil (depot.missi.ncsc.mil [144.51.60.1]) by stingray.missi.ncsc.mil with ESMTP id LAA26704 for <[e-mail]>; Fri, 16 Jul 1999 11:05:12 -0400 (EDT)
Received: from ara.missi.ncsc.mil (ara.missi.ncsc.mil [144.51.58.9]) by missi.ncsc.mil (8.8.8/8.8.8) with ESMTP id LAA21778 for <[e-mail]>; Fri, 16 Jul 1999 11:05:11 -0400 (EDT)
Received: from ara.missi.ncsc.mil (ara.missi.ncsc.mil [144.51.58.9]) by ara.missi.ncsc.mil (8.9.1b+Sun/8.9.1) with SMTP id LAA03854 for <[e-mail]>; Fri, 16 Jul 1999 11:05:04 -0400 (EDT)
Message-Id: <[e-mail]>
Date: Fri, 16 Jul 1999 11:05:04 -0400 (EDT)
From: "David P. Kemp" <[e-mail]>
Reply-To: "David P. Kemp" <[e-mail]>
Subject: RE: KISS for PKIX
To: [e-mail]
MIME-Version: 1.0
Content-Type: TEXT/plain; charset=us-ascii
Content-MD5: zjAYCTE6i1PVbzlUFGfYiw==
X-Mailer: dtmail 1.3.0 CDE Version 1.3 SunOS 5.7 sun4u sparc

> From: "Flanigan, Bill" <[e-mail]>
>
> > I agree that these are precieved problems that hinder PKI deployment, but I
> > also think that many of these are red herrings.  If I use certificates to
> > authenticate users, in lieu of passwords, why are there any new legal
> > issues?  Part of the problem is that people have been led to believe that a
> > PKI must support non-repudiation, which generates a large number of valid,
> > legal concerns. 
> > 
> BF:  Yes, Steve, and these legal issues go way beyond those related to a
> password (in part because now there are a whole bunch of additional entities
> involved).  They include the end entity (human and
> human-responsible-for-machine), the registration agents (RA, LRA,
> out-of-band delivery person/service), the CA (both the cert-server side and
> the directory/repository side), the PKI administrators, etc.  Then there are
> validity issues, CRL issues, repository time-and-security issues (e.g., how
> long must a cert or CRL remain in secure storage?  50 years?  150 years?)
> Aside from the CP and CPS, there are also Privacy Act issues.  Then there is
> key escrow and recovery (yes, they are completely different and involve
> different processes and entities).  I sometimes wonder if there are enough
> lawyers on the planet to support all these up-and-coming PKI!
>
>    <snip>
>
> BF:  Steve, very few humans will read (or be able to understand if they
> read) the CP.  The number of extensions in PKIX for machine-readable policy
> is miniscule compared to what is needed--I would hazard a guess of 30-50 for
> the "typical" CP (and, of course, we still have the CPS which may or may not
> have policy-related items not explicit in the CP plus CA cross certification
> where policy mapping is a MUST).
> 
> BF:  P.S.  Being an early adopter of a PKI striving to be based on PKIX (and
> commercial products) that goes beyond the pilot level is not fun.  It almost
> seems like the standards were designed to make sure that early adopters
> don't progress beyond the pilot stage!  The same could be said of commercial
> products.  You must have very deep pockets to progress a PKI from
> supporting, say, 100K certs to 5,000K certs.  And I am rapidly coming to the
> conclusion (a conclusion I don't at all like) that if PKIX is to the PKI
> flavor of choice for the planet, it must be substantially overhauled (or
> replaced).


Bill,

I must say I'm totally confused by this conclusion.  Of all the issues
you list (the number of PKI entities, validity, archiving, Privacy Act,
KR, CP and CPS), what single issue would be affected by a modification
to the certificate structures defined by PKIX/X.509?

How would a change in the X.509 certificate format affect the number of
CAs, RAs, etc required to run a non-pilot PKI?  How would it affect
archive requirements?  How would a change in the syntax of the X.509
CertificatePolicies extension affect (for the better) the legal/policy
requirements of operating a large-scale PKI?  In short, what single
modification to X.509, or what substantial overhaul or complete
replacement, would make any of these issues the slightest bit easier to
manage or resolve?

In other words, if PKIX needs replacement, what are the business
requirements for whatever you would replace it with, and how would
your new certificate structure satisfy those requirements to any
greater extent than do PKIX certs?


> BF:  Yes, Steve, and these legal issues go way beyond those related to a
> password (in part because now there are a whole bunch of additional entities
> involved).

You are postulating a large-scale general-purpose PKI, and then arguing
that the legal issues related to operating a PKI are caused by a set of
data structures defined in X.509/PKIX.  That does not address Steve's
point that if you are *not* using PKIX to implement a PKI (with support
for NR, archiving, etc), then these issues do not arise.

What if AOL issued X.509 certificates to all of its subscribers, and used
those certificates solely as a replacement for passwords: the identity
proofing is no more and no less than that required to get an AOL password
today; no third-party issuers; no PKIX-specific policy statements other
than statements which currently exist (acceptable-use, data privacy, etc).
Please explain why these PKIX AOL login certs become any more unmanageable
if the number of AOL subscribers grows from 100K to 5,000K?




Received: from svhw0001.statestreet.com (svhw0001.statestreet.com [205.181.240.21]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id HAA17836 for <[e-mail]>; Fri, 16 Jul 1999 07:32:09 -0700 (PDT)
Received: from statestreet.com (itdw2018.itd.ssb.com [155.108.150.43]) by svhw0001.statestreet.com (8.9.1/8.9.1) with ESMTP id KAA08747; Fri, 16 Jul 1999 10:29:42 -0400 (EDT)
Message-ID: <[e-mail]>
Date: Fri, 16 Jul 1999 10:28:39 -0400
From: David Slattery <[e-mail]>
Organization: State Street Bank and Trust
X-Mailer: Mozilla 4.5 [en] (WinNT; U)
X-Accept-Language: en
MIME-Version: 1.0
To: [e-mail]
CC: [e-mail], [e-mail], [e-mail]
Subject: Re: Common misconceptions, was Re: KISS for PKIX. (Was: RE: ASN.1 vs XML  (used to be RE: I-D 	ACTION :draft-ietf-pkix-scvp- 00.txt))
References: <[e-mail]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

>
> >  However, use of a PKI to support SSL, IPsec, and S/MIME
> > (at least on an intranet basis) does not raise such issues, yet promises to
> > improve security and to make life easier for users.
>
> "improve security" and "make life easy for users" seem to be antinomies in all
> systems -- security is counter to functionality, as a general principle. So, I believe
> that last phrase is an empty promise though it may look good in marketing materials.
> Another common misconception.

If PKIX  and certs do not "improve security" and "make life easy for users" what is the point
of this WG and why would anyone want to use it ????
I believe you are dead wrong when you call them antinomies. I believe that line of thinking is
why
we have such a lack of security in the industry. Security and users go hand in hand. Security
and
functionality have to be meshed for the survival of each. If security does not allow for
functionality,
no one will use security. If functionality does not allow security then that functionality can
be denied or
destroyed resulting in partial or no functionality of the system.
I believe security is a form of understanding. Thus confinement can be a tool of security but
it is not the goal.

just some idealistic thoughts
-Dave


  *************************************************************************
  This e-mail expresses my personal views and not those of State State.
  STATE STREET BANK                             Information Technology
  Telephone: [phone]                     Client Server Technology
  *************************************************************************




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 HAA17709 for <[e-mail]>; Fri, 16 Jul 1999 07:29:18 -0700 (PDT)
From: [e-mail]
Received: from mailgw.firstdata.com ([204.48.27.166]) by mail01-ewr.pilot.net with ESMTP id KAA21087; Fri, 16 Jul 1999 10:30:45 -0400 (EDT)
Received: from lnsunr02.firstdata.com (lnsunr02.firstdata.com [192.168.247.16]) by mailgw.firstdata.com with SMTP id KAA23572; Fri, 16 Jul 1999 10:30:43 -0400 (EDT)
Received: by lnsunr02.firstdata.com(Lotus SMTP MTA v4.6.4  (830.2 3-23-1999))  id 852567B0.004F3743 ; Fri, 16 Jul 1999 10:25:14 -0400
X-Lotus-FromDomain: FDC
To: Stephen Kent <[e-mail]>
cc: [e-mail], "'[e-mail]'" <[e-mail]>
Message-ID: <[e-mail]>
Date: Fri, 16 Jul 1999 07:28:07 -0700
Subject: Re: KISS for PKIX. (Was: RE: ASN.1 vs XML (used to be RE: I-D 	 ACTION :draft-ietf-pkix-scvp- 00.txt))
Mime-Version: 1.0
Content-type: text/plain; charset=us-ascii
Content-Disposition: inline

there would also appear to be a semantic problem here .... public key can be
used in lieu of passwords to authenticate.

digital signatures have a lot of advantages over passwords .... like the method
of authenticating the digital signature (the public key) is not prone to
password compromise (eliminating the problems with having a single password
across multiple organizations and/or having to write down the passwords if
unique passwords are alwas selected).

certficates are one method to authenticate the public key ... but there are also
certificate-less PKIs that use other methods of providing the public key.

the dominate authentication application across the whole internet sphere is
RADIUS (ISPs, corporate networks, intranets, extranets, etc). A simple upgrade
method has been demonstrated for radius that registers the public key in place
of the current business processes that register a password (selectively on an
account by account basis) ... and then digital signature authentication is used
in lieu of password authentication.

One of the simplest issues is that a standard X.509 "identity" can represent
privacy invasion and/or violation of privacy mandates if full name/details are
available ... or if relying-party-only certificate is used .... it it is trivial
to show that if the authenticated transaction has to hit an accound-record (like
logging on to an ISP and the ISP wants to know if your account is still active
... and hasn't been voided because of something like spam'ing) then having the
certificate is superfulous and redundant since the public key can be extracted
from the account. it also eliminates any question of legal issues that having
been shroading certificates in the area of trust-propogation

The interesting thing is that certificate-less PKIs tend to preserve exactly
existing authentication business processes .... while at the same time being
able to utilize off-the-self digital signing protocols/technology (just
forgetting to append the certificate when sending off the transaction, or if you
will, using knowledge-base compression to compress the size of the certificate
to zero bytes).

In that sense, certificate-less PKIs are one of the most aggressive applications
of KISS (elimination of redundant and/or superfulous business processes when
there are perfectly good processes in place today).



.




Stephen Kent <[e-mail]> on 07/16/99 12:04:48 AM

To:   [e-mail]
cc:   "'[e-mail]'" <[e-mail]>
Subject:  Re: KISS for PKIX. (Was: RE: ASN.1 vs XML (used to be RE: I-D
      ACTION :draft-ietf-pkix-scvp- 00.txt))




Eric,

>I couldn't agree with you more. However, regarding acceptance of PKI
>technologies by large organizations, I believe there are many reasons
>organizations are not adopting PKI readily besides ease-of-use issues. Nor
>does it have anything to do with ASN.1 vs XML. This issue can't be resolved
>with technology solutions because their lack of acceptance is not due
>solely to technical problems.
>
>The problems with PKI are numerous, from a corporate perspective, and many
>large organizations have not moved initial PKI efforts beyond the
>pilot/evaluation stage. Problems include outstanding legal liability
>issues, the lack of fraud protection laws, the need to address cessation of
>activites of a CA and/or a registry, the inability to bind a certificate
>distinctly to a user (software certificates identify systems, not users),
>the inability of an issuer to associate a security policy with the
>certificate (issuers need to be able to dictate when to allow caching of
>passwords,as well as things like session timeout and password construction
>rules), undefined procedures and products to support records management and
>archiving, as well as that non-repudiation claims for current PKI products
>may have no legal basis. Then there are all the technical problems.

I agree that these are precieved problems that hinder PKI deployment, but I
also think that many of these are red herrings.  If I use certificates to
authenticate users, in lieu of passwords, why are there any new legal
issues?  Part of the problem is that people have been led to believe that a
PKI must support non-repudiation, which generates a large number of valid,
legal concerns.  However, use of a PKI to support SSL, IPsec, and S/MIME
(at least on an intranet basis) does not raise such issues, yet promises to
improve security and to make life easier for users.

I disagree with your statement that a certificate in software binds a
system, vs. a user.  Yes, smart cards are preferable, but if the choice is
between a password and a certificate (and private key) with software
cryptography, I see no reason not to adopt the latter, and I certainly see
no reason to declare that the latter is not a user (vs. system)
authentication mechanism.  Finally, why do you say that an issuer cann
associate a security policy with a certificate?  We have the syntactic
means to do so as part of the standard.  Do you mean that we don't have
appplications that pay attention to the policy extension?

Steve






Received: from rbhub101.chamb.disa.mil (rbhub101.chamb.disa.mil [209.22.120.24]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id GAA16795 for <[e-mail]>; Fri, 16 Jul 1999 06:01:42 -0700 (PDT)
Received: by rbhub101.chamb.disa.mil with Internet Mail Service (5.5.2448.0) id <3XZYXC1X>; Fri, 16 Jul 1999 09:03:30 -0400
Message-ID: <[e-mail]>
From: "Flanigan, Bill" <[e-mail]>
To: [e-mail], "'Stephen Kent'" <[e-mail]>
Cc: "'[e-mail]'" <[e-mail]>
Subject: RE: KISS for PKIX
Date: Fri, 16 Jul 1999 09:06:15 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2448.0)
Content-Type: text/plain; charset="iso-8859-1"

Eric, if I may jump in here:  Steve, please see my "BF:" inline comments
below.

Best regards,
Bill

> ----------
> From: 	Stephen Kent[SMTP:[e-mail]]
> Sent: 	Friday, July 16, 1999 3:04 AM
> To: 	[e-mail]
> Cc: 	'[e-mail]'
> Subject: 	Re: KISS for PKIX. (Was: RE: ASN.1 vs XML (used to be RE:
> I-D 	 ACTION :draft-ietf-pkix-scvp- 00.txt))
> 
> Eric,
> 
> >I couldn't agree with you more. However, regarding acceptance of PKI
> >technologies by large organizations, I believe there are many reasons
> >organizations are not adopting PKI readily besides ease-of-use issues.
> Nor
> >does it have anything to do with ASN.1 vs XML. This issue can't be
> resolved
> >with technology solutions because their lack of acceptance is not due
> >solely to technical problems.
> >
> >The problems with PKI are numerous, from a corporate perspective, and
> many
> >large organizations have not moved initial PKI efforts beyond the
> >pilot/evaluation stage. Problems include outstanding legal liability
> >issues, the lack of fraud protection laws, the need to address cessation
> of
> >activites of a CA and/or a registry, the inability to bind a certificate
> >distinctly to a user (software certificates identify systems, not users),
> >the inability of an issuer to associate a security policy with the
> >certificate (issuers need to be able to dictate when to allow caching of
> >passwords,as well as things like session timeout and password
> construction
> >rules), undefined procedures and products to support records management
> and
> >archiving, as well as that non-repudiation claims for current PKI
> products
> >may have no legal basis. Then there are all the technical problems.
> 
> I agree that these are precieved problems that hinder PKI deployment, but
> I
> also think that many of these are red herrings.  If I use certificates to
> authenticate users, in lieu of passwords, why are there any new legal
> issues?  Part of the problem is that people have been led to believe that
> a
> PKI must support non-repudiation, which generates a large number of valid,
> legal concerns. 
> 
BF:  Yes, Steve, and these legal issues go way beyond those related to a
password (in part because now there are a whole bunch of additional entities
involved).  They include the end entity (human and
human-responsible-for-machine), the registration agents (RA, LRA,
out-of-band delivery person/service), the CA (both the cert-server side and
the directory/repository side), the PKI administrators, etc.  Then there are
validity issues, CRL issues, repository time-and-security issues (e.g., how
long must a cert or CRL remain in secure storage?  50 years?  150 years?)
Aside from the CP and CPS, there are also Privacy Act issues.  Then there is
key escrow and recovery (yes, they are completely different and involve
different processes and entities).  I sometimes wonder if there are enough
lawyers on the planet to support all these up-and-coming PKI!

>  However, use of a PKI to support SSL, IPsec, and S/MIME
> (at least on an intranet basis) does not raise such issues, yet promises
> to
> improve security and to make life easier for users.
> 
BF:  Whether the nonRepudiation bit is set is irrelevant from a legal
perspective (e.g., check out the POV of S&T Subcommittee of the ABA plus
what the States' attorneys and courts have been doing recently).

> I disagree with your statement that a certificate in software binds a
> system, vs. a user.  Yes, smart cards are preferable, but if the choice is
> between a password and a certificate (and private key) with software
> cryptography, I see no reason not to adopt the latter, and I certainly see
> no reason to declare that the latter is not a user (vs. system)
> authentication mechanism.
> 
BF:  Not only do you have to physically protect the .p12 file on the floppy,
you have to protect it from the OS(s), repeatedly.

>   Finally, why do you say that an issuer cann
> associate a security policy with a certificate?  We have the syntactic
> means to do so as part of the standard.  Do you mean that we don't have
> appplications that pay attention to the policy extension?
> 
BF:  Steve, very few humans will read (or be able to understand if they
read) the CP.  The number of extensions in PKIX for machine-readable policy
is miniscule compared to what is needed--I would hazard a guess of 30-50 for
the "typical" CP (and, of course, we still have the CPS which may or may not
have policy-related items not explicit in the CP plus CA cross certification
where policy mapping is a MUST).

> Steve
> 
BF:  P.S.  Being an early adopter of a PKI striving to be based on PKIX (and
commercial products) that goes beyond the pilot level is not fun.  It almost
seems like the standards were designed to make sure that early adopters
don't progress beyond the pilot stage!  The same could be said of commercial
products.  You must have very deep pockets to progress a PKI from
supporting, say, 100K certs to 5,000K certs.  And I am rapidly coming to the
conclusion (a conclusion I don't at all like) that if PKIX is to the PKI
flavor of choice for the planet, it must be substantially overhauled (or
replaced).


Received: from ctron-dnm.ctron.com ([e-mail] [12.25.1.120]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id FAA16540 for <[e-mail]>; Fri, 16 Jul 1999 05:40:57 -0700 (PDT)
Received: (from uucp@localhost) by ctron-dnm.ctron.com (8.8.7/8.8.7) id IAA14165; Fri, 16 Jul 1999 08:40:39 -0400 (EDT)
Received: from roc-mail2.ctron.com(134.141.72.230) by ctron-dnm.ctron.com via smap (4.1) id xma014136; Fri, 16 Jul 99 08:40:31 -0400
Received: from new-exc1.ctron.com (NEW-EXC1 [134.141.200.123]) by roc-mail2.ctron.com (8.8.7/8.8.7) with ESMTP id IAA12810; Fri, 16 Jul 1999 08:44:03 -0400 (EDT)
Received: by new-exc1.ctron.com with Internet Mail Service (5.5.2448.0) id <38L70XVR>; Fri, 16 Jul 1999 13:38:09 +0100
Message-ID: <[e-mail]>
From: "Waters, Stephen" <[e-mail]>
To: =?iso-8859-1?Q?Antonio_Ma=F1a?= <[e-mail]>
Cc: [e-mail]
Subject: RE: SCVP Analysis
Date: Fri, 16 Jul 1999 13:38:09 +0100
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 FAA16541

Too many protocols? Too right! I've lost track of the number of
protocols/formats being proposed to do on-line enrolment and CRL.

It would be quite useful to have CA and related product vendors(e.g. OCSP
servers) agree to implement a common, mandatory approach.  Once we have
that, addition mechanisms can be supported.  

I did some thinking on how I'm going to collect policy for VPNs. COPS seems
on way, and I made a suggestion that the COPS server could also perform the
function of the OCSP server.

Could it be the policy/OCSP/SCVP could all be managed via a single protocol
(COPS)? No, that would be too easy. If I want to look up a policy each time
a user connects to my PKI/VPN, I could pass a certificate to the
COPS-OCSP-SCVP server, have that server validate the certificate, check the
CRLs, lookup the policy and return me the certificate fields of interest (if
my system isn't able to do that for its self), and the policy.

Steve.


-----Original Message-----
From: Antonio Maña [mailto:[e-mail]]
Sent: Friday, July 16, 1999 11:49 AM
To: IETF PKIX list
Subject: Re: SCVP Analysis


Michael Myers escribió:
> 
> All,
> 
> The SCVP draft raises some interesting questions which deserve discussion
on
> the list.  Below are some thoughts to get that started.  Having gone
through
> this process, it's very clear to me at least that needs for delegated path
> validation can more easily be met with a very simple extension to OCSP.
The
> work would be very minimal compared to implementing a totally different
> protocol to do exactly the same thing.

I share your opinion.

> ...
>
> 4.  Optional support for PGP style public key management.
> ----------------------------------------------------------------
> As discussed on the floor in Oslo, inclusion of this functionality would
> require a revision to the PKIX charter.  PKIX was specifically established
> to address X.509 certificates.

The new version of PGP will support X.509 certificates, so it seems
that this opens the door to the generalised use X.509 certificates.
In this situation I do not believe that including PGP certificates
is worth the effort.
See
http://www.pgpinternational.com/product/pgp60features.html

Cheers,
Antonio Maña.

  +--------------------------------------------------------+
  !           _   ,                                        !
  ! Antonio Mana Gomez               eMail: [e-mail] !
  !              http://www.lcc.uma.es/~amg                !
  +--------------------------------------------------------+
  ! Departamento de Lenguajes y Ciencias de la Computacion !
  !      E.T.S.I.Informatica.        Desp. 1.2.B.19        !
  !                  Campus de Teatinos.                   !
  !                 29071 MALAGA (SPAIN)                   !
  +--------------------------------------------------------+
  ! Phone: [phone]        Fax: [phone] !
  +--------------------------------------------------------+
  ! KEY SERVER:                                            !
  !   Cert'eM at http://socrates.crypto.lcc.uma.es         !
  +--------------------------------------------------------+


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 EAA16039 for <[e-mail]>; Fri, 16 Jul 1999 04:38:04 -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 NAA22663 for <[e-mail]>; Fri, 16 Jul 1999 13:39:29 +0200
Received: from HYDRA ([195.198.186.73]) by caesar.udac.se (8.7.3/NetworkC-1) with SMTP id NAA15777; Fri, 16 Jul 1999 13:39:12 +0200
Received: by HYDRA with Microsoft Mail id <01BECF90.38193950@HYDRA>; Fri, 16 Jul 1999 13:36:33 +0200
Message-ID: <01BECF90.38193950@HYDRA>
From: Anders Rundgren <[e-mail]>
To: Stephen Kent <[e-mail]>, "'Ed Gerck'" <[e-mail]>, "'[e-mail]'" <[e-mail]>
Cc: "[e-mail]" <[e-mail]>
Subject: =?iso-8859-1?Q?RE=3A_Common_misconceptions=2C_was_Re=3A_KISS_f?= =?iso-8859-1?Q?or_PKIX=2E_=28Was=3A_RE=3A_ASN=2E1_vs_XML_=28used_to_be?= =?iso-8859-1?Q?_RE=3A_I=2DD_=09ACTION_=3Adraft=2Dietf=2Dpkix=2Dscvp=2D?= =?iso-8859-1?Q?_00=2Etxt=29=29?=
Date: Fri, 16 Jul 1999 13:36:31 +0200
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit

Ed,
<big snip>
>> I disagree with your statement that a certificate in software binds a
>> system, vs. a user.

>I fail to see how you can possibly disagree with Eric's statement.  Trust is not
>distributive in the social sense (ie, not associative in the mathematical sense),
>which alone opens the problem that (here, * is the trust operator):

 >(A*B)*K <> A*(B*K)

>and thus, for example, Alice may trust that Bob's certificate binds to Bob (ie, A*B)
>before Alice knows that Bob trusts Khadaffi (ie, B*K), but not afterwards (ie, A*(B*K)).
>Or, as another example, I may trust my lawyer before I know  that he trusts my competitor
>but not afterwards. Or, Bill may trust Monica before Bill knows that Monica trusts
>Linda, but not afterwards. In summary, this is the "unfaithful proxy " problem as I call it
>-- you can never tell is there is an unfaithful proxy. However, to think otherwise and to
>believe that (A*B)*K = A*(B*K) is a common misconception that leads one to believe
>that Bob's certificate binds to Bob irrespective of Bob's trust on Khadaffi -- in fact, Bob
>may not even exist.

Strange misconception between trust in certificates and bindings versus trust between people.
The latter is not suitable for IETF to handle!  It is basically a manual, indescribable, out-of-band process :-)

That is why you in an large PKI-scenario (inside an organization legal issues and non-repudian is
not that terribly interesting really), DESPERATELY NEED TTPs for issuing identity-certificates.  Even
crooks (Khadaffi?) can get one!  It is not particularly hard for a CA to verify that a person exists
(just by watching him/her) although an individual's "absolute identity" (whatever that mean) may
not always be correct.  The latter is IMO not a stumbling factor for PKI (particularly if biometrics
can be recorded and later verified) as you are unlikely to enter any serious relationship (Employment, 
Bank-account owner) without showing-up physically at least once.

The important thing that a TTP/CA must guarantee is that you must not be able to "borrow" another
individual's identity.  A set of credentials and biometrics does the trick. To certificate-wise get a NEW
identity is another thing which does not eliminate the value of PKI/TTPs/CAs as the subject is back
to square one for all his/her certificate-based relationships.  I.e. they are all gone.  

No signs of rocket-science IMHO.  KISS?  Naah, maybe not.

Note: I deliberately excluded national ID-CAs who HAVE to verify absolute identity (which is
harder and hander to do with all paper-less refugees in Europe).

Anders




Received: from correo.uma.es (correo.uma.es [150.214.40.73]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id DAA15550 for <[e-mail]>; Fri, 16 Jul 1999 03:44:37 -0700 (PDT)
Received: from sol10.lcc.uma.es (sol10.lcc.uma.es [150.214.108.1]) by correo.uma.es (8.9.3/8.9.3) with SMTP id MAA01026 for <[e-mail]>; Fri, 16 Jul 1999 12:45:53 +0200 (MET DST)
Received: from lcc.uma.es by sol10.lcc.uma.es (SMI-8.6/SMI-SVR4) id MAA17267; Fri, 16 Jul 1999 12:45:33 +0200
Message-ID: <[e-mail]>
Date: Fri, 16 Jul 1999 12:49:03 +0200
From: Antonio =?iso-8859-1?Q?Ma=F1a?= <[e-mail]>
Organization: Universidad de =?iso-8859-1?Q?M=E1laga?=
X-Mailer: Mozilla 4.5 [es] (Win95; I)
X-Accept-Language: es,en
MIME-Version: 1.0
To: IETF PKIX list <[e-mail]>
Subject: Re: SCVP Analysis
References: <[e-mail]>
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 8bit

Michael Myers escribió:
> 
> All,
> 
> The SCVP draft raises some interesting questions which deserve discussion on
> the list.  Below are some thoughts to get that started.  Having gone through
> this process, it's very clear to me at least that needs for delegated path
> validation can more easily be met with a very simple extension to OCSP.  The
> work would be very minimal compared to implementing a totally different
> protocol to do exactly the same thing.

I share your opinion.

> ...
>
> 4.  Optional support for PGP style public key management.
> ----------------------------------------------------------------
> As discussed on the floor in Oslo, inclusion of this functionality would
> require a revision to the PKIX charter.  PKIX was specifically established
> to address X.509 certificates.

The new version of PGP will support X.509 certificates, so it seems
that this opens the door to the generalised use X.509 certificates.
In this situation I do not believe that including PGP certificates
is worth the effort.
See
http://www.pgpinternational.com/product/pgp60features.html

Cheers,
Antonio Maña.

  +--------------------------------------------------------+
  !           _   ,                                        !
  ! Antonio Mana Gomez               eMail: [e-mail] !
  !              http://www.lcc.uma.es/~amg                !
  +--------------------------------------------------------+
  ! Departamento de Lenguajes y Ciencias de la Computacion !
  !      E.T.S.I.Informatica.        Desp. 1.2.B.19        !
  !                  Campus de Teatinos.                   !
  !                 29071 MALAGA (SPAIN)                   !
  +--------------------------------------------------------+
  ! Phone: [phone]        Fax: [phone] !
  +--------------------------------------------------------+
  ! KEY SERVER:                                            !
  !   Cert'eM at http://socrates.crypto.lcc.uma.es         !
  +--------------------------------------------------------+


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 BAA11983 for <[e-mail]>; Fri, 16 Jul 1999 01:52:46 -0700 (PDT)
Received: from nma.com (pm02-44.sac.verio.net [209.162.64.63]) by tomcat.sac.verio.net (8.9.1a/8.9.1) with ESMTP id BAA08864; Fri, 16 Jul 1999 01:50:30 -0700 (PDT)
Message-ID: <[e-mail]>
Date: Fri, 16 Jul 1999 01:50:21 -0700
From: Ed Gerck <[e-mail]>
X-Mailer: Mozilla 4.51 [en] (Win98; I)
X-Accept-Language: en
MIME-Version: 1.0
To: Stephen Kent <[e-mail]>
CC: [e-mail], "'[e-mail]'" <[e-mail]>
Subject: Common misconceptions, was Re: KISS for PKIX. (Was: RE: ASN.1 vs XML  (used to be RE: I-D 	ACTION :draft-ietf-pkix-scvp- 00.txt))
References: <v04020a02b3b3e54bc992@[128.33.238.108]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Stephen Kent wrote:

> I agree that these are precieved problems that hinder PKI deployment, but I
> also think that many of these are red herrings.  If I use certificates to
> authenticate users, in lieu of passwords, why are there any new legal
> issues?

This is often a source of confusion. But, basically, the reason is that  passwords
have no challenge-response mechanism.  Since a password can be replayed at
will, the authenticating party (ie, the verifier) is barred from presenting an argument
of non-repudiation when passwords are used because the verifier could have
generated any message all by itself -- the data is intrinsically corrupted. OTOH,
if certificates are used then non-repudiation data may be built by the verifier
*notwithstanding* the desire of the authenticated party to refuse it.  Which data
can then be used in administrative (eg, within company boundaries) or legal
or extra-legal (blackmail) procedures *against* the authenticated party and
*against* its expressed will (since the decision to apply, accept or reject
administrative, legal or extra-legal procedures will lie above the party, in general).
But, there are other legal issues and cert storage liability is certainly one that also
comes to mind -- a user cannot so easily take his private cert with him when he
travels (just try it in NS browsers at some hotels for example) unless he takes his
laptop...  which can then be stolen or searched.

So, this one is not a red herring at all but a red sign of warning. It is a common
misconception, though, to assume that all authentication procedures are legally
equivalent -- but, they simply aren't and for several legal reasons.

> Part of the problem is that people have been led to believe that a
> PKI must support non-repudiation, which generates a large number of valid,
> legal concerns.

Part of the problem is that PKIX also has a so-called non-repudiation bit ;-)

>  However, use of a PKI to support SSL, IPsec, and S/MIME
> (at least on an intranet basis) does not raise such issues, yet promises to
> improve security and to make life easier for users.

"improve security" and "make life easy for users" seem to be antinomies in all
systems -- security is counter to functionality, as a general principle. So, I believe
that last phrase is an empty promise though it may look good in marketing materials.
Another common misconception.

> I disagree with your statement that a certificate in software binds a
> system, vs. a user.

I fail to see how you can possibly disagree with Eric's statement.  Trust is not
distributive in the social sense (ie, not associative in the mathematical sense),
which alone opens the problem that (here, * is the trust operator):

 (A*B)*K <> A*(B*K)

and thus, for example, Alice may trust that Bob's certificate binds to Bob (ie, A*B)
before Alice knows that Bob trusts Khadaffi (ie, B*K), but not afterwards (ie, A*(B*K)).
Or, as another example, I may trust my lawyer before I know  that he trusts my competitor
but not afterwards. Or, Bill may trust Monica before Bill knows that Monica trusts
Linda, but not afterwards. In summary, this is the "unfaithful proxy " problem as I call it
-- you can never tell is there is an unfaithful proxy. However, to think otherwise and to
believe that (A*B)*K = A*(B*K) is a common misconception that leads one to believe
that Bob's certificate binds to Bob irrespective of Bob's trust on Khadaffi -- in fact, Bob
may not even exist.

So, you cannot affirm that a cert binds a user -- which user?  At most, you can
affirm that your challenge-response logs, traceroute, timestamps and whatever
may indeed point to a system that  you believe  has authenticated it -- but only
as an evidence, not as a fact.

> Yes, smart cards are preferable, but if the choice is
> between a password and a certificate (and private key) with software
> cryptography, I see no reason not to adopt the latter,

One reason is to deny unwanted non-repudiation.  Another is to reduce
cert storage liability. Etc.

> and I certainly see
> no reason to declare that the latter is not a user (vs. system)
> authentication mechanism.

as above, trust is not distributive (socially).

> Finally, why do you say that an issuer cann[ot]
> associate a security policy with a certificate?  We have the syntactic
> means to do so as part of the standard.

In which language? In which legal system? In which jurisdiction?
Syntax does not answer these (and other) questions at all -- and yet,
any of them makes the problem overly-variable in comparison to the
given syntax.  All security policies (eg, CPS) need to call themselves
"mutually exclusive" (otherwise I could just devise a security policy that
would render yours ineffective) and yet they can all be different since
security policies per se are not defined as part of the standard, just referred
in the standard as we all know.

> Do you mean that we don't have
> appplications that pay attention to the policy extension?

Policy extensions are not infused with meaning, they are simply pointers
to a meaning -- which meaning can be  inacessible to the application, outdated,
invalid in that jurisdiction, etc.

Cheers,

Ed Gerck



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 AAA09480 for <[e-mail]>; Fri, 16 Jul 1999 00:03:47 -0700 (PDT)
Received: from [128.33.238.108] (tc238-219.bbn.com [128.33.238.219]) by po1.bbn.com (8.9.1/8.9.1) with ESMTP id DAA00649; Fri, 16 Jul 1999 03:03:30 -0400 (EDT)
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Message-Id: <v04020a02b3b3e54bc992@[128.33.238.108]>
In-Reply-To: <852567AE.004F5990.00@LNOTES5>
Date: Fri, 16 Jul 1999 03:04:48 -0400
To: [e-mail]
From: Stephen Kent <[e-mail]>
Subject: Re: KISS for PKIX. (Was: RE: ASN.1 vs XML (used to be RE: I-D 	 ACTION :draft-ietf-pkix-scvp- 00.txt))
Cc: "'[e-mail]'" <[e-mail]>

Eric,

>I couldn't agree with you more. However, regarding acceptance of PKI
>technologies by large organizations, I believe there are many reasons
>organizations are not adopting PKI readily besides ease-of-use issues. Nor
>does it have anything to do with ASN.1 vs XML. This issue can't be resolved
>with technology solutions because their lack of acceptance is not due
>solely to technical problems.
>
>The problems with PKI are numerous, from a corporate perspective, and many
>large organizations have not moved initial PKI efforts beyond the
>pilot/evaluation stage. Problems include outstanding legal liability
>issues, the lack of fraud protection laws, the need to address cessation of
>activites of a CA and/or a registry, the inability to bind a certificate
>distinctly to a user (software certificates identify systems, not users),
>the inability of an issuer to associate a security policy with the
>certificate (issuers need to be able to dictate when to allow caching of
>passwords,as well as things like session timeout and password construction
>rules), undefined procedures and products to support records management and
>archiving, as well as that non-repudiation claims for current PKI products
>may have no legal basis. Then there are all the technical problems.

I agree that these are precieved problems that hinder PKI deployment, but I
also think that many of these are red herrings.  If I use certificates to
authenticate users, in lieu of passwords, why are there any new legal
issues?  Part of the problem is that people have been led to believe that a
PKI must support non-repudiation, which generates a large number of valid,
legal concerns.  However, use of a PKI to support SSL, IPsec, and S/MIME
(at least on an intranet basis) does not raise such issues, yet promises to
improve security and to make life easier for users.

I disagree with your statement that a certificate in software binds a
system, vs. a user.  Yes, smart cards are preferable, but if the choice is
between a password and a certificate (and private key) with software
cryptography, I see no reason not to adopt the latter, and I certainly see
no reason to declare that the latter is not a user (vs. system)
authentication mechanism.  Finally, why do you say that an issuer cann
associate a security policy with a certificate?  We have the syntactic
means to do so as part of the standard.  Do you mean that we don't have
appplications that pay attention to the policy extension?

Steve


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 QAA05292 for <[e-mail]>; Thu, 15 Jul 1999 16:55:47 -0700 (PDT)
Received: from stefan2.telia.se (hil-qbu-ptk-vty13.as.wcom.net [206.175.106.13]) by popmail.inbox.se (8.9.3/8.9.3) with SMTP id BAA20243 for <[e-mail]>; Fri, 16 Jul 1999 01:57:08 +0200
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1 
Date: Thu, 15 Jul 1999 00:54:08 +0200
To: <[e-mail]>
From: Stefan Santesson <[e-mail]>
Subject: Preparation of next I-D for Qualified Certificates
In-Reply-To: <D1A949D4508DD1119C8100400533BEDC12C37E@DSG1>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"

All,

We are now ready to prepare the next draft after the PKIX meeting in Oslo.
No objections to the presented solutions was raised in Oslo, which includes
keeping the current name of the document.

I have prepared the updated text, including all OID:s assigned for the draft.
Tim will finalize the document mainly by updating the ASN.1 sections and
adding an example certificate.

If anyone wish to examine the present text before the next I-D release, it
can be obtained from:

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

The next draft will, according to plan, be submitted at latest August 6.
After that we think we are ready for last call.

All contributions, check for errors and unclear descriptions are highly
welcomed.

/Stefan 


Received: from dsg1.OpenDirectory.com.au ([203.108.249.145]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id MAA02634 for <[e-mail]>; Thu, 15 Jul 1999 12:16:33 -0700 (PDT)
Received: by DSG1 with Internet Mail Service (5.0.1458.49) id <30CCYWZM>; Fri, 16 Jul 1999 05:17:42 +1000
Message-ID: <D1A949D4508DD1119C8100400533BEDC12C37E@DSG1>
From: Alan Lloyd <[e-mail]>
To: "'''PKIX-List' ' '" <[e-mail]>, "''Andrew Probert ' '" <[e-mail]>, "'[e-mail] '" <[e-mail]>
Subject: RE: ASN.1 vs XML (used to be RE: I-D ACTION:draft-ietf-pkix-scvp- 00.txt)
Date: Fri, 16 Jul 1999 05:17:40 +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"

Apologies Todd - I did not cover all the issues.

X.509 certs and crls did come from X.500 as a signed attributes (because
they are part of directory enries), therefore cryptographic bit string
integrity is necessary in cert and crl representation. In addition they
are complex attributes and because one should be able to search on
components of them (such as Issuer Name and Validity, etc) then each
component attribute must have a type and syntax definition formally
applied. In addition matching rules for component matching must also be
defined so that directory system implementors can actually engineer the
search processing algorithms for these complex attributes.

If XML wants to define certs and crls, the types, crypto, syntaxes,
matching rules for these need to be defined also. In addition - the PKI
vendors and businesss that use these "two" formats for PKI use - have to
understand what machines do with two formats, and when one or the other
or both are applied..

It is wrong to say we can have other formats just because of fashion..
when the implications of multiple formats on operations,
validation/revocation and issueance, all have to be dealt with  and
costed and profiled

regards alan

 

----------
From: [e-mail]
To: Alan Lloyd; ''PKIX-List' '; 'Andrew Probert '
Sent: 7/14/99 3:06:03 AM
Subject: Re: ASN.1 vs XML (used to be RE: I-D
ACTION:draft-ietf-pkix-scvp- 00.txt)


----- Original Message -----
From: Alan Lloyd <[e-mail]>
To: ''PKIX-List' ' <[e-mail]>; 'Andrew Probert '
<[e-mail]>
Sent: Tuesday, July 13, 1999 8:01 AM
Subject: RE: ASN.1 vs XML (used to be RE: I-D
ACTION:draft-ietf-pkix-scvp-
00.txt)


> Andrew - stop being so direct :-)
>
> What we need to do is support a ASN.1 replacement program for
> SNMP, PKCS standards, traffic management standards and onboard
> equipment, financial standards, Defence standards, OCSP, LDAP, X.500
and
> LDAP objects, etc, etc  and redefine all the object identifiers in the
> world as their syntax would change - as the format of these  are
defined
> in the ASN.1 standard...Thats all :-)

I want to be clear about what I was saying by way of XML v. ASN.1; I
dont
think that XML is 'better' than ASN.1 for representing the cert in, but
I do
think that there is no reason that an XML representation of the cert
structure is also not an issue. The cert structure is the cert structure
and
who cares what it is represented in. The fact that ASN.1 is the
'official'
language and syntax used to represent ISO models is neat and spiffy, but
the
fact that the industry is gravitating towards using XML is another big
reason that cert formats should be recognized as being representation
independent.

>
> I get the impression this thread is based on the issue that a
> certificate format is better in XML rather than ASN.1 - rather than
the
> knowledge that ASN.1 represents the Presentation layer of the OSI
> reference model in that it maps internal application layer structures
in
> C, etc (the internal syntax) to the transfer syntax TLV system  (ASN.1
> BER/DER) via the production of code/definitions derived from an ASN.1
> compiler using the input of ASN.1 definitions ... as provided in the
> respective standards. Standard which relate to the development of
> distributed applications.
>
>
> Perhaps some reading on the application of ASN.1 as a distributed
> information systems tool and the application of Object Identifiers for
> protocol and information and where this approach to systems is used
> might sway the decision here..

No, there is no need IMHO (not that I was ever humble...)..

The sheer fact of what XML is and the position it has within the IETF
and
other standards orgs, plus the growing number of tools that use it, I
think
that to shut it out and say that certs are ASN.1 is just a bit
shortsided.

>
> regards alan
>
>

Todd





Received: from ns1.dmz.valicert.com (ns1.valicert.com [63.65.221.10]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id LAA01407 for <[e-mail]>; Thu, 15 Jul 1999 11:25:34 -0700 (PDT)
Received: from ns1.serverfarm.valicert.com (corporate-gw.valicert.com [63.65.221.2]) by ns1.dmz.valicert.com (8.9.2/8.9.2) with ESMTP id LAA20795 for <[e-mail]>; Thu, 15 Jul 1999 11:24:57 -0700 (PDT)
Received: from rhone (dhcp-3-128.engineering.valicert.com [192.168.3.128] (may be forged)) by ns1.serverfarm.valicert.com (8.9.2/8.9.2) with SMTP id LAA20315 for <[e-mail]>; Thu, 15 Jul 1999 11:26:18 -0700 (PDT)
From: "Ambarish Malpani" <[e-mail]>
To: <[e-mail]>
Subject: FW: SCVP Analysis
Date: Thu, 15 Jul 1999 11:29:38 -0700
Message-ID: <001401beceef$fffbcbf0$[e-mail]>
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="----=_NextPart_000_0015_01BECEB5.539CF3F0"
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.3110.3
Importance: Normal

This is a multi-part message in MIME format.

------=_NextPart_000_0015_01BECEB5.539CF3F0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit


> 
> Hi Mike,
>     Thanks again, for looking at this so carefully.
> 
> More comments inline:
> 
> Regards.
> Ambarish
> 
>  
> > > 
> > > > All,
> > > >
> > > > The SCVP draft raises some interesting questions
> > > which deserve discussion
> > > on
> > > > the list.  Below are some thoughts to get that
> > > started.  Having gone
> > > through
> > > > this process, it's very clear to me at least that
> > > needs for delegated path
> > > > validation can more easily be met with a very
> > > simple extension to OCSP.
> > > The
> > > > work would be very minimal compared to
> > > implementing a totally different
> > > > protocol to do exactly the same thing.
> 
> Mike, I think we disagree about this topic. OCSP
> was designed to do cert status checking and it does that
> very well. It was never meant to take over the job
> of cert chain building or make trust decisions for the
> client.
> 
> Yes, you could merge the syntaxes of OCSP and SCVP, but
> I am not sure that would be a good approach. I actually
> see the OCSP server responding for the CA, while the
> SCVP responder, would normally sit in an organization
> and implement the security policy of the organization.
> 
> 
> > > >
> > > > Mike
> > > >
> > > > REQUEST SYNTAX AND SEMANTICS
> > > >
> > > > 1.  Optional use of a RequestHash  in lieu of a
> > > digitally signed request.
> > > >
> > >
> > 
> ----------------------------------------------------------------------
> > > > The need to integrity-protect the request hasn't
> > > been established.  How is
> > > > this request-response protocol different from,
> > > say, LDAP?
> > > >
> > > > It seems that requestHash is actually presumed to
> > > be sufficient for the
> > > > non-repudiation needs of accountability in some
> > > environments.  If so, this
> > > > needs to be made explicit and-more
> > > importantly-discussed on the list as
> > > such
> > > > a resolution impacts assumptions underlying
> > > current trade in certificate
> > > > validation services.
> > > >
> > > > If however the authors assert that the requestHash
> > > field is unreliable for
> > > > service accountability and is meant rather simply
> > > as an integrity check,
> > > the
> > > > requirement for integrity protection equally
> > > merits discussion of the
> > > > security risks being addressed.  Perhaps the
> > > authors have some insight
> > > into
> > > > security risks that were overlooked in prior PKIX
> > > protocols now standing
> > > as
> > > > RFCs.
> > > >
> > > > Should that discussion conclude that the request
> > > syntaxes of PKIX
> > > protocols
> > > > need to be integrity protected, it seems we may
> > > need to amend the
> > > > request-response protocols PKIX has currently sent
> > > up to IESG which do not
> > > > provide such protection.
> > > >
> > > > Should that discussion otherwise conclude that
> > > certificate validation
> > > > protocols are unique among other protocols in
> > > their need for integrity
> > > > protected requests, at a minimum this may affect
> > > RFC 2560 (OCSP), which
> > > > bears a striking architectural similarity to the
> > > proposed protocol.
> > > >
> > > > In the absence of resolution of either of these
> > > positions, the
> > > functionality
> > > > seems superfluous.
> 
> No, the requstHash is not superfluous or arbitrary. And
> no, you don't need to add it to an OCSP request.
> 
> The purpose of the requestHash is to prevent a man
> in the middle from changing the request (if it is an
> unsigned request). The reason this is important for
> SCVP (and wasn't so for OCSP), is that we allow a client
> to specify the trusted roots and the usage he
> wants to trust a cert for. Also, if a client doesn't need
> the chain the responder built, it is very likely that it
> will *not* ask the responder to return this chain, or check
> it if it is returned. In this case, if a person could get
> in between the client and the server, he could arbitrarily
> change the request to get the client to server any set of
> roots - not something we would like to encourage :-)
> 
> In OCSP, the client is expected to make sure that the
> response corresponds to the request, by making sure that the
> CertID in the response matches that of the request.
> 
> Hope this clarifies things.
> 
> > > >
> > > > 2.  Explicit specification of a request being a
> > > path validation request
> > > vs.
> > > > a revocation status check.
> > > >
> > >
> > 
> ----------------------------------------------------------------------
> > > > The proposed BIT STRING construct fails to
> > > adequately accommodate future
> > > > evolution of the semantics of certificate
> > > validation.
> > > >
> > > > In a more general framework, one could specify
> > > request types using
> > > OID-based
> > > > extensions as we do today with X.509, and as
> > > currently established by RFC
> > > > 2560 (OCSP).
> 
> Paul and I had already talked about making this change. We agree
> with you. I believe we will make both the WantBack and the
> TypesOfChecks a sequence of OIDs.
> 
> > > >
> > > > 3.  Optional inclusion of the subject certificate
> > > in the request.
> > > >
> > > ----------------------------------------------------------------
> > > > This seems to be a reasonable requirement.
> I don't think this is optional. The client *must* include the
> subject certificate. I think the text specifically states that.
> 
> Paul, I think we should make the text more obvious - I missed that
> the first time also.
> 
> > > >
> > > > 4.  Optional support for PGP style public key
> > > management.
> > > >
> > > ----------------------------------------------------------------
> > > > As discussed on the floor in Oslo, inclusion of
> > > this functionality would
> > > > require a revision to the PKIX charter.  PKIX was
> > > specifically established
> > > > to address X.509 certificates.
> > > >
> > > > 5.  Optional request for the value of subject
> > > public key, subject name,
> > > > certificate chain or revocation proof.
> > > >
> > > ----------------------------------------------------------------
> > > > If it is the objective of the proposed protocol to
> > > fully delegate path
> > > > validation to an external server, then this
> > > functionality isn't in line
> > > with
> > > > that model.  This looks more like a lightweight
> > > data access protocol.
> > > >
> > > > Further, requests for the public key and subject
> > > name seems odd against
> > > the
> > > > prior capability to include the certificate in the
> > > request, which
> > > obviously
> > > > assumes the requester has the certificate.
> > > >
> > > > So in this instance the server is acting like a
> > > remote certificate parser.
> > > > If that's indeed the authors' intent, then the
> > > proposed functionality is
> > > > incomplete.  For completeness, they should
> > > consider remotely parsed access
> > > > to:  subject alt name extension for IPSEC;
> > > certificate policy values for
> > > the
> > > > policy engines; subject directory attributes for
> > > environments using that
> > > > extension.
> > > >
> > > > We have three system level-functions being
> > > addressed by this protocol:
> > > >
> > > > 1.  Fully delegated path validation;
> > > > 2.  Lightweight PKI data access; and
> > > > 3.  Remote certificate parsing.
> > > >
> > > > The need for the first capability has been fairly
> > > obvious for years.  The
> > > > latter two are of questionable value, with perhaps
> > > the exception of
> > > > returning back the intermediate chain.
> 
> >From some of the comments at the meeting, it is not quite
> clear to me that the first capability is fairly
> obvious to everyone even today!
> 
> Anyway, the driving force for this spec was to allow the
> client to be as small as possible and to delegate as
> much of the processing as possible to the server. Our
> original thought was that we might be able to allow the
> client to not even need ASN.1 parsing capability. Given where
> the WG is today, we are withdrawing that thought. We do
> need the client to be able to deal with ASN.1 (the tiny
> syntax is going to be removed for now). This makes the need
> for the public key and subject name less important. However,
> the requirement to allow the client to ask for the cert chain
> and revocation proofs back is still important. Clients may
> choose to use the SCVP server as essentially a data gathering
> element that can collect the relevant data (using LDAP, OCSP
> or whatever) and give it back enough information to prove
> to itself that the cert is good.
> 
> > > >
> > > > 6.  Optional specification of intermediate
> > > certificates to use as a
> > > > supplement to the validation path of the subject
> > > certificate.
> > > >
> > > ----------------------------------------------------------------
> > > > In the context of the legal framework underpinning
> > > the use of certificates
> > > > for electronic commerce, the issuer of a
> > > certificate issued that
> > > certificate
> > > > with a very specific trust chain model in mind.
> > > >
> > > > The proposed functionality seems to suggest that
> > > the authors are asking
> > > PKIX
> > > > to support the notion of the "re-purposing" of
> > > certificates for uses
> > > beyond
> > > > those intended by the original issuer.
> > > >
> > > > Was this the authors' intent?  If not, then what
> > > problem is this proposed
> > > > functionality solving?
> 
> Nothing so deep or fundamental. It is quite possible that
> the client has obtained some intermediate certs as part
> of its communication with the cert holder (e.g. you can
> get a cert chain in SSL). These certs might not be easily
> accessible to the SCVP responder, since it might not know
> where to go for these intermediate certs. The purpose of
> passing these certs to the responder is to make its chain
> building task easier. There was no intent to subvert the
> issuer's intent.
> 
> > > >
> > > > 7.  Optional specification of trusted roots the
> > > server must rely on.
> > > >
> > > ----------------------------------------------------------------
> > > > Same issue as above.
> > > >
> > > > Is it the authors' proposition that the issuer of
> > > a certificate is *not*
> > > the
> > > > final arbiter of the trustworthiness of that
> > > certificate?  (noting that
> > > > "issuer" could be an entity that directs another
> > > entity to manufacture and
> > > > distribute a certificate on its behalf).
> 
> Again Mike, nothing very deep and fundamental here. It is
> quite possible that the SCVP client has a set of roots/certs it
> trusts. It might want all chains built to that/those roots,
> rather than to any roots the responder might choose to trust.
> 
> 
> > > >
> > > > 8.  Optional configuration identifier that points
> > > to a pre-defined set of
> > > > the above options.
> > > >
> > > ----------------------------------------------------------------
> > > > This seems to be a reasonable requirement.
> > > >
> > > > 9.  Extensions may be critical or non-critical.
> > > >
> > > ----------------------------------------------------------------
> > > > Recent experience has shown that this is
> > > inadvisable.  The XML DigSig
> > > group,
> > > > for example, has specifically deprecated proposed
> > > use of critical flags
> > > for
> > > > well-known reasons.
> 
> I am not sure I agree with this conclusion. It is quite possible 
> that an entity wants to make a query that contains some important
> semantics. It only wants an answer if the responder understands
> those semantics. Critical extensions do make sense when people try
> to use this base protocol in different environments.
> 
> > > >
> > > > RESPONSE SYNTAX AND SEMANTICS
> > > >
> > > > 10.  "Unrecognized" error codes related to the
> > > above optional request
> > > > protocol elements.
> > > >
> > > ----------------------------------------------------------------
> > > > No issues, other than alignment with the prior
> > > analysis.
> > > >
> > > > 11.  Validation response values for "valid",
> > > "notValid",
> > > > "temporarilyUnknown" and "unknown".
> > > >
> > > ----------------------------------------------------------------
> > > > This seems to be a reasonable requirement.
> > > >
> > > > Except perhaps for "temporarilyUnknown".  What
> > > does a client do with that?
> 
> "temporarily unknown" is a way for a server to say
> that it does normally know about that particular cert, but can't
> provide an answer right now - for example if it can build the
> chain, but not obtain revocation proof. The client can infer
> that it can go back to the server at a later time with similar
> certs.
> 
> 
> > > >
> > > > 12.  Optional inclusion of an errorMessage text
> > > string
> > > >
> > > ----------------------------------------------------------------
> > > > This seems to be a reasonable requirement.
> > > >
> > > > 13.  Optional inclusion of subject public key
> > > value, subject name or path
> > > > validation chain, consistent with prior request.
> > > >
> > > ----------------------------------------------------------------
> > > > See point #5 above.
> 
> See response to point #5 above
> 
> > > >
> > > > 14.  Optional inclusion of requestHash appearing
> > > in request.
> > > >
> > > ----------------------------------------------------------------
> > > > See point #1 above.
> 
> See response to point #1 above.
> 
> > > >
> > > > 15.  Optional inclusion of revocation proof
> > > content.
> > > >
> > > ----------------------------------------------------------------
> > > > See point #5 above.
> 
> See response to point #5 above
> 
> > > >
> > > > 16.  Optional use of a digital signature
> > > >
> > > ----------------------------------------------------------------
> > > > This is the same as OCSP: some error conditions
> > > don't need to be signed.
> > > > However, the proposed protocol goes on to assert
> > > that other types of
> > > > responses don't need to be signed if conveyed over
> > > a secure channel.
> > > >
> > > > An optional signature on an affirmative response
> > > is equivalent to an
> > > > unsigned CRL.  It can't be used to support
> > > non-repudiation.
> 
> Again, it depends on what the client is using SCVP for.
> If it is using SCVP in an intranet mainly for policy
> management, it might not care whether the response is
> signed or not. If non-repudiation is important, the
> client will need a signed response.
> 
> Hope this clarifies things,
> Regards,
> Ambarish
> 
> P.S.
> Paul,
>     I think we should include some of these clarifications
> in the next revision, so that other readers aren't confused.
> 
> Ambarish
> 
> 
------=_NextPart_000_0015_01BECEB5.539CF3F0
Content-Type: application/octet-stream;
	name="smime.vfs"
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
	filename="smime.vfs"


------=_NextPart_000_0015_01BECEB5.539CF3F0--



Received: from foo.ietf.uninett.no ([e-mail] [128.39.10.31]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id IAA27595 for <[e-mail]>; Thu, 15 Jul 1999 08:53:33 -0700 (PDT)
Received: from ieca.com (dhcp30175.ietf.uninett.no [128.39.30.175]) by foo.ietf.uninett.no (8.9.3/8.9.3) with ESMTP id RAA15891; Thu, 15 Jul 1999 17:54:37 +0200
Message-ID: <[e-mail]>
Date: Thu, 15 Jul 1999 17:53:37 -0500
From: Sean Turner <[e-mail]>
X-Mailer: Mozilla 4.5 [en] (Win98; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Denis Pinkas <[e-mail]>
CC: [e-mail]
Subject: Re: When is Timestamp applied?
References: <[e-mail]> <[e-mail]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Denis,

I agree that all of the examples you present are true, but I hope the difference
between 2 and 3 are pretty close to zero ;)

I think to keep it simple we should just go with when the signature was applied,
whether that be right when the TSA gets the data or at some later time (I assume
a properly acting TSA will sign the data ASAP).  I know there are differences
between the time when signature is asked for and when the signature generation
is completed, but like I said earlier I hope they are really really small (i.e.,
negligible).

spt

Denis Pinkas wrote:

> Sean,
>
> You are perfectly right, we need to say more in the document. Since the
> protocol is transport independent but the time between the request and the
> response is transport dependent, we need to indicate in the TST some
> information to say whether the time is:
>
> 1) the time of reception of the request by the TSA,
> 2) the time when the request was entered/processed in the crypto engine of
> the TSA,
> 3) the time which is en the request left the crypto engine of the TSA (if
> the signature time can be estimated, then the signature time may be
> anticipated).
>
> Case 1. This case is relevant to smtp and ftp, where all the requests will
> be time stamped according to the SAME date of reception.
>
> Case 2. This case is relevant to sockets and HTTP, when there is a single or
> few requests.
>
> Case 3. This case is mostly relevant when the requester indeed is not
> interrested in a time stamp, but by a signed time only. Under that
> circumstance the time in the TST will be the closest to the time of the
> response.
>
> Since the STIME working group wanted to address this concern but was told
> during their meeting that signed time will be addressed by PKIX, it would
> make sense that we cover that case (I noticed that Steve Kent said in the
> meeting that we should not). This is where time below the second is
> important.
>
> When there is no hash present in the response we could assume that the last
> case applied. However, this would impose a specific implementation. I would
> rather allow some kind of flexibility and RECOMMEND to allow the TSA to
> indicate which case applies. The main reason is that in any case it is
> simpler for an implementation to provide the case 2, i.e. the time when the
> request was entered/processed in the crypto engine.
>
> So the proposal would be to include a flag that would say which of the three
> cases has been used by the TSA
>
> The next question is then : should the requester be able to request which
> case he would like to be supported ?
> I would like to avoid this and thus not add any new parameter in the
> request.
>
> Instead I would rather RECOMMEND what the TSA SHOULD do for every case of
> transport keeping in mind that it can use whatever scheme he likes, in
> particular the case 2.
>
> The proposal is thus :
>
> 1) to recommend for every transport which of the three cases should be used,
>
> 2) to recommend when there is no hash present in the request to use case 3,
> 3) to allow the TSA to include a flag (taking the values 0, 1 and 2) stating
> to which instant the time of time stamping applies.
>
> If there is some consensus around this proposal, I will then propose an ASN1
> translation of it, along which new text.
>
> Regards,
>
> Denis
>
> > Denis,
> >
> > At the meeting today you mentioned that the draft doesn't specify when
> > the timestamp is applied, either when the data was received or when the
> > signature was applied.  BUt, the slides you threw up from the ISO text
> > clearly indicated that the timestamp is applied when the signature is
> > generated.  I think the draft should either
> > - specify that the time in the timesatamp is the TSA's signture time or
> > - there should be field included (a choice) to indicate that the time is
> > when the data was received or when the TSA's signature was generated.
> >
> > Otherwise, the meaning of the timestamp is very ambiguious.
> >
> > spt



Received: from foo.ietf.uninett.no ([e-mail] [128.39.10.31]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id IAA27370 for <[e-mail]>; Thu, 15 Jul 1999 08:48:53 -0700 (PDT)
Received: from ieca.com (dhcp30175.ietf.uninett.no [128.39.30.175]) by foo.ietf.uninett.no (8.9.3/8.9.3) with ESMTP id RAA15866; Thu, 15 Jul 1999 17:49:59 +0200
Message-ID: <[e-mail]>
Date: Thu, 15 Jul 1999 17:48:59 -0500
From: Sean Turner <[e-mail]>
X-Mailer: Mozilla 4.5 [en] (Win98; U)
X-Accept-Language: en
MIME-Version: 1.0
To: [e-mail]
CC: Michael Zolotarev <[e-mail]>
Subject: Re: When is Timestamp applied?
References: <[e-mail]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Mike,

I'd actually be in favor of just saying that the time indicated in the timestamp should be when the TSA signed the data.

spt

Michael Zolotarev wrote:

> Denis, Sean,
>
> Does a person who is not currently in Oslo have a right to say :)?
>
> >From the practical point of view, I do not see much benefit in putting extra detail into the stamp. What the time stamp is for? To provide an evidence that a datum existed AT LEAST at certain time. This CERTAIN time is just an astronomical time, which has no inherit reference to a particular TSA's implementation.
> Just think about it: You've got a stamp, and it indicates one of your 3 cases - how do we interpret it?
> Case 1. The time was 12.34.56.789, and it is a time the request entered the TSA box. Conclusion: the datum existed AT LEAST at that time.
> Case 2. The time was 12.34.56.789, and it is a time the request was processed by the crypto. Conclusion:the datum existed AT LEAST at that time. It may have also existed some fraction of the seconds before. But nobody can provide any reasonable estimate of it. And even more important, no serious verifier will accept it as a valid argument.
> Case 3. ...existed AT LEAST .... The conclusion is the same as in 2.
>
> So, thinking practically, the flag may be not such a good thing.
>
> However, it may worth saying in the draft that "TSA should take all possible care to ensure that the time indicated in the stamp is the earliest possible time that TSA could practically apply to the message".
>
> -----Original Message-----
> From: Denis Pinkas [mailto:[e-mail]]
> Sent: Thursday, July 15, 1999 7:42 PM
> To: Sean Turner
> Cc: [e-mail]
> Subject: Re: When is Timestamp applied?
>
> Sean,
>
> You are perfectly right, we need to say more in the document. Since the
> protocol is transport independent but the time between the request and the
> response is transport dependent, we need to indicate in the TST some
> information to say whether the time is:
>
> 1) the time of reception of the request by the TSA,
> 2) the time when the request was entered/processed in the crypto engine of
> the TSA,
> 3) the time which is en the request left the crypto engine of the TSA (if
> the signature time can be estimated, then the signature time may be
> anticipated).
>
> Case 1. This case is relevant to smtp and ftp, where all the requests will
> be time stamped according to the SAME date of reception.
>
> Case 2. This case is relevant to sockets and HTTP, when there is a single or
> few requests.
>
> Case 3. This case is mostly relevant when the requester indeed is not
> interrested in a time stamp, but by a signed time only. Under that
> circumstance the time in the TST will be the closest to the time of the
> response.
>
> Since the STIME working group wanted to address this concern but was told
> during their meeting that signed time will be addressed by PKIX, it would
> make sense that we cover that case (I noticed that Steve Kent said in the
> meeting that we should not). This is where time below the second is
> important.
>
> When there is no hash present in the response we could assume that the last
> case applied. However, this would impose a specific implementation. I would
> rather allow some kind of flexibility and RECOMMEND to allow the TSA to
> indicate which case applies. The main reason is that in any case it is
> simpler for an implementation to provide the case 2, i.e. the time when the
> request was entered/processed in the crypto engine.
>
> So the proposal would be to include a flag that would say which of the three
> cases has been used by the TSA
>
> The next question is then : should the requester be able to request which
> case he would like to be supported ?
> I would like to avoid this and thus not add any new parameter in the
> request.
>
> Instead I would rather RECOMMEND what the TSA SHOULD do for every case of
> transport keeping in mind that it can use whatever scheme he likes, in
> particular the case 2.
>
> The proposal is thus :
>
> 1) to recommend for every transport which of the three cases should be used,
>
> 2) to recommend when there is no hash present in the request to use case 3,
> 3) to allow the TSA to include a flag (taking the values 0, 1 and 2) stating
> to which instant the time of time stamping applies.
>
> If there is some consensus around this proposal, I will then propose an ASN1
> translation of it, along which new text.
>
> Regards,
>
> Denis
>
> > Denis,
> >
> > At the meeting today you mentioned that the draft doesn't specify when
> > the timestamp is applied, either when the data was received or when the
> > signature was applied.  BUt, the slides you threw up from the ISO text
> > clearly indicated that the timestamp is applied when the signature is
> > generated.  I think the draft should either
> > - specify that the time in the timesatamp is the TSA's signture time or
> > - there should be field included (a choice) to indicate that the time is
> > when the data was received or when the TSA's signature was generated.
> >
> > Otherwise, the meaning of the timestamp is very ambiguious.
> >
> > spt



Received: from scaup.prod.itd.earthlink.net (scaup.prod.itd.earthlink.net [207.217.121.49]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id IAA26930 for <[e-mail]>; Thu, 15 Jul 1999 08:26:58 -0700 (PDT)
Received: from lattin (2Cust26.tnt20.sfo3.da.uu.net [208.254.225.26]) by scaup.prod.itd.earthlink.net (8.9.3/8.9.3) with SMTP id IAA20893; Thu, 15 Jul 1999 08:27:57 -0700 (PDT)
From: "Bill Lattin" <[e-mail]>
To: "Michael Zolotarev" <[e-mail]>, "Denis Pinkas" <[e-mail]>
Cc: <[e-mail]>
Subject: RE: When is Timestamp applied?
Date: Thu, 15 Jul 1999 08:27:19 -0700
Message-ID: <000401beced6$87177fe0$d1fe2499@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
In-reply-to: <[e-mail]>
X-MimeOLE: Produced By Microsoft MimeOLE V4.72.2106.4
Importance: Normal

I agree with Michael's analysis.  The granularity within a TSA will be of
limited practical use.

For someone trying to beat someone else to the "punch", I can envisage this
person trying to use a system that stamps earlier than another - this
situation will always exist regardless of flagging the 3 cases since
implementations will always differ.  Short of prescribing an actual
implementation that all must use, there will always be variations as to when
time was applied.

At least if the TSA's are synchronized to a National Timing Authority, most
could agree on the time.

Bill

> -----Original Message-----
> From: Michael Zolotarev [mailto:[e-mail]]
> Sent: Thursday, July 15, 1999 04:24
> To: Denis Pinkas
> Cc: [e-mail]
> Subject: RE: When is Timestamp applied?
>
>
> Denis, Sean,
>
> Does a person who is not currently in Oslo have a right to say :)?
>
> >From the practical point of view, I do not see much benefit in
> putting extra detail into the stamp. What the time stamp is for?
> To provide an evidence that a datum existed AT LEAST at certain
> time. This CERTAIN time is just an astronomical time, which has
> no inherit reference to a particular TSA's implementation.
> Just think about it: You've got a stamp, and it indicates one of
> your 3 cases - how do we interpret it?
> Case 1. The time was 12.34.56.789, and it is a time the request
> entered the TSA box. Conclusion: the datum existed AT LEAST at that time.
> Case 2. The time was 12.34.56.789, and it is a time the request
> was processed by the crypto. Conclusion:the datum existed AT
> LEAST at that time. It may have also existed some fraction of the
> seconds before. But nobody can provide any reasonable estimate of
> it. And even more important, no serious verifier will accept it
> as a valid argument.
> Case 3. ...existed AT LEAST .... The conclusion is the same as in 2.
>
> So, thinking practically, the flag may be not such a good thing.
>
> However, it may worth saying in the draft that "TSA should take
> all possible care to ensure that the time indicated in the stamp
> is the earliest possible time that TSA could practically apply to
> the message".
>
> -----Original Message-----
> From: Denis Pinkas [mailto:[e-mail]]
> Sent: Thursday, July 15, 1999 7:42 PM
> To: Sean Turner
> Cc: [e-mail]
> Subject: Re: When is Timestamp applied?
>
>
> Sean,
>
> You are perfectly right, we need to say more in the document. Since the
> protocol is transport independent but the time between the request and the
> response is transport dependent, we need to indicate in the TST some
> information to say whether the time is:
>
> 1) the time of reception of the request by the TSA,
> 2) the time when the request was entered/processed in the crypto engine of
> the TSA,
> 3) the time which is en the request left the crypto engine of the TSA (if
> the signature time can be estimated, then the signature time may be
> anticipated).
>
> Case 1. This case is relevant to smtp and ftp, where all the requests will
> be time stamped according to the SAME date of reception.
>
> Case 2. This case is relevant to sockets and HTTP, when there is
> a single or
> few requests.
>
> Case 3. This case is mostly relevant when the requester indeed is not
> interrested in a time stamp, but by a signed time only. Under that
> circumstance the time in the TST will be the closest to the time of the
> response.
>
> Since the STIME working group wanted to address this concern but was told
> during their meeting that signed time will be addressed by PKIX, it would
> make sense that we cover that case (I noticed that Steve Kent said in the
> meeting that we should not). This is where time below the second is
> important.
>
> When there is no hash present in the response we could assume
> that the last
> case applied. However, this would impose a specific
> implementation. I would
> rather allow some kind of flexibility and RECOMMEND to allow the TSA to
> indicate which case applies. The main reason is that in any case it is
> simpler for an implementation to provide the case 2, i.e. the
> time when the
> request was entered/processed in the crypto engine.
>
> So the proposal would be to include a flag that would say which
> of the three
> cases has been used by the TSA
>
> The next question is then : should the requester be able to request which
> case he would like to be supported ?
> I would like to avoid this and thus not add any new parameter in the
> request.
>
> Instead I would rather RECOMMEND what the TSA SHOULD do for every case of
> transport keeping in mind that it can use whatever scheme he likes, in
> particular the case 2.
>
> The proposal is thus :
>
> 1) to recommend for every transport which of the three cases
> should be used,
>
> 2) to recommend when there is no hash present in the request to
> use case 3,
> 3) to allow the TSA to include a flag (taking the values 0, 1 and
> 2) stating
> to which instant the time of time stamping applies.
>
> If there is some consensus around this proposal, I will then
> propose an ASN1
> translation of it, along which new text.
>
> Regards,
>
> Denis
>
>
> > Denis,
> >
> > At the meeting today you mentioned that the draft doesn't specify when
> > the timestamp is applied, either when the data was received or when the
> > signature was applied.  BUt, the slides you threw up from the ISO text
> > clearly indicated that the timestamp is applied when the signature is
> > generated.  I think the draft should either
> > - specify that the time in the timesatamp is the TSA's signture time or
> > - there should be field included (a choice) to indicate that the time is
> > when the data was received or when the TSA's signature was generated.
> >
> > Otherwise, the meaning of the timestamp is very ambiguious.
> >
> > spt
>



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 IAA26633 for <[e-mail]>; Thu, 15 Jul 1999 08:14:20 -0700 (PDT)
Received: from stingray.missi.ncsc.mil (root@localhost) by stingray.missi.ncsc.mil with ESMTP id LAA25058 for <[e-mail]>; Thu, 15 Jul 1999 11:15:41 -0400 (EDT)
Received: from missi.ncsc.mil (depot.missi.ncsc.mil [144.51.60.1]) by stingray.missi.ncsc.mil with ESMTP id LAA25052 for <[e-mail]>; Thu, 15 Jul 1999 11:15:41 -0400 (EDT)
Received: from ara.missi.ncsc.mil (ara.missi.ncsc.mil [144.51.58.9]) by missi.ncsc.mil (8.8.8/8.8.8) with ESMTP id LAA11005 for <[e-mail]>; Thu, 15 Jul 1999 11:15:40 -0400 (EDT)
Received: from ara.missi.ncsc.mil (ara.missi.ncsc.mil [144.51.58.9]) by ara.missi.ncsc.mil (8.9.1b+Sun/8.9.1) with SMTP id LAA03136 for <[e-mail]>; Thu, 15 Jul 1999 11:15:34 -0400 (EDT)
Message-Id: <[e-mail]>
Date: Thu, 15 Jul 1999 11:15:34 -0400 (EDT)
From: "David P. Kemp" <[e-mail]>
Reply-To: "David P. Kemp" <[e-mail]>
Subject: Re: SCVP Analysis
To: [e-mail]
MIME-Version: 1.0
Content-Type: TEXT/plain; charset=us-ascii
Content-MD5: Ezk+lSmo3RwhFgytcr+/XA==
X-Mailer: dtmail 1.3.0 CDE Version 1.3 SunOS 5.7 sun4u sparc

> From: Michael Myers <[e-mail]>
>
>   [...]
>
> We have three system level-functions being addressed by this protocol:
> 
> 1.  Fully delegated path validation;
> 2.  Lightweight PKI data access; and
> 3.  Remote certificate parsing.
> 
> The need for the first capability has been fairly obvious for years.  The
> latter two are of questionable value, with perhaps the exception of
> returning back the intermediate chain.
>
>   [...]
>   
> 7.  Optional specification of trusted roots the server must rely on.
> ----------------------------------------------------------------
> Same issue as above.
> 
> Is it the authors' proposition that the issuer of a certificate is *not* the
> final arbiter of the trustworthiness of that certificate?  (noting that
> "issuer" could be an entity that directs another entity to manufacture and
> distribute a certificate on its behalf).

Very nice taxonomy.  I agree that function 1 is needed and that function 3
is of questionable (IMO, zero) value.

I believe that the model described by Ms. Bitan, function 2 where the
server is an untrusted certificate fetching, caching, and chain
building engine, is useful.  In that model, it is useful for the client
to optionally pass it's trusted cert(s) to the path building server,
since the server might not know which certs are trusted by a particular
client at a particular time for a particular purpose.

The distinction between models 1 (where the client trusts the server to
do its security processing) and 2 (where the only security requirement on
the server is to be available) should be made explicit.  The distinction
would be clearer if different messages were used, rather than populating
different optional fields in a single message.


> 9.  Extensions may be critical or non-critical.
> ----------------------------------------------------------------
> Recent experience has shown that this is inadvisable.  The XML DigSig group,
> for example, has specifically deprecated proposed use of critical flags for
> well-known reasons.

I agree that critical flags should not be used.  When defining a new
protocol, there is no need to support half- ummm, baked interoperability
with an installed base of non-compliant implementations.  And when a
"critical" flag is overloaded to modify the semantics of an extension,
the clarity of the specification is further diminished.

The static flags MUST, SHOULD, and MAY in the protocol specification
are sufficient indicators of criticality.



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 HAA26056 for <[e-mail]>; Thu, 15 Jul 1999 07:41:33 -0700 (PDT)
Received: from bull.net (frcls6118.frcl.bull.fr [129.182.109.213]) by clbull.frcl.bull.fr (8.9.1a/8.9.1) with ESMTP id QAA11714; Thu, 15 Jul 1999 16:35:23 +0200
Message-ID: <[e-mail]>
Date: Thu, 15 Jul 1999 16:42:18 +0200
From: Denis Pinkas <[e-mail]>
Organization: Bull
X-Mailer: Mozilla 4.06 [fr] (Win95; I)
MIME-Version: 1.0
To: Michael Myers <[e-mail]>
CC: IETF PKIX list <[e-mail]>
Subject: Re: SCVP Analysis
References: <[e-mail]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit

Michael,

You didn't loose time since the last meeting. :-)

As I mentioned during the Oslo session I think it would be nice to add some new
fields to the existing OSCP propocol to transform it into a SCVP protocol. It
would have been great if you could have made a proposal before the current SCVP
document was posted. This did not happen. We are not going to look backwards, so
let us look forwards. Rather than looking at the details, it appeared to me that
we first need to agree on the scope of the document.

The current scope, which is copied below, is not adequate

" The SCVP protocol allows a client to offload certificate handling to a
server. The server can give a variety of valuable information about the
certificate, such as whether or not it is valid, what the public key
and subject of the certificate is, and so on."

I would propose to reformulate it this way:

" The SCVP protocol allows a thin client to offload certificate validation to a
trusted server, for a given instant of time, according to a given validation
policy known from that trusted server. The server will give an indication
whether the validation was successful or not and, if requested, may also give
back the certification path and the revocation information (CRLs or OCSP
responses) used to perform that validation. The requester may supply in his
request certificates and or revocation information that may be used by the
server to perform that validation."

If we can agree on the scope then writing the ASN1 should be quite easy. :-)
Since the tiny syntax is now gone away, having an ASN1 description should not be
a problem anymore.

We should not try to fix the current SCVP document but write a new one, re-using
OCSP whenever possible. Ideally, a document co-authored by yourself together
with Ambarish Malpani and Paul Hoffman would certainly be appreciated.

Denis


> All,
>
> The SCVP draft raises some interesting questions which deserve discussion on
> the list.  Below are some thoughts to get that started.  Having gone through
> this process, it's very clear to me at least that needs for delegated path
> validation can more easily be met with a very simple extension to OCSP.  The
> work would be very minimal compared to implementing a totally different
> protocol to do exactly the same thing.
>
> Mike
>
> REQUEST SYNTAX AND SEMANTICS
>
> 1.  Optional use of a RequestHash  in lieu of a digitally signed request.
> ----------------------------------------------------------------------
> The need to integrity-protect the request hasn't been established.  How is
> this request-response protocol different from, say, LDAP?
>
> It seems that requestHash is actually presumed to be sufficient for the
> non-repudiation needs of accountability in some environments.  If so, this
> needs to be made explicit and-more importantly-discussed on the list as such
> a resolution impacts assumptions underlying current trade in certificate
> validation services.
>
> If however the authors assert that the requestHash field is unreliable for
> service accountability and is meant rather simply as an integrity check, the
> requirement for integrity protection equally merits discussion of the
> security risks being addressed.  Perhaps the authors have some insight into
> security risks that were overlooked in prior PKIX protocols now standing as
> RFCs.
>
> Should that discussion conclude that the request syntaxes of PKIX protocols
> need to be integrity protected, it seems we may need to amend the
> request-response protocols PKIX has currently sent up to IESG which do not
> provide such protection.
>
> Should that discussion otherwise conclude that certificate validation
> protocols are unique among other protocols in their need for integrity
> protected requests, at a minimum this may affect RFC 2560 (OCSP), which
> bears a striking architectural similarity to the proposed protocol.
>
> In the absence of resolution of either of these positions, the functionality
> seems superfluous.
>
> 2.  Explicit specification of a request being a path validation request vs.
> a revocation status check.
> ----------------------------------------------------------------------
> The proposed BIT STRING construct fails to adequately accommodate future
> evolution of the semantics of certificate validation.
>
> In a more general framework, one could specify request types using OID-based
> extensions as we do today with X.509, and as currently established by RFC
> 2560 (OCSP).
>
> 3.  Optional inclusion of the subject certificate in the request.
> ----------------------------------------------------------------
> This seems to be a reasonable requirement.
>
> 4.  Optional support for PGP style public key management.
> ----------------------------------------------------------------
> As discussed on the floor in Oslo, inclusion of this functionality would
> require a revision to the PKIX charter.  PKIX was specifically established
> to address X.509 certificates.
>
> 5.  Optional request for the value of subject public key, subject name,
> certificate chain or revocation proof.
> ----------------------------------------------------------------
> If it is the objective of the proposed protocol to fully delegate path
> validation to an external server, then this functionality isn't in line with
> that model.  This looks more like a lightweight data access protocol.
>
> Further, requests for the public key and subject name seems odd against the
> prior capability to include the certificate in the request, which obviously
> assumes the requester has the certificate.
>
> So in this instance the server is acting like a remote certificate parser.
> If that's indeed the authors' intent, then the proposed functionality is
> incomplete.  For completeness, they should consider remotely parsed access
> to:  subject alt name extension for IPSEC; certificate policy values for the
> policy engines; subject directory attributes for environments using that
> extension.
>
> We have three system level-functions being addressed by this protocol:
>
> 1.  Fully delegated path validation;
> 2.  Lightweight PKI data access; and
> 3.  Remote certificate parsing.
>
> The need for the first capability has been fairly obvious for years.  The
> latter two are of questionable value, with perhaps the exception of
> returning back the intermediate chain.
>
> 6.  Optional specification of intermediate certificates to use as a
> supplement to the validation path of the subject certificate.
> ----------------------------------------------------------------
> In the context of the legal framework underpinning the use of certificates
> for electronic commerce, the issuer of a certificate issued that certificate
> with a very specific trust chain model in mind.
>
> The proposed functionality seems to suggest that the authors are asking PKIX
> to support the notion of the "re-purposing" of certificates for uses beyond
> those intended by the original issuer.
>
> Was this the authors' intent?  If not, then what problem is this proposed
> functionality solving?
>
> 7.  Optional specification of trusted roots the server must rely on.
> ----------------------------------------------------------------
> Same issue as above.
>
> Is it the authors' proposition that the issuer of a certificate is *not* the
> final arbiter of the trustworthiness of that certificate?  (noting that
> "issuer" could be an entity that directs another entity to manufacture and
> distribute a certificate on its behalf).
>
> 8.  Optional configuration identifier that points to a pre-defined set of
> the above options.
> ----------------------------------------------------------------
> This seems to be a reasonable requirement.
>
> 9.  Extensions may be critical or non-critical.
> ----------------------------------------------------------------
> Recent experience has shown that this is inadvisable.  The XML DigSig group,
> for example, has specifically deprecated proposed use of critical flags for
> well-known reasons.
>
> RESPONSE SYNTAX AND SEMANTICS
>
> 10.  "Unrecognized" error codes related to the above optional request
> protocol elements.
> ----------------------------------------------------------------
> No issues, other than alignment with the prior analysis.
>
> 11.  Validation response values for "valid", "notValid",
> "temporarilyUnknown" and "unknown".
> ----------------------------------------------------------------
> This seems to be a reasonable requirement.
>
> Except perhaps for "temporarilyUnknown".  What does a client do with that?
>
> 12.  Optional inclusion of an errorMessage text string
> ----------------------------------------------------------------
> This seems to be a reasonable requirement.
>
> 13.  Optional inclusion of subject public key value, subject name or path
> validation chain, consistent with prior request.
> ----------------------------------------------------------------
> See point #5 above.
>
> 14.  Optional inclusion of requestHash appearing in request.
> ----------------------------------------------------------------
> See point #1 above.
>
> 15.  Optional inclusion of revocation proof content.
> ----------------------------------------------------------------
> See point #5 above.
>
> 16.  Optional use of a digital signature
> ----------------------------------------------------------------
> This is the same as OCSP: some error conditions don't need to be signed.
> However, the proposed protocol goes on to assert that other types of
> responses don't need to be signed if conveyed over a secure channel.
>
> An optional signature on an affirmative response is equivalent to an
> unsigned CRL.  It can't be used to support non-repudiation.



Received: from www.meridianus.com (209.249.223.18.has.no.reverse [209.249.223.18] (may be forged)) by mail.proper.com (8.8.8/8.8.5) with ESMTP id HAA25770 for <[e-mail]>; Thu, 15 Jul 1999 07:33:15 -0700 (PDT)
Received: from PC1 by www.meridianus.com (8.8.8+Sun/SMI-SVR4) id IAA02867; Thu, 15 Jul 1999 08:29:09 -0700 (PDT)
Message-ID: <002401beced0$d49d2360$[e-mail]>
From: "Todd S. Glassey" <[e-mail]>
To: "Denis Pinkas" <[e-mail]>, "Sean Turner" <[e-mail]>
Cc: <[e-mail]>
References: <[e-mail]> <[e-mail]>
Subject: Re: When is Timestamp applied?
Date: Thu, 15 Jul 1999 07:46:32 -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 5.00.2918.2701
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2918.2701

I have a small question....

----- Original Message -----
From: Denis Pinkas <[e-mail]>
To: Sean Turner <[e-mail]>
Cc: <[e-mail]>
Sent: Thursday, July 15, 1999 2:41 AM
Subject: Re: When is Timestamp applied?


> Sean,
>
> You are perfectly right, we need to say more in the document. Since the
> protocol is transport independent but the time between the request and the
> response is transport dependent, we need to indicate in the TST some
> information to say whether the time is:
>
> 1) the time of reception of the request by the TSA,
> 2) the time when the request was entered/processed in the crypto engine of
> the TSA,
> 3) the time which is en the request left the crypto engine of the TSA (if
> the signature time can be estimated, then the signature time may be
> anticipated).
>
> Case 1. This case is relevant to smtp and ftp, where all the requests will
> be time stamped according to the SAME date of reception.
>
> Case 2. This case is relevant to sockets and HTTP, when there is a single
or
> few requests.
>
> Case 3. This case is mostly relevant when the requester indeed is not
> interrested in a time stamp, but by a signed time only. Under that
> circumstance the time in the TST will be the closest to the time of the
> response.
>
> Since the STIME working group wanted to address this concern but was told
> during their meeting that signed time will be addressed by PKIX, it would
> make sense that we cover that case (I noticed that Steve Kent said in the
> meeting that we should not). This is where time below the second is
> important.

Why doesn't PKIX assign these efforts in a delegated manner to STime and
make the STime folks produce a schedule for "it". It seems to me that PKIX
is swelling to address the totality of the PKI enablement world, and you
know - this is likely to be appropriate. However my feeling is that PKIX
would be warrented in allowing other fledgling orgs like STime and its more
developed bretheren like the XML DigSig groups to offload some of the core
enablement at the application construct levels. PKI will be the forum where
these all come together in the IETF and to my mind that reinforces the
structure and the operations of the Security Area and its local Directorates
actions in the furtherance of the marketplace.

I see this as a big win potentially for the PKIX Chairs and the IETF as a
whole since it will mandate putting in place something thast defines IntraWG
processes to handle a "formal delegation" of responsibility.


Todd



Received: from www.meridianus.com (209.249.223.9.has.no.reverse [209.249.223.9] (may be forged)) by mail.proper.com (8.8.8/8.8.5) with ESMTP id HAA25602 for <[e-mail]>; Thu, 15 Jul 1999 07:32:00 -0700 (PDT)
Received: from PC1 by www.meridianus.com (8.8.8+Sun/SMI-SVR4) id IAA02858; Thu, 15 Jul 1999 08:27:46 -0700 (PDT)
Message-ID: <002301beced0$a363d1e0$[e-mail]>
From: "Todd S. Glassey" <[e-mail]>
To: "Michael Zolotarev" <[e-mail]>, "Denis Pinkas" <[e-mail]>
Cc: <[e-mail]>
References: <[e-mail]>
Subject: Re: When is Timestamp applied?
Date: Thu, 15 Jul 1999 07:45:09 -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 5.00.2918.2701
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2918.2701

----- Original Message -----
From: Michael Zolotarev <[e-mail]>
To: Denis Pinkas <[e-mail]>
Cc: <[e-mail]>
Sent: Thursday, July 15, 1999 4:23 AM
Subject: RE: When is Timestamp applied?


> Denis, Sean,
>
> Does a person who is not currently in Oslo have a right to say :)?
>
> From the practical point of view, I do not see much benefit in putting
extra detail into the stamp. What the time stamp is for? To provide an
evidence that a datum existed AT LEAST at certain time. This CERTAIN time is
just an astronomical time, which has no inherit reference to a particular
TSA's implementation.


> Just think about it: You've got a stamp, and it indicates one of your 3
cases - how do we interpret it?
> Case 1. The time was 12.34.56.789, and it is a time the request entered
the TSA box. Conclusion: the datum existed AT LEAST at that time.

No what this says is that the "counter that was running on the systems that
issued the stamp said the increment that this event happened at was
HH:MM:SS:HH".

The fact that we use a timebase style counter and that we have at some point
synchronized this counter with another counter that hold what we refer to as
a credible timesense, means that we as humans can interpret the context of
the counter as what we know as time.

What the system in question is about IMHO, is the remote issuance of an
event token that is refered to as a timestamp becuase the data in the token
that is used as the proof model is that counter-thing again... displaying
data in what we call "time format".

Becuase of this and that there is no local sense as to the validty of the
timebase under the system submitting the event for verification, the real
issue here is the latency in getting from the issuing body to the stamping
system. The proof model is then not relative to anyting that is in the
submitted token, if it happens to be accuirate, then all the better, but the
only binding part of the model is when the token is stamped at the "TSA"
system.

> Case 2. The time was 12.34.56.789, and it is a time the request was
processed by the crypto. > Conclusion:the datum existed AT LEAST at that
time. It may have also existed some fraction > of the seconds before. But
nobody can provide any reasonable estimate of it. And even more > important,
no serious verifier will accept it as a valid argument.

Yes this is exactly true!. The issue is that in an event logging model,
knowing what time the event got to the logger sets the "event proof time" as
that time. Not what time the event got to the event processing engine. That
is why we (both McNeil and I) have been standing on this soapbox about that
'Timestamping as a proofing model needs to be embedded in the system that
uses it' to have what we refer to as "the likely best level of legal
consequence"

BTW all - Can we use another word in these responses besides Datum, it
confuses the issues because of Datum Corp's entry into secure time.

> Case 3. ...existed AT LEAST .... The conclusion is the same as in 2.
>
> So, thinking practically, the flag may be not such a good thing.
>
> However, it may worth saying in the draft that "TSA should take all
possible care to ensure that the time indicated in the stamp is the earliest
possible time that TSA could practically apply to the message".
>

I propose that what is needed is a local model where the TSA style
technology is used in a vertical system, that is to say that the TS API as
defined by the current draft be amended so that it functions cleanly as an
embedded system as well as a distributed one.

My feeling is that if this were done that it would be possible to merge the
BERT token structures with the TSA model and get on with event logging as a
whole.

Todd




Received: from www.meridianus.com (209.249.223.21.has.no.reverse [209.249.223.21] (may be forged)) by mail.proper.com (8.8.8/8.8.5) with ESMTP id HAA25438 for <[e-mail]>; Thu, 15 Jul 1999 07:30:43 -0700 (PDT)
Received: from PC1 by www.meridianus.com (8.8.8+Sun/SMI-SVR4) id IAA02850; Thu, 15 Jul 1999 08:26:41 -0700 (PDT)
Message-ID: <002201beced0$7c17da50$[e-mail]>
From: "Todd S. Glassey" <[e-mail]>
To: <[e-mail]>, "Flanigan, Bill" <[e-mail]>
Cc: "'Michael Myers'" <[e-mail]>, <[e-mail]>
References: <852567AE.004F5990.00@LNOTES5>
Subject: Re: KISS for PKIX. (Was: RE: ASN.1 vs XML (used to be RE: I-D ACTION :draft-ietf-pkix-scvp- 00.txt))
Date: Thu, 15 Jul 1999 07:44:03 -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 5.00.2918.2701
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2918.2701

Actually made KISS is not quite the right issue. Before PKI technologines
can go mainstream, they need to be fully integrated as end user solutions.
Nothing less.

What this says is that anyone that intends to float a commercial product
around PKI needs to get it into enduser systems.

My feeling is that the win for PKI is in documents like the Roadmap and the
framework, that have end use figured into them.

Todd

----- Original Message -----
From: <[e-mail]>
To: Flanigan, Bill <[e-mail]>
Cc: 'Michael Myers' <[e-mail]>; <[e-mail]>
Sent: Wednesday, July 14, 1999 11:24 AM
Subject: Re: KISS for PKIX. (Was: RE: ASN.1 vs XML (used to be RE: I-D
ACTION :draft-ietf-pkix-scvp- 00.txt))


>
> >>Hello Mike,
> >>
> >>   You are on the right track (and so, I think, is Steve).  Before PKI
> >>technologies (and other IETF *core* security protocol suites) can be
> *main
> >>streamed,* they must be made very easy to use across the board--from
> >>implementers to developers to end (human) entities.  Some might object
to
> >>this as being *dumbed down,* but lack of interoperability due to overly
> >>complex and convoluted multi-protocols (not to mention competing
> protocols)
> >>is a real problem.  So is the resulting complexity of use experienced by
> EEs
> >>(I could write volumes here!).  Unless we aim for the *lowest common
> >>denominator,* CIOs will never be able to show ROIs to justify PKI (and
> >>especially the PKIX favor of PKI) purchases.  We have probably all read
> >>recent reports that Fortune 1,000 CEOs see IT, in general, and PKI, in
> >>particular, as simply drains on profits; and in the UK, companies don't
> seem
> >>to be interested in PKI (and especially the PKIX flavor of PKI) at all.
> As
> >>usual, KISS is the key (no pun intended).  I fear that we do not have
the
> >>luxury of tossing things over the fence to *let the market decide.*  The
> >>market may decide to pass.
> >>
> >>Bill
> >>
>
> I couldn't agree with you more. However, regarding acceptance of PKI
> technologies by large organizations, I believe there are many reasons
> organizations are not adopting PKI readily besides ease-of-use issues. Nor
> does it have anything to do with ASN.1 vs XML. This issue can't be
resolved
> with technology solutions because their lack of acceptance is not due
> solely to technical problems.
>




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 GAA24861 for <[e-mail]>; Thu, 15 Jul 1999 06:54:46 -0700 (PDT)
Received: from stingray.missi.ncsc.mil (root@localhost) by stingray.missi.ncsc.mil with ESMTP id JAA12221 for <[e-mail]>; Thu, 15 Jul 1999 09:56:08 -0400 (EDT)
Received: from missi.ncsc.mil (depot.missi.ncsc.mil [144.51.60.1]) by stingray.missi.ncsc.mil with ESMTP id JAA12217 for <[e-mail]>; Thu, 15 Jul 1999 09:56:07 -0400 (EDT)
Received: from ara.missi.ncsc.mil (ara.missi.ncsc.mil [144.51.58.9]) by missi.ncsc.mil (8.8.8/8.8.8) with ESMTP id JAA09793 for <[e-mail]>; Thu, 15 Jul 1999 09:56:06 -0400 (EDT)
Received: from ara.missi.ncsc.mil (ara.missi.ncsc.mil [144.51.58.9]) by ara.missi.ncsc.mil (8.9.1b+Sun/8.9.1) with SMTP id JAA03124 for <[e-mail]>; Thu, 15 Jul 1999 09:56:00 -0400 (EDT)
Message-Id: <[e-mail]>
Date: Thu, 15 Jul 1999 09:56:00 -0400 (EDT)
From: "David P. Kemp" <[e-mail]>
Reply-To: "David P. Kemp" <[e-mail]>
Subject: Re: IPSec device requirements from PKI server (DCS/CSVP/OCSP)
To: [e-mail]
MIME-Version: 1.0
Content-Type: TEXT/plain; charset=us-ascii
Content-MD5: 79LZ6kHFU2XnFioaiGtHdA==
X-Mailer: dtmail 1.3.0 CDE Version 1.3 SunOS 5.7 sun4u sparc

> From: Sara Bitan <[e-mail]>
> 
> I would like to verify the certificate within my IPsec implementation.
> One requirement I have from PKI server is to be able to produce a
> certificate chain from a given certificate to a trusted CA(s) I specify.
> 
> There are several reasons to this approach
> 1) I don't like the IPSec device to perform the trust path search and be
> able to support LDAP, HTTP or other retrieval protocols for this
> purpose. No trust is needed for the delegation of the search, assuming
> the certificates in the chain and the CRLs are to be trusted.
> 2) why not delegate the certificate verification to a PKI server?  I
> wouldn't trust anybody to verify the signature for me. An IPSec device
> has the public key technology (required for IKE), hence, it has the
> ability to verify the signature on the certificate.
> 3) a certificate verification server will not be aware of the list of
> CAs that the IPSec device doesn't trust. I wouldn't like to configure
> the certificate verification server with the list of trusted CAs for
> each security gateway and IPSec client.
> 4) efficiency reasons - if the IPSec device gets the certificate chain,
> it will be able to cache it and to use it (or parts of it) whenever it
> needs.  It will be able to save some of the queries to the PKI server.
> 
> Since I want the IPSec device to verify the certificate chain, I would
> also like the PKI server to be able to separate the revocation status
> from the trust path search. This way the IPSec device will be able to
> cache the certificate chain and just check the revocation status.
> 
> Regarding the certificate chain there is one problem that was raised.
> Suppose there are several chains leading from the peer's certificate to
> the trusted CA. Suppose some are legal and some are not. Which
> certificate chain should the PKI server return?

This sounds like a reasonable approach.  Given item 4 (the IPsec device
is capable of building a full chain from cached partial chains), there
doesn't appear to be a problem.  If the PKI server forms several valid
chains rather than stopping when the first is found, it could return
the union of the certs contained in all the chains and the device could
construct whichever path it wanted from among the pile of certs in the
cache.

If the device doesn't trust the PKI server (item 2), then it must
validate the chain itself.  Therefore, except for cache overflows, it
doesn't matter in principle whether the PKI server returns all certs in
all chains, all certs in all valid chains, or just the certs in the
first valid chain it finds.   In practice, since the PKI server must
attempt to send at least one valid chain to the device in a finite
amount of time, it may wish to do some chain validation checks in order
to prune the search space.



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 GAA24558 for <[e-mail]>; Thu, 15 Jul 1999 06:37:25 -0700 (PDT)
Received: from mentat.verisign.com by caladan.verisign.com (8.8.5/BCH1.5) id GAA28721; Thu, 15 Jul 1999 06:37:03 -0700 (PDT)
Received: from newman.verisign.com by mentat.verisign.com (8.8.5/BCH1.0) id GAA00188; Thu, 15 Jul 1999 06:38:14 -0700 (PDT)
Received: by newman.verisign.com with Internet Mail Service (5.5.2448.0) id <N7XWFQ71>; Thu, 15 Jul 1999 06:38:16 -0700
Message-ID: <[e-mail]>
From: Michael Myers <[e-mail]>
To: IETF PKIX list <[e-mail]>
Subject: SCVP Analysis
Date: Thu, 15 Jul 1999 06:38:14 -0700
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2448.0)
Content-Type: text/plain; charset="iso-8859-1"

All,

The SCVP draft raises some interesting questions which deserve discussion on
the list.  Below are some thoughts to get that started.  Having gone through
this process, it's very clear to me at least that needs for delegated path
validation can more easily be met with a very simple extension to OCSP.  The
work would be very minimal compared to implementing a totally different
protocol to do exactly the same thing.

Mike


REQUEST SYNTAX AND SEMANTICS


1.  Optional use of a RequestHash  in lieu of a digitally signed request.
----------------------------------------------------------------------
The need to integrity-protect the request hasn't been established.  How is
this request-response protocol different from, say, LDAP?

It seems that requestHash is actually presumed to be sufficient for the
non-repudiation needs of accountability in some environments.  If so, this
needs to be made explicit and-more importantly-discussed on the list as such
a resolution impacts assumptions underlying current trade in certificate
validation services.

If however the authors assert that the requestHash field is unreliable for
service accountability and is meant rather simply as an integrity check, the
requirement for integrity protection equally merits discussion of the
security risks being addressed.  Perhaps the authors have some insight into
security risks that were overlooked in prior PKIX protocols now standing as
RFCs.

Should that discussion conclude that the request syntaxes of PKIX protocols
need to be integrity protected, it seems we may need to amend the
request-response protocols PKIX has currently sent up to IESG which do not
provide such protection.

Should that discussion otherwise conclude that certificate validation
protocols are unique among other protocols in their need for integrity
protected requests, at a minimum this may affect RFC 2560 (OCSP), which
bears a striking architectural similarity to the proposed protocol.

In the absence of resolution of either of these positions, the functionality
seems superfluous.



2.  Explicit specification of a request being a path validation request vs.
a revocation status check.
----------------------------------------------------------------------
The proposed BIT STRING construct fails to adequately accommodate future
evolution of the semantics of certificate validation.

In a more general framework, one could specify request types using OID-based
extensions as we do today with X.509, and as currently established by RFC
2560 (OCSP).



3.  Optional inclusion of the subject certificate in the request.
----------------------------------------------------------------
This seems to be a reasonable requirement.



4.  Optional support for PGP style public key management.
----------------------------------------------------------------
As discussed on the floor in Oslo, inclusion of this functionality would
require a revision to the PKIX charter.  PKIX was specifically established
to address X.509 certificates.



5.  Optional request for the value of subject public key, subject name,
certificate chain or revocation proof.
----------------------------------------------------------------
If it is the objective of the proposed protocol to fully delegate path
validation to an external server, then this functionality isn't in line with
that model.  This looks more like a lightweight data access protocol. 

Further, requests for the public key and subject name seems odd against the
prior capability to include the certificate in the request, which obviously
assumes the requester has the certificate.

So in this instance the server is acting like a remote certificate parser.
If that's indeed the authors' intent, then the proposed functionality is
incomplete.  For completeness, they should consider remotely parsed access
to:  subject alt name extension for IPSEC; certificate policy values for the
policy engines; subject directory attributes for environments using that
extension.

We have three system level-functions being addressed by this protocol:

1.  Fully delegated path validation;
2.  Lightweight PKI data access; and
3.  Remote certificate parsing.

The need for the first capability has been fairly obvious for years.  The
latter two are of questionable value, with perhaps the exception of
returning back the intermediate chain.


6.  Optional specification of intermediate certificates to use as a
supplement to the validation path of the subject certificate.
----------------------------------------------------------------
In the context of the legal framework underpinning the use of certificates
for electronic commerce, the issuer of a certificate issued that certificate
with a very specific trust chain model in mind.

The proposed functionality seems to suggest that the authors are asking PKIX
to support the notion of the "re-purposing" of certificates for uses beyond
those intended by the original issuer.

Was this the authors' intent?  If not, then what problem is this proposed
functionality solving?


7.  Optional specification of trusted roots the server must rely on.
----------------------------------------------------------------
Same issue as above.

Is it the authors' proposition that the issuer of a certificate is *not* the
final arbiter of the trustworthiness of that certificate?  (noting that
"issuer" could be an entity that directs another entity to manufacture and
distribute a certificate on its behalf).


8.  Optional configuration identifier that points to a pre-defined set of
the above options.
----------------------------------------------------------------
This seems to be a reasonable requirement.


9.  Extensions may be critical or non-critical.
----------------------------------------------------------------
Recent experience has shown that this is inadvisable.  The XML DigSig group,
for example, has specifically deprecated proposed use of critical flags for
well-known reasons.



RESPONSE SYNTAX AND SEMANTICS

10.  "Unrecognized" error codes related to the above optional request
protocol elements.
----------------------------------------------------------------
No issues, other than alignment with the prior analysis.


11.  Validation response values for "valid", "notValid",
"temporarilyUnknown" and "unknown".
----------------------------------------------------------------
This seems to be a reasonable requirement.

Except perhaps for "temporarilyUnknown".  What does a client do with that?


12.  Optional inclusion of an errorMessage text string
----------------------------------------------------------------
This seems to be a reasonable requirement.


13.  Optional inclusion of subject public key value, subject name or path
validation chain, consistent with prior request.
----------------------------------------------------------------
See point #5 above.


14.  Optional inclusion of requestHash appearing in request.
----------------------------------------------------------------
See point #1 above.


15.  Optional inclusion of revocation proof content.
----------------------------------------------------------------
See point #5 above.


16.  Optional use of a digital signature
----------------------------------------------------------------
This is the same as OCSP: some error conditions don't need to be signed.
However, the proposed protocol goes on to assert that other types of
responses don't need to be signed if conveyed over a secure channel.

An optional signature on an affirmative response is equivalent to an
unsigned CRL.  It can't be used to support non-repudiation.





Received: from www.paichai.ac.kr (www.paichai.ac.kr [203.250.129.140]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id EAA23340; Thu, 15 Jul 1999 04:55:06 -0700 (PDT)
From: [e-mail]
Received: from Dream06 ([210.109.3.6]) by www.paichai.ac.kr (8.8.8H1/8.8.8) with SMTP id UAA11777; Thu, 15 Jul 1999 20:38:06 +0900 (KST)
Message-Id: <[e-mail]>
Date: Fri, 16 Jul 99 17:30:47 =?EUC-KR?B?tOvH0bnOsbk=?= =?EUC-KR?B?x6XB2L3D?=
To: <[e-mail]>, <[e-mail]>, <[e-mail]>, <[e-mail]>, <[e-mail]>, <[e-mail]>, <[e-mail]>, <[e-mail]>, <[e-mail]>, <[e-mail]>, <[e-mail]>, <[e-mail]>, <[e-mail]>, <[e-mail]>, <[e-mail]>, <[e-mail]>, <[e-mail]>, <[e-mail]>, <[e-mail]>, <[e-mail]>, <[e-mail]>, <[e-mail]>, <[e-mail]>, <[e-mail]>, <[e-mail]>, <[e-mail]>, <[e-mail]>, <[e-mail]>, <[e-mail]>, <[e-mail]>
Subject: =?EUC-KR?B?vsa3obim?= =?EUC-KR?B?x9G5+A==?= =?EUC-KR?B?wvyw7cfYuri8vL+p?=.=?EUC-KR?B?sKHA1LXO?= =?EUC-KR?B?vay/9r/k?=~~
X-Mailer: ad2000 <45>

Àú´Â ¿äÁò Nomoney.co.krÀ̶ó´Â °÷¿¡ °¡ÀÔÇÏ¿´½À´Ï´Ù.
°¡ÀÔÈÄ ¹è³Ê¹Ù¶ó´Â ÇÁ·Î±×·¥À» ´Ù¿î¹ÞÀ» ¼ö ÀÖ½À´Ï´Ù.
ÀÌ ¹è³Ê¹Ù¶ó´Â ÇÁ·Î±×·¥Àº ÇѸ¶µð·Î µ·ÁÖ´Â ÇÁ·Î±×·¥ÀÔ´Ï´Ù.
Æò¼Ò´ë·Î ÀÎÅͳÝÀ» »ç¿ëÇϸ鼭 ÀÌ ¹è³Ê¹Ù ÇÁ·Î±×·¥¸¸ ½ÇÇà½ÃÄÑ ³õÀ¸¸é
¹è³Ê¹Ù¿¡¼­ °è¼ÓÇÏ¿© µ·À» Àû¸³½ÃÄÑ µå¸³´Ï´Ù.
´õ¿í´õ ½Å±âÇÑ °ÍÀº ÀͽºÇ÷η¯³ª ³×½ºÄÉÀÌÇÁ°¡ ¾Æ´Ñ ÇѱÛÀ̳ª ¿¢¼¿,
½ÉÁö¾î °ÔÀÓÁß¿¡µµ ÀÌ ÇÁ·Î±×·¥À» ¶ç¿ï ¼ö ÀÖ°í ¶ç¿ì±â¸¸ ÇÏ¸é µ·À» ÁشٴÂ
°Ì´Ï´Ù.
³ë¸Ó´Ï¿¡¼­´Â Ǭµ·À» ¹ú±âº¸´Ù´Â Çѹø¿¡ µ·À» ¿Õâ ¹ú°í ½ÍÀº »ç¶÷À» À§ÇÑ
¼­ºñ½ºµµ ÁغñÇØ ³õ¾Ò½À´Ï´Ù.
ÀÏÁ¾ÀÇ ÀÎÅÍ³Ý ±¤°íº¹±ÇÀ̶ó´Â °ÍÀε¥, ¸ÅÀÏ º¹±Ç´ç÷ÀÚ°¡ ³ª¿É´Ï´Ù.
Çѹø³ª¿À¸é 100¸¸¿ø ÀÌ»ó ÅÍÁý´Ï´Ù. ÀÌ ÀÎÅÍ³Ý ±¤°íº¹±Çµµ ´ÜÁö ¹è³Ê¹Ù¶ó´Â
ÇÁ·Î±×·¥¸¸À» ¶Ù¿ö ³õÀ¸½Ã¸é Âü¿© ÇϽǼö ÀÖ½À´Ï´Ù.
³ë¸Ó´Ï¿¡¼­ µ·º­¶ôÀ» ¸ÂÀ¸¼¼¿ä.
°¡½Ã´Â ¹æ¹ýÀº http://www.nomoney.co.kr/fid.asp?fid=comdari(ÀÚ½ÅÀÇ ¾ÆÀ̵ð
ºÎºÐ¿¡
È«º¸ÇÏ´Â ºÐ ¾ÆÀ̵𠸦 ÀûÀ¸½Ã¸é ÀÌ ±ÛÀ» ÀÐ°í µé¾î¿À½Ã´Â ºÐÀº ¹«Á¶°Ç
"ÀÚ½ÅÀǾÆÀ̵ð"¿¡
ÀûÈù ¾ÆÀ̵𸦠ÃßõÇÏ°Ô µË´Ï´Ù)·Î °¡¼Å¼­ Á÷Á¢ È®ÀÎÇϼ¼¿ä.

Çѹø °¡º¸¼¼¿ä.´©°¡ ¾Ë¾Æ¿© Çö±Ý 100¸¶³Í ¹ú°ÔµÉÂî~



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 EAA22913 for <[e-mail]>; Thu, 15 Jul 1999 04:25:46 -0700 (PDT)
Received: from sydneymail1.baltimore.com.au (sydneymail1.jp.zergo.com.au [192.168.71.5]) by stargate.zergo.com.au (8.9.1/8.8.7) with ESMTP id VAA15926; Thu, 15 Jul 1999 21:28:54 +1000
Received: by sydneymail1.jp.zergo.com.au with Internet Mail Service (5.5.2448.0) id <37XTVYS6>; Thu, 15 Jul 1999 21:23:31 +1000
Message-ID: <[e-mail]>
From: Michael Zolotarev <[e-mail]>
To: Denis Pinkas <[e-mail]>
Cc: [e-mail]
Subject: RE: When is Timestamp applied?
Date: Thu, 15 Jul 1999 21:23:30 +1000
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2448.0)
Content-Type: text/plain; charset="iso-8859-1"

Denis, Sean,

Does a person who is not currently in Oslo have a right to say :)?

>From the practical point of view, I do not see much benefit in putting extra detail into the stamp. What the time stamp is for? To provide an evidence that a datum existed AT LEAST at certain time. This CERTAIN time is just an astronomical time, which has no inherit reference to a particular TSA's implementation.
Just think about it: You've got a stamp, and it indicates one of your 3 cases - how do we interpret it?
Case 1. The time was 12.34.56.789, and it is a time the request entered the TSA box. Conclusion: the datum existed AT LEAST at that time.
Case 2. The time was 12.34.56.789, and it is a time the request was processed by the crypto. Conclusion:the datum existed AT LEAST at that time. It may have also existed some fraction of the seconds before. But nobody can provide any reasonable estimate of it. And even more important, no serious verifier will accept it as a valid argument.
Case 3. ...existed AT LEAST .... The conclusion is the same as in 2.

So, thinking practically, the flag may be not such a good thing.

However, it may worth saying in the draft that "TSA should take all possible care to ensure that the time indicated in the stamp is the earliest possible time that TSA could practically apply to the message".

-----Original Message-----
From: Denis Pinkas [mailto:[e-mail]]
Sent: Thursday, July 15, 1999 7:42 PM
To: Sean Turner
Cc: [e-mail]
Subject: Re: When is Timestamp applied?


Sean,

You are perfectly right, we need to say more in the document. Since the
protocol is transport independent but the time between the request and the
response is transport dependent, we need to indicate in the TST some
information to say whether the time is:

1) the time of reception of the request by the TSA,
2) the time when the request was entered/processed in the crypto engine of
the TSA,
3) the time which is en the request left the crypto engine of the TSA (if
the signature time can be estimated, then the signature time may be
anticipated).

Case 1. This case is relevant to smtp and ftp, where all the requests will
be time stamped according to the SAME date of reception.

Case 2. This case is relevant to sockets and HTTP, when there is a single or
few requests.

Case 3. This case is mostly relevant when the requester indeed is not
interrested in a time stamp, but by a signed time only. Under that
circumstance the time in the TST will be the closest to the time of the
response.

Since the STIME working group wanted to address this concern but was told
during their meeting that signed time will be addressed by PKIX, it would
make sense that we cover that case (I noticed that Steve Kent said in the
meeting that we should not). This is where time below the second is
important.

When there is no hash present in the response we could assume that the last
case applied. However, this would impose a specific implementation. I would
rather allow some kind of flexibility and RECOMMEND to allow the TSA to
indicate which case applies. The main reason is that in any case it is
simpler for an implementation to provide the case 2, i.e. the time when the
request was entered/processed in the crypto engine.

So the proposal would be to include a flag that would say which of the three
cases has been used by the TSA

The next question is then : should the requester be able to request which
case he would like to be supported ?
I would like to avoid this and thus not add any new parameter in the
request.

Instead I would rather RECOMMEND what the TSA SHOULD do for every case of
transport keeping in mind that it can use whatever scheme he likes, in
particular the case 2.

The proposal is thus :

1) to recommend for every transport which of the three cases should be used,

2) to recommend when there is no hash present in the request to use case 3,
3) to allow the TSA to include a flag (taking the values 0, 1 and 2) stating
to which instant the time of time stamping applies.

If there is some consensus around this proposal, I will then propose an ASN1
translation of it, along which new text.

Regards,

Denis


> Denis,
>
> At the meeting today you mentioned that the draft doesn't specify when
> the timestamp is applied, either when the data was received or when the
> signature was applied.  BUt, the slides you threw up from the ISO text
> clearly indicated that the timestamp is applied when the signature is
> generated.  I think the draft should either
> - specify that the time in the timesatamp is the TSA's signture time or
> - there should be field included (a choice) to indicate that the time is
> when the data was received or when the TSA's signature was generated.
>
> Otherwise, the meaning of the timestamp is very ambiguious.
>
> spt


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 CAA19493 for <[e-mail]>; Thu, 15 Jul 1999 02:40:49 -0700 (PDT)
Received: from bull.net (frcls6118.frcl.bull.fr [129.182.109.213]) by clbull.frcl.bull.fr (8.9.1a/8.9.1) with ESMTP id LAA12940; Thu, 15 Jul 1999 11:34:53 +0200
Message-ID: <[e-mail]>
Date: Thu, 15 Jul 1999 11:41:49 +0200
From: Denis Pinkas <[e-mail]>
Organization: Bull
X-Mailer: Mozilla 4.06 [fr] (Win95; I)
MIME-Version: 1.0
To: Sean Turner <[e-mail]>
CC: [e-mail]
Subject: Re: When is Timestamp applied?
References: <[e-mail]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit

Sean,

You are perfectly right, we need to say more in the document. Since the
protocol is transport independent but the time between the request and the
response is transport dependent, we need to indicate in the TST some
information to say whether the time is:

1) the time of reception of the request by the TSA,
2) the time when the request was entered/processed in the crypto engine of
the TSA,
3) the time which is en the request left the crypto engine of the TSA (if
the signature time can be estimated, then the signature time may be
anticipated).

Case 1. This case is relevant to smtp and ftp, where all the requests will
be time stamped according to the SAME date of reception.

Case 2. This case is relevant to sockets and HTTP, when there is a single or
few requests.

Case 3. This case is mostly relevant when the requester indeed is not
interrested in a time stamp, but by a signed time only. Under that
circumstance the time in the TST will be the closest to the time of the
response.

Since the STIME working group wanted to address this concern but was told
during their meeting that signed time will be addressed by PKIX, it would
make sense that we cover that case (I noticed that Steve Kent said in the
meeting that we should not). This is where time below the second is
important.

When there is no hash present in the response we could assume that the last
case applied. However, this would impose a specific implementation. I would
rather allow some kind of flexibility and RECOMMEND to allow the TSA to
indicate which case applies. The main reason is that in any case it is
simpler for an implementation to provide the case 2, i.e. the time when the
request was entered/processed in the crypto engine.

So the proposal would be to include a flag that would say which of the three
cases has been used by the TSA

The next question is then : should the requester be able to request which
case he would like to be supported ?
I would like to avoid this and thus not add any new parameter in the
request.

Instead I would rather RECOMMEND what the TSA SHOULD do for every case of
transport keeping in mind that it can use whatever scheme he likes, in
particular the case 2.

The proposal is thus :

1) to recommend for every transport which of the three cases should be used,

2) to recommend when there is no hash present in the request to use case 3,
3) to allow the TSA to include a flag (taking the values 0, 1 and 2) stating
to which instant the time of time stamping applies.

If there is some consensus around this proposal, I will then propose an ASN1
translation of it, along which new text.

Regards,

Denis


> Denis,
>
> At the meeting today you mentioned that the draft doesn't specify when
> the timestamp is applied, either when the data was received or when the
> signature was applied.  BUt, the slides you threw up from the ISO text
> clearly indicated that the timestamp is applied when the signature is
> generated.  I think the draft should either
> - specify that the time in the timesatamp is the TSA's signture time or
> - there should be field included (a choice) to indicate that the time is
> when the data was received or when the TSA's signature was generated.
>
> Otherwise, the meaning of the timestamp is very ambiguious.
>
> spt



Received: from romulus.ncsc.mil (romulus.ncsc.mil [144.51.5.2]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id SAA17898 for <[e-mail]>; Wed, 14 Jul 1999 18:24:15 -0700 (PDT)
Received: from aeneas (e06.ncsc.mil [144.51.101.134]) by romulus.ncsc.mil (8.9.1/8.9.1) with SMTP id VAA03543; Wed, 14 Jul 1999 21:25:25 -0400 (EDT)
Message-ID: <000c01bece5d$e43dfa60$86653390@aeneas>
Reply-To: "Mark Ciccarello" <[e-mail]>
From: "Mark Ciccarello" <[e-mail]>
To: "Flanigan, Bill" <[e-mail]>, "'Michael Myers'" <[e-mail]>
Cc: <[e-mail]>
Subject: Re: KISS for PKIX.  (Was: RE: ASN.1 vs XML (used to be RE: I-D ACTION:draft-ietf-pkix-scvp- 00.txt))
Date: Wed, 14 Jul 1999 21:03:14 -0400
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 4.72.2106.4
X-MimeOLE: Produced By Microsoft MimeOLE V4.72.2106.4

Hello Bill

I'd like to endorse your message and the previous one ("average user").

The realities you allude to have profound implications as to what type
of PKIs can successfully be deployed and effectively utilized inside a
large organization.  I do not think this is a problem peculiar to
"government" organizations.

[My own personal views, but I could add to your volumes]

Mark Ciccarello
-----Original Message-----
From: Flanigan, Bill <[e-mail]>
To: 'Michael Myers' <[e-mail]>
Cc: '[e-mail]' <[e-mail]>
Date: Wednesday, July 14, 1999 9:03 AM
Subject: KISS for PKIX. (Was: RE: ASN.1 vs XML (used to be RE: I-D
ACTION:draft-ietf-pkix-scvp- 00.txt))


>Hello Mike,
>
> You are on the right track (and so, I think, is Steve).  Before PKI
>technologies (and other IETF *core* security protocol suites) can be *main
>streamed,* they must be made very easy to use across the board--from
>implementers to developers to end (human) entities.  Some might object to
>this as being *dumbed down,* but lack of interoperability due to overly
>complex and convoluted multi-protocols (not to mention competing protocols)
>is a real problem.  So is the resulting complexity of use experienced by
EEs
>(I could write volumes here!).  Unless we aim for the *lowest common
>denominator,* CIOs will never be able to show ROIs to justify PKI (and
>especially the PKIX favor of PKI) purchases.  We have probably all read
>recent reports that Fortune 1,000 CEOs see IT, in general, and PKI, in
>particular, as simply drains on profits; and in the UK, companies don't
seem
>to be interested in PKI (and especially the PKIX flavor of PKI) at all.  As
>usual, KISS is the key (no pun intended).  I fear that we do not have the
>luxury of tossing things over the fence to *let the market decide.*  The
>market may decide to pass.
>
>Bill
>
>> ----------
>> From: Michael Myers[SMTP:[e-mail]]
>> Sent: Tuesday, July 13, 1999 9:29 PM
>> To: 'Stephen Kent'; Anders Rundgren
>> Cc: 'Peter Sylvester'; '[e-mail]'
>> Subject: RE: ASN.1 vs XML (used to be RE: I-D
>> ACTION:draft-ietf-pkix-scvp- 00.txt)
>>
>> Steve,
>>
>> I'll probably bring this point to your attention on the floor before you
>> read this email, but for the record (and further, for the benefit of
those
>> unable to attend the Oslo session), I would claim that making PKI easy
for
>> developers is a very good thing.  Your comment belows seems to modestly
>> suggest that such an objective is less worthy than it might ought to be.
>>
>> Indeed, this principle was the primary motivation for OCSP's original
>> non-ASN.1 proposal.
>>
>> Mike
>>
>>
>>
>> > -----Original Message-----
>> > From: Stephen Kent [mailto:[e-mail]]
>> > Sent: Tuesday, July 13, 1999 12:28 AM
>> > To: Anders Rundgren
>> > Cc: 'Peter Sylvester'; '[e-mail]'
>> > Subject: RE: ASN.1 vs XML (used to be RE: I-D
>> > ACTION:draft-ietf-pkix-scvp-00.txt)
>> >
>> >
>> > Anders,
>> >
>> >
>> > >The important thing is that in order to make PKI a
>> > main-stream technology
>> > >(which it is
>> > >not today), may require changes like going to XML as XML is likely to
>> > >at least replace EDI which is often used in the same contexts as
>> > >certificates (or
>> > >rather should be).  So if XML becomes the HTML (which is closer to a
>> > >"peoples movement" than a computer language) of business
>> > messages, ASN.1
>> > >may be too obscure (few know it) and less satisfactory as a long-term
>> > >solution.
>> > >
>> > >This should be seen in the light of the fact that the only
>> > main-stream
>> > >PKI-application
>> > >I can think about, is e-commerce.  As very few e-commerce
>> > standards are ready
>> > >for prime time, there is plenty of room for new things.
>> >
>> > There seems to be an implication here that mainstream users
>> > want to be able
>> > to read the signed data in its native format, and thus XML encoding is
>> > preferable to DER.  But we know this is not true, i.e.,
>> > whatever has been
>> > signed will be decoded prior to display, and then rendered
>> > for the user.
>> > So, it would seem that the use of an encoding scheme such as
>> > XML would be
>> > more attractive for developers performing debugging, rather
>> > than for users.
>> >
>> > Steve
>> >
>>
>



Received: from localhost (daemon@localhost) by mail.proper.com (8.8.8/8.8.5) with SMTP id HAA24349; Wed, 14 Jul 1999 07:12:17 -0700 (PDT)
Received: by mail.imc.org (bulk_mailer v1.12); Wed, 14 Jul 1999 07:12:16 -0700
Received: from barbar.esat.kuleuven.ac.be ([e-mail] [134.58.56.153]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id HAA24215; Wed, 14 Jul 1999 07:09:55 -0700 (PDT)
Received: from domein.esat.kuleuven.ac.be ([e-mail] [134.58.189.69]) by barbar (version 8.8.5)  with ESMTP id QAA04539; Wed, 14 Jul 1999 16:10:32 +0200 (METDST)
Organization: ESAT, K.U.Leuven, Belgium
Date: Wed, 14 Jul 1999 16:10:30 +0200 (METDST)
From: "CMS'99" <[e-mail]>
To: Communications and Multimedia Security 1999 <[e-mail]>
Subject: CMS'99 - Communications and Multimedia Security
Message-ID: <[e-mail]>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=X-UNKNOWN
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from QUOTED-PRINTABLE to 8bit by mail.proper.com id HAB24220
Precedence: bulk
List-Archive: http://www.imc.org/ietf-pkix/mail-archive/
List-Unsubscribe: mailto:[e-mail]?body=unsubscribe
X-UIDL: 420fafb5f113e0d6523a286c13dce3a8

[apologies if you receive this mail multiple times]


Communications and Multimedia Security is a joint working conference
of IFIP TC6 and TC11.

CMS'99 will be organized September 20-21, 1999
at the Katholieke Universiteit Leuven, Belgium.

On-line registration can be done at
http://www.esat.kuleuven.ac.be/cosic/cms99/

Reduced fee of 250 EURO until August 1, 1999.


Draft program:

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

Monday, September 20

  8u00-8u45 Registration

  8u45-9u00 Welcome

  9u00-10u30 Network security: ATM and ISDN

    Security On ATM Networks 
    Stelios Karanastasis, Ahmed Patel 

    ISDN Security Services 
    Herbert Leitold, Karl Christian Posch, Reinhard Posch 

    An Alternative Access Control Architecture for IP over ATM Networks 
    Olivier Paul, Maryline Laurent 

  10u30-10u50 Coffee

  10u50-11u50 Applied Cryptology I

    Verifiable Democracy 
    Yvo Desmedt, Brian King 

    Efficient Oblivious Proofs of Correct Exponentiation 
    Markus Jakobsson, Claus Peter Schnorr 

  11u50-13u30  Lunch

  13u30-14u30  Invited talk (to be announced)

  14u30-15u30 Entity Authentication and Key Agreement Protocols

    Weaknesses in EHA Authentication and Key Distribution Protocol 
    Martin Stanek, Daniel Olejár 

    Formal Design of Efficient Authentication and Key-Agreement
Protocols 
    Gunnar Jacobson 

  15u30-16u00 Coffee

  16u00-17u30 Network security: IP

    Protecting Key Exchange and Management Protocols Against Resource
Clogging Attacks 
    Rolf Oppliger 

    Secured Distributed Virtual Conferencing 
    W.A. Adamson, C.J. Antonelli, K.W. Coffman, P. McDaniel, J. Rees 

    PIM-SM Security: Interdomain Issues and Solutions 
    Thomas Hardjono, Brad Cain 

  17u30-18u00 Recent results

  19u30 Banquet

Tuesday, September 21

  8:30-10u00 Protocols for Mobile Applications

    Attacks against the WAP WTLS protocol 
    Markku-Juhani Saarinen 

    A New Authentication Protocol for Portable Communication Systems 
    Sheng-bo Xu, Cees Jansen, Henk van Tilborg 

    Token Based Authentication for Handover Security 
    Yi Cheng, Arne Norefors 

  10u00-10u30 Coffee Break

  10u30-12u00 Applications

    On Authentication, Digital Signatures and Signature Laws 
    Per Kaijser 

    Watermarking and Secure Distribution for Encrypted Video 
    T. Amornraksa, D.R.B. Burgess, P. Sweeney 

    Implementing a Secure Log File Download Manager for the Java Card 
    Constantinos Markantonakis, Simeon Xenitellis 

  12u00-14u00 Lunch

  14u00-15u30 Applied Cryptology II

    How to Securely Broadcast a Secret 
    Jörg Schwenk 

    Proofs of Work and Bread Pudding Protocols 
    Markus Jakobsson, Ari Juels 

    Attack on Liu/Farrel/Boyd Arithmetic Coding Encryption Scheme 
    Takeyuki Uehara, Reihaneh Safavi-Naini 

  15u30-16u00 Coffee

  16u00-17u00 Web security

    Secure Data-Transfer for Web-Based Applications 
    Wolfgang Platzer 

    Using SESAME to Secure Web Based Applications on an Intranet 
    Paul Ashley, Mark Vandenwauver, Joris Claessens 

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



Received: from localhost (daemon@localhost) by mail.proper.com (8.8.8/8.8.5) with SMTP id HAA24838; Wed, 14 Jul 1999 07:20:24 -0700 (PDT)
Received: by mail.imc.org (bulk_mailer v1.12); Wed, 14 Jul 1999 07:19:03 -0700
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 HAA24758 for <[e-mail]>; Wed, 14 Jul 1999 07:19:03 -0700 (PDT)
Received: from stingray.missi.ncsc.mil (root@localhost) by stingray.missi.ncsc.mil with ESMTP id KAA08396 for <[e-mail]>; Wed, 14 Jul 1999 10:20:19 -0400 (EDT)
Received: from missi.ncsc.mil (depot.missi.ncsc.mil [144.51.60.1]) by stingray.missi.ncsc.mil with ESMTP id KAA08391 for <[e-mail]>; Wed, 14 Jul 1999 10:20:18 -0400 (EDT)
Received: from ara.missi.ncsc.mil (ara.missi.ncsc.mil [144.51.58.9]) by missi.ncsc.mil (8.8.8/8.8.8) with ESMTP id KAA28524 for <[e-mail]>; Wed, 14 Jul 1999 10:20:19 -0400 (EDT)
Received: from ara.missi.ncsc.mil (ara.missi.ncsc.mil [144.51.58.9]) by ara.missi.ncsc.mil (8.9.1b+Sun/8.9.1) with SMTP id KAA02640 for <[e-mail]>; Wed, 14 Jul 1999 10:20:14 -0400 (EDT)
Message-Id: <[e-mail]>
Date: Wed, 14 Jul 1999 10:20:14 -0400 (EDT)
From: "David P. Kemp" <[e-mail]>
Reply-To: "David P. Kemp" <[e-mail]>
Subject: ASN.1 vs XML (was Re: I-D ACTION:draft-ietf-pkix-scvp-00.txt)
To: [e-mail]
MIME-Version: 1.0
Content-Type: TEXT/plain; charset=us-ascii
Content-MD5: N8CcKmI5X5Ny829O0y8G9g==
X-Mailer: dtmail 1.3.0 CDE Version 1.3 SunOS 5.7 sun4u sparc 
Precedence: bulk
List-Archive: http://www.imc.org/ietf-pkix/mail-archive/
List-Unsubscribe: mailto:[e-mail]?body=unsubscribe
X-UIDL: 5de66aff136627277889e75247c3b4e4

> From: Stephen Kent <[e-mail]>
>
>  I do disparge the notion that
> standards are established by distributed software.

I agree with that, and disagree particularly with the notion that
standards or profiles should be modified to accommodate deficiencies
in widely-used software.


> As the CTO of a CA product developer I can and do take exception with the
> suggestion that use of SSLeay is relevant to core CA business.  We
> developed our own ASN.1 compiler years ago, even sold it to some folks, and
> have not found it necessary to avail ourselves of freeware.

That is a reasonable position for the CTO of a company with deep and
longstanding expertise to take.  However, I agree with Mike Myers that
the IETF should make its standards accessible to the other 99% of us.
The "Running code" in the IETF motto applies most strongly to
running code for which source is available.

But whereas Mike believes the proper approach is to dummy-down the
syntax, I believe the proper approach is to smarten-up the developers.
SSLeay (which supports TLS, but predated it, hence the name) is a
valuable resource for developers.  The S/MIME Freeware Library, the
OpenLDAP BER library, and the zillions of SNMP books with code
mentioned by Peter are all educational materials available to
developers who would like to use ASN.1 but are put off by the
difficulty of either learning from scratch or purchasing expensive
expertise.

My own small attempt at protocol design, a digital-signature based
equivalent of S/KEY written up in a series of I-Ds several years ago,
used a yacc grammar as the syntax expression language because I
believed the buzz that ASN.1 is "too hard" or "too OSI" for the IETF.
Today, if there were still a need for such a protocol, I wouldn't
hesitate to specify and implement it in ASN.1, perhaps constrained to
the LDAP-supported subset.

Carl Ellison is correct when he claims that the worst feature of ASN.1
is that it enables (in the pejorative psychobabble sense: "you're
enabling this destructive behavior") protocol committees to lard their
designs with complex features.  Complex functionality requires complex
syntax, but when the only examples of ASN.1 people see are big and
incomprehensible, they get the impression that the language is the
cause of the incomprehensibility.  A counterexample - a simple protocol
expressed in a simple subset of ASN.1 with a simple reference
implementation, would both help dispell that impression and widen the
pool of expertise.  You have to start somewhere.



Received: from localhost (daemon@localhost) by mail.proper.com (8.8.8/8.8.5) with SMTP id HAA23837; Wed, 14 Jul 1999 07:04:00 -0700 (PDT)
Received: by mail.imc.org (bulk_mailer v1.12); Wed, 14 Jul 1999 07:03:57 -0700
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 HAA23814 for <[e-mail]>; Wed, 14 Jul 1999 07:03:55 -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 CAA03251 for <[e-mail]>; Thu, 15 Jul 1999 02:05:08 +1200 (NZST) (sender [e-mail])
Received: by cs26.cs.auckland.ac.nz (relaymail v0.9) id <93196110808894>; Thu, 15 Jul 1999 02:05:08 (NZST)
From: [e-mail] (Peter Gutmann)
To: [e-mail]
Subject: Re: I-D ACTION:draft-ietf-pkix-scvp-00.txt
Sender: [e-mail]
Reply-To: [e-mail]
X-Charge-To: pgut001
X-Authenticated: relaymail v0.9 on cs26.cs.auckland.ac.nz
Date: Thu, 15 Jul 1999 02:05:08 (NZST)
Message-ID: <[e-mail]>
Precedence: bulk
List-Archive: http://www.imc.org/ietf-pkix/mail-archive/
List-Unsubscribe: mailto:[e-mail]?body=unsubscribe
X-UIDL: 4d0de430f2515cbab616001b098e22ec

Stephen Kent <[e-mail]> writes:

>Your sample may not be too representative, especially with respect to the 
>topic at hand.  Do you know what products were used to generate the certs?

I many cases I could guess based on the encoding bugs present (certain products
leave a signature (in the non-crypto sense) on the certs they generate based on
encoding bugs), in others it wasn't possible to tell.  I would hope the sample 
was representative of what's out there, the whole point of grabbing a random
sample of publicly-available certs was to test what was being used in the real
world.

>Also, were the errors in question encoding ones, relevant to this debate, or 
>did they have to do with the data values per se?

Mostly encoding ones, since I couldn't locate CA certs for many of the certs I
grabbed I never even got as far as checking whether the values themselves were
valid/consistent.

Peter.



Received: from localhost (daemon@localhost) by mail.proper.com (8.8.8/8.8.5) with SMTP id FAA22448; Wed, 14 Jul 1999 05:58:34 -0700 (PDT)
Received: by mail.imc.org (bulk_mailer v1.12); Wed, 14 Jul 1999 05:58:31 -0700
Received: from rbhub101.chamb.disa.mil (rbhub101.chamb.disa.mil [209.22.120.24]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id FAA22426 for <[e-mail]>; Wed, 14 Jul 1999 05:58:30 -0700 (PDT)
Received: by rbhub101.chamb.disa.mil with Internet Mail Service (5.5.2448.0) id <3XZYVH9L>; Wed, 14 Jul 1999 09:00:20 -0400
Message-ID: <[e-mail]>
From: "Flanigan, Bill" <[e-mail]>
To: "'Michael Myers'" <[e-mail]>
Cc: "'[e-mail]'" <[e-mail]>
Subject: KISS for PKIX.  (Was: RE: ASN.1 vs XML (used to be RE: I-D ACTION :draft-ietf-pkix-scvp- 00.txt))
Date: Wed, 14 Jul 1999 09:03:04 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2448.0)
Content-Type: text/plain
Precedence: bulk
List-Archive: http://www.imc.org/ietf-pkix/mail-archive/
List-Unsubscribe: mailto:[e-mail]?body=unsubscribe
X-UIDL: 37c41e82595b682519f4ad11cbcd05d1

Hello Mike,

	You are on the right track (and so, I think, is Steve).  Before PKI
technologies (and other IETF *core* security protocol suites) can be *main
streamed,* they must be made very easy to use across the board--from
implementers to developers to end (human) entities.  Some might object to
this as being *dumbed down,* but lack of interoperability due to overly
complex and convoluted multi-protocols (not to mention competing protocols)
is a real problem.  So is the resulting complexity of use experienced by EEs
(I could write volumes here!).  Unless we aim for the *lowest common
denominator,* CIOs will never be able to show ROIs to justify PKI (and
especially the PKIX favor of PKI) purchases.  We have probably all read
recent reports that Fortune 1,000 CEOs see IT, in general, and PKI, in
particular, as simply drains on profits; and in the UK, companies don't seem
to be interested in PKI (and especially the PKIX flavor of PKI) at all.  As
usual, KISS is the key (no pun intended).  I fear that we do not have the
luxury of tossing things over the fence to *let the market decide.*  The
market may decide to pass.

Bill

> ----------
> From: 	Michael Myers[SMTP:[e-mail]]
> Sent: 	Tuesday, July 13, 1999 9:29 PM
> To: 	'Stephen Kent'; Anders Rundgren
> Cc: 	'Peter Sylvester'; '[e-mail]'
> Subject: 	RE: ASN.1 vs XML (used to be RE: I-D
> ACTION:draft-ietf-pkix-scvp- 00.txt)
> 
> Steve,
> 
> I'll probably bring this point to your attention on the floor before you
> read this email, but for the record (and further, for the benefit of those
> unable to attend the Oslo session), I would claim that making PKI easy for
> developers is a very good thing.  Your comment belows seems to modestly
> suggest that such an objective is less worthy than it might ought to be.
> 
> Indeed, this principle was the primary motivation for OCSP's original
> non-ASN.1 proposal.
> 
> Mike
> 
> 
> 
> > -----Original Message-----
> > From: Stephen Kent [mailto:[e-mail]]
> > Sent: Tuesday, July 13, 1999 12:28 AM
> > To: Anders Rundgren
> > Cc: 'Peter Sylvester'; '[e-mail]'
> > Subject: RE: ASN.1 vs XML (used to be RE: I-D
> > ACTION:draft-ietf-pkix-scvp-00.txt)
> > 
> > 
> > Anders,
> > 
> > 
> > >The important thing is that in order to make PKI a 
> > main-stream technology
> > >(which it is
> > >not today), may require changes like going to XML as XML is likely to
> > >at least replace EDI which is often used in the same contexts as
> > >certificates (or
> > >rather should be).  So if XML becomes the HTML (which is closer to a
> > >"peoples movement" than a computer language) of business 
> > messages, ASN.1
> > >may be too obscure (few know it) and less satisfactory as a long-term
> > >solution.
> > >
> > >This should be seen in the light of the fact that the only 
> > main-stream
> > >PKI-application
> > >I can think about, is e-commerce.  As very few e-commerce 
> > standards are ready
> > >for prime time, there is plenty of room for new things.
> > 
> > There seems to be an implication here that mainstream users 
> > want to be able
> > to read the signed data in its native format, and thus XML encoding is
> > preferable to DER.  But we know this is not true, i.e., 
> > whatever has been
> > signed will be decoded prior to display, and then rendered 
> > for the user.
> > So, it would seem that the use of an encoding scheme such as 
> > XML would be
> > more attractive for developers performing debugging, rather 
> > than for users.
> > 
> > Steve
> > 
> 


Received: from localhost (daemon@localhost) by mail.proper.com (8.8.8/8.8.5) with SMTP id FAA21658; Wed, 14 Jul 1999 05:24:53 -0700 (PDT)
Received: by mail.imc.org (bulk_mailer v1.12); Wed, 14 Jul 1999 05:24:51 -0700
Received: from rbhub101.chamb.disa.mil (rbhub101.chamb.disa.mil [209.22.120.24]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id FAA21636 for <[e-mail]>; Wed, 14 Jul 1999 05:24:51 -0700 (PDT)
Received: by rbhub101.chamb.disa.mil with Internet Mail Service (5.5.2448.0) id <3XZYVG38>; Wed, 14 Jul 1999 08:26:21 -0400
Message-ID: <[e-mail]>
From: "Flanigan, Bill" <[e-mail]>
To: "'Stephen Kent'" <[e-mail]>
Cc: "'[e-mail]'" <[e-mail]>
Subject: The Average User  (Was: RE: ASN.1 vs XML (used to be RE: I-DACTIO N:draft-ietf-pkix-scvp-00.txt))
Date: Wed, 14 Jul 1999 08:29:07 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2448.0)
Content-Type: text/plain
Precedence: bulk
List-Archive: http://www.imc.org/ietf-pkix/mail-archive/
List-Unsubscribe: mailto:[e-mail]?body=unsubscribe
X-UIDL: e12cf37e1d411e035665f1760d15f38b

Hello Steve,

	Boy, have you ever got that one right!  The *average user* in a
large organization's PKI is often just barely computer literate, and doesn't
know (or care) what a browser is much less how it works.  It's just
point-and-click, point-and-click, etc.  And this is how it should be.  If
you don't "hide all technology from all life forms," it won't be used (or
used correctly).  For those who are interested (less than five percent of
end users?), they can, of course, view the windows proffered by their
favorite browser or download the binary from the repository.

Bill

> ----------
> From: 	Stephen Kent[SMTP:[e-mail]]
> Sent: 	Wednesday, July 14, 1999 2:19 AM
> To: 	Timothy Fisher
> Cc: 	'[e-mail]'
> Subject: 	Re: ASN.1 vs XML (used to be RE:
> I-DACTION:draft-ietf-pkix-scvp-00.txt)
> 
> Tim,
> 
> I think it is a rare user indeed who ever wants to look at a certificate.
> Experience suggests that the certificate viewing feature of browsers is
> rarely invoked by the average user.
> 
> Steve
> 


Received: from localhost (daemon@localhost) by mail.proper.com (8.8.8/8.8.5) with SMTP id EAA20783; Wed, 14 Jul 1999 04:44:10 -0700 (PDT)
Received: by mail.imc.org (bulk_mailer v1.12); Wed, 14 Jul 1999 04:44:07 -0700
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 EAA20760 for <[e-mail]>; Wed, 14 Jul 1999 04:44:01 -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 LAA13157; Wed, 14 Jul 1999 11:44:55 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 MAA01173; Wed, 14 Jul 1999 12:45:07 +0100
Message-ID: <[e-mail]>
Date: Wed, 14 Jul 1999 12:44:51 +0100
From: Ben Laurie <[e-mail]>
Organization: A.L. Group plc
X-Mailer: Mozilla 4.08 [en] (WinNT; I)
MIME-Version: 1.0
To: Stephen Kent <[e-mail]>
CC: PKIX-List <[e-mail]>
Subject: Re: I-D ACTION:draft-ietf-pkix-scvp-00.txt
References: <002201bec991$b0d12510$[e-mail]>		 <[e-mail]> <v04020a04b3abb1930baa@[128.89.0.110]> <v04020a04b3b09ba515d7@[128.33.238.237]> <v04020a02b3b1da7827d4@[128.33.238.233]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Precedence: bulk
List-Archive: http://www.imc.org/ietf-pkix/mail-archive/
List-Unsubscribe: mailto:[e-mail]?body=unsubscribe
X-UIDL: e2727dc8302b8ac070e95b9587b8c43e

Stephen Kent wrote:
> 
> Ben,
> 
> >Leaving aside the attempt at a personal slight (which widely misses the
> >mark, as I was not a developer of OpenSSL when this problem was current,
> >and one of the first things I did as a developer was to fix it), I
> >completely fail to see the distinction between the OpenSSL/SSLeay
> >"developer community" and the "CA and X.500 product communities". Any CA
> >or X.500 developer with any pretence at credibility will surely have
> >tested SSLeay. In fact, many of them used it as the basis for their
> >products.
> 
> There was no personal slight intended in my remarks, nor, in my reading,
> none expressed.  There was, however, a pointed criticism of SSLeay, a
> collection of software, not a standard.  I do disparge the notion that
> standards are established by distributed software.

I didn't suggest they were. However, interoperability testing is a part
of establishing a standard and is a good way of testing conformance to a
standard.

> As the CTO of a CA product developer I can and do take exception with the
> suggestion that use of SSLeay is relevant to core CA business.  We
> developed our own ASN.1 compiler years ago, even sold it to some folks, and
> have not found it necessary to avail ourselves of freeware.  I think your
> sample of CA vendors and mine differ considerably.

Again, I'm not suggesting that you should use SSLeay, I'm suggesting
that you would be wise to test against it (well, against OpenSSL).

> >And when Peter Gutmann made that remark, he was certainly not referring
> >to OpenSSL's standards conformance, as it was in the context of checking
> >signatures in OpenSSL.
> 
> OpenSSL, what's the RFC for that protocol?  TLS is a standard, and SSL as a
> proprietary protocol developed by browser vendors.

OpenSSL conforms to standards, such as the TLS draft standard (unless I
missed something, it isn't a standard yet) and a pile of other ones,
too. I am not suggesting that OpenSSL is a standard. I don't know why
you think I am.

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 localhost (daemon@localhost) by mail.proper.com (8.8.8/8.8.5) with SMTP id DAA16495; Wed, 14 Jul 1999 03:06:44 -0700 (PDT)
Received: by mail.imc.org (bulk_mailer v1.12); Wed, 14 Jul 1999 03:06:26 -0700
Received: from foo.ietf.uninett.no ([e-mail] [128.39.10.31]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id DAA16465 for <[e-mail]>; Wed, 14 Jul 1999 03:06:25 -0700 (PDT)
Received: from ieca.com (dhcp30175.ietf.uninett.no [128.39.30.175]) by foo.ietf.uninett.no (8.9.3/8.9.3) with ESMTP id MAA09672; Wed, 14 Jul 1999 12:07:27 +0200
Message-ID: <[e-mail]>
Date: Wed, 14 Jul 1999 12:06:23 -0500
From: Sean Turner <[e-mail]>
X-Mailer: Mozilla 4.5 [en] (Win98; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Denis Pinkas <[e-mail]>
CC: [e-mail]
Subject: When is Timestamp applied?
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Precedence: bulk
List-Archive: http://www.imc.org/ietf-pkix/mail-archive/
List-Unsubscribe: mailto:[e-mail]?body=unsubscribe
X-UIDL: dd09627dcf538a4ad15c9c11903aab7f

Denis,

At the meeting today you mentioned that the draft doesn't specify when
the timestamp is applied, either when the data was received or when the
signature was applied.  BUt, the slides you threw up from the ISO text
clearly indicated that the timestamp is applied when the signature is
generated.  I think the draft should either
- specify that the time in the timesatamp is the TSA's signture time or
- there should be field included (a choice) to indicate that the time is
when the data was received or when the TSA's signature was generated.

Otherwise, the meaning of the timestamp is very ambiguious.

spt



Received: from mail.inter.net.il ([e-mail] [192.116.192.53]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id OAA10706 for <[e-mail]>; Wed, 14 Jul 1999 14:57:03 -0700 (PDT)
Received: from radguard.com (radguard.com [192.114.169.3]) by mail.inter.net.il (8.9.3/8.8.6/PA) with SMTP id AAA18780 for <[e-mail]>; Thu, 15 Jul 1999 00:58:01 +0300 (IDT)
Received: by radguard.com   (4.1/SMI-4.1) id AA06323; Thu, 15 Jul 99 00:58:12 IDT
Received: from hellman.radguard.com(192.114.33.100) by gatekeeper.radguard.com via smap (V2.0beta) id xma006320; Thu, 15 Jul 99 00:57:42 +0300
Received: from radguard.com by hellman. (SMI-8.6/SMI-SVR4) id AAA15674; Thu, 15 Jul 1999 00:58:31 +0200
Message-Id: <[e-mail]>
Date: Thu, 15 Jul 1999 00:56:21 +0300
From: Sara Bitan <[e-mail]>
Organization: RADGUARD
X-Mailer: Mozilla 4.5 [en] (Win95; I)
X-Accept-Language: en
Mime-Version: 1.0
To: IETF PKIX list <[e-mail]>
Subject: IPSec device requirements from PKI server (DCS/CSVP/OCSP)
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

During the discussion in the morning session of the working group today,
people had refereed to the requirements of a PKI client from a
DCS/CSVP/OCSP server.

I would like to present my perspective as an IPSec vendor, both from the
security gateway and the IPSec client point of view.

I would like to verify the certificate within my IPsec implementation.
One requirement I have from PKI server is to be able to produce a
certificate chain from a given certificate to a trusted CA(s) I specify.

There are several reasons to this approach
1) I don't like the IPSec device to perform the trust path search and be
able to support LDAP, HTTP or other retrieval protocols for this
purpose. No trust is needed for the delegation of the search, assuming
the certificates in the chain and the CRLs are to be trusted.
2) why not delegate the certificate verification to a PKI server?  I
wouldn't trust anybody to verify the signature for me. An IPSec device
has the public key technology (required for IKE), hence, it has the
ability to verify the signature on the certificate.
3) a certificate verification server will not be aware of the list of
CAs that the IPSec device doesn't trust. I wouldn't like to configure
the certificate verification server with the list of trusted CAs for
each security gateway and IPSec client.
4) efficiency reasons - if the IPSec device gets the certificate chain,
it will be able to cache it and to use it (or parts of it) whenever it
needs.  It will be able to save some of the queries to the PKI server.

Since I want the IPSec device to verify the certificate chain, I would
also like the PKI server to be able to separate the revocation status
from the trust path search. This way the IPSec device will be able to
cache the certificate chain and just check the revocation status.

Regarding the certificate chain there is one problem that was raised.
Suppose there are several chains leading from the peer's certificate to
the trusted CA. Suppose some are legal and some are not. Which
certificate chain should the PKI server return?

Once again, this is my private point of view of the requirements from
and IPSec vendor's perspective. Hope that's helpful,

 Thanks, Sara.




Received: from foo.ietf.uninett.no ([e-mail] [128.39.10.31]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id OAA10042 for <[e-mail]>; Wed, 14 Jul 1999 14:36:55 -0700 (PDT)
Received: from dwc-acer (dhcp3129.ietf.uninett.no [128.39.31.29]) by foo.ietf.uninett.no (8.9.3/8.9.3) with SMTP id XAA12385; Wed, 14 Jul 1999 23:37:59 +0200
Message-Id: <[e-mail]>
From: "David Chadwick" <[e-mail]>
Organization: University of Salford
To: "Salter, Thomas A" <[e-mail]>, [e-mail]
Date: Wed, 14 Jul 1999 22:42:30 +0100
MIME-Version: 1.0
Content-type: text/plain; charset=US-ASCII
Content-transfer-encoding: 7BIT
Subject: RE: New ID on LDAPv3
Reply-to: [e-mail]
Priority: normal
In-reply-to: <[e-mail]>
X-mailer: Pegasus Mail for Win32 (v3.01d)

> 
> Is the confusion here that the ;binary description says to use BER, but
> certificates, CRLs, etc. must be in DER?  Perhaps the server should be
> required to preserve the encoding of binary attributes as they were added;
> that is, the server must not decode and re-encode certificates.  Then
> signatures can be validated even if the original attribute was not quite
> correct DER.

You have it in one. I also think some brain dead servers may 
decode and recode the signed attributes :-) (only heresay though, 
dont know of a concrete example)

> Is there a distinction here between attributes with Binary syntax and
> others, such as those with Certificate syntax ?  RFC2252 clearly states
> that attributes with certificate syntax must always be requested or
> returned with ;binary.
> 

I think Chris was trying to have separate text for certificates that 
must be sent with binary syntax and any attributes that may be sent 
with binary syntax. But I did not think that this text was appropriate 
for the PKIX profile.

> 
> The server should be required to specify the ;binary whenever it returns
> BER encodings.

I can certainly agree with this

>
> 
> Why is OCTET STRING a special case ?  As I read the RFCs, a server can
> support ;binary on attributes of any syntax, in which case it returns the
> BER encoding of the value.  An OCTET STRING should be handled just like an
> INTEGER or a SEQUENCE, so there would be an extra OCTET STRING wrapper.
> 

This also seems fine to me
David

***************************************************

David Chadwick
IT Institute, University of Salford, Salford M5 4WT
Tel [phone]  Fax [phone]
*NEW* Mobile [phone] *NEW*
Email [e-mail]
Home Page  http://www.salford.ac.uk/its024/chadwick.htm
Understanding X.500  http://www.salford.ac.uk/its024/X500.htm
X.500/LDAP Seminars http://www.salford.ac.uk/its024/seminars.htm
Entrust key validation string MLJ9-DU5T-HV8J

***************************************************


Received: from bbmail1.unisys.com (bbmail1.unisys.com [192.63.108.35]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id NAA08629 for <[e-mail]>; Wed, 14 Jul 1999 13:52:20 -0700 (PDT)
Received: from trsvrbk.tr.unisys.com (trsvrbk.tr.unisys.com [192.63.236.1]) by bbmail1.unisys.com (8.8.5/8.8.5) with ESMTP id UAA06183; Wed, 14 Jul 1999 20:53:04 GMT
Received: from us-tr-exch-2.tr.unisys.com by trsvrbk.tr.unisys.com (8.8.5/8.8.5) id UAA10951 ; Wed, 14 Jul 1999 20:52:11 GMT
Received: by us-tr-exch-2.tr.unisys.com with Internet Mail Service (5.5.2448.0) id <3W07V4P2>; Wed, 14 Jul 1999 16:52:15 -0400
Message-ID: <[e-mail]>
From: "Salter, Thomas A" <[e-mail]>
To: [e-mail], Christopher Oliva <[e-mail]>, Mike Just <[e-mail]>
Cc: [e-mail]
Subject: RE: New ID on LDAPv3
Date: Wed, 14 Jul 1999 16:52:18 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2448.0)
Content-Type: text/plain; charset="iso-8859-1"

My comments below relate only to the BER/DER and ;binary discussions.  

 > -----Original Message-----
 > From: David Chadwick [mailto:[e-mail]]
 > Sent: Wednesday, July 14, 1999 3:39 PM
 > To: Christopher Oliva; Mike Just
 > Cc: [e-mail]
 > Subject: RE: New ID on LDAPv3
 > 
 > 
 > From:           	Christopher Oliva <[e-mail]>
 > To:             	"'[e-mail]'" 
 > <[e-mail]>
 > Copies to:      	Mike Just <[e-mail]>
 > Subject:        	RE: New ID on LDAPv3
 > Date sent:      	Thu, 8 Jul 1999 10:45:31 -0400 
 > 
 > > Hi,
 > > 
 > > I have some comments on the ldapv3 profile:
 > > 
 > > 1) Point 2, Paragraph 1 - re BER encodings
 > > 
 > > Interoperability with various vendors has shown that the 
 > industry trend is
 > > set towards using DER encodings in the protocol. The BER encodings
 > > specified by ldapv3 is too liberal which many clients 
 > cannot properly
 > 
 > There are two sets of encodings to consider. 
 > i) the encoding of the LDAP protocol itself - the request, response 
 > and all the parameters. This is specified as a simplified version of 
 > BER (eg. definite length encodings must be used). I presume you 
 > are not referring to this.
 > ii) the encoding of the X.509 attributes, i.e. certificates 
 > and CRLs. 
 > This is an issue for the CA and not for LDAP in my opinion. 
 > It is the 
 > CA that initially puts the signature on the data item and 
 > then passes 
 > it to the directory for storage. In the process of creating the 
 > signature the CA decide to do DER encoding according to X.509 
 > standard. The directory should not in my opinion decode and then 
 > recode the attribute during storage otherwise it could 
 > invalidate the 
 > signature. Rather the directory may decode (in order to extract the 
 > data item for use in indexing and searches) but should store the 
 > encoded attribute as is, ready for retrieval.
 > 
 > By the way, I am perfectly happy with the wording in RFC 2559 as it 
 > stands and can cut and paste this as appropriately into the 
 > ID if you 
 > wish.
 > 
 > > parse. For that reason, the ldapv3 profile should be 
 > aligned with the
 > > current RFC 2559 and mandate DER encodings. In this case 
 > the clients must
 > > use DER encodings when adding new attribute values and the 
 > server must
 > > return the identical encoding which was originally added 
 > by the client.
 > > 
 > 
 > It seems like we are in agreement here. Incidentally, a CA could use 
 > BER to generate a signature and it should  still all work 
 > fine providing 
 > clients can decode BER. Clients other than CAs should never need 
 > to encode in BER.
 > 
 > > Also, this constraint should apply not only to CRLs and 
 > certificate but to
 > > any attribute which has a SIGNED syntax (for example, 
 > caCertificate,
 > > attributeCertificate etc.)
 > 
 > AGREED!!
 > 

Is the confusion here that the ;binary description says to use BER, but
certificates, CRLs, etc. must be in DER?  Perhaps the server should be
required to preserve the encoding of binary attributes as they were added;
that is, the server must not decode and re-encode certificates.  Then
signatures can be validated even if the original attribute was not quite
correct DER.


 > > 
 > > 2) Point 2, Paragraph 1 - re ;binary support
 > > 
 > > In my opinion, support of the ;binary attribute option is somewhat
 > > ambiguous in the ldap specification. 
 > 
 > Agreed, this is why I added some minimal explanatory text in the ID. 
 > It obviously was not enough. However, we really ought to be 
 > updating the base LDAP texts and not fixing it in the PKIX profile. 
 > Dont you agree?
 > 
 > >I would like to include some text in
 > > the profile to clarify exactly what the behaviour of 
 > clients and server
 > > should be with respect to ;binary. My suggestion is:
 > > 
 > >  ".. When a client adds, deletes or modifies values which 
 > are defined to
 > > have the Binary syntax (defined in RFC 2252), the 
 > attribute type name MUST
 > > always be specified with the ;binary attribute option. 
 > 
 > Dont forget the case of a client retrieving a certificate as well. 
 > ;binary is mandatory for this as well.
 > 
 > >When the server
 > > returns such an attribute in a search result, the 
 > attribute type name
 > > SHOULD include the ;binary but it is not necessary 
 > (whether or not the
 > > attribute type was explicitly requested in the search operation). 
 > 
 > Why do you relax this to SHOULD. What is wrong with MUST. Is it 
 > because the client can infer this during parsing.
 > 

Is there a distinction here between attributes with Binary syntax and
others, such as those with Certificate syntax ?  RFC2252 clearly states that
attributes with certificate syntax must always be requested or returned with
;binary.
 
 > 
 > >The
 > > encoding of the attribute value is BER or DER (for 
 > attributes whose ASN.1
 > > syntax is a SIGNED structure).
 > > 
 > >  When a client adds, deletes or modifies values which are 
 > not defined to
 > > have the Binary syntax, the use of ;binary in the 
 > attribute type name is
 > > optional however if ;binary is used, the value MUST be a valid BER
 > > encoding. If the server cannot accept this form of 
 > presentation of the
 > > attribute value, the server MUST respond with an 
 > invalidAttributeSyntax
 > > error. 
 > 
 > I dont think any of the above has anything to do with PKIX since all 
 > the X.509 attributes are binary. I do not propose putting 
 > this text in 
 > at the moment unless other people think I should.
 > 
 > >If the attribute name with ;binary is specified in a modify
 > > (delete) operation (such that no new values are specified 
 > in the client
 > > operation), the server MUST accept the request as if the 
 > ;binary option
 > > was not present. 
 > 
 > This is not PKIX specific but LDAP general. Is there a bug in LDAP 
 > here?
 > 
 > >When the client performs a search operation and the
 > > attribute type is not explicitly requested or is 
 > explicitly requested
 > > without the ;binary option, the server MUST return an 
 > encoding of the
 > > attribute which matches the syntax used in the attribute's schema
 > > definition. If the attribute type is explicitly requested 
 > with the ;binary
 > > option, the server MUST return a BER encoding for the 
 > value and the type
 > > name SHOULD include the ;binary option. In this case, if 
 > the server cannot
 > > return a BER encoding, it must omit the attribute from the 
 > search response
 > > (treat it as if it were an undefined attribute type).
 > 
 > Again this seems to me to be general LDAP text rather than PKIX 
 > specific text.
 > 

The server should be required to specify the ;binary whenever it returns BER
encodings.

 > > 
 > >  If the attribute in question is defined to have an Octet String
 > > syntax, the same octet string encoding is always used by 
 > the client and
 > > returned by the server whether or not the ;binary option 
 > is used in the
 > > client operation (i.e. the transmitted value will not have 
 > an extra OCTET
 > > STRING wrapper). In this case, the attribute may or may 
 > not have a BER
 > > encoding ..."
 > 
 > ditto above.
 > 

Why is OCTET STRING a special case ?  As I read the RFCs, a server can
support ;binary on attributes of any syntax, in which case it returns the
BER encoding of the value.  An OCTET STRING should be handled just like an
INTEGER or a SEQUENCE, so there would be an extra OCTET STRING wrapper.


... rest deleted ...


 > ***************************************************
 > 
 > David Chadwick
 > IT Institute, University of Salford, Salford M5 4WT
 > Tel [phone]  Fax [phone]
 > *NEW* Mobile [phone] *NEW*
 > Email [e-mail]
 > Home Page  http://www.salford.ac.uk/its024/chadwick.htm
 > Understanding X.500  http://www.salford.ac.uk/its024/X500.htm
 > X.500/LDAP Seminars http://www.salford.ac.uk/its024/seminars.htm
 > Entrust key validation string MLJ9-DU5T-HV8J
 > 
 > ***************************************************
 > 


Received: from foo.ietf.uninett.no ([e-mail] [128.39.10.31]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id MAA04992 for <[e-mail]>; Wed, 14 Jul 1999 12:34:27 -0700 (PDT)
Received: from dwc-acer (dhcp3129.ietf.uninett.no [128.39.31.29]) by foo.ietf.uninett.no (8.9.3/8.9.3) with SMTP id VAA11832; Wed, 14 Jul 1999 21:35:09 +0200
Message-Id: <[e-mail]>
From: "David Chadwick" <[e-mail]>
Organization: University of Salford
To: Christopher Oliva <[e-mail]>, Mike Just <[e-mail]>
Date: Wed, 14 Jul 1999 20:39:25 +0100
MIME-Version: 1.0
Content-type: text/plain; charset=US-ASCII
Content-transfer-encoding: 7BIT
Subject: RE: New ID on LDAPv3
Reply-to: [e-mail]
CC: [e-mail]
Priority: normal
In-reply-to: <[e-mail]>
X-mailer: Pegasus Mail for Win32 (v3.01d)

From:           	Christopher Oliva <[e-mail]>
To:             	"'[e-mail]'" 
<[e-mail]>
Copies to:      	Mike Just <[e-mail]>
Subject:        	RE: New ID on LDAPv3
Date sent:      	Thu, 8 Jul 1999 10:45:31 -0400 

> Hi,
> 
> I have some comments on the ldapv3 profile:
> 
> 1) Point 2, Paragraph 1 - re BER encodings
> 
> Interoperability with various vendors has shown that the industry trend is
> set towards using DER encodings in the protocol. The BER encodings
> specified by ldapv3 is too liberal which many clients cannot properly

There are two sets of encodings to consider. 
i) the encoding of the LDAP protocol itself - the request, response 
and all the parameters. This is specified as a simplified version of 
BER (eg. definite length encodings must be used). I presume you 
are not referring to this.
ii) the encoding of the X.509 attributes, i.e. certificates and CRLs. 
This is an issue for the CA and not for LDAP in my opinion. It is the 
CA that initially puts the signature on the data item and then passes 
it to the directory for storage. In the process of creating the 
signature the CA decide to do DER encoding according to X.509 
standard. The directory should not in my opinion decode and then 
recode the attribute during storage otherwise it could invalidate the 
signature. Rather the directory may decode (in order to extract the 
data item for use in indexing and searches) but should store the 
encoded attribute as is, ready for retrieval.

By the way, I am perfectly happy with the wording in RFC 2559 as it 
stands and can cut and paste this as appropriately into the ID if you 
wish.

> parse. For that reason, the ldapv3 profile should be aligned with the
> current RFC 2559 and mandate DER encodings. In this case the clients must
> use DER encodings when adding new attribute values and the server must
> return the identical encoding which was originally added by the client.
> 

It seems like we are in agreement here. Incidentally, a CA could use 
BER to generate a signature and it should  still all work fine providing 
clients can decode BER. Clients other than CAs should never need 
to encode in BER.

> Also, this constraint should apply not only to CRLs and certificate but to
> any attribute which has a SIGNED syntax (for example, caCertificate,
> attributeCertificate etc.)

AGREED!!

> 
> 2) Point 2, Paragraph 1 - re ;binary support
> 
> In my opinion, support of the ;binary attribute option is somewhat
> ambiguous in the ldap specification. 

Agreed, this is why I added some minimal explanatory text in the ID. 
It obviously was not enough. However, we really ought to be 
updating the base LDAP texts and not fixing it in the PKIX profile. 
Dont you agree?

>I would like to include some text in
> the profile to clarify exactly what the behaviour of clients and server
> should be with respect to ;binary. My suggestion is:
> 
>  ".. When a client adds, deletes or modifies values which are defined to
> have the Binary syntax (defined in RFC 2252), the attribute type name MUST
> always be specified with the ;binary attribute option. 

Dont forget the case of a client retrieving a certificate as well. 
;binary is mandatory for this as well.

>When the server
> returns such an attribute in a search result, the attribute type name
> SHOULD include the ;binary but it is not necessary (whether or not the
> attribute type was explicitly requested in the search operation). 

Why do you relax this to SHOULD. What is wrong with MUST. Is it 
because the client can infer this during parsing.


>The
> encoding of the attribute value is BER or DER (for attributes whose ASN.1
> syntax is a SIGNED structure).
> 
>  When a client adds, deletes or modifies values which are not defined to
> have the Binary syntax, the use of ;binary in the attribute type name is
> optional however if ;binary is used, the value MUST be a valid BER
> encoding. If the server cannot accept this form of presentation of the
> attribute value, the server MUST respond with an invalidAttributeSyntax
> error. 

I dont think any of the above has anything to do with PKIX since all 
the X.509 attributes are binary. I do not propose putting this text in 
at the moment unless other people think I should.

>If the attribute name with ;binary is specified in a modify
> (delete) operation (such that no new values are specified in the client
> operation), the server MUST accept the request as if the ;binary option
> was not present. 

This is not PKIX specific but LDAP general. Is there a bug in LDAP 
here?

>When the client performs a search operation and the
> attribute type is not explicitly requested or is explicitly requested
> without the ;binary option, the server MUST return an encoding of the
> attribute which matches the syntax used in the attribute's schema
> definition. If the attribute type is explicitly requested with the ;binary
> option, the server MUST return a BER encoding for the value and the type
> name SHOULD include the ;binary option. In this case, if the server cannot
> return a BER encoding, it must omit the attribute from the search response
> (treat it as if it were an undefined attribute type).

Again this seems to me to be general LDAP text rather than PKIX 
specific text.

> 
>  If the attribute in question is defined to have an Octet String
> syntax, the same octet string encoding is always used by the client and
> returned by the server whether or not the ;binary option is used in the
> client operation (i.e. the transmitted value will not have an extra OCTET
> STRING wrapper). In this case, the attribute may or may not have a BER
> encoding ..."

ditto above.

> 
> 3) Point 2, Paragraph 1 - re other attribute options
> 
> I feel that the statement that other attribute options should not be
> supported is unnecessary and should be removed. Otherwise a valid reason
> for this should be provided.

As a result of this and Mark Wahl's comments, this has now been 
changed to

"Other attribute description options SHOULD NOT 
be generated by clients. Servers MAY choose to 
support them at their discretion."

The rationale is to simply implemenations since this feature is not 
required for PKIX operation.

> 
> 4) Point 2, Paragraph 2 - re UTF8 encodings
> 
> Support for UTF8 should include a statement which specifies that raw,
> binary UTF8 should be used in the protocol and the escaped hex-ascii
> mechanism of RFC 2253 should not be used in the protocol.
> 

I dont agree with this from reading the LDAP specs. This will need to 
be discussed by a wider audience, including the LDAP group 
before I make a change.

> 5) Point 2, Paragraph 2 - re distinguished names
> 
> From experiences with some directory vendors, I feel it is necessary to
> state that DN support MUST include support for multiple AVAs within RDN
> components and that the ordering of the AVAs is non-deterministic. For
> example cn=John + uid=123 is the same as uid=123 + cn=John.
> 

Good Point.Agreed. The inserted text reads as follows:

Multiple attribute value assertions (AVAs) within 
RDN components of distinguished names MUST be 
supported and the ordering of the AVAs is non-
deterministic. For example cn=John + uid=123 is 
the same as uid=123 + cn=John.


> 6) Point 2 - Additional recommendation - common schema
> 
> I'm sure that a common ldapv3 schema is planned to support the protocol

I had not planned to do this, I dont know if you want to start?

> profile but it would be important to reference it and perhaps note that
> only the standard attribute names MUST be used by the client and server.

SHOULD is probably better here, since orgs could change it if they 
had a really good reason to.

> For example, legacy names such as rfc822Mailbox should not be used. the
> attribute name is more commonly defined as "mail". Since that is not
> actually standardized anywhere I think a common schema for this type of
> thing would be useful.

The closest it has got to standardisation is the InetOrgPerson draft 
from Mark Smith

> 
> I would also like to recommend that the common schema should include a
> mechanism to identify what CAs have authority within a given subtree of
> the DIT. This could take the form of a collective attribute which applies
> to specific users or as a multi valued root DSE operational attribute
> which applies to subtrees.

I had not thought about this before. You seem to be suggesting that I 
can search the DIT to find out which CA is in charge, is that correct.
What purpose does this serve? Since I can get this anyway from 
the issuer field of the retrieved cert.

> 
> 7) Point 3 - re referrals and search continuations
> 
> RFC 2255 allows ldap URLs to identify new search filters, and list of
> attributes to return as well as new bind credentials. This MUST not be
> supported in the PKI environment since integrity of the operations require
> consistency in these parameters.
> 

I have inserted the following text

However, the returned referrals SHOULD NOT 
specify new search filters, attributes to be 
returned or user credentials. Servers SHOULD only 
return the hostport, and DN components and MAY 
return the scope component.

(Scope is needed for a onelevel search that hits an alias in another 
server)

> I would like to propose a new extension for URLs: a minimal authentication
> level. This would specify the minimal authentication level which is
> necessary to bind to the server. This would never be critical so the
> client is free to use a stronger form of authentication if so desired.

This ID is not the correct place to add updates to the URL. THis 
should be referred to the LDAPExt group. However, if you are 
suggesting returning authentication level information, why not accept 
new credentials as well?


> 
> 8) Point 4 - Paragraph 1 - re modifyDN, compare and abandon operations
> 
> I see no reason that these operations should be omitted. Perhaps in the
> case of modifyDN there may be concern with respect to making sure that the
> DN in the certificate subject is the same as the DN in the entry name
> however this is dependent on the organization's CPS and other
> implementation factors. Generally, I believe that leaving the statement in
> the current draft will lead to confusion and degraded functionality and
> should be removed (vendors should not be discouraged from supporting
> ModifyDN which is an extremely useful operation).

After discussion with Mark Wahl, the text currently reads:
"A client following this profile need not send 
the ModifyDN, Compare and Abandon operations. The 
server MAY choose to support these operations at 
its discretion."

I appreciate that Entrust does support change of 
DN, and I can see its use. Does the above satisfy 
you or not?


> 
> 9) Point 4 - Paragraph 4 - re schema publication
> 
> I don't see why vendors would be discouraged from publishing the schema.
> Indeed it is conceivable that a server's support of schema may affect how
> revocation information is published or how user entries are created. There
> are also other useful reasons to retrieve schema information such as
> constructing a list of attribute which have opaque binary syntaxes and
> cannot be displayed to users. The statement should be removed unless there
> is a strong argument for discouraging vendors from implementing schema
> publication.

This was not the rationale for excluding it.I am generally in favour of 
schema publishing. I thought (perhaps incorrectly) that it was not 
needed by PKIX. Mark Wahl pointed out one use for it, and I am 
happy to have schema publishing in the ID. The text currenly has 
matching rules added as follows:

"LDAPv3 allows the subschema supported by the 
server to be published in a subschema subentry. 
Clients following this profile which support
invoking a search containing an extensible 
matching rule MAY use the
subschemaSubentry attribute in the root DSE and 
retrieve the subschema to determine whether the 
server supports the certificateMatch matching 
rule described below."


If this is not sufficient for you please advise.

> 
> 10) Point 5 - Paragraph 4 - re certificate matching rules
> 
> I think that vendors should be encouraged to implement certificate
> matching rules as much as possible. For that reason, I would recommend
> that support of this feature should be upgraded to SHOULD rather than MAY.
> 

The text currently reads

"If the server supports flexible matching, then 
the extensibleMatch filter item MUST be 
supported. Clients MAY support the 
extensibleMatch filter item."

Is this enough for you or not?

David

***************************************************

David Chadwick
IT Institute, University of Salford, Salford M5 4WT
Tel [phone]  Fax [phone]
*NEW* Mobile [phone] *NEW*
Email [e-mail]
Home Page  http://www.salford.ac.uk/its024/chadwick.htm
Understanding X.500  http://www.salford.ac.uk/its024/X500.htm
X.500/LDAP Seminars http://www.salford.ac.uk/its024/seminars.htm
Entrust key validation string MLJ9-DU5T-HV8J

***************************************************


Received: from foo.ietf.uninett.no ([e-mail] [128.39.10.31]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id MAA04936 for <[e-mail]>; Wed, 14 Jul 1999 12:34:07 -0700 (PDT)
Received: from dwc-acer (dhcp3129.ietf.uninett.no [128.39.31.29]) by foo.ietf.uninett.no (8.9.3/8.9.3) with SMTP id VAA11829; Wed, 14 Jul 1999 21:35:09 +0200
Message-Id: <[e-mail]>
From: "David Chadwick" <[e-mail]>
Organization: University of Salford
To: Mark Wahl <[e-mail]>
Date: Wed, 14 Jul 1999 20:39:24 +0100
MIME-Version: 1.0
Content-type: text/plain; charset=US-ASCII
Content-transfer-encoding: 7BIT
Subject: Re: some comments on draft-chadwick-pkixldap-v3-00.txt
Reply-to: [e-mail]
CC: [e-mail]
Priority: normal
In-reply-to: <[e-mail]>
X-mailer: Pegasus Mail for Win32 (v3.01d)

Mark

Thankyou for your detailed comments.
In the test below, >> represents my original text and > represents 
Mark's comments and revised text

> 
> Section 2
> 
> In the first paragraph of this section you write:
> 
> > Other attribute description options SHOULD NOT be supported by clients.
> > Servers MAY choose to support them at their discretion.
> 
> This is problematic: if a server does support them but a client does not,
> then that client cannot read an attribute with an option returned by that
> server. I suggest your intent might be closer to the following statement:

My intent was to limit the coding effort of both clients and certificate 
servers. However I had only considered the case of requests with 
;options being sent from clients  to a server, and not vice versa as 
you had done. 

> 
> Other attribute description options SHOULD NOT be generated by clients,

Agreed.

> since servers MAY choose to support them at their discretion.

We dont need the since. Keep it as a separate sentence.

In fact ;options are only used for attribute hierarchies (attribute 
subtyping) and in the case of X.509 attributes (certs, CRLs, ACs 
etc) I believe we do not have any supertypes and subtypes so in 
reality the situation should not arise. However we should still cater 
for the possibility in the draft as above. 

> In the last paragraph of this section you write:
> 
> > This attribute MUST be stored in the root DSE of the server and MUST be
> > available to clients for retrieval. If no alternative servers exist this
> > attribute MUST point to the current server. 
> 
> The first MUST is redunant as this is the only location where the
> altServer attribute has been suggested. 

No its not redundant, because the LDAPv3 spec makes it optional 
and I wanted to make it mandatory. Hence the MUST was over 
storage, and not about the location. This same issue was raised by 
Rob Weltman of Netscape and this was my response to him

My rationale for making altServer mandatory is that CRLs 
(especially) should be available 24 hours a day 365 days a year. 
Thus a failsafe installation will have backup servers. These might be 
at different addresses or at the same address (a cluster for 
example), and altServer will say where they are located. Hence the 
reason for making it mandatory.

> Second, what I think you are
> trying to say is that it can't be filtered out by the server's access
> control policy.  

As you can see from the rationale above this was not my primary 
concern. But you are correct. If a relying party or subscriber has 
access to the CRLs then he should also have access to the altServer.
How about if we add the following text

The access controls on this MUST BE the same or less than those 
on the certificates and CRLs. 

>The next sentence however I disagree with: I don't see
> the value of a attribute pointing to itself. 

It tells the client that backup servers dont exist anywhere else.

> I would propose replacing
> this with
> 
> Deployments SHOULD provide for high availability of the directory, and
> this attribute of the root DSE MUST when present be visible to properly
> authenticated clients following this profile.
> 

I like your text as well as mine, but I think mine is slightly stronger. 
We are at the wordsmithing approach now I think, since we broadly 
agree on aims.

> Section 3
> 
> > Servers SHOULD be able to return referrals to clients. 
> > Clients SHOULD be able to receive referrals, although they are not
> > required to automatically process them and support multiple asynchronous
> > outgoing connections. 
> 
> The statement
> 
> > As a minimum, clients SHOULD be able to ask the user if the referrals
> > are be cached locally and added to the set of servers known to the
> > client. 
> 
> First, there is a typo "are be". 
Thanks

> Second, it is not always the case that a
> 'user', presuming human user, is available to be asked. The PKIX
> application may be part of an automated system.   

Agreed.

>Third, I don't see the
> relationship between caching and automatically following referrals: I may
> want to have a client automatically follow referrals without caching them.

I see the relationship as follows. A client that always automatically  
follows referrals by parallel processing does not need to cache 
them. The user (human or application) always contacts the same 
directory server and always gets a response. Clients that are not 
able to automatically follow referrals in parallel have to cache one of 
more of them at least temporarily (even if its only in memory), and 
then follow them in sequence. Therefore in order to speed up 
subsequent requests it would be preferrable if the client made a 
more permanent cache of remote servers and then asked the user 
which one to contact, so as to avoid subsequent sequential referral 
processing. Finally clients that cannot support automatic processing 
of referrals (either in parallel or sequentially) must be able to support 
caching of the user would not get a proper service. This is what I 
was trying to get at in my badly worded text.


>   I propose that this sentence be removed as it is not necessary to the
> protocol between the client and the server.
> 

However if we remove it we will need to alter the preceding sentence 
which states "they are not required to automatically 
process them"
If a client is not required to automatically 
process a referral, nor cache it, then the user 
would not be able to obtain a distributed service.

> Section 4
> 
> > 4. Features Of Ldapv3 That SHOULD NOT Be Supported
> 
> I don't like the title of this section.  It implies that it will limit
> interoperability should a client abandon an operation.  Furthermore, it is
> quite likely that a client will implement NOT ONLY this profile but
> others: a white pages profile, an access control profile, etc. I would
> prefer this section to be:
> 
> 4. Features Of Ldapv3 That Are Not Used by this Profile
> 

Completely agree with you. Done

> In the first paragraph
> 
> > The client SHOULD NOT support the ModifyDN, Compare and Abandon 
> > operations. The server MAY choose to support these operations at its
> > discretion.
> 
> The former sentence implies an interoperability problem with Compare and
> Abandon.  I think instead you are wanting to say that you are not using
> them. I don't see that the second sentence is needed.  I would suggest
> replacing this paragraph with
> 
> A client following this profile need not send the ModifyDN, Compare and
> Abandon operations.

Agreed. Done. But I have kept the second sentence for 
completeness sake.

> 
> The second paragraph:
> 
> > The LDAPv3 protocol is infinitely extensible via two mechanisms: 
> > extended operations and controls on existing operations. The client
> > SHOULD NOT generate any LDAPv3 protocol extensions (extended operations
> > or controls).  The server SHOULD NOT return any LDAPv3 protocol
> > extensions (extended operations or controls).
> 
> Some control defintions are useful and are non-critical.   Furthermore, a
> client which DOES send a control (remember SHOULD NOT allows situations
> where it is useful) needs a response.  I would suggest something more
> along the lines of: 
> 
> The LDAPv3 protocol is infinitely extensible via two mechanisms: 
> extended operations and controls on existing operations. The client does
> not need to generate any LDAPv3 protocol extensions (extended operations
> or controls) when following this profile. 

I am quite happy with this re-wording. However, if we consider 
making the server implementation easier, your rewording does not 
actually help does it.

> The server SHOULD NOT return
> any LDAPv3 protocol extensions (extended operations or controls) marked
> as critical except when requested by the client.
> 

This one is more difficult. I dont like your rewording. Firstly some 
controls are always critical and some are chosen to be so by the 
client. Extended operations are never marked critical. So I would 
propose the following re-wording

The server SHOULD NOT return any LDAPv3 protocol 
extensions (extended operations or controls) 
apart from supported controls which were marked 
as critical by the user.

> The third paragraph:
> 
> > LDAPv3 has the concept of unsolicited notifications that can be sent
> > from the server to the client. The server SHOULD NOT generate any
> > unsolicited notifications.
> 
> This contradicts the recommendations of the IETF operations area director,
> who requests that LDAP servers return an unsolicited notification to
> indicate that they are going down, so that a client can distinguish
> between a server failure and a network failure. 

I submit to a higher authority. I was not aware of this.

> I propose that this
> paragraph be replaced with:
> 
> LDAPv3 has the concept of unsolicited notifications that can be sent
> from the server to the client. A client MUST be prepared to accept
> unsolicited notifications defined in RFC 2251.
> 

DONE, and moved to the Must Support section

> Next paragraph:
> 
> > LDAPv3 allows the subschema supported by the server to be published in a
> > subschema subentry. Subschema publishing is not needed for normal PKI
> > use, therefore the client SHOULD NOT try to retrieve either the contents
> > of the subschema subentry or the pointer to it (held in the
> > subschemaSubentry attribute of the root DSE) from the server. The server
> > MAY publish its subschema at its discretion.
> 
> Again, the term "SHOULD NOT" contradicts the text of 2251-2256: which says
> that LDAP clients MAY.  

Conformance wise, I dont believe this is a problem, as a profile can 
always say it wont use a particular optional feature. So the issue is 
one of whether it is needed or not for PKIX.

>And the last sentence contradicts 2251-2256 which
> makes schema requirement a mandatory aspect.  

I am aware of this, but again, a profile can decide not to use a 
mandatory feature (I believe so, but I may be wrong),

>Furthermore, a client does
> need to access the subschema in order to determine the supported matching
> rule and matching rule use statements of the server to provide the check
> for the extensibleMatch functionality in the end of section 5. I would
> propose replacing this with:
> 

I agree that a skilled client implementation could make use of 
matching rule schema definitions and configure itself to use them or 
not with each server it talks to. I dont want to rule this out.

>  
> LDAPv3 allows the subschema supported by the server to be published in a
> subschema subentry. Clients following this profile which support
> invoking a search containing an extensible matching rule SHOULD use the

I prefer MAY here rather than SHOULD. What do you think

> subschemaSubentry attribute in the root DSE and retrieve the subschema
> to determine whether the server supports the matching rule described in
> section 5.  
> 
> Final paragraph:
> 
> > Operational attributes are attributes stored by the server that hold
> > administrative information. Clients SHOULD NOT request any operational
> > attributes from the server other than the altServer attribute, and the
> > server need not store any operational attributes other than altServer.
> 
> This contradicts X.500 and 2251-2252 which requires servers to maintain
> operational attributes.  

Again, I dont think it is a problem for a profile to omit certain 
features. I was trying to limit the complexity of certificate server.

>Again, this can be fixed in this document by
> changing the statement of client behavior and removing the requirement on
> server behavior.
> 
> Operational attributes are attributes stored by the server that hold
> administrative information. Clients following this profile do not need
> any operational attributes from the server, other than the altServer
> attribute of the root DSE.
> 

I am happy with this. DONE. But I would still like to keep
"The server need not store any operational attributes other than 
altServer."

> Section 5
> 
> First paragraph:
> 
> The term 'CPS' is not defined: an acronym expansion or reference to the
> defining text would be helpful for readers.
> 
DONE

> This draft uses "MUST" twice in the first paragraph for anonymous access,
> but uses "SHOULD" for password protection and certificate-based
> authentication. Could you explain why this is different?
> 

Relying parties must have access to CRLs or they cannot validate 
the signatures. IF the CPS allows unauthenticated access this must 
be a MUST as it is the only way of doing it. If the CPS allows 
password based access there are several ways of doing it - hashing 
or clear over TLS (recommended therefore SHOULD) or passwords 
in the clear (not recommended but possible, hence we dont have to 
mandate the other two methods).

> Also, there needs to be a statement that support for TLS SHOULD be present
> when the client and servers are operating in environments where a CPS may
> state that information is not publically available.  BTW, I assume that a
> CPS is machine readable?  

Unfortunately No. This is the topic of current research projects. So 
dont hold your breath. However, what happens in practice is that the 
CA sets its policy/practice then configures its clients to follow it.

>How does a server know when about to return a
> certificate or CRL that the CPS governing it requires confidentiality?

This would be configured into the server by the CA (indirectly)

> 
> Second paragraph:
> 
> There is a "may" which is not capitalized.

DONE, Ta

> 
> Last paragraph:
> 
> > The parameters of the Search operation for "read" or "search" type
> > queries will usually be set as specified in RFC 2559. 
> 
> Not quite, as a client will be using userCertificate;binary,
> caCertificate;binary, certificateRevocationList;binary, 
> authorityRevocationList;binary etc as described in RFC 2256.
> 

I have added

The userCertificate;binary, caCertificate;binary, 
certificateRevocationList;binary, and 
authorityRevocationList;binary attributes, if 
specified, will be set as described in RFC 2256 
[13]. 

> > However, X.509(1997) [9] supports flexible certificate matching by the
> > server, via the certificateMatch MATCHING-RULE. 
> 
> The OID and string representation of this matching rule should be given by
> this section, since the reference [9] is not suitable for a client to be
> able to implement it.  AFAIK it is not yet published. 

Correct. However it is publically available on the BULL server (which 
ironically is better than it being published, because once it is 
published it will no longer be publically available (for free). I checked 
up on other PKIX docs that are RFCs and this is what they 
reference. So I could change the reference to this.

[X509-AM] ISO/IEC JTC1/SC 21, Draft Amendments 
DAM 4 to ISO/IEC 9594-2, DAM 2 to ISO/IEC 9594-6, 
DAM 1 to ISO/IEC 9594-7, and DAM 1 to ISO/IEC 
9594-8 on Certificate Extensions, 1 December, 
1996.

I also agree that it would be good to repeat the 
OID in this document, along with the string 
represenation of the matching rule. Here is my 
text
"For convenience the string description of this 
matching rule is produced here:

( 2.5.13.35 NAME 'certificateMatch'
    SYNTAX 1.3.6.1.4.1.1466.115.121.1.54 )"

However I need you to add a new definition to 
LDAP syntaxes as below:

CertificateAssertion  N 
1.3.6.1.4.1.1466.115.121.1.54 

David


> If X.509(1997) is
> not expected to be published before this document goes into last call,
> perhaps this paragraph should be replaced by a statement that "Future
> revisions of this specification may take advantage of the extensibleMatch
> search filter item to locate certificates that match a particular pattern,
> as defined in forthcoming revisions of X.509."
> 
> 
> Mark Wahl, Directory Product Architect
> Innosoft International, Inc.
> 


***************************************************

David Chadwick
IT Institute, University of Salford, Salford M5 4WT
Tel [phone]  Fax [phone]
*NEW* Mobile [phone] *NEW*
Email [e-mail]
Home Page  http://www.salford.ac.uk/its024/chadwick.htm
Understanding X.500  http://www.salford.ac.uk/its024/X500.htm
X.500/LDAP Seminars http://www.salford.ac.uk/its024/seminars.htm
Entrust key validation string MLJ9-DU5T-HV8J

***************************************************


Received: from mailbox1.appliedtheory.com (mailbox1.appliedtheory.com [204.168.16.14]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id LAA02638 for <[e-mail]>; Wed, 14 Jul 1999 11:25:49 -0700 (PDT)
From: [e-mail]
Received: from eaglei-internet.ssg.bny.com (bk01.bankofny.com [160.254.115.80]) by mailbox1.appliedtheory.com (8.8.8/8.8.8) with SMTP id OAA03689; Wed, 14 Jul 1999 14:26:32 -0400 (EDT)
Received: from Hermes.bankofny.com by eaglei-internet.ssg.bny.com via smtpd (for mailbox1.appliedtheory.com [204.168.16.14]) with SMTP; 14 Jul 1999 18:26:32 UT
Received: from LNOTES5 by HERMES via SMTP with TCP; Wed, 14 Jul 99 14:24:00-EDT
Received: from LNOTES5 by HERMES via SMTP with TCP; Wed, 14 Jul 99 14:24:11-EDT
Received: by LNOTES5(Lotus SMTP MTA v1.2  (600.1 3-26-1998))  id 852567AE.00651FD1 ; Wed, 14 Jul 1999 14:24:32 -0400
X-Lotus-FromDomain: BNY
To: "Flanigan, Bill" <[e-mail]>
cc: "'Michael Myers'" <[e-mail]>, "'[e-mail]'" <[e-mail]>
Message-ID: <852567AE.004F5990.00@LNOTES5>
Date: Wed, 14 Jul 1999 14:24:30 -0400
Subject: Re: KISS for PKIX. (Was: RE: ASN.1 vs XML (used to be RE: I-D ACTION :draft-ietf-pkix-scvp- 00.txt))
Mime-Version: 1.0
Content-type: text/plain; charset=us-ascii
Content-Disposition: inline

>>Hello Mike,
>>
>>   You are on the right track (and so, I think, is Steve).  Before PKI
>>technologies (and other IETF *core* security protocol suites) can be
*main
>>streamed,* they must be made very easy to use across the board--from
>>implementers to developers to end (human) entities.  Some might object to
>>this as being *dumbed down,* but lack of interoperability due to overly
>>complex and convoluted multi-protocols (not to mention competing
protocols)
>>is a real problem.  So is the resulting complexity of use experienced by
EEs
>>(I could write volumes here!).  Unless we aim for the *lowest common
>>denominator,* CIOs will never be able to show ROIs to justify PKI (and
>>especially the PKIX favor of PKI) purchases.  We have probably all read
>>recent reports that Fortune 1,000 CEOs see IT, in general, and PKI, in
>>particular, as simply drains on profits; and in the UK, companies don't
seem
>>to be interested in PKI (and especially the PKIX flavor of PKI) at all.
As
>>usual, KISS is the key (no pun intended).  I fear that we do not have the
>>luxury of tossing things over the fence to *let the market decide.*  The
>>market may decide to pass.
>>
>>Bill
>>

I couldn't agree with you more. However, regarding acceptance of PKI
technologies by large organizations, I believe there are many reasons
organizations are not adopting PKI readily besides ease-of-use issues. Nor
does it have anything to do with ASN.1 vs XML. This issue can't be resolved
with technology solutions because their lack of acceptance is not due
solely to technical problems.

The problems with PKI are numerous, from a corporate perspective, and many
large organizations have not moved initial PKI efforts beyond the
pilot/evaluation stage. Problems include outstanding legal liability
issues, the lack of fraud protection laws, the need to address cessation of
activites of a CA and/or a registry, the inability to bind a certificate
distinctly to a user (software certificates identify systems, not users),
the inability of an issuer to associate a security policy with the
certificate (issuers need to be able to dictate when to allow caching of
passwords,as well as things like session timeout and password construction
rules), undefined procedures and products to support records management and
archiving, as well as that non-repudiation claims for current PKI products
may have no legal basis. Then there are all the technical problems.

There are interoperability issues, mostly because there are no products
that provide an infrastructure to support the PKI. There are point
solutions (certificate servers, directory servers, mail programs, browsers,
etc.) from multiple vendors that have to be woven together to create an
infrastructure. Consider that any organization that is using Lotus Notes
(ten years now ?) has been using certificates and public/private keys all
along and most did not even know they were. That is because Notes provides
an infrastructure to support its PKI, and hid most of the details from the
user. Any organization that treads into the latest PKI solutions for
anything other than SSL encryption quickly realizes something is missing.

Perhaps PKI will come of age when it is embedded in a smartcard. Just the
two-cents of someone who has looked at PKI for a large organization.
eric

//* opinions expressed are my own and not necessarily those of my employer
//*




Received: from pub.siac.com (pub.siac.com [162.69.5.194]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id JAA28405 for <[e-mail]>; Wed, 14 Jul 1999 09:11:13 -0700 (PDT)
Received: from bigmouth.siac.com(162.69.5.8) by pub.siac.com via smap (4.1) id xma025422; Wed, 14 Jul 99 12:11:20 -0400
Received: from siac.com (dfinkels@localhost [127.0.0.1]) by orchid.wisdom.siac.com (8.8.6 (PHNE_17135)/8.8.6) with ESMTP id MAA10433 for <[e-mail]>; Wed, 14 Jul 1999 12:11:16 -0400 (EDT)
Sender: [e-mail]
Message-ID: <[e-mail]>
Date: Wed, 14 Jul 1999 12:11:16 -0400
From: Daniel Finkelstein <[e-mail]>
Organization: Securities Industry Automation Corporation
X-Mailer: Mozilla 4.61 [en] (X11; U; HP-UX B.10.20 9000/879)
X-Accept-Language: en
MIME-Version: 1.0
To: "'[e-mail]'" <[e-mail]>
Subject: Re: ASN.1 vs XML (used to be RE:I-DACTION:draft-ietf-pkix-scvp-00.txt)
References: <[e-mail]>
Content-Type: text/html; charset=us-ascii
Content-Transfer-Encoding: 7bit

<!doctype html public "-//w3c//dtd html 4.0 transitional//en">
<html>
Aram Perez wrote:
<blockquote TYPE=CITE>Steve Kent wrote:
<p>> I think it is a rare user indeed who ever wants to look at a certificate.
<br>> Experience suggests that the certificate viewing feature of browsers
is
<br>> rarely invoked by the average user.
<p>That's because the average user (and I'm afraid a lot of people who
claim to
<br>understand public key cryptography/PKI) don't realize the need/requirement
<br>to verify root certificates with an out-of-band mechanism.
<p>Aram Perez</blockquote>
And these can get more complicated as operations differ. Such a verification
mechanism as provided by Netscape's security window only does so much;
presumably more when it retrieves certificates from directory servers.
To quote from the EntrustFile Toolkit documentation:
<br>&nbsp;
<blockquote>It is often asked why a user needs to log in just to verify
a digital signature. In order to verify a digital signature, it is first
necessary to prove that the sent verification public key certificate is
valid. The latter task requires the retrieval of a trusted copy of the
CA's verification certificate from the user's password-protected profile.
To open the user profile, the user needs to identify the profile and supply
the password for it -- in other words, the user needs to log in.</blockquote>

<pre>--&nbsp;
Daniel Alex Finkelstein
New Technologies
phone&nbsp;&nbsp; 212-383-2951
pager&nbsp;&nbsp; 917-427-1630
fax&nbsp;&nbsp;&nbsp;&nbsp; 212-383-3289
Securities Industry Automation Corporation</pre>
&nbsp;</html>



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 IAA27852 for <[e-mail]>; Wed, 14 Jul 1999 08:55:38 -0700 (PDT)
Received: from mailgate2.apple.com ([17.129.100.225]) by mail-out2.apple.com (8.8.5/8.8.5) with ESMTP id IAA12944 for <[e-mail]>; Wed, 14 Jul 1999 08:56:56 -0700
Received: from scv3.apple.com (scv3.apple.com) by mailgate2.apple.com (mailgate2.apple.com- SMTPRS 2.0.15) with ESMTP id <[e-mail]> for <[e-mail]>; Wed, 14 Jul 1999 08:56:47 -0700
Received: from [17.205.41.166] (aram1.apple.com [17.205.41.166]) by scv3.apple.com (8.9.3/8.9.3) with ESMTP id IAA16366 for <[e-mail]>; Wed, 14 Jul 1999 08:56:46 -0700
Message-Id: <[e-mail]>
X-Mailer: Microsoft Outlook Express Macintosh Edition - 4.5 (0410)
Date: Wed, 14 Jul 1999 08:56:46 -0700
Subject: Re: ASN.1 vs XML (used to be RE: I-DACTION:draft-ietf-pkix-scvp-00.txt)
From: "Aram Perez" <[e-mail]>
To: "'[e-mail]'" <[e-mail]>
MIME-Version: 1.0
X-Priority: 3
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: 7bit

Steve Kent wrote:

> I think it is a rare user indeed who ever wants to look at a certificate.
> Experience suggests that the certificate viewing feature of browsers is
> rarely invoked by the average user.

That's because the average user (and I'm afraid a lot of people who claim to
understand public key cryptography/PKI) don't realize the need/requirement
to verify root certificates with an out-of-band mechanism.

Aram Perez


Received: from localhost (daemon@localhost) by mail.proper.com (8.8.8/8.8.5) with SMTP id XAA06054; Tue, 13 Jul 1999 23:15:37 -0700 (PDT)
Received: by mail.imc.org (bulk_mailer v1.12); Tue, 13 Jul 1999 23:15:33 -0700
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 XAA06028 for <[e-mail]>; Tue, 13 Jul 1999 23:15:32 -0700 (PDT)
Received: from [128.33.238.250] (tc238-250.bbn.com [128.33.238.250]) by po1.bbn.com (8.9.1/8.9.1) with ESMTP id CAA15673; Wed, 14 Jul 1999 02:16:41 -0400 (EDT)
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Message-Id: <v04020a02b3b1da7827d4@[128.33.238.233]>
In-Reply-To: <[e-mail]>
References: <002201bec991$b0d12510$[e-mail]>		 <[e-mail]> <v04020a04b3abb1930baa@[128.89.0.110]> <v04020a04b3b09ba515d7@[128.33.238.237]>
Date: Wed, 14 Jul 1999 02:17:47 -0400
To: Ben Laurie <[e-mail]>
From: Stephen Kent <[e-mail]>
Subject: Re: I-D ACTION:draft-ietf-pkix-scvp-00.txt
Cc: PKIX-List <[e-mail]>
Precedence: bulk
List-Archive: http://www.imc.org/ietf-pkix/mail-archive/
List-Unsubscribe: mailto:[e-mail]?body=unsubscribe
X-UIDL: 724d7d3bb46fea7fb2fab08bb3e47be3

Ben,

>Leaving aside the attempt at a personal slight (which widely misses the
>mark, as I was not a developer of OpenSSL when this problem was current,
>and one of the first things I did as a developer was to fix it), I
>completely fail to see the distinction between the OpenSSL/SSLeay
>"developer community" and the "CA and X.500 product communities". Any CA
>or X.500 developer with any pretence at credibility will surely have
>tested SSLeay. In fact, many of them used it as the basis for their
>products.

There was no personal slight intended in my remarks, nor, in my reading,
none expressed.  There was, however, a pointed criticism of SSLeay, a
collection of software, not a standard.  I do disparge the notion that
standards are established by distributed software.

As the CTO of a CA product developer I can and do take exception with the
suggestion that use of SSLeay is relevant to core CA business.  We
developed our own ASN.1 compiler years ago, even sold it to some folks, and
have not found it necessary to avail ourselves of freeware.  I think your
sample of CA vendors and mine differ considerably.

>And when Peter Gutmann made that remark, he was certainly not referring
>to OpenSSL's standards conformance, as it was in the context of checking
>signatures in OpenSSL.

OpenSSL, what's the RFC for that protocol?  TLS is a standard, and SSL as a
proprietary protocol developed by browser vendors.

Steve


Received: from localhost (daemon@localhost) by mail.proper.com (8.8.8/8.8.5) with SMTP id XAA06321; Tue, 13 Jul 1999 23:17:26 -0700 (PDT)
Received: by mail.imc.org (bulk_mailer v1.12); Tue, 13 Jul 1999 23:17:26 -0700
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 XAA06294 for <[e-mail]>; Tue, 13 Jul 1999 23:17:25 -0700 (PDT)
Received: from [128.33.238.250] (tc238-250.bbn.com [128.33.238.250]) by po1.bbn.com (8.9.1/8.9.1) with ESMTP id CAA15716; Wed, 14 Jul 1999 02:18:34 -0400 (EDT)
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Message-Id: <v04020a03b3b1dc238c37@[128.33.238.250]>
In-Reply-To: <[e-mail]>
References: <v04020a03b3b0988158f8@[128.33.238.237]>
Date: Wed, 14 Jul 1999 02:19:20 -0400
To: Timothy Fisher <[e-mail]>
From: Stephen Kent <[e-mail]>
Subject: Re: ASN.1 vs XML (used to be RE: I-DACTION:draft-ietf-pkix-scvp-00.txt)
Cc: "'[e-mail]'" <[e-mail]>
Precedence: bulk
List-Archive: http://www.imc.org/ietf-pkix/mail-archive/
List-Unsubscribe: mailto:[e-mail]?body=unsubscribe
X-UIDL: 3d6990c59dda25c2480b5b7671a4c44a

Tim,

I think it is a rare user indeed who ever wants to look at a certificate.
Experience suggests that the certificate viewing feature of browsers is
rarely invoked by the average user.

Steve


Received: from localhost (daemon@localhost) by mail.proper.com (8.8.8/8.8.5) with SMTP id XAA07421; Tue, 13 Jul 1999 23:27:14 -0700 (PDT)
Received: by mail.imc.org (bulk_mailer v1.12); Tue, 13 Jul 1999 23:27:13 -0700
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 XAA07391 for <[e-mail]>; Tue, 13 Jul 1999 23:27:12 -0700 (PDT)
Received: from [128.33.238.250] (tc238-250.bbn.com [128.33.238.250]) by po1.bbn.com (8.9.1/8.9.1) with ESMTP id CAA16028; Wed, 14 Jul 1999 02:28:15 -0400 (EDT)
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Message-Id: <v04020a05b3b1dddbf391@[128.33.238.250]>
In-Reply-To: <[e-mail]>
Date: Wed, 14 Jul 1999 02:29:26 -0400
To: [e-mail]
From: Stephen Kent <[e-mail]>
Subject: Re: I-D ACTION:draft-ietf-pkix-scvp-00.txt
Cc: [e-mail]
Precedence: bulk
List-Archive: http://www.imc.org/ietf-pkix/mail-archive/
List-Unsubscribe: mailto:[e-mail]?body=unsubscribe
X-UIDL: dfca2005a7896da8d630c6aaa9ce6d53

peter,


>I must have missed this one, hidden as it was among the 1e6 other messages in
>this (mostly pointless) thread, or I would have commented on it... the "X.500
>product community" has a really appalling track record in getting things
>right
>(see also Rose, Marshall, "The Open Book" and various other publications).  I
>posted a message to this list a year or two back in which I took something
>like a dozen random certs off web pages and checked them, and all but one were
>invalid for one reason or another.  If this is the result of being
>careful, I'd
>hate to see what being careless is.

Marshall's book is rather out of date.  My comments were directed at more
recent experience in the area.

Your sample may not be too representative, especially with respect to the
topic at hand.  Do you know what products were used to generate the certs?
if not, then one cannot infer what part of the cert generation process has
gone wrong.  Also, were the errors in question encoding ones, relevant to
this debate, or did they have to do with the data values per se?

Steve


Received: from localhost (daemon@localhost) by mail.proper.com (8.8.8/8.8.5) with SMTP id SAA06908; Tue, 13 Jul 1999 18:29:09 -0700 (PDT)
Received: by mail.imc.org (bulk_mailer v1.12); Tue, 13 Jul 1999 18:28:43 -0700
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 SAA06761 for <[e-mail]>; Tue, 13 Jul 1999 18:28:43 -0700 (PDT)
Received: from mentat.verisign.com by caladan.verisign.com (8.8.5/BCH1.5) id SAA10421; Tue, 13 Jul 1999 18:28:15 -0700 (PDT)
Received: from newman.verisign.com by mentat.verisign.com (8.8.5/BCH1.0) id SAA01845; Tue, 13 Jul 1999 18:29:22 -0700 (PDT)
Received: by newman.verisign.com with Internet Mail Service (5.5.2448.0) id <N7XWF2FZ>; Tue, 13 Jul 1999 18:29:25 -0700
Message-ID: <[e-mail]>
From: Michael Myers <[e-mail]>
To: "'Stephen Kent'" <[e-mail]>, Anders Rundgren <[e-mail]>
Cc: "'Peter Sylvester'" <[e-mail]>, "'[e-mail]'" <[e-mail]>
Subject: RE: ASN.1 vs XML (used to be RE: I-D ACTION:draft-ietf-pkix-scvp- 00.txt)
Date: Tue, 13 Jul 1999 18:29:24 -0700
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2448.0)
Content-Type: text/plain; charset="iso-8859-1"
Precedence: bulk
List-Archive: http://www.imc.org/ietf-pkix/mail-archive/
List-Unsubscribe: mailto:[e-mail]?body=unsubscribe
X-UIDL: 62ddb5b29ce3857f667fd9b2c3e9c137

Steve,

I'll probably bring this point to your attention on the floor before you
read this email, but for the record (and further, for the benefit of those
unable to attend the Oslo session), I would claim that making PKI easy for
developers is a very good thing.  Your comment belows seems to modestly
suggest that such an objective is less worthy than it might ought to be.

Indeed, this principle was the primary motivation for OCSP's original
non-ASN.1 proposal.

Mike



> -----Original Message-----
> From: Stephen Kent [mailto:[e-mail]]
> Sent: Tuesday, July 13, 1999 12:28 AM
> To: Anders Rundgren
> Cc: 'Peter Sylvester'; '[e-mail]'
> Subject: RE: ASN.1 vs XML (used to be RE: I-D
> ACTION:draft-ietf-pkix-scvp-00.txt)
> 
> 
> Anders,
> 
> 
> >The important thing is that in order to make PKI a 
> main-stream technology
> >(which it is
> >not today), may require changes like going to XML as XML is likely to
> >at least replace EDI which is often used in the same contexts as
> >certificates (or
> >rather should be).  So if XML becomes the HTML (which is closer to a
> >"peoples movement" than a computer language) of business 
> messages, ASN.1
> >may be too obscure (few know it) and less satisfactory as a long-term
> >solution.
> >
> >This should be seen in the light of the fact that the only 
> main-stream
> >PKI-application
> >I can think about, is e-commerce.  As very few e-commerce 
> standards are ready
> >for prime time, there is plenty of room for new things.
> 
> There seems to be an implication here that mainstream users 
> want to be able
> to read the signed data in its native format, and thus XML encoding is
> preferable to DER.  But we know this is not true, i.e., 
> whatever has been
> signed will be decoded prior to display, and then rendered 
> for the user.
> So, it would seem that the use of an encoding scheme such as 
> XML would be
> more attractive for developers performing debugging, rather 
> than for users.
> 
> Steve
> 


Received: from localhost (daemon@localhost) by mail.proper.com (8.8.8/8.8.5) with SMTP id LAA19233; Tue, 13 Jul 1999 11:39:23 -0700 (PDT)
Received: by mail.imc.org (bulk_mailer v1.12); Tue, 13 Jul 1999 11:39:12 -0700
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 LAA19164 for <[e-mail]>; Tue, 13 Jul 1999 11:39:11 -0700 (PDT)
Received: from [128.33.238.233] (tc238-233.bbn.com [128.33.238.233]) by po1.bbn.com (8.9.1/8.9.1) with ESMTP id OAA16950; Tue, 13 Jul 1999 14:40:03 -0400 (EDT)
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
X-Sender: [e-mail] (Unverified)
Message-Id: <v04020a02b3b096fdfde5@[128.33.238.237]>
In-Reply-To: <[e-mail]>
Date: Tue, 13 Jul 1999 03:11:41 -0400
To: Michael Myers <[e-mail]>
From: Stephen Kent <[e-mail]>
Subject: RE: I-D ACTION:draft-ietf-pkix-scvp-00.txt
Cc: Stephen Kent <[e-mail]>, Ben Laurie <[e-mail]>, PKIX-List <[e-mail]>
Precedence: bulk
List-Archive: http://www.imc.org/ietf-pkix/mail-archive/
List-Unsubscribe: mailto:[e-mail]?body=unsubscribe
X-UIDL: 0e4c268744250686dedf14e7102e7f61

Mike,

>Let us however lose sight of the fact that certificates provide a very
>convenient vehicle for the transport of application-independant attributes.
>One's purchasing authority or purchase authorization authority isn't and
>shouldn't necessarily be restricted to a particular application context.  We
>run the risk otherwise of re-inventing the equivalent of a PKI for each
>application.

Agreed.  Just let's not go overboard.

Steve


Received: from localhost (daemon@localhost) by mail.proper.com (8.8.8/8.8.5) with SMTP id LAA19243; Tue, 13 Jul 1999 11:39:27 -0700 (PDT)
Received: by mail.imc.org (bulk_mailer v1.12); Tue, 13 Jul 1999 11:39:20 -0700
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 LAA19176 for <[e-mail]>; Tue, 13 Jul 1999 11:39:19 -0700 (PDT)
Received: from [128.33.238.233] (tc238-233.bbn.com [128.33.238.233]) by po1.bbn.com (8.9.1/8.9.1) with ESMTP id OAA16983; Tue, 13 Jul 1999 14:40:14 -0400 (EDT)
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
X-Sender: [e-mail] (Unverified)
Message-Id: <v04020a03b3b0988158f8@[128.33.238.237]>
In-Reply-To: <01BECC66.4D867320@HYDRA>
Date: Tue, 13 Jul 1999 03:28:07 -0400
To: Anders Rundgren <[e-mail]>
From: Stephen Kent <[e-mail]>
Subject: RE: ASN.1 vs XML (used to be RE: I-D ACTION:draft-ietf-pkix-scvp-00.txt)
Cc: "'Peter Sylvester'" <[e-mail]>, "'[e-mail]'" 	 <[e-mail]>
Precedence: bulk
List-Archive: http://www.imc.org/ietf-pkix/mail-archive/
List-Unsubscribe: mailto:[e-mail]?body=unsubscribe
X-UIDL: 913f46e2de8bad662fbada1abfae6f67

Anders,


>The important thing is that in order to make PKI a main-stream technology
>(which it is
>not today), may require changes like going to XML as XML is likely to
>at least replace EDI which is often used in the same contexts as
>certificates (or
>rather should be).  So if XML becomes the HTML (which is closer to a
>"peoples movement" than a computer language) of business messages, ASN.1
>may be too obscure (few know it) and less satisfactory as a long-term
>solution.
>
>This should be seen in the light of the fact that the only main-stream
>PKI-application
>I can think about, is e-commerce.  As very few e-commerce standards are ready
>for prime time, there is plenty of room for new things.

There seems to be an implication here that mainstream users want to be able
to read the signed data in its native format, and thus XML encoding is
preferable to DER.  But we know this is not true, i.e., whatever has been
signed will be decoded prior to display, and then rendered for the user.
So, it would seem that the use of an encoding scheme such as XML would be
more attractive for developers performing debugging, rather than for users.

Steve


Received: from localhost (daemon@localhost) by mail.proper.com (8.8.8/8.8.5) with SMTP id LAA19237; Tue, 13 Jul 1999 11:39:23 -0700 (PDT)
Received: by mail.imc.org (bulk_mailer v1.12); Tue, 13 Jul 1999 11:39:22 -0700
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 LAA19201 for <[e-mail]>; Tue, 13 Jul 1999 11:39:21 -0700 (PDT)
Received: from [128.33.238.233] (tc238-233.bbn.com [128.33.238.233]) by po1.bbn.com (8.9.1/8.9.1) with ESMTP id OAA17004; Tue, 13 Jul 1999 14:40:24 -0400 (EDT)
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
X-Sender: [e-mail] (Unverified)
Message-Id: <v04020a04b3b09ba515d7@[128.33.238.237]>
In-Reply-To: <[e-mail]>
References: <002201bec991$b0d12510$[e-mail]>	 <[e-mail]> <v04020a04b3abb1930baa@[128.89.0.110]>
Date: Tue, 13 Jul 1999 03:39:38 -0400
To: Ben Laurie <[e-mail]>
From: Stephen Kent <[e-mail]>
Subject: Re: I-D ACTION:draft-ietf-pkix-scvp-00.txt
Cc: PKIX-List <[e-mail]>
Precedence: bulk
List-Archive: http://www.imc.org/ietf-pkix/mail-archive/
List-Unsubscribe: mailto:[e-mail]?body=unsubscribe
X-UIDL: b198cc1950d8e9b5360dff255e66aab8

Ben,

>Stephen Kent wrote:
>>         - depending on the  context, Ben is right that one might be able to
>> avoid some of the issues that motivate the use of DER in ASN.1. however,
>> our experience with PEM development back in the late 80s showed the need
>> for canonical representations in other than just certificates, with regard
>> to signed data structures.
>
>Showed how?

RFC 822 specifies a canonicalization algorithm for simple text messages.
Messages are stored en route and often mail gateways modify text in an
effort to be "helpful."  So, in PEM we performed the 822 processing to
ensure a canonical format prior to signing, and developed the base64
encoding technique (now used in MIME) to discourage mail gateways from
modifying the signed text.

>>  I disagree with Ben's comments re DER.  while
>> it is certainly true that people have made mistakes in implementing DER, I
>> think we are in pretty good shape these days and I'm not aware of any
>> lingering issues now.
>
>Well, OpenSSL seems to have a fair few workarounds for broken
>implementations, and Peter Gutmann recently commented that the only way
>to check signatures reliably was to keep the original binary data,
>because reconstruction didn't work.
>
>OpenSSL/SSLeay itself failed to correctly construct SETs for years and
>no-one noticed.

This seems to be an example of sloppy work, embraced by a developer
community which did inadequate testing.  In contrast, folks working in the
CA and X.500 product communities, and those who used ASN for various ISO
protocols, seem to have been more careful, or have had more time to find an
fix errors.  I stand by my comments.

Steve


Received: from localhost (daemon@localhost) by mail.proper.com (8.8.8/8.8.5) with SMTP id NAA22521; Tue, 13 Jul 1999 13:31:50 -0700 (PDT)
Received: by mail.imc.org (bulk_mailer v1.12); Tue, 13 Jul 1999 13:31:49 -0700
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 NAA22499 for <[e-mail]>; Tue, 13 Jul 1999 13:31:46 -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 UAA01795; Tue, 13 Jul 1999 20:32:38 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 VAA26664; Tue, 13 Jul 1999 21:33:02 +0100
Message-ID: <[e-mail]>
Date: Tue, 13 Jul 1999 21:32:38 +0100
From: Ben Laurie <[e-mail]>
Organization: A.L. Group plc
X-Mailer: Mozilla 4.08 [en] (WinNT; I)
MIME-Version: 1.0
To: Stephen Kent <[e-mail]>
CC: PKIX-List <[e-mail]>
Subject: Re: I-D ACTION:draft-ietf-pkix-scvp-00.txt
References: <002201bec991$b0d12510$[e-mail]>	 <[e-mail]> <v04020a04b3abb1930baa@[128.89.0.110]> <v04020a04b3b09ba515d7@[128.33.238.237]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Precedence: bulk
List-Archive: http://www.imc.org/ietf-pkix/mail-archive/
List-Unsubscribe: mailto:[e-mail]?body=unsubscribe
X-UIDL: bd49976a245c3a599b982a71e3cc9cb4

Stephen Kent wrote:
> >>  I disagree with Ben's comments re DER.  while
> >> it is certainly true that people have made mistakes in implementing DER, I
> >> think we are in pretty good shape these days and I'm not aware of any
> >> lingering issues now.
> >
> >Well, OpenSSL seems to have a fair few workarounds for broken
> >implementations, and Peter Gutmann recently commented that the only way
> >to check signatures reliably was to keep the original binary data,
> >because reconstruction didn't work.
> >
> >OpenSSL/SSLeay itself failed to correctly construct SETs for years and
> >no-one noticed.
> 
> This seems to be an example of sloppy work, embraced by a developer
> community which did inadequate testing.  In contrast, folks working in the
> CA and X.500 product communities, and those who used ASN for various ISO
> protocols, seem to have been more careful, or have had more time to find an
> fix errors.  I stand by my comments.

Leaving aside the attempt at a personal slight (which widely misses the
mark, as I was not a developer of OpenSSL when this problem was current,
and one of the first things I did as a developer was to fix it), I
completely fail to see the distinction between the OpenSSL/SSLeay
"developer community" and the "CA and X.500 product communities". Any CA
or X.500 developer with any pretence at credibility will surely have
tested SSLeay. In fact, many of them used it as the basis for their
products.

And when Peter Gutmann made that remark, he was certainly not referring
to OpenSSL's standards conformance, as it was in the context of checking
signatures in OpenSSL.

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 localhost (daemon@localhost) by mail.proper.com (8.8.8/8.8.5) with SMTP id NAA22863; Tue, 13 Jul 1999 13:39:29 -0700 (PDT)
Received: by mail.imc.org (bulk_mailer v1.12); Tue, 13 Jul 1999 13:39:28 -0700
Received: from mail.rdc1.az.home.com ([e-mail] [24.1.240.66]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id NAA22841 for <[e-mail]>; Tue, 13 Jul 1999 13:39:28 -0700 (PDT)
Received: from earthlink.net ([24.1.214.107]) by mail.rdc1.az.home.com (InterMail v4.01.01.00 201-229-111) with ESMTP id <[e-mail]>; Tue, 13 Jul 1999 13:40:40 -0700
Message-ID: <[e-mail]>
Date: Tue, 13 Jul 1999 13:43:12 -0700
From: Timothy Fisher <[e-mail]>
X-Mailer: Mozilla 4.61 [en] (WinNT; I)
X-Accept-Language: en
MIME-Version: 1.0
To: Stephen Kent <[e-mail]>
CC: Anders Rundgren <[e-mail]>, "'Peter Sylvester'" <[e-mail]>, "'[e-mail]'" <[e-mail]>
Subject: Re: ASN.1 vs XML (used to be RE: I-DACTION:draft-ietf-pkix-scvp-00.txt)
References: <v04020a03b3b0988158f8@[128.33.238.237]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Precedence: bulk
List-Archive: http://www.imc.org/ietf-pkix/mail-archive/
List-Unsubscribe: mailto:[e-mail]?body=unsubscribe
X-UIDL: c3ec4e9a6cfa28695bab522ca3713c01

Although your right that developers would benefit greatly in having an easier time
with debugging, users would also benefit.  I am certain there are times when end
users would like to view for example a certificate, but can not do so unless they
have an ASN.1/DER certificate decoder.  XML is much more readable to the average
user.

Tim

Stephen Kent wrote:

> Anders,
>
> >The important thing is that in order to make PKI a main-stream technology
> >(which it is
> >not today), may require changes like going to XML as XML is likely to
> >at least replace EDI which is often used in the same contexts as
> >certificates (or
> >rather should be).  So if XML becomes the HTML (which is closer to a
> >"peoples movement" than a computer language) of business messages, ASN.1
> >may be too obscure (few know it) and less satisfactory as a long-term
> >solution.
> >
> >This should be seen in the light of the fact that the only main-stream
> >PKI-application
> >I can think about, is e-commerce.  As very few e-commerce standards are ready
> >for prime time, there is plenty of room for new things.
>
> There seems to be an implication here that mainstream users want to be able
> to read the signed data in its native format, and thus XML encoding is
> preferable to DER.  But we know this is not true, i.e., whatever has been
> signed will be decoded prior to display, and then rendered for the user.
> So, it would seem that the use of an encoding scheme such as XML would be
> more attractive for developers performing debugging, rather than for users.
>
> Steve



Received: from localhost (daemon@localhost) by mail.proper.com (8.8.8/8.8.5) with SMTP id MAA21278; Tue, 13 Jul 1999 12:52:06 -0700 (PDT)
Received: by mail.imc.org (bulk_mailer v1.12); Tue, 13 Jul 1999 12:51:59 -0700
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 MAA21255 for <[e-mail]>; Tue, 13 Jul 1999 12:51: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 VAA25117 for <[e-mail]>; Tue, 13 Jul 1999 21:53:02 +0200
Received: from mega (t4o69p13.telia.com [62.20.145.133]) by caesar.udac.se (8.7.3/NetworkC-1) with SMTP id VAA112432; Tue, 13 Jul 1999 21:53:01 +0200
Message-ID: <002001becd71$5dad4e70$[e-mail]>
From: "Anders Rundgren" <[e-mail]>
To: "PKIX-List" <[e-mail]>, "Stephen Kent" <[e-mail]>
Subject: Re: ASN.1 vs XML (used to be RE: I-DACTION:draft-ietf-pkix-scvp-00.txt)
Date: Tue, 13 Jul 1999 21:50:39 +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.3110.5
X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by mail.proper.com id MAA21256
Precedence: bulk
List-Archive: http://www.imc.org/ietf-pkix/mail-archive/
List-Unsubscribe: mailto:[e-mail]?body=unsubscribe
X-UIDL: 836c0bf9372496e92c32b230f4154eef

<snip>
>There seems to be an implication here that mainstream users want to be able
>to read the signed data in its native format, and thus XML encoding is
>preferable to DER.  But we know this is not true, i.e., whatever has been
>signed will be decoded prior to display, and then rendered for the user.
>So, it would seem that the use of an encoding scheme such as XML would be
>more attractive for developers performing debugging, rather than for users.
>


Steve, I was a little bit unclear I think.  By users I referred to Issuers and RPs
who could benefit (as U point out) from a language format that lends itself to debugging.

Anders



Received: from localhost (daemon@localhost) by mail.proper.com (8.8.8/8.8.5) with SMTP id OAA24089; Tue, 13 Jul 1999 14:27:59 -0700 (PDT)
Received: by mail.imc.org (bulk_mailer v1.12); Tue, 13 Jul 1999 14:27:56 -0700
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 OAA24061 for <[e-mail]>; Tue, 13 Jul 1999 14:27:51 -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 JAA08833 for <[e-mail]>; Wed, 14 Jul 1999 09:28:50 +1200 (NZST) (sender [e-mail])
Received: by cs26.cs.auckland.ac.nz (relaymail v0.9) id <93190132923994>; Wed, 14 Jul 1999 09:28:49 (NZST)
From: [e-mail] (Peter Gutmann)
To: [e-mail]
Subject: Re: I-D ACTION:draft-ietf-pkix-scvp-00.txt
Sender: [e-mail]
Reply-To: [e-mail]
X-Charge-To: pgut001
X-Authenticated: relaymail v0.9 on cs26.cs.auckland.ac.nz
Date: Wed, 14 Jul 1999 09:28:49 (NZST)
Message-ID: <[e-mail]>
Precedence: bulk
List-Archive: http://www.imc.org/ietf-pkix/mail-archive/
List-Unsubscribe: mailto:[e-mail]?body=unsubscribe
X-UIDL: 5016b65673118fe4610b5e006fa267e1

Ben Laurie <[e-mail]>

>Stephen Kent wrote:
>>This seems to be an example of sloppy work, embraced by a developer
>>community which did inadequate testing.  In contrast, folks working in the
>>CA and X.500 product communities, and those who used ASN for various ISO
>>protocols, seem to have been more careful, or have had more time to find an
>>fix errors.  I stand by my comments.

I must have missed this one, hidden as it was among the 1e6 other messages in
this (mostly pointless) thread, or I would have commented on it... the "X.500 
product community" has a really appalling track record in getting things right 
(see also Rose, Marshall, "The Open Book" and various other publications).  I 
posted a message to this list a year or two back in which I took something 
like a dozen random certs off web pages and checked them, and all but one were
invalid for one reason or another.  If this is the result of being careful, I'd
hate to see what being careless is.

>And when Peter Gutmann made that remark, he was certainly not referring to 
>OpenSSL's standards conformance, as it was in the context of checking 
>signatures in OpenSSL.

Exactly.  SSLeay/OpenSSL is one of the more correct implementations out there.

Can we please finally let this XML debate rest?  If anyone really believes XML
is the way to go then do what I suggested in a previous message, rebuild X.500
in XML and let the market decide[0].

Sheesh, now look what you've made me do, I'm agreeing with Alan Lloyd over
something.

Peter (who really didn't want to contribute yet another message to this thing, 
       but doesn't see any hope of the thread dying any time soon.  Could 
	   someone please finally mention Nazis and get it over with?)

[0] That message was intended as sarcasm/silliness BTW, apparently some people 
    took it seriously.



Received: from localhost (daemon@localhost) by mail.proper.com (8.8.8/8.8.5) with SMTP id IAA16573; Tue, 13 Jul 1999 08:54:01 -0700 (PDT)
Received: by mail.imc.org (bulk_mailer v1.12); Tue, 13 Jul 1999 08:54:00 -0700
Received: from mtiwmhc01.worldnet.att.net (mtiwmhc01.worldnet.att.net [204.127.131.36]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id IAA16551 for <[e-mail]>; Tue, 13 Jul 1999 08:53:59 -0700 (PDT)
Received: from btw.btw.net ([12.72.202.36]) by mtiwmhc01.worldnet.att.net (InterMail v03.02.07.07 118-134) with SMTP id <[e-mail]> for <[e-mail]>; Tue, 13 Jul 1999 15:54:40 +0000
Received: by btw.btw.net with Microsoft Mail id <[e-mail]>; Tue, 13 Jul 1999 08:54:59 -0700
Message-ID: <[e-mail]>
From: Russ Savage <[e-mail]>
To: "'[e-mail]'" <[e-mail]>
Subject: RE: Certicate Format Independence
Date: Tue, 13 Jul 1999 08:54:33 -0700
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Precedence: bulk
List-Archive: http://www.imc.org/ietf-pkix/mail-archive/
List-Unsubscribe: mailto:[e-mail]?body=unsubscribe
X-UIDL: 06ea76ab5dc1689dbb90493889dc3c51

(Caution: newbie comments)

I went to sleep last night thinking about this phrase "bits-on-
the-wire or blob of bits." And thinking how everything builds 
from "bits on the wire." Even back in the "old" days when I 
was learning Fortran using Hollerenth punch cards. A byte is 
bits on the wire but files, fields and records build on bytes in 
dozens of "standards" - EBCDIC, ASCII, Unicode, and so on. 
The point is that once you get past "bits," you are into blob-of-bits-
on-the-wire. I don't think it's either-or - it's both, meaning 
structured bits on the wire. The problem sounds to my newbie ears 
like trying to define byte, field and record all in one standard - after 
IBM, Digital, Apple and Microsoft have started selling divergent 
stuff.

Which is where I think the XML attraction comes from. But I 
agree that the bit/blob-on-the-wire standard should be neutral about 
the "program" that reads it (XML, Java, C++, who cares). My 
understanding of ANS.1/BER/DER is that there is a structure of 
objects where some are ambiguous about when, why and how they 
are used. Sounds a little like saying this is a byte which means this 
if its EBCDIC but that if its ASCII and this other if its Unicode. 
(I know it's more like a field in a record that we sometimes use &
sometimes ignore - depending on who "we" are - 
but play with me here)

Maybe there needs to be nested standards just as there are 
for byte types, which lead to different file types (PKIX 
profiles) with differing record and field types. If I use ASCII 
and I know the incoming file is in EBCDIC, then can I convert 
on the fly. The same could happen here with a decoder 
becoming a collection of objects and my decoder looks at the 
certificate, attempts to figure out the profile (format type) and 
run it through the appropriate decoding object. As it is, 
I have to do that anyway so why not tighten it up.

As a user of PKI, I'm less concerned about a single, global 
set of rules than I am about rules that are consistent over 
time. I need to be able to create a digital signature that will 
be legally enforceable for years regardless of the changes to 
the standard (or cert revocation, etc). To me that's a 
consistent data structure (a blob in a bit stream) that I can read 
on any platform using any decoder compliant with the data 
structure version the cert is in.

What that implies is a "gold standard" bit stream structure 
that any cert can be translated to and behave in a standard, 
consistent way. I doubt we can throw out ANS.1 at this point. 
(we at least would have to have backward compatible decoding)
But, from what I know, it definitely needs to be made less 
ambiguous. Even if that means flavors ala EBCDIC and 
ASCII in the byte world - if the cert is this flavor, then the bit 
stream consistently reads this way but if it is this other flavor, 
then it consistently reads this other way.

I agree with this statement: "In order for the data structure to 
be verified, the verifier needs the same bit stream as the 
signer used. That is why using BER (as someone earlier 
suggested) is wrong, because BER allows more than one bit 
stream to represent that same value." It does not follow that 
there can only be one set of rules for all bit streams, 
merely that the rules for that particular bit stream structure 
be known (identifiable by the decoder) and consistently used 
(the decoder "knows" the rules to use for that structure).

My vote : the decode default is the mush we have now, 
but we build tighter structure(s) from here on out.

The question then is cross-certification - I think it's possible,
maybe even easier, if you have strictly defined sets of 
date/rules to compare - 
even if the rules are in two different profiles/structures.

Russ Savage
[e-mail]


Received: from localhost (daemon@localhost) by mail.proper.com (8.8.8/8.8.5) with SMTP id JAA17105; Tue, 13 Jul 1999 09:22:12 -0700 (PDT)
Received: by mail.imc.org (bulk_mailer v1.12); Tue, 13 Jul 1999 09:22:09 -0700
Received: from THOR.INNOSOFT.COM ([e-mail] [192.160.253.66]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id JAA17083 for <[e-mail]>; Tue, 13 Jul 1999 09:22:09 -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]; Tue, 13 Jul 1999 09:22:20 PDT
Received: from threadgill.austin.innosoft.com (threadgill.austin.innosoft.com [207.8.108.5]) by austin.innosoft.com (PMDF V5.2-31 #13579) with SMTP id <[e-mail]>; Tue, 13 Jul 1999 11:22:18 -0500 (CDT)
Date: Tue, 13 Jul 1999 11:22:17 -0500
From: Mark Wahl <[e-mail]>
Subject: some comments on draft-chadwick-pkixldap-v3-00.txt
Sender: [e-mail]
To: [e-mail]
Cc: [e-mail]
Cc: [e-mail]
Message-id: <[e-mail]>
Precedence: bulk
List-Archive: http://www.imc.org/ietf-pkix/mail-archive/
List-Unsubscribe: mailto:[e-mail]?body=unsubscribe
X-UIDL: bb3367bd480e367479e824d80c9bcc04

Section 2

In the first paragraph of this section you write:

> Other attribute description options SHOULD NOT be supported by clients. 
> Servers MAY choose to support them at their discretion.

This is problematic: if a server does support them but a client does not, then
that client cannot read an attribute with an option returned by that server.
I suggest your intent might be closer to the following statement:

> Other attribute description options SHOULD NOT be generated by clients, 
> since servers MAY choose to support them at their discretion.

In the last paragraph of this section you write:

> This attribute MUST be stored in the root DSE of the server and MUST be 
> available to clients for retrieval. If no alternative servers exist this 
> attribute MUST point to the current server. 

The first MUST is redunant as this is the only location where the altServer
attribute has been suggested.  Second, what I think you are trying to say is
that it can't be filtered out by the server's access control policy.  The 
next sentence however I disagree with: I don't see the value of a attribute
pointing to itself.  I would propose replacing this with

> Deployments SHOULD provide for high availability of the directory, and this 
> attribute of the root DSE MUST when present be visible to properly 
> authenticated clients following this profile.

Section 3

> Servers SHOULD be able to return referrals to clients. 
> Clients SHOULD be able to receive referrals, although they are not required 
> to automatically process them and support multiple asynchronous outgoing 
> connections. 

The statement

> As a minimum, clients SHOULD be able to ask the user if the referrals are be
> cached locally and added to the set of servers known to the client. 

First, there is a typo "are be".  Second, it is not always the case that a
'user', presuming human user, is available to be asked.  The PKIX application
may be part of an automated system.  Third, I don't see the relationship 
between caching and automatically following referrals: I may want to have a 
client automatically follow referrals without caching them.   I propose that
this sentence be removed as it is not necessary to the protocol between the
client and the server.

Section 4

> 4. Features Of Ldapv3 That SHOULD NOT Be Supported

I don't like the title of this section.  It implies that it will limit 
interoperability should a client abandon an operation.  Furthermore, it is 
quite likely that a client will implement NOT ONLY this profile but others: 
a white pages profile, an access control profile, etc. I would prefer this
section to be:

> 4. Features Of Ldapv3 That Are Not Used by this Profile

In the first paragraph

> The client SHOULD NOT support the ModifyDN, Compare and Abandon 
> operations. The server MAY choose to support these operations at its 
> discretion.

The former sentence implies an interoperability problem with Compare and 
Abandon.  I think instead you are wanting to say that you are not using them. 
I don't see that the second sentence is needed.  I would suggest replacing this
paragraph with

> A client following this profile need not send the ModifyDN, Compare and 
> Abandon operations.

The second paragraph:

> The LDAPv3 protocol is infinitely extensible via two mechanisms: 
> extended operations and controls on existing operations. The client 
> SHOULD NOT generate any LDAPv3 protocol extensions (extended 
> operations or controls).  The server SHOULD NOT return any LDAPv3 
> protocol extensions (extended operations or controls).

Some control defintions are useful and are non-critical.   Furthermore, a 
client which DOES send a control (remember SHOULD NOT allows situations where
it is useful) needs a response.  I would suggest something more along the 
lines of: 

> The LDAPv3 protocol is infinitely extensible via two mechanisms: 
> extended operations and controls on existing operations. The client 
> does not need to generate any LDAPv3 protocol extensions (extended 
> operations or controls) when following this profile.  The server 
> SHOULD NOT return any LDAPv3 protocol extensions (extended operations 
> or controls) marked as critical except when requested by the client.

The third paragraph:

> LDAPv3 has the concept of unsolicited notifications that can be sent 
> from the server to the client. The server SHOULD NOT generate any 
> unsolicited notifications.

This contradicts the recommendations of the IETF operations area director, 
who requests that LDAP servers return an unsolicited notification to indicate
that they are going down, so that a client can distinguish between a server 
failure and a network failure.  I propose that this paragraph be replaced with:

> LDAPv3 has the concept of unsolicited notifications that can be sent 
> from the server to the client. A client MUST be prepared to accept
> unsolicited notifications defined in RFC 2251.

Next paragraph:

> LDAPv3 allows the subschema supported by the server to be published 
> in a subschema subentry. Subschema publishing is not needed for 
> normal PKI use, therefore the client SHOULD NOT try to retrieve 
> either the contents of the subschema subentry or the pointer to it 
> (held in the subschemaSubentry attribute of the root DSE) from the 
> server. The server MAY publish its subschema at its discretion.

Again, the term "SHOULD NOT" contradicts the text of 2251-2256: which says
that LDAP clients MAY.  And the last sentence contradicts 2251-2256 which 
makes schema requirement a mandatory aspect.  Furthermore, a client does
need to access the subschema in order to determine the supported matching
rule and matching rule use statements of the server to provide the check
for the extensibleMatch functionality in the end of section 5. 
I would propose replacing this with:

> 
> LDAPv3 allows the subschema supported by the server to be published 
> in a subschema subentry. Clients following this profile which support
> invoking a search containing an extensible matching rule SHOULD use the
> subschemaSubentry attribute in the root DSE and retrieve the subschema
> to determine whether the server supports the matching rule described in
> section 5.  

Final paragraph:

> Operational attributes are attributes stored by the server that hold 
> administrative information. Clients SHOULD NOT request any 
> operational attributes from the server other than the altServer 
> attribute, and the server need not store any operational attributes 
> other than altServer.

This contradicts X.500 and 2251-2252 which requires servers to maintain
operational attributes.  Again, this can be fixed in this document by
changing the statement of client behavior and removing the requirement
on server behavior.

> Operational attributes are attributes stored by the server that hold 
> administrative information. Clients following this profile do not need
> any operational attributes from the server, other than the altServer 
> attribute of the root DSE.

Section 5

First paragraph:

The term 'CPS' is not defined: an acronym expansion or reference to the 
defining text would be helpful for readers.

This draft uses "MUST" twice in the first paragraph for anonymous access,
but uses "SHOULD" for password protection and certificate-based authentication.
Could you explain why this is different?

Also, there needs to be a statement that support for TLS SHOULD be present 
when the client and servers are operating in environments where a CPS may 
state that information is not publically available.  BTW, I assume that a 
CPS is machine readable?  How does a server know when about to return a 
certificate or CRL that the CPS governing it requires confidentiality?

Second paragraph:

There is a "may" which is not capitalized.

Last paragraph:

> The parameters of the Search operation for "read" or "search" type 
> queries will usually be set as specified in RFC 2559. 

Not quite, as a client will be using userCertificate;binary,
caCertificate;binary, certificateRevocationList;binary, 
authorityRevocationList;binary etc as described in RFC 2256.

> However, X.509(1997) [9] supports flexible certificate matching by the 
> server, via the certificateMatch MATCHING-RULE. 

The OID and string representation of this matching rule should be given 
by this section, since the reference [9] is not suitable for a client to
be able to implement it.  AFAIK it is not yet published.  If X.509(1997)
is not expected to be published before this document goes into last call, 
perhaps this paragraph should be replaced by a statement that "Future
revisions of this specification may take advantage of the extensibleMatch
search filter item to locate certificates that match a particular pattern,
as defined in forthcoming revisions of X.509."


Mark Wahl, Directory Product Architect
Innosoft International, Inc.


Received: from localhost (daemon@localhost) by mail.proper.com (8.8.8/8.8.5) with SMTP id KAA17720; Tue, 13 Jul 1999 10:05:44 -0700 (PDT)
Received: by mail.imc.org (bulk_mailer v1.12); Tue, 13 Jul 1999 10:05:42 -0700
Received: from www.meridianus.com (209.249.223.17.has.no.reverse [209.249.223.17] (may be forged)) by mail.proper.com (8.8.8/8.8.5) with ESMTP id KAA17698 for <[e-mail]>; Tue, 13 Jul 1999 10:05:42 -0700 (PDT)
Received: from pc1 by www.meridianus.com (8.8.8+Sun/SMI-SVR4) id LAA01576; Tue, 13 Jul 1999 11:01:27 -0700 (PDT)
Message-ID: <021201becd51$fecebfc0$[e-mail]>
From: "[e-mail]" <[e-mail]>
To: "Alan Lloyd" <[e-mail]>, "''PKIX-List' '" <[e-mail]>, "'Andrew Probert '" <[e-mail]>
References: <D1A949D4508DD1119C8100400533BEDC125418@DSG1>
Subject: Re: ASN.1 vs XML (used to be RE: I-D ACTION:draft-ietf-pkix-scvp- 00.txt)
Date: Tue, 13 Jul 1999 10:06:03 -0700
Organization: Meridianus
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.00.2314.1300
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300
Precedence: bulk
List-Archive: http://www.imc.org/ietf-pkix/mail-archive/
List-Unsubscribe: mailto:[e-mail]?body=unsubscribe
X-UIDL: 542b137bd956126f8313a532be065663

----- Original Message -----
From: Alan Lloyd <[e-mail]>
To: ''PKIX-List' ' <[e-mail]>; 'Andrew Probert '
<[e-mail]>
Sent: Tuesday, July 13, 1999 8:01 AM
Subject: RE: ASN.1 vs XML (used to be RE: I-D ACTION:draft-ietf-pkix-scvp-
00.txt)


> Andrew - stop being so direct :-)
>
> What we need to do is support a ASN.1 replacement program for
> SNMP, PKCS standards, traffic management standards and onboard
> equipment, financial standards, Defence standards, OCSP, LDAP, X.500 and
> LDAP objects, etc, etc  and redefine all the object identifiers in the
> world as their syntax would change - as the format of these  are defined
> in the ASN.1 standard...Thats all :-)

I want to be clear about what I was saying by way of XML v. ASN.1; I dont
think that XML is 'better' than ASN.1 for representing the cert in, but I do
think that there is no reason that an XML representation of the cert
structure is also not an issue. The cert structure is the cert structure and
who cares what it is represented in. The fact that ASN.1 is the 'official'
language and syntax used to represent ISO models is neat and spiffy, but the
fact that the industry is gravitating towards using XML is another big
reason that cert formats should be recognized as being representation
independent.

>
> I get the impression this thread is based on the issue that a
> certificate format is better in XML rather than ASN.1 - rather than the
> knowledge that ASN.1 represents the Presentation layer of the OSI
> reference model in that it maps internal application layer structures in
> C, etc (the internal syntax) to the transfer syntax TLV system  (ASN.1
> BER/DER) via the production of code/definitions derived from an ASN.1
> compiler using the input of ASN.1 definitions ... as provided in the
> respective standards. Standard which relate to the development of
> distributed applications.
>
>
> Perhaps some reading on the application of ASN.1 as a distributed
> information systems tool and the application of Object Identifiers for
> protocol and information and where this approach to systems is used
> might sway the decision here..

No, there is no need IMHO (not that I was ever humble...)..

The sheer fact of what XML is and the position it has within the IETF and
other standards orgs, plus the growing number of tools that use it, I think
that to shut it out and say that certs are ASN.1 is just a bit shortsided.

>
> regards alan
>
>

Todd





Received: from localhost (daemon@localhost) by mail.proper.com (8.8.8/8.8.5) with SMTP id IAA15496; Tue, 13 Jul 1999 08:00:53 -0700 (PDT)
Received: by mail.imc.org (bulk_mailer v1.12); Tue, 13 Jul 1999 08:00:13 -0700
Received: from dsg1.OpenDirectory.com.au ([203.108.249.145]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id IAA15463 for <[e-mail]>; Tue, 13 Jul 1999 08:00:05 -0700 (PDT)
Received: by DSG1 with Internet Mail Service (5.0.1458.49) id <3WZHJB0Q>; Wed, 14 Jul 1999 01:01:08 +1000
Message-ID: <D1A949D4508DD1119C8100400533BEDC125418@DSG1>
From: Alan Lloyd <[e-mail]>
To: "''PKIX-List' '" <[e-mail]>, "'Andrew Probert '" <[e-mail]>
Subject: RE: ASN.1 vs XML (used to be RE: I-D ACTION:draft-ietf-pkix-scvp- 00.txt)
Date: Wed, 14 Jul 1999 01:01:05 +1000
X-Priority: 3
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.0.1458.49)
Content-Type: text/plain
Precedence: bulk
List-Archive: http://www.imc.org/ietf-pkix/mail-archive/
List-Unsubscribe: mailto:[e-mail]?body=unsubscribe
X-UIDL: d922833538f6b73eee1f0273915e8d2b

Andrew - stop being so direct :-)

What we need to do is support a ASN.1 replacement program for
SNMP, PKCS standards, traffic management standards and onboard
equipment, financial standards, Defence standards, OCSP, LDAP, X.500 and
LDAP objects, etc, etc  and redefine all the object identifiers in the
world as their syntax would change - as the format of these  are defined
in the ASN.1 standard...Thats all :-)

I get the impression this thread is based on the issue that a
certificate format is better in XML rather than ASN.1 - rather than the
knowledge that ASN.1 represents the Presentation layer of the OSI
reference model in that it maps internal application layer structures in
C, etc (the internal syntax) to the transfer syntax TLV system  (ASN.1
BER/DER) via the production of code/definitions derived from an ASN.1
compiler using the input of ASN.1 definitions ... as provided in the
respective standards. Standard which relate to the development of
distributed applications.


Perhaps some reading on the application of ASN.1 as a distributed
information systems tool and the application of Object Identifiers for
protocol and information and where this approach to systems is used
might sway the decision here..

regards alan




----------
From: Andrew Probert
To: 'PKIX-List'
Sent: 7/12/99 11:05:37 AM
Subject: RE: ASN.1 vs XML (used to be RE: I-D
ACTION:draft-ietf-pkix-scvp- 00.txt)

Get real guys.

There's millions of deployed certificate-using clients in Microsoft
(CryptoAPI), Netscape (PKCS#11), Lotus (PKCS#11), not to mention Java
implementations and hardware vendor implementations like CISCO, that
have
built-in decoders for certificates 

These mega-mass market products are on 2 year lead-times, so next year's
products are already half constructed now.  Not to mention Win2000 that
is
imminent.

They work, they are out there.

Not to mention the CAs who have got sizeable investment in certificate
issuing systems that already work and deployed and vendors that have
investment in CSPs and PKCS#11 drivers for smartcards.  We Rotek/SNS are
in
these categories and we certainly do not want to rebuild, we are busy
deploying!

There are video player manufacturers, CD-ROM manufacturers who have
voted
for the 'best' standard and still been left behind by the market.  I am
not
going to argue the benefits of XML versus ASN.1, but suggest that the
market
and major players have voted with their feet a few years ago.

Andew Probert
Rotek Consulting   http://www.rotek.com.au
a Division of Secure Network Solutions
Tel  [phone]
Fax [phone]





Received: from localhost (daemon@localhost) by mail.proper.com (8.8.8/8.8.5) with SMTP id NAA20437; Mon, 12 Jul 1999 13:08:13 -0700 (PDT)
Received: by mail.imc.org (bulk_mailer v1.12); Mon, 12 Jul 1999 13:08:10 -0700
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 NAA20415 for <[e-mail]>; Mon, 12 Jul 1999 13:08:09 -0700 (PDT)
Received: from mentat.verisign.com by caladan.verisign.com (8.8.5/BCH1.5) id NAA18622; Mon, 12 Jul 1999 13:07:35 -0700 (PDT)
Received: from pbaker-pc.verisign.com by mentat.verisign.com (8.8.5/BCH1.0) id NAA02073; Mon, 12 Jul 1999 13:08:44 -0700 (PDT)
From: "Phillip M Hallam-Baker" <[e-mail]>
To: "Rich Salz" <[e-mail]>, <[e-mail]>
Subject: RE: ASN.1 vs XML (used to be RE: I-D ACTION:draft-ietf-pkix-scvp-00.txt)
Date: Mon, 12 Jul 1999 16:10:00 -0400
Message-ID: <003f01becca2$8561cce0$[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
In-Reply-To: <[e-mail]>
X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3
Importance: Normal
Precedence: bulk
List-Archive: http://www.imc.org/ietf-pkix/mail-archive/
List-Unsubscribe: mailto:[e-mail]?body=unsubscribe
X-UIDL: a431aeb8e43b85690a269cc955642512

> I am often disappointedly surprised by how one comment coming out of left
> field from someone with no obvious participatory history can throw an
> IETF WG mailing list into a complete spinout.
> 	/r$

Thats the Internet for you, bringing people together is going to cut down on
wars y' know.

I thought the original comment quite sensible. Paul and Ambarish essentially
propose redoing the syntax of OCSP and moving away from ASN.1. Kind of funny
that given that a year ago we had a big argument with everyone demanding
that
OCSP be ASN.1.

Having had the argument once and lost it we are no longer where we were. We
have now got an OCSP RFC and much as I like nice syntax I don't see the need
to reopen the discussion.

95% of the complaints about ASN.1 are really only valid against DER which is
based on a theological belief in canonicalization I believe to be completely
bogus. Switch to BER encoding and most of the problems simply vanish.

Only to do so would break everything...


Before folk get too engrossed with XML please remember that it is only a
version
of SGML with (some of) the lossage taken out. The purpose of XML was to
enable
folk like Dave Ragget and myself to hack on the HTML DTD without needing to
wear a clothespeg on the nose at the time. If folk think DER is bad, try
using
strict SGML.

The idea of XML is to provide a tool to help solve some interesting new
problems.
I don't see how re-solving our existing solutions in the XML framework is
necessary or usefull. There are plenty of new problems to address first.


		Phill



Received: from localhost (daemon@localhost) by mail.proper.com (8.8.8/8.8.5) with SMTP id NAA20896; Mon, 12 Jul 1999 13:27:27 -0700 (PDT)
Received: by mail.imc.org (bulk_mailer v1.12); Mon, 12 Jul 1999 13:27:26 -0700
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 NAA20872 for <[e-mail]>; Mon, 12 Jul 1999 13:27:24 -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 UAA26704; Mon, 12 Jul 1999 20:27:56 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 VAA19525; Mon, 12 Jul 1999 21:28:49 +0100
Message-ID: <[e-mail]>
Date: Mon, 12 Jul 1999 21:27:55 +0100
From: Ben Laurie <[e-mail]>
Organization: A.L. Group plc
X-Mailer: Mozilla 4.08 [en] (WinNT; I)
MIME-Version: 1.0
To: Phillip M Hallam-Baker <[e-mail]>
CC: Rich Salz <[e-mail]>, [e-mail]
Subject: Re: ASN.1 vs XML (used to be RE: I-D ACTION:draft-ietf-pkix-scvp-00.txt)
References: <003f01becca2$8561cce0$[e-mail]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Precedence: bulk
List-Archive: http://www.imc.org/ietf-pkix/mail-archive/
List-Unsubscribe: mailto:[e-mail]?body=unsubscribe
X-UIDL: f14181f689e1c71994361ad90ae134a3

Phillip M Hallam-Baker wrote:
> 
> > I am often disappointedly surprised by how one comment coming out of left
> > field from someone with no obvious participatory history can throw an
> > IETF WG mailing list into a complete spinout.
> >       /r$
> 
> Thats the Internet for you, bringing people together is going to cut down on
> wars y' know.
> 
> I thought the original comment quite sensible. Paul and Ambarish essentially
> propose redoing the syntax of OCSP and moving away from ASN.1. Kind of funny
> that given that a year ago we had a big argument with everyone demanding
> that
> OCSP be ASN.1.
> 
> Having had the argument once and lost it we are no longer where we were. We
> have now got an OCSP RFC and much as I like nice syntax I don't see the need
> to reopen the discussion.
> 
> 95% of the complaints about ASN.1 are really only valid against DER which is
> based on a theological belief in canonicalization I believe to be completely
> bogus. Switch to BER encoding and most of the problems simply vanish.
> 
> Only to do so would break everything...

??? Why? Switching to BER is just relaxing the rules.

> Before folk get too engrossed with XML please remember that it is only a
> version
> of SGML with (some of) the lossage taken out. The purpose of XML was to
> enable
> folk like Dave Ragget and myself to hack on the HTML DTD without needing to
> wear a clothespeg on the nose at the time. If folk think DER is bad, try
> using
> strict SGML.
> 
> The idea of XML is to provide a tool to help solve some interesting new
> problems.
> I don't see how re-solving our existing solutions in the XML framework is
> necessary or usefull. There are plenty of new problems to address first.

You could do everything you do with DTD/XML using ASN.1/DER. So, why
don't you?

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 localhost (daemon@localhost) by mail.proper.com (8.8.8/8.8.5) with SMTP id OAA21785; Mon, 12 Jul 1999 14:25:14 -0700 (PDT)
Received: by mail.imc.org (bulk_mailer v1.12); Mon, 12 Jul 1999 14:25:03 -0700
Received: from www.meridianus.com (209.249.223.12.has.no.reverse [209.249.223.12] (may be forged)) by mail.proper.com (8.8.8/8.8.5) with ESMTP id OAA21762 for <[e-mail]>; Mon, 12 Jul 1999 14:25:03 -0700 (PDT)
Received: from pc1 by www.meridianus.com (8.8.8+Sun/SMI-SVR4) id PAA01088; Mon, 12 Jul 1999 15:20:55 -0700 (PDT)
Message-ID: <012801beccad$0f04e4a0$[e-mail]>
From: "[e-mail]" <[e-mail]>
To: "Aram Perez" <[e-mail]>, <[e-mail]>
References: <[e-mail]>
Subject: Re: Certicate Format Independence
Date: Mon, 12 Jul 1999 14:25:26 -0700
Organization: Meridianus
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.00.2314.1300
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300
Precedence: bulk
List-Archive: http://www.imc.org/ietf-pkix/mail-archive/
List-Unsubscribe: mailto:[e-mail]?body=unsubscribe
X-UIDL: b37c8784126c165509b5632fe3000890

----- Original Message -----
From: Aram Perez <[e-mail]>
To: <[e-mail]>
Sent: Monday, July 12, 1999 9:32 AM
Subject: Certicate Format Independence


> (used to be RE: ASN.1 vs XML (used to be RE: I-D
> ACTION:draft-ietf-pkix-scvp-00.txt)), etc.
>
> Having been beat up over algorithm independence (and maybe the beating
isn't
> allowing be to think clearly), IETF should support format independence for
> certificates.
>
> :-),
> Aram Perez
>

Aram, Don't we already have that though?.

The standard is set at the BER/DER encoding of the X.509 data structure
represented in the ASN.1 Structure Standard. Anyone that wants to encode to
the standard represented can chose to do so at either  the source level
structure or  the "resolved" binary cert token, it should be up to their
applications.

There cert structure represents the greatest common denominator between a
number of use models and that's why its the right standard as a crossing
point in PKI systems. This places the level of interoperability of the trust
processes at the data structure of the cert token. By the way, time and
event stamps should be the same way, that is as datastructures rather than
service API's or Protocol Models..

meanwhile back to the rant - So the XML issue is really a question of  "can
I represent the same structures in XML as I can in ASN.1?", and the answer
is obviously "Yes"...

My feeling here is that the stumbling block is that we are getting hung up
on what it is we are standardizing here -  is it the blob of bits as
processed through some encoder or resolver or is it the data structure that
you feed into the resolver... or is it both? These are the questions that
must be answered for this conversation to really make sense and these are
relatively simple questions to answer.

If the standards are about the data structure that represent the entities
(certs) as raw binary, then the fact that they are made human readable by
writing them in ASN.1 is irrelevant to the standard structure except as a
reference notation. It becomes a nicety done purely for the reader's comfort
and nothing more.

If what is being standardized is that the X.509 cert is a ASN.1 represented
structure as processed by a "Standardized" BER or DER compliant encoder,
then we are stuck with ASN.1 and the encoders. But I think that what is
being standardized is a binary token that happens for the use of the
"standards" documents to refer to the data structures in ANS.1 for my
reading ease. Nothing more. That makes the real issue here only one of
whether someone wants to step to the plate and write a binary compiler ala a
DER encoder for XML and the preprocessor/rules process to convert the XML
structures into the appropriate ASN.1 compiled outputs.


Todd





Received: from localhost (daemon@localhost) by mail.proper.com (8.8.8/8.8.5) with SMTP id PAA23422; Mon, 12 Jul 1999 15:46:16 -0700 (PDT)
Received: by mail.imc.org (bulk_mailer v1.12); Mon, 12 Jul 1999 15:45:17 -0700
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 PAA23374 for <[e-mail]>; Mon, 12 Jul 1999 15:45:17 -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 PAA36314 for <[e-mail]>; Mon, 12 Jul 1999 15:46:27 -0700
Received: from scv2.apple.com (scv2.apple.com) by mailgate1.apple.com (mailgate1.apple.com- SMTPRS 2.0.15) with ESMTP id <[e-mail]> for <[e-mail]>; Mon, 12 Jul 1999 15:46:16 -0700
Received: from [17.205.41.166] (aram1.apple.com [17.205.41.166]) by scv2.apple.com (8.9.3/8.9.3) with ESMTP id PAA16766 for <[e-mail]>; Mon, 12 Jul 1999 15:46:14 -0700
Message-Id: <[e-mail]>
X-Mailer: Microsoft Outlook Express Macintosh Edition - 4.5 (0410)
Date: Mon, 12 Jul 1999 15:46:15 -0700
Subject: Re: Certicate Format Independence
From: "Aram Perez" <[e-mail]>
To: [e-mail]
MIME-Version: 1.0
X-Priority: 3
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: 7bit
Precedence: bulk
List-Archive: http://www.imc.org/ietf-pkix/mail-archive/
List-Unsubscribe: mailto:[e-mail]?body=unsubscribe
X-UIDL: 9ef71131c09f6fe6ed7b96aef3c58b14

Hi Todd,

I really didn't think anyone would respond (I was trying to be facetious).
Please see my comments below...

[snip]
>> (used to be RE: ASN.1 vs XML (used to be RE: I-D
>> ACTION:draft-ietf-pkix-scvp-00.txt)), etc.
>>
>> Having been beat up over algorithm independence (and maybe the beating
>> isn't allowing me to think clearly), IETF should support format
>> independence for certificates.
>>
>> :-),
>> Aram Perez
>>
>
> Aram, Don't we already have that though?.

I do not think so, otherwise there would not be this flurry of postings on
this issue.

>
> The standard is set at the BER/DER encoding of the X.509 data structure
> represented in the ASN.1 Structure Standard. Anyone that wants to encode to
> the standard represented can chose to do so at either  the source level
> structure or  the "resolved" binary cert token, it should be up to their
> applications.
>
> There cert structure represents the greatest common denominator between a
> number of use models and that's why its the right standard as a crossing
> point in PKI systems. This places the level of interoperability of the trust
> processes at the data structure of the cert token. By the way, time and
> event stamps should be the same way, that is as datastructures rather than
> service API's or Protocol Models..
>
> meanwhile back to the rant - So the XML issue is really a question of  "can
> I represent the same structures in XML as I can in ASN.1?", and the answer
> is obviously "Yes"...

I won't disagree your concept of "data structures". I do not think the issue
is the data structure or whether I can "represent the same structures in XML
as I can in ASN.1". The issue is "How do I get the same bit stream to verify
the data structure that you signed?" In order for the data structure to be
verified, the verifier needs the same bit stream as the signer used. That is
why using BER (as someone earlier suggested) is wrong, because BER allows
more than one bit stream to represent that same value.

>
> My feeling here is that the stumbling block is that we are getting hung up
> on what it is we are standardizing here -  is it the blob of bits as
> processed through some encoder or resolver or is it the data structure that
> you feed into the resolver... or is it both? These are the questions that
> must be answered for this conversation to really make sense and these are
> relatively simple questions to answer.

I believe it is both. And while your questions may be "relatively simple
questions to answer", the answers certainly are not simple. What is supposed
to happen if you put in "07/12/99" to your encoder but I input your "blob of
bits" to my decoder I get "7/12/1999"? And does "07/12/99" represent July
12, 1999 or December 7, 1999?

>
> If the standards are about the data structure that represent the entities
> (certs) as raw binary, then the fact that they are made human readable by
> writing them in ASN.1 is irrelevant to the standard structure except as a
> reference notation. It becomes a nicety done purely for the reader's comfort
> and nothing more.
>
> If what is being standardized is that the X.509 cert is a ASN.1 represented
> structure as processed by a "Standardized" BER or DER compliant encoder,
> then we are stuck with ASN.1 and the encoders. But I think that what is
> being standardized is a binary token that happens for the use of the
> "standards" documents to refer to the data structures in ANS.1 for my
> reading ease. Nothing more. That makes the real issue here only one of
> whether someone wants to step to the plate and write a binary compiler ala a
> DER encoder for XML and the preprocessor/rules process to convert the XML
> structures into the appropriate ASN.1 compiled outputs.

I don't think is quite that simple. See my previous comments above.

Regards,
Aram Perez


Received: from localhost (daemon@localhost) by mail.proper.com (8.8.8/8.8.5) with SMTP id QAA24047; Mon, 12 Jul 1999 16:39:31 -0700 (PDT)
Received: by mail.imc.org (bulk_mailer v1.12); Mon, 12 Jul 1999 16:39:30 -0700
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 QAA24025 for <[e-mail]>; Mon, 12 Jul 1999 16:39:30 -0700 (PDT)
Received: from catalyst (catalyst.llnl.gov [128.115.223.61]) by poptop.llnl.gov (8.8.8/LLNL-3.0.2/pop.llnl.gov-5.1) with SMTP id QAA22511; Mon, 12 Jul 1999 16:40:37 -0700 (PDT)
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.3 (32)
Date: Mon, 12 Jul 1999 16:40:06 -0700
To: "Aram Perez" <[e-mail]>, [e-mail]
From: Tony Bartoletti <[e-mail]>
Subject: Re: Certicate Format Independence
In-Reply-To: <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Precedence: bulk
List-Archive: http://www.imc.org/ietf-pkix/mail-archive/
List-Unsubscribe: mailto:[e-mail]?body=unsubscribe
X-UIDL: aabace5d0a2517e05c382064b4201aab

At 03:46 PM 7/12/99 -0700, Aram Perez wrote:
[tony-snips]

>questions to answer", the answers certainly are not simple. What is supposed
>to happen if you put in "07/12/99" to your encoder but I input your "blob of
>bits" to my decoder I get "7/12/1999"? And does "07/12/99" represent July
>12, 1999 or December 7, 1999?

(Warning: Novice Lurker Commentary)

Suppose I choose an encoder that displays input dates in dd/mm/yy format.
I encode the date "07/12/99" (7 Dec 99), producing a "proper blob".

The blob gets signed.  The blob gets received by two users Sam and Ted.
The blob gets verified by each.

Sam prefers a decoder that displays dates in dd/mm/yy format, while
Ted prefers a decoder that displays dates in mm/dd/yy format.

So... Sam sees the blob as 07/12/99, and understands this as 7 Dec 99.
and   Ted sees the blob as 12/07/99, and understands this as 7 Dec 99.

All is well, assuming Sam and Ted (and I) understand the encode/decode
interpretation to be supplied (and trust the encoders/decoders.)

Is this how its supposed to work?

___tony___


Tony Bartoletti                                             LL
IOWA Center                                              LL LL
Lawrence Livermore National Laboratory                LL LL LL
PO Box 808, L - 089                                   LL LL LL
Livermore, CA 94551-9900                              LL LL LLLLLLLL
phone: [phone]   fax: [phone]               LL LLLLLLLL
email: [e-mail]                                   LLLLLLLL


Received: from localhost (daemon@localhost) by mail.proper.com (8.8.8/8.8.5) with SMTP id RAA24971; Mon, 12 Jul 1999 17:35:53 -0700 (PDT)
Received: by mail.imc.org (bulk_mailer v1.12); Mon, 12 Jul 1999 17:35:48 -0700
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 RAA24948 for <[e-mail]>; Mon, 12 Jul 1999 17:35:48 -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 RAA20834 for <[e-mail]>; Mon, 12 Jul 1999 17:36:56 -0700
Received: from scv2.apple.com (scv2.apple.com) by mailgate1.apple.com (mailgate1.apple.com- SMTPRS 2.0.15) with ESMTP id <[e-mail]> for <[e-mail]>; Mon, 12 Jul 1999 17:36:14 -0700
Received: from [17.205.41.166] (aram1.apple.com [17.205.41.166]) by scv2.apple.com (8.9.3/8.9.3) with ESMTP id RAA16756 for <[e-mail]>; Mon, 12 Jul 1999 17:36:12 -0700
Message-Id: <[e-mail]>
X-Mailer: Microsoft Outlook Express Macintosh Edition - 4.5 (0410)
Date: Mon, 12 Jul 1999 17:36:12 -0700
Subject: Re: Certicate Format Independence
From: "Aram Perez" <[e-mail]>
To: [e-mail]
MIME-Version: 1.0
X-Priority: 3
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: 7bit
Precedence: bulk
List-Archive: http://www.imc.org/ietf-pkix/mail-archive/
List-Unsubscribe: mailto:[e-mail]?body=unsubscribe
X-UIDL: 36f6848c8489fa8473c1d921bff7bda7

Hi Tony,

See my comments below...

> At 03:46 PM 7/12/99 -0700, Aram Perez wrote:
> [tony-snips]
>
>>questions to answer", the answers certainly are not simple. What is supposed
>>to happen if you put in "07/12/99" to your encoder but I input your "blob of
>>bits" to my decoder I get "7/12/1999"? And does "07/12/99" represent July
>>12, 1999 or December 7, 1999?
>
> (Warning: Novice Lurker Commentary)
>
> Suppose I choose an encoder that displays input dates in dd/mm/yy format.

Do you mean a decoder?

> I encode the date "07/12/99" (7 Dec 99), producing a "proper blob".

That's part of the issue, what is a proper blob? Are there more than one
proper blobs? If yes, how do you transform one proper blob (DER) into
another proper blob (XML)?

>
> The blob gets signed.  The blob gets received by two users Sam and Ted.
> The blob gets verified by each.
>
> Sam prefers a decoder that displays dates in dd/mm/yy format, while
> Ted prefers a decoder that displays dates in mm/dd/yy format.

Another part of the issue is the "proper blob" (a.k.a. bits-on-the-wire or
blob of bits) vs. the display format. What do you verify, the proper blob or
the dsiplay format?

>
> So... Sam sees the blob as 07/12/99, and understands this as 7 Dec 99.
> and   Ted sees the blob as 12/07/99, and understands this as 7 Dec 99.
>
> All is well, assuming Sam and Ted (and I) understand the encode/decode
> interpretation to be supplied (and trust the encoders/decoders.)
>
> Is this how its supposed to work?

>From an ideal point of view yes. But not in practice for several reasons:
Generally, what we are discussing are operations/processes performed by
machines and not humans. So both machines have to follow the same set of
rules/standards. The use of public key encryption based digital signatures
(that's a mouth-full ;-) requires that the verifier have the identical bit
stream as the signer (that's the reason that X.509 specifies DER rules and
not BER rules). So even though Sam understands that 07/12/99 means 7 Dec 99
and Ted understands that 12/07/99 also means 7 Dec 99, with respect to a
digital signature, 07/12/99 is not the same as 12/07/99.

Regards,
Aram Perez


Received: from localhost (daemon@localhost) by mail.proper.com (8.8.8/8.8.5) with SMTP id IAA15166; Mon, 12 Jul 1999 08:54:27 -0700 (PDT)
Received: by mail.imc.org (bulk_mailer v1.12); Mon, 12 Jul 1999 08:54:20 -0700
Received: from mail.rdc1.az.home.com ([e-mail] [24.1.240.66]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id IAA15141 for <[e-mail]>; Mon, 12 Jul 1999 08:54:20 -0700 (PDT)
Received: from earthlink.net ([24.1.214.107]) by mail.rdc1.az.home.com (InterMail v4.01.01.00 201-229-111) with ESMTP id <[e-mail]>; Mon, 12 Jul 1999 08:55:26 -0700
Message-ID: <[e-mail]>
Date: Mon, 12 Jul 1999 08:57:40 -0700
From: Timothy Fisher <[e-mail]>
X-Mailer: Mozilla 4.61 [en] (WinNT; I)
X-Accept-Language: en
MIME-Version: 1.0
To: Rich Salz <[e-mail]>
CC: [e-mail]
Subject: Re: ASN.1 vs XML (used to be RE: I-D ACTION:draft-ietf-pkix-scvp-00.txt)
References: <[e-mail]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Precedence: bulk
List-Archive: http://www.imc.org/ietf-pkix/mail-archive/
List-Unsubscribe: mailto:[e-mail]?body=unsubscribe
X-UIDL: b9c87c3500292130e2f1e46f7f475c29

One of the tasks of a working group should be to solicit and consider new
ideas I believe.

Tim

Rich Salz wrote:

> I am often disappointedly surprised by how one comment coming out of left
> field from someone with no obvious participatory history can throw an
> IETF WG mailing list into a complete spinout.
>         /r$



Received: from localhost (daemon@localhost) by mail.proper.com (8.8.8/8.8.5) with SMTP id JAA15590; Mon, 12 Jul 1999 09:07:42 -0700 (PDT)
Received: by mail.imc.org (bulk_mailer v1.12); Mon, 12 Jul 1999 09:07:41 -0700
Received: from www.meridianus.com (209.249.223.12.has.no.reverse [209.249.223.12] (may be forged)) by mail.proper.com (8.8.8/8.8.5) with ESMTP id JAA15567 for <[e-mail]>; Mon, 12 Jul 1999 09:07:41 -0700 (PDT)
Received: from pc1 by www.meridianus.com (8.8.8+Sun/SMI-SVR4) id KAA00880; Mon, 12 Jul 1999 10:03:26 -0700 (PDT)
Message-ID: <00b701becc80$b3578490$[e-mail]>
From: "[e-mail]" <[e-mail]>
To: "Peter Sylvester" <[e-mail]>, <[e-mail]>
Cc: <[e-mail]>
References: <[e-mail]>
Subject: Re: ASN.1 vs XML (used to be RE: I-D ACTION:draft-ietf-pkix-scvp-00.txt)
Date: Mon, 12 Jul 1999 09:07:54 -0700
Organization: Meridianus
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.00.2314.1300
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300
Precedence: bulk
List-Archive: http://www.imc.org/ietf-pkix/mail-archive/
List-Unsubscribe: mailto:[e-mail]?body=unsubscribe
X-UIDL: b1a80ebe8a413a53542e727870f9342a

----- Original Message -----
From: Peter Sylvester <[e-mail]>
To: <[e-mail]>
Cc: <[e-mail]>
Sent: Monday, July 12, 1999 12:57 AM
Subject: Re: ASN.1 vs XML (used to be RE: I-D
ACTION:draft-ietf-pkix-scvp-00.txt)


> >
> > I would go further than to encode the ASN.1 data in XML as some are
suggesting
> > in this thread.  I would say the ideal solution would be to "reinvent"
> > certificate encodings in pure XML and get rid of ASN.1 altogether.  Now
having
> > said that, I do understand the difficultly in doing so since ASN.1 is
already
> > well established.

personally I think that ASN.1 should remain, but that you should be able to
take a compiled ASN.1 Object and install it into an XML structure without
any pain. Likewise there should be some interoperability bridge for the
compiled XML Structures themselves. Otherwise, if it is just a source level
interpretation issue, then the tools that compile ASN.1 should be extended
to support XML structure notation as well as a framework. Or maybe we need
an ASN.2

Just some thoughts - any comments in response?

> >
> <document>
> <anotheruselessComment>
> <headerordescription>
> <WordwideusabilityClassIdentifier>1</<WordwideusabilityClassIdentifier>
> <numberofWordsReturnedinText>few</numberofWordsReturnedinText>
> </headerordescription>
> <content>
> <yetanotherflame>
> <sentence>
> <bigparagraph>This would be ideal for vendors of disks, bandwidth etc.
> Xml is a rather inefficient encoding of largely structured non structured
data.

No XML doesn't encode squat. XML is a representation language and nothing
more. The processors that convert XML into its "presentation form" are what
is at question here.

> Remember the origins. The environment where xml, html, sgml, script,
latex, etc.
> was used initialally was to get annotations <highlight>by hand</highlight>
to
> textual data.

Absolutely, and their context mandates a presentation engine framework as
the "paper fiber" that the text is layed upon. What this means is that to
date that the XML interpreters are largely inefficient, built for
represnting flattened documents with dynamic links in them... but there is
no reason the DER style encoiding rules could not be adopted for XML
processing if XML coding representation style is selected as a basic
"language for communicating higherlevel transaction models" -
Remember it is the processing that creates the data stream format.

>It is also popular because it supports the definition by
> name paradigm: Just give something a name, and you know what it is.
Replace
> all the tags in this message by &lt;a1> &lt;a2> and so on....
> </bigparagraph>
> </sentence>
> </yetanotherflame>
> <normaltext>
> Look at the examples in
> <universalressourceidentifier>
> http://asf.gils.net/xer/index.html
> </universalressourceidentifier>
> </normaltext>
> </content>
> </anotheruselessComment>
> <postscript>
> <remark><smiley>:-)</smiley></remark>
> </postscript>
> <signature>PS</signature>
> <Zertifikat>untypisch Deutsch</Zertifikat>
> </document>
>
>
>




Received: from localhost (daemon@localhost) by mail.proper.com (8.8.8/8.8.5) with SMTP id JAA15908; Mon, 12 Jul 1999 09:16:57 -0700 (PDT)
Received: by mail.imc.org (bulk_mailer v1.12); Mon, 12 Jul 1999 09:16:56 -0700
Received: from mail.rdc1.az.home.com ([e-mail] [24.1.240.66]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id JAA15886 for <[e-mail]>; Mon, 12 Jul 1999 09:16:56 -0700 (PDT)
Received: from earthlink.net ([24.1.214.107]) by mail.rdc1.az.home.com (InterMail v4.01.01.00 201-229-111) with ESMTP id <[e-mail]>; Mon, 12 Jul 1999 09:18:02 -0700
Message-ID: <[e-mail]>
Date: Mon, 12 Jul 1999 09:20:17 -0700
From: Timothy Fisher <[e-mail]>
X-Mailer: Mozilla 4.61 [en] (WinNT; I)
X-Accept-Language: en
MIME-Version: 1.0
To: "[e-mail]" <[e-mail]>
CC: Peter Sylvester <[e-mail]>, [e-mail]
Subject: Re: ASN.1 vs XML (used to be RE: I-D ACTION:draft-ietf-pkix-scvp-00.txt)
References: <[e-mail]> <00b701becc80$b3578490$[e-mail]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Precedence: bulk
List-Archive: http://www.imc.org/ietf-pkix/mail-archive/
List-Unsubscribe: mailto:[e-mail]?body=unsubscribe
X-UIDL: 2e86c3a54fffa4af6482b126070d42b1

I would say that if your going to continue to use ASN.1 and/or DER encoding
schemes, the reason for moving to XML loses much of its value, so in that case,
I would say just leave ASN.1 as is.
The value of moving to XML would be to rid ourselves of ASN.1 and DER encoding
complications.

Tim

"[e-mail]" wrote:

> ----- Original Message -----
> From: Peter Sylvester <[e-mail]>
> To: <[e-mail]>
> Cc: <[e-mail]>
> Sent: Monday, July 12, 1999 12:57 AM
> Subject: Re: ASN.1 vs XML (used to be RE: I-D
> ACTION:draft-ietf-pkix-scvp-00.txt)
>
> > >
> > > I would go further than to encode the ASN.1 data in XML as some are
> suggesting
> > > in this thread.  I would say the ideal solution would be to "reinvent"
> > > certificate encodings in pure XML and get rid of ASN.1 altogether.  Now
> having
> > > said that, I do understand the difficultly in doing so since ASN.1 is
> already
> > > well established.
>
> personally I think that ASN.1 should remain, but that you should be able to
> take a compiled ASN.1 Object and install it into an XML structure without
> any pain. Likewise there should be some interoperability bridge for the
> compiled XML Structures themselves. Otherwise, if it is just a source level
> interpretation issue, then the tools that compile ASN.1 should be extended
> to support XML structure notation as well as a framework. Or maybe we need
> an ASN.2
>
> Just some thoughts - any comments in response?
>
> > >
> > <document>
> > <anotheruselessComment>
> > <headerordescription>
> > <WordwideusabilityClassIdentifier>1</<WordwideusabilityClassIdentifier>
> > <numberofWordsReturnedinText>few</numberofWordsReturnedinText>
> > </headerordescription>
> > <content>
> > <yetanotherflame>
> > <sentence>
> > <bigparagraph>This would be ideal for vendors of disks, bandwidth etc.
> > Xml is a rather inefficient encoding of largely structured non structured
> data.
>
> No XML doesn't encode squat. XML is a representation language and nothing
> more. The processors that convert XML into its "presentation form" are what
> is at question here.
>
> > Remember the origins. The environment where xml, html, sgml, script,
> latex, etc.
> > was used initialally was to get annotations <highlight>by hand</highlight>
> to
> > textual data.
>
> Absolutely, and their context mandates a presentation engine framework as
> the "paper fiber" that the text is layed upon. What this means is that to
> date that the XML interpreters are largely inefficient, built for
> represnting flattened documents with dynamic links in them... but there is
> no reason the DER style encoiding rules could not be adopted for XML
> processing if XML coding representation style is selected as a basic
> "language for communicating higherlevel transaction models" -
> Remember it is the processing that creates the data stream format.
>
> >It is also popular because it supports the definition by
> > name paradigm: Just give something a name, and you know what it is.
> Replace
> > all the tags in this message by &lt;a1> &lt;a2> and so on....
> > </bigparagraph>
> > </sentence>
> > </yetanotherflame>
> > <normaltext>
> > Look at the examples in
> > <universalressourceidentifier>
> > http://asf.gils.net/xer/index.html
> > </universalressourceidentifier>
> > </normaltext>
> > </content>
> > </anotheruselessComment>
> > <postscript>
> > <remark><smiley>:-)</smiley></remark>
> > </postscript>
> > <signature>PS</signature>
> > <Zertifikat>untypisch Deutsch</Zertifikat>
> > </document>
> >
> >
> >



Received: from localhost (daemon@localhost) by mail.proper.com (8.8.8/8.8.5) with SMTP id LAA19307; Mon, 12 Jul 1999 11:22:47 -0700 (PDT)
Received: by mail.imc.org (bulk_mailer v1.12); Mon, 12 Jul 1999 11:22:46 -0700
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 LAA19284 for <[e-mail]>; Mon, 12 Jul 1999 11:22:46 -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 LAA48666 for <[e-mail]>; Mon, 12 Jul 1999 11:23:41 -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]> for <[e-mail]>; Mon, 12 Jul 1999 09:32:21 -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 JAA34934 for <[e-mail]>; Mon, 12 Jul 1999 09:32:20 -0700
Message-Id: <[e-mail]>
X-Mailer: Microsoft Outlook Express Macintosh Edition - 4.5 (0410)
Date: Mon, 12 Jul 1999 09:32:20 -0700
Subject: Certicate Format Independence
From: "Aram Perez" <[e-mail]>
To: [e-mail]
MIME-Version: 1.0
X-Priority: 3
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: 7bit
Precedence: bulk
List-Archive: http://www.imc.org/ietf-pkix/mail-archive/
List-Unsubscribe: mailto:[e-mail]?body=unsubscribe
X-UIDL: e623d7c2f937a0060c931aecf3bb4281

(used to be RE: ASN.1 vs XML (used to be RE: I-D 
ACTION:draft-ietf-pkix-scvp-00.txt)), etc.

Having been beat up over algorithm independence (and maybe the beating isn't
allowing be to think clearly), IETF should support format independence for
certificates.

:-),
Aram Perez


Received: from localhost (daemon@localhost) by mail.proper.com (8.8.8/8.8.5) with SMTP id KAA18650; Mon, 12 Jul 1999 10:59:06 -0700 (PDT)
Received: by mail.imc.org (bulk_mailer v1.12); Mon, 12 Jul 1999 10:58:53 -0700
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 KAA18620 for <[e-mail]>; Mon, 12 Jul 1999 10:58:49 -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 FAA04583 for <[e-mail]>; Tue, 13 Jul 1999 05:59:30 +1200 (NZST) (sender [e-mail])
Received: by cs26.cs.auckland.ac.nz (relaymail v0.9) id <93180237027915>; Tue, 13 Jul 1999 05:59:30 (NZST)
From: [e-mail] (Peter Gutmann)
To: [e-mail]
Subject: Re: I-D ACTION:draft-ietf-pkix-scvp-00.txt
Sender: [e-mail]
Reply-To: [e-mail]
X-Charge-To: pgut001
X-Authenticated: relaymail v0.9 on cs26.cs.auckland.ac.nz
Date: Tue, 13 Jul 1999 05:59:30 (NZST)
Message-ID: <[e-mail]>
Precedence: bulk
List-Archive: http://www.imc.org/ietf-pkix/mail-archive/
List-Unsubscribe: mailto:[e-mail]?body=unsubscribe
X-UIDL: c4e963080107530677e2c73f37c2f844

Ben Laurie <[e-mail]> writes:

>OpenSSL/SSLeay itself failed to correctly construct SETs for years and no-
>one noticed.

There's one case where it might get noticed, in S/MIME signed attributes.  I
used to output them sorted by OID (which made debugging a lot easier) and it
turned out that there are some S/MIME clients which will check for correct
sorted SET's.  I think I've currently got it set up to sort by OID for debug
builds and by DER rules for release builds for the clients which check for
this.

Peter.



Received: from localhost (daemon@localhost) by mail.proper.com (8.8.8/8.8.5) with SMTP id HAA13321; Mon, 12 Jul 1999 07:33:51 -0700 (PDT)
Received: by mail.imc.org (bulk_mailer v1.12); Mon, 12 Jul 1999 07:33:47 -0700
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 HAA13299 for <[e-mail]>; Mon, 12 Jul 1999 07:33:46 -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 OAA10695; Mon, 12 Jul 1999 14:34:36 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 PAA17252; Mon, 12 Jul 1999 15:35:21 +0100
Message-ID: <[e-mail]>
Date: Mon, 12 Jul 1999 15:34:36 +0100
From: Ben Laurie <[e-mail]>
Organization: A.L. Group plc
X-Mailer: Mozilla 4.08 [en] (WinNT; I)
MIME-Version: 1.0
To: Stephen Kent <[e-mail]>
CC: PKIX-List <[e-mail]>
Subject: Re: I-D ACTION:draft-ietf-pkix-scvp-00.txt
References: <002201bec991$b0d12510$[e-mail]> <[e-mail]> <v04020a04b3abb1930baa@[128.89.0.110]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Precedence: bulk
List-Archive: http://www.imc.org/ietf-pkix/mail-archive/
List-Unsubscribe: mailto:[e-mail]?body=unsubscribe
X-UIDL: a9235987296beaf8fa146d7231a14d2b

I thought I'd replied to this, but I haven't seen the reply.

Stephen Kent wrote:
>         - depending on the  context, Ben is right that one might be able to
> avoid some of the issues that motivate the use of DER in ASN.1. however,
> our experience with PEM development back in the late 80s showed the need
> for canonical representations in other than just certificates, with regard
> to signed data structures.

Showed how?

>  I disagree with Ben's comments re DER.  while
> it is certainly true that people have made mistakes in implementing DER, I
> think we are in pretty good shape these days and I'm not aware of any
> lingering issues now.

Well, OpenSSL seems to have a fair few workarounds for broken
implementations, and Peter Gutmann recently commented that the only way
to check signatures reliably was to keep the original binary data,
because reconstruction didn't work.

OpenSSL/SSLeay itself failed to correctly construct SETs for years and
no-one noticed.

And so on.

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 localhost (daemon@localhost) by mail.proper.com (8.8.8/8.8.5) with SMTP id HAA13684; Mon, 12 Jul 1999 07:36:52 -0700 (PDT)
Received: by mail.imc.org (bulk_mailer v1.12); Mon, 12 Jul 1999 07:36:51 -0700
Received: from btec-fw.certco.com (btec-fw.certco.com [209.2.102.3]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id HAA13662 for <[e-mail]>; Mon, 12 Jul 1999 07:36:51 -0700 (PDT)
From: [e-mail]
Received: from panga.ny.certco.com (panga.ny.certco.com [192.168.69.21]) by btec-fw.certco.com (Postfix) with ESMTP id 8944632DDB; Mon, 12 Jul 1999 10:37:43 -0400 (EDT)
Received: from nycertco-srv1.ny.certco.com (nycertco-srv1.ny.certco.com [192.168.69.12]) by panga.ny.certco.com (Postfix) with ESMTP id 1D8B754001; Mon, 12 Jul 1999 10:37:43 -0400 (EDT)
Received: by nycertco-srv1.ny.certco.com with Internet Mail Service (5.5.2232.9) id <3X8ZLDDZ>; Mon, 12 Jul 1999 10:37:43 -0400
Message-ID: <[e-mail]>
To: [e-mail], [e-mail], [e-mail]
Cc: [e-mail]
Subject: RE: ASN.1 vs XML (used to be RE: I-D ACTION:draft-ietf-pkix-scvp- 00.txt)
Date: Mon, 12 Jul 1999 10:37:42 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2232.9)
Content-Type: text/plain; charset="iso-8859-1"
Precedence: bulk
List-Archive: http://www.imc.org/ietf-pkix/mail-archive/
List-Unsubscribe: mailto:[e-mail]?body=unsubscribe
X-UIDL: 104a0ed7fb24c0609123fcc231efd2e4

I think two issues exist: certificates and protocols.

With regard to certificates, Steve makes a good point:

    don't try to stuff everything into a cert

If applications stopped stuffing application data into certificates, they
would not need to understand ASN.1 and DER. A precedent exists: public keys.
How many applications do you know that decode and parse
SubjectPublicKeyInfos. Most applications I know treat ASN.1-defined
DER-encoded SubjectPublicKeyInfos as opaque blobs and pass them to
cryptographic functions (e.g., BSAFE).

With regard to protocols, I do not see much value in using the lowest common
denominator. For example, I would argue against using XML to re-engineer the
next version of the Internet Protocol (IP).

Frank Balluffi
CertCo

-----Original Message-----
From: Michael Myers [mailto:[e-mail]]
Sent: Sunday, July 11, 1999 6:32 PM
To: Stephen Kent; Ben Laurie
Cc: PKIX-List
Subject: RE: I-D ACTION:draft-ietf-pkix-scvp-00.txt


Steve,

Let us however lose sight of the fact that certificates provide a very
convenient vehicle for the transport of application-independant attributes.
One's purchasing authority or purchase authorization authority isn't and
shouldn't necessarily be restricted to a particular application context.  We
run the risk otherwise of re-inventing the equivalent of a PKI for each
application.

Mike


> -----Original Message-----
> From: Stephen Kent [mailto:[e-mail]]
> Sent: Friday, July 09, 1999 7:11 AM
> To: Ben Laurie
> Cc: PKIX-List
> Subject: Re: I-D ACTION:draft-ietf-pkix-scvp-00.txt
> 
> 
> Folks,
> 
> I think we may be loosing trakc of some issues here.
> 
> 	- certificates are not the only option for passing around signed
> data.  many appications develop their own data structures 
> when then need to
> use signatures to ensure data origin authentication and connectionless
> integrity, or non-repudiation.  thus, the use of XML for various
> applications does not imply a need to use XML in 
> certificates.  don't try
> to stuff everything into a cert just because we have an 
> ability to do so
> via extensions.
> 
> 	- depending on the  context, Ben is right that one 
> might be able to
> avoid some of the issues that motivate the use of DER in 
> ASN.1. however,
> our experience with PEM development back in the late 80s 
> showed the need
> for canonical representations in other than just 
> certificates, with regard
> to signed data structures.  I disagree with Ben's comments re 
> DER.  while
> it is certainly true that people have made mistakes in 
> implementing DER, I
> think we are in pretty good shape these days and I'm not aware of any
> lingering issues now.
> 
> Steve
> 


Received: from localhost (daemon@localhost) by mail.proper.com (8.8.8/8.8.5) with SMTP id EAA10246; Mon, 12 Jul 1999 04:00:46 -0700 (PDT)
Received: by mail.imc.org (bulk_mailer v1.12); Mon, 12 Jul 1999 04:00:36 -0700
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 EAA10221 for <[e-mail]>; Mon, 12 Jul 1999 04:00:35 -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 NAA19097 for <[e-mail]>; Mon, 12 Jul 1999 13:01:39 +0200
Received: from HYDRA ([195.198.186.73]) by caesar.udac.se (8.7.3/NetworkC-1) with SMTP id NAA108834; Mon, 12 Jul 1999 13:01:29 +0200
Received: by HYDRA with Microsoft Mail id <01BECC66.4D867320@HYDRA>; Mon, 12 Jul 1999 12:58:57 +0200
Message-ID: <01BECC66.4D867320@HYDRA>
From: Anders Rundgren <[e-mail]>
To: "'Peter Sylvester'" <[e-mail]>, "'[e-mail]'" <[e-mail]>
Subject: RE: ASN.1 vs XML (used to be RE: I-D ACTION:draft-ietf-pkix-scvp-00.txt)
Date: Mon, 12 Jul 1999 12:58:55 +0200
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Precedence: bulk
List-Archive: http://www.imc.org/ietf-pkix/mail-archive/
List-Unsubscribe: mailto:[e-mail]?body=unsubscribe
X-UIDL: 54989aadeb060d2741a02e18af0b2abf

Peter,
This was fun to read!

Technically you are right although I doubt that XML-certs will be more
than 1.5 - 2 the size of their ASN.1 counterparts which is not THAT bad IMO.

The important thing is that in order to make PKI a main-stream technology (which it is
not today), may require changes like going to XML as XML is likely to
at least replace EDI which is often used in the same contexts as certificates (or
rather should be).  So if XML becomes the HTML (which is closer to a
"peoples movement" than a computer language) of business messages, ASN.1
may be too obscure (few know it) and less satisfactory as a long-term solution.

This should be seen in the light of the fact that the only main-stream PKI-application
I can think about, is e-commerce.  As very few e-commerce standards are ready
for prime time, there is plenty of room for new things.

Anders

<document>
<anotheruselessComment>
<headerordescription>
<WordwideusabilityClassIdentifier>1</<WordwideusabilityClassIdentifier>
<numberofWordsReturnedinText>few</numberofWordsReturnedinText>
</headerordescription>
<content>
<yetanotherflame>
<sentence>
<bigparagraph>This would be ideal for vendors of disks, bandwidth etc. 
Xml is a rather inefficient encoding of largely structured non structured data.
Remember the origins. The environment where xml, html, sgml, script, latex, etc.
was used initialally was to get annotations <highlight>by hand</highlight> to
textual data. It is also popular because it supports the definition by
name paradigm: Just give something a name, and you know what it is. Replace
all the tags in this message by &lt;a1> &lt;a2> and so on....
</bigparagraph>
</sentence>
</yetanotherflame>
<normaltext>
Look at the examples in
<universalressourceidentifier>
http://asf.gils.net/xer/index.html
</universalressourceidentifier>
</normaltext>
</content>
</anotheruselessComment>
<postscript>
<remark><smiley>:-)</smiley></remark>
</postscript>
<signature>PS</signature>
<Zertifikat>untypisch Deutsch</Zertifikat>
</document>






Received: from localhost (daemon@localhost) by mail.proper.com (8.8.8/8.8.5) with SMTP id FAA11519; Mon, 12 Jul 1999 05:00:20 -0700 (PDT)
Received: by mail.imc.org (bulk_mailer v1.12); Mon, 12 Jul 1999 05:00:18 -0700
Received: from fwma1.certco.com (fwma1.certco.com [208.222.33.4]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id FAA11497 for <[e-mail]>; Mon, 12 Jul 1999 05:00:17 -0700 (PDT)
Received: from haggis.ma.certco.com (haggis.ma.certco.com [10.200.200.20]) by fwma1.certco.com (Postfix) with ESMTP for <[e-mail]> id A0B3A15533; Mon, 12 Jul 1999 08:00:48 -0400 (EDT)
Received: by haggis.ma.certco.com (Postfix, from userid 1079) id 977BC7C042; Mon, 12 Jul 1999 08:00:48 -0400 (EDT)
Received: from localhost (localhost [127.0.0.1]) by haggis.ma.certco.com (Postfix) with SMTP id 949B074449 for <[e-mail]>; Mon, 12 Jul 1999 08:00:48 -0400 (EDT)
Date: Mon, 12 Jul 1999 08:00:48 -0400 (EDT)
From: Rich Salz <[e-mail]>
To: [e-mail]
Subject: Re: ASN.1 vs XML (used to be RE: I-D ACTION:draft-ietf-pkix-scvp-00.txt)
In-Reply-To: <[e-mail]>
Message-ID: <[e-mail]>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Precedence: bulk
List-Archive: http://www.imc.org/ietf-pkix/mail-archive/
List-Unsubscribe: mailto:[e-mail]?body=unsubscribe
X-UIDL: d9fe06bfd26fd7b5ca3dcb2cce9d2a62

I am often disappointedly surprised by how one comment coming out of left
field from someone with no obvious participatory history can throw an
IETF WG mailing list into a complete spinout.
	/r$



Received: from localhost (daemon@localhost) by mail.proper.com (8.8.8/8.8.5) with SMTP id FAA12057; Mon, 12 Jul 1999 05:42:52 -0700 (PDT)
Received: by mail.imc.org (bulk_mailer v1.12); Mon, 12 Jul 1999 05:42:44 -0700
Received: from pub.siac.com (pub.siac.com [162.69.5.194]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id FAA12035 for <[e-mail]>; Mon, 12 Jul 1999 05:42:44 -0700 (PDT)
Received: from bigmouth.siac.com(162.69.5.8) by pub.siac.com via smap (4.1) id xma002915; Mon, 12 Jul 99 08:43:41 -0400
Received: from siac.com (dfinkels@localhost [127.0.0.1]) by orchid.wisdom.siac.com (8.8.6 (PHNE_17135)/8.8.6) with ESMTP id IAA03436; Mon, 12 Jul 1999 08:43:39 -0400 (EDT)
Sender: [e-mail]
Message-ID: <[e-mail]>
Date: Mon, 12 Jul 1999 08:43:39 -0400
From: Daniel Finkelstein <[e-mail]>
Organization: Securities Industry Automation Corporation
X-Mailer: Mozilla 4.61 [en] (X11; U; HP-UX B.10.20 9000/879)
X-Accept-Language: en
MIME-Version: 1.0
To: Rich Salz <[e-mail]>
CC: [e-mail]
Subject: Re: ASN.1 vs XML (used to be RE: I-D ACTION:draft-ietf-pkix-scvp-00.txt)
References: <[e-mail]>
Content-Type: text/html; charset=us-ascii
Content-Transfer-Encoding: 7bit
Precedence: bulk
List-Archive: http://www.imc.org/ietf-pkix/mail-archive/
List-Unsubscribe: mailto:[e-mail]?body=unsubscribe
X-UIDL: 1555ce3c2069a7640a33e488735a0e5d

<!doctype html public "-//w3c//dtd html 4.0 transitional//en">
<html>
Rich Salz wrote:
<blockquote TYPE=CITE>I am often disappointedly surprised by how one comment
coming out of left
<br>field from someone with no obvious participatory history can throw
an
<br>IETF WG mailing list into a complete spinout.
<br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; /r$</blockquote>
Regardless of one's stature either academically or on this list, everyone
should be heard. Just because someone may not have a reputation as great
as someone else does not negate his argument. That's one of the great fallacies:
if Plato thinks this is a good book, it is therefore a good book.
<p>Personally I think it's to his credit, to whomever you refer, that he
should bring up a topic so deeply important the list participants have
responded in such volume. Let's keep the flame wars to the historical past
of USENET; we have too much important work here to do.
<pre>--&nbsp;
Daniel Alex Finkelstein
New Technologies
phone&nbsp;&nbsp; 212-383-2951
pager&nbsp;&nbsp; 917-427-1630
fax&nbsp;&nbsp;&nbsp;&nbsp; 212-383-3289
Securities Industry Automation Corporation</pre>
&nbsp;</html>




Received: from localhost (daemon@localhost) by mail.proper.com (8.8.8/8.8.5) with SMTP id FAA12290; Mon, 12 Jul 1999 05:54:09 -0700 (PDT)
Received: by mail.imc.org (bulk_mailer v1.12); Mon, 12 Jul 1999 05:54:08 -0700
Received: from dazzler.ndhm.gtegsc.com (dazzler.ndhm.gtegsc.com [155.95.230.163]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id FAA12268 for <[e-mail]>; Mon, 12 Jul 1999 05:54:07 -0700 (PDT)
Received: (from jsaylor@localhost) by dazzler.ndhm.gtegsc.com (8.9.3/8.9.3) id IAA18272; Mon, 12 Jul 1999 08:54:20 -0400 (EDT)
Sender: [e-mail]
To: Andrew Probert <[e-mail]>
Cc: "'PKIX-List'" <[e-mail]>
Subject: Re: ASN.1 vs XML (used to be RE: I-D ACTION:draft-ietf-pkix-scvp- 00.txt)
References: <C13ABC20EDDAD111B29E0000B456EABC0A64ED@SPRINGFIELD>
Organization: CyberTrust
From: John Saylor <[e-mail]>
Date: 12 Jul 1999 08:54:20 -0400
In-Reply-To: Andrew Probert's message of "Mon, 12 Jul 1999 11:05:37 +1000"
Message-ID: <[e-mail]>
Lines: 14
User-Agent: Gnus/5.070088 (Pterodactyl Gnus v0.88) XEmacs/21.1 (20 Minutes to Nikko)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Precedence: bulk
List-Archive: http://www.imc.org/ietf-pkix/mail-archive/
List-Unsubscribe: mailto:[e-mail]?body=unsubscribe
X-UIDL: 11955f94a6002afb835c2d19516f2163

Hi

>>>>> "AP" == Andrew Probert <[e-mail]> writes:

 AP> There are video player manufacturers, CD-ROM manufacturers who
 AP> have voted for the 'best' standard and still been left behind by
 AP> the market.  I am not going to argue the benefits of XML versus
 AP> ASN.1, but suggest that the market and major players have voted
 AP> with their feet a few years ago.

When there's only one option, it's not much of a vote, is it?

-- 
\js


Received: from localhost (daemon@localhost) by mail.proper.com (8.8.8/8.8.5) with SMTP id AAA05830; Mon, 12 Jul 1999 00:56:24 -0700 (PDT)
Received: by mail.imc.org (bulk_mailer v1.12); Mon, 12 Jul 1999 00:56:21 -0700
Received: from edelweb.fr (edelweb.fr [193.51.12.16]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id AAA05806 for <[e-mail]>; Mon, 12 Jul 1999 00:56:20 -0700 (PDT)
Received: from champagne.edelweb.fr (localhost.edelweb.fr [127.0.0.1]) by edelweb.fr with ESMTP id JAA04529; Mon, 12 Jul 1999 09:57:21 +0200 (MET DST)
Received: from champagne.edelweb.fr (champagne.edelweb.fr [193.51.14.161]) by edelweb.fr (nospam/1.1); Mon, 12 Jul 1999 09:57:21 +0200 (MET DST)
Received: from emeriau.edelweb.fr (emeriau.edelweb.fr [193.51.14.5]) by champagne.edelweb.fr (8.7.6/8.6.6) with ESMTP id JAA06146; Mon, 12 Jul 1999 09:57:19 +0200 (MET DST)
From: Peter Sylvester <[e-mail]>
Received: (sylvest@localhost) by emeriau.edelweb.fr (8.7.6/8.6.6) id JAA16248; Mon, 12 Jul 1999 09:57:18 +0200 (MET DST)
Date: Mon, 12 Jul 1999 09:57:18 +0200 (MET DST)
Message-Id: <[e-mail]>
To: [e-mail]
Subject: Re: ASN.1 vs XML (used to be RE: I-D ACTION:draft-ietf-pkix-scvp-00.txt)
Cc: [e-mail]
Precedence: bulk
List-Archive: http://www.imc.org/ietf-pkix/mail-archive/
List-Unsubscribe: mailto:[e-mail]?body=unsubscribe
X-UIDL: 8535c5af3ca945383b596aa5a1fda561

> 
> I would go further than to encode the ASN.1 data in XML as some are suggesting
> in this thread.  I would say the ideal solution would be to "reinvent"
> certificate encodings in pure XML and get rid of ASN.1 altogether.  Now having
> said that, I do understand the difficultly in doing so since ASN.1 is already
> well established.
> 
<document>
<anotheruselessComment>
<headerordescription>
<WordwideusabilityClassIdentifier>1</<WordwideusabilityClassIdentifier>
<numberofWordsReturnedinText>few</numberofWordsReturnedinText>
</headerordescription>
<content>
<yetanotherflame>
<sentence>
<bigparagraph>This would be ideal for vendors of disks, bandwidth etc. 
Xml is a rather inefficient encoding of largely structured non structured data.
Remember the origins. The environment where xml, html, sgml, script, latex, etc.
was used initialally was to get annotations <highlight>by hand</highlight> to
textual data. It is also popular because it supports the definition by
name paradigm: Just give something a name, and you know what it is. Replace
all the tags in this message by &lt;a1> &lt;a2> and so on....
</bigparagraph>
</sentence>
</yetanotherflame>
<normaltext>
Look at the examples in
<universalressourceidentifier>
http://asf.gils.net/xer/index.html
</universalressourceidentifier>
</normaltext>
</content>
</anotheruselessComment>
<postscript>
<remark><smiley>:-)</smiley></remark>
</postscript>
<signature>PS</signature>
<Zertifikat>untypisch Deutsch</Zertifikat>
</document>




Received: from localhost (daemon@localhost) by mail.proper.com (8.8.8/8.8.5) with SMTP id PAA06322; Sun, 11 Jul 1999 15:34:34 -0700 (PDT)
Received: by mail.imc.org (bulk_mailer v1.12); Sun, 11 Jul 1999 15:33:13 -0700
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 PAA06245 for <[e-mail]>; Sun, 11 Jul 1999 15:32:17 -0700 (PDT)
Received: from mentat.verisign.com by caladan.verisign.com (8.8.5/BCH1.5) id PAA27945; Sun, 11 Jul 1999 15:31:40 -0700 (PDT)
Received: from newman.verisign.com by mentat.verisign.com (8.8.5/BCH1.0) id PAA05371; Sun, 11 Jul 1999 15:32:23 -0700 (PDT)
Received: by newman.verisign.com with Internet Mail Service (5.5.2448.0) id <N7XW15KJ>; Sun, 11 Jul 1999 15:32:26 -0700
Message-ID: <[e-mail]>
From: Michael Myers <[e-mail]>
To: Stephen Kent <[e-mail]>, Ben Laurie <[e-mail]>
Cc: PKIX-List <[e-mail]>
Subject: RE: I-D ACTION:draft-ietf-pkix-scvp-00.txt
Date: Sun, 11 Jul 1999 15:32:22 -0700
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2448.0)
Content-Type: text/plain; charset="iso-8859-1"
Precedence: bulk
List-Archive: http://www.imc.org/ietf-pkix/mail-archive/
List-Unsubscribe: mailto:[e-mail]?body=unsubscribe
X-UIDL: d0b985d8d31fd4ad93c391e5ecf89057

Steve,

Let us however lose sight of the fact that certificates provide a very
convenient vehicle for the transport of application-independant attributes.
One's purchasing authority or purchase authorization authority isn't and
shouldn't necessarily be restricted to a particular application context.  We
run the risk otherwise of re-inventing the equivalent of a PKI for each
application.

Mike


> -----Original Message-----
> From: Stephen Kent [mailto:[e-mail]]
> Sent: Friday, July 09, 1999 7:11 AM
> To: Ben Laurie
> Cc: PKIX-List
> Subject: Re: I-D ACTION:draft-ietf-pkix-scvp-00.txt
> 
> 
> Folks,
> 
> I think we may be loosing trakc of some issues here.
> 
> 	- certificates are not the only option for passing around signed
> data.  many appications develop their own data structures 
> when then need to
> use signatures to ensure data origin authentication and connectionless
> integrity, or non-repudiation.  thus, the use of XML for various
> applications does not imply a need to use XML in 
> certificates.  don't try
> to stuff everything into a cert just because we have an 
> ability to do so
> via extensions.
> 
> 	- depending on the  context, Ben is right that one 
> might be able to
> avoid some of the issues that motivate the use of DER in 
> ASN.1. however,
> our experience with PEM development back in the late 80s 
> showed the need
> for canonical representations in other than just 
> certificates, with regard
> to signed data structures.  I disagree with Ben's comments re 
> DER.  while
> it is certainly true that people have made mistakes in 
> implementing DER, I
> think we are in pretty good shape these days and I'm not aware of any
> lingering issues now.
> 
> Steve
> 


Received: from localhost (daemon@localhost) by mail.proper.com (8.8.8/8.8.5) with SMTP id PAA06276; Sun, 11 Jul 1999 15:33:02 -0700 (PDT)
Received: by mail.imc.org (bulk_mailer v1.12); Sun, 11 Jul 1999 15:32:19 -0700
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 PAA06246 for <[e-mail]>; Sun, 11 Jul 1999 15:32:18 -0700 (PDT)
Received: from mentat.verisign.com by caladan.verisign.com (8.8.5/BCH1.5) id PAA27949; Sun, 11 Jul 1999 15:31:41 -0700 (PDT)
Received: from newman.verisign.com by mentat.verisign.com (8.8.5/BCH1.0) id PAA05383; Sun, 11 Jul 1999 15:32:48 -0700 (PDT)
Received: by newman.verisign.com with Internet Mail Service (5.5.2448.0) id <N7XW15K2>; Sun, 11 Jul 1999 15:32:26 -0700
Message-ID: <[e-mail]>
From: Michael Myers <[e-mail]>
To: Timothy Fisher <[e-mail]>, Ambarish Malpani <[e-mail]>
Cc: "'PKIX-List'" <[e-mail]>
Subject: RE: ASN.1 vs XML (used to be RE: I-D ACTION:draft-ietf-pkix-scvp- 00.txt)
Date: Sun, 11 Jul 1999 15:32:25 -0700
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2448.0)
Content-Type: text/plain; charset="iso-8859-1"
Precedence: bulk
List-Archive: http://www.imc.org/ietf-pkix/mail-archive/
List-Unsubscribe: mailto:[e-mail]?body=unsubscribe
X-UIDL: 0f9f27d01d2c5b9723019f414f46e9b4

Tim,

I must strongly disagree.  Doubtless this will come up in various fora this
week.  In my opinion, we should build on what we've managed to accomplish
rather than reinvent it.

Mike

> -----Original Message-----
> From: Timothy Fisher [mailto:[e-mail]]
> Sent: Friday, July 09, 1999 8:11 AM
> To: Ambarish Malpani
> Cc: 'PKIX-List'
> Subject: Re: ASN.1 vs XML (used to be RE: I-D
> ACTION:draft-ietf-pkix-scvp-00.txt)
> 
> 
> I think it would be a very smart idea to move the Certificate encoding
> mechanism from ASN.1 to XML.   ASN.1 has always been the 
> down-side of X.509
> certificates.  XML would be a great improvement.
> 
> Tim
> Cyclone Software
> 
> Ambarish Malpani wrote:
> 
> > Can we please change the subject on this discussion?
> >
> > Thanks,
> > Ambarish
> >
> > 
> ---------------------------------------------------------------------
> > Ambarish Malpani
> > Architect                                                
> 650.567.5457
> > ValiCert, Inc.                                  
> [e-mail]
> > 1215 Terra Bella Ave.                        http://www.valicert.com
> > Mountain View, CA 94043-1833
> >
> > > -----Original Message-----
> > > From: [e-mail]
> > > [mailto:[e-mail]]
> > > Sent: Thursday, July 08, 1999 3:56 PM
> > > To: Anders Rundgren; PKIX-List; Stephen Kent;
> > > [e-mail]; William Z Pope
> > > Subject: Re: I-D ACTION:draft-ietf-pkix-scvp-00.txt
> > >
> > >
> > >
> > > ----- Original Message -----
> > > From: Anders Rundgren <[e-mail]>
> > > To: PKIX-List <[e-mail]>; Stephen Kent 
> <[e-mail]>;
> > > [e-mail]
> > > <[e-mail]>; William Z
> > > Pope <[e-mail]>
> > > Sent: Thursday, July 08, 1999 3:31 PM
> > > Subject: Re: I-D ACTION:draft-ietf-pkix-scvp-00.txt
> > >
> > >
> > > > Well,
> > > > sorry for bringing this up.  For certificates with huge
> > > informational
> > > contents I
> > > > see some gain by wrapping an XML information object 
> into ASN.1 X509
> > > > wrapper.  If PKI goes big, certificates proliferate the
> > > decoding part (RP
> > > debugging)
> > > > will be helped by using XML rather than ASN.1.  
> Particularly if XML
> > > becomes
> > > > the lingua franca of the Web.   But of course XML is not
> > > required, it is
> > > just
> > > > something that could be worth considering for lets say X509.v4
> > >
> > > Actually if that is your intent,  I would think that the real
> > > win here is
> > > having a number of different cert representation formats 
> that include
> > > ASN.1/BER-DER, Binary, XML, and SMIME, myself.
> > >
> > > and have the approved Cert Management Protocols support these
> > > inter-deployment interoperability issues directly.
> > >
> > > Todd.
> > >
> > >
> > >
> > >
> 


Received: from localhost (daemon@localhost) by mail.proper.com (8.8.8/8.8.5) with SMTP id QAA07230; Sun, 11 Jul 1999 16:56:08 -0700 (PDT)
Received: by mail.imc.org (bulk_mailer v1.12); Sun, 11 Jul 1999 16:56:06 -0700
Received: from pub.siac.com (pub.siac.com [162.69.5.194]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id QAA07208 for <[e-mail]>; Sun, 11 Jul 1999 16:56:05 -0700 (PDT)
Received: from bigmouth.siac.com(162.69.5.8) by pub.siac.com via smap (4.1) id xma024824; Sun, 11 Jul 99 19:57:05 -0400
Received: from siac.com (dfinkels@localhost [127.0.0.1]) by orchid.wisdom.siac.com (8.8.6 (PHNE_17135)/8.8.6) with ESMTP id TAA01953; Sun, 11 Jul 1999 19:57:03 -0400 (EDT)
Sender: [e-mail]
Message-ID: <[e-mail]>
Date: Sun, 11 Jul 1999 19:57:03 -0400
From: Daniel Finkelstein <[e-mail]>
Organization: Securities Industry Automation Corporation
X-Mailer: Mozilla 4.61 [en] (X11; U; HP-UX B.10.20 9000/879)
X-Accept-Language: en
MIME-Version: 1.0
To: Michael Myers <[e-mail]>
CC: "'PKIX-List'" <[e-mail]>
Subject: Re: ASN.1 vs XML (used to be RE: I-D ACTION:draft-ietf-pkix-scvp-00.txt)
References: <[e-mail]>
Content-Type: text/html; charset=us-ascii
Content-Transfer-Encoding: 7bit
Precedence: bulk
List-Archive: http://www.imc.org/ietf-pkix/mail-archive/
List-Unsubscribe: mailto:[e-mail]?body=unsubscribe
X-UIDL: 68eee74c1f96bded698834185da53ff8

<!doctype html public "-//w3c//dtd html 4.0 transitional//en">
<html>
Michael Myers wrote:
<blockquote TYPE=CITE>Tim,
<p>I must strongly disagree.&nbsp; Doubtless this will come up in various
fora this
<br>week.&nbsp; In my opinion, we should build on what we've managed to
accomplish
<br>rather than reinvent it.
<p>Mike</blockquote>
I agree with you, Mike. I don't see harm, however, in pursuing (tangentially)
XML&nbsp;implementation so long as it doesn't distract from continued development
along ASN.1. Arguably XML is a technology that will be important to each
of us, but in such a young state as it is -- still volatile drafts -- it
seems like we'd be playing catch-up constantly with XML standards as they
appear, and then have to figure out PKIX directions based on the new directions
of XML.
<p>At least with ASN.1 we have a solid definition to work with and a good
understanding of it in the development community.
<br>&nbsp;
<pre>--&nbsp;
Daniel Alex Finkelstein
New Technologies
phone&nbsp;&nbsp; 212-383-2951
pager&nbsp;&nbsp; 917-427-1630
fax&nbsp;&nbsp;&nbsp;&nbsp; 212-383-3289
Securities Industry Automation Corporation</pre>
&nbsp;</html>




Received: from localhost (daemon@localhost) by mail.proper.com (8.8.8/8.8.5) with SMTP id RAA07468; Sun, 11 Jul 1999 17:03:06 -0700 (PDT)
Received: by mail.imc.org (bulk_mailer v1.12); Sun, 11 Jul 1999 17:03:05 -0700
Received: from pub.siac.com (pub.siac.com [162.69.5.194]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id RAA07444 for <[e-mail]>; Sun, 11 Jul 1999 17:03:05 -0700 (PDT)
Received: from bigmouth.siac.com(162.69.5.8) by pub.siac.com via smap (4.1) id xma024880; Sun, 11 Jul 99 20:04:06 -0400
Received: from siac.com (dfinkels@localhost [127.0.0.1]) by orchid.wisdom.siac.com (8.8.6 (PHNE_17135)/8.8.6) with ESMTP id UAA01976; Sun, 11 Jul 1999 20:04:04 -0400 (EDT)
Sender: [e-mail]
Message-ID: <[e-mail]>
Date: Sun, 11 Jul 1999 20:04:04 -0400
From: Daniel Finkelstein <[e-mail]>
Organization: Securities Industry Automation Corporation
X-Mailer: Mozilla 4.61 [en] (X11; U; HP-UX B.10.20 9000/879)
X-Accept-Language: en
MIME-Version: 1.0
To: Michael Myers <[e-mail]>
CC: PKIX-List <[e-mail]>
Subject: Re: I-D ACTION:draft-ietf-pkix-scvp-00.txt
References: <[e-mail]>
Content-Type: text/html; charset=us-ascii
Content-Transfer-Encoding: 7bit
Precedence: bulk
List-Archive: http://www.imc.org/ietf-pkix/mail-archive/
List-Unsubscribe: mailto:[e-mail]?body=unsubscribe
X-UIDL: d7d8dfc749b86e882e118ab1daeb5404

<!doctype html public "-//w3c//dtd html 4.0 transitional//en">
<html>
Michael Myers wrote:
<blockquote TYPE=CITE>Steve,
<p>Let us however lose sight of the fact that certificates provide a very
<br>convenient vehicle for the transport of application-independant attributes.
<br>One's purchasing authority or purchase authorization authority isn't
and
<br>shouldn't necessarily be restricted to a particular application context.&nbsp;
We
<br>run the risk otherwise of re-inventing the equivalent of a PKI for
each
<br>application.</blockquote>
It's a risk that's already happening. Interoperability threatens to create
such a monster, as "draft-compliant" PKI implementations function well
enough alone, but not with each other. So then we'll need glue to tie them
together. PKI&nbsp;middleware!
<p>Having worked with many of the participants' company's PKI software
products, it's interesting to note how many don't work together at all,
especially considering the teamwork required in the drafts. It seems like
a case of one hand not knowing what the other hand is doing. But then again,
this is all very academic. Until the drafts are static and concrete enough
in the details to justify judgment, PKI&nbsp;products have very good excuses
as to why they don't work together. And become, as you noted, application
specific.
<pre>--&nbsp;
Daniel Alex Finkelstein
New Technologies
phone&nbsp;&nbsp; 212-383-2951
pager&nbsp;&nbsp; 917-427-1630
fax&nbsp;&nbsp;&nbsp;&nbsp; 212-383-3289
Securities Industry Automation Corporation</pre>
&nbsp;</html>




Received: from localhost (daemon@localhost) by mail.proper.com (8.8.8/8.8.5) with SMTP id SAA09792; Sun, 11 Jul 1999 18:06:42 -0700 (PDT)
Received: by mail.imc.org (bulk_mailer v1.12); Sun, 11 Jul 1999 18:06:39 -0700
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 SAA09753 for <[e-mail]>; Sun, 11 Jul 1999 18:06:37 -0700 (PDT)
Received: by SPRINGFIELD with Internet Mail Service (5.5.2232.9) id <MPSPBVY7>; Mon, 12 Jul 1999 11:05:42 +1000
Message-ID: <C13ABC20EDDAD111B29E0000B456EABC0A64ED@SPRINGFIELD>
From: Andrew Probert <[e-mail]>
To: "'PKIX-List'" <[e-mail]>
Subject: RE: ASN.1 vs XML (used to be RE: I-D ACTION:draft-ietf-pkix-scvp- 00.txt)
Date: Mon, 12 Jul 1999 11:05:37 +1000
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2232.9)
Content-Type: text/plain
Precedence: bulk
List-Archive: http://www.imc.org/ietf-pkix/mail-archive/
List-Unsubscribe: mailto:[e-mail]?body=unsubscribe
X-UIDL: 2bee279d16ec133eceb39efc89520907

Get real guys.

There's millions of deployed certificate-using clients in Microsoft
(CryptoAPI), Netscape (PKCS#11), Lotus (PKCS#11), not to mention Java
implementations and hardware vendor implementations like CISCO, that have
built-in decoders for certificates 

These mega-mass market products are on 2 year lead-times, so next year's
products are already half constructed now.  Not to mention Win2000 that is
imminent.

They work, they are out there.

Not to mention the CAs who have got sizeable investment in certificate
issuing systems that already work and deployed and vendors that have
investment in CSPs and PKCS#11 drivers for smartcards.  We Rotek/SNS are in
these categories and we certainly do not want to rebuild, we are busy
deploying!

There are video player manufacturers, CD-ROM manufacturers who have voted
for the 'best' standard and still been left behind by the market.  I am not
going to argue the benefits of XML versus ASN.1, but suggest that the market
and major players have voted with their feet a few years ago.

Andew Probert
Rotek Consulting   http://www.rotek.com.au
a Division of Secure Network Solutions
Tel  [phone]
Fax [phone]





Received: from localhost (daemon@localhost) by mail.proper.com (8.8.8/8.8.5) with SMTP id SAA14550; Sun, 11 Jul 1999 18:30:05 -0700 (PDT)
Received: by mail.imc.org (bulk_mailer v1.12); Sun, 11 Jul 1999 18:30:03 -0700
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 SAA14528 for <[e-mail]>; Sun, 11 Jul 1999 18:30:00 -0700 (PDT)
Received: from sydneymail1.baltimore.com.au (sydneymail1.jp.zergo.com.au [192.168.71.5]) by stargate.zergo.com.au (8.9.1/8.8.7) with ESMTP id LAA28316; Mon, 12 Jul 1999 11:32:41 +1000
Received: by sydneymail1.jp.zergo.com.au with Internet Mail Service (5.5.2448.0) id <3XXR6MS0>; Mon, 12 Jul 1999 11:27:48 +1000
Message-ID: <[e-mail]>
From: Michael Zolotarev <[e-mail]>
To: Andrew Probert <[e-mail]>
Cc: PKIX mailing group <[e-mail]>
Subject: RE: ASN.1 vs. XML (used to be RE: I-D ACTION:draft-ietf-pkix-scvp - 00.txt)
Date: Mon, 12 Jul 1999 11:27:47 +1000
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2448.0)
Content-Type: text/plain; charset="iso-8859-1"
Precedence: bulk
List-Archive: http://www.imc.org/ietf-pkix/mail-archive/
List-Unsubscribe: mailto:[e-mail]?body=unsubscribe
X-UIDL: 8b33d702c1c9743c72e868656b6c0163

Andrew,

What you are saying is obviously right. Except, it is only true if you look at the matter from the Microsoft's "Where do you want to go..." position.
However, this group, and the directions/decisions it takes, should not be 100% influenced by the well-appreciated difficulties the industry might be having today and in the nearest future. Because tomorrow the same industry will blame us for not looking forward beyond 2 or some years.

Just imagine what your arguments would've been 3 years ago, had we have a 'WindowsHelpFile' vs. HTML format discussion :).

I am not the greatest defender of switching from ASN.1 to XML. As well as you, I do not see much rational in doing so, at least at this stage. But the matter apparently deserves technical(!) discussion, before the industry starts even looking on more practical implications of it.

Just look at how much response we got for the last few days - I haven't seeing so many new names in the list for months. Which proves that there is obvious interest out there, whatever speculative it might be.

MichaelZ

-----Original Message-----
From: Andrew Probert [mailto:[e-mail]]
Sent: Monday, July 12, 1999 11:06 AM
To: 'PKIX-List'
Subject: RE: ASN.1 vs XML (used to be RE: I-D
ACTION:draft-ietf-pkix-scvp- 00.txt)


Get real guys.

There's millions of deployed certificate-using clients in Microsoft
(CryptoAPI), Netscape (PKCS#11), Lotus (PKCS#11), not to mention Java
implementations and hardware vendor implementations like CISCO, that have
built-in decoders for certificates 

These mega-mass market products are on 2 year lead-times, so next year's
products are already half constructed now.  Not to mention Win2000 that is
imminent.

They work, they are out there.

Not to mention the CAs who have got sizeable investment in certificate
issuing systems that already work and deployed and vendors that have
investment in CSPs and PKCS#11 drivers for smartcards.  We Rotek/SNS are in
these categories and we certainly do not want to rebuild, we are busy
deploying!

There are video player manufacturers, CD-ROM manufacturers who have voted
for the 'best' standard and still been left behind by the market.  I am not
going to argue the benefits of XML versus ASN.1, but suggest that the market
and major players have voted with their feet a few years ago.

Andew Probert
Rotek Consulting   http://www.rotek.com.au
a Division of Secure Network Solutions
Tel  [phone]
Fax [phone]




Received: from localhost (daemon@localhost) by mail.proper.com (8.8.8/8.8.5) with SMTP id XAA04185; Sun, 11 Jul 1999 23:02:36 -0700 (PDT)
Received: by mail.imc.org (bulk_mailer v1.12); Sun, 11 Jul 1999 23:02:32 -0700
Received: from mail.rdc1.az.home.com ([e-mail] [24.1.240.66]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id XAA04162 for <[e-mail]>; Sun, 11 Jul 1999 23:02:32 -0700 (PDT)
Received: from earthlink.net ([24.1.214.107]) by mail.rdc1.az.home.com (InterMail v4.01.01.00 201-229-111) with ESMTP id <[e-mail]>; Sun, 11 Jul 1999 23:03:36 -0700
Message-ID: <[e-mail]>
Date: Sun, 11 Jul 1999 23:05:49 -0700
From: Timothy Fisher <[e-mail]>
X-Mailer: Mozilla 4.61 [en] (WinNT; I)
X-Accept-Language: en
MIME-Version: 1.0
To: Michael Myers <[e-mail]>
CC: Ambarish Malpani <[e-mail]>, "'PKIX-List'" <[e-mail]>
Subject: Re: ASN.1 vs XML (used to be RE: I-D ACTION:draft-ietf-pkix-scvp-00.txt)
References: <[e-mail]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Precedence: bulk
List-Archive: http://www.imc.org/ietf-pkix/mail-archive/
List-Unsubscribe: mailto:[e-mail]?body=unsubscribe
X-UIDL: 88b2850e52c231f7472011ddd1f748be

Mike,

I do understand the reluctance to "reinvent" the certificate encoding scheme,
and realize that realisticly we are probably stuck with ASN.1 and DER
encodings.  My point is probably more of an academic one at this point.  Many
people trying to learn how to manipulate and parse certificates themselves
always find ASN.1 and DER to be a big hurdle.  I have heard it complained about
on many occasions.  XML is a very easy to use and very flexible encoding scheme
that would be ideal for certificates and other security data structures.

I would go further than to encode the ASN.1 data in XML as some are suggesting
in this thread.  I would say the ideal solution would be to "reinvent"
certificate encodings in pure XML and get rid of ASN.1 altogether.  Now having
said that, I do understand the difficultly in doing so since ASN.1 is already
well established.

Tim

Michael Myers wrote:

> Tim,
>
> I must strongly disagree.  Doubtless this will come up in various fora this
> week.  In my opinion, we should build on what we've managed to accomplish
> rather than reinvent it.
>
> Mike
>
> > -----Original Message-----
> > From: Timothy Fisher [mailto:[e-mail]]
> > Sent: Friday, July 09, 1999 8:11 AM
> > To: Ambarish Malpani
> > Cc: 'PKIX-List'
> > Subject: Re: ASN.1 vs XML (used to be RE: I-D
> > ACTION:draft-ietf-pkix-scvp-00.txt)
> >
> >
> > I think it would be a very smart idea to move the Certificate encoding
> > mechanism from ASN.1 to XML.   ASN.1 has always been the
> > down-side of X.509
> > certificates.  XML would be a great improvement.
> >
> > Tim
> > Cyclone Software
> >
> > Ambarish Malpani wrote:
> >
> > > Can we please change the subject on this discussion?
> > >
> > > Thanks,
> > > Ambarish
> > >
> > >
> > ---------------------------------------------------------------------
> > > Ambarish Malpani
> > > Architect
> > 650.567.5457
> > > ValiCert, Inc.
> > [e-mail]
> > > 1215 Terra Bella Ave.                        http://www.valicert.com
> > > Mountain View, CA 94043-1833
> > >
> > > > -----Original Message-----
> > > > From: [e-mail]
> > > > [mailto:[e-mail]]
> > > > Sent: Thursday, July 08, 1999 3:56 PM
> > > > To: Anders Rundgren; PKIX-List; Stephen Kent;
> > > > [e-mail]; William Z Pope
> > > > Subject: Re: I-D ACTION:draft-ietf-pkix-scvp-00.txt
> > > >
> > > >
> > > >
> > > > ----- Original Message -----
> > > > From: Anders Rundgren <[e-mail]>
> > > > To: PKIX-List <[e-mail]>; Stephen Kent
> > <[e-mail]>;
> > > > [e-mail]
> > > > <[e-mail]>; William Z
> > > > Pope <[e-mail]>
> > > > Sent: Thursday, July 08, 1999 3:31 PM
> > > > Subject: Re: I-D ACTION:draft-ietf-pkix-scvp-00.txt
> > > >
> > > >
> > > > > Well,
> > > > > sorry for bringing this up.  For certificates with huge
> > > > informational
> > > > contents I
> > > > > see some gain by wrapping an XML information object
> > into ASN.1 X509
> > > > > wrapper.  If PKI goes big, certificates proliferate the
> > > > decoding part (RP
> > > > debugging)
> > > > > will be helped by using XML rather than ASN.1.
> > Particularly if XML
> > > > becomes
> > > > > the lingua franca of the Web.   But of course XML is not
> > > > required, it is
> > > > just
> > > > > something that could be worth considering for lets say X509.v4
> > > >
> > > > Actually if that is your intent,  I would think that the real
> > > > win here is
> > > > having a number of different cert representation formats
> > that include
> > > > ASN.1/BER-DER, Binary, XML, and SMIME, myself.
> > > >
> > > > and have the approved Cert Management Protocols support these
> > > > inter-deployment interoperability issues directly.
> > > >
> > > > Todd.
> > > >
> > > >
> > > >
> > > >
> >



Received: from localhost (daemon@localhost) by mail.proper.com (8.8.8/8.8.5) with SMTP id XAA04323; Sun, 11 Jul 1999 23:05:04 -0700 (PDT)
Received: by mail.imc.org (bulk_mailer v1.12); Sun, 11 Jul 1999 23:05:04 -0700
Received: from mail.rdc1.az.home.com ([e-mail] [24.1.240.66]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id XAA04301 for <[e-mail]>; Sun, 11 Jul 1999 23:05:03 -0700 (PDT)
Received: from earthlink.net ([24.1.214.107]) by mail.rdc1.az.home.com (InterMail v4.01.01.00 201-229-111) with ESMTP id <[e-mail]>; Sun, 11 Jul 1999 23:06:08 -0700
Message-ID: <[e-mail]>
Date: Sun, 11 Jul 1999 23:08:21 -0700
From: Timothy Fisher <[e-mail]>
X-Mailer: Mozilla 4.61 [en] (WinNT; I)
X-Accept-Language: en
MIME-Version: 1.0
To: Daniel Finkelstein <[e-mail]>
CC: Michael Myers <[e-mail]>, "'PKIX-List'" <[e-mail]>
Subject: Re: ASN.1 vs XML (used to be RE: I-D ACTION:draft-ietf-pkix-scvp-00.txt)
References: <[e-mail]> <[e-mail]>
Content-Type: multipart/alternative; boundary="------------14CEF645D90CCE805B969E9B"
Precedence: bulk
List-Archive: http://www.imc.org/ietf-pkix/mail-archive/
List-Unsubscribe: mailto:[e-mail]?body=unsubscribe
X-UIDL: b53e516a4c2183aa73e30b5098e422cb

<!doctype html public "-//w3c//dtd html 4.0 transitional//en">
<html>
I certainly am not suggesting that work on ASN.1 be abandoned either.&nbsp;
That is certainly where certificates are "today".&nbsp;&nbsp; BUT, I do
think that tangential work in defining security structures in XML would
have value.&nbsp; I do not limit this to certificates either.
<p>Timothy Fisher
<br>Cyclone Software
<br>&nbsp;
<p>Daniel Finkelstein wrote:
<blockquote TYPE=CITE>Michael Myers wrote:
<blockquote TYPE=CITE>Tim,
<p>I must strongly disagree.&nbsp; Doubtless this will come up in various
fora this
<br>week.&nbsp; In my opinion, we should build on what we've managed to
accomplish
<br>rather than reinvent it.
<p>Mike</blockquote>
I agree with you, Mike. I don't see harm, however, in pursuing (tangentially)
XML implementation so long as it doesn't distract from continued development
along ASN.1. Arguably XML is a technology that will be important to each
of us, but in such a young state as it is -- still volatile drafts -- it
seems like we'd be playing catch-up constantly with XML standards as they
appear, and then have to figure out PKIX directions based on the new directions
of XML.
<p>At least with ASN.1 we have a solid definition to work with and a good
understanding of it in the development community.
<br>&nbsp;
<pre>--&nbsp;
Daniel Alex Finkelstein
New Technologies
phone&nbsp;&nbsp; 212-383-2951
pager&nbsp;&nbsp; 917-427-1630
fax&nbsp;&nbsp;&nbsp;&nbsp; 212-383-3289
Securities Industry Automation Corporation</pre>
&nbsp;</blockquote>
</html>


Received: from localhost (daemon@localhost) by mail.proper.com (8.8.8/8.8.5) with SMTP id XAA04531; Sun, 11 Jul 1999 23:07:21 -0700 (PDT)
Received: by mail.imc.org (bulk_mailer v1.12); Sun, 11 Jul 1999 23:07:20 -0700
Received: from mail.rdc1.az.home.com ([e-mail] [24.1.240.66]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id XAA04509 for <[e-mail]>; Sun, 11 Jul 1999 23:07:20 -0700 (PDT)
Received: from earthlink.net ([24.1.214.107]) by mail.rdc1.az.home.com (InterMail v4.01.01.00 201-229-111) with ESMTP id <[e-mail]>; Sun, 11 Jul 1999 23:08:24 -0700
Message-ID: <[e-mail]>
Date: Sun, 11 Jul 1999 23:10:37 -0700
From: Timothy Fisher <[e-mail]>
X-Mailer: Mozilla 4.61 [en] (WinNT; I)
X-Accept-Language: en
MIME-Version: 1.0
To: Andrew Probert <[e-mail]>
CC: "'PKIX-List'" <[e-mail]>
Subject: Re: ASN.1 vs XML (used to be RE: I-D ACTION:draft-ietf-pkix-scvp-00.txt)
References: <C13ABC20EDDAD111B29E0000B456EABC0A64ED@SPRINGFIELD>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Precedence: bulk
List-Archive: http://www.imc.org/ietf-pkix/mail-archive/
List-Unsubscribe: mailto:[e-mail]?body=unsubscribe
X-UIDL: 74c328c026c442d714d5f95509eb9625

Andrew,

I don't think that anyone is suggesting that a commercial release of an XML
encoded product is realistic "today".  Your comments are valid, but that does
not mean that XML should be ignored.

Tim

Andrew Probert wrote:

> Get real guys.
>
> There's millions of deployed certificate-using clients in Microsoft
> (CryptoAPI), Netscape (PKCS#11), Lotus (PKCS#11), not to mention Java
> implementations and hardware vendor implementations like CISCO, that have
> built-in decoders for certificates
>
> These mega-mass market products are on 2 year lead-times, so next year's
> products are already half constructed now.  Not to mention Win2000 that is
> imminent.
>
> They work, they are out there.
>
> Not to mention the CAs who have got sizeable investment in certificate
> issuing systems that already work and deployed and vendors that have
> investment in CSPs and PKCS#11 drivers for smartcards.  We Rotek/SNS are in
> these categories and we certainly do not want to rebuild, we are busy
> deploying!
>
> There are video player manufacturers, CD-ROM manufacturers who have voted
> for the 'best' standard and still been left behind by the market.  I am not
> going to argue the benefits of XML versus ASN.1, but suggest that the market
> and major players have voted with their feet a few years ago.
>
> Andew Probert
> Rotek Consulting   http://www.rotek.com.au
> a Division of Secure Network Solutions
> Tel  [phone]
> Fax [phone]



Received: from localhost (daemon@localhost) by mail.proper.com (8.8.8/8.8.5) with SMTP id FAA17093; Sat, 10 Jul 1999 05:50:38 -0700 (PDT)
Received: by mail.imc.org (bulk_mailer v1.12); Sat, 10 Jul 1999 05:50:26 -0700
Received: from smtp2.erols.com (smtp2.erols.com [207.172.3.235]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id FAA17070 for <[e-mail]>; Sat, 10 Jul 1999 05:50:25 -0700 (PDT)
Received: from rankney (209-122-254-68.s68.tnt1.lnh.md.dialup.rcn.com [209.122.254.68]) by smtp2.erols.com (8.8.8/8.8.5) with SMTP id IAA11428; Sat, 10 Jul 1999 08:57:04 -0400 (EDT)
Message-ID: <001b01becad3$1c6d7c00$44fe7ad1@rankney>
From: "Rich Ankney" <[e-mail]>
To: "[e-mail]" <[e-mail]>, <[e-mail]>
Cc: "IETF PKIX" <[e-mail]>
Subject: Re: ASN.1 vs XML (used to be RE: I-D ACTION:draft-ietf-pkix-scvp-00.txt)
Date: Sat, 10 Jul 1999 08:52:44 -0400
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 4.72.3155.0
X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3155.0
Precedence: bulk
List-Archive: http://www.imc.org/ietf-pkix/mail-archive/
List-Unsubscribe: mailto:[e-mail]?body=unsubscribe
X-UIDL: 7bd8b3ded803a834115739a4bdcdd3d1

Actually, there's been a little work on XML Encoding Rules
(XER).  Check out, e.g., http://asf.gils.net/xer/standard.html.
I've also seen proposals that include an indication of the
primitive (ASN.1) datatype for an element in the XML encoding,
which would be useful till there's a standard way to do that in XML.
One such proposal is at
http://www.oclc.org/~levan/docs/xerencodingrules.html.

Regards,
Rich
-----Original Message-----
From: [e-mail] <[e-mail]>
To: [e-mail] <[e-mail]>
Cc: IETF PKIX <[e-mail]>
Date: Friday, July 09, 1999 7:35 PM
Subject: Re: ASN.1 vs XML (used to be RE: I-D
ACTION:draft-ietf-pkix-scvp-00.txt)


>Frank - good point on the XML encoding of ASN.1 Structures - I like it.
>
>Add 'the about to be proposed' preprocessor to resolve all the persistent
>objects, their policy, and authentication requirements and who-ha!
>
>----- Original Message -----
>From: <[e-mail]>
>To: <[e-mail]>; <>
>Sent: Friday, July 09, 1999 11:38 AM
>Subject: RE: ASN.1 vs XML (used to be RE: I-D
>ACTION:draft-ietf-pkix-scvp-00.txt)
>
>
>> ASN.1 is a syntax
>
>technically its a language. It has a syntax.
>
>> that enables protocol engineers to communicate abstractly
>> about bits that may travel down a wire, including the qualities:
>
>after being interpreted by an BER or DER encoder it does.
>
>>
>> optional elements
>> default values
>> inheritance (using object classes)
>> constraints
>>
>> XML is markup language that can be used to format (or encode) bits that
>> travel down a wire.
>>
>> There is no reason why ASN.1-defined data can not be formatted as XML.
>
>Absolutely True !!! Actually this is an interesting observation to make.
>That there is really no reason that you cannot write ASN.1 in XML...
Imagine
>being able to have one framework that encapsulates all service models.
>
>
>>
>> For those of you advocating the use of XML, does XML provide a rich set a

>> abstract qualities for engineers to use when communicating about bits
that
>> may travel down a wire?
>
>Sure it does, or "it could" is a better answer -  becuase there is really
no
>reason you or anyone else cannot write an XML encoder (ala BER or DER) to
>produce this said same datastream.
>
>XML, like ASN.1 is a language and a related syntax to support the
conveyance
>of certain abstractions. Nothing more. Without the BER or DER encoders to
>reduce ASN.1 to its data form.
>
>The fact that no one has one of these tools floating about today is merely
>an inconvience in the bigger picture.
>
>>
>> Frank Balluffi
>> CertCo
>>
>
>Todd
>
>---SNIP---
>
>
>



Received: from localhost (daemon@localhost) by mail.proper.com (8.8.8/8.8.5) with SMTP id OAA03673; Fri, 9 Jul 1999 14:22:57 -0700 (PDT)
Received: by mail.imc.org (bulk_mailer v1.12); Fri, 9 Jul 1999 14:22:52 -0700
Received: from mail.rdc1.az.home.com ([e-mail] [24.1.240.66]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id OAA03650 for <[e-mail]>; Fri, 9 Jul 1999 14:22:51 -0700 (PDT)
Received: from earthlink.net ([24.1.214.107]) by mail.rdc1.az.home.com (InterMail v4.01.01.00 201-229-111) with ESMTP id <[e-mail]>; Fri, 9 Jul 1999 14:23:40 -0700
Message-ID: <[e-mail]>
Date: Fri, 09 Jul 1999 14:25:47 -0700
From: Timothy Fisher <[e-mail]>
X-Mailer: Mozilla 4.61 [en] (WinNT; I)
X-Accept-Language: en
MIME-Version: 1.0
To: [e-mail]
CC: [e-mail]
Subject: Re: ASN.1 vs XML (used to be RE: I-D ACTION:draft-ietf-pkix-scvp-00.txt)
References: <[e-mail]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Precedence: bulk
List-Archive: http://www.imc.org/ietf-pkix/mail-archive/
List-Unsubscribe: mailto:[e-mail]?body=unsubscribe
X-UIDL: b59c43a6f6941a3a8cebae606b254b39

Peter,

Nice suggestion, unfortunately your not being realistic.   One person/company
could not make this change successful.

Tim

Peter Gutmann wrote:

> Timothy Fisher <[e-mail]>
>
> >Ambarish Malpani wrote:
>
> >>Can we please change the subject on this discussion?
>
> >I think it would be a very smart idea to move the Certificate encoding
> >mechanism from ASN.1 to XML.   ASN.1 has always been the down-side of X.509
> >certificates.  XML would be a great improvement.
>
> How about the following: Tim redefines and re-specs all of X.509 in XML,
> implements the whole lot, and then lets the market decide (for maximum impact
> you should do it all in Java and use CORBA/IIOP to move the certs around).  If
> XML is really a superior solution then obviously everyone will flock to it and
> ASN.1-based X.509 will die a natural death.  QED.
>
> Peter.



Received: from localhost (daemon@localhost) by mail.proper.com (8.8.8/8.8.5) with SMTP id QAA04573; Fri, 9 Jul 1999 16:10:23 -0700 (PDT)
Received: by mail.imc.org (bulk_mailer v1.12); Fri, 9 Jul 1999 16:10:18 -0700
Received: from praseodumium.btinternet.com (praseodumium.btinternet.com [194.73.73.82]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id QAA04503 for <[e-mail]>; Fri, 9 Jul 1999 16:10:17 -0700 (PDT)
Received: from [212.140.5.16] (helo=dwc-acer) by praseodumium.btinternet.com with smtp (Exim 2.05 #1) id 112jiU-0004PP-00; Sat, 10 Jul 1999 00:06:02 +0100
From: "David Chadwick" <[e-mail]>
Organization: University of Salford
To: "Anders Rundgren" <[e-mail]>, [e-mail]
Date: Sat, 10 Jul 1999 00:14:46 +0100
MIME-Version: 1.0
Content-type: text/plain; charset=US-ASCII
Content-transfer-encoding: 7BIT
Subject: Re: Use of localityName attribute
Reply-to: [e-mail]
CC: "Petra Gloeckner" <[e-mail]>, "PKIX-List" <[e-mail]>, "Stefan Santesson" <[e-mail]>
Priority: normal
In-reply-to: <[e-mail]>
X-mailer: Pegasus Mail for Win32 (v3.01d)
Message-Id: <[e-mail]>
Precedence: bulk
List-Archive: http://www.imc.org/ietf-pkix/mail-archive/
List-Unsubscribe: mailto:[e-mail]?body=unsubscribe
X-UIDL: ab713cc9a9e83b07a0395a351eb833cf

From:           	[e-mail]

> [Tom Gindin]   Locality is often part of the uniquely identifying set of
> information for a legally registered organization, and thus needs to go
> into some such certificates.  How about some wording such as the
> following: StateOrProvinceName and/or localityName SHOULD be included in
> the subject and issuer name only when the organization or
> organizationalUnit is legally registered as possessing a unique right to
> the specified organizational name within the state or locality specified.

I dont have a problem with that wording for organisations but for org 
units that are in the DIT below their parent organisation (like o=NHS) 
and also beneath a locality then legal registration is not relevant. 
Legal registration would be relevant if the OU was in the DIT directly 
below county and locality and your wording would be correct for this 
situation. But your proposed wording makes this implicit assumption 
without stating it, and I believe that it does not hold true for all 
situations.

David

***************************************************

David Chadwick
IT Institute, University of Salford, Salford M5 4WT
Tel [phone]  Fax [phone]
*NEW* Mobile [phone] *NEW*
Email [e-mail]
Home Page  http://www.salford.ac.uk/its024/chadwick.htm
Understanding X.500  http://www.salford.ac.uk/its024/X500.htm
X.500/LDAP Seminars http://www.salford.ac.uk/its024/seminars.htm
Entrust key validation string MLJ9-DU5T-HV8J

***************************************************


Received: from localhost (daemon@localhost) by mail.proper.com (8.8.8/8.8.5) with SMTP id QAA04555; Fri, 9 Jul 1999 16:10:22 -0700 (PDT)
Received: by mail.imc.org (bulk_mailer v1.12); Fri, 9 Jul 1999 16:10:17 -0700
Received: from praseodumium.btinternet.com (praseodumium.btinternet.com [194.73.73.82]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id QAA04498 for <[e-mail]>; Fri, 9 Jul 1999 16:10:16 -0700 (PDT)
Received: from [212.140.5.16] (helo=dwc-acer) by praseodumium.btinternet.com with smtp (Exim 2.05 #1) id 112jiM-0004PP-00; Sat, 10 Jul 1999 00:05:54 +0100
From: "David Chadwick" <[e-mail]>
Organization: University of Salford
To: "Anders Rundgren" <[e-mail]>, [e-mail]
Date: Sat, 10 Jul 1999 00:14:48 +0100
MIME-Version: 1.0
Content-type: text/plain; charset=US-ASCII
Content-transfer-encoding: 7BIT
Subject: Re: Use of localityName attribute
Reply-to: [e-mail]
CC: "Petra Gloeckner" <[e-mail]>, "PKIX-List" <[e-mail]>, "Stefan Santesson" <[e-mail]>
Priority: normal
In-reply-to: <[e-mail]>
X-mailer: Pegasus Mail for Win32 (v3.01d)
Message-Id: <[e-mail]>
Precedence: bulk
List-Archive: http://www.imc.org/ietf-pkix/mail-archive/
List-Unsubscribe: mailto:[e-mail]?body=unsubscribe
X-UIDL: ab6476f96a5b19f4b2debd1799b92ec8

From:           	[e-mail]

> [Tom Gindin]   Actually, my proposed rule was intended to make the set of
> attributes used more predictable rather than less.  Here's a short version
> of the rules I was suggesting: CN, O, and C MUST be present, OU MAY be
> present, ST and L MAY be present in cases where they are required to
> render a name legally unambiguous and SHOULD NOT be present otherwise. 
> Furthermore, in any country where ST is defined, L MUST NOT be present if
> ST is not present.  Also, since L and ST are intended for legal
> clarification of organization names, they SHOULD come between C and O, and
> MUST come between C and OU.
>

I appreciate what you are trying to do with your rules, but I think that 
a short set such as above will not be sufficient to cater for every 
case, and if you were to do that the text would get too long and 
unwieldly. It might be best to simply stick with Santosh's first wording 
that simply allowed L as an option and leave it up to the good sense 
of the people designing their DNs to do it sensibly and 
unambiguously whilst ensuring that they used legally registered 
names. And leave it at that.

David

***************************************************

David Chadwick
IT Institute, University of Salford, Salford M5 4WT
Tel [phone]  Fax [phone]
*NEW* Mobile [phone] *NEW*
Email [e-mail]
Home Page  http://www.salford.ac.uk/its024/chadwick.htm
Understanding X.500  http://www.salford.ac.uk/its024/X500.htm
X.500/LDAP Seminars http://www.salford.ac.uk/its024/seminars.htm
Entrust key validation string MLJ9-DU5T-HV8J

***************************************************


Received: from localhost (daemon@localhost) by mail.proper.com (8.8.8/8.8.5) with SMTP id QAA04551; Fri, 9 Jul 1999 16:10:22 -0700 (PDT)
Received: by mail.imc.org (bulk_mailer v1.12); Fri, 9 Jul 1999 16:10:18 -0700
Received: from praseodumium.btinternet.com (praseodumium.btinternet.com [194.73.73.82]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id QAA04497 for <[e-mail]>; Fri, 9 Jul 1999 16:10:15 -0700 (PDT)
Received: from [212.140.5.16] (helo=dwc-acer) by praseodumium.btinternet.com with smtp (Exim 2.05 #1) id 112jiO-0004PP-00; Sat, 10 Jul 1999 00:05:56 +0100
From: "David Chadwick" <[e-mail]>
Organization: University of Salford
To: "Petra Gloeckner" <[e-mail]>, "Anders Rundgren" <[e-mail]>
Date: Sat, 10 Jul 1999 00:14:49 +0100
MIME-Version: 1.0
Content-type: text/plain; charset=ISO-8859-1
Subject: Re: Use of localityName attribute
Reply-to: [e-mail]
CC: "PKIX-List" <[e-mail]>, "Stefan Santesson" <[e-mail]>
Priority: normal
In-reply-to: <001c01bec599$e5ea5380$[e-mail]>
X-mailer: Pegasus Mail for Win32 (v3.01d)
Message-Id: <[e-mail]>
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from Quoted-printable to 8bit by mail.proper.com id QAA04505
Precedence: bulk
List-Archive: http://www.imc.org/ietf-pkix/mail-archive/
List-Unsubscribe: mailto:[e-mail]?body=unsubscribe
X-UIDL: 49ae0df585701f26f8607a19a2e6df25

From:           	"Anders Rundgren" <[e-mail]>

> David,
> The answers you got from the QC-editors signifiy what I consider the
> fundamentally flawed model that QC is based on:
> 

Its a pity that you did not describe this model that you have in your 
head, since it is very difficult to pick it up from your comments 
below. It is also difficult to make sensible comments against some 
model that is not explicitly spelt out, but rather has been implicitly 
assumed.


> #1:
> To begin with, miss Glöckner's answer was signed with a QC-like
> certificate which was issued by her employer (?) and was of course not
> trusted by my mail-program's root-certficates which it told me in many
> ways. This is where QCs will fail to meet the needs of the market and will
> make PKI a word associated with offensive amounts of tax-payers money
> spent in vain.  I.e. QCs of that kind have no use outside a very limited
> domain and definitely not in a public area.

I must be missing something here, since I dont see how configuring 
trust in root CA certificates, which clearly needs to be initialised into 
each RP's client before you can trust the subject of a certificate, is 
tied into the debate about the name forms to be used in QCs. Once 
a root is trusted by some possibly out of band means, the QC 
actually makes it much easier to identify who the subject is beneath 
that root.

> 
> 
> #2:
> In many implementations (like yours) both an organization and
> an individual within that organization must be unambiguously defined.
> 

Agreed. This is where I believe QCs help a lot.

> As it is already a hard task to uniquely identify an organization, it
> deserves a certificate of its own.  

Why? If I do not communicate with the organisation (as opposed to 
an organisations CA or manager or employee) what use is the 
certificate?

>And to build identity on local
> addresses is a bad idea as for instance my own company just moved a couple
> of blocks and we are still known as the Swedish company "Jaybis AB" with
> registration number 564567-1267.  If you need to know the address of an
> organization you should look in a public registry (assuming it is legally
> registered) and not in a certificate.

I agree, thats what the directory is for. I did not suggest putting the 
complete address in the certificate (it is too big), just the locality. In 
the UK (at least) hospitals hardly ever move locations. We have 
many still standing from the last century. They are much more stable 
than the lifetime of a certificate. So they make a good unique name 
component for org units like hospitals that have the same common 
name (such as St Marys)

> 
> #3:
> A real problem with QCs is when they also provide information like
> profession and roles because then the need for diversion will make it
> virtually impossible to create interoperability and TTP support.
> 

This is a completely separate topic, not directly related to QCs, but 
related to any type of certificate and how you determine privileges 
for people based on roles. A red herring QC wise in my opinion.

> Solutions?
> TTPs should certify organizations and individuals separately. 
> Organizations themselves should publish additional information about
> employees in formats and ways that are adapted and agreed upon by the
> business segment they operate within.

And how do you get the trust that this person is an employee if his 
subject DN does not have the name of the organisation anywhere 
within it?

David

> 
> QCs do not eliminate that possibility but as indicated by many pre-QC
> projects, it is obviously very tempting to put a lot of stuff in a QC that
> will in the end render it less useful.
> 
> Regards
> Anders Rundgren
> 
> >> I need to request a change to the qualified certificate draft to allow
> >> the use of the localityName attribute to be used to unambiguously
> >> identify a subject and issuer in a DN. The UK National Health Service
> >> Standard for Directory Services requires the use of locality name to
> >> unambiguously identify different organisational units within the NHS.
> >> For example, there are literally dozens of St Mary's Hospitals within
> >> the UK NHS, so that O and OU are insufficient as differentiators.
> >> Consequently localityName, based on the UK Post Office defined
> >> localities, is used to differentiate between them (we do not use the
> >> full postal address as this is too cumbersome.)
> >> 
> >> As the QC draft stands at the moment, (as I read it), the use of
> >> localityName as currently defined by the NHS would not be allowed
> >> as a differentiator.
> >> 
> >> The offending sections are:
> >> 
> >> 3.1.1 Issuer -  allows for state or province name but not for
> >> localityName. We request that localityName be added to this section.
> >> 
> >> 3.1.2 Subject - allows postalAddress but not localityName and states
> >> "Other attributes may be present but MUST NOT be necessary to
> >> distinguish the subject name from other subject names within the issuer
> >> domain."
> >> 
> >> This effectively precludes localityName from being used to
> >> unambiguously differentiate between hospital. We request that
> >> localityName be added to the MAY list.
> >> 
> >> Regards
> >> David
> >> 
> >> ***************************************************
> >> 
> >> David Chadwick
> >> IT Institute, University of Salford, Salford M5 4WT
> >> Tel [phone]  Fax [phone]
> >> *NEW* Mobile [phone] *NEW*
> >> Email [e-mail]
> >> Home Page  http://www.salford.ac.uk/its024/chadwick.htm
> >> Understanding X.500  http://www.salford.ac.uk/its024/X500.htm
> >> X.500/LDAP Seminars http://www.salford.ac.uk/its024/seminars.htm
> >> Entrust key validation string MLJ9-DU5T-HV8J
> >> 
> >> ***************************************************
> 
> 


***************************************************

David Chadwick
IT Institute, University of Salford, Salford M5 4WT
Tel [phone]  Fax [phone]
*NEW* Mobile [phone] *NEW*
Email [e-mail]
Home Page  http://www.salford.ac.uk/its024/chadwick.htm
Understanding X.500  http://www.salford.ac.uk/its024/X500.htm
X.500/LDAP Seminars http://www.salford.ac.uk/its024/seminars.htm
Entrust key validation string MLJ9-DU5T-HV8J

***************************************************


Received: from localhost (daemon@localhost) by mail.proper.com (8.8.8/8.8.5) with SMTP id QAA05278; Fri, 9 Jul 1999 16:34:40 -0700 (PDT)
Received: by mail.imc.org (bulk_mailer v1.12); Fri, 9 Jul 1999 16:34:39 -0700
Received: from www.meridianus.com (209.249.223.21.has.no.reverse [209.249.223.21] (may be forged)) by mail.proper.com (8.8.8/8.8.5) with ESMTP id QAA05256 for <[e-mail]>; Fri, 9 Jul 1999 16:34:38 -0700 (PDT)
Received: from pc1 by www.meridianus.com (8.8.8+Sun/SMI-SVR4) id RAA14147; Fri, 9 Jul 1999 17:30:20 -0700 (PDT)
Message-ID: <044c01beca63$a41671e0$[e-mail]>
From: "[e-mail]" <[e-mail]>
To: <[e-mail]>
Cc: "IETF PKIX" <[e-mail]>
References: <[e-mail]>
Subject: Re: ASN.1 vs XML (used to be RE: I-D ACTION:draft-ietf-pkix-scvp-00.txt)
Date: Fri, 9 Jul 1999 16:34:50 -0700
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.00.2014.211
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2014.211
Precedence: bulk
List-Archive: http://www.imc.org/ietf-pkix/mail-archive/
List-Unsubscribe: mailto:[e-mail]?body=unsubscribe
X-UIDL: 30a52e5a5ce42e705907c5a21e4a7c81

Frank - good point on the XML encoding of ASN.1 Structures - I like it.

Add 'the about to be proposed' preprocessor to resolve all the persistent
objects, their policy, and authentication requirements and who-ha!

----- Original Message -----
From: <[e-mail]>
To: <[e-mail]>; <>
Sent: Friday, July 09, 1999 11:38 AM
Subject: RE: ASN.1 vs XML (used to be RE: I-D
ACTION:draft-ietf-pkix-scvp-00.txt)


> ASN.1 is a syntax

technically its a language. It has a syntax.

> that enables protocol engineers to communicate abstractly
> about bits that may travel down a wire, including the qualities:

after being interpreted by an BER or DER encoder it does.

>
> optional elements
> default values
> inheritance (using object classes)
> constraints
>
> XML is markup language that can be used to format (or encode) bits that
> travel down a wire.
>
> There is no reason why ASN.1-defined data can not be formatted as XML.

Absolutely True !!! Actually this is an interesting observation to make.
That there is really no reason that you cannot write ASN.1 in XML... Imagine
being able to have one framework that encapsulates all service models.


>
> For those of you advocating the use of XML, does XML provide a rich set a
> abstract qualities for engineers to use when communicating about bits that
> may travel down a wire?

Sure it does, or "it could" is a better answer -  becuase there is really no
reason you or anyone else cannot write an XML encoder (ala BER or DER) to
produce this said same datastream.

XML, like ASN.1 is a language and a related syntax to support the conveyance
of certain abstractions. Nothing more. Without the BER or DER encoders to
reduce ASN.1 to its data form.

The fact that no one has one of these tools floating about today is merely
an inconvience in the bigger picture.

>
> Frank Balluffi
> CertCo
>

Todd

---SNIP---




Received: from localhost (daemon@localhost) by mail.proper.com (8.8.8/8.8.5) with SMTP id RAA05678; Fri, 9 Jul 1999 17:00:57 -0700 (PDT)
Received: by mail.imc.org (bulk_mailer v1.12); Fri, 9 Jul 1999 17:00:55 -0700
Received: from www.meridianus.com (209.249.223.21.has.no.reverse [209.249.223.21] (may be forged)) by mail.proper.com (8.8.8/8.8.5) with ESMTP id RAA05656 for <[e-mail]>; Fri, 9 Jul 1999 17:00:55 -0700 (PDT)
Received: from pc1 by www.meridianus.com (8.8.8+Sun/SMI-SVR4) id RAA14171; Fri, 9 Jul 1999 17:56:32 -0700 (PDT)
Message-ID: <047501beca67$4cec7640$[e-mail]>
From: "[e-mail]" <[e-mail]>
To: "Stephen Kent" <[e-mail]>
Cc: "IETF PKIX" <[e-mail]>
References: <000601bec49b$747b3880$2348ffd0@lattin><[e-mail]><v04020a01b3a9087882d1@[128.33.238.77]> <v04020a08b3abb7a578e6@[128.89.0.110]>
Subject: Re: Usage of TDTs
Date: Fri, 9 Jul 1999 17:01:03 -0700
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.00.2014.211
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2014.211
Precedence: bulk
List-Archive: http://www.imc.org/ietf-pkix/mail-archive/
List-Unsubscribe: mailto:[e-mail]?body=unsubscribe
X-UIDL: c2403156f25060ceea80fdb31cf72d44

Steve,
this is getting to long to hammer the entire list with. You and I clearly
see the world through different glasses and since I believe that you believe
what you are saying - as I do, that's OK.

----- Original Message -----
From: Stephen Kent <[e-mail]>
To: [e-mail] <[e-mail]>
Cc: IETF PKIX <[e-mail]>
Sent: Friday, July 09, 1999 11:08 AM
Subject: Re: Usage of TDTs


> Todd,
>

T.






Received: from localhost (daemon@localhost) by mail.proper.com (8.8.8/8.8.5) with SMTP id RAA06022; Fri, 9 Jul 1999 17:15:04 -0700 (PDT)
Received: by mail.imc.org (bulk_mailer v1.12); Fri, 9 Jul 1999 17:15:02 -0700
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 RAA05997 for <[e-mail]>; Fri, 9 Jul 1999 17:14:56 -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 CAA07862 for <[e-mail]>; Sat, 10 Jul 1999 02:15:45 +0200
Received: from mega (t3o69p85.telia.com [62.20.145.85]) by caesar.udac.se (8.7.3/NetworkC-1) with SMTP id CAA106913; Sat, 10 Jul 1999 02:15:42 +0200
Message-ID: <001801beca71$68b1f1c0$[e-mail]>
From: "Anders Rundgren" <[e-mail]>
To: "PKIX-List" <[e-mail]>, "Petra Gloeckner" <[e-mail]>, <[e-mail]>
Cc: "Stefan Santesson" <[e-mail]>
Subject: Re: Use of localityName attribute
Date: Sat, 10 Jul 1999 02:13:23 +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.3110.5
X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by mail.proper.com id RAA06001
Precedence: bulk
List-Archive: http://www.imc.org/ietf-pkix/mail-archive/
List-Unsubscribe: mailto:[e-mail]?body=unsubscribe
X-UIDL: d6dc7291b2188051ec75105ec78fbdbc

David

>> The answers you got from the QC-editors signifiy what I consider the
>> fundamentally flawed model that QC is based on:
>> 
>
>Its a pity that you did not describe this model that you have in your 
>head, since it is very difficult to pick it up from your comments 
>below. It is also difficult to make sensible comments against some 
>model that is not explicitly spelt out, but rather has been implicitly 
>assumed.


Well, some of it was in the points 1-3.

>> #1:
>> To begin with, miss Glöckner's answer was signed with a QC-like
>> certificate which was issued by her employer (?) and was of course not
>> trusted by my mail-program's root-certficates which it told me in many
>> ways. This is where QCs will fail to meet the needs of the market and will
>> make PKI a word associated with offensive amounts of tax-payers money
>> spent in vain.  I.e. QCs of that kind have no use outside a very limited
>> domain and definitely not in a public area.
>
>I must be missing something here, since I dont see how configuring 
>trust in root CA certificates, which clearly needs to be initialised into 
>each RP's client before you can trust the subject of a certificate, is 
>tied into the debate about the name forms to be used in QCs. Once 
>a root is trusted by some possibly out of band means, the QC 
>actually makes it much easier to identify who the subject is beneath 
>that root.


My remark had as you say not so much to do with name-forms.
I just expressed what I feel about a specification that I think will
create more problems than it solves by beeing to imprecise
and too flexible.

But I don't expect you to agree on that as you obviously are up to your
ears into QC-implemenrtations.

This initializing of RPs is though not so easy to do if there are
many roots.  And the QC-specification with its hairy variations
will create many roots since every organsation or business sector
will need different attributes.  Who are U going to trust?

<snip>

>> As it is already a hard task to uniquely identify an organization, it
>> deserves a certificate of its own.  
>
>Why? If I do not communicate with the organisation (as opposed to 
>an organisations CA or manager or employee) what use is the 
>certificate?


This is a very interesting question that I have asked many times but
the QC-camp has not responded to AT ALL:  When and how are QCs to
be used and how many do U need on average? When you know that then it gets 
much more interesting to discuss.

>>And to build identity on local
>> addresses is a bad idea as for instance my own company just moved a couple
>> of blocks and we are still known as the Swedish company "Jaybis AB" with
>> registration number 564567-1267.  If you need to know the address of an
>> organization you should look in a public registry (assuming it is legally
>> registered) and not in a certificate.
>
>I agree, thats what the directory is for. I did not suggest putting the 
>complete address in the certificate (it is too big), just the locality. In 
>the UK (at least) hospitals hardly ever move locations. We have 
>many still standing from the last century. They are much more stable 
>than the lifetime of a certificate. So they make a good unique name 
>component for org units like hospitals that have the same common 
>name (such as St Marys)


Sure, but then you create a system that fits uniquelly well to your perspective only.
How about interoperability? 

>
>> 
>> #3:
>> A real problem with QCs is when they also provide information like
>> profession and roles because then the need for diversion will make it
>> virtually impossible to create interoperability and TTP support.
>> 
>
>This is a completely separate topic, not directly related to QCs, but 
>related to any type of certificate and how you determine privileges 
>for people based on roles. A red herring QC wise in my opinion.

I can't say I know the herring stuff.  Is it an english version of B***S***?
It is a bit related to QCs as some published examples did indeed contain
profession which I consider a bad idea as then you elimnate TTPs
(in most cases) due to cost and inflexibility.

>> Solutions?
>> TTPs should certify organizations and individuals separately. 
>> Organizations themselves should publish additional information about
>> employees in formats and ways that are adapted and agreed upon by the
>> business segment they operate within.
>
>And how do you get the trust that this person is an employee if his 
>subject DN does not have the name of the organisation anywhere 
>within it?

There are several ways to do that.  Directory lookup.  Attribute certificates
and my (in)famous "Thin PKI" approach (no URL here otherwise Steve
will put me in the spam-filter :-(   )

Anders



Received: from localhost (daemon@localhost) by mail.proper.com (8.8.8/8.8.5) with SMTP id NAA02698; Fri, 9 Jul 1999 13:31:49 -0700 (PDT)
Received: by mail.imc.org (bulk_mailer v1.12); Fri, 9 Jul 1999 13:31:37 -0700
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 NAA02676 for <[e-mail]>; Fri, 9 Jul 1999 13:31: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 IAA11879 for <[e-mail]>; Sat, 10 Jul 1999 08:32:24 +1200 (NZST) (sender [e-mail])
Received: by cs26.cs.auckland.ac.nz (relaymail v0.9) id <93155234411584>; Sat, 10 Jul 1999 08:32:24 (NZST)
From: [e-mail] (Peter Gutmann)
To: [e-mail]
Subject: Re: ASN.1 vs XML (used to be RE: I-D ACTION:draft-ietf-pkix-scvp-00.txt)
Sender: [e-mail]
Reply-To: [e-mail]
X-Charge-To: pgut001
X-Authenticated: relaymail v0.9 on cs26.cs.auckland.ac.nz
Date: Sat, 10 Jul 1999 08:32:24 (NZST)
Message-ID: <[e-mail]>
Precedence: bulk
List-Archive: http://www.imc.org/ietf-pkix/mail-archive/
List-Unsubscribe: mailto:[e-mail]?body=unsubscribe
X-UIDL: 404ace490ef0b1867ef8178aa46950d4

Timothy Fisher <[e-mail]>

>Ambarish Malpani wrote:

>>Can we please change the subject on this discussion?

>I think it would be a very smart idea to move the Certificate encoding
>mechanism from ASN.1 to XML.   ASN.1 has always been the down-side of X.509
>certificates.  XML would be a great improvement.

How about the following: Tim redefines and re-specs all of X.509 in XML,
implements the whole lot, and then lets the market decide (for maximum impact
you should do it all in Java and use CORBA/IIOP to move the certs around).  If
XML is really a superior solution then obviously everyone will flock to it and
ASN.1-based X.509 will die a natural death.  QED.

Peter.



Received: from localhost (daemon@localhost) by mail.proper.com (8.8.8/8.8.5) with SMTP id MAA01703; Fri, 9 Jul 1999 12:34:36 -0700 (PDT)
Received: by mail.imc.org (bulk_mailer v1.12); Fri, 9 Jul 1999 12:34:34 -0700
Received: from chi6-1.relay.mail.uu.net (chi6-1.relay.mail.uu.net [199.171.54.98]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id MAA01680 for <[e-mail]>; Fri, 9 Jul 1999 12:34:34 -0700 (PDT)
Received: from xedia.com by chi6sosrv11.alter.net with SMTP  (peer crosschecked as: madway.xedia.com [198.202.232.199]) id QQgxdu12828; Fri, 9 Jul 1999 19:35:22 GMT
Received: from tonga.xedia.com by xedia.com (4.1/SMI-4.1) id AA27429; Fri, 9 Jul 99 15:34:09 EDT
Received: by tonga.xedia.com (SMI-8.6/SMI-SVR4) id PAA29099; Fri, 9 Jul 1999 15:35:18 -0400
Date: Fri, 9 Jul 1999 15:35:18 -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], [e-mail]
Subject: Re: ASN.1 vs XML (used to be RE: I-D ACTION:draft-ietf-pkix-scvp-00.txt)
References: <007f01bec99b$a7c19c70$[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
X-Mailer: VM 6.34 under 20.3 "Vatican City" XEmacs  Lucid
Precedence: bulk
List-Archive: http://www.imc.org/ietf-pkix/mail-archive/
List-Unsubscribe: mailto:[e-mail]?body=unsubscribe
X-UIDL: 6747bfc522b6e50ba303eab4f3103e35

>>>>> "Ben" == Ben Laurie <[e-mail]> writes:

 Ben> Paul Koning wrote:
 >>  I'm really baffled by the notion of creating Yet Another Format
 >> for encoding something when a format exists today that can do the
 >> job.  It may be a leading candidate for the world's ugliest
 >> encoding, admittedly, but it is known to do the job.
 >> 
 >> Creating another encoding will just force implementations to
 >> support two formats rather than one, deal with two sets of bugs
 >> rather than one, cope with backwards compatibility issues when
 >> talking to other boxes that only support one format,
 >> etc. etc. etc.
 >> 
 >> In short, I see no conceivable benefit and lots of drawbacks.  Am
 >> I missing something?

 Ben> I don't know if anyone is suggesting actually creating another
 Ben> format right now (though there are aleady two, anyway) but the
 Ben> important point, I think, is whether further use of ASN.1/DER
 Ben> should be encouraged.  Discussing the relative merits of
 Ben> alternate formats is probably the only way to ever get to a
 Ben> point where we consider using them.

It sure looked like a proposal to create another formant for existing
things, because people were talking about certificates.

I do agree that new things that don't have any encoding yet should not 
be encoded in BER/DER.  But when an encoding exists, no new encodings
should be proposed unless there are VERY strong arguments why it is
better to have to encodings than one.

	paul


Received: from localhost (daemon@localhost) by mail.proper.com (8.8.8/8.8.5) with SMTP id MAA01992; Fri, 9 Jul 1999 12:40:48 -0700 (PDT)
Received: by mail.imc.org (bulk_mailer v1.12); Fri, 9 Jul 1999 12:40:47 -0700
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 MAA01970 for <[e-mail]>; Fri, 9 Jul 1999 12:40:46 -0700 (PDT)
Received: from stingray.missi.ncsc.mil (root@localhost) by stingray.missi.ncsc.mil with ESMTP id PAA26942; Fri, 9 Jul 1999 15:41:38 -0400 (EDT)
Received: from missi.ncsc.mil (depot.missi.ncsc.mil [144.51.60.1]) by stingray.missi.ncsc.mil with ESMTP id PAA26931; Fri, 9 Jul 1999 15:41:37 -0400 (EDT)
Received: from ara.missi.ncsc.mil (ara.missi.ncsc.mil [144.51.58.9]) by missi.ncsc.mil (8.8.8/8.8.8) with ESMTP id PAA26521; Fri, 9 Jul 1999 15:41:38 -0400 (EDT)
Received: from ara.missi.ncsc.mil (ara.missi.ncsc.mil [144.51.58.9]) by ara.missi.ncsc.mil (8.9.1b+Sun/8.9.1) with SMTP id PAA00519; Fri, 9 Jul 1999 15:38:08 -0400 (EDT)
Message-Id: <[e-mail]>
Date: Fri, 9 Jul 1999 15:38:08 -0400 (EDT)
From: "David P. Kemp" <[e-mail]>
Reply-To: "David P. Kemp" <[e-mail]>
Subject: RE: ASN.1 vs XML
To: [e-mail], [e-mail]
Cc: [e-mail]
MIME-Version: 1.0
Content-Type: TEXT/plain; charset=us-ascii
Content-MD5: Dsdbve/zpNdaCpfMUWCqJg==
X-Mailer: dtmail 1.3.0 CDE Version 1.3 SunOS 5.7 sun4u sparc 
Precedence: bulk
List-Archive: http://www.imc.org/ietf-pkix/mail-archive/
List-Unsubscribe: mailto:[e-mail]?body=unsubscribe
X-UIDL: c27d8b4917923bf70e58366047e5cdc7

> From: Paul Koning <[e-mail]>
> 
> >>>>> "BalluffiF" == BalluffiF  <[e-mail]> writes:
> 
>  BalluffiF> ASN.1 is a syntax that enables protocol engineers to
>  BalluffiF> communicate abstractly about bits that may travel down a
>  BalluffiF> wire, ...
> 
> True.
> 
> I think when people say "ASN.1" they really mean "ASN.1 and BER and
> DER" -- and in fact most of the objections are to the latter two, not
> to ASN.1 as an abstract notation.
> 
> 	paul

Yes and no.

I think most people do mean ASN.1 and BER, but I'm not sure that the
objections are mainly to BER or DER.  I believe the objections are to
the use of any formal syntax, because such systems (may)
have a separate compilation step to produce encoders and decoders.

As Paul Hoffman says, it's easier for Perl to parse/emit XML than BER
(although a Perl BER module, which I haven't used, does exist).  But
Perl does not support going directly from *any* formal syntax to
*any* encoding - the encoding and parsing modules must be handcrafted by
someone from some other type of syntax specification.

Anyone who says "Anything but ASN.1/BER" should specify which syntax
language (prose, bits-n'-boxes, ABNF, yacc grammar, ASN.1, ...) and which
encoding/marshalling mechanism (bits-in-a-packet, XML, XDR (RFC 1832),
BER/DER, S-expressions, ...) they are advocating as an alternative, and
provide a full translation of X.509 certs and standard extensions into the
proposed syntax language.  The results of that exercise might be an
eye-opener, and afterwards ASN.1 might not look so ugly after all.



Received: from localhost (daemon@localhost) by mail.proper.com (8.8.8/8.8.5) with SMTP id MAA01143; Fri, 9 Jul 1999 12:10:56 -0700 (PDT)
Received: by mail.imc.org (bulk_mailer v1.12); Fri, 9 Jul 1999 12:10:55 -0700
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 MAA01120 for <[e-mail]>; Fri, 9 Jul 1999 12:10:53 -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 TAA09058; Fri, 9 Jul 1999 19:11:30 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 UAA27526; Fri, 9 Jul 1999 20:11:53 +0100
Message-ID: <[e-mail]>
Date: Fri, 09 Jul 1999 20: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: Paul Koning <[e-mail]>
CC: [e-mail], [e-mail], [e-mail]
Subject: Re: ASN.1 vs XML (used to be RE: I-D ACTION:draft-ietf-pkix-scvp-00.txt)
References: <007f01bec99b$a7c19c70$[e-mail]> <[e-mail]> <[e-mail]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Precedence: bulk
List-Archive: http://www.imc.org/ietf-pkix/mail-archive/
List-Unsubscribe: mailto:[e-mail]?body=unsubscribe
X-UIDL: 7c4d4e063fc120dfa16e69930dde09b1

Paul Koning wrote:
> 
> I'm really baffled by the notion of creating Yet Another Format for
> encoding something when a format exists today that can do the job.  It
> may be a leading candidate for the world's ugliest encoding,
> admittedly, but it is known to do the job.
> 
> Creating another encoding will just force implementations to support
> two formats rather than one, deal with two sets of bugs rather than
> one, cope with backwards compatibility issues when talking to other
> boxes that only support one format, etc. etc. etc.
> 
> In short, I see no conceivable benefit and lots of drawbacks.  Am I
> missing something?

I don't know if anyone is suggesting actually creating another format
right now (though there are aleady two, anyway) but the important point,
I think, is whether further use of ASN.1/DER should be encouraged.
Discussing the relative merits of alternate formats is probably the only
way to ever get to a point where we consider using them.

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 localhost (daemon@localhost) by mail.proper.com (8.8.8/8.8.5) with SMTP id LAA00395; Fri, 9 Jul 1999 11:51:14 -0700 (PDT)
Received: by mail.imc.org (bulk_mailer v1.12); Fri, 9 Jul 1999 11:50:59 -0700
Received: from dfw7-1.relay.mail.uu.net (dfw7-1.relay.mail.uu.net [199.171.54.106]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id LAA00366 for <[e-mail]>; Fri, 9 Jul 1999 11:50:58 -0700 (PDT)
Received: from xedia.com by dfw7sosrv11.alter.net with SMTP  (peer crosschecked as: madway.xedia.com [198.202.232.199]) id QQgxdr10236; Fri, 9 Jul 1999 18:51:49 GMT
Received: from tonga.xedia.com by xedia.com (4.1/SMI-4.1) id AA26784; Fri, 9 Jul 99 14:50:38 EDT
Received: by tonga.xedia.com (SMI-8.6/SMI-SVR4) id OAA28986; Fri, 9 Jul 1999 14:51:47 -0400
Date: Fri, 9 Jul 1999 14:51:47 -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: ASN.1 vs XML (used to be RE: I-D ACTION:draft-ietf-pkix-scvp- 00.txt)
References: <[e-mail]>
X-Mailer: VM 6.34 under 20.3 "Vatican City" XEmacs  Lucid
Precedence: bulk
List-Archive: http://www.imc.org/ietf-pkix/mail-archive/
List-Unsubscribe: mailto:[e-mail]?body=unsubscribe
X-UIDL: 52ea49082971e4b405b7293046c391a1

>>>>> "BalluffiF" == BalluffiF  <[e-mail]> writes:

 BalluffiF> ASN.1 is a syntax that enables protocol engineers to
 BalluffiF> communicate abstractly about bits that may travel down a
 BalluffiF> wire, ...

True.

I think when people say "ASN.1" they really mean "ASN.1 and BER and
DER" -- and in fact most of the objections are to the latter two, not
to ASN.1 as an abstract notation.

	paul


Received: from localhost (daemon@localhost) by mail.proper.com (8.8.8/8.8.5) with SMTP id LAA00682; Fri, 9 Jul 1999 11:57:27 -0700 (PDT)
Received: by mail.imc.org (bulk_mailer v1.12); Fri, 9 Jul 1999 11:57:26 -0700
Received: from aum (ip11.proper.com [165.227.249.11]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id LAA00660 for <[e-mail]>; Fri, 9 Jul 1999 11:57:25 -0700 (PDT)
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58 
Date: Fri, 09 Jul 1999 11:57:59 -0700
To: [e-mail]
From: Paul Hoffman / IMC <[e-mail]>
Subject: RE: ASN.1 vs XML (used to be RE: I-D ACTION:draft-ietf-pkix-scvp- 00.txt)
In-Reply-To: <[e-mail] rtco.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Precedence: bulk
List-Archive: http://www.imc.org/ietf-pkix/mail-archive/
List-Unsubscribe: mailto:[e-mail]?body=unsubscribe
X-UIDL: 67c73456db838229c4ce6d0a16f8b45e

Could we defer this discussion, maybe for about a year? This is a serious 
request.

There is already an IETF WG that is looking at XML digital signatures 
(xmldigsig). Although XML certs are explicitly out of scope for that WG, 
they are also out of scope for the PKIX WG. My guess is that, if they can 
agree to an interoperable way of encoding signatures in XML, they will have 
done most of the work toward encoding certificates, and IETF momentum being 
what it is, I imagine they'll plod ahead into the cert realm before they 
shut themselves down.

I speak here as an early casualty of the XML wars (trying to encode simple 
things like vCards in XML). XML is prettier than ASN.1, and it works better 
with my favorite programming language (Perl). It is also still in a state 
of serious flux that even the XML gurus say has no clear resolution. I 
believe it is too early for almost anyone to be writing format standards 
with XML, because we will see big (and positve) changes in XML in a year or 
two.

We are not XML experts. Let's let those folks have a crack at the 
certificate problem. We have a lovely document full of semantics that we 
can offer to them as a starting point for their syntax explorations. Let's 
leave it at that for now.


--Paul Hoffman, Director
--Internet Mail Consortium



Received: from localhost (daemon@localhost) by mail.proper.com (8.8.8/8.8.5) with SMTP id LAA29165; Fri, 9 Jul 1999 11:07:20 -0700 (PDT)
Received: by mail.imc.org (bulk_mailer v1.12); Fri, 9 Jul 1999 11:07:18 -0700
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 LAA29143 for <[e-mail]>; Fri, 9 Jul 1999 11:07:18 -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 OAA07715; Fri, 9 Jul 1999 14:08:03 -0400 (EDT)
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
X-Sender: [e-mail]
Message-Id: <v04020a08b3abb7a578e6@[128.89.0.110]>
In-Reply-To: <00af01bec95f$080c9130$[e-mail]>
References:  <000601bec49b$747b3880$2348ffd0@lattin><[e-mail]> <v04020a01b3a9087882d1@[128.33.238.77]>
Date: Fri, 9 Jul 1999 14:08:04 -0400
To: "[e-mail]" <[e-mail]>
From: Stephen Kent <[e-mail]>
Subject: Re: Usage of TDTs
Cc: "IETF PKIX" <[e-mail]>
Precedence: bulk
List-Archive: http://www.imc.org/ietf-pkix/mail-archive/
List-Unsubscribe: mailto:[e-mail]?body=unsubscribe
X-UIDL: 51a5d1c37fc69b04ffcf8c373e378742

Todd,

>You talk about Interoperability in your other responses to this commentary
>too and I am wondering where the interoperability is in the many protocols
>that you know have under your watchful care, Oh trustee of the Technology
>Farm Project...

Vendors implement to IETF standards with varying degree of fidelity.  The
IETF has shunned developing explicit test criteria, although that could
certainly help.  Sometimes outside organizations get into the act and
arrange "bakeoffs" to facilitate interoperability testing.  This too is
outside the scope of the IETF.  We usually draw the line between local
implementation issues and interface issues, because the latter affect
interoperability and the former do not.  The assumption is that if we do
our job well, and if vendors implement correctly, then interoperability
will be possible.  The WGs don't always get it right, nor do the vendors,
but it generally works out pretty well over time.  if this is not the sort
of interoperability you're looking for, then perhaps you should look
elsewhere.

>Again the reality is that we are still too early in the development and
>evolutionary curve of PKI to be forced to address the issues of
>interoperability. I liken it to still being "in the Summer of Love" with
>regard to the evolutioon and deployment of commercially usable PKI.

The PKIX standards define protocols, data formats, and processing
conventions to facilitate certificate management for "PKI-enabled"
applications.  We want to do so in a context that permits applications from
various vendors, and CA products and serviecs from various vendors, to
interoperate.  To that end, it is not too early to be working on
interoperability.  Perhaps your definition of interoperability is more far
reaching, more application specific, and that's why you see a disconnect.

<deleted text, purportedly POSSION related>

>>
>> When you criticise the notion that a TSA can be relied upon by its clients
>> to provide accurate timestamps, and cite the insecurities of OSs, you have
>> stepped outside of the bounds of our WG charter, and of IETF standards in
>> general.
>
>So any criticism of the current Timestamping Draft is a criticism of the WG
>Charter? - Right. Or is it a criticism of the OS Model itself. What is it
>that you are saying here, "This Criticism is outside the scope of this WG,
>leave these people alone..." or what?

I am saying that the time stamping draft is based on a notion, stated
repeatedly by many other Wg members, that a TSA is, by definition, trusted
to provide an accurate time stamp function to its subscribers.

>Come on Steve, the reaility is that the lines between the stack, the
>communications processors, and the virtual services interfaces that are a
>part of every commercial OS are blurring to the point of nondistinction. If
>you have any doubt try to "rip" the stack out of Oh say, Solaris 2.6 or
>better yet 2.7, and see what happens. Thin clients are even worse.

I would not disagree with most of this observation, but I also don't see
it's relevance to the discussion.  What I said was that implementation
details are usually not part of our standards work.  If you criticize a
standard based on your perception of how it is to be implemented, the
criticism had better be airtight, i.e., it ought to be based on a generally
agreed upon fundamental problem that will affect ALL implementations, not
one that arises only under certain implementation assumptions.

>and as to Interoperating with a timestamp, does that happen at the routines
>that create the stamp or at the data structure of the stamp itself? My vote
>is at the TSToken or Data Structure of the Stamp itself.

Not sure I understand the context of this comment.

>> One could elect to implement a protocol supporting a TSA in a
>> dedicated device that is immune to these criticisms.
>
>The issue is not whether you need a device to insure theat the OS borne Time
>Services are what they claim to be, but rather what and how the timestamping
>model works.
>
>The model you are so many others are working on is based in the Trusted
>Third Party Model entierly, and I personally think that this is not the type
>of Timestamping that Industry will mandate. If it was, then Surity and
>others would be rockin' on down to the bank to deposit their checks...
>
>What people want in timestamping is a locally valid mechanism of creating
>and verifying  stamps. If they are to be issued remotely, then the said same
>system needs a listener and a daemon or somesuch if you need the TTP
>functionality, but to base the protocol onto the TTP model itself is silly
>and short-sided, IMHO.
>
>The world is likely to want a mechanism to establish as much credibility for
>a Timestamping Solution as possible, and that means that the entire solution
>needs to be able to live on a single platform, i.e. with the app that is
>going to use it. It also means that the stamping model needs to be as
>complete, that is  self-contained, as possible, but the stamps have to be
>small enough to put into a DB without too much pain. Also that they can be
>lightened further for the Warehouseing Operators becuase most of them are
>choking at the concept of a 511 byte stamp like we produce with the
>"neutral" version of BERT. So what is really going on here?
>
>But there is more - the issues with the timestamping model are more
>rudimentry than is being dealt with. It really seems to me that the
>timestamping protocol as suggested so far is trying to do knock-offs of NTP
>and OCSP and some other services that are really not it's responsibility
>either.

Essentially all of the literature on secure time stamping is based on the
use of a TTP as a TSA. The underlying assumption is that a locally
controlled TSA could be manipulated by those who have physical and
administrative control over it.  If this assumption is false, it must be
because of implementation details, which raises issues about standards
scope and perhaps bout vendor-specific technology.  The reason that PKIX is
the home for a time stamp protocol development effort is because we assume
that the protocol will make use of signatures and X.509 certificates, which
fall under the purview of this WG. if these assumptions are not true, then
we may not be the right WG for the activity.  However, when the WG was
asked to voice its opinion on this topic a while ago, the response was
positive.  Thus I plan that the WG will continue to develop time stamp
protocols consistent with these constraints.

>What the time services protocols shoud do is very simple:
>
>    1)    Allow for the credible and audited depolyment of timedata to the
>host systems as part of the timestamping process. Also that the source and
>credibility of the stamps and their timesource are documented.
>
>    2)    Allow for local OS Borne Timestamps to be built and validated
>sapecific to some structure standards, like BERT or whatever.
>
>    3)    Allow for the verification of the timestamps and their ESP's
>through some mechanism
>
>    4)    Run the timestamping model in local or remote models.
>
>    5)    Have at least one prototypical logging model for the use there of
>of #2-4 above
>
>    6)    Create a recommendation for using certified time.

I see a serious disconnect here.  Most of what you describe above is a
secure time distribution service, not a secure time stamping service.  The
former is more appropriately the purview of a newly formed WG and you
should bring these issues up there.

>> It is fair for us to
>> consider, in the course of protocol design, when we may do to facilitate
>> more secure implementation, without prescribing implementation details.
>
>That's good, and this says that the security model is a part of the totality
>of the system, here again demonstrating that the protocol is not the
>protocol itself but a key piece of a larger systems that needs to be
>considered as a system itself.
>
>> However, as a matter of policy, I would not skew a protocol design based
>on
>> any technology that gives undue advantage to any given vendor, e.g., based
>> on use of a patented technology, dominant market position, etc.
>
>So, what your saying is that as the Chair, you personally will not allow for
>any hanky panky in the filing or promulgation of Drafts or their Concepts.
>BUT that the drafts you support must reflect non-proprietary efforts.
>Doesn't this violate the charter of the IETF. I seem to recall that I can
>submit proprietary efforts and you just said that you wouldn't SKEW the
>standards efforts to favor any of these. So what if there are no other
>solutions proposed? - Steve what this sounds like to me is an invitation for
>a lawsuit with the IETF named as the Respondant. Personally I think that
>this is somethign that the IETF needs to protect itself better against but I
>will take that up with POISSON.
>
>I will end this response here but I will address your other concerns in the
>Letter to POISSED about the global changes in the WG Chairs Responsibilities
>as Trustee's Guarding the Technology Grist Mill.

By all means fell free to discuss these issues on the POISSON mailing list.
I am quite comfortable with my stance on this matter. The IETF has never
viewed itself as a vehicle for vendors to receive standards endorsement of
proprietary technology.  We have had much more stringent constraints re
adoption of standards that involve patents, e.g., vs. the IEEE.

Steve


Received: from localhost (daemon@localhost) by mail.proper.com (8.8.8/8.8.5) with SMTP id LAA29881; Fri, 9 Jul 1999 11:38:31 -0700 (PDT)
Received: by mail.imc.org (bulk_mailer v1.12); Fri, 9 Jul 1999 11:38:29 -0700
Received: from btec-fw.certco.com (btec-fw.certco.com [209.2.102.3]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id LAA29858 for <[e-mail]>; Fri, 9 Jul 1999 11:38:26 -0700 (PDT)
From: [e-mail]
Received: from panga.ny.certco.com (panga.ny.certco.com [192.168.69.21]) by btec-fw.certco.com (Postfix) with ESMTP id 1220C32DDC; Fri,  9 Jul 1999 14:39:00 -0400 (EDT)
Received: from nycertco-srv1.ny.certco.com (nycertco-srv1.ny.certco.com [192.168.69.12]) by panga.ny.certco.com (Postfix) with ESMTP id 67CFC54001; Fri,  9 Jul 1999 14:39:00 -0400 (EDT)
Received: by nycertco-srv1.ny.certco.com with Internet Mail Service (5.5.2232.9) id <3SV903R8>; Fri, 9 Jul 1999 14:39:00 -0400
Message-ID: <[e-mail]>
To: [e-mail], [e-mail]
Subject: RE: ASN.1 vs XML (used to be RE: I-D ACTION:draft-ietf-pkix-scvp- 00.txt)
Date: Fri, 9 Jul 1999 14:38:59 -0400 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2232.9)
Content-Type: text/plain; charset="iso-8859-1"
Precedence: bulk
List-Archive: http://www.imc.org/ietf-pkix/mail-archive/
List-Unsubscribe: mailto:[e-mail]?body=unsubscribe
X-UIDL: 9dc797376e8ee75e17def11897faebac

ASN.1 is a syntax that enables protocol engineers to communicate abstractly
about bits that may travel down a wire, including the qualities:

optional elements
default values
inheritance (using object classes)
constraints

XML is markup language that can be used to format (or encode) bits that
travel down a wire.

There is no reason why ASN.1-defined data can not be formatted as XML.

For those of you advocating the use of XML, does XML provide a rich set a
abstract qualities for engineers to use when communicating about bits that
may travel down a wire?

Frank Balluffi
CertCo

-----Original Message-----
From: Ambarish Malpani [mailto:[e-mail]]
Sent: Thursday, July 08, 1999 7:43 PM
To: 'PKIX-List'
Subject: ASN.1 vs XML (used to be RE: I-D
ACTION:draft-ietf-pkix-scvp-00.txt)



Can we please change the subject on this discussion?

Thanks,
Ambarish

---------------------------------------------------------------------
Ambarish Malpani
Architect					         650.567.5457
ValiCert, Inc.				        [e-mail]
1215 Terra Bella Ave.		              http://www.valicert.com
Mountain View, CA 94043-1833


> -----Original Message-----
> From: [e-mail]
> [mailto:[e-mail]]
> Sent: Thursday, July 08, 1999 3:56 PM
> To: Anders Rundgren; PKIX-List; Stephen Kent;
> [e-mail]; William Z Pope
> Subject: Re: I-D ACTION:draft-ietf-pkix-scvp-00.txt
> 
> 
> 
> ----- Original Message -----
> From: Anders Rundgren <[e-mail]>
> To: PKIX-List <[e-mail]>; Stephen Kent <[e-mail]>;
> [e-mail] 
> <[e-mail]>; William Z
> Pope <[e-mail]>
> Sent: Thursday, July 08, 1999 3:31 PM
> Subject: Re: I-D ACTION:draft-ietf-pkix-scvp-00.txt
> 
> 
> > Well,
> > sorry for bringing this up.  For certificates with huge 
> informational
> contents I
> > see some gain by wrapping an XML information object into ASN.1 X509
> > wrapper.  If PKI goes big, certificates proliferate the 
> decoding part (RP
> debugging)
> > will be helped by using XML rather than ASN.1.  Particularly if XML
> becomes
> > the lingua franca of the Web.   But of course XML is not 
> required, it is
> just
> > something that could be worth considering for lets say X509.v4
> 
> Actually if that is your intent,  I would think that the real 
> win here is
> having a number of different cert representation formats that include
> ASN.1/BER-DER, Binary, XML, and SMIME, myself.
> 
> and have the approved Cert Management Protocols support these
> inter-deployment interoperability issues directly.
> 
> Todd.
> 
> 
> 
> 


Received: from localhost (daemon@localhost) by mail.proper.com (8.8.8/8.8.5) with SMTP id KAA28298; Fri, 9 Jul 1999 10:40:06 -0700 (PDT)
Received: by mail.imc.org (bulk_mailer v1.12); Fri, 9 Jul 1999 10:40:04 -0700
Received: from edelweb.fr (edelweb.fr [193.51.12.16]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id KAA28273 for <[e-mail]>; Fri, 9 Jul 1999 10:40:03 -0700 (PDT)
Received: from champagne.edelweb.fr (localhost.edelweb.fr [127.0.0.1]) by edelweb.fr with ESMTP id TAA16834; Fri, 9 Jul 1999 19:40:49 +0200 (MET DST)
Received: from champagne.edelweb.fr (champagne.edelweb.fr [193.51.14.161]) by edelweb.fr (nospam/1.1); Fri, 9 Jul 1999 19:40:49 +0200 (MET DST)
Received: from emeriau.edelweb.fr (emeriau.edelweb.fr [193.51.14.5]) by champagne.edelweb.fr (8.7.6/8.6.6) with ESMTP id TAA25252; Fri, 9 Jul 1999 19:40:48 +0200 (MET DST)
From: Peter Sylvester <[e-mail]>
Received: (sylvest@localhost) by emeriau.edelweb.fr (8.7.6/8.6.6) id TAA15169; Fri, 9 Jul 1999 19:40:47 +0200 (MET DST)
Date: Fri, 9 Jul 1999 19:40:47 +0200 (MET DST)
Message-Id: <[e-mail]>
To: [e-mail], [e-mail]
Subject: Re: ASN.1 vs XML (used to be RE: I-D ACTION:draft-ietf-pkix-scvp-00.txt)
Cc: [e-mail]
Precedence: bulk
List-Archive: http://www.imc.org/ietf-pkix/mail-archive/
List-Unsubscribe: mailto:[e-mail]?body=unsubscribe
X-UIDL: c4daa09fa36ce1d632c255f34204839d

> Bill Burr 

> But, I've been around long enough to remember when very similar claims that
> never panned out, were made for SGML and ASN.1 itself.  It seems perhaps a
> bit too early to just assume that XML will be the great unifying data model
> and format for the next millennium. 
> 
> It replacement of ASN.1 be a reasonable idea to consider, but I'd like to
> see how XML plays our a little more, before jumping head first into the XML
> pool.
> Regards,

If you read the chapter abeot service elements in X.400
(for exemple chapter 4 in the 84 version) you do not find
any indication of ASN.1 or even a data format. 

There is a clear distinction between the semantics of the
abstract service, the data formats used, and the way how
several elements are set in order to provide the desired
service elements.

An interesting example to read is RFC987 and its successors, especially
the comments about service elements in RFC822 (they are IMPLIED), etc. 

> Phillip M Hallam-Baker:

> Tony Hoare once argued that programming language features should be 
> argued separately from the syntax. I would be much happier if IETF
> process encouraged a separation of protocol semantics and syntax.

Impossible, this would be too OSI :-) In some cases it seems to
me that the actual semantics of a protocol is not completely defined
in advance, or the developer of the protocol ist playing the
half-open game: I already put the syntax in the public domain, but
not the semantics. 

Peter Sylvester




Received: from localhost (daemon@localhost) by mail.proper.com (8.8.8/8.8.5) with SMTP id JAA26473; Fri, 9 Jul 1999 09:20:51 -0700 (PDT)
Received: by mail.imc.org (bulk_mailer v1.12); Fri, 9 Jul 1999 09:20:14 -0700
Received: from csmes.ncsl.nist.gov (csmes.ncsl.nist.gov [129.6.54.2]) by mail.proper.com (8.8.8/8.8.5) with SMTP id JAA26444 for <[e-mail]>; Fri, 9 Jul 1999 09:20:14 -0700 (PDT)
Received: from thunderbolt.ncsl.nist.gov (thunderbolt.ncsl.nist.gov [129.6.54.130]) by csmes.ncsl.nist.gov (8.6.12/8.6.4jck0) with SMTP id MAA10707; Fri, 9 Jul 1999 12:21:17 -0400
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (32)
Date: Fri, 09 Jul 1999 12:23:34 -0400
To: Paul Koning <[e-mail]>, [e-mail]
From: Bill Burr <[e-mail]>
Subject: Re: ASN.1 vs XML (used to be RE: I-D ACTION:draft-ietf-pkix-scvp-00.txt)
Cc: [e-mail], [e-mail]
In-Reply-To: <[e-mail]>
References: <007f01bec99b$a7c19c70$[e-mail]> <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Precedence: bulk
List-Archive: http://www.imc.org/ietf-pkix/mail-archive/
List-Unsubscribe: mailto:[e-mail]?body=unsubscribe
X-UIDL: 3893eff6b6c0400a4b75622d7fb2daab

At 11:36 AM 7/9/99 -0400, Paul Koning wrote:
>I'm really baffled by the notion of creating Yet Another Format for
>encoding something when a format exists today that can do the job.  It 
>may be a leading candidate for the world's ugliest encoding,
>admittedly, but it is known to do the job.
>
>Creating another encoding will just force implementations to support
>two formats rather than one, deal with two sets of bugs rather than
>one, cope with backwards compatibility issues when talking to other
>boxes that only support one format, etc. etc. etc.
>
>In short, I see no conceivable benefit and lots of drawbacks.  Am I
>missing something?
>
>	paul
>
>

Paul

The argument, as far as I can see it is:

1.  ASN.1 is so ugly that perhaps it ought to die, and

2.  XML is becoming the great unifying data encoding format, supported by
all the tools, from Microsoft Office to databases and many more specialized
tools, while ASN.1 remains a curiosity with tools that are either largely
unsupported or expensive.  If we will have good pervasive XML tools
supported everywhere, why not plug into them and drop the last OSI baggage?

But, I've been around long enough to remember when very similar claims that
never panned out, were made for SGML and ASN.1 itself.  It seems perhaps a
bit too early to just assume that XML will be the great unifying data model
and format for the next millennium. 

It replacement of ASN.1 be a reasonable idea to consider, but I'd like to
see how XML plays our a little more, before jumping head first into the XML
pool.
Regards,

Bill Burr


Received: from localhost (daemon@localhost) by mail.proper.com (8.8.8/8.8.5) with SMTP id KAA27185; Fri, 9 Jul 1999 10:07:11 -0700 (PDT)
Received: by mail.imc.org (bulk_mailer v1.12); Fri, 9 Jul 1999 10:07:10 -0700
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 KAA27163 for <[e-mail]>; Fri, 9 Jul 1999 10:07:09 -0700 (PDT)
Received: from mentat.verisign.com by caladan.verisign.com (8.8.5/BCH1.5) id KAA03143; Fri, 9 Jul 1999 10:06:21 -0700 (PDT)
Received: from pbaker-pc.verisign.com by mentat.verisign.com (8.8.5/BCH1.0) id KAA25471; Fri, 9 Jul 1999 10:07:28 -0700 (PDT)
From: "Phillip M Hallam-Baker" <[e-mail]>
To: "Bill Burr" <[e-mail]>, "Paul Koning" <[e-mail]>, <[e-mail]>
Cc: <[e-mail]>, <[e-mail]>
Subject: RE: ASN.1 vs XML (used to be RE: I-D ACTION:draft-ietf-pkix-scvp-00.txt)
Date: Fri, 9 Jul 1999 13:08:47 -0400
Message-ID: <002a01beca2d$b54cc940$[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
In-Reply-To: <[e-mail]>
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3
Precedence: bulk
List-Archive: http://www.imc.org/ietf-pkix/mail-archive/
List-Unsubscribe: mailto:[e-mail]?body=unsubscribe
X-UIDL: 35e2a47717e94fb92513a8a44ba57edd

I am reminded of the occasion late in the development of the HTTP spec
when there was some considerable argument over a proposal to correct
the spelling of the 'referer' tag.

I was quite amazed by the number of people who were keen to change the
spelling dispite the fact that they would break an installed base of
gazillions of browsers with a change that would be 1) invisible and
2) if anything slightly decrease performance since each message would
carry an extra byte.

Pausing only to note that my spelling of the word referer is arguably 
the common usage at this point since a trillion web site hits hourly
have that spelling encoded, I would like to make the point that any 
change in syntax needs a lot of justification and that architectural
purity ain't much of a justification.

Tony Hoare once argued that programming language features should be 
argued separately from the syntax. I would be much happier if IETF
process encouraged a separation of protocol semantics and syntax.


		Phill






Received: from localhost (daemon@localhost) by mail.proper.com (8.8.8/8.8.5) with SMTP id KAA27582; Fri, 9 Jul 1999 10:17:47 -0700 (PDT)
Received: by mail.imc.org (bulk_mailer v1.12); Fri, 9 Jul 1999 10:17:46 -0700
Received: from imo28.mx.aol.com (imo28.mx.aol.com [198.81.17.72]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id KAA27560 for <[e-mail]>; Fri, 9 Jul 1999 10:17:45 -0700 (PDT)
From: [e-mail]
Received: from [e-mail] by imo28.mx.aol.com (IMOv20.21) id nFJEa05500 (4226); Fri, 9 Jul 1999 13:15:50 -0400 (EDT)
Message-ID: <[e-mail]>
Date: Fri, 9 Jul 1999 13:14:59 EDT
Subject: Re: ASN.1 vs XML (used to be RE: I-D ACTION:draft-ietf-pkix-scvp-00.txt)
To: [e-mail], [e-mail], [e-mail]
CC: [e-mail], [e-mail]
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: AOL 4.0 for Windows 95 sub 13
Precedence: bulk
List-Archive: http://www.imc.org/ietf-pkix/mail-archive/
List-Unsubscribe: mailto:[e-mail]?body=unsubscribe
X-UIDL: 7685e4f81ea1c8d0743d813d9e98ffb6

Bill,

Good call.    I have people on my team pursuing both approaches, but remain 
agnostic because I have been down this road myself  before.   I believe that 
standards compliance and interoperability are critical for most apps, but 
have been known to build custom non-interoperable stuff using alot of glue 
when necessary.   I think I will wait this one out, but bet on ASN.1 
surviving...Kawika


Kawika Daguio
EVP - Financial Information Protection Association


Received: from localhost (daemon@localhost) by mail.proper.com (8.8.8/8.8.5) with SMTP id IAA25125; Fri, 9 Jul 1999 08:28:35 -0700 (PDT)
Received: by mail.imc.org (bulk_mailer v1.12); Fri, 9 Jul 1999 08:28:34 -0700
Received: from www.meridianus.com (209.249.223.18.has.no.reverse [209.249.223.18] (may be forged)) by mail.proper.com (8.8.8/8.8.5) with ESMTP id IAA25101 for <[e-mail]>; Fri, 9 Jul 1999 08:28:34 -0700 (PDT)
Received: from pc1 by www.meridianus.com (8.8.8+Sun/SMI-SVR4) id JAA13758; Fri, 9 Jul 1999 09:22:54 -0700 (PDT)
Message-ID: <034101beca1f$8b6399f0$[e-mail]>
From: "[e-mail]" <[e-mail]>
To: "Michael Zolotarev" <[e-mail]>
Cc: "IETF PKIX" <[e-mail]>
References: <[e-mail]>
Subject: Re: Usage of TDTs
Date: Fri, 9 Jul 1999 08:27:24 -0700
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.00.2014.211
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2014.211
Precedence: bulk
List-Archive: http://www.imc.org/ietf-pkix/mail-archive/
List-Unsubscribe: mailto:[e-mail]?body=unsubscribe
X-UIDL: 5a3cfed693d92162cdf02884312f3d9d

Thanks Michael. This is a very good suggestion and we support it.

BTW, we have always intended to interoperate between BERT physical tokens,
the BERT Protocol API  and the TSA architecture. There is only a
representation filter to convert structures into event queues using the ZAPC
Draft Protocols... The idea is that generally all of the core enablement
protocols that make up what I refer to as the "Basic Transaction Toolkit" -
that is to say, the primary PKIX4, OCSP, DCS/BERT, etc. should interoperate
together. The intent is to package the core suite as a  PKI-Based Event
Authentication and Assurance "toolkit". This way, the end users get to use
what they want without having to jump through too many painful hoops.

Also, I really believe that the WG' Chairs should encourage us as a
collective group to build and release a "recommendation for use models"
document for the core suite of protocols that we develop.  This
recommendation is likely to be more important as a collective document since
it would be the first in a series of potential IETF-PKIX Recommended
Technologies Brief's that other standard's orgs could rely on. Talk about
adding some value to what we do here, Eh?

In conjunction with producing such a document, we also will need management
buy-in  into selecting ambassadors (formally that is) to the other standards
groups and get our efforts some serious partnering!

What this does in my estimation, is critically reinforces the value of the
PKIX and its process. Also it starts to really make us part of the
operational standards process, instead of just the geeks at the bottom of
the food-chain that came up with the core enablement.

I would propose that Stephen and Warwick add this concept to the agenda in
Oslo and that PKIX start looking at how we package to totality of our
efforts for our friends and sibling WG's into a more "effective"
presentation model, now that we have the core reference layer pretty well
defined.

Todd


----- Original Message -----
From: Michael Zolotarev <[e-mail]>
To: [e-mail] <[e-mail]>; Paul
Hoffman / IMC <[e-mail]>; Denis Pinkas
<Denis.Pinkas[[e-mail]]>; Stephen Kent <[e-mail]>
Sent: Thursday, July 08, 1999 7:27 PM
Subject: RE: Usage of TDTs


> Off-the-records.
>
> Following your discussion is a real pleasure and a very educative
experience. Pity I'm not going to see the live show in Oslo :).
>
> The TDT and general time stamping issue has been around for long enough to
make everybody shudder when there is yet another message in the mailer. The
amount of emotions involved and readiness to defend one's position makes me
believe that we probably has a space for two here, instead of all jamming
into a single cabin. To put it simple - 1) why don't we accomplish the
current TSA draft, and see for ourselves how it performs, and 2) let Todd
with the help of the WG to delineate another approach which he is trying to
foster (local timestamping infrastructure + TDT etc).
>
> I do not see much harm in doing that, as the TSA draft, in its current
state
> 1. addresses at least a subset of real industry's needs
> 2. is not redundant
> 3. does not interfere with other protocols/mechanisms
> 4. insures interoperability and is expandable
> 5. does not claim to do what it does not
> 6. is just a draft, after all
>
> Apart from PKI and other techno-philosophycal issues, the another TS
mechanism would immediately gain the advantage IF its usage/implementation
is not so heavily constrained by the patents, as it happens now.

The only issue is whether the  I think that is still up in the air is
whether any of the later patens are any good and is the RE:34954 Patent's
Claim #1 fort real. If the court upholds the patents primary claim then
there is an issue and all timestamping falls under the realm of this claim.

However, if the claim is struck down for whatever reason, then timestamping
as either the Z/A/C/P Draft as well as McNeils and out BERT and NTP based
solutions will be OK.

As it happens there is a wealth of prior art but who knows.


>
> Michael
>
>
>




Received: from localhost (daemon@localhost) by mail.proper.com (8.8.8/8.8.5) with SMTP id IAA25450; Fri, 9 Jul 1999 08:35:56 -0700 (PDT)
Received: by mail.imc.org (bulk_mailer v1.12); Fri, 9 Jul 1999 08:35:55 -0700
Received: from chi6-1.relay.mail.uu.net (chi6-1.relay.mail.uu.net [199.171.54.98]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id IAA25428 for <[e-mail]>; Fri, 9 Jul 1999 08:35:54 -0700 (PDT)
Received: from xedia.com by chi6sosrv11.alter.net with SMTP  (peer crosschecked as: madway.xedia.com [198.202.232.199]) id QQgxde10552; Fri, 9 Jul 1999 15:36:44 GMT
Received: from tonga.xedia.com by xedia.com (4.1/SMI-4.1) id AA23722; Fri, 9 Jul 99 11:35:34 EDT
Received: by tonga.xedia.com (SMI-8.6/SMI-SVR4) id LAA28783; Fri, 9 Jul 1999 11:36:39 -0400
Date: Fri, 9 Jul 1999 11:36:39 -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: ASN.1 vs XML (used to be RE: I-D ACTION:draft-ietf-pkix-scvp-00.txt)
References: <007f01bec99b$a7c19c70$[e-mail]> <[e-mail]>
X-Mailer: VM 6.34 under 20.3 "Vatican City" XEmacs  Lucid
Precedence: bulk
List-Archive: http://www.imc.org/ietf-pkix/mail-archive/
List-Unsubscribe: mailto:[e-mail]?body=unsubscribe
X-UIDL: 2105544745c8bd52031c4ceeeafe3090

I'm really baffled by the notion of creating Yet Another Format for
encoding something when a format exists today that can do the job.  It 
may be a leading candidate for the world's ugliest encoding,
admittedly, but it is known to do the job.

Creating another encoding will just force implementations to support
two formats rather than one, deal with two sets of bugs rather than
one, cope with backwards compatibility issues when talking to other
boxes that only support one format, etc. etc. etc.

In short, I see no conceivable benefit and lots of drawbacks.  Am I
missing something?

	paul


Received: from localhost (daemon@localhost) by mail.proper.com (8.8.8/8.8.5) with SMTP id IAA24484; Fri, 9 Jul 1999 08:08:15 -0700 (PDT)
Received: by mail.imc.org (bulk_mailer v1.12); Fri, 9 Jul 1999 08:07:59 -0700
Received: from mail.rdc1.az.home.com ([e-mail] [24.1.240.66]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id IAA24451 for <[e-mail]>; Fri, 9 Jul 1999 08:07:58 -0700 (PDT)
Received: from earthlink.net ([24.1.214.107]) by mail.rdc1.az.home.com (InterMail v4.01.01.00 201-229-111) with ESMTP id <[e-mail]>; Fri, 9 Jul 1999 08:08:50 -0700
Message-ID: <[e-mail]>
Date: Fri, 09 Jul 1999 08:10:57 -0700
From: Timothy Fisher <[e-mail]>
X-Mailer: Mozilla 4.61 [en] (WinNT; I)
X-Accept-Language: en
MIME-Version: 1.0
To: Ambarish Malpani <[e-mail]>
CC: "'PKIX-List'" <[e-mail]>
Subject: Re: ASN.1 vs XML (used to be RE: I-D ACTION:draft-ietf-pkix-scvp-00.txt)
References: <007f01bec99b$a7c19c70$[e-mail]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Precedence: bulk
List-Archive: http://www.imc.org/ietf-pkix/mail-archive/
List-Unsubscribe: mailto:[e-mail]?body=unsubscribe
X-UIDL: 7e38620ec2e20d56c511bc335556fb3d

I think it would be a very smart idea to move the Certificate encoding
mechanism from ASN.1 to XML.   ASN.1 has always been the down-side of X.509
certificates.  XML would be a great improvement.

Tim
Cyclone Software

Ambarish Malpani wrote:

> Can we please change the subject on this discussion?
>
> Thanks,
> Ambarish
>
> ---------------------------------------------------------------------
> Ambarish Malpani
> Architect                                                650.567.5457
> ValiCert, Inc.                                  [e-mail]
> 1215 Terra Bella Ave.                        http://www.valicert.com
> Mountain View, CA 94043-1833
>
> > -----Original Message-----
> > From: [e-mail]
> > [mailto:[e-mail]]
> > Sent: Thursday, July 08, 1999 3:56 PM
> > To: Anders Rundgren; PKIX-List; Stephen Kent;
> > [e-mail]; William Z Pope
> > Subject: Re: I-D ACTION:draft-ietf-pkix-scvp-00.txt
> >
> >
> >
> > ----- Original Message -----
> > From: Anders Rundgren <[e-mail]>
> > To: PKIX-List <[e-mail]>; Stephen Kent <[e-mail]>;
> > [e-mail]
> > <[e-mail]>; William Z
> > Pope <[e-mail]>
> > Sent: Thursday, July 08, 1999 3:31 PM
> > Subject: Re: I-D ACTION:draft-ietf-pkix-scvp-00.txt
> >
> >
> > > Well,
> > > sorry for bringing this up.  For certificates with huge
> > informational
> > contents I
> > > see some gain by wrapping an XML information object into ASN.1 X509
> > > wrapper.  If PKI goes big, certificates proliferate the
> > decoding part (RP
> > debugging)
> > > will be helped by using XML rather than ASN.1.  Particularly if XML
> > becomes
> > > the lingua franca of the Web.   But of course XML is not
> > required, it is
> > just
> > > something that could be worth considering for lets say X509.v4
> >
> > Actually if that is your intent,  I would think that the real
> > win here is
> > having a number of different cert representation formats that include
> > ASN.1/BER-DER, Binary, XML, and SMIME, myself.
> >
> > and have the approved Cert Management Protocols support these
> > inter-deployment interoperability issues directly.
> >
> > Todd.
> >
> >
> >
> >



Received: from localhost (daemon@localhost) by mail.proper.com (8.8.8/8.8.5) with SMTP id HAA23201; Fri, 9 Jul 1999 07:10:38 -0700 (PDT)
Received: by mail.imc.org (bulk_mailer v1.12); Fri, 9 Jul 1999 07:10:36 -0700
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 HAA23178 for <[e-mail]>; Fri, 9 Jul 1999 07:10:35 -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 KAA06872; Fri, 9 Jul 1999 10:11:17 -0400 (EDT)
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
X-Sender: [e-mail]
Message-Id: <v04020a04b3abb1930baa@[128.89.0.110]>
In-Reply-To: <[e-mail]>
References: <002201bec991$b0d12510$[e-mail]> <[e-mail]>
Date: Fri, 9 Jul 1999 10:11:06 -0400
To: Ben Laurie <[e-mail]>
From: Stephen Kent <[e-mail]>
Subject: Re: I-D ACTION:draft-ietf-pkix-scvp-00.txt
Cc: PKIX-List <[e-mail]>
Precedence: bulk
List-Archive: http://www.imc.org/ietf-pkix/mail-archive/
List-Unsubscribe: mailto:[e-mail]?body=unsubscribe
X-UIDL: 736af00819addb7053390505e1208d88

Folks,

I think we may be loosing trakc of some issues here.

	- certificates are not the only option for passing around signed
data.  many appications develop their own data structures when then need to
use signatures to ensure data origin authentication and connectionless
integrity, or non-repudiation.  thus, the use of XML for various
applications does not imply a need to use XML in certificates.  don't try
to stuff everything into a cert just because we have an ability to do so
via extensions.

	- depending on the  context, Ben is right that one might be able to
avoid some of the issues that motivate the use of DER in ASN.1. however,
our experience with PEM development back in the late 80s showed the need
for canonical representations in other than just certificates, with regard
to signed data structures.  I disagree with Ben's comments re DER.  while
it is certainly true that people have made mistakes in implementing DER, I
think we are in pretty good shape these days and I'm not aware of any
lingering issues now.

Steve


Received: from localhost (daemon@localhost) by mail.proper.com (8.8.8/8.8.5) with SMTP id GAA22706; Fri, 9 Jul 1999 06:50:49 -0700 (PDT)
Received: by mail.imc.org (bulk_mailer v1.12); Fri, 9 Jul 1999 06:50:30 -0700
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 GAA22682 for <[e-mail]>; Fri, 9 Jul 1999 06:50:28 -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 NAA24636; Fri, 9 Jul 1999 13:48:40 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 OAA25726; Fri, 9 Jul 1999 14:48:55 +0100
Message-ID: <[e-mail]>
Date: Fri, 09 Jul 1999 14:48:39 +0100
From: Ben Laurie <[e-mail]>
Organization: A.L. Group plc
X-Mailer: Mozilla 4.08 [en] (WinNT; I)
MIME-Version: 1.0
To: Kathy Dally <[e-mail]>
CC: Anders Rundgren <[e-mail]>, PKIX-List <[e-mail]>, Stephen Kent <[e-mail]>, "[e-mail]" <[e-mail]>, William Z Pope <[e-mail]>
Subject: Re: I-D ACTION:draft-ietf-pkix-scvp-00.txt
References: <002201bec991$b0d12510$[e-mail]> <[e-mail]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Precedence: bulk
List-Archive: http://www.imc.org/ietf-pkix/mail-archive/
List-Unsubscribe: mailto:[e-mail]?body=unsubscribe
X-UIDL: 9491c54febc6b43d7d57944a9cd226b4

Kathy Dally wrote:
> 
> Hi Anders!
> 
> Two reactions:
> 
>         Wrapping XML/XSL in ASN.1 encoding means implementations must deal with
> both
>         types of encoding.

Which would make it pointless, I presume you are implying.

>         Is XSL encoding always unique or will there be a BER/DER-like problem?

XSL is for presentation, and its uniqueness or lack thereof is not
relevant. XML is not unique, so there is indeed a BER/DER-like problem,
if you believe that the ability to reconstruct the object is needed to
check the signature.

If, on the other hand, you take a realistic approach and only require
the source of the data to be signed and not a reconstructed version,
then you have no such problem. Incidentally, since almost no-one can
implement DER 100% correctly, it seems, DER doesn't solve that problem
anway.

Finally, if people really do want DER-like abilities, I'm sure extra
rules could be applied to XML to make that possible. And since the
result would be considerably less baroque than DER is, it may even be
that sometimes it will get correctly implemented.

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 localhost (daemon@localhost) by mail.proper.com (8.8.8/8.8.5) with SMTP id TAA16866; Thu, 8 Jul 1999 19:23:39 -0700 (PDT)
Received: by mail.imc.org (bulk_mailer v1.12); Thu, 8 Jul 1999 19:23:32 -0700
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 TAA16826 for <[e-mail]>; Thu, 8 Jul 1999 19:23:32 -0700 (PDT)
Received: from lattin (1Cust133.tnt22.sfo3.da.uu.net [208.254.230.133]) by falcon.prod.itd.earthlink.net (8.9.3/8.9.3) with SMTP id TAA28555; Thu, 8 Jul 1999 19:23:27 -0700 (PDT)
From: "Bill Lattin" <[e-mail]>
To: "Stephen Kent" <[e-mail]>, "[e-mail]" <[e-mail]>, <[e-mail]>
Cc: <[e-mail]>
Subject: RE: Usage of TDTs
Date: Thu, 8 Jul 1999 19:22:47 -0700
Message-ID: <000501bec9b1$ef6b17c0$85e6fed0@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: <v04020a01b3a9087882d1@[128.33.238.77]>
Importance: Normal
Precedence: bulk
List-Archive: http://www.imc.org/ietf-pkix/mail-archive/
List-Unsubscribe: mailto:[e-mail]?body=unsubscribe
X-UIDL: 69eca3c5ce8fdefb45aaac4d077049e6

Steve and Denis,

Sorry for the late response to both your emails, but I've been away from my
email for a bit (imagine that :-)).  The following is my response to both
your messages...


While Todd and I share some common concerns regarding information security
and its successful implementation, I do not want the debate about TDTs to be
lost in the forest.  My thread started with a better way to use the optional
TDT field and I would like to keep the spot light focussed brightly on the
need to keep the TDT in the existing draft.  So my thread continues....

In my thread, I am not at all discussing a specific implementation; rather,
I am concerned that the currently proposed time stamp protocol will be
modified to eliminate a useful component which can be used to convey
directly applicable timing information.  Further, if eliminated, then
interoperability will suffer since no standard definition would exist for a
TDT.

The proposed use of the TDT to distribute timing traceable to a National
Timing Authority (NTA) is one which has roots in current business practice,
but which has not yet been extended to the modern digital age.  The concept
of a TSA and its need for policy shows to me that the group is struggling
with this issue (among others).  I am not criticizing the notion that the
TSA cannot be be relied upon by its clients - I have affirmed local trust in
the TSA in prior messages; the problem is that without a link to the
National Time Authority, for certain applications, local TSA policy will be
insufficient - as it is today in the paper world.

Carl Ellison once told me that just as politics are local so is trust in
names, permissions and certificates (sorry Carl for the paraphrased quote).
I agree that this is the case with names, permissions, attributes, etc.  I
disagree that this is necessarily so with time.  The international community
has established a hierarchy for synchronizing clocks and agreeing on time;
if time were purely local, no one would have bothered with such a global
agreement.  It seems that the WG is ignoring this and trying to apply a
local trust policy, similar to that used for certificates, to that of time
stamps.  While this will work for many applications, it will not suffice for
all.

The argument for using the TDT to link a TSA to this national (and
international) timing hierarchy does nothing to diminish the quality of the
TSA; it adds to its quality and it enables the TSA to participate in those
applications that require links to an NTA.  This linkage to the NTA has not
been addressed in the current draft.

Many arguments have been raised by Denis against the proposed TDT.  He
suggested using multiple time stamps instead of the TDT.  While this
approach does add multiple witnesses as does the TDT, it does nothing about
providing a link to the NTA.  He has also suggested that if someone doesn't
trust a TSA, he should use another.  What if this person has an application
that requires a link to the NTA?  Without the proposed TDT, no TSA will
comply.  Denis has suggested that TSAs are sufficient with their variable
bits of accuracy.  We, again, are not talking about local accuracy, but the
ability to tie into the international timing infrastructure.  Finally, Denis
raised the issue that verification of the TST with a TDT will be much longer
and complicated.  I sincerely doubt this is the case - verifying PKIX
certificates will likely be far more complex, but this borders on an
implementation issue :-).

So, in closing, the TDT should be kept in the draft as a necessary component
of the protocol.  The issue we are addressing with the TDT is linkage to the
NTA - something that the current "local policy-centric" approach fails to
address.

Best regards,

Bill


> -----Original Message-----
> From: Stephen Kent [mailto:[e-mail]]
> Sent: Wednesday, July 07, 1999 06:55
> To: [e-mail]
> Cc: [e-mail]
> Subject: Re: Usage of TDTs
>
>
> Todd & Bill,
>
> I think we are seeing some serious disagreements here, in part due to
> fundamentally different assumptions about implementations and the role of
> IETF WGs.
>
> This WG, like all others in the IETF, develops protocols as a means of
> specifying interoperability.  We don't develop implementation
> specifications; we leave that to the implementors, so long as they achieve
> the interoperability requirements of the protocols.  For example, the
> security offered through the use of a protocol such as SSL, IPsec, or
> S/MIME is heavily dependent on the quality of the implementation.
> Moreover, when these protocols are implemented on top of an
> insecure OS, an
> active attacker has a whole new set of opportunities to circumvent the
> security offered by the protocols.  This is a valid concern, but it is
> outside the scope of IETF standards.  (You can find informational RFCs on
> operational and implementation security issues, but they are not
> standards.)
>
> When you criticise the notion that a TSA can be relied upon by its clients
> to provide accurate timestamps, and cite the insecurities of OSs, you have
> stepped outside of the bounds of our WG charter, and of IETF standards in
> general.  One could elect to implement a protocol supporting a TSA in a
> dedicated device that is immune to these criticisms.  It is fair for us to
> consider, in the course of protocol design, when we may do to facilitate
> more secure implementation, without prescribing implementation details.
> However, as a matter of policy, I would not skew a protocol
> design based on
> any technology that gives undue advantage to any given vendor, e.g., based
> on use of a patented technology, dominant market position, etc.
>
> Steve
>



Received: from localhost (daemon@localhost) by mail.proper.com (8.8.8/8.8.5) with SMTP id SAA10934; Thu, 8 Jul 1999 18:43:09 -0700 (PDT)
Received: by mail.imc.org (bulk_mailer v1.12); Thu, 8 Jul 1999 18:43:07 -0700
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 SAA10890 for <[e-mail]>; Thu, 8 Jul 1999 18:42:56 -0700 (PDT)
Received: from sydneymail1.baltimore.com.au (sydneymail1.jp.zergo.com.au [192.168.71.5]) by stargate.zergo.com.au (8.9.1/8.8.7) with ESMTP id LAA05701; Fri, 9 Jul 1999 11:41:25 +1000
Received: by sydneymail1.jp.zergo.com.au with Internet Mail Service (5.5.2448.0) id <3PSBMFPC>; Fri, 9 Jul 1999 11:38:10 +1000
Message-ID: <[e-mail]>
From: Michael Zolotarev <[e-mail]>
To: "[e-mail]" <[e-mail]>, Anders Rundgren <[e-mail]>, PKIX-List <[e-mail]>, Stephen Kent <[e-mail]>, William Z Pope <[e-mail]>
Subject: RE: I-D ACTION:draft-ietf-pkix-scvp-00.txt
Date: Fri, 9 Jul 1999 11:38:09 +1000 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2448.0)
Content-Type: text/plain; charset="iso-8859-1"
Precedence: bulk
List-Archive: http://www.imc.org/ietf-pkix/mail-archive/
List-Unsubscribe: mailto:[e-mail]?body=unsubscribe
X-UIDL: 584f5971df251cc91fec45ba9a6851a2

>Actually if that is your intent,  I would think that the real win here is
>having a number of different cert representation formats that include
>ASN.1/BER-DER, Binary, XML, and SMIME, myself.

>and have the approved Cert Management Protocols support these
>inter-deployment interoperability issues directly.

Replying with your own question, Todd - what is the gain?

Should we just leave ASN.1 as the only cert format? And let another media to absorb it. So that let XML guys define a standard tag for ASN.1-encoded cert. And MIME to define content type for cert (or use degenerated PKCS7 with SMIME), etc, etc.

Anybody having troubles parsing ASN.1 - last week we had a lovely discussion about, didn't we?

Of course, it may worth considering profiling 'data-store' extensions for the X.509 Vxxx cert, to include a general type content, that can be XML, or anything.

Michael



Received: from localhost (daemon@localhost) by mail.proper.com (8.8.8/8.8.5) with SMTP id SAA12728; Thu, 8 Jul 1999 18:53:00 -0700 (PDT)
Received: by mail.imc.org (bulk_mailer v1.12); Thu, 8 Jul 1999 18:52:59 -0700
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 SAA12702 for <[e-mail]>; Thu, 8 Jul 1999 18:52:52 -0700 (PDT)
Received: from sydneymail1.baltimore.com.au (sydneymail1.jp.zergo.com.au [192.168.71.5]) by stargate.zergo.com.au (8.9.1/8.8.7) with ESMTP id LAA05990; Fri, 9 Jul 1999 11:54:25 +1000
Received: by sydneymail1.jp.zergo.com.au with Internet Mail Service (5.5.2448.0) id <3PSBMFPY>; Fri, 9 Jul 1999 11:51:10 +1000
Message-ID: <[e-mail]>
From: Michael Zolotarev <[e-mail]>
To: Anders Rundgren <[e-mail]>, PKIX-List <[e-mail]>, Kathy Dally <[e-mail]>
Subject: RE: I-D ACTION:draft-ietf-pkix-scvp-00.txt
Date: Fri, 9 Jul 1999 11:51:10 +1000 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2448.0)
Content-Type: text/plain; charset="iso-8859-1"
Precedence: bulk
List-Archive: http://www.imc.org/ietf-pkix/mail-archive/
List-Unsubscribe: mailto:[e-mail]?body=unsubscribe
X-UIDL: e29c103e2942502534bb521929103e1f

A little suggestion: please, can we be more considerate about the Subject of the mails? So we change it accordingly when the topic is changed? Otherwise it becomes more of a police detective's job to go through the discussion threads.

Thank you
Michael 

-----Original Message-----
From: Anders Rundgren [mailto:[e-mail]]
Sent: Friday, July 09, 1999 10:24 AM
To: PKIX-List; Kathy Dally
Cc: William Z Pope; [e-mail]; Stephen Kent
Subject: Re: I-D ACTION:draft-ietf-pkix-scvp-00.txt


Hi Kathy,

Comments in line

>
>Two reactions:
>
> Wrapping XML/XSL in ASN.1 encoding means implementations must deal with
>both 
> types of encoding.


That is true.  However, if the XML object for a certificate has a fixed OID there should
be no hard problems to generalize a certificate decoder.

> Is XSL encoding always unique or will there be a BER/DER-like problem?


So far as I know there are no such problems

/Anders



Received: from localhost (daemon@localhost) by mail.proper.com (8.8.8/8.8.5) with SMTP id RAA02738; Thu, 8 Jul 1999 17:59:01 -0700 (PDT)
Received: by mail.imc.org (bulk_mailer v1.12); Thu, 8 Jul 1999 17:58:49 -0700
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 RAA02714 for <[e-mail]>; Thu, 8 Jul 1999 17:58:47 -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 BAA09458 for <[e-mail]>; Fri, 9 Jul 1999 01:25:51 +0200
Received: from mega (t2o69p7.telia.com [62.20.144.127]) by caesar.udac.se (8.7.3/NetworkC-1) with SMTP id BAA62542; Fri, 9 Jul 1999 01:25:49 +0200
Message-ID: <004301bec9a1$463dde90$[e-mail]>
From: "Anders Rundgren" <[e-mail]>
To: "PKIX-List" <[e-mail]>, "Kathy Dally" <[e-mail]>
Cc: "William Z Pope" <[e-mail]>, "[e-mail]" <[e-mail]>, "Stephen Kent" <[e-mail]>
Subject: Re: I-D ACTION:draft-ietf-pkix-scvp-00.txt
Date: Fri, 9 Jul 1999 01:23:30 +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.3110.5
X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by mail.proper.com id RAA02716
Precedence: bulk
List-Archive: http://www.imc.org/ietf-pkix/mail-archive/
List-Unsubscribe: mailto:[e-mail]?body=unsubscribe
X-UIDL: 324d9e64bfb6dd6e9e4d41c5bdf460f4

Hi Kathy,

Comments in line

>
>Two reactions:
>
> Wrapping XML/XSL in ASN.1 encoding means implementations must deal with
>both 
> types of encoding.


That is true.  However, if the XML object for a certificate has a fixed OID there should
be no hard problems to generalize a certificate decoder.

> Is XSL encoding always unique or will there be a BER/DER-like problem?


So far as I know there are no such problems

/Anders




Received: from localhost (daemon@localhost) by mail.proper.com (8.8.8/8.8.5) with SMTP id QAA00497; Thu, 8 Jul 1999 16:08:06 -0700 (PDT)
Received: by mail.imc.org (bulk_mailer v1.12); Thu, 8 Jul 1999 16:04:05 -0700
Received: from www.meridianus.com (209.249.223.17.has.no.reverse [209.249.223.17] (may be forged)) by mail.proper.com (8.8.8/8.8.5) with ESMTP id QAA00427 for <[e-mail]>; Thu, 8 Jul 1999 16:04:05 -0700 (PDT)
Received: from pc1 by www.meridianus.com (8.8.8+Sun/SMI-SVR4) id QAA13281; Thu, 8 Jul 1999 16:51:19 -0700 (PDT)
Message-ID: <027801bec995$9c94a550$[e-mail]>
From: "[e-mail]" <[e-mail]>
To: "Anders Rundgren" <[e-mail]>, "PKIX-List" <[e-mail]>, "Stephen Kent" <[e-mail]>, "[e-mail]" <[e-mail]>, "William Z Pope" <[e-mail]>
References: <002201bec991$b0d12510$[e-mail]>
Subject: Re: I-D ACTION:draft-ietf-pkix-scvp-00.txt
Date: Thu, 8 Jul 1999 15:55:44 -0700
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.00.2014.211
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2014.211
Precedence: bulk
List-Archive: http://www.imc.org/ietf-pkix/mail-archive/
List-Unsubscribe: mailto:[e-mail]?body=unsubscribe
X-UIDL: 1d9987981a478dbf9c5f60b0cb2aa3e5

----- Original Message -----
From: Anders Rundgren <[e-mail]>
To: PKIX-List <[e-mail]>; Stephen Kent <[e-mail]>;
[e-mail] <[e-mail]>; William Z
Pope <[e-mail]>
Sent: Thursday, July 08, 1999 3:31 PM
Subject: Re: I-D ACTION:draft-ietf-pkix-scvp-00.txt


> Well,
> sorry for bringing this up.  For certificates with huge informational
contents I
> see some gain by wrapping an XML information object into ASN.1 X509
> wrapper.  If PKI goes big, certificates proliferate the decoding part (RP
debugging)
> will be helped by using XML rather than ASN.1.  Particularly if XML
becomes
> the lingua franca of the Web.   But of course XML is not required, it is
just
> something that could be worth considering for lets say X509.v4

Actually if that is your intent,  I would think that the real win here is
having a number of different cert representation formats that include
ASN.1/BER-DER, Binary, XML, and SMIME, myself.

and have the approved Cert Management Protocols support these
inter-deployment interoperability issues directly.

Todd.




Received: from localhost (daemon@localhost) by mail.proper.com (8.8.8/8.8.5) with SMTP id QAA01148; Thu, 8 Jul 1999 16:42:45 -0700 (PDT)
Received: by mail.imc.org (bulk_mailer v1.12); Thu, 8 Jul 1999 16:40:03 -0700
Received: from ns1.dmz.valicert.com (ns1.valicert.com [63.65.221.10]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id QAA01092 for <[e-mail]>; Thu, 8 Jul 1999 16:40:02 -0700 (PDT)
Received: from ns1.serverfarm.valicert.com (corporate-gw.valicert.com [63.65.221.2]) by ns1.dmz.valicert.com (8.9.2/8.9.2) with ESMTP id QAA06938 for <[e-mail]>; Thu, 8 Jul 1999 16:38:56 -0700 (PDT)
Received: from rhone (dhcp-3-128.engineering.valicert.com [192.168.3.128] (may be forged)) by ns1.serverfarm.valicert.com (8.9.2/8.9.2) with SMTP id QAA11217 for <[e-mail]>; Thu, 8 Jul 1999 16:40:13 -0700 (PDT)
From: "Ambarish Malpani" <[e-mail]>
To: "'PKIX-List'" <[e-mail]>
Subject: ASN.1 vs XML (used to be RE: I-D ACTION:draft-ietf-pkix-scvp-00.txt)
Date: Thu, 8 Jul 1999 16:43:17 -0700
Message-ID: <007f01bec99b$a7c19c70$[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.3110.3
In-Reply-To: <027801bec995$9c94a550$[e-mail]>
Precedence: bulk
List-Archive: http://www.imc.org/ietf-pkix/mail-archive/
List-Unsubscribe: mailto:[e-mail]?body=unsubscribe
X-UIDL: b874e98ce50db1f6f8876feb461951ab

Can we please change the subject on this discussion?

Thanks,
Ambarish

---------------------------------------------------------------------
Ambarish Malpani
Architect					         650.567.5457
ValiCert, Inc.				        [e-mail]
1215 Terra Bella Ave.		              http://www.valicert.com
Mountain View, CA 94043-1833


> -----Original Message-----
> From: [e-mail]
> [mailto:[e-mail]]
> Sent: Thursday, July 08, 1999 3:56 PM
> To: Anders Rundgren; PKIX-List; Stephen Kent;
> [e-mail]; William Z Pope
> Subject: Re: I-D ACTION:draft-ietf-pkix-scvp-00.txt
> 
> 
> 
> ----- Original Message -----
> From: Anders Rundgren <[e-mail]>
> To: PKIX-List <[e-mail]>; Stephen Kent <[e-mail]>;
> [e-mail] 
> <[e-mail]>; William Z
> Pope <[e-mail]>
> Sent: Thursday, July 08, 1999 3:31 PM
> Subject: Re: I-D ACTION:draft-ietf-pkix-scvp-00.txt
> 
> 
> > Well,
> > sorry for bringing this up.  For certificates with huge 
> informational
> contents I
> > see some gain by wrapping an XML information object into ASN.1 X509
> > wrapper.  If PKI goes big, certificates proliferate the 
> decoding part (RP
> debugging)
> > will be helped by using XML rather than ASN.1.  Particularly if XML
> becomes
> > the lingua franca of the Web.   But of course XML is not 
> required, it is
> just
> > something that could be worth considering for lets say X509.v4
> 
> Actually if that is your intent,  I would think that the real 
> win here is
> having a number of different cert representation formats that include
> ASN.1/BER-DER, Binary, XML, and SMIME, myself.
> 
> and have the approved Cert Management Protocols support these
> inter-deployment interoperability issues directly.
> 
> Todd.
> 
> 
> 
> 


Received: from localhost (daemon@localhost) by mail.proper.com (8.8.8/8.8.5) with SMTP id PAA29235; Thu, 8 Jul 1999 15:24:57 -0700 (PDT)
Received: by mail.imc.org (bulk_mailer v1.12); Thu, 8 Jul 1999 15:24:54 -0700
Received: from smtpproxy1.mitre.org (mbunix.mitre.org [129.83.20.100]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id PAA29207 for <[e-mail]>; Thu, 8 Jul 1999 15:24:53 -0700 (PDT)
Received: from avsrv1.mitre.org (avsrv1.mitre.org [129.83.20.58]) by smtpproxy1.mitre.org (8.9.3/8.9.3) with ESMTP id SAA09311; Thu, 8 Jul 1999 18:20:43 -0400 (EDT)
Received: (from root@localhost) by avsrv1.mitre.org (8.9.3/8.9.3) id SAA23647; Thu, 8 Jul 1999 18:20:32 -0400 (EDT)
Received: from smtpsrv1.mitre.org (smtpsrv1.mitre.org [129.83.20.101]) by avsrv1.mitre.org (8.9.3/8.9.3) with ESMTP id SAA23599; Thu, 8 Jul 1999 18:20:22 -0400 (EDT)
Received: from MAILHUB2 (mailhub2.mitre.org [129.83.221.18]) by smtpsrv1.mitre.org (8.9.3/8.9.3) with ESMTP id SAA00629; Thu, 8 Jul 1999 18:20:10 -0400 (EDT)
Received: from m25060-pc.mitre.org (128.29.105.80) by mailhub2.mitre.org with SMTP id 1152309; Thu, 08 Jul 1999 18:20:09 EST
Message-ID: <[e-mail]>
Date: Thu, 08 Jul 1999 18:22:56 -0400
From: Kathy Dally <[e-mail]>
Organization: The MITRE Corporation
X-Mailer: Mozilla 4.5 [en]C-19990120M  (Win95; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Anders Rundgren <[e-mail]>
CC: PKIX-List <[e-mail]>, Stephen Kent <[e-mail]>, "[e-mail]" <[e-mail]>, William Z Pope <[e-mail]>
Subject: Re: I-D ACTION:draft-ietf-pkix-scvp-00.txt
References: <002201bec991$b0d12510$[e-mail]>
Content-Type: multipart/mixed; boundary="------------C6954E9885C7FD8A92A75656"
Precedence: bulk
List-Archive: http://www.imc.org/ietf-pkix/mail-archive/
List-Unsubscribe: mailto:[e-mail]?body=unsubscribe
X-UIDL: 6186747c527c346ca633d6cdc2e0306b

Hi Anders!

Two reactions:

	Wrapping XML/XSL in ASN.1 encoding means implementations must deal with
both 
	types of encoding.

	Is XSL encoding always unique or will there be a BER/DER-like problem?

Thanks,
Kathy Dally


Anders Rundgren wrote:
> 
> Well,
> sorry for bringing this up.  For certificates with huge informational contents I
> see some gain by wrapping an XML information object into ASN.1 X509
> wrapper.  If PKI goes big, certificates proliferate the decoding part (RP debugging)
> will be helped by using XML rather than ASN.1.  Particularly if XML becomes
> the lingua franca of the Web.   But of course XML is not required, it is just
> something that could be worth considering for lets say X509.v4
> 
> Anders
> 
> >I agree with you that the XSL standard does indeed address the encoding
> >standards, but ther real issue is why change from the standard ASN.1 mindset
> >to XML.
> >
> >What is the gain here?
> >
> >Todd
> >
> >----- Original Message -----
> >From: William Z Pope <[e-mail]>
> >To: [e-mail] <[e-mail]>; Anders
> >Rundgren <[e-mail]>; Stephen Kent <[e-mail]>
> >Cc: <[e-mail]>
> >Sent: Thursday, July 08, 1999 1:14 PM
> >Subject: RE: I-D ACTION:draft-ietf-pkix-scvp-00.txt
> >
> >
> >>
> >> A point of clarification, XML is a human readable data description
> >> format.  I has nothing to do with presentation.  XSL defines presentation
> >> options for XML documents based on the structure and content of the XML
> >> document.
> >>
> >> I now return you to your regularly scheduled discussion :^)
> >>
> >> =bill
> >>
> >> > -----Original Message-----
> >> > From: [e-mail]
> >> > [mailto:[e-mail]]
> >> > Sent: Thursday, July 08, 1999 12:48 PM
> >> > To: Anders Rundgren; Stephen Kent
> >> > Cc: [e-mail]
> >> > Subject: Re: I-D ACTION:draft-ietf-pkix-scvp-00.txt
> >> >
> >> >
> >> > Steve is absolutely right here. The While XML will likely expand to
> >> > encompass a number of the presentation processing formats, ass the core
> >> > representation mechanism we need something better.
> >> >
> >> > Hard to believe but I support Steve's commentary in this 100%
> >> >
> >> >
> >> > Todd
> >> > ----- Original Message -----
> >> > From: Stephen Kent <[e-mail]>
> >> > To: Anders Rundgren <[e-mail]>
> >> > Cc: <[e-mail]>
> >> > Sent: Wednesday, July 07, 1999 3:04 PM
> >> > Subject: RE: I-D ACTION:draft-ietf-pkix-scvp-00.txt
> >> >
> >> >
> >> > > Anders,
> >> > >
> >> > > We have heard from others who work for large companies who use the
> >> > > technology base that you cite as unable to process ASN.1 structures,
> >and
> >> > > their comments are at odds with yours.
> >> > >
> >> > > Yes, there are a lot of folks who are enamored with XML, as one would
> >> > > expect of any new mechanism that has gotten so much hype in
> >> > trade rags.  I
> >> > > don't question the value of XML in some applications, but given the
> >> > > commitment we already have to ASN.1 in our protocols and in the
> >> > base cert
> >> > > and CRL syntax, I don't see a good argument to change here.
> >> > >
> >> > > Barring more evidence to the contrary, we should stick with ASN.1.
> >> > >
> >> > > Steve
> >> > >
> >> >
> >> >
> >>
> >>
> >
> >
> >
Attachment Converted: "C:\Temp\kdally1.vcf"
>From ???@??? Thu Jul 08 15:48:03 1999
Received: from localhost (daemon@localhost)
	by mail.proper.com (8.8.8/8.8.5) with SMTP id PAA29696;
	Thu, 8 Jul 1999 15:41:43 -0700 (PDT)
Received: by mail.imc.org (bulk_mailer v1.12); Thu, 8 Jul 1999 15:38:56 -0700
Received: from generalserver3.commerceone.com ([204.71.220.19])
	by mail.proper.com (8.8.8/8.8.5) with ESMTP id PAA29610
	for <[e-mail]>; Thu, 8 Jul 1999 15:38:56 -0700 (PDT)
Received: by ip5-19.5.20.172.in-addr.arpa with Internet Mail Service (5.5.2448.0)
	id <N4VVZJMB>; Thu, 8 Jul 1999 15:36:01 -0700
Message-ID: <[e-mail]>
From: Zahid Ahmed <[e-mail]>
To: Kathy Dally <[e-mail]>,
        Anders Rundgren
	 <[e-mail]>
Cc: PKIX-List <[e-mail]>, Stephen Kent <[e-mail]>,
        "[e-mail]" <[e-mail]>,
        William Z Pope <[e-mail]>
Subject: RE: I-D ACTION:draft-ietf-pkix-scvp-00.txt
Date: Thu, 8 Jul 1999 15:26:18 -0700 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2448.0)
Content-Type: text/plain;
	charset="iso-8859-1"
Precedence: bulk
List-Archive: http://www.imc.org/ietf-pkix/mail-archive/
List-Unsubscribe: mailto:[e-mail]?body=unsubscribe
X-UIDL: 7d90aac8405516d5e9c832e8016d9c1d


I think there can be advantages of using XML to
describe certificate/identity and management documents 
being included in PKIX description. 

The reason is that most customer/enterprise/application
data is not described in ASN.1. A lot of it may end
up being mapped to XML data description languages. When
such data needs to be included in X.509 certs, e.g.,
we will need to do a mapping between XML and ASN.1.
Most of the time this is straightforward; however,
there are cost involved in converting security data
to and from application data model(s).

Another alternative, I think, within PKIX could be 
to add some v3 or v4 extensions for XML instances.

---Zahid


> -----Original Message-----
> From: Kathy Dally [mailto:[e-mail]]
> Sent: Thursday, July 08, 1999 3:23 PM
> To: Anders Rundgren
> Cc: PKIX-List; Stephen Kent; [e-mail]; 
> William Z Pope
> Subject: Re: I-D ACTION:draft-ietf-pkix-scvp-00.txt
> 
> 
> Hi Anders!
> 
> Two reactions:
> 
> 	Wrapping XML/XSL in ASN.1 encoding means 
> implementations must deal with
> both 
> 	types of encoding.
> 
> 	Is XSL encoding always unique or will there be a 
> BER/DER-like problem?
> 
> Thanks,
> Kathy Dally
> 
> 
> Anders Rundgren wrote:
> > 
> > Well,
> > sorry for bringing this up.  For certificates with huge 
> informational contents I
> > see some gain by wrapping an XML information object into ASN.1 X509
> > wrapper.  If PKI goes big, certificates proliferate the 
> decoding part (RP debugging)
> > will be helped by using XML rather than ASN.1.  
> Particularly if XML becomes
> > the lingua franca of the Web.   But of course XML is not 
> required, it is just
> > something that could be worth considering for lets say X509.v4
> > 
> > Anders
> > 
> > >I agree with you that the XSL standard does indeed address 
> the encoding
> > >standards, but ther real issue is why change from the 
> standard ASN.1 mindset
> > >to XML.
> > >
> > >What is the gain here?
> > >
> > >Todd
> > >
> > >----- Original Message -----
> > >From: William Z Pope <[e-mail]>
> > >To: [e-mail] 
> <[e-mail]>; Anders
> > >Rundgren <[e-mail]>; Stephen Kent 
> <[e-mail]>
> > >Cc: <[e-mail]>
> > >Sent: Thursday, July 08, 1999 1:14 PM
> > >Subject: RE: I-D ACTION:draft-ietf-pkix-scvp-00.txt
> > >
> > >
> > >>
> > >> A point of clarification, XML is a human readable data 
> description
> > >> format.  I has nothing to do with presentation.  XSL 
> defines presentation
> > >> options for XML documents based on the structure and 
> content of the XML
> > >> document.
> > >>
> > >> I now return you to your regularly scheduled discussion :^)
> > >>
> > >> =bill
> > >>
> > >> > -----Original Message-----
> > >> > From: [e-mail]
> > >> > [mailto:[e-mail]]
> > >> > Sent: Thursday, July 08, 1999 12:48 PM
> > >> > To: Anders Rundgren; Stephen Kent
> > >> > Cc: [e-mail]
> > >> > Subject: Re: I-D ACTION:draft-ietf-pkix-scvp-00.txt
> > >> >
> > >> >
> > >> > Steve is absolutely right here. The While XML will 
> likely expand to
> > >> > encompass a number of the presentation processing 
> formats, ass the core
> > >> > representation mechanism we need something better.
> > >> >
> > >> > Hard to believe but I support Steve's commentary in this 100%
> > >> >
> > >> >
> > >> > Todd
> > >> > ----- Original Message -----
> > >> > From: Stephen Kent <[e-mail]>
> > >> > To: Anders Rundgren <[e-mail]>
> > >> > Cc: <[e-mail]>
> > >> > Sent: Wednesday, July 07, 1999 3:04 PM
> > >> > Subject: RE: I-D ACTION:draft-ietf-pkix-scvp-00.txt
> > >> >
> > >> >
> > >> > > Anders,
> > >> > >
> > >> > > We have heard from others who work for large 
> companies who use the
> > >> > > technology base that you cite as unable to process 
> ASN.1 structures,
> > >and
> > >> > > their comments are at odds with yours.
> > >> > >
> > >> > > Yes, there are a lot of folks who are enamored with 
> XML, as one would
> > >> > > expect of any new mechanism that has gotten so much hype in
> > >> > trade rags.  I
> > >> > > don't question the value of XML in some 
> applications, but given the
> > >> > > commitment we already have to ASN.1 in our protocols 
> and in the
> > >> > base cert
> > >> > > and CRL syntax, I don't see a good argument to change here.
> > >> > >
> > >> > > Barring more evidence to the contrary, we should 
> stick with ASN.1.
> > >> > >
> > >> > > Steve
> > >> > >
> > >> >
> > >> >
> > >>
> > >>
> > >
> > >
> > >
> 


Received: from localhost (daemon@localhost) by mail.proper.com (8.8.8/8.8.5) with SMTP id OAA28198; Thu, 8 Jul 1999 14:33:39 -0700 (PDT)
Received: by mail.imc.org (bulk_mailer v1.12); Thu, 8 Jul 1999 14:33:32 -0700
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 OAA28174 for <[e-mail]>; Thu, 8 Jul 1999 14:33: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 XAA08283 for <[e-mail]>; Thu, 8 Jul 1999 23:34:19 +0200
Received: from mega (t4o69p68.telia.com [62.20.145.188]) by caesar.udac.se (8.7.3/NetworkC-1) with SMTP id XAA44887; Thu, 8 Jul 1999 23:34:16 +0200
Message-ID: <002201bec991$b0d12510$[e-mail]>
From: "Anders Rundgren" <[e-mail]>
To: "PKIX-List" <[e-mail]>, "Stephen Kent" <[e-mail]>, "[e-mail]" <[e-mail]>, "William Z Pope" <[e-mail]>
Subject: Re: I-D ACTION:draft-ietf-pkix-scvp-00.txt
Date: Thu, 8 Jul 1999 23:31:57 +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.3110.5
X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by mail.proper.com id OAA28175
Precedence: bulk
List-Archive: http://www.imc.org/ietf-pkix/mail-archive/
List-Unsubscribe: mailto:[e-mail]?body=unsubscribe
X-UIDL: 5ce6818d5a6f77a2ccd8c093c72c5a02

Well,
sorry for bringing this up.  For certificates with huge informational contents I
see some gain by wrapping an XML information object into ASN.1 X509
wrapper.  If PKI goes big, certificates proliferate the decoding part (RP debugging)
will be helped by using XML rather than ASN.1.  Particularly if XML becomes
the lingua franca of the Web.   But of course XML is not required, it is just
something that could be worth considering for lets say X509.v4

Anders

>I agree with you that the XSL standard does indeed address the encoding
>standards, but ther real issue is why change from the standard ASN.1 mindset
>to XML.
>
>What is the gain here?
>
>Todd
>
>----- Original Message -----
>From: William Z Pope <[e-mail]>
>To: [e-mail] <[e-mail]>; Anders
>Rundgren <[e-mail]>; Stephen Kent <[e-mail]>
>Cc: <[e-mail]>
>Sent: Thursday, July 08, 1999 1:14 PM
>Subject: RE: I-D ACTION:draft-ietf-pkix-scvp-00.txt
>
>
>>
>> A point of clarification, XML is a human readable data description
>> format.  I has nothing to do with presentation.  XSL defines presentation
>> options for XML documents based on the structure and content of the XML
>> document.
>>
>> I now return you to your regularly scheduled discussion :^)
>>
>> =bill
>>
>> > -----Original Message-----
>> > From: [e-mail]
>> > [mailto:[e-mail]]
>> > Sent: Thursday, July 08, 1999 12:48 PM
>> > To: Anders Rundgren; Stephen Kent
>> > Cc: [e-mail]
>> > Subject: Re: I-D ACTION:draft-ietf-pkix-scvp-00.txt
>> >
>> >
>> > Steve is absolutely right here. The While XML will likely expand to
>> > encompass a number of the presentation processing formats, ass the core
>> > representation mechanism we need something better.
>> >
>> > Hard to believe but I support Steve's commentary in this 100%
>> >
>> >
>> > Todd
>> > ----- Original Message -----
>> > From: Stephen Kent <[e-mail]>
>> > To: Anders Rundgren <[e-mail]>
>> > Cc: <[e-mail]>
>> > Sent: Wednesday, July 07, 1999 3:04 PM
>> > Subject: RE: I-D ACTION:draft-ietf-pkix-scvp-00.txt
>> >
>> >
>> > > Anders,
>> > >
>> > > We have heard from others who work for large companies who use the
>> > > technology base that you cite as unable to process ASN.1 structures,
>and
>> > > their comments are at odds with yours.
>> > >
>> > > Yes, there are a lot of folks who are enamored with XML, as one would
>> > > expect of any new mechanism that has gotten so much hype in
>> > trade rags.  I
>> > > don't question the value of XML in some applications, but given the
>> > > commitment we already have to ASN.1 in our protocols and in the
>> > base cert
>> > > and CRL syntax, I don't see a good argument to change here.
>> > >
>> > > Barring more evidence to the contrary, we should stick with ASN.1.
>> > >
>> > > Steve
>> > >
>> >
>> >
>>
>>
>
>
>



Received: from localhost (daemon@localhost) by mail.proper.com (8.8.8/8.8.5) with SMTP id MAA26189; Thu, 8 Jul 1999 12:50:36 -0700 (PDT)
Received: by mail.imc.org (bulk_mailer v1.12); Thu, 8 Jul 1999 12:50:22 -0700
Received: from www.meridianus.com (209.249.223.21.has.no.reverse [209.249.223.21] (may be forged)) by mail.proper.com (8.8.8/8.8.5) with ESMTP id MAA26164 for <[e-mail]>; Thu, 8 Jul 1999 12:50:22 -0700 (PDT)
Received: from pc1 by www.meridianus.com (8.8.8+Sun/SMI-SVR4) id NAA13109; Thu, 8 Jul 1999 13:43:54 -0700 (PDT)
Message-ID: <015e01bec97a$d446b7b0$[e-mail]>
From: "[e-mail]" <[e-mail]>
To: "Anders Rundgren" <[e-mail]>, "Stephen Kent" <[e-mail]>
Cc: <[e-mail]>
References: <v04020a03b3a90d93b5b5@[128.33.238.77]>
Subject: Re: I-D ACTION:draft-ietf-pkix-scvp-00.txt
Date: Thu, 8 Jul 1999 12:48:18 -0700
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.00.2014.211
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2014.211
Precedence: bulk
List-Archive: http://www.imc.org/ietf-pkix/mail-archive/
List-Unsubscribe: mailto:[e-mail]?body=unsubscribe
X-UIDL: 02e0cb7d52990196aca274b51fcf68ac

Steve is absolutely right here. The While XML will likely expand to
encompass a number of the presentation processing formats, ass the core
representation mechanism we need something better.

Hard to believe but I support Steve's commentary in this 100%


Todd
----- Original Message -----
From: Stephen Kent <[e-mail]>
To: Anders Rundgren <[e-mail]>
Cc: <[e-mail]>
Sent: Wednesday, July 07, 1999 3:04 PM
Subject: RE: I-D ACTION:draft-ietf-pkix-scvp-00.txt


> Anders,
>
> We have heard from others who work for large companies who use the
> technology base that you cite as unable to process ASN.1 structures, and
> their comments are at odds with yours.
>
> Yes, there are a lot of folks who are enamored with XML, as one would
> expect of any new mechanism that has gotten so much hype in trade rags.  I
> don't question the value of XML in some applications, but given the
> commitment we already have to ASN.1 in our protocols and in the base cert
> and CRL syntax, I don't see a good argument to change here.
>
> Barring more evidence to the contrary, we should stick with ASN.1.
>
> Steve
>




Received: from localhost (daemon@localhost) by mail.proper.com (8.8.8/8.8.5) with SMTP id NAA26654; Thu, 8 Jul 1999 13:16:45 -0700 (PDT)
Received: by mail.imc.org (bulk_mailer v1.12); Thu, 8 Jul 1999 13:16:41 -0700
Received: from debbie.dascom.com (debbie.dascom.com [12.7.226.1]) by mail.proper.com (8.8.8/8.8.5) with SMTP id NAA26631 for <[e-mail]>; Thu, 8 Jul 1999 13:16:41 -0700 (PDT)
Received: (qmail 1399 invoked from network); 8 Jul 1999 20:17:28 -0000
Received: from server.cruz.dascom.com (HELO dascom.com) (10.0.0.171) by debbie.dascom.com with SMTP; 8 Jul 1999 20:17:28 -0000
Received: from cowell (cowell.cruz.dascom.com [10.0.0.147]) by dascom.com ; Thu, 8 Jul 1999 13:17:32 -0700 (PDT)
From: "William Z Pope" <[e-mail]>
To: "[e-mail]" <[e-mail]>, "Anders Rundgren" <[e-mail]>, "Stephen Kent" <[e-mail]>
Cc: <[e-mail]>
Subject: RE: I-D ACTION:draft-ietf-pkix-scvp-00.txt
Date: Thu, 8 Jul 1999 13:14:07 -0700
Message-ID: <000301bec97e$6f16f3b0$[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
X-MimeOLE: Produced By Microsoft MimeOLE V4.72.2106.4
Importance: Normal
In-Reply-To: <015e01bec97a$d446b7b0$[e-mail]>
Precedence: bulk
List-Archive: http://www.imc.org/ietf-pkix/mail-archive/
List-Unsubscribe: mailto:[e-mail]?body=unsubscribe
X-UIDL: 69b299a6cf8e199dbcc080771117a9b9

A point of clarification, XML is a human readable data description
format.  I has nothing to do with presentation.  XSL defines presentation
options for XML documents based on the structure and content of the XML
document.

I now return you to your regularly scheduled discussion :^)

=bill

> -----Original Message-----
> From: [e-mail]
> [mailto:[e-mail]]
> Sent: Thursday, July 08, 1999 12:48 PM
> To: Anders Rundgren; Stephen Kent
> Cc: [e-mail]
> Subject: Re: I-D ACTION:draft-ietf-pkix-scvp-00.txt
>
>
> Steve is absolutely right here. The While XML will likely expand to
> encompass a number of the presentation processing formats, ass the core
> representation mechanism we need something better.
>
> Hard to believe but I support Steve's commentary in this 100%
>
>
> Todd
> ----- Original Message -----
> From: Stephen Kent <[e-mail]>
> To: Anders Rundgren <[e-mail]>
> Cc: <[e-mail]>
> Sent: Wednesday, July 07, 1999 3:04 PM
> Subject: RE: I-D ACTION:draft-ietf-pkix-scvp-00.txt
>
>
> > Anders,
> >
> > We have heard from others who work for large companies who use the
> > technology base that you cite as unable to process ASN.1 structures, and
> > their comments are at odds with yours.
> >
> > Yes, there are a lot of folks who are enamored with XML, as one would
> > expect of any new mechanism that has gotten so much hype in
> trade rags.  I
> > don't question the value of XML in some applications, but given the
> > commitment we already have to ASN.1 in our protocols and in the
> base cert
> > and CRL syntax, I don't see a good argument to change here.
> >
> > Barring more evidence to the contrary, we should stick with ASN.1.
> >
> > Steve
> >
>
>



Received: from localhost (daemon@localhost) by mail.proper.com (8.8.8/8.8.5) with SMTP id NAA26932; Thu, 8 Jul 1999 13:25:31 -0700 (PDT)
Received: by mail.imc.org (bulk_mailer v1.12); Thu, 8 Jul 1999 13:25:30 -0700
Received: from www.meridianus.com (209.249.223.10.has.no.reverse [209.249.223.10] (may be forged)) by mail.proper.com (8.8.8/8.8.5) with ESMTP id NAA26909; Thu, 8 Jul 1999 13:25:30 -0700 (PDT)
Received: from pc1 by www.meridianus.com (8.8.8+Sun/SMI-SVR4) id OAA13152; Thu, 8 Jul 1999 14:21:09 -0700 (PDT)
Message-ID: <018d01bec980$07580b40$[e-mail]>
From: "[e-mail]" <[e-mail]>
To: "Paul Hoffman / IMC" <[e-mail]>
Cc: "IETF PKIX" <[e-mail]>
References: <000601bec49b$747b3880$2348ffd0@lattin><[e-mail]><v04020a01b3a9087882d1@[128.33.238.77]> <[e-mail]>
Subject: Re: Usage of TDTs
Date: Thu, 8 Jul 1999 13:25:32 -0700
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.00.2014.211
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2014.211
Precedence: bulk
List-Archive: http://www.imc.org/ietf-pkix/mail-archive/
List-Unsubscribe: mailto:[e-mail]?body=unsubscribe
X-UIDL: 59671dcc7e8bbf2b46d6ad8191317568

Paul, exactly what in this comment is a threat?

Seems like you are focusing on shooting the messeger rather than reading the
messege.

>
> >  - Steve what this sounds like to me is an invitation for
> >a lawsuit with the IETF named as the Respondant.
>
> Todd, do you think that making threats like this will make people want to
> adopt your proposals?

So who is making threats here? - Certianly not me. Nowhere does it say "I am
going to sue you"...  What it does say is that as a Lay Person, that spends
a substantial amount of time around Counsel, that this is an issue. -
Nothing more - What I am concerned with is the sanctity and value of the
efforts that we as IETF Particilpants invest in the IETF process. So in
response to this acerbic retort of yours - I have to ask "Why is it that
you, IMC Directorate,  and the rest of the management of the WG's take
criticism of the current Modus Opeandi as a threat?".

> Do you react positively when folks threaten you like
> this?

Where is the paranoia coming from here? You hold a public office and are
subjetc to public review because of it. Sorry, that's just the way it is.

> I'd imagine not.

Can I assume that you are taking the 'pointing out that you and the other WG
Chairs might be vulnerable to legal attack' as a threat?. I am sorry that
this is your interpretation -  I thought it was an observation of a
potential threat to the sanctity of our communal process here. Something
that we need to address so it doesn't happen.

In particular Paul, in light of this clarification - What is your problem
with this concept ?

> The best way for you to get your ideas adopted is to
> write an Internet Draft, have it discussed on the list, and see if there
is
> any interest.
>
> --Paul Hoffman, Director
> --Internet Mail Consortium
>

Paul, like I said in the commentary of both of the letters I sent out... I
am not interested in going to war with anyone over these issues, obviously
you included, but I believe that you're looking at issues down in the
basement and claiming that the current policies rooted in the attic cover
them, and IMHO you are dead wrong here.  The problem is that a good number
of the issues I have pointed out aren't totally out in the light and I think
that your response above is based in maintaining the Status Quo rather than
dealing with the issues at hand.

Or am I wrong here too?... If I am wrong, then I steadfastly apologize for
any consternation I caused in your life... But if I am right then you and
every other WG Chair owes me this debt as it does with every other IETF/IMC
participant, and that is a problem. Its in my mind exactly the thing that
you pointed out when you said that "things were not going to change" and
signed it with the IMC Directorate's Signature.... See - the reality is that
'things' as you put it,  have and are continuing to change whether you, I,
or anyone else likes it or not.

BTW, I personally find it offensive for you as the IMC Director to slam
people on the list. If you want to slam me - then use your own signature and
do it as a normal mortal., but keep the IMC clean.

Todd
<Standard Disclaimers Apply>







Received: from localhost (daemon@localhost) by mail.proper.com (8.8.8/8.8.5) with SMTP id NAA27184; Thu, 8 Jul 1999 13:31:16 -0700 (PDT)
Received: by mail.imc.org (bulk_mailer v1.12); Thu, 8 Jul 1999 13:31:14 -0700
Received: from www.meridianus.com (209.249.223.16.has.no.reverse [209.249.223.16] (may be forged)) by mail.proper.com (8.8.8/8.8.5) with ESMTP id NAA27162 for <[e-mail]>; Thu, 8 Jul 1999 13:31:14 -0700 (PDT)
Received: from pc1 by www.meridianus.com (8.8.8+Sun/SMI-SVR4) id OAA13157; Thu, 8 Jul 1999 14:23:50 -0700 (PDT)
Message-ID: <019801bec980$6796b740$[e-mail]>
From: "[e-mail]" <[e-mail]>
To: "William Z Pope" <[e-mail]>, "[e-mail]" <[e-mail]>, "Anders Rundgren" <[e-mail]>, "Stephen Kent" <[e-mail]>
Cc: <[e-mail]>
References: <000301bec97e$6f16f3b0$[e-mail]>
Subject: Re: I-D ACTION:draft-ietf-pkix-scvp-00.txt
Date: Thu, 8 Jul 1999 13:28:14 -0700
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.00.2014.211
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2014.211
Precedence: bulk
List-Archive: http://www.imc.org/ietf-pkix/mail-archive/
List-Unsubscribe: mailto:[e-mail]?body=unsubscribe
X-UIDL: 3391d6c144b5d83a15f203ee0c5d72eb

I agree with you that the XSL standard does indeed address the encoding
standards, but ther real issue is why change from the standard ASN.1 mindset
to XML.

What is the gain here?

Todd

----- Original Message -----
From: William Z Pope <[e-mail]>
To: [e-mail] <[e-mail]>; Anders
Rundgren <[e-mail]>; Stephen Kent <[e-mail]>
Cc: <[e-mail]>
Sent: Thursday, July 08, 1999 1:14 PM
Subject: RE: I-D ACTION:draft-ietf-pkix-scvp-00.txt


>
> A point of clarification, XML is a human readable data description
> format.  I has nothing to do with presentation.  XSL defines presentation
> options for XML documents based on the structure and content of the XML
> document.
>
> I now return you to your regularly scheduled discussion :^)
>
> =bill
>
> > -----Original Message-----
> > From: [e-mail]
> > [mailto:[e-mail]]
> > Sent: Thursday, July 08, 1999 12:48 PM
> > To: Anders Rundgren; Stephen Kent
> > Cc: [e-mail]
> > Subject: Re: I-D ACTION:draft-ietf-pkix-scvp-00.txt
> >
> >
> > Steve is absolutely right here. The While XML will likely expand to
> > encompass a number of the presentation processing formats, ass the core
> > representation mechanism we need something better.
> >
> > Hard to believe but I support Steve's commentary in this 100%
> >
> >
> > Todd
> > ----- Original Message -----
> > From: Stephen Kent <[e-mail]>
> > To: Anders Rundgren <[e-mail]>
> > Cc: <[e-mail]>
> > Sent: Wednesday, July 07, 1999 3:04 PM
> > Subject: RE: I-D ACTION:draft-ietf-pkix-scvp-00.txt
> >
> >
> > > Anders,
> > >
> > > We have heard from others who work for large companies who use the
> > > technology base that you cite as unable to process ASN.1 structures,
and
> > > their comments are at odds with yours.
> > >
> > > Yes, there are a lot of folks who are enamored with XML, as one would
> > > expect of any new mechanism that has gotten so much hype in
> > trade rags.  I
> > > don't question the value of XML in some applications, but given the
> > > commitment we already have to ASN.1 in our protocols and in the
> > base cert
> > > and CRL syntax, I don't see a good argument to change here.
> > >
> > > Barring more evidence to the contrary, we should stick with ASN.1.
> > >
> > > Steve
> > >
> >
> >
>
>




Received: from localhost (daemon@localhost) by mail.proper.com (8.8.8/8.8.5) with SMTP id KAA23288; Thu, 8 Jul 1999 10:35:41 -0700 (PDT)
Received: by mail.imc.org (bulk_mailer v1.12); Thu, 8 Jul 1999 10:35:37 -0700
Received: from honcho.austin.dascom.com (email.austin.dascom.com [206.196.73.5]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id KAA23266 for <[e-mail]>; Thu, 8 Jul 1999 10:35:37 -0700 (PDT)
Received: from austin.dascom.com by honcho.austin.dascom.com (8.8.8/SMI-SVR4) id MAA22364; Thu, 8 Jul 1999 12:33:44 -0500 (CDT)
Received: from shaggy by austin.dascom.com (8.8.8/SMI-SVR4) id MAA27525; Thu, 8 Jul 1999 12:33:43 -0500 (CDT)
Message-ID: <005401bec968$88c8df00$[e-mail]>
Reply-To: "Bob Blakley" <[e-mail]>
From: "Bob Blakley" <[e-mail]>
To: "[e-mail]" <[e-mail]>, "Stephen Kent" <[e-mail]>
Cc: "IETF PKIX" <[e-mail]>
Subject: Re: NEED A BETTER PKI use ROADMAP - was Re: Initial comments onSCVP
Date: Thu, 8 Jul 1999 12:37:21 -0500
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="----=_NextPart_000_0051_01BEC93E.9FB8DB40"
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 4.72.3110.1
X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3
Precedence: bulk
List-Archive: http://www.imc.org/ietf-pkix/mail-archive/
List-Unsubscribe: mailto:[e-mail]?body=unsubscribe
X-UIDL: 2d9620478eb3611441e17a0476ac9851

Steve,

>>    2)    The Scope of the efforts and responsibilities of the
>>players/protocols
>
>Protocols, not being people, are not responsible :-).  Scope was addressed
>above.

"responsibilities of the players" parses properly and makes sense; I do think
it deserves an answer.  I think the answer can be found in the various drafts
in the form of specifications of what kinds of messages each participant
in a PKI can consume and produce.

--bob

Bob Blakley ([e-mail])
Chief Scientist, Dascom

Attachment Converted: "C:\Temp\Bob Blakley.vcf"
>From ???@??? Thu Jul 08 15:18:27 1999
Received: from localhost (daemon@localhost)
	by mail.proper.com (8.8.8/8.8.5) with SMTP id LAA24495;
	Thu, 8 Jul 1999 11:22:20 -0700 (PDT)
Received: by mail.imc.org (bulk_mailer v1.12); Thu, 8 Jul 1999 11:22:14 -0700
Received: from www.meridianus.com (209.249.223.17.has.no.reverse [209.249.223.17] (may be forged))
	by mail.proper.com (8.8.8/8.8.5) with ESMTP id LAA24470
	for <[e-mail]>; Thu, 8 Jul 1999 11:22:13 -0700 (PDT)
Received: from pc1 by www.meridianus.com (8.8.8+Sun/SMI-SVR4)
	id MAA12940; Thu, 8 Jul 1999 12:17:48 -0700 (PDT)
Message-ID: <010701bec96e$cc5f8470$[e-mail]>
From: "[e-mail]" <[e-mail]>
To: "Juan Rodriguez-Torrent" <[e-mail]>, <[e-mail]>,
        <[e-mail]>, <[e-mail]>,
        <[e-mail]>, <[e-mail]>,
        <[e-mail]>, <WG-Authentication&[e-mail]>,
        <[e-mail]>
References: <00a801bec903$4c260ec0$[e-mail]>
Subject: Re: RFC 2527 revision
Date: Thu, 8 Jul 1999 11:22:10 -0700
MIME-Version: 1.0
Content-Type: multipart/alternative;
	boundary="----=_NextPart_000_0104_01BEC934.1EF3A940"
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.00.2014.211
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2014.211
Precedence: bulk
List-Archive: http://www.imc.org/ietf-pkix/mail-archive/
List-Unsubscribe: mailto:[e-mail]?body=unsubscribe
X-UIDL: 103a1536696615d740e3a480f599d946


<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META content="text/html; charset=iso-8859-1" http-equiv=Content-Type>
<META content="MSHTML 5.00.2014.210" name=GENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=#ffffff>
<DIV><FONT face=Arial size=2>Juan, can you clarify the plans for promulgating 
the document(s) in question to the various other organizations that need to buy 
into it, and any plans by the creator's to address this.</FONT></DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT face=Arial size=2>Todd</FONT></DIV>
<DIV>&nbsp;</DIV>
<BLOCKQUOTE 
style="BORDER-LEFT: #000000 2px solid; MARGIN-LEFT: 5px; MARGIN-RIGHT: 0px; PADDING-LEFT: 5px; PADDING-RIGHT: 0px">
  <DIV style="FONT: 10pt arial">----- Original Message ----- </DIV>
  <DIV 
  style="BACKGROUND: #e4e4e4; FONT: 10pt arial; font-color: black"><B>From:</B> 
  <A href="mailto:[e-mail]" title=[e-mail]>Juan 
  Rodriguez-Torrent</A> </DIV>
  <DIV style="FONT: 10pt arial"><B>To:</B> <A href="mailto:[e-mail]" 
  title=[e-mail]>[e-mail]</A> ; <A 
  href="mailto:[e-mail]" title=[e-mail]>[e-mail]</A> 
  ; <A href="mailto:[e-mail]" 
  title=[e-mail]>[e-mail]</A> ; <A 
  href="mailto:[e-mail]" 
  title=[e-mail]>[e-mail]</A> ; <A 
  href="mailto:[e-mail]" 
  title=[e-mail]>[e-mail]</A> ; <A 
  href="mailto:[e-mail]" 
  title=[e-mail]>[e-mail]</A> ; <A 
  href="mailto:WG-Authentication&amp;[e-mail]" 
  title=WG-Authentication&amp;[e-mail]>WG-Authentication&amp;[e-mail]</A> 
  ; <A href="mailto:[e-mail]" 
  title=[e-mail]>[e-mail]</A> </DIV>
  <DIV style="FONT: 10pt arial"><B>Sent:</B> Wednesday, July 07, 1999 10:32 
  PM</DIV>
  <DIV style="FONT: 10pt arial"><B>Subject:</B> RFC 2527 revision</DIV>
  <DIV><BR></DIV>
  <DIV><FONT size=2>
  <DIV><B><FONT size=3>
  <P>RFC 2527 (Certificate Policy and Certification Practices Framework) 
  Revision.</P></B></FONT><FONT size=2></FONT><FONT size=3>
  <P>The Internet Engineering Task Force (IETF) Request for Comments (RFC) 2527, 
  originally known as PKIX4 and also as "The Chokhani-Ford Framework" was 
  developed from two different projects funded by the U.S. and Canadian 
  governments. The IETF PKIX group iterated the draft for about a year, then was 
  approved as an informal RFC. The final version is dated April 1998 and the 
  formal RFC number was granted in March 1999.</P>
  <P>At some point, the original draft was used as a starting document by many 
  individuals and organizations developing Certificate Policies (CPs) and 
  Certification Practices Statements (CPSs) and began to be used in a number of 
  different forums. Feedback has indicated that the document in its present 
  state does not meet all the needs from the different communities it is 
  supposed to help. As a result of this feedback an effort to revise this 
  document coalesced. The broad acceptance and interest garnered by this work 
  from the business, legal, government, and technical communities motivated 
  widening the editorial group to include members of several interest groups. 
  The original authors of RFC 2527, S. Chokhani &#8211;CygnaCom- and W. Ford 
  &#8211;VeriSign- joined forces with J. Larimer &#8211;NACHA-, C. Merrill &#8211;ABA-, M. Power &#8211; 
  Gov. of Canada-, J. Rodriguez-Torrent &#8211;IBM- and R. Sabett &#8211;Spyrus- forming an 
  editorial group and initiating a formal revision of the RFC 2527 to make 
  changes to the General Provisions and Certificate Life-Cycle aspects of the 
  RFC.</P>
  <P>To bring forward to the IETF open process a revised draft of RFC 2527 
  promptly, while keeping the instructional value and the completeness of the 
  original work intact, the editorial group decided to obtain comments from the 
  various communities of interest. These comments, gathered in open meetings, 
  will be the first posting to the PKIX4 revision public mail list as it 
  initiates operations today. Individuals can bring forth comments and 
  requirements by joining this public mail list &#8211;see how to join below- or 
  sending a note to the chair of the editorial group (</FONT><A 
  href="mailto:[e-mail]"><FONT 
  size=2>[e-mail]</FONT></A><FONT size=3>). A coherent first draft 
  will be released shortly after the July meeting of the IETF in Oslo (Several 
  items pending at this late date).</P></FONT>
  <P><FONT size=3>To join the PKIX4 mailing list, send a request to <A 
  href="mailto:[e-mail]">[e-mail]</A> with 
  "subscribe pkix4" in the body of the message or to <A 
  href="mailto:[e-mail]">[e-mail]</A> 
  with only the word "subscribe" in the body of the message. In either case DO 
  NOT include the quotation marks on your request.</FONT></P>
  <P><FONT size=3>Thank you</FONT></P>
  <P><FONT size=3>The Editorial Group for the Revision of RFC 2527</FONT></P>
  <P><FONT size=3></FONT>&nbsp;</P>
  <P><FONT size=3>PS&nbsp; I'm behind schedule with the draft but the list is 
  open for business and I will start posting stuff (feedback collected from open 
  meetings) sometime today. </FONT><FONT size=3></FONT></P>
  <P><FONT size=3>JRT</FONT></P></FONT><FONT size=2><BR>Juan 
  Rodriguez-Torrent<BR><A 
  href="mailto:[e-mail]">[e-mail]</A></FONT></DIV></DIV>
  <DIV>&nbsp;</DIV>
  <DIV><FONT size=2>"It is better to sleep on things beforehand than lie awake 
  about them afterwards." Baltasar 
Gracian<BR></FONT></DIV></BLOCKQUOTE></BODY></HTML>


Received: from localhost (daemon@localhost) by mail.proper.com (8.8.8/8.8.5) with SMTP id KAA22023; Thu, 8 Jul 1999 10:10:42 -0700 (PDT)
Received: by mail.imc.org (bulk_mailer v1.12); Thu, 8 Jul 1999 10:10:39 -0700
Received: from aum (ip11.proper.com [165.227.249.11]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id KAA21999 for <[e-mail]>; Thu, 8 Jul 1999 10:10:36 -0700 (PDT)
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.56 (Beta)
Date: Thu, 08 Jul 1999 10:10:39 -0700
To: [e-mail]
From: Paul Hoffman / IMC <[e-mail]>
Subject: Re: Usage of TDTs
In-Reply-To: <00af01bec95f$080c9130$[e-mail]>
References: <000601bec49b$747b3880$2348ffd0@lattin> <[e-mail]> <v04020a01b3a9087882d1@[128.33.238.77]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Precedence: bulk
List-Archive: http://www.imc.org/ietf-pkix/mail-archive/
List-Unsubscribe: mailto:[e-mail]?body=unsubscribe
X-UIDL: 3dc998102063b88cfbe133deeb524eb2

At 09:29 AM 7/8/1999 -0700, [e-mail] wrote:
>You talk about Interoperability in your other responses to this commentary
>too and I am wondering where the interoperability is in the many protocols
>that you know have under your watchful care, Oh trustee of the Technology
>Farm Project...

Could we dispense with the name-calling? It does not help us come up with 
solutions.

If you are wondering "where the interoperability is", there are many 
sources of information. You can alk to the implementors. Bob Moskowitz 
recently posted a draft that covers testing of CMP interoperability. Peter 
Gutmann has posted many messages about interoperability (and severe lack 
thereof) in cert format. And so on.

>Again the reality is that we are still too early in the development and
>evolutionary curve of PKI to be forced to address the issues of
>interoperability.

I cannot disagree with you more strongly. It is *never* too soon to aim for 
interoperability. If immediate interoperability is not your goal, the IETF 
is probably not your venue. There are many other groups that discuss how to 
do PKI without much care for interoperability; you may be happier there. 
Or, you may realize that such groups aren't getting real work done and 
change your attitude about the importance of interoperability.

The PKIX WG is not the place to argue about whether the IETF should care 
about interoperability.

> > We don't develop implementation
> > specifications; we leave that to the implementors, so long as they achieve
> > the interoperability requirements of the protocols.  For example, the
> > security offered through the use of a protocol such as SSL, IPsec, or
> > S/MIME is heavily dependent on the quality of the implementation.
> > Moreover, when these protocols are implemented on top of an insecure OS,
>an
> > active attacker has a whole new set of opportunities to circumvent the
> > security offered by the protocols.  This is a valid concern, but it is
> > outside the scope of IETF standards.  (You can find informational RFCs on
> > operational and implementation security issues, but they are not
>standards.)
>
>
>Your responses above are based in a flurry of motion, much of which whould
>have been directed at POISSON Efforts.

I disagree here as well. Your followup messages haven't made it to the 
poised list (or to this one), so I can't speak of their content. But until 
the IETF makes a radical change in direction (and I sincerely doubt this 
will happen soon), quality of implementation work is pretty much out of 
scope. I say "pretty much" because sometimes there are changes that can be 
made to protocols that can make them less prone to mis-implementation, and 
sometimes there is good value to additional documents that give 
implementation advice. But those are generally side issues.

> > When you criticise the notion that a TSA can be relied upon by its clients
> > to provide accurate timestamps, and cite the insecurities of OSs, you have
> > stepped outside of the bounds of our WG charter, and of IETF standards in
> > general.
>
>So any criticism of the current Timestamping Draft is a criticism of the WG
>Charter? - Right.

That's not what he said: re-read your own quote. There is nothing in the WG 
charter that says anything about operating systems.

>The model you are so many others are working on is based in the Trusted
>Third Party Model entierly, and I personally think that this is not the type
>of Timestamping that Industry will mandate.

Then you should write a new Internet Draft with the different model in it. 
Start off with a set of requirements. Describe the current model and your 
model. Discuss how your model is different (not better than) the current 
model as you see it. If there is WG interest, your draft will be adopted. 
If you don't write the draft, then all we have to work from is some 
hard-to-read mail messages.

>If it was, then Surity and
>others would be rockin' on down to the bank to deposit their checks...

This is completely irrelevant. Microsoft rocks bigger when they go to their 
bank: are you saying that their model is better? What happens when two big 
companies with different models both rock to the bank? Do our heads 
explode? This is why the IETF doesn't care about these types of arguments.

> > However, as a matter of policy, I would not skew a protocol design based
>on
> > any technology that gives undue advantage to any given vendor, e.g., based
> > on use of a patented technology, dominant market position, etc.
>
>So, what your saying is that as the Chair, you personally will not allow for
>any hanky panky in the filing or promulgation of Drafts or their Concepts.

No, he's saying something that many of us will completely agree with: 
protocol design should not be skewed to an encumbered technology if there 
is a different, reasonably good unencumbered solution.

>BUT that the drafts you support must reflect non-proprietary efforts.
>Doesn't this violate the charter of the IETF.

No; if you think so, please point out specific wording in "the charter of 
the IETF" that this contradicts.

>  I seem to recall that I can
>submit proprietary efforts and you just said that you wouldn't SKEW the
>standards efforts to favor any of these.

Correct.

>  So what if there are no other
>solutions proposed?

Then it is up to the WG to decide whether or not to embrace the proposal in 
your Internet Draft.

>  - Steve what this sounds like to me is an invitation for
>a lawsuit with the IETF named as the Respondant.

Todd, do you think that making threats like this will make people want to 
adopt your proposals? Do you react positively when folks threaten you like 
this? I'd imagine not. The best way for you to get your ideas adopted is to 
write an Internet Draft, have it discussed on the list, and see if there is 
any interest.

--Paul Hoffman, Director
--Internet Mail Consortium



Received: from localhost (daemon@localhost) by mail.proper.com (8.8.8/8.8.5) with SMTP id JAA20739; Thu, 8 Jul 1999 09:30:29 -0700 (PDT)
Received: by mail.imc.org (bulk_mailer v1.12); Thu, 8 Jul 1999 09:30:27 -0700
Received: from www.meridianus.com (209.249.223.20.has.no.reverse [209.249.223.20] (may be forged)) by mail.proper.com (8.8.8/8.8.5) with ESMTP id JAA20713 for <[e-mail]>; Thu, 8 Jul 1999 09:30:26 -0700 (PDT)
Received: from pc1 by www.meridianus.com (8.8.8+Sun/SMI-SVR4) id KAA12846; Thu, 8 Jul 1999 10:24:57 -0700 (PDT)
Message-ID: <00af01bec95f$080c9130$[e-mail]>
From: "[e-mail]" <[e-mail]>
To: "[e-mail]" <[e-mail]>, "Stephen Kent" <[e-mail]>
Cc: "IETF PKIX" <[e-mail]>
References: <000601bec49b$747b3880$2348ffd0@lattin><[e-mail]> <v04020a01b3a9087882d1@[128.33.238.77]>
Subject: Re: Usage of TDTs
Date: Thu, 8 Jul 1999 09:29:20 -0700
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.00.2014.211
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2014.211
Precedence: bulk
List-Archive: http://www.imc.org/ietf-pkix/mail-archive/
List-Unsubscribe: mailto:[e-mail]?body=unsubscribe
X-UIDL: f748a23a02d31795ea21357514245c34

Steve I agonized over responding here to you or not.

----- Original Message -----
From: Stephen Kent <[e-mail]>
To: [e-mail] <[e-mail]>
Cc: <[e-mail]>
Sent: Wednesday, July 07, 1999 6:55 AM
Subject: Re: Usage of TDTs


> Todd & Bill,
>
> I think we are seeing some serious disagreements here, in part due to
> fundamentally different assumptions about implementations and the role of
> IETF WGs.
>
> This WG, like all others in the IETF, develops protocols as a means of
> specifying interoperability.

You talk about Interoperability in your other responses to this commentary
too and I am wondering where the interoperability is in the many protocols
that you know have under your watchful care, Oh trustee of the Technology
Farm Project...

Again the reality is that we are still too early in the development and
evolutionary curve of PKI to be forced to address the issues of
interoperability. I liken it to still being "in the Summer of Love" with
regard to the evolutioon and deployment of commercially usable PKI.

> We don't develop implementation
> specifications; we leave that to the implementors, so long as they achieve
> the interoperability requirements of the protocols.  For example, the
> security offered through the use of a protocol such as SSL, IPsec, or
> S/MIME is heavily dependent on the quality of the implementation.
> Moreover, when these protocols are implemented on top of an insecure OS,
an
> active attacker has a whole new set of opportunities to circumvent the
> security offered by the protocols.  This is a valid concern, but it is
> outside the scope of IETF standards.  (You can find informational RFCs on
> operational and implementation security issues, but they are not
standards.)


Your responses above are based in a flurry of motion, much of which whould
have been directed at POISSON Efforts.  The POISSON Responses will be sent
under separate cover and cross posted to the POISSON List, that I just
posted.

>
> When you criticise the notion that a TSA can be relied upon by its clients
> to provide accurate timestamps, and cite the insecurities of OSs, you have
> stepped outside of the bounds of our WG charter, and of IETF standards in
> general.

So any criticism of the current Timestamping Draft is a criticism of the WG
Charter? - Right. Or is it a criticism of the OS Model itself. What is it
that you are saying here, "This Criticism is outside the scope of this WG,
leave these people alone..." or what?

Come on Steve, the reaility is that the lines between the stack, the
communications processors, and the virtual services interfaces that are a
part of every commercial OS are blurring to the point of nondistinction. If
you have any doubt try to "rip" the stack out of Oh say, Solaris 2.6 or
better yet 2.7, and see what happens. Thin clients are even worse.

and as to Interoperating with a timestamp, does that happen at the routines
that create the stamp or at the data structure of the stamp itself? My vote
is at the TSToken or Data Structure of the Stamp itself.

> One could elect to implement a protocol supporting a TSA in a
> dedicated device that is immune to these criticisms.

The issue is not whether you need a device to insure theat the OS borne Time
Services are what they claim to be, but rather what and how the timestamping
model works.

The model you are so many others are working on is based in the Trusted
Third Party Model entierly, and I personally think that this is not the type
of Timestamping that Industry will mandate. If it was, then Surity and
others would be rockin' on down to the bank to deposit their checks...

What people want in timestamping is a locally valid mechanism of creating
and verifying  stamps. If they are to be issued remotely, then the said same
system needs a listener and a daemon or somesuch if you need the TTP
functionality, but to base the protocol onto the TTP model itself is silly
and short-sided, IMHO.

The world is likely to want a mechanism to establish as much credibility for
a Timestamping Solution as possible, and that means that the entire solution
needs to be able to live on a single platform, i.e. with the app that is
going to use it. It also means that the stamping model needs to be as
complete, that is  self-contained, as possible, but the stamps have to be
small enough to put into a DB without too much pain. Also that they can be
lightened further for the Warehouseing Operators becuase most of them are
choking at the concept of a 511 byte stamp like we produce with the
"neutral" version of BERT. So what is really going on here?

But there is more - the issues with the timestamping model are more
rudimentry than is being dealt with. It really seems to me that the
timestamping protocol as suggested so far is trying to do knock-offs of NTP
and OCSP and some other services that are really not it's responsibility
either.

What the time services protocols shoud do is very simple:

    1)    Allow for the credible and audited depolyment of timedata to the
host systems as part of the timestamping process. Also that the source and
credibility of the stamps and their timesource are documented.

    2)    Allow for local OS Borne Timestamps to be built and validated
sapecific to some structure standards, like BERT or whatever.

    3)    Allow for the verification of the timestamps and their ESP's
through some mechanism

    4)    Run the timestamping model in local or remote models.

    5)    Have at least one prototypical logging model for the use there of
of #2-4 above

    6)    Create a recommendation for using certified time.

> It is fair for us to
> consider, in the course of protocol design, when we may do to facilitate
> more secure implementation, without prescribing implementation details.

That's good, and this says that the security model is a part of the totality
of the system, here again demonstrating that the protocol is not the
protocol itself but a key piece of a larger systems that needs to be
considered as a system itself.

> However, as a matter of policy, I would not skew a protocol design based
on
> any technology that gives undue advantage to any given vendor, e.g., based
> on use of a patented technology, dominant market position, etc.

So, what your saying is that as the Chair, you personally will not allow for
any hanky panky in the filing or promulgation of Drafts or their Concepts.
BUT that the drafts you support must reflect non-proprietary efforts.
Doesn't this violate the charter of the IETF. I seem to recall that I can
submit proprietary efforts and you just said that you wouldn't SKEW the
standards efforts to favor any of these. So what if there are no other
solutions proposed? - Steve what this sounds like to me is an invitation for
a lawsuit with the IETF named as the Respondant. Personally I think that
this is somethign that the IETF needs to protect itself better against but I
will take that up with POISSON.

I will end this response here but I will address your other concerns in the
Letter to POISSED about the global changes in the WG Chairs Responsibilities
as Trustee's Guarding the Technology Grist Mill.

These responses are my own personal issues -Standard Disclaimer, etc etc
etc, my company has already disavowed me anyway...

Todd Glassey






Received: from localhost (daemon@localhost) by mail.proper.com (8.8.8/8.8.5) with SMTP id JAA20936; Thu, 8 Jul 1999 09:35:35 -0700 (PDT)
Received: by mail.imc.org (bulk_mailer v1.12); Thu, 8 Jul 1999 09:35:34 -0700
Received: from www.meridianus.com (209.249.223.20.has.no.reverse [209.249.223.20] (may be forged)) by mail.proper.com (8.8.8/8.8.5) with ESMTP id JAA20914 for <[e-mail]>; Thu, 8 Jul 1999 09:35:34 -0700 (PDT)
Received: from pc1 by www.meridianus.com (8.8.8+Sun/SMI-SVR4) id KAA12860; Thu, 8 Jul 1999 10:31:07 -0700 (PDT)
Message-ID: <00cc01bec95f$e75e8500$[e-mail]>
From: "[e-mail]" <[e-mail]>
To: "Warwick Ford" <[e-mail]>, <[e-mail]>, "Paul Hoffman / VPNC" <[e-mail]>
References: <[e-mail]>
Subject: Re: PKIX Agenda for Oslo
Date: Thu, 8 Jul 1999 09:35:30 -0700
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.00.2014.211
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2014.211
Precedence: bulk
List-Archive: http://www.imc.org/ietf-pkix/mail-archive/
List-Unsubscribe: mailto:[e-mail]?body=unsubscribe
X-UIDL: 7187331214d9c7d9c95bb0fe8e3ef556

This is a good topic for Oslo to address and is part in parcel to how the
IETF plans to maintain the value of the Intellectual Properties it produces.
Also how it plans to promulgate these to other standard orgs and who's
responsibility to do this, it is.


As to the Road Map discussion I want to add the idea that a Recommended M.O.
be added for each protocol taken beyond RFC by PKIX and that this M.O. be
promulgated formally to other orgs as our working recommendations on the
"subject".


See the lenghtily note I hammed the POISSED LIST with this AM for the
further references to what needs to be addressed as part of the RoadMap
Effort. BTW, I would be willing ot work on this project as well if the
Roadmap Authors would have me.

T
----- Original Message -----
From: Paul Hoffman / VPNC <[e-mail]>
To: Warwick Ford <[e-mail]>; <[e-mail]>
Sent: Wednesday, July 07, 1999 5:31 PM
Subject: Re: PKIX Agenda for Oslo


>
> >Here is the draft agenda for the Oslo PKIX WG meeting.  Please advise any
> >additions...
>
> You may want to address the recent discussion of "why so many protocols".
I
> think that it is a reasonable question and should be discussed before the
> many protocols it might replace. I propose that such a discussion happen
> before or after the Roadmap discussion. The outcome of such a discussion
> could affect at least three of the other discussions.
>
> --Paul Hoffman, Director
> --VPN Consortium
>




Received: from localhost (daemon@localhost) by mail.proper.com (8.8.8/8.8.5) with SMTP id JAA20248; Thu, 8 Jul 1999 09:09:58 -0700 (PDT)
Received: by mail.imc.org (bulk_mailer v1.12); Thu, 8 Jul 1999 09:08:57 -0700
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 JAA20171 for <[e-mail]>; Thu, 8 Jul 1999 09:08:55 -0700 (PDT)
Received: from bull.net (frcls6118.frcl.bull.fr [129.182.109.213]) by clbull.frcl.bull.fr (8.9.1a/8.9.1) with ESMTP id SAA10754; Thu, 8 Jul 1999 18:03:43 +0200
Message-ID: <[e-mail]>
Date: Thu, 08 Jul 1999 18:07:49 +0200
From: Denis Pinkas <[e-mail]>
Organization: Bull
X-Mailer: Mozilla 4.06 [fr] (Win95; I)
MIME-Version: 1.0
To: Michael Duren <[e-mail]>
CC: Stephen Kent <[e-mail]>, [e-mail]
Subject: Re: Usage of TDTs
References: <003c01bec94d$e38595c0$1a45fcd0@desktop>
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 8bit
Content-Transfer-Encoding: 8bit
Precedence: bulk
List-Archive: http://www.imc.org/ietf-pkix/mail-archive/
List-Unsubscribe: mailto:[e-mail]?body=unsubscribe
X-UIDL: 8a44ded2a8413e2ee7408d05bfcbe9eb

Michael,

The final question placed at the end of your E-mail is the following:

" Does it make sense to remove the optional TDT from the timestamp standard? "

I do not think this is the right question. The question should be instead:

"For what reasons should we maintain the optional TDT from the timestamp
standard? "

I am not convinced that the use you describe can only be supported by TDTs.

Detailed comments are embedded in your E-mail.


> Stephen,
>
> I understand your point regarding the scope of the IETF WGs.  However, it
> seems as though you are selective in the issues that you choose to address.
> Perhaps it is time to reset the debate regarding the TDT.
>
> As far as the standard is concerned, the TDT is an optional field that was
> originally put into the specification to provide additional justification of
> a TSA's time in the form of signed, temporal information.  Unfortunately, it
> seems as though the examples that were given in the specification were not
> well thought out.
>
> Members of the group were quick to point out that temporal information such
> as “stock quotes” does not add additional credibility to a Timestamp.  The
> group has since been debating as to whether or not the optional TDT should
> remain in the specification.
>
> In the meantime, Bill Latin has introduced a usage for the TDT that has both
> commercial application and can enhance the timestamp protocol's trust model.
> Bill's idea of using the TDT to provide NTA traceable time is an excellent
> example of how to use the TDT. He has simply asked the group to keep the TDT
> in the specification.
>
> I can certainly stop here and argue: the optional TDT was in the original
> specification - someone found a use for the optional TDT - and now that same
> someone has to argue to keep the optional TDT in the specification.  I don't
> get it.
>
> Perhaps Bill's idea can add new dimension to the fundamental idea of the
> TDT.  In regards to a timestamp, we must ask, how do you know the value of
> time in the Timestamp is valid?  And, how do you prove this validity to
> someone else?  Those are fundamental questions about timestamping that
> should be effectively addressed by this standards body and by this
> specification.  The only answer that I have heard so far regarding trust in
> time is that everyone must trust in policy.  The client must trust in a
> policy, and anyone that is to believe the validity of a timestamp, must also
> trust the same policy.  Trust in policy may be fine for many users, but I
> suggest we can do better.

As you say, this is fine for most users. I do not see the necessity to do
better.


> It has already been suggested that a TSA might deploy some sort of audit
> procedures to maintain valid time.  Certainly, a trustworthy TSA will deploy
> redundant mechanisms for maintaining time accuracy.  TSA's could use GPS,
> specialized hardware, redundancy, NTP synchronization, auditing, and perhaps
> some new, innovative technology or application.  But how does the use of
> those mechanisms, and how does trust in policy allow a client that has a
> timestamp to prove to someone else that the actual time in the stamp is
> valid.  There is nothing in the TST to prove that a TSA's clock was
> accurate.  There is no evidence in the timestamp that suggests a TSA's
> audits have been successful or that procedures to maintain a TSA's clock
> have been properly followed.

The TSA claims that it is accurate up to a precision that may be good *or bad*.
We now have such a field that can express a *variable* accuracy of the time.

If someone does not trust a TSA it should not use it. In some cases, for example
when building a contract, A trusts one TSA but B trusts another one. The
solution is very simple: use two time stamps instead of one. The contract will
only be valid, if it bears the two time stamps. Two is not enough ? Use three .


> Latin's suggestion to put NTA traceable time in the TDT adds a new dimension
> to the TDT trust model.  Placing this trusted time in the TDT allows
> multiple, signed time testimonies that could reasonably come from more that
> one NTA.  Placing this trusted time in the TDT allows a separation of roles
> and responsibilities so that trust in time is not dependent on one signature
> or on a policy.  Placing this trusted time in the TDT allows clients to
> instantly recognize and authenticate information that links the timestamp to
> a NTA.

The verifiation of such Time Stamps would be much longer and complicated.

> In addition, the TST that contains multiple, signed testimonies of time can
> be much more trustworthy than the TST with one signed testimony of time.
> Corroboration of time from multiple, independent authorities is very
> difficult to dispute and can be achieved through the TDA.
>
> In a real life criminal case, it is much easier to prove that someone was
> “at a certain place at a certain time” if you have multiple eye witnesses
> than can attest to a person's location.

Hence the solution is very simple: "use multiple eyes" means "use multiple time
stamps" - NOT a single time stamp that bears different proofs in it. This is
much simpler to implement

Regards,

Denis


> Why, then, build a timestamping
> system that limits the number of “electronic witnesses” to one?  The first
> question that my defense attorney will ask is "how can you prove that the
> time was valid on the TSA's clock? Policy? Audit? How many people verified
> the clock?  How often was the clock verified?  Can you prove the
> verification?"
>
> With that said, the question for the group is not about implementation
> details, or about undue marketplace advantages, or about complexity, or
> about -what if this and what if that-, the question for the group is simply
> this: Does it make sense to remove the optional TDT from the timestamp
> standard?
>
>  Sincerely,
>
> Mike Duren
>
> -----Original Message-----
> From: Stephen Kent <[e-mail]>
> To: [e-mail] <[e-mail]>
> Cc: [e-mail] <[e-mail]>
> Date: Wednesday, July 07, 1999 6:04 PM
> Subject: Re: Usage of TDTs
>
> >Todd & Bill,
> >
> >I think we are seeing some serious disagreements here, in part due to
> >fundamentally different assumptions about implementations and the role of
> >IETF WGs.
> >
> >This WG, like all others in the IETF, develops protocols as a means of
> >specifying interoperability.  We don't develop implementation
> >specifications; we leave that to the implementors, so long as they achieve
> >the interoperability requirements of the protocols.  For example, the
> >security offered through the use of a protocol such as SSL, IPsec, or
> >S/MIME is heavily dependent on the quality of the implementation.
> >Moreover, when these protocols are implemented on top of an insecure OS, an
> >active attacker has a whole new set of opportunities to circumvent the
> >security offered by the protocols.  This is a valid concern, but it is
> >outside the scope of IETF standards.  (You can find informational RFCs on
> >operational and implementation security issues, but they are not
> standards.)
> >
> >When you criticise the notion that a TSA can be relied upon by its clients
> >to provide accurate timestamps, and cite the insecurities of OSs, you have
> >stepped outside of the bounds of our WG charter, and of IETF standards in
> >general.  One could elect to implement a protocol supporting a TSA in a
> >dedicated device that is immune to these criticisms.  It is fair for us to
> >consider, in the course of protocol design, when we may do to facilitate
> >more secure implementation, without prescribing implementation details.
> >However, as a matter of policy, I would not skew a protocol design based on
> >any technology that gives undue advantage to any given vendor, e.g., based
> >on use of a patented technology, dominant market position, etc.
> >
> >Steve
> >



Received: from localhost (daemon@localhost) by mail.proper.com (8.8.8/8.8.5) with SMTP id HAA18973; Thu, 8 Jul 1999 07:34:11 -0700 (PDT)
Received: by mail.imc.org (bulk_mailer v1.12); Thu, 8 Jul 1999 07:33:56 -0700
Received: from smtp2.gte.net (smtp2.gte.net [207.115.153.31]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id HAA18949 for <[e-mail]>; Thu, 8 Jul 1999 07:33:56 -0700 (PDT)
Received: from desktop (1Cust26.tnt4.clearwater.fl.da.uu.net [208.252.69.26]) by smtp2.gte.net  with SMTP ; id JAA10225 Thu, 8 Jul 1999 09:32:48 -0500 (CDT)
Message-ID: <003c01bec94d$e38595c0$1a45fcd0@desktop>
Reply-To: "Michael Duren" <[e-mail]>
From: "Michael Duren" <[e-mail]>
To: "Stephen Kent" <[e-mail]>
Cc: <[e-mail]>
Subject: Re: Usage of TDTs
Date: Thu, 8 Jul 1999 10:25:46 -0400
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.1
X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3
Precedence: bulk
List-Archive: http://www.imc.org/ietf-pkix/mail-archive/
List-Unsubscribe: mailto:[e-mail]?body=unsubscribe
X-UIDL: 51b3da34c7653f0f095eefef2dd74ee7

Stephen,

I understand your point regarding the scope of the IETF WGs.  However, it
seems as though you are selective in the issues that you choose to address.
Perhaps it is time to reset the debate regarding the TDT.

As far as the standard is concerned, the TDT is an optional field that was
originally put into the specification to provide additional justification of
a TSA's time in the form of signed, temporal information.  Unfortunately, it
seems as though the examples that were given in the specification were not
well thought out.

Members of the group were quick to point out that temporal information such
as “stock quotes” does not add additional credibility to a Timestamp.  The
group has since been debating as to whether or not the optional TDT should
remain in the specification.

In the meantime, Bill Latin has introduced a usage for the TDT that has both
commercial application and can enhance the timestamp protocol's trust model.
Bill's idea of using the TDT to provide NTA traceable time is an excellent
example of how to use the TDT. He has simply asked the group to keep the TDT
in the specification.

I can certainly stop here and argue: the optional TDT was in the original
specification - someone found a use for the optional TDT - and now that same
someone has to argue to keep the optional TDT in the specification.  I don't
get it.

Perhaps Bill's idea can add new dimension to the fundamental idea of the
TDT.  In regards to a timestamp, we must ask, how do you know the value of
time in the Timestamp is valid?  And, how do you prove this validity to
someone else?  Those are fundamental questions about timestamping that
should be effectively addressed by this standards body and by this
specification.  The only answer that I have heard so far regarding trust in
time is that everyone must trust in policy.  The client must trust in a
policy, and anyone that is to believe the validity of a timestamp, must also
trust the same policy.  Trust in policy may be fine for many users, but I
suggest we can do better.

It has already been suggested that a TSA might deploy some sort of audit
procedures to maintain valid time.  Certainly, a trustworthy TSA will deploy
redundant mechanisms for maintaining time accuracy.  TSA's could use GPS,
specialized hardware, redundancy, NTP synchronization, auditing, and perhaps
some new, innovative technology or application.  But how does the use of
those mechanisms, and how does trust in policy allow a client that has a
timestamp to prove to someone else that the actual time in the stamp is
valid.  There is nothing in the TST to prove that a TSA's clock was
accurate.  There is no evidence in the timestamp that suggests a TSA's
audits have been successful or that procedures to maintain a TSA's clock
have been properly followed.

Latin's suggestion to put NTA traceable time in the TDT adds a new dimension
to the TDT trust model.  Placing this trusted time in the TDT allows
multiple, signed time testimonies that could reasonably come from more that
one NTA.  Placing this trusted time in the TDT allows a separation of roles
and responsibilities so that trust in time is not dependent on one signature
or on a policy.  Placing this trusted time in the TDT allows clients to
instantly recognize and authenticate information that links the timestamp to
a NTA.

In addition, the TST that contains multiple, signed testimonies of time can
be much more trustworthy than the TST with one signed testimony of time.
Corroboration of time from multiple, independent authorities is very
difficult to dispute and can be achieved through the TDA.

In a real life criminal case, it is much easier to prove that someone was
“at a certain place at a certain time” if you have multiple eye witnesses
than can attest to a person's location.  Why, then, build a timestamping
system that limits the number of “electronic witnesses” to one?  The first
question that my defense attorney will ask is "how can you prove that the
time was valid on the TSA's clock? Policy? Audit? How many people verified
the clock?  How often was the clock verified?  Can you prove the
verification?"

With that said, the question for the group is not about implementation
details, or about undue marketplace advantages, or about complexity, or
about -what if this and what if that-, the question for the group is simply
this: Does it make sense to remove the optional TDT from the timestamp
standard?

 Sincerely,

Mike Duren

-----Original Message-----
From: Stephen Kent <[e-mail]>
To: [e-mail] <[e-mail]>
Cc: [e-mail] <[e-mail]>
Date: Wednesday, July 07, 1999 6:04 PM
Subject: Re: Usage of TDTs


>Todd & Bill,
>
>I think we are seeing some serious disagreements here, in part due to
>fundamentally different assumptions about implementations and the role of
>IETF WGs.
>
>This WG, like all others in the IETF, develops protocols as a means of
>specifying interoperability.  We don't develop implementation
>specifications; we leave that to the implementors, so long as they achieve
>the interoperability requirements of the protocols.  For example, the
>security offered through the use of a protocol such as SSL, IPsec, or
>S/MIME is heavily dependent on the quality of the implementation.
>Moreover, when these protocols are implemented on top of an insecure OS, an
>active attacker has a whole new set of opportunities to circumvent the
>security offered by the protocols.  This is a valid concern, but it is
>outside the scope of IETF standards.  (You can find informational RFCs on
>operational and implementation security issues, but they are not
standards.)
>
>When you criticise the notion that a TSA can be relied upon by its clients
>to provide accurate timestamps, and cite the insecurities of OSs, you have
>stepped outside of the bounds of our WG charter, and of IETF standards in
>general.  One could elect to implement a protocol supporting a TSA in a
>dedicated device that is immune to these criticisms.  It is fair for us to
>consider, in the course of protocol design, when we may do to facilitate
>more secure implementation, without prescribing implementation details.
>However, as a matter of policy, I would not skew a protocol design based on
>any technology that gives undue advantage to any given vendor, e.g., based
>on use of a patented technology, dominant market position, etc.
>
>Steve
>



Received: from localhost (daemon@localhost) by mail.proper.com (8.8.8/8.8.5) with SMTP id WAA28758; Wed, 7 Jul 1999 22:30:39 -0700 (PDT)
Received: by mail.imc.org (bulk_mailer v1.12); Wed, 7 Jul 1999 22:30:28 -0700
Received: from harrier.prod.itd.earthlink.net (harrier.prod.itd.earthlink.net [207.217.121.12]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id WAA28734 for <[e-mail]>; Wed, 7 Jul 1999 22:30:28 -0700 (PDT)
Received: from cbljrtorrent (CBL-jrtorrent.hs.earthlink.net [208.233.117.109]) by harrier.prod.itd.earthlink.net (8.9.3/8.9.3) with SMTP id WAA22733; Wed, 7 Jul 1999 22:31:05 -0700 (PDT)
Message-ID: <00a801bec903$4c260ec0$[e-mail]>
Reply-To: "Juan Rodriguez-Torrent" <[e-mail]>
From: "Juan Rodriguez-Torrent" <[e-mail]>
To: <[e-mail]>, <[e-mail]>, <[e-mail]>, <[e-mail]>, <[e-mail]>, <[e-mail]>, <WG-Authentication&[e-mail]>, <[e-mail]>
Subject: RFC 2527 revision
Date: Thu, 8 Jul 1999 01:32:38 -0400
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="----=_NextPart_000_00A4_01BEC8E1.C39A03C0"
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.00.2014.211
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2014.211
Precedence: bulk
List-Archive: http://www.imc.org/ietf-pkix/mail-archive/
List-Unsubscribe: mailto:[e-mail]?body=unsubscribe
X-UIDL: 4793f0b6a81a3b426c957f39a41f7a3b

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META content="text/html; charset=iso-8859-1" http-equiv=Content-Type>
<META content="MSHTML 5.00.2614.3401" name=GENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=#ffffff>
<DIV><FONT size=2>
<DIV><B><FONT size=3>
<P>RFC 2527 (Certificate Policy and Certification Practices Framework) 
Revision.</P></B></FONT><FONT size=2></FONT><FONT size=3>
<P>The Internet Engineering Task Force (IETF) Request for Comments (RFC) 2527, 
originally known as PKIX4 and also as "The Chokhani-Ford Framework" was 
developed from two different projects funded by the U.S. and Canadian 
governments. The IETF PKIX group iterated the draft for about a year, then was 
approved as an informal RFC. The final version is dated April 1998 and the 
formal RFC number was granted in March 1999.</P>
<P>At some point, the original draft was used as a starting document by many 
individuals and organizations developing Certificate Policies (CPs) and 
Certification Practices Statements (CPSs) and began to be used in a number of 
different forums. Feedback has indicated that the document in its present state 
does not meet all the needs from the different communities it is supposed to 
help. As a result of this feedback an effort to revise this document coalesced. 
The broad acceptance and interest garnered by this work from the business, 
legal, government, and technical communities motivated widening the editorial 
group to include members of several interest groups. The original authors of RFC 
2527, S. Chokhani &#8211;CygnaCom- and W. Ford &#8211;VeriSign- joined forces with J. 
Larimer &#8211;NACHA-, C. Merrill &#8211;ABA-, M. Power &#8211; Gov. of Canada-, J. 
Rodriguez-Torrent &#8211;IBM- and R. Sabett &#8211;Spyrus- forming an editorial group and 
initiating a formal revision of the RFC 2527 to make changes to the General 
Provisions and Certificate Life-Cycle aspects of the RFC.</P>
<P>To bring forward to the IETF open process a revised draft of RFC 2527 
promptly, while keeping the instructional value and the completeness of the 
original work intact, the editorial group decided to obtain comments from the 
various communities of interest. These comments, gathered in open meetings, will 
be the first posting to the PKIX4 revision public mail list as it initiates 
operations today. Individuals can bring forth comments and requirements by 
joining this public mail list &#8211;see how to join below- or sending a note to the 
chair of the editorial group (</FONT><A href="mailto:[e-mail]"><FONT 
size=2>[e-mail]</FONT></A><FONT size=3>). A coherent first draft will 
be released shortly after the July meeting of the IETF in Oslo (Several items 
pending at this late date).</P></FONT>
<P><FONT size=3>To join the PKIX4 mailing list, send a request to <A 
href="mailto:[e-mail]">[e-mail]</A> with 
"subscribe pkix4" in the body of the message or to <A 
href="mailto:[e-mail]">[e-mail]</A> 
with only the word "subscribe" in the body of the message. In either case DO NOT 
include the quotation marks on your request.</FONT></P>
<P><FONT size=3>Thank you</FONT></P>
<P><FONT size=3>The Editorial Group for the Revision of RFC 2527</FONT></P>
<P><FONT size=3></FONT>&nbsp;</P>
<P><FONT size=3>PS&nbsp; I'm behind schedule with the draft but the list is open 
for business and I will start posting stuff (feedback collected from open 
meetings) sometime today. </FONT><FONT size=3></FONT></P>
<P><FONT size=3>JRT</FONT></P></FONT><FONT size=2><BR>Juan 
Rodriguez-Torrent<BR><A 
href="mailto:[e-mail]">[e-mail]</A></FONT></DIV></DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT size=2>"It is better to sleep on things beforehand than lie awake 
about them afterwards." Baltasar Gracian<BR></FONT></DIV></BODY></HTML>


Attachment Converted: "C:\Temp\Juan Rodriguez-Torrent1.vcf"
>From ???@??? Thu Jul 08 07:44:31 1999
Received: from localhost (daemon@localhost)
	by mail.proper.com (8.8.8/8.8.5) with SMTP id XAA03171;
	Wed, 7 Jul 1999 23:45:13 -0700 (PDT)
Received: by mail.imc.org (bulk_mailer v1.12); Wed, 7 Jul 1999 23:45:06 -0700
Received: from fw1b.telekom.de (gw1.telekom.de [194.25.15.11])
	by mail.proper.com (8.8.8/8.8.5) with SMTP id XAA03146
	for <[e-mail]>; Wed, 7 Jul 1999 23:45:05 -0700 (PDT)
Received: by fw1b.telekom.de; (5.65v4.0/1.3/10May95) id AA10232; Thu, 8 Jul 1999 08:45:43 +0200
Received: from Q8P65.blf01.telekom.de by U8PW4.blf01.telekom.de with ESMTP for [e-mail]; Thu, 8 Jul 1999 08:45:53 +0200
Received: from u8p11.blf01.telekom.de by q8p65.blf01.telekom.de with ESMTP for [e-mail]; Thu, 8 Jul 1999 08:45:12 +0200
Received: by U8P11.blf01.telekom.de with Internet Mail Service (5.5.2448.0)
	id <28QB471H>; Thu, 8 Jul 1999 08:52:42 +0200
Message-Id: <056BFE552B14D311BD8A0800060D98EC229090@u8p13>
From: "Trenker, Stefan" <[e-mail]>
To: "'[e-mail]'" <[e-mail]>
Subject: subscribe
Date: Thu, 8 Jul 1999 08:42:05 +0200 
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 XAA03148
Precedence: bulk
List-Archive: http://www.imc.org/ietf-pkix/mail-archive/
List-Unsubscribe: mailto:[e-mail]?body=unsubscribe
X-UIDL: 2d87ef6418c48e8e4553906c27d2ffa8

subscribe

Stefan Trenker
IT-Directory Services and 
IT-Security Management Systems

DeTeCSM GmbH
NL TBS Darmstadt
Palaswiesenstraße 182
D-64214 Darmstadt

Tel.: [phone] - 6115
Fax: [phone] - 652
mailto:[e-mail]



Received: from localhost (daemon@localhost) by mail.proper.com (8.8.8/8.8.5) with SMTP id RAA00196; Wed, 7 Jul 1999 17:30:49 -0700 (PDT)
Received: by mail.imc.org (bulk_mailer v1.12); Wed, 7 Jul 1999 17:30:42 -0700
Received: from mail.vpnc.org (mail.vpnc.org [165.227.249.9]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id RAA00162 for <[e-mail]>; Wed, 7 Jul 1999 17:30:41 -0700 (PDT)
Received: from aum (ip11.proper.com [165.227.249.11]) by mail.vpnc.org (8.9.3/8.9.0) with ESMTP id RAA08714; Wed, 7 Jul 1999 17:30:33 -0700 (PDT)
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.56 (Beta)
Date: Wed, 07 Jul 1999 17:31:09 -0700
To: Warwick Ford <[e-mail]>, "'[e-mail]'" <[e-mail]>
From: Paul Hoffman / VPNC <[e-mail]>
Subject: Re: PKIX Agenda for Oslo
In-Reply-To: <[e-mail] >
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Precedence: bulk
List-Archive: http://www.imc.org/ietf-pkix/mail-archive/
List-Unsubscribe: mailto:[e-mail]?body=unsubscribe
X-UIDL: de7ce73166560b3ccf689cb35c5738a9
Status: O
X-Status:

>Here is the draft agenda for the Oslo PKIX WG meeting.  Please advise any
>additions...

You may want to address the recent discussion of "why so many protocols". I 
think that it is a reasonable question and should be discussed before the 
many protocols it might replace. I propose that such a discussion happen 
before or after the Roadmap discussion. The outcome of such a discussion 
could affect at least three of the other discussions.

--Paul Hoffman, Director
--VPN Consortium



Received: from localhost (daemon@localhost) by mail.proper.com (8.8.8/8.8.5) with SMTP id PAA27777; Wed, 7 Jul 1999 15:02:14 -0700 (PDT)
Received: by mail.imc.org (bulk_mailer v1.12); Wed, 7 Jul 1999 15:02:13 -0700
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 PAA27755 for <[e-mail]>; Wed, 7 Jul 1999 15:02:12 -0700 (PDT)
Received: from [128.33.238.130] (TC130.BBN.COM [128.33.238.130]) by po1.bbn.com (8.9.1/8.9.1) with ESMTP id SAA24197; Wed, 7 Jul 1999 18:02:50 -0400 (EDT)
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
X-Sender: [e-mail] (Unverified)
Message-Id: <v04020a01b3a9087882d1@[128.33.238.77]>
In-Reply-To: <05fa01bec4bc$de7025e0$[e-mail]>
References: <000601bec49b$747b3880$2348ffd0@lattin> <[e-mail]>
Date: Wed, 7 Jul 1999 09:55:14 -0400
To: "[e-mail]" <[e-mail]>
From: Stephen Kent <[e-mail]>
Subject: Re: Usage of TDTs
Cc: <[e-mail]>
Precedence: bulk
List-Archive: http://www.imc.org/ietf-pkix/mail-archive/
List-Unsubscribe: mailto:[e-mail]?body=unsubscribe
X-UIDL: a3a910db90d1dbe16850d206c45f846c

Todd & Bill,

I think we are seeing some serious disagreements here, in part due to
fundamentally different assumptions about implementations and the role of
IETF WGs.

This WG, like all others in the IETF, develops protocols as a means of
specifying interoperability.  We don't develop implementation
specifications; we leave that to the implementors, so long as they achieve
the interoperability requirements of the protocols.  For example, the
security offered through the use of a protocol such as SSL, IPsec, or
S/MIME is heavily dependent on the quality of the implementation.
Moreover, when these protocols are implemented on top of an insecure OS, an
active attacker has a whole new set of opportunities to circumvent the
security offered by the protocols.  This is a valid concern, but it is
outside the scope of IETF standards.  (You can find informational RFCs on
operational and implementation security issues, but they are not standards.)

When you criticise the notion that a TSA can be relied upon by its clients
to provide accurate timestamps, and cite the insecurities of OSs, you have
stepped outside of the bounds of our WG charter, and of IETF standards in
general.  One could elect to implement a protocol supporting a TSA in a
dedicated device that is immune to these criticisms.  It is fair for us to
consider, in the course of protocol design, when we may do to facilitate
more secure implementation, without prescribing implementation details.
However, as a matter of policy, I would not skew a protocol design based on
any technology that gives undue advantage to any given vendor, e.g., based
on use of a patented technology, dominant market position, etc.

Steve


Received: from localhost (daemon@localhost) by mail.proper.com (8.8.8/8.8.5) with SMTP id PAA27842; Wed, 7 Jul 1999 15:02:23 -0700 (PDT)
Received: by mail.imc.org (bulk_mailer v1.12); Wed, 7 Jul 1999 15:02:22 -0700
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 PAA27799 for <[e-mail]>; Wed, 7 Jul 1999 15:02:21 -0700 (PDT)
Received: from [128.33.238.130] (TC130.BBN.COM [128.33.238.130]) by po1.bbn.com (8.9.1/8.9.1) with ESMTP id SAA24203; Wed, 7 Jul 1999 18:02:55 -0400 (EDT)
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
X-Sender: [e-mail] (Unverified)
Message-Id: <v04020a04b3a910655f5a@[128.33.238.77]>
In-Reply-To: <[e-mail]>
References: <007901bec496$745a8360$[e-mail]> <[e-mail]>
Date: Wed, 7 Jul 1999 10:16:58 -0400
To: Tony Bartoletti <[e-mail]>
From: Stephen Kent <[e-mail]>
Subject: RE: I-D ACTION:draft-ietf-pkix-scvp-00.txt
Cc: [e-mail]
Precedence: bulk
List-Archive: http://www.imc.org/ietf-pkix/mail-archive/
List-Unsubscribe: mailto:[e-mail]?body=unsubscribe
X-UIDL: ae929e3ee0701a0d64f0c45cd958f412

While it would be nice if the complexity of implementing an Internet
standard was always so well bounded, this is not the case.  As counter
examples I propose the following, assuming that a target implementation is
complete and robust:

	- MIME
	- BGP4
	- IKE
	- RFC 822

I claim these all require more effort, based on a mix of personal
experience and observations of how long it takes before we see good
implementations of these protocols deployed.

Steve


Received: from localhost (daemon@localhost) by mail.proper.com (8.8.8/8.8.5) with SMTP id PAA27865; Wed, 7 Jul 1999 15:02:24 -0700 (PDT)
Received: by mail.imc.org (bulk_mailer v1.12); Wed, 7 Jul 1999 15:02:23 -0700
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 PAA27820 for <[e-mail]>; Wed, 7 Jul 1999 15:02:22 -0700 (PDT)
Received: from [128.33.238.130] (TC130.BBN.COM [128.33.238.130]) by po1.bbn.com (8.9.1/8.9.1) with ESMTP id SAA24225; Wed, 7 Jul 1999 18:03:00 -0400 (EDT)
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
X-Sender: [e-mail] (Unverified)
Message-Id: <v04020a07b3a91339096e@[128.33.238.77]>
In-Reply-To: <04ee01bec7c5$f9c11d20$[e-mail]>
References:  <[e-mail]> <[e-mail]>
Date: Wed, 7 Jul 1999 13:55:11 -0400
To: "[e-mail]" <[e-mail]>
From: Stephen Kent <[e-mail]>
Subject: Re: NEED A BETTER PKI use ROADMAP - was Re: Initial comments on SCVP
Cc: "IETF PKIX" <[e-mail]>
Precedence: bulk
List-Archive: http://www.imc.org/ietf-pkix/mail-archive/
List-Unsubscribe: mailto:[e-mail]?body=unsubscribe
X-UIDL: 7f21f5dcc4bfca8b898e0e21f8732782

Todd,

I'll skip the ad hominim parts of your message, and focus on your 6 questions:

>So then this new updated ROADMAP plan needs to address
>
>    1)     What we are trying to do - What are the goals of the effort and
>the subsystem efforts, in no uncertain terms

The function of the WG is to develop protocols and data formats for use of
X.509 certificates and CRLs in the Internet environment.  PKIX does not
address all possible standards activities that are PKI and Internet
related.  Rather, we focus on that which we consider to be generally
applicable, leaving application-specific PKI standards to relevant
application (security) WGs.

>    2)    The Scope of the efforts and responsibilities of the
>players/protocols

Protocols, not being people, are not responsible :-).  Scope was addressed
above.

>    3)    What types of systems and transaction processing infrastructure
>that we need to put in place and WHY!

Transaction processing infrastructure?  We are providing generic,
X.509-based public key infrastructure standards.  There will probably be
many PKIs in practice and our goal is to provide standards that will serve
as a suitable basis for most of these. Your question seems to suggest a
more narrow focus.  The certs covered by PKIX standards may be used to
support authentication, authorization, and non-repudiation. Not all
PKIX-compliant applications will use all of these capabilities of certs and
thus no single instance of a PKI will be appropriate for all.

>    4)    What other standards agencies we are making alliances with and who
>from the WG is the representative to handle the relationship

We try to work closely with the ITU X.500 committee, since much of our work
has been profiling base standards produced by that committee.  We have
informal relationships, via shared membership, with the ANSI X.9 folks.
Several members of the WG act as liasions to other WGs, as reflected in
their contributions and or by their role in the other WGs.  This is not a
formalized relationship. For example, I act as a liasion to IPsec, Russ and
Paul work in S/MIME, Sharron for LDAP, ...

>    5)    What the goals and deliverables for our standards are, that is
>what Standards these efforts are built to address.

See answer to #1 above.

>    6)    Regular reports on the a) Status of the management efforts, b)
>relations to other efforts within the Group and their state, and c)
>cooperative (cross standards group) efforts.

Status reports are distributed via the mailing list. Because of the
informal nature of the liasion realtioships with other groups, these
reports are generated in response to relevant events in the other WGs.
Since our focus is on generic PKI standards, not all PKI activities in
other groups will be of interest to all PKIX members, and thus folks are
encouraged to sign up for mailing lists that match their interests.


>BTW, my feeling  is that with everything that is going on today, that PKI
>may need to be split into a number of other WG's to support this since
>mindset the PKI roadmap is getting too large for one group to handle without
>some additional structure.

As noted above, application-specific PKI standards are, by our charter, to
be farmed out to relevant application WGs.  That is happening in S/MIME,
TLS, and IPsec.

Steve


Received: from localhost (daemon@localhost) by mail.proper.com (8.8.8/8.8.5) with SMTP id QAA28984; Wed, 7 Jul 1999 16:26:22 -0700 (PDT)
Received: by mail.imc.org (bulk_mailer v1.12); Wed, 7 Jul 1999 16:26:17 -0700
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 PAA28093 for <[e-mail]>; Wed, 7 Jul 1999 15:03:18 -0700 (PDT)
Received: from [128.33.238.130] (TC130.BBN.COM [128.33.238.130]) by po1.bbn.com (8.9.1/8.9.1) with ESMTP id SAA24288; Wed, 7 Jul 1999 18:03:53 -0400 (EDT)
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
X-Sender: [e-mail] (Unverified)
Message-Id: <v04020a03b3a90d93b5b5@[128.33.238.77]>
In-Reply-To: <01BEC6D6.FED0A460@HYDRA>
Date: Wed, 7 Jul 1999 18:04:45 -0400
To: Anders Rundgren <[e-mail]>
From: Stephen Kent <[e-mail]>
Subject: RE: I-D ACTION:draft-ietf-pkix-scvp-00.txt
Cc: "[e-mail]" <[e-mail]>
Precedence: bulk
List-Archive: http://www.imc.org/ietf-pkix/mail-archive/
List-Unsubscribe: mailto:[e-mail]?body=unsubscribe
X-UIDL: 53c71fa221d195f86d6084b6db2af08a

Anders,

We have heard from others who work for large companies who use the
technology base that you cite as unable to process ASN.1 structures, and
their comments are at odds with yours.

Yes, there are a lot of folks who are enamored with XML, as one would
expect of any new mechanism that has gotten so much hype in trade rags.  I
don't question the value of XML in some applications, but given the
commitment we already have to ASN.1 in our protocols and in the base cert
and CRL syntax, I don't see a good argument to change here.

Barring more evidence to the contrary, we should stick with ASN.1.

Steve


Received: from localhost (daemon@localhost) by mail.proper.com (8.8.8/8.8.5) with SMTP id OAA27396; Wed, 7 Jul 1999 14:36:11 -0700 (PDT)
Received: by mail.imc.org (bulk_mailer v1.12); Wed, 7 Jul 1999 14:36:00 -0700
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 OAA27372 for <[e-mail]>; Wed, 7 Jul 1999 14:36:00 -0700 (PDT)
Received: from mentat.verisign.com by caladan.verisign.com (8.8.5/BCH1.5) id OAA08520; Wed, 7 Jul 1999 14:34:54 -0700 (PDT)
Received: from newman.verisign.com by mentat.verisign.com (8.8.5/BCH1.0) id OAA14645; Wed, 7 Jul 1999 14:35:59 -0700 (PDT)
Received: by newman.verisign.com with Internet Mail Service (5.5.2448.0) id <N7XW12GS>; Wed, 7 Jul 1999 14:36:02 -0700
Message-ID: <[e-mail]>
From: Warwick Ford <[e-mail]>
To: "'[e-mail]'" <[e-mail]>
Subject: PKIX Agenda for Oslo
Date: Wed, 7 Jul 1999 14:36:00 -0700 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2448.0)
Content-Type: text/plain; charset="iso-8859-1"
Precedence: bulk
List-Archive: http://www.imc.org/ietf-pkix/mail-archive/
List-Unsubscribe: mailto:[e-mail]?body=unsubscribe
X-UIDL: 9fdd60292eed0dbc514ff353754a2ca1

Here is the draft agenda for the Oslo PKIX WG meeting.  Please advise any
additions...

*	Introduction; Project Status; Agenda
*	Active Projects:
*	CMC & Diffie-Hellman POP
*	ECDSA
*	PKIX Roadmap
*	Timestamp Protocol
*	Data Certification Server
*	Qualified Certificates 
*	New Proposals
*	LDAP v3 Profile (Chadwick)
*	Attribute Certificates (Farrell)
*	Event Representation Token (Glassey)
*	Non-repudiation Token (Namjoshi)
*	Cert Validation Protocol (Hoffman)
*	TDTs (Lattin)
*	Any other business


---------------------------------------------------------------------
Warwick Ford, VeriSign, Inc., Tel [phone] x225; Fax [phone]
[e-mail];  301 Edgewater Pl, Suite 210, Wakefield, MA 01880
---------------------------------------------------------------------



Received: from localhost (daemon@localhost)  by mail.proper.com (8.8.8/8.8.5) with SMTP id NAA26124;  Wed, 7 Jul 1999 13:17:28 -0700 (PDT) 
Received: by mail.imc.org (bulk_mailer v1.12); Wed, 7 Jul 1999 13:17:15 -0700 
Received: from iaik.tu-graz.ac.at (excalibur.iaik.tu-graz.ac.at [129.27.152.30])  by mail.proper.com (8.8.8/8.8.5) with ESMTP id NAA26099  for <[e-mail]>; Wed, 7 Jul 1999 13:17:11 -0700 (PDT) 
Received: from plipp [129.27.152.34] by iaik.tu-graz.ac.at  (SMTPD32-5.01) id A473CB00FE; Wed, 07 Jul 1999 22:11:31 +03d0 
Received: from localhost [127.0.0.1] by plipp (IAIK S/MIME Mapper 1.41  14/June/1999); Wed, 07 Jul 1999 22:18:15 +0100 
From: "Peter Lipp" <[e-mail]> 
To: "Carlisle Adams" <[e-mail]> 
Cc: <[e-mail]> 
Subject: AW: Initial comments on SCVP 
Date: Wed, 7 Jul 1999 22:18:15 +0200 
Message-ID: <001f01bec8b5$d82df980$[e-mail]> 
MIME-Version: 1.0 
Content-Type: multipart/signed; micalg=sha1;  boundary="--IAIK.SMIME.MAPPER.79837AB9--";  protocol="application/x-pkcs7-signature" 
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 V5.00.2014.211 
Importance: Normal 
In-Reply-To: <[e-mail]> 
Precedence: bulk 
List-Archive:

The following are the message properties:


   Encrypted: No
   Signed: Yes
   Contents Altered after signing: Yes
   Signature Algorithm: Unknown


> P.S., Al's note just arrived in my inbox.  I tend to prefer the
> smaller-number-of-quite-general-protocols approach
Agreed .
What about something in the middle of it: a general protocol framework with
"subprotocols". One thing that I currently don't like is that all the
protocols are different. DCS uses PKCS#7 for signing the request, OCSP
doesn't but still uses ASN.1 and SCVP does neither. Hmm. Makes me wonder.


Peter
---------------------------------
Dr. Peter Lipp
IAIK, TU Graz
Email [e-mail]
Phone [phone]
Fax   [phone]
Web   http://jcewww.iaik.tu-graz.ac.at


 
List-Unsubscribe: mailto:[e-mail]?body=unsubscribe 
X-UIDL: e4914044f15d5403970c35a0fda0217f 

<html><DIV><A href="file://C:\Temp\AW Initial comments on SCVP.ems <0265.0002>" 
EUDORA="PLUGIN"><IMG alt="C:\Temp\AW Initial comments on SCVP.ems" 
src="file://d:\mail\combined\icons\3ada664.jpg"> AW Initial comments on SCVP.ems 
</A></DIV></html>
>From ???@??? Wed Jul 07 17:07:31 1999
Received: from localhost (daemon@localhost)
	by mail.proper.com (8.8.8/8.8.5) with SMTP id NAA26560;
	Wed, 7 Jul 1999 13:47:34 -0700 (PDT)
Received: by mail.imc.org (bulk_mailer v1.12); Wed, 7 Jul 1999 13:47:33 -0700
Received: from aum (ip11.proper.com [165.227.249.11])
	by mail.proper.com (8.8.8/8.8.5) with ESMTP id NAA26538
	for <[e-mail]>; Wed, 7 Jul 1999 13:47:32 -0700 (PDT)
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.56 (Beta)
Date: Wed, 07 Jul 1999 13:48:02 -0700
To: [e-mail]
From: Paul Hoffman / VPNC <[e-mail]>
Subject: Re: Initial comments on SCVP
In-Reply-To: <[e-mail]>
References: <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Precedence: bulk
List-Archive: http://www.imc.org/ietf-pkix/mail-archive/
List-Unsubscribe: mailto:[e-mail]?body=unsubscribe
X-UIDL: b7b38cac15199962932e8dc74c59c2e9

At 10:09 AM 7/6/1999 -0400, Al Arsenault wrote:
>Right now, it seems like we're adopting a "got a problem, get a protocol"
>approach.

To be more accurate, the approach is closer to "got a problem, get one or 
two protocols".

>   That is:
>
>     - if you want to communicate between an end-entity and a CA/RA, use CMP
>     - if you want to do that using CMS formats, use CMC

That's one problem with two solutions. The "want to do" is not a problem, 
it is a preference.

>     - if you want proof that bits existed at a certain time, use Timestamp
>     - if you want proof that bits existed at a certain time, AND that they
>possessed certain qualities, use DCS

That's one problem (and a subproblem) with two solutions. Clearly, DCS can 
emit an answer that says "I didn't look at the qualities of the bits you 
gave me".

>     - if you don't want to process CRLs yourself, but want to know if a
>certificate is valid at a given time, use OCSP
>     - if you want to have a server do most of the PKI stuff, and let "thin
>clients" just ask servers for the answers, use SCVP

That's one problem (and a subproblem) with two solutions. The only 
difference in this pair is that OCSP is already a standard.

>     - ad infinitum, ad nauseum

Nausea is in the stomach of the beholder. :-)

>The problem to me is that each time we introduce a new protocol, we introduce
>new overhead, much of which is going to be redundant.

Or, worse, slightly different from the other solutions (can you say "key 
identifier"?) which leads to having to be much more careful when 
implementing more than one.


>So, the question I ask is, does this working group believe that the right
>approach should be:
>
>     (a) continue along the current path of building a "large" number of 
> "simple"
>protocols; or
>     (b) redesign the architecture somewhat so that there is a small number of
>protocols, with options and extensions to handle all of the different 
>services.
>
>To me, the advantage to (a) is that it lets designers have lots of flexibility
>in putting together their own PKI structures.  If I don't want OCSP, I 
>leave it
>out completely.  If I have a lightweight client, SCVP may be the only protocol
>it needs; everything else can be off-loaded.  If I just want timestamp 
>services,
>I implement Timestamp and ignore DCS.  et cetera, et cetera.

That's not really an advantage if (b) is designed correctly. Yes, I know 
the "design" word doesn't come up much in this working group: we mostly use 
the stuff that someone else already gave us and we try to salvage what we 
can and make it Internet-friendly (or at least less Internet-scary). If we 
design (b) correctly, implementors still have the flexibility because they 
just turn on or off the parts of the single protocol they want or don't want.

>Similarly, the disadvantage to (b) is that, if we're not careful, we're 
>going to
>force somebody with only a small subset of "the PKI problem" to implement a
>large protocol with lots of overhead, potentially causing them to drop out of
>the PKIX arena altogether.

Two comments here: we can be careful, and we're already forcing out many 
people.

>   The advantage is that my gut feeling tells me we've
>got a better chance of getting an interoperable PKI with a small number of
>protocols that everybody implements.

Absolutely right. We'll do even better if we design carefully so that 
implementors without the advantage of the years that many folks have spent 
on these protocols can still do it right and do it well.

>   (It's bad enough now listening to vendors
>pitching me "we implement PKIX", and having to go through exactly which 
>parts of
>PKIX they mean, and whether that has a snowball's chance in the Sahara of
>actually interoperating with the stuff I've already got.  The problem is going
>to grow exponentially very soon, with all the additional protocols we keep
>defining.)

And it will grow as everyone who thinks they have to do PKI says "we do 
PKIX" and then starts to cobble together the bits they need.

>So - I'm soliciting feedback from the group on  this issue.  The 
>resolution has
>already been reached for CMP vs CMC (approve them both and let the market
>decide),

...not an auspicious beginning for design cleanliness...

>and to an extent for OCSP (its scope was tightly constrained to be
>certificate status, rightly or wrongly).

We could stop there and say "no more piecemeal protocols".

>   But, I don't think we're that far
>along with any of the other protocols, and I'd really like to get a sense for
>the group's views now, while there's still a chance to do something about it.

I for one would be happy to not move SCVP forwards if we were sure we could 
get a more inclusive protocol that covers all the things desired for 
timestamp, DCS, and OCSP. I'm wary of doing certificate enrollment over the 
new protocol, because three choices are worse than two, but if folks want 
One True Protocol, it could be done there cleanly as well (with work).

>We'll put whatever the "right" answer is in the Roadmap, and figure out how to
>say it correctly.  Sean did an outstanding job putting together draft -02 
>of the
>Roadmap (I'm afraid I haven't been much help lately :-).  However, it's 
>getting
>close to time to advance this turkey to informational RFC (most likely, after
>CMC has advanced to Proposed Standard).

That would be nice, but not until more people read it and comment on it. 
You also have a large, unfinished section (5.4) which I think is vitally 
important to get right, given that the press still says  "PKIX uses a 
hierarchical trust model" all the time.

>   So, the sooner decisions can be made
>about "approach" the better.

Sounds like we'll have something to talk about in Oslo.

--Paul Hoffman, Director
--Internet Mail Consortium



Received: from localhost (daemon@localhost) by mail.proper.com (8.8.8/8.8.5) with SMTP id KAA24210; Wed, 7 Jul 1999 10:29:42 -0700 (PDT)
Received: by mail.imc.org (bulk_mailer v1.12); Wed, 7 Jul 1999 10:29:25 -0700
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 KAA24188 for <[e-mail]>; Wed, 7 Jul 1999 10:29:19 -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 TAA00748 for <[e-mail]>; Wed, 7 Jul 1999 19:29:58 +0200
Received: from mega (t4o69p2.telia.com [62.20.145.122]) by caesar.udac.se (8.7.3/NetworkC-1) with SMTP id TAA66943; Wed, 7 Jul 1999 19:29:55 +0200
Message-ID: <000201bec8a6$643da340$[e-mail]>
From: "Anders Rundgren" <[e-mail]>
To: "Stephen Kent" <[e-mail]>
Cc: "PKIX-List" <[e-mail]>
Subject: Re: Use of localityName attribute
Date: Wed, 7 Jul 1999 07:54: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.3110.5
X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by mail.proper.com id KAA24189
Precedence: bulk
List-Archive: http://www.imc.org/ietf-pkix/mail-archive/
List-Unsubscribe: mailto:[e-mail]?body=unsubscribe
X-UIDL: 5b32ad091ca4e9772df6bdc48f3459b7

Steve,
Comments in-line

>Anders,
>
>I strongly disagree with your comments re organization certification.
>
>Organizatiolns issues paper credentials to employees, students, customers,
>etc. all the time.  It is quite logical to move these relationships to
>cyberespace, through the issuance of digital certificates. Organizations
>are uniquely well qualified to certify individuals in organizational
>contexts!

Never said anything else.  But certify in such a context is IMO to bind
AN ALREADY ESTABLISHED IDENTITY (companies do not generally
have too much reason to verify things like origin country etc.) to a
role or credential that the organization have control of (or are certified
for being able to issue!).    This is what is done today.  If you start
an employment you usually have to show some kind of identity
paper to your employer.   Based on that you get entrance cards,
employee number etc.

>One may debate the appropriate scope of these credentials, but
>there is certainly nothing inherrently wrong with organizational
>certification.


Well, as long as companies do not issue ID-cards that are to be treated
with same respect as passports etc. I agree. 

>The use of DUN numbers is purely a private sector initiative.  Dun and
>Bradstreet and encouraging companies to sign up, but this form of
>registration is not universal and has no intrinsic legal standing.  It's
>just an initiative my a company to increase the value of their database, so
>that they can sell the database contents to clients.  Maybe the Swedish
>registration is a government sanctioned form of registration, but DUN
>numbers are not.

I know, the solution is (as written in another posting) that each certificate
domain maintains unique codes for their certified subjects, be it organizations
or idividuals.  Then if there are sanctioned or more or less accepted
official codes they can for organizations, be published by the CA together
with other attributes that are public and is a part of the registration data.


Anders



Received: from localhost (daemon@localhost) by mail.proper.com (8.8.8/8.8.5) with SMTP id IAA22107; Wed, 7 Jul 1999 08:32:55 -0700 (PDT)
Received: by mail.imc.org (bulk_mailer v1.12); Wed, 7 Jul 1999 08:31:48 -0700
Received: from smtpproxy1.mitre.org (mbunix.mitre.org [129.83.20.100]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id IAA22053 for <[e-mail]>; Wed, 7 Jul 1999 08:31:47 -0700 (PDT)
Received: from avsrv1.mitre.org (avsrv1.mitre.org [129.83.20.58]) by smtpproxy1.mitre.org (8.9.3/8.9.3) with ESMTP id LAA12284; Wed, 7 Jul 1999 11:31:20 -0400 (EDT)
Received: (from root@localhost) by avsrv1.mitre.org (8.9.3/8.9.3) id LAA01814; Wed, 7 Jul 1999 11:31:00 -0400 (EDT)
Received: from smtpsrv1.mitre.org (smtpsrv1.mitre.org [129.83.20.101]) by avsrv1.mitre.org (8.9.3/8.9.3) with ESMTP id LAA01769; Wed, 7 Jul 1999 11:30:39 -0400 (EDT)
Received: from MAILHUB2 (mailhub2.mitre.org [129.83.221.18]) by smtpsrv1.mitre.org (8.9.3/8.9.3) with ESMTP id LAA08579; Wed, 7 Jul 1999 11:30:26 -0400 (EDT)
Received: from mm60206-lptp.mitre.org (128.29.105.60) by mailhub2.mitre.org with SMTP id 1139787; Wed, 07 Jul 1999 11:30:26 EST
Message-ID: <[e-mail]>
Date: Wed, 07 Jul 1999 11:22:14 -0400
From: "Ella P. Gardner" <[e-mail]>
Organization: The MITRE Corporation
X-Mailer: Mozilla 4.5 [en]C-19990120M  (Win95; U)
X-Accept-Language: en
MIME-Version: 1.0
To: blues James <[e-mail]>
CC: [e-mail]
Subject: Re: OID 2 5 29 44
References: <[e-mail]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Precedence: bulk
List-Archive: http://www.imc.org/ietf-pkix/mail-archive/
List-Unsubscribe: mailto:[e-mail]?body=unsubscribe
X-UIDL: ace3c5cea3574183ad09556fc9419cdd

Looks like:

joint-iso-ccitt ds(5) certificateExtension (29) crlScope (44)

Ella



Received: from localhost (daemon@localhost) by mail.proper.com (8.8.8/8.8.5) with SMTP id TAA19756; Tue, 6 Jul 1999 19:52:06 -0700 (PDT)
Received: by mail.imc.org (bulk_mailer v1.12); Tue, 6 Jul 1999 19:52:03 -0700
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 TAA19733 for <[e-mail]>; Tue, 6 Jul 1999 19:52:02 -0700 (PDT)
Received: from [128.33.238.77] (TC077.BBN.COM [128.33.238.77]) by po1.bbn.com (8.9.1/8.9.1) with ESMTP id WAA28655; Tue, 6 Jul 1999 22:52:32 -0400 (EDT)
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Message-Id: <v04020a04b3a87105d086@[128.33.238.77]>
In-Reply-To: <004a01bec817$a54c5a00$[e-mail]>
Date: Tue, 6 Jul 1999 22:53:31 -0400
To: "Anders Rundgren" <[e-mail]>
From: Stephen Kent <[e-mail]>
Subject: Re: Use of localityName attribute
Cc: "PKIX-List" <[e-mail]>
Precedence: bulk
List-Archive: http://www.imc.org/ietf-pkix/mail-archive/
List-Unsubscribe: mailto:[e-mail]?body=unsubscribe
X-UIDL: c3d6cdddfd94f1ca61b8f8ffba1577ca
Status: O
X-Status:

Anders,

I strongly disagree with your comments re organization certification.

Organizatiolns issues paper credentials to employees, students, customers,
etc. all the time.  It is quite logical to move these relationships to
cyberespace, through the issuance of digital certificates. Organizations
are uniquely well qualified to certify individuals in organizational
contexts! One may debate the appropriate scope of these credentials, but
there is certainly nothing inherrently wrong with organizational
certification.

Steve


Received: from localhost (daemon@localhost) by mail.proper.com (8.8.8/8.8.5) with SMTP id TAA20079; Tue, 6 Jul 1999 19:55:10 -0700 (PDT)
Received: by mail.imc.org (bulk_mailer v1.12); Tue, 6 Jul 1999 19:55:09 -0700
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 TAA20056 for <[e-mail]>; Tue, 6 Jul 1999 19:55:09 -0700 (PDT)
Received: from [128.33.238.77] (TC077.BBN.COM [128.33.238.77]) by po1.bbn.com (8.9.1/8.9.1) with ESMTP id WAA28934; Tue, 6 Jul 1999 22:55:44 -0400 (EDT)
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Message-Id: <v04020a05b3a871dc030a@[128.33.238.77]>
In-Reply-To: <001901bec807$4aa97b60$[e-mail]>
Date: Tue, 6 Jul 1999 22:56:47 -0400
To: "Anders Rundgren" <[e-mail]>
From: Stephen Kent <[e-mail]>
Subject: Re: Use of localityName attribute
Cc: "PKIX-List" <[e-mail]>
Precedence: bulk
List-Archive: http://www.imc.org/ietf-pkix/mail-archive/
List-Unsubscribe: mailto:[e-mail]?body=unsubscribe
X-UIDL: 96111d2f8d8db117a2b77d03a65ef160
Status: O
X-Status:

Anders,

>When you register a company you usually provide a lot of data such as
>addresses, telephone-numbers, president and board-member, some
>description of what the company does etc.
>
>In return you get a DUN-number (in the US) or a registration number (in
>Sweden).

The use of DUN numbers is purely a private sector initiative.  Dun and
Bradstreet and encouraging companies to sign up, but this form of
registration is not universal and has no intrinsic legal standing.  It's
just an initiative my a company to increase the value of their database, so
that they can sell the database contents to clients.  Maybe the Swedish
registration is a government sanctioned form of registration, but DUN
numbers are not.

Steve


Received: from localhost (daemon@localhost) by mail.proper.com (8.8.8/8.8.5) with SMTP id SAA15796; Tue, 6 Jul 1999 18:41:40 -0700 (PDT)
Received: by mail.imc.org (bulk_mailer v1.12); Tue, 6 Jul 1999 18:41:16 -0700
Received: from mail.tradevan.com.tw (mail.tradevan.com.tw [203.67.65.16]) by mail.proper.com (8.8.8/8.8.5) with SMTP id SAA15766 for <[e-mail]>; Tue, 6 Jul 1999 18:41:06 -0700 (PDT)
Received: from hello.com.tw ([172.20.1.107]) by mail.tradevan.com.tw (8.6.12/8.6.9) with ESMTP id JAA08055 for <[e-mail]>; Wed, 7 Jul 1999 09:57:52 +0800
Message-ID: <[e-mail]>
Date: Wed, 07 Jul 1999 09:41:17 +0800
From: blues James <[e-mail]>
X-Mailer: Mozilla 4.6 [en] (Win98; I)
X-Accept-Language: en
MIME-Version: 1.0
To: [e-mail]
Subject: OID 2 5 29 44
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Precedence: bulk
List-Archive: http://www.imc.org/ietf-pkix/mail-archive/
List-Unsubscribe: mailto:[e-mail]?body=unsubscribe
X-UIDL: 21ccfeedd877f2076fbb60ebe0bd68af

Hello,
  As I parsed a CRL cert, I found an OID "2 5 29 44". But I don't know
what it mean. ay somebody tell me what it means?

Thanks,
James Lam



Received: from localhost (daemon@localhost) by mail.proper.com (8.8.8/8.8.5) with SMTP id RAA05350; Tue, 6 Jul 1999 17:28:00 -0700 (PDT)
Received: by mail.imc.org (bulk_mailer v1.12); Tue, 6 Jul 1999 17:27:41 -0700
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 RAA05312 for <[e-mail]>; Tue, 6 Jul 1999 17:27: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 CAA07727 for <[e-mail]>; Wed, 7 Jul 1999 02:28:19 +0200
Received: from mega (t1o69p19.telia.com [62.20.144.19]) by caesar.udac.se (8.7.3/NetworkC-1) with SMTP id CAA09314; Wed, 7 Jul 1999 02:28:06 +0200
Message-ID: <004a01bec817$a54c5a00$[e-mail]>
From: "Anders Rundgren" <[e-mail]>
To: <[e-mail]>
Cc: <[e-mail]>, "Petra Gloeckner" <[e-mail]>, "PKIX-List" <[e-mail]>, "Stefan Santesson" <[e-mail]>
Subject: Re: Use of localityName attribute
Date: Wed, 7 Jul 1999 02:25:48 +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.3110.5
X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by mail.proper.com id RAA05313
Precedence: bulk
List-Archive: http://www.imc.org/ietf-pkix/mail-archive/
List-Unsubscribe: mailto:[e-mail]?body=unsubscribe
X-UIDL: cbef699ebbcd7beedb1fd5b6ed05aada

Tom,
Thanx for the short-version (although it still sounds complicated to me).

<large snip>
>And aren't certificates mainly intended for computers to read and interprete?
>
>[Tom Gindin]   Of course they are, but who administers the unique codes?  In
>Sweden, the answer is probably "the government".  In the USA and a number of
>other countries, there is no equally simple answer.


To me it seems natural that CAs/RAs create and maintain these codes regardless if
they denote individuals or organisations.  Such a code does not have to be unique
outside a "certificate domain" if there exists no "absolute" code like SSN (or U may not
even want to use such).  This though more or less requires CAs to be independent
commercial or government-owned to work.

As this works fine today on a fairly large global scale with DNS names and server-
certificates I see no reason why it should not work for organisations and individuals. 
That server-certificates do not contain IP-addresses is because this is an unstable
attribute of less importance, as is the address of an organization or an employment
for an individual.  In case you need such an attribute you interrogate thee true owner
rather than a TTP.

But, I will not waste bandwidth on this item [more] as I know that the idea that organizations
should create certificates seems to be a cornerstone in QC/EU-projects.  I object to that as it is not
in line with normal company business priorities to certify individuals/employees.  As long as
employees do the tasks they are supposed to they are OK to most employers!

However, if an employee starts to use his/her in-house created cert for private use, their employer puts
on a potential liability burdon they have no reason to accept.   But if individuals can't use their
certs externally what was really the point with a CA hierarky anyway?


Anders



Received: from localhost (daemon@localhost) by mail.proper.com (8.8.8/8.8.5) with SMTP id QAA01348; Tue, 6 Jul 1999 16:06:37 -0700 (PDT)
Received: by mail.imc.org (bulk_mailer v1.12); Tue, 6 Jul 1999 16:06:35 -0700
Received: from e3.ny.us.ibm.com (e3.ny.us.ibm.com [32.97.182.103]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id QAA01323 for <[e-mail]>; Tue, 6 Jul 1999 16:06:35 -0700 (PDT)
From: [e-mail]
Received: from northrelay02.pok.ibm.com (northrelay02.pok.ibm.com [9.117.200.22]) by e3.ny.us.ibm.com (8.9.3/8.9.3) with ESMTP id TAA60290; Tue, 6 Jul 1999 19:07:00 -0400
Received: from D51MTA05.pok.ibm.com (d51mta05.pok.ibm.com [9.117.200.33]) by northrelay02.pok.ibm.com (8.8.8m2/NCO v2.03) with SMTP id TAA63654; Tue, 6 Jul 1999 19:07:09 -0400
Received: by D51MTA05.pok.ibm.com(Lotus SMTP MTA v4.6.4  (830.2 3-23-1999))  id 852567A6.007EFDE6 ; Tue, 6 Jul 1999 19:07:05 -0400
X-Lotus-FromDomain: IBMUS
To: "Anders Rundgren" <[e-mail]>
cc: [e-mail], "Petra Gloeckner" <[e-mail]>, "PKIX-List" <[e-mail]>, "Stefan Santesson" <[e-mail]>
Message-ID: <[e-mail]>
Date: Tue, 6 Jul 1999 19:06:39 -0400
Subject: Re: Use of localityName attribute
Mime-Version: 1.0
Content-type: text/plain; charset=us-ascii
Content-Disposition: inline
Precedence: bulk
List-Archive: http://www.imc.org/ietf-pkix/mail-archive/
List-Unsubscribe: mailto:[e-mail]?body=unsubscribe
X-UIDL: ca1fcbf2781d3ff00bce1d9aaf629e6a

"Anders Rundgren" <[e-mail]> on 07/06/99 07:28:44 PM

To:   Tom Gindin/Watson/IBM@IBMUS, [e-mail]
cc:   "Petra Gloeckner" <[e-mail]>, "PKIX-List"
      <[e-mail]>, "Stefan Santesson" <[e-mail]>
Subject:  Re: Use of localityName attribute





Tom
I think that I have a slightly different view on unique identity in
EE-certificates

<snip>
>Locality is often part of the uniquely identifying set of
>information for a legally registered organization, and thus needs to go into
>some such certificates.  How about some wording such as the following:
>StateOrProvinceName and/or localityName SHOULD be included in the subject and
>issuer name only when the organization or organizationalUnit is legally
>registered as possessing a unique right to the specified organizational name
>within the state or locality specified.


When you register a company you usually provide a lot of data such as
addresses, telephone-numbers, president and board-member, some
description of what the company does etc.

In return you get a DUN-number (in the US) or a registration number (in Sweden)
Why do you need anything more than information about the registering
organisation,
the subject organisation name and their registration code?

[Tom Gindin]   DUNS numbers are assigned by Dun & Bradstreet, the largest
business credit reporting service in the USA.  They have no particular legal
standing and you don't get one by registering a company or a non-profit.  Of
course, small businesses usually do get one pretty quickly but non-profits might
not always do so.  The legal identification numbers an organization does get are
usually local to a state, except for the federal taxpayer ID, which is not
normally published anywhere except on tax forms.  People use DUNS numbers
largely because the US government doesn't want the taxpayer ID's used for this,
while D&B is quite happy to have their numbers used.

Actually the same apply equally well to individuals.  You are probably
registered
with an employee-number at IBM for reasons like it is very convenient, uses very
little space and is compatible with current database technlogy.  QCs way of
determine
identity based on an unspecified (or variant) set of attributes is extremely
hard to combine with normal staff adminstering systems.  That you may want to
search a certified entity for various attributes does not require these to be
included
in the certificate.  And then any number of attributes can be specified
externally in
the way that apply to the situation/business etc. without interfering with the
certificate.

[Tom Gindin]   Actually, my proposed rule was intended to make the set of
attributes used more predictable rather than less.  Here's a short version of
the rules I was suggesting: CN, O, and C MUST be present, OU MAY be present, ST
and L MAY be present in cases where they are required to render a name legally
unambiguous and SHOULD NOT be present otherwise.  Furthermore, in any country
where ST is defined, L MUST NOT be present if ST is not present.  Also, since L
and ST are intended for legal clarification of organization names, they SHOULD
come between C and O, and MUST come between C and OU.

As an analogy: I have yet to see a computerized customer register using anything
but a single unique code to separate them from each other.  Or a credit-card
BTW.

And aren't certificates mainly intended for computers to read and interprete?

[Tom Gindin]   Of course they are, but who administers the unique codes?  In
Sweden, the answer is probably "the government".  In the USA and a number of
other countries, there is no equally simple answer.

<snip>




Received: from localhost (daemon@localhost) by mail.proper.com (8.8.8/8.8.5) with SMTP id PAA29955; Tue, 6 Jul 1999 15:31:18 -0700 (PDT)
Received: by mail.imc.org (bulk_mailer v1.12); Tue, 6 Jul 1999 15:30:58 -0700
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 PAA29924 for <[e-mail]>; Tue, 6 Jul 1999 15:30: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 AAA07048 for <[e-mail]>; Wed, 7 Jul 1999 00:31:27 +0200
Received: from mega (t3o69p113.telia.com [62.20.145.113]) by caesar.udac.se (8.7.3/NetworkC-1) with SMTP id AAA85211; Wed, 7 Jul 1999 00:31:01 +0200
Message-ID: <001901bec807$4aa97b60$[e-mail]>
From: "Anders Rundgren" <[e-mail]>
To: <[e-mail]>, <[e-mail]>
Cc: "Petra Gloeckner" <[e-mail]>, "PKIX-List" <[e-mail]>, "Stefan Santesson" <[e-mail]>
Subject: Re: Use of localityName attribute
Date: Wed, 7 Jul 1999 00:28:44 +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.3110.5
X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by mail.proper.com id PAA29925
Precedence: bulk
List-Archive: http://www.imc.org/ietf-pkix/mail-archive/
List-Unsubscribe: mailto:[e-mail]?body=unsubscribe
X-UIDL: c4e30836bebb08fa5390bf6fb6e16736

Tom
I think that I have a slightly different view on unique identity in EE-certificates

<snip>
>Locality is often part of the uniquely identifying set of
>information for a legally registered organization, and thus needs to go into
>some such certificates.  How about some wording such as the following:
>StateOrProvinceName and/or localityName SHOULD be included in the subject and
>issuer name only when the organization or organizationalUnit is legally
>registered as possessing a unique right to the specified organizational name
>within the state or locality specified.


When you register a company you usually provide a lot of data such as
addresses, telephone-numbers, president and board-member, some
description of what the company does etc.

In return you get a DUN-number (in the US) or a registration number (in Sweden).

Why do you need anything more than information about the registering organisation,
the subject organisation name and their registration code?

Actually the same apply equally well to individuals.  You are probably registered
with an employee-number at IBM for reasons like it is very convenient, uses very
little space and is compatible with current database technlogy.  QCs way of determine
identity based on an unspecified (or variant) set of attributes is extremely
hard to combine with normal staff adminstering systems.  That you may want to
search a certified entity for various attributes does not require these to be included
in the certificate.  And then any number of attributes can be specified externally in
the way that apply to the situation/business etc. without interfering with the certificate.

As an analogy: I have yet to see a computerized customer register using anything
but a single unique code to separate them from each other.  Or a credit-card BTW.

And aren't certificates mainly intended for computers to read and interprete?

<snip>

Regards
Anders Rundgren



Received: from localhost (daemon@localhost) by mail.proper.com (8.8.8/8.8.5) with SMTP id MAA23984; Tue, 6 Jul 1999 12:27:35 -0700 (PDT)
Received: by mail.imc.org (bulk_mailer v1.12); Tue, 6 Jul 1999 12:27:25 -0700
Received: from e1.ny.us.ibm.com (e2.ny.us.ibm.com [32.97.182.102]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id MAA23960 for <[e-mail]>; Tue, 6 Jul 1999 12:27:24 -0700 (PDT)
From: [e-mail]
Received: from northrelay02.pok.ibm.com (northrelay02.pok.ibm.com [9.117.200.22]) by e1.ny.us.ibm.com (8.9.3/8.9.3) with ESMTP id PAA85142; Tue, 6 Jul 1999 15:27:40 -0400
Received: from D51MTA05.pok.ibm.com (d51mta05.pok.ibm.com [9.117.200.33]) by northrelay02.pok.ibm.com (8.8.8m2/NCO v2.03) with SMTP id PAA144368; Tue, 6 Jul 1999 15:27:44 -0400
Received: by D51MTA05.pok.ibm.com(Lotus SMTP MTA v4.6.4  (830.2 3-23-1999))  id 852567A6.006AE555 ; Tue, 6 Jul 1999 15:27:35 -0400
X-Lotus-FromDomain: IBMUS
To: "Anders Rundgren" <[e-mail]>, [e-mail]
cc: "Petra Gloeckner" <[e-mail]>, "PKIX-List" <[e-mail]>, "Stefan Santesson" <[e-mail]>
Message-ID: <[e-mail]>
Date: Tue, 6 Jul 1999 13:00:18 -0400
Subject: Re: Use of localityName attribute
Mime-Version: 1.0
Content-type: text/plain; charset=us-ascii
Content-Disposition: inline
Precedence: bulk
List-Archive: http://www.imc.org/ietf-pkix/mail-archive/
List-Unsubscribe: mailto:[e-mail]?body=unsubscribe
X-UIDL: 298a1f3b5ded8b9c7dd84fbf48eccd2b

     Serious comments, with some others, below.  Comments with my name in
brackets are mine, with leading ">>" are David Chadwick's, and with no prefix
are Anders'.

          Tom Gindin


"Anders Rundgren" <[e-mail]> on 07/03/99 05:20:37 PM

To:   [e-mail], "Petra Gloeckner"
      <[e-mail]>
cc:   "PKIX-List" <[e-mail]>, "Stefan Santesson" <[e-mail]>
      (bcc: Tom Gindin/Watson/IBM)
Subject:  Re: Use of localityName attribute


(snip)
#2:
In many implementations (like yours) both an organization and
an individual within that organization must be unambiguously defined.

As it is already a hard task to uniquely identify an organization, it deserves
a certificate of its own.  And to build identity on local addresses is a bad
idea
as for instance my own company just moved a couple of blocks and we
are still known as the Swedish company "Jaybis AB" with registration
number 564567-1267.  If you need to know the address of an organization
you should look in a public registry (assuming it is legally registered) and not
in a certificate.

[Tom Gindin]   Locality is often part of the uniquely identifying set of
information for a legally registered organization, and thus needs to go into
some such certificates.  How about some wording such as the following:
StateOrProvinceName and/or localityName SHOULD be included in the subject and
issuer name only when the organization or organizationalUnit is legally
registered as possessing a unique right to the specified organizational name
within the state or locality specified.

>> I need to request a change to the qualified certificate draft to allow
>> the use of the localityName attribute to be used to unambiguously
>> identify a subject and issuer in a DN. The UK National Health
>> Service Standard for Directory Services requires the use of locality
>> name to unambiguously identify different organisational units within
>> the NHS. For example, there are literally dozens of St Mary's
>> Hospitals within the UK NHS, so that O and OU are insufficient as
>> differentiators. Consequently localityName, based on the UK Post
>> Office defined localities, is used to differentiate between them (we
>> do not use the full postal address as this is too cumbersome.)

[Tom Gindin]   In the particular case of hospitals in the NHS I'm somewhat
dubious about putting the locality into the subject or issuer name rather than
adding an extra OU.  After all, "St. Mary's of Bethlehem" is not in Bethlehem.
Perhaps we are all there anyhow (Bedlam, not Bethlehem) :-)

>>
>> As the QC draft stands at the moment, (as I read it), the use of
>> localityName as currently defined by the NHS would not be allowed
>> as a differentiator.
>>
>> The offending sections are:
>>
>> 3.1.1 Issuer -  allows for state or province name but not for
>> localityName. We request that localityName be added to this section.
>>
>> 3.1.2 Subject - allows postalAddress but not localityName and states
>> "Other attributes may be present but MUST NOT be necessary to
>> distinguish the subject name from other subject names within the
>> issuer domain."
>>
>> This effectively precludes localityName from being used to
>> unambiguously differentiate between hospital. We request that
>> localityName be added to the MAY list.
>>
>> Regards
>> David




Received: from localhost (daemon@localhost) by mail.proper.com (8.8.8/8.8.5) with SMTP id KAA21136; Tue, 6 Jul 1999 10:20:20 -0700 (PDT)
Received: by mail.imc.org (bulk_mailer v1.12); Tue, 6 Jul 1999 10:20:16 -0700
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 KAA21110 for <[e-mail]>; Tue, 6 Jul 1999 10:20:16 -0700 (PDT)
Received: from catalyst (catalyst.llnl.gov [128.115.223.61]) by poptop.llnl.gov (8.8.8/LLNL-3.0.2/pop.llnl.gov-5.1) with SMTP id KAA03361; Tue, 6 Jul 1999 10:20:48 -0700 (PDT)
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.3 (32)
Date: Tue, 06 Jul 1999 10:20:23 -0700
To: "Peter Williams" <[e-mail]>
From: Tony Bartoletti <[e-mail]>
Subject: RE: I-D ACTION:draft-ietf-pkix-scvp-00.txt 
Cc: [e-mail]
In-Reply-To: <007901bec496$745a8360$[e-mail]>
References: <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Precedence: bulk
List-Archive: http://www.imc.org/ietf-pkix/mail-archive/
List-Unsubscribe: mailto:[e-mail]?body=unsubscribe
X-UIDL: 5eed5034d71c7b77a9cd0fec6c9c3ddd

At 09:23 AM 7/2/99 -0500, Peter Williams wrote:

>Remember, internet standards should be basically implementable by
>a programmer-year. Of course, productization takes more effort,
>but we are not here as a vendor-forum... we are here to address
>the internet community who want to interwork and communicate.

I'd like to have that paragraph bronzed, if I may;)

___tony___



Tony Bartoletti                                             LL
IOWA Center                                              LL LL
Lawrence Livermore National Laboratory                LL LL LL
PO Box 808, L - 089                                   LL LL LL
Livermore, CA 94551-9900                              LL LL LLLLLLLL
phone: [phone]   fax: [phone]               LL LLLLLLLL
email: [e-mail]                                   LLLLLLLL


Received: from localhost (daemon@localhost) by mail.proper.com (8.8.8/8.8.5) with SMTP id IAA18232; Tue, 6 Jul 1999 08:25:03 -0700 (PDT)
Received: by mail.imc.org (bulk_mailer v1.12); Tue, 6 Jul 1999 08:24:56 -0700
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 IAA18206 for <[e-mail]>; Tue, 6 Jul 1999 08:24:56 -0700 (PDT)
Received: from mentat.verisign.com by caladan.verisign.com (8.8.5/BCH1.5) id IAA21602; Tue, 6 Jul 1999 08:23:55 -0700 (PDT)
Received: from newman.verisign.com by mentat.verisign.com (8.8.5/BCH1.0) id IAA16524; Tue, 6 Jul 1999 08:25:01 -0700 (PDT)
Received: by newman.verisign.com with Internet Mail Service (5.5.2448.0) id <N7XWD9BC>; Tue, 6 Jul 1999 08:25:02 -0700
Message-ID: <[e-mail]>
From: Michael Myers <[e-mail]>
To: [e-mail]
Subject: Further comments on SCVP
Date: Tue, 6 Jul 1999 08:24:56 -0700 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2448.0)
Content-Type: text/plain; charset="iso-8859-1"
Precedence: bulk
List-Archive: http://www.imc.org/ietf-pkix/mail-archive/
List-Unsubscribe: mailto:[e-mail]?body=unsubscribe
X-UIDL: edb694d822e4b0e33337a7d1eb394744

All,

My data points on the similarities and diffs between RFC2560 and the
proposed protocol.  Analysis to follow.


Similarities between RFC2560 and the proposed protocol:
-----------------------------------------------------------------------

-  Both are online request-response protocols related to reliance on public
key certificates.
-  Both enable use of a digitally signed request.
-  Both enable generation of a digitally signed response
-  Both provide for OID-based request extensibility.
-  Both provide for OID-based response extensibility.
-  Both have optional nonces in the request.
-  Both enable integration of request nonces in the response.
-  Both enable basic revocation checking.
-  Both provide a producedAt value in the response.
-  Both include a value of thisUpdate in the response.
-  Both include response values for unknown, revoked and good.
-  Both enable inclusion of multiple certificates in the request.
-  Both establish request version numbers.
-  Both establish response version numbers.
-  Both enable inclusion of policy OIDs.
-  Both define response status fields
-  Both define a per-certificate response validation structure

OCSP further enables certificate validation against archives and the
optional specification in the request of the URL address of a requester's
intended responder. 

SCVP appears to introduce online certificate validation protocol elements
that eliminate or substantially reduce reliance on embedded trusted roots.
Call this the "Delegated Path Validation" (DPV) extension to the basic
concept of online certificate validation. Building on the above
capabilities, SCVP proposes a DPV transaction as:

Request extensions
------------------------
1.  Optional use of a RequestHash  in lieu of a digitally signed request.
2.  Explicit specification of a request being a path validation request vs.
a revocation status check.
3.  Optional inclusion of the subject certificate in the request.
4.  Optional support for PGP style public key management.
5.  Optional request for the value of subject public key, subject name,
certificate chain or revocation proof.
6.  Optional specification of intermediate certificates to use as a
supplement to the validation path of the subject certificate.
7.  Optional specification of trusted roots the server must rely on.
8.  Optional configuration identifier that points to a pre-defined set of
the above options.
9.  Extensions may be critical or non-critical.

And in the response: 

Response extensions
--------------------------
10.  "Unrecognized" error codes related to the above optional request
protocol elements.
11.  Validation response values for "valid", "notValid",
"temporarilyUnknown" and "unknown".
12.  Optional inclusion of an errorMessage text string
13.  Optional inclusion of subject public key value, subject name or path
validation chain, consistent with prior request.
14.  Optional inclusion of requestHash appearing in request.
15.  Optional inclusion of revocation proof content.
16.  Optional use of a digital signature


Mike


Received: from localhost (daemon@localhost) by mail.proper.com (8.8.8/8.8.5) with SMTP id IAA18798; Tue, 6 Jul 1999 08:41:29 -0700 (PDT)
Received: by mail.imc.org (bulk_mailer v1.12); Tue, 6 Jul 1999 08:41:26 -0700
Received: from www.meridianus.com (209.249.223.18.has.no.reverse [209.249.223.18] (may be forged)) by mail.proper.com (8.8.8/8.8.5) with ESMTP id IAA18771 for <[e-mail]>; Tue, 6 Jul 1999 08:41:26 -0700 (PDT)
Received: from pc1 by www.meridianus.com (8.8.8+Sun/SMI-SVR4) id JAA11218; Tue, 6 Jul 1999 09:36:37 -0700 (PDT)
Message-ID: <04ee01bec7c5$f9c11d20$[e-mail]>
From: "[e-mail]" <[e-mail]>
To: "Al Arsenault" <[e-mail]>
Cc: "IETF PKIX" <[e-mail]>
References: <[e-mail]> <[e-mail]>
Subject: NEED A BETTER PKI use ROADMAP - was Re: Initial comments on SCVP
Date: Tue, 6 Jul 1999 08:40:57 -0700
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.00.2014.211
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2014.211
Precedence: bulk
List-Archive: http://www.imc.org/ietf-pkix/mail-archive/
List-Unsubscribe: mailto:[e-mail]?body=unsubscribe
X-UIDL: ddeb2c91564bceaa3be5210b79ba70d4

Hi all, I apologize upfront for this commentary and it bears no one person
any personal ill. It is likely to seriously piss some people off, and a
number more will just say "There is Todd popping off again..." but the
reality of this commentary is very true and important for the bigger picture
of the Group, it's deliverables and the continued respect and allegiance it
has.

Al was right in his commentary about the larger issue looming here, that of
a understandable and cohesive roadmap. That is what is specifically trying
to be accomplished, and how we can eliminate the corporate "We did it first"
mentality that permeates the group now...

You as intelligent people must understand that the key uses of the
management of the PKIX world is to provide structure for the working group's
efforts and part of that structure is involved in promulgating the standards
to other organizations.

What we really need is a plan for how the IETF and it's management intend to
promulgate our efforts into other standards organizations and what the scope
of our activities should be., THESE ARE KEY RESPONSIBILITIES of the WG
Chairs and in my mind are undone to date in the PKI WG. My feeling is that
the IETF's requirements and efforts have changed and the organization is
trying not to, and that this is introducing a lot of Entropy into the mix
and slowing down our progress.

So then this new updated ROADMAP plan needs to address

    1)     What we are trying to do - What are the goals of the effort and
the subsystem efforts, in no uncertain terms
    2)    The Scope of the efforts and responsibilities of the
players/protocols
    3)    What types of systems and transaction processing infrastructure
that we need to put in place and WHY!
    4)    What other standards agencies we are making alliances with and who
from the WG is the representative to handle the relationship
    5)    What the goals and deliverables for our standards are, that is
what Standards these efforts are built to address.

    6)    Regular reports on the a) Status of the management efforts, b)
relations to other efforts within the Group and their state, and c)
cooperative (cross standards group) efforts.

 From my standpoint the operating of the PKIX WG, as a passive pit that
people just come to  swirl their designs through is bogus. What we really
need is a better definition of the evolutionary process and the interface
points and these fall directly on the WG Chair's.

BTW, my feeling  is that with everything that is going on today, that PKI
may need to be split into a number of other WG's to support this since
mindset the PKI roadmap is getting too large for one group to handle without
some additional structure.

Me specific response to Al's commentary are included below.

----- Original Message -----
From: Al Arsenault <[e-mail]>
To: <[e-mail]>
Cc: <[e-mail]>; <[e-mail]>
Sent: Tuesday, July 06, 1999 7:09 AM
Subject: Re: Initial comments on SCVP


>
>
> [e-mail] wrote:
>
> > OCSP, SCVP, and now DCS. It appears that there is more commonality
between
> > the various protocol's goals, then there is difference. Even the authors
of
> > the drafts are apparently perplexed when trying to substantiate the work
and
> > to outline the distinction of one protocol from the others.


> > Writing a [rough
> > cut of a] road map would be a nightmare, I'm imagining. Or could it be a
> > good, probably even a necessary thing to do at this stage, to see for
> > ourselves where we are heading?

AMEN!!!!!

>
> Actually, stuff like this (CRS/CMC, CMP, etc.) was what led to the initial
cut
> at a PKIX roadmap in the first place.  Some of us were tired and
frustrated at
> having to explain what all the alphabet soup in PKIX was in the first
place.

This is a bigger issue in PKIX that what people think since there clearly
are a limited amount of commercial apps for a number of the efforts underway
in PKIX right now.

The reality of the situation is that we spend a tremendous amount of time
and collective focus working on what is clearly "Art for Art Sake" and this
must end as our predominent activity  or it is my feeling that PKIX is
ultimately doomed.

>
> Right now, it seems like we're adopting a "got a problem, get a protocol"
> approach.

AMEN!!! - The issue herre is that the 'problems' haven't changed, it's just
that with no end use statement everytime a new rock in the road pops up, the
protocol is morphed instead of just addressing the end use goal to begin
with.

> That is:
>
>     - if you want to communicate between an end-entity and a CA/RA, use
CMP
>     - if you want to do that using CMS formats, use CMC
>     - if you want proof that bits existed at a certain time, use Timestamp
>     - if you want proof that bits existed at a certain time, AND that they
> possessed certain qualities, use DCS
>     - if you don't want to process CRLs yourself, but want to know if a
> certificate is valid at a given time, use OCSP
>     - if you want to have a server do most of the PKI stuff, and let "thin
> clients" just ask servers for the answers, use SCVP
>     - ad infinitum, ad nauseum

This is so true it is ridiculous and the mindset that "I'll just morph this
existing effort" to fill that need becuase I didn't work my use models out
from the beginning is also negligent of the group. If you are trying to
solve a problem and the problem morphs on you, one of two things happened.
1 - you didn't do the upfront work to understand what you were trying to do,
or 2, you tried to fix a movig target style problem. Either way the efforts
wind up dilluting the focus and causing enough noise in the machine that the
organization looks like a bumch of arrogent geeks trying to tell the world
how they are going to do what it is they do.


>
> The problem to me is that each time we introduce a new protocol, we
introduce
> new overhead, much of which is going to be redundant.

AMEN

>
> So, the question I ask is, does this working group believe that the right
> approach should be:
>
>     (a) continue along the current path of building a "large" number of
"simple"
> protocols; or
>     (b) redesign the architecture somewhat so that there is a small number
of
> protocols, with options and extensions to handle all of the different
services.
>
> To me, the advantage to (a) is that it lets designers have lots of
flexibility
> in putting together their own PKI structures.  If I don't want OCSP, I
leave it
> out completely.  If I have a lightweight client, SCVP may be the only
protocol
> it needs; everything else can be off-loaded.  If I just want timestamp
services,
> I implement Timestamp and ignore DCS.  et cetera, et cetera.

You could, if the end use models would be satisfied with those services. How
many applications for these literal unbundled protocols are there though?

>
> The disadvantage, though, is that for somebody who's going to do a lot of
the
> protocols in a "heavyweight" PKI, there's a lot of redundancy.

> If I have DCS,
> what does Timestamp truly buy me - and is this something that couldn't be
better
> handled by a slight modification to DCS?

No... (what I mean is that), it buys you a limited proofing model, because
TTP models are in themselves flawed and costly to scale. The reality about
timestamping from a commercial standpoint is that the value is in embedding
the timestamping infrastructure as a proof model *INSIDE* the transaction
engine(s). This way if you need a TTP they connet to their embedded system
through a simple protocol, maybe like an SSL transport.

The real issue is that the people driving the current proposal still haven't
addressed that the underlying inability to deliver and reference relaible
time has been fixed for sometime now.

To support this assertion, and that I am wrong and TTP models work so well
then explain to me why NetDox's failure and Surety's position now are so
powerful. The bottomline is that any self-respecting IT person wants to own
and operate their infrastructure and that's that.

> Similarly, if I do SCVP, what does
> OCSP buy me?  Would I be better served by defining SCVP to have a
mandatory part
> that's the moral equivalent of OCSP, with extensions to handle the rest of
the
> stuff?
>
> Similarly, the disadvantage to (b) is that, if we're not careful, we're
going to
> force somebody with only a small subset of "the PKI problem" to implement
a
> large protocol with lots of overhead, potentially causing them to drop out
of
> the PKIX arena altogether.

No we are not. Becuase they wont. It's purely a financial thing.

> The advantage is that my gut feeling tells me we've
> got a better chance of getting an interoperable PKI with a small number of
> protocols that everybody implements.

ABSOLUTELY!

>  (It's bad enough now listening to vendors
> pitching me "we implement PKIX", and having to go through exactly which
parts of
> PKIX they mean, and whether that has a snowball's chance in the Sahara of
> actually interoperating with the stuff I've already got.  The problem is
going
> to grow exponentially very soon, with all the additional protocols we keep
> defining.)
>
> So - I'm soliciting feedback from the group on  this issue.  The
resolution has
> already been reached for CMP vs CMC (approve them both and let the market
> decide), and to an extent for OCSP (its scope was tightly constrained to
be
> certificate status, rightly or wrongly).  But, I don't think we're that
far
> along with any of the other protocols, and I'd really like to get a sense
for
> the group's views now, while there's still a chance to do something about
it.

I agree with you 100%

>
> We'll put whatever the "right" answer is in the Roadmap, and figure out
how to
> say it correctly.

So far I suggest that we have done this only for a  few of our systems and
technologies.

The reality is that the management and players involved in steering these
efforts have not done their homework properly. I suggest that the key issues
to advancing this technology to the RFC state would involve the standard RFC
rules and two implementations
I further suggest that the most valuable thing that the IETF and in
particular the PKI team management can do is to create a road map of what
protocols it has on the board and what their intended usese are and how they
effect one and other.

I also suggest that these protocols be modled in how they interact and what
they provide,so people know what they are getting at the commerical
black-box level. That way the commercial world knows what this might set of
tools can do and what it cannot and we regain our credibility. These should
be amended into the PKI Roadmap or included as an appendix.


The problem with this is that most of the efforts currently underway,
especially the timestamping one does not have a specific clearly stated end
use model. It is more the thing of "Well we created it, now you use it" and
this make us look foolish and unkempt. All in all, the real issue is that
this inability to control these issues says to me that PKIX is way out of
hand.

> Sean did an outstanding job putting together draft -02 of the
> Roadmap (I'm afraid I haven't been much help lately :-).  However, it's
getting
> close to time to advance this turkey to informational RFC (most likely,
after
> CMC has advanced to Proposed Standard).  So, the sooner decisions can be
made
> about "approach" the better.

I suggest that without a statement of use that NO PROTOCOL or draft should
be advanced beyond a I-D. The day's for doing art-for-art's-sake are not
over yet, it's just we need to understand what is intended and what we can
depend on. So if there is no specific use model, then say that upfront.


Todd




Received: from localhost (daemon@localhost) by mail.proper.com (8.8.8/8.8.5) with SMTP id HAA16799; Tue, 6 Jul 1999 07:36:35 -0700 (PDT)
Received: by mail.imc.org (bulk_mailer v1.12); Tue, 6 Jul 1999 07:36:34 -0700
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 HAA16776 for <[e-mail]>; Tue, 6 Jul 1999 07:36:33 -0700 (PDT)
Received: 	id KAB10093; Tue, 6 Jul 1999 10:30:24 -0400
Received: by gateway id <NP651PLL>; Tue, 6 Jul 1999 10:32:51 -0400
Message-ID: <[e-mail]>
From: Carlisle Adams <[e-mail]>
To: "'[e-mail]'" <[e-mail]>
Cc: [e-mail], [e-mail]
Subject: RE: Initial comments on SCVP
Date: Tue, 6 Jul 1999 10:32:50 -0400 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2448.0)
Content-Type: text/plain
Precedence: bulk
List-Archive: http://www.imc.org/ietf-pkix/mail-archive/
List-Unsubscribe: mailto:[e-mail]?body=unsubscribe
X-UIDL: 506ae84717a294d6bec85c3130624519

Hi Michael,

> ----------
> From: 	[e-mail][SMTP:[e-mail]]
> Sent: 	Tuesday, July 06, 1999 2:24 AM
> To: 	[e-mail]; [e-mail]
> Subject: 	RE: Initial comments on SCVP
> 
> OCSP, SCVP, and now DCS. 
 
Actually, if memory serves me correctly, this should be, "DCS, OCSP, and now
SCVP."  :-)

> It appears that there is more commonality between
> the various protocol's goals, then there is difference. 
 
Yes; this is the problem.

> Even the authors of
> the drafts are apparently perplexed when trying to substantiate the work
> and
> to outline the distinction of one protocol from the others. Writing a
> [rough
> cut of a] road map would be a nightmare, I'm imagining. Or could it be a
> good, probably even a necessary thing to do at this stage, to see for
> ourselves where we are heading? 
 
Unfortunately, the PKIX roadmap document gets its input (primarily) from the
drafts themselves and from the authors of those drafts.  Thus, if the
authors appear perplexed to the rest of the group then it's not obvious that
a roadmap document could clear things up.

We should certainly continue discussion on this list, but I have a feeling
that face-to-face, real-time discussions will go some distance in resolving
this.  Should be a lively meeting next week!

Carlisle.

P.S., Al's note just arrived in my inbox.  I tend to prefer the
smaller-number-of-quite-general-protocols approach (which is why I've been
involved with CMP (originally intended to do every aspect of cert.
management) and with DCS (originally intended to do everything that TSP,
OCSP, and SCVP are trying to do, plus more)).  However, I certainly
recognize the merits of the many-many-simple-protocols approach for some
specialized or restricted environments.

I agree with Al.  The group should try to consciously choose a direction
(though perhaps it has subconsciously already chosen, since these simpler
protocols are getting proposed, reviewed, and progressed...).



Received: from localhost (daemon@localhost) by mail.proper.com (8.8.8/8.8.5) with SMTP id HAA16059; Tue, 6 Jul 1999 07:09:39 -0700 (PDT)
Received: by mail.imc.org (bulk_mailer v1.12); Tue, 6 Jul 1999 07:09:27 -0700
Received: from magenta.omnisig.com (magenta.omnisig.com [207.107.11.7]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id HAA16035 for <[e-mail]>; Tue, 6 Jul 1999 07:09:26 -0700 (PDT)
Received: from netmail.home.com ([172.16.6.249]) by magenta.omnisig.com (8.8.7/8.8.5) with ESMTP id LAA28681; Tue, 6 Jul 1999 11:09:11 -0400 (EDT)
Message-ID: <[e-mail]>
Date: Tue, 06 Jul 1999 10:09:17 -0400
From: Al Arsenault <[e-mail]>
X-Mailer: Mozilla 4.5 [en] (Win98; I)
X-Accept-Language: en
MIME-Version: 1.0
To: [e-mail]
CC: [e-mail], [e-mail]
Subject: Re: Initial comments on SCVP
References: <[e-mail]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Precedence: bulk
List-Archive: http://www.imc.org/ietf-pkix/mail-archive/
List-Unsubscribe: mailto:[e-mail]?body=unsubscribe
X-UIDL: 3f279245fa351797cc575ca9f729f826

[e-mail] wrote:

> OCSP, SCVP, and now DCS. It appears that there is more commonality between
> the various protocol's goals, then there is difference. Even the authors of
> the drafts are apparently perplexed when trying to substantiate the work and
> to outline the distinction of one protocol from the others. Writing a [rough
> cut of a] road map would be a nightmare, I'm imagining. Or could it be a
> good, probably even a necessary thing to do at this stage, to see for
> ourselves where we are heading?

Actually, stuff like this (CRS/CMC, CMP, etc.) was what led to the initial cut
at a PKIX roadmap in the first place.  Some of us were tired and frustrated at
having to explain what all the alphabet soup in PKIX was in the first place.

Right now, it seems like we're adopting a "got a problem, get a protocol"
approach.  That is:

    - if you want to communicate between an end-entity and a CA/RA, use CMP
    - if you want to do that using CMS formats, use CMC
    - if you want proof that bits existed at a certain time, use Timestamp
    - if you want proof that bits existed at a certain time, AND that they
possessed certain qualities, use DCS
    - if you don't want to process CRLs yourself, but want to know if a
certificate is valid at a given time, use OCSP
    - if you want to have a server do most of the PKI stuff, and let "thin
clients" just ask servers for the answers, use SCVP
    - ad infinitum, ad nauseum

The problem to me is that each time we introduce a new protocol, we introduce
new overhead, much of which is going to be redundant.

So, the question I ask is, does this working group believe that the right
approach should be:

    (a) continue along the current path of building a "large" number of "simple"
protocols; or
    (b) redesign the architecture somewhat so that there is a small number of
protocols, with options and extensions to handle all of the different services.

To me, the advantage to (a) is that it lets designers have lots of flexibility
in putting together their own PKI structures.  If I don't want OCSP, I leave it
out completely.  If I have a lightweight client, SCVP may be the only protocol
it needs; everything else can be off-loaded.  If I just want timestamp services,
I implement Timestamp and ignore DCS.  et cetera, et cetera.

The disadvantage, though, is that for somebody who's going to do a lot of the
protocols in a "heavyweight" PKI, there's a lot of redundancy.  If I have DCS,
what does Timestamp truly buy me - and is this something that couldn't be better
handled by a slight modification to DCS?  Similarly, if I do SCVP, what does
OCSP buy me?  Would I be better served by defining SCVP to have a mandatory part
that's the moral equivalent of OCSP, with extensions to handle the rest of the
stuff?

Similarly, the disadvantage to (b) is that, if we're not careful, we're going to
force somebody with only a small subset of "the PKI problem" to implement a
large protocol with lots of overhead, potentially causing them to drop out of
the PKIX arena altogether.  The advantage is that my gut feeling tells me we've
got a better chance of getting an interoperable PKI with a small number of
protocols that everybody implements.  (It's bad enough now listening to vendors
pitching me "we implement PKIX", and having to go through exactly which parts of
PKIX they mean, and whether that has a snowball's chance in the Sahara of
actually interoperating with the stuff I've already got.  The problem is going
to grow exponentially very soon, with all the additional protocols we keep
defining.)

So - I'm soliciting feedback from the group on  this issue.  The resolution has
already been reached for CMP vs CMC (approve them both and let the market
decide), and to an extent for OCSP (its scope was tightly constrained to be
certificate status, rightly or wrongly).  But, I don't think we're that far
along with any of the other protocols, and I'd really like to get a sense for
the group's views now, while there's still a chance to do something about it.

We'll put whatever the "right" answer is in the Roadmap, and figure out how to
say it correctly.  Sean did an outstanding job putting together draft -02 of the
Roadmap (I'm afraid I haven't been much help lately :-).  However, it's getting
close to time to advance this turkey to informational RFC (most likely, after
CMC has advanced to Proposed Standard).  So, the sooner decisions can be made
about "approach" the better.

                        Al Arsenault

-- this represents my personal opinion, and may or may not represent the
opinions of my employer, or of any other organization with which I have a
relationship





Received: from localhost (daemon@localhost) by mail.proper.com (8.8.8/8.8.5) with SMTP id WAA25370; Mon, 5 Jul 1999 22:59:05 -0700 (PDT)
Received: by mail.imc.org (bulk_mailer v1.12); Mon, 5 Jul 1999 22:58:03 -0700
Received: from ns1.dmz.valicert.com (ns1.valicert.com [63.65.221.10]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id WAA25149 for <[e-mail]>; Mon, 5 Jul 1999 22:58:02 -0700 (PDT)
Received: from ns1.serverfarm.valicert.com (corporate-gw.valicert.com [63.65.221.2]) by ns1.dmz.valicert.com (8.9.2/8.9.2) with ESMTP id WAA18159 for <[e-mail]>; Mon, 5 Jul 1999 22:56:46 -0700 (PDT)
Received: from rhone (dhcp-3-128.engineering.valicert.com [192.168.3.128] (may be forged)) by ns1.serverfarm.valicert.com (8.9.2/8.9.2) with SMTP id WAA26796 for <[e-mail]>; Mon, 5 Jul 1999 22:58:02 -0700 (PDT)
From: "Ambarish Malpani" <[e-mail]>
To: <[e-mail]>
Subject: RE: Initial comments on SCVP
Date: Mon, 5 Jul 1999 23:00:58 -0700
Message-ID: <005a01bec774$eb872930$[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
X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3
In-Reply-To: <[e-mail]>
Importance: Normal
Precedence: bulk
List-Archive: http://www.imc.org/ietf-pkix/mail-archive/
List-Unsubscribe: mailto:[e-mail]?body=unsubscribe
X-UIDL: 5301c72f5e6ce7ad2cd5a5f7a21dc9a9

Hi Mike,
    Thanks for taking the time to read the draft and compose these
comments. Since I am on both the OCSP and SCVP drafts, I think I
need to address them.

I actually see OCSP and SCVP addressing pretty different needs and
most probably pretty different communities of users.

OCSP essentially deals with the status of a certificate (and
potentially, other attributes of the holder/account associated with
that certificate). It is a mechanism for a client to ask for
information about a particular cert.

SCVP is mainly directed at making it easier for applications to use
PKI. Yes, it does deal with cert status, but it also deals with
issues like chain building, policy management etc. The main goals
are:
1. To make it easier for an application to use PKI
2. To make it easier for an organization to deploy PKI (by allowing
them to control policy etc.)

I think of OCSP as being an infrastructure protocol, to help provide
up-to-date status information - something that is run as an underlying
mechanism. I see SCVP as something that is used between a low end client
and a server it trusts, to offload the complicated parts of PKIX.

Hope this clarifies the issue.

More comments inline:


> -----Original Message-----
> From: Michael Myers [mailto:[e-mail]]
> Sent: Friday, July 02, 1999 6:28 PM
> To: [e-mail]
> Subject: Initial comments on SCVP
> 
> 
> Ambarish, Paul:
> 
> A very timely draft.

Thank you.

> 
> I've got to wonder though if we need yet another online 
> protocol or if we'd
> be doing our job better by building on our prior work. Both 
> OCSP or DCS have
> achieved a fairly stable level of maturity in the IETF.  In 
> fact, OCSP is
> now RFC 2560.  Upon reviewing the proposal, it seems to me that either
> provide a more stable platform for addressing these requirements.
> 
> OCSP was in its inception aimed at solving the more general 
> certificate
> validation problem. At the request of several very large 
> stakeholders who
> intended to rely on OCSP for Internet-based financial 
> transactions, we chose
> to first deal with the revocation problem, recognizing that via
> extensibility we were architecting a more general certificate 
> validation
> framework.

Mike, I thought it was reasonably clear from previous OCSP debates
that OCSP just returns the status of the certificate(s) asked for -
it doesn't do any additional chain building or chain validation (I
think I remember some explicit comments about that not being part
of OCSP).


> 
> Let's build on that, especially since it was the original 
> intent of OCSP to
> do so.  With the investment people are today making in 
> extensible OCSP, that
> only makes sense.

A lot of SCVP was designed after seeing how people were trying to
use OCSP - there are applications where OCSP makes sense. There
are others where SCVP works better.

> 
> It would relatively straightforward to publish an extensions 
> document. Doing
> so, we would have the advantage of incrementally building on 
> a existing RFC
> specifically intended to be extended in this fashion, for 
> specifically this
> need, rather that totally revinent what that RFC has already 
> established.

Not at all - OCSP fundamentally assumes that you as a client
will to do all validation yourself and are only using OCSP to
query the status of a certificate. It was never meant to work
in an environment where you had no idea of the chain being used
to validate the certificate - remember we use the issuer and
serial number to identify the certificate - not the certificate
itself.

> 
> Otherwise, what's the advantage of replacing a protocol that 
> has already
> been ratified by the working group and promoted to proposed 
> standard status?
> Especially since the requirements being met by the proposed 
> protocol are
> already met or are intended to be met by extensions to 
> RFC2560?  I just
> don't see a compelling case being made for so radical a revision.
> 
> I'm compelled to ask the group at large if others share these 
> sentiments.
> Perhaps I missed something.
> 
> Mike
> 
> 

Regards,
Ambarish


Received: from localhost (daemon@localhost) by mail.proper.com (8.8.8/8.8.5) with SMTP id XAA27933; Mon, 5 Jul 1999 23:25:10 -0700 (PDT)
Received: by mail.imc.org (bulk_mailer v1.12); Mon, 5 Jul 1999 23:25:08 -0700
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 XAA27899 for <[e-mail]>; Mon, 5 Jul 1999 23:25:04 -0700 (PDT)
From: [e-mail]
Received: from sydneymail1.baltimore.com.au (sydneymail1.jp.zergo.com.au [192.168.71.5]) by stargate.zergo.com.au (8.9.1/8.8.7) with ESMTP id QAA04916; Tue, 6 Jul 1999 16:27:34 +1000
Received: by sydneymail1.jp.zergo.com.au with Internet Mail Service (5.5.2448.0) id <3LT8AHMM>; Tue, 6 Jul 1999 16:24:05 +1000
Message-ID: <[e-mail]>
To: [e-mail], [e-mail]
Subject: RE: Initial comments on SCVP
Date: Tue, 6 Jul 1999 16:24:04 +1000 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2448.0)
Content-Type: text/plain; charset="iso-8859-1"
Precedence: bulk
List-Archive: http://www.imc.org/ietf-pkix/mail-archive/
List-Unsubscribe: mailto:[e-mail]?body=unsubscribe
X-UIDL: 7f8920485ee6537fc67a88ad42e32220

OCSP, SCVP, and now DCS. It appears that there is more commonality between
the various protocol's goals, then there is difference. Even the authors of
the drafts are apparently perplexed when trying to substantiate the work and
to outline the distinction of one protocol from the others. Writing a [rough
cut of a] road map would be a nightmare, I'm imagining. Or could it be a
good, probably even a necessary thing to do at this stage, to see for
ourselves where we are heading? 

It would also help other people, from the non-directly PKI-related problem
areas, to realize where we are and to start contributing to the group.

MichaelZ

-----Original Message-----
From: Ambarish Malpani [mailto:[e-mail]]
Sent: Tuesday, July 06, 1999 4:01 PM
To: [e-mail]
Subject: RE: Initial comments on SCVP




Hi Mike,
    Thanks for taking the time to read the draft and compose these
comments. Since I am on both the OCSP and SCVP drafts, I think I
need to address them.

I actually see OCSP and SCVP addressing pretty different needs and
most probably pretty different communities of users.

OCSP essentially deals with the status of a certificate (and
potentially, other attributes of the holder/account associated with
that certificate). It is a mechanism for a client to ask for
information about a particular cert.

SCVP is mainly directed at making it easier for applications to use
PKI. Yes, it does deal with cert status, but it also deals with
issues like chain building, policy management etc. The main goals
are:
1. To make it easier for an application to use PKI
2. To make it easier for an organization to deploy PKI (by allowing
them to control policy etc.)

I think of OCSP as being an infrastructure protocol, to help provide
up-to-date status information - something that is run as an underlying
mechanism. I see SCVP as something that is used between a low end client
and a server it trusts, to offload the complicated parts of PKIX.

Hope this clarifies the issue.

More comments inline:


> -----Original Message-----
> From: Michael Myers [mailto:[e-mail]]
> Sent: Friday, July 02, 1999 6:28 PM
> To: [e-mail]
> Subject: Initial comments on SCVP
> 
> 
> Ambarish, Paul:
> 
> A very timely draft.

Thank you.

> 
> I've got to wonder though if we need yet another online 
> protocol or if we'd
> be doing our job better by building on our prior work. Both 
> OCSP or DCS have
> achieved a fairly stable level of maturity in the IETF.  In 
> fact, OCSP is
> now RFC 2560.  Upon reviewing the proposal, it seems to me that either
> provide a more stable platform for addressing these requirements.
> 
> OCSP was in its inception aimed at solving the more general 
> certificate
> validation problem. At the request of several very large 
> stakeholders who
> intended to rely on OCSP for Internet-based financial 
> transactions, we chose
> to first deal with the revocation problem, recognizing that via
> extensibility we were architecting a more general certificate 
> validation
> framework.

Mike, I thought it was reasonably clear from previous OCSP debates
that OCSP just returns the status of the certificate(s) asked for -
it doesn't do any additional chain building or chain validation (I
think I remember some explicit comments about that not being part
of OCSP).


> 
> Let's build on that, especially since it was the original 
> intent of OCSP to
> do so.  With the investment people are today making in 
> extensible OCSP, that
> only makes sense.

A lot of SCVP was designed after seeing how people were trying to
use OCSP - there are applications where OCSP makes sense. There
are others where SCVP works better.

> 
> It would relatively straightforward to publish an extensions 
> document. Doing
> so, we would have the advantage of incrementally building on 
> a existing RFC
> specifically intended to be extended in this fashion, for 
> specifically this
> need, rather that totally revinent what that RFC has already 
> established.

Not at all - OCSP fundamentally assumes that you as a client
will to do all validation yourself and are only using OCSP to
query the status of a certificate. It was never meant to work
in an environment where you had no idea of the chain being used
to validate the certificate - remember we use the issuer and
serial number to identify the certificate - not the certificate
itself.

> 
> Otherwise, what's the advantage of replacing a protocol that 
> has already
> been ratified by the working group and promoted to proposed 
> standard status?
> Especially since the requirements being met by the proposed 
> protocol are
> already met or are intended to be met by extensions to 
> RFC2560?  I just
> don't see a compelling case being made for so radical a revision.
> 
> I'm compelled to ask the group at large if others share these 
> sentiments.
> Perhaps I missed something.
> 
> Mike
> 
> 

Regards,
Ambarish


Received: from localhost (daemon@localhost) by mail.proper.com (8.8.8/8.8.5) with SMTP id DAA10115; Mon, 5 Jul 1999 03:59:49 -0700 (PDT)
Received: by mail.imc.org (bulk_mailer v1.12); Mon, 5 Jul 1999 03:59:41 -0700
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 DAA10091 for <[e-mail]>; Mon, 5 Jul 1999 03:59:35 -0700 (PDT)
Received: from mail0.sse.ie (actually localhost) by mail0.sse.ie; Mon, 5 Jul 1999 11:58:23 +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 LAA12576; Mon, 5 Jul 1999 11:58:21 +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 LAA29486; Mon, 5 Jul 1999 11:58:03 +0100 (BST)
Message-Id: <[e-mail]>
X-Mailer: exmh version 1.6.9 8/22/96
To: Denis Pinkas <[e-mail]>
cc: IETF-PXIX <[e-mail]>, [e-mail]
Subject: Re: Attribute Certificates 
In-reply-to: Your message of "Mon, 05 Jul 1999 10:27:39 +0200." <[e-mail]> 
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Date: Mon, 05 Jul 1999 11:58:03 +0100
From: Stephen Farrell <[e-mail]>
Precedence: bulk
List-Archive: http://www.imc.org/ietf-pkix/mail-archive/
List-Unsubscribe: mailto:[e-mail]?body=unsubscribe
X-UIDL: 0e4b92fe70a8ce00b75425f9b3ec6f29

Denis,

Thanks for the detailed comments (and for not getting back
into attribute encryption:-)

> First of all, I welcome this document in general because the
> support of Attribute Certificate is becoming very important.
> However, I have several reservations on its content, because the
> current specification is too large and too complex to implement.

FWIW, we have implemented the AC issuer and interop'd with a third
party AC acquirer/verifier without much trouble, so I'd disagree 
about the complexity (but then I would, wouldn't I:-)

> 1. On page 3, there is statement saying : "A major benefit of the
> "pull" model is that it can be implemented without changes to the
> client and client/server protocol". There is a major drawback to
> do so that should be mentioned in the text: The "pull" model,
> without *any* change to the client and client/server protocol
> does not allow to fulfil the principle of least privilege in that
> sense that the client cannot restrict the set of privileges that
> will be used by the server to validate the access. In some cases,
> this fact may rule out the support of the pull technique.

Fine, I'd prefer to add least privilege as a benefit of the
"push" model though, how about adding something like the 
following to the end of the "In some environments..." para:

"In addition the push model provides better support for least
privilege as a client may be able to select a "minimal" AC
thus not exposing its full privilege to servers."

> 2. Could we simply rename "AC issuer": "Attribute Authority"
> since the acronym AA is used later on ? :-)

I don't think I've a problem with this - I'll check 
the text in the next revision.

> 3. On page 5. The text says "The following are the requirements
> that the "full" profile defined here meets." The basic question
> is how many profiles are being defined there. I would expect the
> definition of a basic profile (yet to be defined) and of various
> additions to the basic profile (like the support of targeting or
> proxying) that form other profiles. This topic needs to be
> discussed at the Oslo meeting.

I agree that this warrants dicsussion, lets see where we get to
in Oslo. 

(*) You've made a number of comments like "this should be earlier 
in the document" related to profiles. Maybe its worth saying how
we came up with the structure - basically we presented requirements
in section 3, sections 4 - 7 describe fields, ASN.1 and processing
stuff and section 8 describes conformance (basic & proxy-enabled
profiles). I guess we should at least have more text up front
explaining this, though of course, it might change depending
on the general "profiles" discussion.

> 4. I would recommend the use of baseCertificateId to link the
> attribute certificate to a public key certificate and warn the
> reader about the danger to use entityName and thus while still
> allowing its use (?) deprecate its use, because it is less
> secure. This may also be a good topic to cover in the "security
> considerations" section.

I've no problem with that, (in cases where a PKC has been used for
authentication!), though I believe that some other people will have.

> 5. In the same way I would recommend the use of baseCertificateID
> to identify the certificate of the AA instead of the issuerName
> that should be deprecated. To this respect I do not agree with
> the text in section 4.3.3. that says the contrary (" ACs
> conforming to this profile MUST use the issuerName choice which
> MUST contain one and only one GeneralName which MUST contain its
> non-null value in the directoryName field "). The argument of
> dependency upon the PKI is not a really valid argument to support
> the choice that is made there: security should come first.

I'd prefer not to make this change, but if that's the consensus...
(Amongst other reasons, I quite like the model where a "foreign" AC 
issuer's public key is recertified by a "local" CA.)

> 6. The use of issuerUID currently optional should be recommended
> because it provides better protection in case of a CA key
> compromise. This may also be a good topic to cover in the
> "security considerations" section.

Hmm... I don't think so - the text says that issuerUID must only 
be present if it is also present in the corresponding
PKC and 2459 says UniqueIdentifiers "SHOULD NOT" be present (cf
2459, section 4.1.2.8). How would you handle a case where the 
issuerUID was present in the AC but not in the PKC?

> 7. In section 4.4.1 there is a question about the need to support
> restrictions. Restrictions are very difficult to support in a
> distributed environment when the push model is used, because
> there is no guaranty that all the restrictions will really be
> included in the AC. If all were included, in some cases, some
> "unwanted" information would be released to target that do not
> have the need to know about these restrictions. The simplest
> solution is  not to support restrictions.

I pretty much agree - we left them in there to see if anyone
would shout "I need these", so far, no-one has.

> 8. On page 13. There is a section 4.4.3. on AC Targeting and
> Proxying. Since I believe that Targeting and Proxying will not be
> in the base profile, moving this section later would be more
> adequate.

See (*) above 

> 9. Targeting (i.e. targets field) is nice and easy to understand
> when used in a connection oriented mode. However, I have a
> reservation with the proxy case (proxies field): how is it really
> possible to restrict the proxy to the targets which are of the
> same "proxy sets" as itself ? How is this verified on the next
> leg ? I got the impression that we could support targeting *for a
> connection mode* but the support of proxies is more complicated
> and the overall model should be clarified before considering
> inclusion of proxies and even delegates in this document.

Enforcement of targeting/proxying depends on the AC verifiers.
Properly using the proxies field means that the protocol used
to carry (or reference) the AC must also provide proof about the
connections which preceeded the current connection. The form
of such proof is out of scope here, but I guess we could provide
some more text.

> 10.On page 16. There is a section 4.5 on Attribute Types. Since I
> believe that Attribute Types (with the exception of 4.5.1 and
> 4.5.7) are part of the base profile, moving this section earlier
> would be more adequate.

See (*) above

> 11. On page 21. There is a section 4.6.1. on AAControls
> addressing the question: Is this AC issuer trusted to issue ACs
> containing this attribute"? The question itself is fine, however
> the answer to the question might not be adequate. It is hard to
> answer that question outside the context of use and maybe it is
> where the difficulty lies. 

Fair point, it is hard.

> If this question is to be answered in
> a authorization scheme using ACLs, then the answer lies in the
> ACL itself, rather than an extension in the certificate as
> proposed. It is then up to the ACL manager to state which
> attributes from an AA, if ever presented, will be acceptable. 

But if such an ACL scheme is not in use? 

> The
> proposed solution is first very complicated and second addresses
> the problem from the wrong side: a CA cannot know in advance
> which attributes a given AA is really able to generate. That
> section should be deleted.

I disagee - in many cases a CA *can* know in advance which 
attributes are allowed (or disallowed) for an AC issuer.
However, I'm wide open to someone providing a better
solution. (One thing we considered but dropped was to
regard the OIDs in the AAControls as being the top of
an arc - so that 1.2.3 in the permittedAttrs field
would also cover an attribute type of 1.2.3.4.5.6.7 
and so on. Can't recall exactly why we dropped this.)

I think we do need some solution since just assuming that
the question is answered by AC verifier configuration (e.g.
via static ACLs) isn't sufficient.

> 12. On page 21. There is a section 5. on Attribute Certificate
> Validation. The rules that are mentioned there do not allow to
> verify an AC that was issued years before and to test its
> validity at the time it was issued. This is however a very
> important case. The rules for testing the validity of an AC
> should thus not be restricted to real time use in a connection
> mode environment. The item 3 about the time of evaluation seems
> to mean the current time which is not correct. What is the time
> of evaluation should be clarified: it should be the time for
> which the validation is being requested. The item 1should be
> moved in the first position so that it can apply to the current
> item 1 where the validity of the certification path must be
> checked at that time rather than the current time.

I can add some text defining the "time of evaluation" better.

> 13. aaControls extensions are mandated. On the contrary, it is
> not believed (see top of page 23) that any aaControls extensions
> should ever be used. Thus the mandatory clauses 1) 2) and 3) from
> the additional certification path checks should all be deleted.

No (unless we completely delete aaControls). The additional 
certification path checks are only needed if the AC issuer 
is not directly trusted as an AC issuer. Maybe we should say 
more about this in point 2.

> 14. Some checks are missing in particular when a target field is
> present.

Isn't the reference to 4.4.3 sufficient? If not, why not?

> 15. In general, the description of the various checks should
> follow the description of the various profiles, including the
> base profile. This section 5 should be re-written to address
> these concerns.

See (*) above

> 16. The section 8 on conformance should define more profiles. The
> basic profile should only mandate the support of attributes
> linked to a certificate. All other features should be part of
> other profiles, like the targeting of a certificate. These other
> profiles should be defined. This means that the title of the
> document should be changed from "Attribute Certificate profile
> for authorization " to "Attribute Certificate profiles for
> authorization".

See (*) above

Regards,
Stephen.









Received: from localhost (daemon@localhost) by mail.proper.com (8.8.8/8.8.5) with SMTP id SAA10405; Sun, 4 Jul 1999 18:13:35 -0700 (PDT)
Received: by mail.imc.org (bulk_mailer v1.12); Sun, 4 Jul 1999 18:12:17 -0700
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 SAA09994; Sun, 4 Jul 1999 18:12:02 -0700 (PDT)
From: [e-mail]
Received: from sydneymail1.baltimore.com.au (sydneymail1.jp.zergo.com.au [192.168.71.5]) by stargate.zergo.com.au (8.9.1/8.8.7) with ESMTP id LAA28147; Mon, 5 Jul 1999 11:14:02 +1000
Received: by sydneymail1.jp.zergo.com.au with Internet Mail Service (5.5.2448.0) id <3B34Y5H7>; Mon, 5 Jul 1999 11:10:55 +1000
Message-ID: <[e-mail]>
To: [e-mail], [e-mail], [e-mail]
Subject: RE: I-D ACTION:draft-ietf-pkix-scvp-00.txt
Date: Mon, 5 Jul 1999 11:10:54 +1000 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2448.0)
Content-Type: text/plain; charset="iso-8859-1"
Precedence: bulk
List-Archive: http://www.imc.org/ietf-pkix/mail-archive/
List-Unsubscribe: mailto:[e-mail]?body=unsubscribe
X-UIDL: ac1a2701a8ae9f55780831d272fadcee

I knew you would turn up, Anders. A big voice from small devices :)

1.What makes XML any better then ASN in PKI world?
2.Any more solid proposals/ideas about XML usage? 
3.Any known implementations?

Looking forward...

Regards
MichaelZ


-----Original Message-----
From: Anders Rundgren [mailto:[e-mail]]
Sent: Saturday, July 03, 1999 7:04 PM
To: [e-mail]; [e-mail]; [e-mail]
Subject: Re: I-D ACTION:draft-ietf-pkix-scvp-00.txt


Hi Michel,
Here are some comments on the tiny format

>Since the discussion started, have we received any 'at last' greetings from
>small device manufactures? They should be the first to reply and the
>majority among the participants. Where are you, guys??? Aren't you that
much
>concerned about complexity of handling ASN.1?

No, particularly if one looks a couple a years ahead.
Only within certain places like in static data in smart-cards ASN.1 parsing
is
a problem and in these places ASN.1 will be supplemented by ASN.1 opaque
objects
containing hard-code binary data.

<snip>
>Otherwise, I'm not sure we are talking the reality here, proposing a
>'simple' alternative to ASN.

XML is my candidate.  Universal, hyped and human-readable.  It is not a
compact
format though but that is not such a big problem anymore. 

Regards
Anders Rundgren

http://www.mobilephones-tng.com



Received: from localhost (daemon@localhost) by mail.proper.com (8.8.8/8.8.5) with SMTP id BAA05682; Mon, 5 Jul 1999 01:27:17 -0700 (PDT)
Received: by mail.imc.org (bulk_mailer v1.12); Mon, 5 Jul 1999 01:27:13 -0700
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 BAA05660 for <[e-mail]>; Mon, 5 Jul 1999 01:27:12 -0700 (PDT)
Received: from bull.net (frcls6118.frcl.bull.fr [129.182.109.213]) by clbull.frcl.bull.fr (8.9.1a/8.9.1) with ESMTP id KAA09888 for <[e-mail]>; Mon, 5 Jul 1999 10:24:44 +0200
Message-ID: <[e-mail]>
Date: Mon, 05 Jul 1999 10:27:39 +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: Attribute Certificates
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit
Precedence: bulk
List-Archive: http://www.imc.org/ietf-pkix/mail-archive/
List-Unsubscribe: mailto:[e-mail]?body=unsubscribe
X-UIDL: e1e1bf7ced0282bb9d7f2355e90924cb

Here are my comments on the Attribute Certificate profile for
authorization (ac509prof-00.txt) - avoiding as much as possible
discussions on the encryption option until the Oslo meeting. :-|

First of all, I welcome this document in general because the
support of Attribute Certificate is becoming very important.
However, I have several reservations on its content, because the
current specification is too large and too complex to implement.
Starting "smaller", i.e. with a smaller set of functionality,
would be more adequate.

The following detailed comments follow the page numbering and are
not classified according to their importance.

1. On page 3, there is statement saying : "A major benefit of the
"pull" model is that it can be implemented without changes to the
client and client/server protocol". There is a major drawback to
do so that should be mentioned in the text: The "pull" model,
without *any* change to the client and client/server protocol
does not allow to fulfil the principle of least privilege in that
sense that the client cannot restrict the set of privileges that
will be used by the server to validate the access. In some cases,
this fact may rule out the support of the pull technique.

2. Could we simply rename "AC issuer": "Attribute Authority"
since the acronym AA is used later on ? :-)

3. On page 5. The text says "The following are the requirements
that the "full" profile defined here meets." The basic question
is how many profiles are being defined there. I would expect the
definition of a basic profile (yet to be defined) and of various
additions to the basic profile (like the support of targeting or
proxying) that form other profiles. This topic needs to be
discussed at the Oslo meeting.

4. I would recommend the use of baseCertificateId to link the
attribute certificate to a public key certificate and warn the
reader about the danger to use entityName and thus while still
allowing its use (?) deprecate its use, because it is less
secure. This may also be a good topic to cover in the "security
considerations" section.

5. In the same way I would recommend the use of baseCertificateID
to identify the certificate of the AA instead of the issuerName
that should be deprecated. To this respect I do not agree with
the text in section 4.3.3. that says the contrary (" ACs
conforming to this profile MUST use the issuerName choice which
MUST contain one and only one GeneralName which MUST contain its
non-null value in the directoryName field "). The argument of
dependency upon the PKI is not a really valid argument to support
the choice that is made there: security should come first.

6. The use of issuerUID currently optional should be recommended
because it provides better protection in case of a CA key
compromise. This may also be a good topic to cover in the
"security considerations" section.

7. In section 4.4.1 there is a question about the need to support
restrictions. Restrictions are very difficult to support in a
distributed environment when the push model is used, because
there is no guaranty that all the restrictions will really be
included in the AC. If all were included, in some cases, some
"unwanted" information would be released to target that do not
have the need to know about these restrictions. The simplest
solution is  not to support restrictions.

8. On page 13. There is a section 4.4.3. on AC Targeting and
Proxying. Since I believe that Targeting and Proxying will not be
in the base profile, moving this section later would be more
adequate.

9. Targeting (i.e. targets field) is nice and easy to understand
when used in a connection oriented mode. However, I have a
reservation with the proxy case (proxies field): how is it really
possible to restrict the proxy to the targets which are of the
same "proxy sets" as itself ? How is this verified on the next
leg ? I got the impression that we could support targeting *for a
connection mode* but the support of proxies is more complicated
and the overall model should be clarified before considering
inclusion of proxies and even delegates in this document.

10.On page 16. There is a section 4.5 on Attribute Types. Since I
believe that Attribute Types (with the exception of 4.5.1 and
4.5.7) are part of the base profile, moving this section earlier
would be more adequate.

11. On page 21. There is a section 4.6.1. on AAControls
addressing the question: Is this AC issuer trusted to issue ACs
containing this attribute"? The question itself is fine, however
the answer to the question might not be adequate. It is hard to
answer that question outside the context of use and maybe it is
where the difficulty lies. If this question is to be answered in
a authorization scheme using ACLs, then the answer lies in the
ACL itself, rather than an extension in the certificate as
proposed. It is then up to the ACL manager to state which
attributes from an AA, if ever presented, will be acceptable. The
proposed solution is first very complicated and second addresses
the problem from the wrong side: a CA cannot know in advance
which attributes a given AA is really able to generate. That
section should be deleted.

12. On page 21. There is a section 5. on Attribute Certificate
Validation. The rules that are mentioned there do not allow to
verify an AC that was issued years before and to test its
validity at the time it was issued. This is however a very
important case. The rules for testing the validity of an AC
should thus not be restricted to real time use in a connection
mode environment. The item 3 about the time of evaluation seems
to mean the current time which is not correct. What is the time
of evaluation should be clarified: it should be the time for
which the validation is being requested. The item 1should be
moved in the first position so that it can apply to the current
item 1 where the validity of the certification path must be
checked at that time rather than the current time.

13. aaControls extensions are mandated. On the contrary, it is
not believed (see top of page 23) that any aaControls extensions
should ever be used. Thus the mandatory clauses 1) 2) and 3) from
the additional certification path checks should all be deleted.

14. Some checks are missing in particular when a target field is
present.

15. In general, the description of the various checks should
follow the description of the various profiles, including the
base profile. This section 5 should be re-written to address
these concerns.

16. The section 8 on conformance should define more profiles. The
basic profile should only mandate the support of attributes
linked to a certificate. All other features should be part of
other profiles, like the targeting of a certificate. These other
profiles should be defined. This means that the title of the
document should be changed from "Attribute Certificate profile
for authorization " to "Attribute Certificate profiles for
authorization".

Denis






Received: from localhost (daemon@localhost) by mail.proper.com (8.8.8/8.8.5) with SMTP id BAA06005; Mon, 5 Jul 1999 01:39:15 -0700 (PDT)
Received: by mail.imc.org (bulk_mailer v1.12); Mon, 5 Jul 1999 01:39:14 -0700
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 BAA05983 for <[e-mail]>; Mon, 5 Jul 1999 01:39:12 -0700 (PDT)
Received: from bull.net (frcls6118.frcl.bull.fr [129.182.109.213]) by clbull.frcl.bull.fr (8.9.1a/8.9.1) with ESMTP id KAA15336; Mon, 5 Jul 1999 10:36:35 +0200
Message-ID: <[e-mail]>
Date: Mon, 05 Jul 1999 10:39:31 +0200
From: Denis Pinkas <[e-mail]>
Organization: Bull
X-Mailer: Mozilla 4.06 [fr] (Win95; I)
MIME-Version: 1.0
To: Ambarish Malpani <[e-mail]>
CC: [e-mail]
Subject: Re: I-D ACTION:draft-ietf-pkix-scvp-00.txt
References: <004101bec4d4$d4fddb70$[e-mail]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit
Precedence: bulk
List-Archive: http://www.imc.org/ietf-pkix/mail-archive/
List-Unsubscribe: mailto:[e-mail]?body=unsubscribe
X-UIDL: 71c6f6095743a9423cec11bd134cfb56

Ambarish wrote:

[text deleted]


> *Now*, can we continue with discussing the semantic of the
> protocol and whether those are useful/correct etc.?

Here are a few comments on the SCVP document.

1. I was expecting (and still I am !) the document to address the problem: "Was
that certificate valid at that time ?" However, currently it does not, because
there is no indication of date, such as ValidAt in the request so only the
current date can be used.

2. Validation can only occur according to strict rules. Two parameters may be
used to achieve this: TrustedRoots and UsageID. In the text (sections 3.14 and
3.15) there is no indication to know which is mandatory or optional. When
looking at the ASN1 both are OPTIONAL without any additional information. I
would think that one of them shall be present. Is this interpretation correct ?
However, it should be realized that using the TrustedRoots parameter makes a
"loose" validation that does not take into consideration policy constraints and
naming constraints at every node of the certification chain. The use of UsageID,
which should be renamed something like ValidationPolicy to better describe what
it is, allows more complex cases of validation. This also means that the
TypeOfCheck parameter (with the value zero) does not bear the right meaning: the
check is not necessarily a validation to a trusted root, but also a validation
according to a validation policy.

3. An individual Certificate to be validated may be accompanied not only with a
sequence of certificates (IntermediateCerts) but also by a sequence of
revocation information (CRLs and/or OCSP responses) that the (thin) client got
by some way, but is unable or unwilling to validate itself. A parameter like
RevocationInformation should be added.

4. The WantBack parameter allows to get back (item 2) "the certificate chain
used to validate the certificate". This is not sufficient. As another option it
should be possible to get back the RevocationInformation mentioned earlier so
that the client can get back not only the sequence of certificates but also a
sequence of revocation information (CRLs and/or OCSP responses).


Minor comments:

5. The TrustedRoots contained in the CertBundle are defined as a FullCert or a
CertID. In reality this is a self signed certificate. I have difficulties to
understand how it can be only a hash, without further information.

6. The IntermediateCerts contained in CertBundle may contains the FullCert or
the CertID. I have difficulties to understand why the CertID is only the hash of
the certificate and not the CA name + serial number + optionally the hash of the
certificate under query. If the hash of the Certificate under query is not
given, then it shall be returned in the response.

Finally :

7.One question is whether the problem that is attempted to be addressed should
be solved by an extension to OSCP, DCS or SCVP (i.e. this new document). There
has been very little discussion on DCS and a new version of that document has
been made available past the dead line (I have not looked at it). I will not
answer the question, but surely this is a matter for consideration.

8. Following the discussion about the tiny syntax, the fact that SNACC can be
used, seems to make the tiny syntax unnecessary. The use/definition of a reduced
set of ASN1 might be the solution.

Denis





Received: from localhost (daemon@localhost) by mail.proper.com (8.8.8/8.8.5) with SMTP id CAA06510; Mon, 5 Jul 1999 02:12:31 -0700 (PDT)
Received: by mail.imc.org (bulk_mailer v1.12); Mon, 5 Jul 1999 02:12:30 -0700
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 CAA06486 for <[e-mail]>; Mon, 5 Jul 1999 02:12:29 -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 LAA01572 for <[e-mail]>; Mon, 5 Jul 1999 11:12:55 +0200
Received: from HYDRA ([195.198.186.73]) by caesar.udac.se (8.7.3/NetworkC-1) with SMTP id LAA24028; Mon, 5 Jul 1999 11:12:51 +0200
Received: by HYDRA with Microsoft Mail id <01BEC6D6.FED0A460@HYDRA>; Mon, 5 Jul 1999 11:10:31 +0200
Message-ID: <01BEC6D6.FED0A460@HYDRA>
From: Anders Rundgren <[e-mail]>
To: "[e-mail]" <[e-mail]>, "[e-mail]" <[e-mail]>, "'[e-mail]'" <[e-mail]>
Subject: RE: I-D ACTION:draft-ietf-pkix-scvp-00.txt
Date: Mon, 5 Jul 1999 11:10:30 +0200
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Precedence: bulk
List-Archive: http://www.imc.org/ietf-pkix/mail-archive/
List-Unsubscribe: mailto:[e-mail]?body=unsubscribe
X-UIDL: 1c567b8da230b661ffaf8afe737a25b5

Michael,
>I knew you would turn up, Anders. A big voice from small devices :)

Thanx!

>1.What makes XML any better then ASN in PKI world?

Human-readable is one thing, another is the (still only anticipated) use
of XML for business documents like MSFTs Biz-Talk. The net effect could
be that for new systems XML can not only complement ASN.1,
but also replace EDI and various proprietary message formats.
XML is also the foundation for the WAP micro-browser that will be featured in the next-
generation of mobile-phones. Digital signing and XML seems like a
good mix as the combination of computer-readable and human-readable data
is badly needed for PKI-based e-commerce.

>2.Any more solid proposals/ideas about XML usage? 

I am sure that there are quite a few things going on in this field and I am personally
working with a design that that will use XML together with my "Thin PKI" approach to
create dynamical attributes replacing attribute certificates in businss-2-business e-commerce.

Actually I think that PKIX ACs and QCs could benefit from having the attribute part expressed in
XML and only use an ASN.1 wrapper to get both X509-compatibility and ease of 
decoding.

>3.Any known implementations?

Not that I know of but lots of things are probably in the works.

Regards
Anders Rundgren
http://www.mobilephones-tng.com




Received: from localhost (daemon@localhost) by mail.proper.com (8.8.8/8.8.5) with SMTP id NAA12348; Sat, 3 Jul 1999 13:20:15 -0700 (PDT)
Received: by mail.imc.org (bulk_mailer v1.12); Sat, 3 Jul 1999 13:19:30 -0700
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 NAA12322 for <[e-mail]>; Sat, 3 Jul 1999 13:19:29 -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 WAA03243 for <[e-mail]>; Sat, 3 Jul 1999 22:23:21 +0200
Received: from mega (t4o69p89.telia.com [62.20.145.209]) by caesar.udac.se (8.7.3/NetworkC-1) with SMTP id WAA87497; Sat, 3 Jul 1999 22:22:53 +0200
Message-ID: <001c01bec599$e5ea5380$[e-mail]>
From: "Anders Rundgren" <[e-mail]>
To: <[e-mail]>, "Petra Gloeckner" <[e-mail]>
Cc: "PKIX-List" <[e-mail]>, "Stefan Santesson" <[e-mail]>
Subject: Re: Use of localityName attribute
Date: Sat, 3 Jul 1999 22:20:37 +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.3110.5
X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by mail.proper.com id NAA12323
Precedence: bulk
List-Archive: http://www.imc.org/ietf-pkix/mail-archive/
List-Unsubscribe: mailto:[e-mail]?body=unsubscribe
X-UIDL: e236533069ddc18ea1e6cafc089d576e

David,
The answers you got from the QC-editors signifiy what I consider the
fundamentally flawed model that QC is based on:

#1:
To begin with, miss Glöckner's answer was signed with a QC-like certificate
which was issued by her employer (?) and was of course not trusted
by my mail-program's root-certficates which it told me in many ways.
This is where QCs will fail to meet the needs of the market and will
make PKI a word associated with offensive amounts of tax-payers money
spent in vain.  I.e. QCs of that kind have no use outside a very limited domain
and definitely not in a public area.


#2:
In many implementations (like yours) both an organization and
an individual within that organization must be unambiguously defined.

As it is already a hard task to uniquely identify an organization, it deserves
a certificate of its own.  And to build identity on local addresses is a bad idea
as for instance my own company just moved a couple of blocks and we
are still known as the Swedish company "Jaybis AB" with registration
number 564567-1267.  If you need to know the address of an organization
you should look in a public registry (assuming it is legally registered) and not
in a certificate.

#3:
A real problem with QCs is when they also provide information like profession
and roles because then the need for diversion will make it virtually impossible
to create interoperability and TTP support.

Solutions?
TTPs should certify organizations and individuals separately.  Organizations
themselves should publish additional information about employees in formats
and ways that are adapted and agreed upon by the business segment they
operate within.

QCs do not eliminate that possibility but as indicated by many pre-QC
projects, it is obviously very tempting to put a lot of stuff in a QC that will in the end
render it less useful.

Regards
Anders Rundgren

>> I need to request a change to the qualified certificate draft to allow
>> the use of the localityName attribute to be used to unambiguously
>> identify a subject and issuer in a DN. The UK National Health
>> Service Standard for Directory Services requires the use of locality
>> name to unambiguously identify different organisational units within
>> the NHS. For example, there are literally dozens of St Mary's
>> Hospitals within the UK NHS, so that O and OU are insufficient as
>> differentiators. Consequently localityName, based on the UK Post
>> Office defined localities, is used to differentiate between them (we
>> do not use the full postal address as this is too cumbersome.)
>> 
>> As the QC draft stands at the moment, (as I read it), the use of
>> localityName as currently defined by the NHS would not be allowed
>> as a differentiator.
>> 
>> The offending sections are:
>> 
>> 3.1.1 Issuer -  allows for state or province name but not for
>> localityName. We request that localityName be added to this section.
>> 
>> 3.1.2 Subject - allows postalAddress but not localityName and states
>> "Other attributes may be present but MUST NOT be necessary to
>> distinguish the subject name from other subject names within the
>> issuer domain."
>> 
>> This effectively precludes localityName from being used to
>> unambiguously differentiate between hospital. We request that
>> localityName be added to the MAY list.
>> 
>> Regards
>> David
>> 
>> ***************************************************
>> 
>> David Chadwick
>> IT Institute, University of Salford, Salford M5 4WT
>> Tel [phone]  Fax [phone]
>> *NEW* Mobile [phone] *NEW*
>> Email [e-mail]
>> Home Page  http://www.salford.ac.uk/its024/chadwick.htm
>> Understanding X.500  http://www.salford.ac.uk/its024/X500.htm
>> X.500/LDAP Seminars http://www.salford.ac.uk/its024/seminars.htm
>> Entrust key validation string MLJ9-DU5T-HV8J
>> 
>> ***************************************************



Received: from localhost (daemon@localhost) by mail.proper.com (8.8.8/8.8.5) with SMTP id IAA10079; Sat, 3 Jul 1999 08:00:25 -0700 (PDT)
Received: by mail.imc.org (bulk_mailer v1.12); Sat, 3 Jul 1999 07:58:56 -0700
Received: from harrier.prod.itd.earthlink.net (harrier.prod.itd.earthlink.net [207.217.121.12]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id HAA10048 for <[e-mail]>; Sat, 3 Jul 1999 07:58:56 -0700 (PDT)
Received: from lattin (1Cust209.tnt31.sfo3.da.uu.net [208.255.86.209]) by harrier.prod.itd.earthlink.net (8.9.3/8.9.3) with SMTP id IAA16224; Sat, 3 Jul 1999 08:02:39 -0700 (PDT)
From: "Bill Lattin" <[e-mail]>
To: "Denis Pinkas" <[e-mail]>
Cc: "Dave Robinson" <[e-mail]>, "Ron Holm" <[e-mail]>, "T. Mark Hastings" <[e-mail]>, <[e-mail]>
Subject: RE: Usage of TDTs
Date: Sat, 3 Jul 1999 08:02:00 -0700
Message-ID: <000101bec565$00683270$d156ffd0@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
In-Reply-To: <[e-mail]>
X-MimeOLE: Produced By Microsoft MimeOLE V4.72.2106.4
Importance: Normal
Precedence: bulk
List-Archive: http://www.imc.org/ietf-pkix/mail-archive/
List-Unsubscribe: mailto:[e-mail]?body=unsubscribe
X-UIDL: a0fa8bfff68353bd4316fcd62d3e6ae4

Denis,

As I see it, the proposed TDT enables the operation of a TSA to be extended
to address markets that it otherwise could not.

Certainly usage of a TSA will be determined by policy, but policy alone will
not be able to promote a local source of time to one that is linked to NTAs
and back to BIPM (the international source of time) in France.  There will
be applications that require a TSA to have access to NTA time; local time
will not be sufficient.  I have given a current *real* example of such a
requirement.  The TDT enables this link to the NTA and BIPM in a secure,
auditable manner.

The TDT is optional.  If a TSA doesn't need it, then it won't use it.  For
those applications requiring NTA time, then the TSA will have an
IETF-standardized way to get it.

In thinking about this further, time distribution has already been solved by
policy - global policy that establishes BIPM as the true source of
international time and that describes how the NTAs will synchronize to it.
Governments have policies declaring NTAs as the sources of national time.
All we are trying to do is enable TSAs to take advantage of an already
exisiting, recognized system - one that local TSA policy and local TSA
clocks will never  supplant.

Let's keep the TDA section in the time stamp draft.  It has been well
drafted and we have shown a use for it that is far better than just
providing incidental temporal data such as stock market closing indicies.

Best regards,

Bill

> -----Original Message-----
> From: Denis Pinkas [mailto:[e-mail]]
> Sent: Friday, July 02, 1999 09:05
> To: Bill Lattin
> Cc: [e-mail]
> Subject: Usage of TDTs
>
>
> Bill and others,
>
> I am watching this thread.
>
> As far as the need of PKIX is concerned, we trust that a given
> TSA will give the
> time up to a given (good or bad) precision. If someone does not
> trust a given
> TSA it uses another one that it trusts. There is no need for
> additional proofs
> (such as TDTs) for "additional trust". The trust is indicated
> indirectly in the
> policy included in the TST. Once again the *primary* use of a TSA
> in PKIX is to
> compare the time indicated in the TST with the time indicated in
> a CRL (limited
> to the granularity of a second with an undefined precision).
>
> So the use of the information, provided by a TDA, does not appear
> to be relevant
> in that case.
>
> Currently we can include additional data from a TDA but I have not seen
> argumentations for this. The idea is not to see if there *might be* a
> possibility to use that additional information, but if there is a
> *strong need*
> for it. If yes, what for ?
>
> Denis
>
>
> > MichaelZ,
> >
> > I've inserted my comments in your response to Mike Duren below.
> >
> > > -----Original Message-----
> > > From: [e-mail] [mailto:[e-mail]]
> > > Sent: Thursday, July 01, 1999 21:43
> > > To: [e-mail]; "[Denis.Pinkas"@bull.net];
> [e-mail];
> > > [e-mail]
> > > Cc: [e-mail]; [e-mail]; [e-mail];
> > > [e-mail]; [e-mail]
> > > Subject: RE: Time Stamp: Usage of TDTs
> > >
> > snip
> >
> > > [MD]
> > > >How do you prove that a TSA is time-accurate?  I don't see
> > > anything in the
> > > >TST that allows this, just a signature?  Because the
> signature is valid,
> > > >does that mean the time is accurate?  Can this only be
> solved by placing
> > > >trust in a policy or by relying on out of band information?
> > >
> > > [MZ]
> > > Hopefully so. Otherwise why don't I just go direct to the
> > > NIST-operated TSA,
> > > which I'm sure provides highly accurate timing?
> >
> > Lattin:  From my earlier email, certainly policy will be
> important to the
> > operation of all TSAs and TDAs.  Some applications will only require
> > agreement on policy at relatively local levels (between direct
> participants
> > and the TSA); others may require agreement on a broader scale and thus
> > require access to an NTA (e.g. the NASDAQ OATS application).  The OATS
> > application is one that supports both viewpoints being expressed here:
> > NASDAQ could run its own TSA, but it wants the time traceable
> to NIST - this
> > is exactly where the TDA would be applicable.  Again, I don't
> believe NTAs
> > will enter the TSA business - they could, but (i)governments typically
> > abstain from competition with corporations, and (ii) an NTA,
> whose business
> > it is to provide time, is unlikely to want to accept the liability and
> > perform the other operations associated with the TSA.
> >
> > snip
> >
> > > [MD]
> > > >Why is it unreasonable to include information in the
> > > Timestamping protocol
> > > that allows clients to trace the time value in >the stamp to
> some timing
> > > authority?  If the TDT can contain time values that are traceable to a
> > > Timing Authority, then why >not define a protocol that allows
> those tokens
> > > to be included in the timestamp?
> > > >The TDT is an optional field.
> > >
> > > [MZ]
> > > a TSA IS a timing authority from the client's prospective, or
> at least it
> > > should be viewed as one. And you do not use the TSA as a source
> > > of a precise
> > > timing anyway. At least the initial intention was not so.
> > > The prime usage of a TST is to compare the time in it to
> something else.
> > > Consider two possible scenarios:
> > > 1) comparing a TST to a high resolution time value (the bid
> entered the
> > > system at 15'32.1.3'):
> > > For such a system most likely a single TSA will be used, and
> it is more
> > > important to know that the ordering of TST is correct (who
> was the first).
> > > Having a TDT would not help there, as each clock, whatever carefully
> > > synchronised with NTA, has its own resolution, preventing any precise
> > > comparison.
> > > 2)comparing a token to some 'human' time ('A document existed at 15.00
> > > yesterday').
> > > I do not think that synchronisation with NTA is critical here.
> > >
> >
> > Lattin:  The primary problem the proposed TDT is solving is providing
> > non-repudiatable traceability of time information from a clock
> back to an
> > NTA.  It can enhance accuracy, but this is not its primary
> purpose.  If a
> > TSA is using GPS as its timing source, it may be very accurate,
> but from a
> > legal standpoint, that source of time may not be acceptable for some
> > applications which may require direct traceability of time back to the
> > issuing NTA.
> >
> > >[MZ] I'm trying to see a business case when knowing how
> precisely TSA clock
> > is
> > > synchronised with the NTA is critical, or relevant, rather then
> > > satisfying a
> > > curiosity of the users. Please, help me out.
> >
> > Lattin:  The business case is where traceablity to an NTA is
> required.  In
> > this case, a TSA without the capability to provide traceability
> to an NTA
> > would not be acceptable (e.g. NASDAQ OATS).  The proposed TDT
> will provide a
> > simple way to do this.
> >
> > No one is disputing that local policy agreement may work for a
> variety of
> > applications- especially today, but there are also applications
> today that
> > require traceability to an NTA so a local trusted clock will
> not suffice.
> > PKIX is a forward looking standard.  As more commerce and
> business processes
> > are moved to the internet, the ability to provide a link to nationally
> > recognized time sources will be increasingly important - it
> will facilitate
> > agreement between disparate parties as to the time of an event.
>  Time can be
> > as local or as universal as we chose to make it.  The proposed
> TDT is a way
> > to make national time available to all local TSAs.
> >
> > How about opinions from others on the list?  I know you're out
> there...:-)
> >
> > Regards,
> >
> > Bill
>
>



Received: from localhost (daemon@localhost) by mail.proper.com (8.8.8/8.8.5) with SMTP id BAA01541; Sat, 3 Jul 1999 01:03:11 -0700 (PDT)
Received: by mail.imc.org (bulk_mailer v1.12); Sat, 3 Jul 1999 01:02:54 -0700
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 BAA01513 for <[e-mail]>; Sat, 3 Jul 1999 01:02:52 -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 KAA31753 for <[e-mail]>; Sat, 3 Jul 1999 10:06:37 +0200
Received: from mega (t2o69p93.telia.com [62.20.144.213]) by caesar.udac.se (8.7.3/NetworkC-1) with SMTP id KAA44897; Sat, 3 Jul 1999 10:06:34 +0200
Message-ID: <015601bec533$09501600$[e-mail]>
From: "Anders Rundgren" <[e-mail]>
To: <[e-mail]>, <[e-mail]>, <[e-mail]>
Subject: Re: I-D ACTION:draft-ietf-pkix-scvp-00.txt
Date: Sat, 3 Jul 1999 10:04:18 +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.3110.5
X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by mail.proper.com id BAA01514
Precedence: bulk
List-Archive: http://www.imc.org/ietf-pkix/mail-archive/
List-Unsubscribe: mailto:[e-mail]?body=unsubscribe
X-UIDL: 5fb502d0af458aebb3cad5cc1f075cc9

Hi Michel,
Here are some comments on the tiny format

>Since the discussion started, have we received any 'at last' greetings from
>small device manufactures? They should be the first to reply and the
>majority among the participants. Where are you, guys??? Aren't you that much
>concerned about complexity of handling ASN.1?

No, particularly if one looks a couple a years ahead.
Only within certain places like in static data in smart-cards ASN.1 parsing is
a problem and in these places ASN.1 will be supplemented by ASN.1 opaque objects
containing hard-code binary data.

<snip>
>Otherwise, I'm not sure we are talking the reality here, proposing a
>'simple' alternative to ASN.

XML is my candidate.  Universal, hyped and human-readable.  It is not a compact
format though but that is not such a big problem anymore. 

Regards
Anders Rundgren

http://www.mobilephones-tng.com




Received: from localhost (daemon@localhost) by mail.proper.com (8.8.8/8.8.5) with SMTP id UAA16260; Fri, 2 Jul 1999 20:00:46 -0700 (PDT)
Received: by mail.imc.org (bulk_mailer v1.12); Fri, 2 Jul 1999 20:00:33 -0700
Received: from aum (ip11.proper.com [165.227.249.11]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id UAA16219 for <[e-mail]>; Fri, 2 Jul 1999 20:00:32 -0700 (PDT)
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.56 (Beta)
Date: Fri, 02 Jul 1999 20:02:54 -0700
To: [e-mail]
From: Paul Hoffman / IMC <[e-mail]>
Subject: Re: Initial comments on SCVP
In-Reply-To: <[e-mail].c om>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Precedence: bulk
List-Archive: http://www.imc.org/ietf-pkix/mail-archive/
List-Unsubscribe: mailto:[e-mail]?body=unsubscribe
X-UIDL: bcea78dc2a96c28d76d602cc3704d404

At 06:28 PM 7/2/1999 -0700, Michael Myers wrote:
>I've got to wonder though if we need yet another online protocol or if we'd
>be doing our job better by building on our prior work.

Wonder no more. You, as an author on OCSP, know that the spec talks only 
about status. In order to extend it to do what SCVP is proposing, you would 
have to completely rewrite all of the semantics in sections 2 and 3, you 
would have to create about a dozen extensions (that would be marked 
critical, of course), and so on. In other words, it would no longer be OCSP 
at all.

>OCSP was in its inception aimed at solving the more general certificate
>validation problem. At the request of several very large stakeholders who
>intended to rely on OCSP for Internet-based financial transactions, we chose
>to first deal with the revocation problem, recognizing that via
>extensibility we were architecting a more general certificate validation
>framework.

Unfortunately, that latter phrase didn't come true at all. OCSP is so 
constrained in the semantics that extending it into validation is 
impossible without rewriting the whole spec. I guess that's the downside of 
giving "very large stakeholders" so much say on the scope of the protocol.

>Let's build on that, especially since it was the original intent of OCSP to
>do so.  With the investment people are today making in extensible OCSP, that
>only makes sense.

I'm not sure what you mean by this. Are you saying that developers would 
have an easier time adding a raft of critical extensions to one ASN.1-based 
request-response protocol than they would simply writing a new one? 
Interpreting the extensions would be just as hard as interpreting the new 
protocol, one imagines.

>It would relatively straightforward to publish an extensions document. Doing
>so, we would have the advantage of incrementally building on a existing RFC
>specifically intended to be extended in this fashion, for specifically this
>need, rather that totally revinent what that RFC has already established.

I disagree here. The extensions document would have to say "ignore the 
semantics and restrictions of sections 2 and 3 of OCSP", which very 
narrowly target status. The ASN.1 might be possible, of course, but the 
semantics of the extensions would require a significant over-riding of 
OCSP's semantics.

Of course, if the WG doesn't mind this, please feel free to write an OCSP 
extensions document that covers the same semantics as SCVP. If it looks 
like a better fit, we could just drop SCVP.

...except, of course, you have ignored the non-ASN.1 clients.

>Otherwise, what's the advantage of replacing a protocol that has already
>been ratified by the working group and promoted to proposed standard status?
>Especially since the requirements being met by the proposed protocol are
>already met or are intended to be met by extensions to RFC2560?

If OCSP was supposed to be extended with extensions for things other than 
revocation, why were the semantics crafted so narrowly to exclude them?

>   I just
>don't see a compelling case being made for so radical a revision.

Hopefully, you do now.


--Paul Hoffman, Director
--Internet Mail Consortium



Received: from localhost (daemon@localhost) by mail.proper.com (8.8.8/8.8.5) with SMTP id SAA04852; Fri, 2 Jul 1999 18:25:02 -0700 (PDT)
Received: by mail.imc.org (bulk_mailer v1.12); Fri, 2 Jul 1999 18:24:49 -0700
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 SAA04787 for <[e-mail]>; Fri, 2 Jul 1999 18:24:48 -0700 (PDT)
Received: from mentat.verisign.com by caladan.verisign.com (8.8.5/BCH1.5) id SAA23101; Fri, 2 Jul 1999 18:27:00 -0700 (PDT)
Received: from newman.verisign.com by mentat.verisign.com (8.8.5/BCH1.0) id SAA18655; Fri, 2 Jul 1999 18:28:05 -0700 (PDT)
Received: by newman.verisign.com with Internet Mail Service (5.5.2448.0) id <N7XWDYX4>; Fri, 2 Jul 1999 18:28:07 -0700
Message-ID: <[e-mail]>
From: Michael Myers <[e-mail]>
To: [e-mail]
Subject: Initial comments on SCVP
Date: Fri, 2 Jul 1999 18:28:00 -0700 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2448.0)
Content-Type: text/plain; charset="iso-8859-1"
Precedence: bulk
List-Archive: http://www.imc.org/ietf-pkix/mail-archive/
List-Unsubscribe: mailto:[e-mail]?body=unsubscribe
X-UIDL: 181ccee0ec2d7af58dfd4223258ea270
Status: O
X-Status:

Ambarish, Paul:

A very timely draft.

I've got to wonder though if we need yet another online protocol or if we'd
be doing our job better by building on our prior work. Both OCSP or DCS have
achieved a fairly stable level of maturity in the IETF.  In fact, OCSP is
now RFC 2560.  Upon reviewing the proposal, it seems to me that either
provide a more stable platform for addressing these requirements.

OCSP was in its inception aimed at solving the more general certificate
validation problem. At the request of several very large stakeholders who
intended to rely on OCSP for Internet-based financial transactions, we chose
to first deal with the revocation problem, recognizing that via
extensibility we were architecting a more general certificate validation
framework.

Let's build on that, especially since it was the original intent of OCSP to
do so.  With the investment people are today making in extensible OCSP, that
only makes sense.

It would relatively straightforward to publish an extensions document. Doing
so, we would have the advantage of incrementally building on a existing RFC
specifically intended to be extended in this fashion, for specifically this
need, rather that totally revinent what that RFC has already established.

Otherwise, what's the advantage of replacing a protocol that has already
been ratified by the working group and promoted to proposed standard status?
Especially since the requirements being met by the proposed protocol are
already met or are intended to be met by extensions to RFC2560?  I just
don't see a compelling case being made for so radical a revision.

I'm compelled to ask the group at large if others share these sentiments.
Perhaps I missed something.

Mike


Received: from localhost (daemon@localhost) by mail.proper.com (8.8.8/8.8.5) with SMTP id OAA27876; Fri, 2 Jul 1999 14:43:50 -0700 (PDT)
Received: by mail.imc.org (bulk_mailer v1.12); Fri, 2 Jul 1999 14:43:47 -0700
Received: from ns1.dmz.valicert.com (ns1.valicert.com [63.65.221.10]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id OAA27854 for <[e-mail]>; Fri, 2 Jul 1999 14:43:47 -0700 (PDT)
Received: from ns1.serverfarm.valicert.com (corporate-gw.valicert.com [63.65.221.2]) by ns1.dmz.valicert.com (8.9.2/8.9.2) with ESMTP id OAA05528 for <[e-mail]>; Fri, 2 Jul 1999 14:45:56 -0700 (PDT)
Received: from rhone (dhcp-3-128.engineering.valicert.com [192.168.3.128] (may be forged)) by ns1.serverfarm.valicert.com (8.9.2/8.9.2) with SMTP id OAA27909 for <[e-mail]>; Fri, 2 Jul 1999 14:47:10 -0700 (PDT)
From: "Ambarish Malpani" <[e-mail]>
To: <[e-mail]>
Subject: RE: I-D ACTION:draft-ietf-pkix-scvp-00.txt 
Date: Fri, 2 Jul 1999 14:49:58 -0700
Message-ID: <004101bec4d4$d4fddb70$[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
X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3
In-Reply-To: <008701bec4ba$c5cbc6e0$[e-mail]>
Importance: Normal
Precedence: bulk
List-Archive: http://www.imc.org/ietf-pkix/mail-archive/
List-Unsubscribe: mailto:[e-mail]?body=unsubscribe
X-UIDL: acca38510c243ccef6536ffe59553e59

Reasonably early on in this ASN.1/non-ASN.1 discussion, Paul had
actually put it very nicely:

> We're quite open to any syntaxes that would make client vendors more
likely
> to implement SVCP. That's precisely why we have two in the draft, and why
> all of the semantics are in a different section. If we can go with one and
> show how someone with little or no ASN.1 experience can create a program
> that writes requests and reads responses, that would be great. But I'm
> skeptical...

Neither of us is particularly tied to the syntax. We are, interested
in making sure the semantics are clear and the syntax(es) let us
express the syntax easily.

If nobody likes the tiny syntax, nobody will implement it in the
client, which will make it disappear from spec. Let's not rush in
to figure out whether there is any value to the tiny syntax. Give
it a chance and we will let developers answer that question.

*Now*, can we continue with discussing the semantic of the
protocol and whether those are useful/correct etc.?

Regards,
Ambarish

---------------------------------------------------------------------
Ambarish Malpani
Architect					         650.567.5457
ValiCert, Inc.				        [e-mail]
1215 Terra Bella Ave.		              http://www.valicert.com
Mountain View, CA 94043-1833


> -----Original Message-----
> From: Peter Williams [mailto:[e-mail]]
> Sent: Friday, July 02, 1999 11:43 AM
> To: David P. Kemp; [e-mail]
> Subject: RE: I-D ACTION:draft-ietf-pkix-scvp-00.txt
>
>
>
>
> > -----Original Message-----
> > From: David P. Kemp [mailto:[e-mail]]
> > Sent: Friday, July 02, 1999 2:43 PM
> > To: [e-mail]
> > Subject: RE: I-D ACTION:draft-ietf-pkix-scvp-00.txt
> >
> >
> >
> > > From: "Peter Williams" <[e-mail]>
> > >
> > > Rather than invent a new tiny notation, perhaps just
> adopt the snmp
> > > style guidelines. A whole, multi-vendor, SNMP industry
> already suceeded
> > > in this adoption.
> >
> >
> > Agreed.
>
> Ok, providing the context was intepreted as I meant it - "rather han
> invent a new tiny [ASN.1] notation [distinct from that in SNMP]...."
>
> >
> > The thesis has been presented that there are device developers who
> > could make (compliant and secure) use of X.509 certificates
> if there were
> > a protocol to allow server-based path construction and path
> validation,
> > AND that some of those developers are so uncomfortable with
> ASN.1 that
> > they would not use SCVP unless a non-ASN.1 transfer encoding were
> > defined.
>
>
> > We have not heard from those developers on the mail list, but I am
> > assured that they do exist.  Perhaps casting the SCVP
> syntax in terms
> > of the ASN.1 subset defined by SNMP would reassure them that
> > it is indeed possible to implement SCVP on any device capable of
> > supporting an SNMP MIB, and that the SCVP tiny syntax is
> > unnecessary baggage.
>
> I think we could sensibly choose based on the communities who
> are being
> addressed. I can see the MIB/SNMP community argument as a
> driver. And I
> can see the type-able telnet/http/pop3 line of argument as a
> driver, also.
>
> Failing some groundswell of sentiment, we will just have to let the
> authors decide - unless someone can come up with some important
> criteria for this tiny-msg encoding matter. There are perhaps
> more important
> semantic issues to pursue at this first draft publication stage, along
> the lines that Steven was commenting on. But, scoping out the
> simplicity
> assumptions was useful! It is vital and represents much of
> the momentum
> behind the draft, I suspect.
>
> Peter.
>
>
>



Received: from localhost (daemon@localhost) by mail.proper.com (8.8.8/8.8.5) with SMTP id NAA26793; Fri, 2 Jul 1999 13:31:30 -0700 (PDT)
Received: by mail.imc.org (bulk_mailer v1.12); Fri, 2 Jul 1999 13:31:25 -0700
Received: from ns1.dmz.valicert.com (ns1.valicert.com [63.65.221.10]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id NAA26771 for <[e-mail]>; Fri, 2 Jul 1999 13:31:24 -0700 (PDT)
Received: from ns1.serverfarm.valicert.com (corporate-gw.valicert.com [63.65.221.2]) by ns1.dmz.valicert.com (8.9.2/8.9.2) with ESMTP id NAA05158; Fri, 2 Jul 1999 13:33:34 -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 NAA26828; Fri, 2 Jul 1999 13:34:48 -0700 (PDT)
From: "Peter Williams" <[e-mail]>
To: "David P. Kemp" <[e-mail]>, <[e-mail]>
Subject: RE: I-D ACTION:draft-ietf-pkix-scvp-00.txt 
Date: Fri, 2 Jul 1999 13:43:27 -0500
Message-ID: <008701bec4ba$c5cbc6e0$[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 V5.00.2314.1300
In-Reply-To: <[e-mail]>
Precedence: bulk
List-Archive: http://www.imc.org/ietf-pkix/mail-archive/
List-Unsubscribe: mailto:[e-mail]?body=unsubscribe
X-UIDL: 1de67bfc4e44ff6ea9b1e1f815d03e80

> -----Original Message-----
> From: David P. Kemp [mailto:[e-mail]]
> Sent: Friday, July 02, 1999 2:43 PM
> To: [e-mail]
> Subject: RE: I-D ACTION:draft-ietf-pkix-scvp-00.txt
>
>
>
> > From: "Peter Williams" <[e-mail]>
> >
> > Rather than invent a new tiny notation, perhaps just adopt the snmp
> > style guidelines. A whole, multi-vendor, SNMP industry already suceeded
> > in this adoption.
>
>
> Agreed.

Ok, providing the context was intepreted as I meant it - "rather han
invent a new tiny [ASN.1] notation [distinct from that in SNMP]...."

>
> The thesis has been presented that there are device developers who
> could make (compliant and secure) use of X.509 certificates if there were
> a protocol to allow server-based path construction and path validation,
> AND that some of those developers are so uncomfortable with ASN.1 that
> they would not use SCVP unless a non-ASN.1 transfer encoding were
> defined.


> We have not heard from those developers on the mail list, but I am
> assured that they do exist.  Perhaps casting the SCVP syntax in terms
> of the ASN.1 subset defined by SNMP would reassure them that
> it is indeed possible to implement SCVP on any device capable of
> supporting an SNMP MIB, and that the SCVP tiny syntax is
> unnecessary baggage.

I think we could sensibly choose based on the communities who are being
addressed. I can see the MIB/SNMP community argument as a driver. And I
can see the type-able telnet/http/pop3 line of argument as a driver, also.

Failing some groundswell of sentiment, we will just have to let the
authors decide - unless someone can come up with some important
criteria for this tiny-msg encoding matter. There are perhaps more important
semantic issues to pursue at this first draft publication stage, along
the lines that Steven was commenting on. But, scoping out the simplicity
assumptions was useful! It is vital and represents much of the momentum
behind the draft, I suspect.

Peter.



Received: from localhost (daemon@localhost) by mail.proper.com (8.8.8/8.8.5) with SMTP id MAA26095; Fri, 2 Jul 1999 12:42:39 -0700 (PDT)
Received: by mail.imc.org (bulk_mailer v1.12); Fri, 2 Jul 1999 12:42:37 -0700
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 MAA26068 for <[e-mail]>; Fri, 2 Jul 1999 12:42:36 -0700 (PDT)
Received: from stingray.missi.ncsc.mil (root@localhost) by stingray.missi.ncsc.mil with ESMTP id PAA16751 for <[e-mail]>; Fri, 2 Jul 1999 15:46:24 -0400 (EDT)
Received: from missi.ncsc.mil (depot.missi.ncsc.mil [144.51.60.1]) by stingray.missi.ncsc.mil with ESMTP id PAA16747 for <[e-mail]>; Fri, 2 Jul 1999 15:46:23 -0400 (EDT)
Received: from ara.missi.ncsc.mil (ara.missi.ncsc.mil [144.51.58.9]) by missi.ncsc.mil (8.8.8/8.8.8) with ESMTP id PAA07732 for <[e-mail]>; Fri, 2 Jul 1999 15:46:25 -0400 (EDT)
Received: from ara.missi.ncsc.mil (ara.missi.ncsc.mil [144.51.58.9]) by ara.missi.ncsc.mil (8.9.1b+Sun/8.9.1) with SMTP id PAA03356 for <[e-mail]>; Fri, 2 Jul 1999 15:43:00 -0400 (EDT)
Message-Id: <[e-mail]>
Date: Fri, 2 Jul 1999 15:43:00 -0400 (EDT)
From: "David P. Kemp" <[e-mail]>
Reply-To: "David P. Kemp" <[e-mail]>
Subject: RE: I-D ACTION:draft-ietf-pkix-scvp-00.txt 
To: [e-mail]
MIME-Version: 1.0
Content-Type: TEXT/plain; charset=us-ascii
Content-MD5: zbZuIP0avBVf8KsRoBABZQ==
X-Mailer: dtmail 1.3.0 CDE Version 1.3 SunOS 5.7 sun4u sparc 
Precedence: bulk
List-Archive: http://www.imc.org/ietf-pkix/mail-archive/
List-Unsubscribe: mailto:[e-mail]?body=unsubscribe
X-UIDL: fa015076357d4782665eeebf348b5762

> From: "Peter Williams" <[e-mail]>
> 
> Rather than invent a new tiny notation, perhaps just adopt the snmp
> style guidelines. A whole, multi-vendor, SNMP industry already suceeded
> in this adoption.


Agreed.

The thesis has been presented that there are device developers who
could make (compliant and secure) use of X.509 certificates if there were
a protocol to allow server-based path construction and path validation,
AND that some of those developers are so uncomfortable with ASN.1 that
they would not use SCVP unless a non-ASN.1 transfer encoding were
defined.

We have not heard from those developers on the mail list, but I am
assured that they do exist.  Perhaps casting the SCVP syntax in terms
of the ASN.1 subset defined by SNMP would reassure them that
it is indeed possible to implement SCVP on any device capable of
supporting an SNMP MIB, and that the SCVP tiny syntax is
unnecessary baggage.



Received: from localhost (daemon@localhost) by mail.proper.com (8.8.8/8.8.5) with SMTP id LAA25330; Fri, 2 Jul 1999 11:55:12 -0700 (PDT)
Received: by mail.imc.org (bulk_mailer v1.12); Fri, 2 Jul 1999 11:55:10 -0700
Received: from www.meridianus.com (209.249.223.21.has.no.reverse [209.249.223.21] (may be forged)) by mail.proper.com (8.8.8/8.8.5) with ESMTP id LAA25308 for <[e-mail]>; Fri, 2 Jul 1999 11:55:10 -0700 (PDT)
Received: from pc1 by www.meridianus.com (8.8.8+Sun/SMI-SVR4) id MAA08232; Fri, 2 Jul 1999 12:53:54 -0700 (PDT)
Message-ID: <05fa01bec4bc$de7025e0$[e-mail]>
From: "[e-mail]" <[e-mail]>
To: "Denis Pinkas" <[e-mail]>, "Bill Lattin" <[e-mail]>
Cc: <[e-mail]>
References: <000601bec49b$747b3880$2348ffd0@lattin> <[e-mail]>
Subject: Re: Usage of TDTs
Date: Fri, 2 Jul 1999 11:58:27 -0700
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.00.2014.211
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2014.211
Precedence: bulk
List-Archive: http://www.imc.org/ietf-pkix/mail-archive/
List-Unsubscribe: mailto:[e-mail]?body=unsubscribe
X-UIDL: a0346e382d5f9a6b16cd31e80cc9334e

Actually Denis I would disagree.

The source of time and its accuracy are critically important to the overall
believability of the actual event represented by the timestamp and
particularly to its portability. We coined a term at Coastek called a
Portable Trust Model and that is what the timestamp is intended to produce.
A clearly defined level of portability in the enent logging system or a
validatible control signal in some other automated process model.

With that said the real issue here is the timestamp, and then the
infrastructure that creates it (the timestamp) and these need top be
specific to the end use models... The current model as proposed just
"believes" that the timebase is accurate and that for me elicits the thought
of someone standing in Court 10 years later swearing that their BCP model
involved resetting the OS TOD timebase and that the time in the timestamp is
right becuase of this... As opposing Counsel in the matter my response would
have been something like "Ahahahahahahahah - this is patently ridiculous on
the face of it. Who audited the OS to prove that the OS TOD services were
secure, audited what else was running on that platform, what other
transactions and processes interacted with this one, etc etc etc."

The bottom line is that without a clean OS independent model, it is really
difficult to get beyond the "Well we said so, isn't that enough?" proofing
models and they just won't hold water in the courts of today let alone the
computing-savvy ones of tomorrow... No, I think that if this timestamping
technology is to be of any real commercial use it has to address the
requirements that the timeservices infrastructure be capable of being
subsumed into the Server Platform as an integral component of the Audit
system.

That's why we got Datum involved in this arena so that we could address this
requirement in a HW manner and get the flimsy OS-borne support models out of
the question as to the Veracity of the Timestamp Data. BTW, for me, the
issues of placing the certification data inline as to the timebase validity
and source are key to the records that are produced being viable in and of
themselves, and not dependant on a lot of uncontrollable human parameters or
the unsafe OS infrastructure that created them.

Sorry to throw oil onto a fire, but this issue of the sanctity of the
timebase is a core gating issue in the believability of the event it
references in an absolute timestamping model.

Todd Glassey

----- Original Message -----
From: Denis Pinkas <[e-mail]>
To: Bill Lattin <[e-mail]>
Cc: <[e-mail]>
Sent: Friday, July 02, 1999 9:04 AM
Subject: Usage of TDTs


> Bill and others,
>
> I am watching this thread.
>
> As far as the need of PKIX is concerned, we trust that a given TSA will
give the
> time up to a given (good or bad) precision. If someone does not trust a
given
> TSA it uses another one that it trusts. There is no need for additional
proofs
> (such as TDTs) for "additional trust". The trust is indicated indirectly
in the
> policy included in the TST. Once again the *primary* use of a TSA in PKIX
is to
> compare the time indicated in the TST with the time indicated in a CRL
(limited
> to the granularity of a second with an undefined precision).
>
> So the use of the information, provided by a TDA, does not appear to be
relevant
> in that case.
>
> Currently we can include additional data from a TDA but I have not seen
> argumentations for this. The idea is not to see if there *might be* a
> possibility to use that additional information, but if there is a *strong
need*
> for it. If yes, what for ?
>
> Denis
>
>
> > MichaelZ,
> >
> > I've inserted my comments in your response to Mike Duren below.
> >
> > > -----Original Message-----
> > > From: [e-mail] [mailto:[e-mail]]
> > > Sent: Thursday, July 01, 1999 21:43
> > > To: [e-mail]; "[Denis.Pinkas"@bull.net];
[e-mail];
> > > [e-mail]
> > > Cc: [e-mail]; [e-mail]; [e-mail];
> > > [e-mail]; [e-mail]
> > > Subject: RE: Time Stamp: Usage of TDTs
> > >
> > snip
> >
> > > [MD]
> > > >How do you prove that a TSA is time-accurate?  I don't see
> > > anything in the
> > > >TST that allows this, just a signature?  Because the signature is
valid,
> > > >does that mean the time is accurate?  Can this only be solved by
placing
> > > >trust in a policy or by relying on out of band information?
> > >
> > > [MZ]
> > > Hopefully so. Otherwise why don't I just go direct to the
> > > NIST-operated TSA,
> > > which I'm sure provides highly accurate timing?
> >
> > Lattin:  From my earlier email, certainly policy will be important to
the
> > operation of all TSAs and TDAs.  Some applications will only require
> > agreement on policy at relatively local levels (between direct
participants
> > and the TSA); others may require agreement on a broader scale and thus
> > require access to an NTA (e.g. the NASDAQ OATS application).  The OATS
> > application is one that supports both viewpoints being expressed here:
> > NASDAQ could run its own TSA, but it wants the time traceable to NIST -
this
> > is exactly where the TDA would be applicable.  Again, I don't believe
NTAs
> > will enter the TSA business - they could, but (i)governments typically
> > abstain from competition with corporations, and (ii) an NTA, whose
business
> > it is to provide time, is unlikely to want to accept the liability and
> > perform the other operations associated with the TSA.
> >
> > snip
> >
> > > [MD]
> > > >Why is it unreasonable to include information in the
> > > Timestamping protocol
> > > that allows clients to trace the time value in >the stamp to some
timing
> > > authority?  If the TDT can contain time values that are traceable to a
> > > Timing Authority, then why >not define a protocol that allows those
tokens
> > > to be included in the timestamp?
> > > >The TDT is an optional field.
> > >
> > > [MZ]
> > > a TSA IS a timing authority from the client's prospective, or at least
it
> > > should be viewed as one. And you do not use the TSA as a source
> > > of a precise
> > > timing anyway. At least the initial intention was not so.
> > > The prime usage of a TST is to compare the time in it to something
else.
> > > Consider two possible scenarios:
> > > 1) comparing a TST to a high resolution time value (the bid entered
the
> > > system at 15'32.1.3'):
> > > For such a system most likely a single TSA will be used, and it is
more
> > > important to know that the ordering of TST is correct (who was the
first).
> > > Having a TDT would not help there, as each clock, whatever carefully
> > > synchronised with NTA, has its own resolution, preventing any precise
> > > comparison.
> > > 2)comparing a token to some 'human' time ('A document existed at 15.00
> > > yesterday').
> > > I do not think that synchronisation with NTA is critical here.
> > >
> >
> > Lattin:  The primary problem the proposed TDT is solving is providing
> > non-repudiatable traceability of time information from a clock back to
an
> > NTA.  It can enhance accuracy, but this is not its primary purpose.  If
a
> > TSA is using GPS as its timing source, it may be very accurate, but from
a
> > legal standpoint, that source of time may not be acceptable for some
> > applications which may require direct traceability of time back to the
> > issuing NTA.
> >
> > >[MZ] I'm trying to see a business case when knowing how precisely TSA
clock
> > is
> > > synchronised with the NTA is critical, or relevant, rather then
> > > satisfying a
> > > curiosity of the users. Please, help me out.
> >
> > Lattin:  The business case is where traceablity to an NTA is required.
In
> > this case, a TSA without the capability to provide traceability to an
NTA
> > would not be acceptable (e.g. NASDAQ OATS).  The proposed TDT will
provide a
> > simple way to do this.
> >
> > No one is disputing that local policy agreement may work for a variety
of
> > applications- especially today, but there are also applications today
that
> > require traceability to an NTA so a local trusted clock will not
suffice.
> > PKIX is a forward looking standard.  As more commerce and business
processes
> > are moved to the internet, the ability to provide a link to nationally
> > recognized time sources will be increasingly important - it will
facilitate
> > agreement between disparate parties as to the time of an event.  Time
can be
> > as local or as universal as we chose to make it.  The proposed TDT is a
way
> > to make national time available to all local TSAs.
> >
> > How about opinions from others on the list?  I know you're out
there...:-)
> >
> > Regards,
> >
> > Bill
>
>




Received: from localhost (daemon@localhost) by mail.proper.com (8.8.8/8.8.5) with SMTP id LAA24256; Fri, 2 Jul 1999 11:01:45 -0700 (PDT)
Received: by mail.imc.org (bulk_mailer v1.12); Fri, 2 Jul 1999 11:01:40 -0700
Received: from ns1.dmz.valicert.com (ns1.valicert.com [63.65.221.10]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id LAA24232 for <[e-mail]>; Fri, 2 Jul 1999 11:01:39 -0700 (PDT)
Received: from ns1.serverfarm.valicert.com (corporate-gw.valicert.com [63.65.221.2]) by ns1.dmz.valicert.com (8.9.2/8.9.2) with ESMTP id LAA04305; Fri, 2 Jul 1999 11:03:48 -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 LAA24319; Fri, 2 Jul 1999 11:05:02 -0700 (PDT)
From: "Peter Williams" <[e-mail]>
To: "David P. Kemp" <[e-mail]>, <[e-mail]>
Subject: RE: I-D ACTION:draft-ietf-pkix-scvp-00.txt 
Date: Fri, 2 Jul 1999 11:13:41 -0500
Message-ID: <008201bec4a5$d9d44e10$[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 V5.00.2314.1300
In-Reply-To: <[e-mail]>
Precedence: bulk
List-Archive: http://www.imc.org/ietf-pkix/mail-archive/
List-Unsubscribe: mailto:[e-mail]?body=unsubscribe
X-UIDL: 71a23d8cf22590e5a0a001b016017fb8

> I find the compact format more readable, but concede that indentation
> and brace placement is a matter of religious preference.  Was there
> anything more profound you had in mind when referring to notation?

Profundity is not my style: keeping the use of SCVP syntax notation 
conforming with the style used in the various SNMP 
RFCS would be an ideal, if you all go this direction.

Unless there is a reason, use the types (and tags) pre-defined. Part
of the style benefit is that one does not invent [tagged] types when
existing definitions can be leveraged. After all, several hundred
MIBs could make do with a restricted type set.

Rather than invent a new tiny notation, perhaps just adopt the snmp
style guidelines. A whole, multi-vendor, SNMP industry already suceeded
in this adoption. And that industry, unlike PKIX, interoperates technically
in the real world.

Dont let this SNMP tack sidetrack the list from the idea that
non-BER approaches may be deemed suitable. The protocol could used
Signed XML text for the message object encoding, for all it really 
matters. Wider architectural-needs understanding and discussion
in the document may help here.

Peter.



> -----Original Message-----
> From: David P. Kemp [mailto:[e-mail]]
> Sent: Friday, July 02, 1999 12:33 PM
> To: [e-mail]
> Subject: RE: I-D ACTION:draft-ietf-pkix-scvp-00.txt 
> 
> 
> 
> > From: "Peter Williams" <[e-mail]>
> > 
> > I think the SNMP example holds here, given it
> > is simple but also uses BER and a ASN.1-based notation. The 
> full CMIF model
> > was addressed by the IESG-policy and WG ethic, but reduced, and
> > a simple to implement protocol was specified.  If we were to here
> > use any OSI message encoding, Id have us use the SNMP BER Subset
> > and have it specified in the notation used in
> > the SNMP RFCs. A hundred implementations of this
> > already exist; a reusable one even comes free with Windows
> > and a $50  code sample book.
> 
> 
> RFC1157 defines the BER subset as:
> 
>    Also for the sake of simplicity, the SNMP uses only a subset of the
>    basic encoding rules of ASN.1 [10].  Namely, all encodings use the
>    definite-length form.  Further, whenever permissible, non-constructor
>    encodings are used rather than constructor encodings.
> 
> "Wherever permissible" is pretty wishy-washy language for a standard
> specification; the software can't be simplified unless constructed
> encodings of primitive data items are prohibited, period.
> 
> I might suggest a few additional restrictions to enable the ultimate
> in simple software: no PDUs larger than 4GB (4 byte max length field),
> no UNIVERSAL tags except { BOOLEAN, INTEGER, BITSTRING, OCTETSTRING,
> OID, ENUMERATED, UTF8STRING, SEQUENCE, GENERALIZEDTIME },
> no CONTEXT tags with a value > 30, no APPLICATION or PRIVATE tags at all.
> SET is omitted to eliminate DER sorting code.  UTCTIME is omitted because
> it's 1999 already.  The other string types are omitted simply because too
> many choices are too many - UTF8 can encode everything without penalizing
> Latin-only implementations.  I'd hate to get rid of DEFAULT and OPTIONAL
> in a "tiny ASN.1" language specification, but would suggest that protocol
> definitions avoid using them.
> 
> 
> 
> I'm not sure what you mean by the notation used in the SNMP RFCs; as
> far as I can tell, it's standard ASN.1 except for a *lot* of extra
> whitespace.   What RFC1157 writes as:
> 
>              Message ::=
>                      SEQUENCE {
>                           version        -- version-1 for this RFC
>                              INTEGER {
>                                  version-1(0)
>                              },
> 
>                          community      -- community name
>                              OCTET STRING,
> 
>                          data           -- e.g., PDUs if trivial
>                              ANY        -- authentication is being used
>                      }
> 
> PKIX might write as:
> 
>        Message ::= SEQUENCE {
>           version     INTEGER version-1(0),  -- version-1 for this RFC
>           community   OCTET STRING,          -- community name
>           data        ANY }                  -- e.g., PDUs if trivial
>                                              -- authentication is 
> being used
> 
> 
> I find the compact format more readable, but concede that indentation
> and brace placement is a matter of religious preference.  Was there
> anything more profound you had in mind when referring to notation?
> 
> 
> 
> 


Received: from localhost (daemon@localhost) by mail.proper.com (8.8.8/8.8.5) with SMTP id JAA23138; Fri, 2 Jul 1999 09:54:57 -0700 (PDT)
Received: by mail.imc.org (bulk_mailer v1.12); Fri, 2 Jul 1999 09:53:33 -0700
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 JAA23092 for <[e-mail]>; Fri, 2 Jul 1999 09:53:32 -0700 (PDT)
Received: from mail0.sse.ie (actually localhost) by mail0.sse.ie; Fri, 2 Jul 1999 17:56:14 +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 RAA10237; Fri, 2 Jul 1999 17:56:12 +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 RAA28144; Fri, 2 Jul 1999 17:55:57 +0100 (BST)
Message-Id: <[e-mail]>
X-Mailer: exmh version 1.6.9 8/22/96
To: "Peter Williams" <[e-mail]>
cc: "Stephen Farrell" <[e-mail]>, [e-mail]
Subject: Re: I-D ACTION:draft-ietf-pkix-scvp-00.txt 
In-reply-to: Your message of "Fri, 02 Jul 1999 09:23:28 CDT." <007901bec496$745a8360$[e-mail]> 
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Date: Fri, 02 Jul 1999 17:55:56 +0100
From: Stephen Farrell <[e-mail]>
Precedence: bulk
List-Archive: http://www.imc.org/ietf-pkix/mail-archive/
List-Unsubscribe: mailto:[e-mail]?body=unsubscribe
X-UIDL: f8b7e25edcf0fceeac3619edb77378fc

Peter,

Just responding to the major points, not blow-by-blow.

> > I'd like some examples of applications that will be deployed with
> 
> The relationship of SVCP to CMP ...
[...lots of stuff deleted...]

I'm surprised you compare scvp (or is it SVCP?) to CMP, I saw
it as an alternative to an EE doing its own cert path 
construction and validation. I certainly would never envisage
anyone using CMP as it stands for this functionality.
Correct me if I'm wrong, but the I-D certainly doesn't give
this scvp vs. CMP impression.

> > > - Enable the PKI to be used on low-end devices such as telephones
> >
> > This seems spurious to me - 
[stuff deleted]

Ok, so it doesn't seem spurious to you, we disagree.
 
> I think the SNMP example holds here, given it
> is simple but also uses BER and a ASN.1-based notation. The full CMIF model
> was addressed by the IESG-policy and WG ethic, but reduced, and
> a simple to implement protocol was specified.  
[stuff deleted again]

Is your argument to call this "simpler certificate validation
protocol"? Simpler than what? As fas as I know there is no other
standardised certificate validation protocol (other than in the 
EDIFACT world).

> SVCP is not meant to be a profile of ldap tuned to
> certification-domain graph searching problems. We should profile
> an ldap operation to address this need, if its required. 

Actually, I can't really see how an ldap operation can do
path construction in general. Be interested in being shown
how it could.

> I think we have to be careful of server-side client-state
> management.

True, however, a path constructing server wouldn't managing 
state for a client, its state would rather be a "snapshot" 
of the PKI which is independent of particular clients.

Stephen.




Received: from localhost (daemon@localhost) by mail.proper.com (8.8.8/8.8.5) with SMTP id KAA23809; Fri, 2 Jul 1999 10:32:26 -0700 (PDT)
Received: by mail.imc.org (bulk_mailer v1.12); Fri, 2 Jul 1999 10:32:25 -0700
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 KAA23786 for <[e-mail]>; Fri, 2 Jul 1999 10:32:24 -0700 (PDT)
Received: from stingray.missi.ncsc.mil (root@localhost) by stingray.missi.ncsc.mil with ESMTP id NAA04935 for <[e-mail]>; Fri, 2 Jul 1999 13:36:12 -0400 (EDT)
Received: from missi.ncsc.mil (depot.missi.ncsc.mil [144.51.60.1]) by stingray.missi.ncsc.mil with ESMTP id NAA04930 for <[e-mail]>; Fri, 2 Jul 1999 13:36:11 -0400 (EDT)
Received: from ara.missi.ncsc.mil (ara.missi.ncsc.mil [144.51.58.9]) by missi.ncsc.mil (8.8.8/8.8.8) with ESMTP id NAA05756 for <[e-mail]>; Fri, 2 Jul 1999 13:36:12 -0400 (EDT)
Received: from ara.missi.ncsc.mil (ara.missi.ncsc.mil [144.51.58.9]) by ara.missi.ncsc.mil (8.9.1b+Sun/8.9.1) with SMTP id NAA03316 for <[e-mail]>; Fri, 2 Jul 1999 13:32:49 -0400 (EDT)
Message-Id: <[e-mail]>
Date: Fri, 2 Jul 1999 13:32:49 -0400 (EDT)
From: "David P. Kemp" <[e-mail]>
Reply-To: "David P. Kemp" <[e-mail]>
Subject: RE: I-D ACTION:draft-ietf-pkix-scvp-00.txt 
To: [e-mail]
MIME-Version: 1.0
Content-Type: TEXT/plain; charset=us-ascii
Content-MD5: d0INy0BWObfwiULBIpnCAQ==
X-Mailer: dtmail 1.3.0 CDE Version 1.3 SunOS 5.7 sun4u sparc 
Precedence: bulk
List-Archive: http://www.imc.org/ietf-pkix/mail-archive/
List-Unsubscribe: mailto:[e-mail]?body=unsubscribe
X-UIDL: 93afed5a1a1a5c93b240902e3fcb711d

> From: "Peter Williams" <[e-mail]>
> 
> I think the SNMP example holds here, given it
> is simple but also uses BER and a ASN.1-based notation. The full CMIF model
> was addressed by the IESG-policy and WG ethic, but reduced, and
> a simple to implement protocol was specified.  If we were to here
> use any OSI message encoding, Id have us use the SNMP BER Subset
> and have it specified in the notation used in
> the SNMP RFCs. A hundred implementations of this
> already exist; a reusable one even comes free with Windows
> and a $50  code sample book.


RFC1157 defines the BER subset as:

   Also for the sake of simplicity, the SNMP uses only a subset of the
   basic encoding rules of ASN.1 [10].  Namely, all encodings use the
   definite-length form.  Further, whenever permissible, non-constructor
   encodings are used rather than constructor encodings.

"Wherever permissible" is pretty wishy-washy language for a standard
specification; the software can't be simplified unless constructed
encodings of primitive data items are prohibited, period.

I might suggest a few additional restrictions to enable the ultimate
in simple software: no PDUs larger than 4GB (4 byte max length field),
no UNIVERSAL tags except { BOOLEAN, INTEGER, BITSTRING, OCTETSTRING,
OID, ENUMERATED, UTF8STRING, SEQUENCE, GENERALIZEDTIME },
no CONTEXT tags with a value > 30, no APPLICATION or PRIVATE tags at all.
SET is omitted to eliminate DER sorting code.  UTCTIME is omitted because
it's 1999 already.  The other string types are omitted simply because too
many choices are too many - UTF8 can encode everything without penalizing
Latin-only implementations.  I'd hate to get rid of DEFAULT and OPTIONAL
in a "tiny ASN.1" language specification, but would suggest that protocol
definitions avoid using them.



I'm not sure what you mean by the notation used in the SNMP RFCs; as
far as I can tell, it's standard ASN.1 except for a *lot* of extra
whitespace.   What RFC1157 writes as:

             Message ::=
                     SEQUENCE {
                          version        -- version-1 for this RFC
                             INTEGER {
                                 version-1(0)
                             },

                         community      -- community name
                             OCTET STRING,

                         data           -- e.g., PDUs if trivial
                             ANY        -- authentication is being used
                     }

PKIX might write as:

       Message ::= SEQUENCE {
          version     INTEGER version-1(0),  -- version-1 for this RFC
          community   OCTET STRING,          -- community name
          data        ANY }                  -- e.g., PDUs if trivial
                                             -- authentication is being used


I find the compact format more readable, but concede that indentation
and brace placement is a matter of religious preference.  Was there
anything more profound you had in mind when referring to notation?




Received: from localhost (daemon@localhost) by mail.proper.com (8.8.8/8.8.5) with SMTP id JAA22737; Fri, 2 Jul 1999 09:36:31 -0700 (PDT)
Received: by mail.imc.org (bulk_mailer v1.12); Fri, 2 Jul 1999 09:36:30 -0700
Received: from wfhqex05.wangfed.com (netva01.wangfed.com [206.137.100.2]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id JAA22712 for <[e-mail]>; Fri, 2 Jul 1999 09:36:29 -0700 (PDT)
Received: by wfhqex05.wangfed.com with Internet Mail Service (5.5.2448.0) id <NRPZ29H6>; Fri, 2 Jul 1999 12:39:51 -0400
Message-ID: <33BD629222C0D211B6DB0060085ACF3136081D@WFHQEX03>
From: "Pawling, John" <[e-mail]>
To: [e-mail]
Subject: RE: SNACC ASN.1 DER Freeware (was RE: I-D ACTION:draft-ietf-pkix- scvp -00.txt)
Date: Fri, 2 Jul 1999 12:39:47 -0400 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2448.0)
Content-Type: text/plain; charset="iso-8859-1"
Precedence: bulk
List-Archive: http://www.imc.org/ietf-pkix/mail-archive/
List-Unsubscribe: mailto:[e-mail]?body=unsubscribe
X-UIDL: a16f9cde7b116cd8496375ce7565165a

Aram,

I agree that SNACC does not support all of the latest ASN.1 features, but
there are work-arounds that allow SNACC to be used to produce ASN.1 hex
encodings that are identical to those produced by ASN.1 libraries that do
support the latest ASN.1 features.  Also note that many of the PKIX specs,
such as RFC 2459, include 1988-compliant ASN.1 syntax modules which can be
directly compiled using SNACC.  As part of the S/MIME Freeware Library, VDA
used SNACC to implement the S/MIME v3 set of specs.  There is also a
freeware Certificate Management Library
(http://www.armadillo.huntsville.al.us/software/certmgmt/index.html) that
uses SNACC to implement the 1997 X.509 Recommendation.

============================================
John Pawling, Director - Systems Engineering
J.G. Van Dyke & Associates, Inc.
[e-mail]
============================================





Received: from localhost (daemon@localhost) by mail.proper.com (8.8.8/8.8.5) with SMTP id JAA22323; Fri, 2 Jul 1999 09:11:39 -0700 (PDT)
Received: by mail.imc.org (bulk_mailer v1.12); Fri, 2 Jul 1999 09:11:38 -0700
Received: from ns1.dmz.valicert.com (ns1.valicert.com [63.65.221.10]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id JAA22301 for <[e-mail]>; Fri, 2 Jul 1999 09:11:38 -0700 (PDT)
Received: from ns1.serverfarm.valicert.com (corporate-gw.valicert.com [63.65.221.2]) by ns1.dmz.valicert.com (8.9.2/8.9.2) with ESMTP id JAA03616; Fri, 2 Jul 1999 09:13:36 -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 JAA22162; Fri, 2 Jul 1999 09:14:50 -0700 (PDT)
From: "Peter Williams" <[e-mail]>
To: "Stephen Farrell" <[e-mail]>, <[e-mail]>
Subject: RE: I-D ACTION:draft-ietf-pkix-scvp-00.txt 
Date: Fri, 2 Jul 1999 09:23:28 -0500
Message-ID: <007901bec496$745a8360$[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 V5.00.2314.1300
In-Reply-To: <[e-mail]>
Precedence: bulk
List-Archive: http://www.imc.org/ietf-pkix/mail-archive/
List-Unsubscribe: mailto:[e-mail]?body=unsubscribe
X-UIDL: 866903d1cfa9810a73a90e7621b7b4da

Hi,

Here are some internet-engineering comments, based on
reading this message on the context of the recent message
flow:



> -----Original Message-----
> From: Stephen Farrell [mailto:[e-mail]]
> Sent: Friday, July 02, 1999 6:03 AM
> To: [e-mail]
> Cc: [e-mail]
> Subject: Re: I-D ACTION:draft-ietf-pkix-scvp-00.txt
>
>
>
> Hi All,
>
> I'm afraid that I haven't had time to read all the mails
> on this , so forgive any repeats, but I have a number
> of fairly major problems with this draft.
>
> Starting with the goals:
>
> > - Make it easier for applications to deploy PKI based systems
>
> I'd like some examples of applications that will be deployed with
> clients that *only* support scvp - if clients have to be able
> to work in either "full" or "scvp" mode, then scvp just adds
> complexity, and shouldn't be promoted.  To me this certainly
> seems to rule out almost all mainstream Internet applications.
> (I wouldn't regard appealing to possible applications as a
> good motivation - lets not give solutions to problems that
> aren't there yet.)


The relationship of SVCP to CMP is very similar to
the motivating relationship between X400 P7 and X400 P3 protocols. In that
messaging environment, the overhead of a full P3 UA was hard
to justify - so message store concept was added, and a supporting
protocol created.

The relationship of SVCP to CMP is very similar to
the motivating relationship between X500 DAP and IETF LDAP protocols. In
that
directory enviornment, the overhead of a full DAP UA was hard
to justify - so a lightweight gateway concept was added, and a
supporting protocol created.

The motivating relationship of SVCP to CMP is very similar to
the relationship between X700 CMIP and IETF SNMP v2 protocols. In that
management environment, the overhead of a full CMIS UA was hard
to justify - so a lightweight management concept was added, and a
supporting protocol created.

It is true, as IETF doctrine suggests, that the simple solution
may actually address 90% of the needs - including security needs; and
the full solution may be less required than professional architects
may suggest. The is much evidence for this.


>
> > - Enable the PKI to be used on low-end devices such as telephones
>
> This seems spurious to me - a lot of the phones we make (being part
> of Siemens) already do quite a lot of processing involving ASN.1
> and crypto (its called GSM and we've made quite a *lot* of phones),
> they also have some serious DSPs in them, so I'd need convincing that
> path processing complexity is such an issue. (Path construction
> is a different case, but see below).

Interoperable PKIX path processing requires PKIX-complying path
contruction, and  both local and remote repository management. Not
all "phones" need be "high-end phones"; a pager accepting a PKIX-signed page
should
not be forced into high-end manufacturing and engineering, if we
are aiming at a manufacturing cost of $5, so a billion Chinese
rural folk can access this Internet technology without requiring
a world bank loan becuase the standards were over-engineered and biased
to the industrial world's infrastructure!

Remember, internet standards should be basically implementable by
a programmer-year. Of course, productization takes more
effort, but we are not here as a vendor-forum... we are
here to address the internet community who want
to interwork and communicate.

>
> OTOH, a position that the entire PKI represented by PKIX is too
> heavy is defensible, (though wrong, I'd say), but presumably
> the draft wouldn't be in PKIX if that were the authors' position.
>
> > - Allow certralization of administering PKI policies
>
> If this is a goal of the draft, (and I do agree that this is
> needed in a lot of situations), then the proposed solution fails
> to meet the goal - if you allow clients to specify all the inputs
> to the path validation algorithm and mandate that the servers
> process according to 2459 then all you've done is moved the
> CPU cycles. (Maybe I'm misreading the draft here though? Or maybe
> it doesn't say?)
>
> I also have a quite simple problem with the title: this
> doesn't look any simpler than cert path validation!
> (In fact, I'd be willing to sign a petition that no future
> drafts should include the word "simple" in their titles
> unless they're less than four pages:-).

I think the SNMP example holds here, given it
is simple but also uses BER and a ASN.1-based notation. The full CMIF model
was addressed by the IESG-policy and WG ethic, but reduced, and
a simple to implement protocol was specified.  If we were to here
use any OSI message encoding, Id have us use the SNMP BER Subset
and have it specified in the notation used in
the SNMP RFCs. A hundred implementations of this
already exist; a reusable one even comes free with Windows
and a $50  code sample book.

SNMP experience holds again.  The draft should perhaps address
only the protocol, not the required processing by
the server. There are complex MIBs, and simple MIBs in
the SNMP world. Similarly, there can and should be complex
and simple remote-validation-handlers (RVHs!) RVH
and protocol implemention should be separated, I would agree.
one such RVH is of course, validating that a path meets PKIX-QC -
before the little CEC-flag icon is authorized for display to the user...

>
> However, I do think that one of the problems the draft does try
> to address is a serious problem for PKI end entities - path
> constuction.
>
> On the face of it, there are two main hard issues for PKIX end
> entities - path validation and path constuction. Now, I'd
> argue that path validation is by far the better understood
> (by client implementors) and that we should be looking at a
> protocol to help EEs with path construction, not a protocol
> which allows various mixtures of the two.

If PKIX path validation is understood, just as with server-side
SET-PKI and cert-validating wallets, there is no reason why PKI
server-solutions cannot support less-capable and less-managed
clients with the same benefits as that this SET variety brought to that
secure payment environment. (SET deals with all
the same PKI issues as PKIX at a more stringent level
of engineered security, note.) In SET, essentially http
was used to access the server-side PKI-Client. In the IETF
we should use the SVCP direction, rather than once
again over-leverage http in a way which is now contrary
to IESG advice.


>
> A protocol to assist with path construction also has much
> less impact on security. (Basically, scvp as currently
> presented has the potential to nullify a lot of the
> security assumptions underlying a lot of deployed
> systems, so I'm quite wary of some aspects of this
> proposal, e.g. root self-certs flying about in unsigned
> messages!)

An initialization facility in the protocol is acceptable. Of course
its risks should be discussed here. Nothing stopped
TLS doing trust-point distribution in unprotected
messages, note. So, there is precedent on the current design.
Inclusion, is indeed arguable, however. SVCP over TLS
is also an approach to do trust-point distribution. Requirement
and mechanism analysis would be useful. Need is obvious...

>
> For help with path construction, I'd like a protocol where
> a client simply sends a cert plus some very constrained
> settings to a server and receives back (what the server
> thinks) is a good looking cert path, plus a reference so
> the client can ask the server later for another path for
> the same request (if the client doesn't like the first path
> returned).

SVCP is not meant to be a profile of ldap tuned to
certification-domain graph searching problems. We should profile
an ldap operation to address this need, if its required. Searching
is what directories are good at. I would expect an SVCP provider
to also in reality provide a high-end PKI-tailored directory
solution, to support other aspects of server-side PKI
management for those clients which require greater amounts
of interoperability, and therefore management support.

>
> Interestingly, path construction is also suitable for
> implementation on a server - the fact that it can be
> configured to point at the right LDAP, OCSP, whatever,...
> servers and can maintain lots of state means that such
> a server could get around all the problems clients have
> with the possible existence of multiple (potentially) valid
> paths and sub-paths.

I think we have to be careful of server-side client-state
management.


>
> My suggestion then would be to progress along the following
> lines:
>
> - split this work:
> 	- one part purely for assistance with path construction
> 	- and one part (or zero:-) to see if remote path validation
> 	  can really be made "simple"
> - loose lots of the optional fields (go for an 80% solution
>   not the full whack:-)
> - remove the "tiny" gunk entirely (I just don't buy the
>   anti-ASN.1 arguments, we've been here too often already)
>
> Regards,
> Stephen.
>
>
>
>
>
>
>



Received: from localhost (daemon@localhost) by mail.proper.com (8.8.8/8.8.5) with SMTP id JAA22039; Fri, 2 Jul 1999 09:01:34 -0700 (PDT)
Received: by mail.imc.org (bulk_mailer v1.12); Fri, 2 Jul 1999 09:01:19 -0700
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 JAA22015 for <[e-mail]>; Fri, 2 Jul 1999 09:01:17 -0700 (PDT)
Received: from bull.net (frcls6118.frcl.bull.fr [129.182.109.213]) by clbull.frcl.bull.fr (8.9.1a/8.9.1) with ESMTP id SAA17208; Fri, 2 Jul 1999 18:03:10 +0200
Message-ID: <[e-mail]>
Date: Fri, 02 Jul 1999 18:04:52 +0200
From: Denis Pinkas <[e-mail]>
Organization: Bull
X-Mailer: Mozilla 4.06 [fr] (Win95; I)
MIME-Version: 1.0
To: Bill Lattin <[e-mail]>
CC: [e-mail]
Subject: Usage of TDTs
References: <000601bec49b$747b3880$2348ffd0@lattin>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit
Precedence: bulk
List-Archive: http://www.imc.org/ietf-pkix/mail-archive/
List-Unsubscribe: mailto:[e-mail]?body=unsubscribe
X-UIDL: 3c3d9b3dd41eadc8bfc0e6a4f7864041

Bill and others,

I am watching this thread.

As far as the need of PKIX is concerned, we trust that a given TSA will give the
time up to a given (good or bad) precision. If someone does not trust a given
TSA it uses another one that it trusts. There is no need for additional proofs
(such as TDTs) for "additional trust". The trust is indicated indirectly in the
policy included in the TST. Once again the *primary* use of a TSA in PKIX is to
compare the time indicated in the TST with the time indicated in a CRL (limited
to the granularity of a second with an undefined precision).

So the use of the information, provided by a TDA, does not appear to be relevant
in that case.

Currently we can include additional data from a TDA but I have not seen
argumentations for this. The idea is not to see if there *might be* a
possibility to use that additional information, but if there is a *strong need*
for it. If yes, what for ?

Denis


> MichaelZ,
>
> I've inserted my comments in your response to Mike Duren below.
>
> > -----Original Message-----
> > From: [e-mail] [mailto:[e-mail]]
> > Sent: Thursday, July 01, 1999 21:43
> > To: [e-mail]; "[Denis.Pinkas"@bull.net]; [e-mail];
> > [e-mail]
> > Cc: [e-mail]; [e-mail]; [e-mail];
> > [e-mail]; [e-mail]
> > Subject: RE: Time Stamp: Usage of TDTs
> >
> snip
>
> > [MD]
> > >How do you prove that a TSA is time-accurate?  I don't see
> > anything in the
> > >TST that allows this, just a signature?  Because the signature is valid,
> > >does that mean the time is accurate?  Can this only be solved by placing
> > >trust in a policy or by relying on out of band information?
> >
> > [MZ]
> > Hopefully so. Otherwise why don't I just go direct to the
> > NIST-operated TSA,
> > which I'm sure provides highly accurate timing?
>
> Lattin:  From my earlier email, certainly policy will be important to the
> operation of all TSAs and TDAs.  Some applications will only require
> agreement on policy at relatively local levels (between direct participants
> and the TSA); others may require agreement on a broader scale and thus
> require access to an NTA (e.g. the NASDAQ OATS application).  The OATS
> application is one that supports both viewpoints being expressed here:
> NASDAQ could run its own TSA, but it wants the time traceable to NIST - this
> is exactly where the TDA would be applicable.  Again, I don't believe NTAs
> will enter the TSA business - they could, but (i)governments typically
> abstain from competition with corporations, and (ii) an NTA, whose business
> it is to provide time, is unlikely to want to accept the liability and
> perform the other operations associated with the TSA.
>
> snip
>
> > [MD]
> > >Why is it unreasonable to include information in the
> > Timestamping protocol
> > that allows clients to trace the time value in >the stamp to some timing
> > authority?  If the TDT can contain time values that are traceable to a
> > Timing Authority, then why >not define a protocol that allows those tokens
> > to be included in the timestamp?
> > >The TDT is an optional field.
> >
> > [MZ]
> > a TSA IS a timing authority from the client's prospective, or at least it
> > should be viewed as one. And you do not use the TSA as a source
> > of a precise
> > timing anyway. At least the initial intention was not so.
> > The prime usage of a TST is to compare the time in it to something else.
> > Consider two possible scenarios:
> > 1) comparing a TST to a high resolution time value (the bid entered the
> > system at 15'32.1.3'):
> > For such a system most likely a single TSA will be used, and it is more
> > important to know that the ordering of TST is correct (who was the first).
> > Having a TDT would not help there, as each clock, whatever carefully
> > synchronised with NTA, has its own resolution, preventing any precise
> > comparison.
> > 2)comparing a token to some 'human' time ('A document existed at 15.00
> > yesterday').
> > I do not think that synchronisation with NTA is critical here.
> >
>
> Lattin:  The primary problem the proposed TDT is solving is providing
> non-repudiatable traceability of time information from a clock back to an
> NTA.  It can enhance accuracy, but this is not its primary purpose.  If a
> TSA is using GPS as its timing source, it may be very accurate, but from a
> legal standpoint, that source of time may not be acceptable for some
> applications which may require direct traceability of time back to the
> issuing NTA.
>
> >[MZ] I'm trying to see a business case when knowing how precisely TSA clock
> is
> > synchronised with the NTA is critical, or relevant, rather then
> > satisfying a
> > curiosity of the users. Please, help me out.
>
> Lattin:  The business case is where traceablity to an NTA is required.  In
> this case, a TSA without the capability to provide traceability to an NTA
> would not be acceptable (e.g. NASDAQ OATS).  The proposed TDT will provide a
> simple way to do this.
>
> No one is disputing that local policy agreement may work for a variety of
> applications- especially today, but there are also applications today that
> require traceability to an NTA so a local trusted clock will not suffice.
> PKIX is a forward looking standard.  As more commerce and business processes
> are moved to the internet, the ability to provide a link to nationally
> recognized time sources will be increasingly important - it will facilitate
> agreement between disparate parties as to the time of an event.  Time can be
> as local or as universal as we chose to make it.  The proposed TDT is a way
> to make national time available to all local TSAs.
>
> How about opinions from others on the list?  I know you're out there...:-)
>
> Regards,
>
> Bill



Received: from localhost (daemon@localhost) by mail.proper.com (8.8.8/8.8.5) with SMTP id IAA21796; Fri, 2 Jul 1999 08:54:06 -0700 (PDT)
Received: by mail.imc.org (bulk_mailer v1.12); Fri, 2 Jul 1999 08:53:49 -0700
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 IAA21772 for <[e-mail]>; Fri, 2 Jul 1999 08:53:49 -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 IAA41308 for <[e-mail]>; Fri, 2 Jul 1999 08:57:36 -0700
Received: from scv2.apple.com (scv2.apple.com) by mailgate1.apple.com (mailgate1.apple.com- SMTPRS 2.0.15) with ESMTP id <[e-mail]> for <[e-mail]>; Fri, 02 Jul 1999 08:57:36 -0700
Received: from [17.219.25.199] ([17.219.25.199]) by scv2.apple.com (8.9.3/8.9.3) with ESMTP id IAA08288 for <[e-mail]>; Fri, 2 Jul 1999 08:57:35 -0700
Message-Id: <[e-mail]>
X-Mailer: Microsoft Outlook Express Macintosh Edition - 4.5 (0410)
Date: Fri, 02 Jul 1999 08:57:32 -0700
Subject: Re: SNACC ASN.1 DER Freeware (was RE: I-D ACTION:draft-ietf-pkix-scvp -00.txt)
From: "Aram Perez" <[e-mail]>
To: [e-mail]
MIME-Version: 1.0
X-Priority: 3
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: 7bit
Precedence: bulk
List-Archive: http://www.imc.org/ietf-pkix/mail-archive/
List-Unsubscribe: mailto:[e-mail]?body=unsubscribe
X-UIDL: 5e4a73e28caeb04b637c33d4b9d14868

John Pawling wrote:
>
> The DER-enhanced SNACC ASN.1 freeware is freely available to everyone at
> J.G. Van Dyke and Associates' (VDA) S/MIME Freeware Library (SFL) web page
> (http://www.jgvandyke.com/services/infosec/sfl.htm).  The snaccvda07.zip
> file contains SNACC v1.3 rev 0.07 ASN.1 Compiler and Library source code
> compilable for Unix and MS Windows NT/95/98.  The C++ version of SNACC has
> been enhanced by VDA to implement the Distinguished Encoding Rules.  Project
> files and makefiles are included.  This file also includes a sample test
> project demonstrating the use of the SNACC classes.  SNACC implements the
> full set of ASN.1 encoding/decoding rules, but it is pretty darn small
> already.
>
> The SNACC ASN.1 library is totally unencumbered as documented in the
> following excerpt from the SFL Public License.
>
[snip]

Having used SNACC I agree with most of what John wrote. However, the trouble
with SNACC is that is does not support the latest ASN.1. I'm pretty sure
that you cannot compile all of the PKIX ASN.1 modules with it.

Regards,
Aram Perez


Received: from localhost (daemon@localhost) by mail.proper.com (8.8.8/8.8.5) with SMTP id HAA20624; Fri, 2 Jul 1999 07:57:08 -0700 (PDT)
Received: by mail.imc.org (bulk_mailer v1.12); Fri, 2 Jul 1999 07:56:56 -0700
Received: from harrier.prod.itd.earthlink.net (harrier.prod.itd.earthlink.net [207.217.121.12]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id HAA20599 for <[e-mail]>; Fri, 2 Jul 1999 07:56:56 -0700 (PDT)
Received: from lattin (1Cust1.tnt20.sfo3.da.uu.net [208.254.224.1]) by harrier.prod.itd.earthlink.net (8.9.3/8.9.3) with SMTP id HAA09866; Fri, 2 Jul 1999 07:59:54 -0700 (PDT)
From: "Bill Lattin" <[e-mail]>
To: <[e-mail]>, <[e-mail]>, <"[Denis.Pinkas"@bull.net]>, <[e-mail]>
Cc: <[e-mail]>, <[e-mail]>, <[e-mail]>, <[e-mail]>, <[e-mail]>
Subject: RE: Time Stamp:  Usage of TDTs
Date: Fri, 2 Jul 1999 07:59:16 -0700
Message-ID: <000601bec49b$747b3880$2348ffd0@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
Importance: Normal
In-Reply-To: <[e-mail]>
Precedence: bulk
List-Archive: http://www.imc.org/ietf-pkix/mail-archive/
List-Unsubscribe: mailto:[e-mail]?body=unsubscribe
X-UIDL: 19f856616726b81adb748063be5e5b56

MichaelZ,

I've inserted my comments in your response to Mike Duren below.

> -----Original Message-----
> From: [e-mail] [mailto:[e-mail]]
> Sent: Thursday, July 01, 1999 21:43
> To: [e-mail]; "[Denis.Pinkas"@bull.net]; [e-mail];
> [e-mail]
> Cc: [e-mail]; [e-mail]; [e-mail];
> [e-mail]; [e-mail]
> Subject: RE: Time Stamp: Usage of TDTs
>
snip

> [MD]
> >How do you prove that a TSA is time-accurate?  I don't see
> anything in the
> >TST that allows this, just a signature?  Because the signature is valid,
> >does that mean the time is accurate?  Can this only be solved by placing
> >trust in a policy or by relying on out of band information?
>
> [MZ]
> Hopefully so. Otherwise why don't I just go direct to the
> NIST-operated TSA,
> which I'm sure provides highly accurate timing?


Lattin:  From my earlier email, certainly policy will be important to the
operation of all TSAs and TDAs.  Some applications will only require
agreement on policy at relatively local levels (between direct participants
and the TSA); others may require agreement on a broader scale and thus
require access to an NTA (e.g. the NASDAQ OATS application).  The OATS
application is one that supports both viewpoints being expressed here:
NASDAQ could run its own TSA, but it wants the time traceable to NIST - this
is exactly where the TDA would be applicable.  Again, I don't believe NTAs
will enter the TSA business - they could, but (i)governments typically
abstain from competition with corporations, and (ii) an NTA, whose business
it is to provide time, is unlikely to want to accept the liability and
perform the other operations associated with the TSA.

snip

> [MD]
> >Why is it unreasonable to include information in the
> Timestamping protocol
> that allows clients to trace the time value in >the stamp to some timing
> authority?  If the TDT can contain time values that are traceable to a
> Timing Authority, then why >not define a protocol that allows those tokens
> to be included in the timestamp?
> >The TDT is an optional field.
>
> [MZ]
> a TSA IS a timing authority from the client's prospective, or at least it
> should be viewed as one. And you do not use the TSA as a source
> of a precise
> timing anyway. At least the initial intention was not so.
> The prime usage of a TST is to compare the time in it to something else.
> Consider two possible scenarios:
> 1) comparing a TST to a high resolution time value (the bid entered the
> system at 15'32.1.3'):
> For such a system most likely a single TSA will be used, and it is more
> important to know that the ordering of TST is correct (who was the first).
> Having a TDT would not help there, as each clock, whatever carefully
> synchronised with NTA, has its own resolution, preventing any precise
> comparison.
> 2)comparing a token to some 'human' time ('A document existed at 15.00
> yesterday').
> I do not think that synchronisation with NTA is critical here.
>

Lattin:  The primary problem the proposed TDT is solving is providing
non-repudiatable traceability of time information from a clock back to an
NTA.  It can enhance accuracy, but this is not its primary purpose.  If a
TSA is using GPS as its timing source, it may be very accurate, but from a
legal standpoint, that source of time may not be acceptable for some
applications which may require direct traceability of time back to the
issuing NTA.

>[MZ] I'm trying to see a business case when knowing how precisely TSA clock
is
> synchronised with the NTA is critical, or relevant, rather then
> satisfying a
> curiosity of the users. Please, help me out.

Lattin:  The business case is where traceablity to an NTA is required.  In
this case, a TSA without the capability to provide traceability to an NTA
would not be acceptable (e.g. NASDAQ OATS).  The proposed TDT will provide a
simple way to do this.

No one is disputing that local policy agreement may work for a variety of
applications- especially today, but there are also applications today that
require traceability to an NTA so a local trusted clock will not suffice.
PKIX is a forward looking standard.  As more commerce and business processes
are moved to the internet, the ability to provide a link to nationally
recognized time sources will be increasingly important - it will facilitate
agreement between disparate parties as to the time of an event.  Time can be
as local or as universal as we chose to make it.  The proposed TDT is a way
to make national time available to all local TSAs.

How about opinions from others on the list?  I know you're out there...:-)

Regards,

Bill



Received: from localhost (daemon@localhost) by mail.proper.com (8.8.8/8.8.5) with SMTP id IAA20926; Fri, 2 Jul 1999 08:09:25 -0700 (PDT)
Received: by mail.imc.org (bulk_mailer v1.12); Fri, 2 Jul 1999 08:09:24 -0700
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 IAA20904 for <[e-mail]>; Fri, 2 Jul 1999 08:09:23 -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 RAA16377; Fri, 2 Jul 1999 17:12:49 +0200
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1 
Date: Fri, 02 Jul 1999 17:13:01 +0200
To: Petra Gloeckner <[e-mail]>, [e-mail]
From: Stefan Santesson <[e-mail]>
Subject: Re: Use of localityName attribute
Cc: [e-mail]
In-Reply-To: <[e-mail]>
References: <v04020a09b39070b60562@[128.89.0.110]> <[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 IAA20905
Precedence: bulk
List-Archive: http://www.imc.org/ietf-pkix/mail-archive/
List-Unsubscribe: mailto:[e-mail]?body=unsubscribe
X-UIDL: 0bc54ee28b6752eccf7606949d4d93d7

It's included.

Thank you for your help David.

/Stefan

At 06:32 PM 7/1/99 +0200, Petra Gloeckner wrote:
>Hi David,
>
>you're absolutely right. We need to add the localityName attribute.
>
>Bye - Petra
>
>David Chadwick wrote:
>> 
>> Stefan,
>> 
>> I need to request a change to the qualified certificate draft to allow
>> the use of the localityName attribute to be used to unambiguously
>> identify a subject and issuer in a DN. The UK National Health
>> Service Standard for Directory Services requires the use of locality
>> name to unambiguously identify different organisational units within
>> the NHS. For example, there are literally dozens of St Mary's
>> Hospitals within the UK NHS, so that O and OU are insufficient as
>> differentiators. Consequently localityName, based on the UK Post
>> Office defined localities, is used to differentiate between them (we
>> do not use the full postal address as this is too cumbersome.)
>> 
>> As the QC draft stands at the moment, (as I read it), the use of
>> localityName as currently defined by the NHS would not be allowed
>> as a differentiator.
>> 
>> The offending sections are:
>> 
>> 3.1.1 Issuer -  allows for state or province name but not for
>> localityName. We request that localityName be added to this section.
>> 
>> 3.1.2 Subject - allows postalAddress but not localityName and states
>> "Other attributes may be present but MUST NOT be necessary to
>> distinguish the subject name from other subject names within the
>> issuer domain."
>> 
>> This effectively precludes localityName from being used to
>> unambiguously differentiate between hospital. We request that
>> localityName be added to the MAY list.
>> 
>> Regards
>> David
>> 
>> ***************************************************
>> 
>> David Chadwick
>> IT Institute, University of Salford, Salford M5 4WT
>> Tel [phone]  Fax [phone]
>> *NEW* Mobile [phone] *NEW*
>> Email [e-mail]
>> Home Page  http://www.salford.ac.uk/its024/chadwick.htm
>> Understanding X.500  http://www.salford.ac.uk/its024/X500.htm
>> X.500/LDAP Seminars http://www.salford.ac.uk/its024/seminars.htm
>> Entrust key validation string MLJ9-DU5T-HV8J
>> 
>> ***************************************************

-------------------------------------------------------------------
Stefan Santesson                <[e-mail]>
Accurata 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 localhost (daemon@localhost) by mail.proper.com (8.8.8/8.8.5) with SMTP id IAA21170; Fri, 2 Jul 1999 08:16:11 -0700 (PDT)
Received: by mail.imc.org (bulk_mailer v1.12); Fri, 2 Jul 1999 08:16:10 -0700
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 IAA21148 for <[e-mail]>; Fri, 2 Jul 1999 08:16:09 -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 RAA16448 for <[e-mail]>; Fri, 2 Jul 1999 17:19:55 +0200
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1 
Date: Fri, 02 Jul 1999 17:20:07 +0200
To: <[e-mail]>
From: Stefan Santesson <[e-mail]>
Subject: Preversion of the new Qualified Certificates draft
In-Reply-To: <[e-mail]>
References: <[e-mail]> <[e-mail]> <v04020a09b39070b60562@[128.89.0.110]> <[e-mail]> <v04020a11b38f168558d5@[128.33.238.33]> <[e-mail]> <v04020a10b38b45a34213@[128.33.238.203]> <[e-mail]> <v04020a0fb383271ddc78@[128.89.0.110]> <[e-mail]> <41ACC8CF2BF1D011AEDD00805F31E54C02F232CD@AUNT15>
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 IAA21149
Precedence: bulk
List-Archive: http://www.imc.org/ietf-pkix/mail-archive/
List-Unsubscribe: mailto:[e-mail]?body=unsubscribe
X-UIDL: 04163c1afc46a0c5da08f6758c7baf96

I have prepared a pre version of the next Qualified Certificates draft.

It can be obtained from:

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

For updated information about settled and unsettled topics, pleas also see:

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

We will finalize the draft under the Oslo meeting. Please submit comments
to the list before the PKIX meeting in Oslo.

After this I hope that we are ready for last call.

/Stefan

-------------------------------------------------------------------
Stefan Santesson                <[e-mail]>
Accurata 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 localhost (daemon@localhost) by mail.proper.com (8.8.8/8.8.5) with SMTP id GAA19558; Fri, 2 Jul 1999 06:37:14 -0700 (PDT)
Received: by mail.imc.org (bulk_mailer v1.12); Fri, 2 Jul 1999 06:37:10 -0700
Received: from wfhqex05.wangfed.com (netva01.wangfed.com [206.137.100.2]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id GAA19536 for <[e-mail]>; Fri, 2 Jul 1999 06:37:09 -0700 (PDT)
Received: by wfhqex05.wangfed.com with Internet Mail Service (5.5.2448.0) id <NRPZ282Q>; Fri, 2 Jul 1999 09:40:27 -0400
Message-ID: <33BD629222C0D211B6DB0060085ACF31360812@WFHQEX03>
From: "Pawling, John" <[e-mail]>
To: [e-mail]
Subject: SNACC ASN.1 DER Freeware (was RE: I-D ACTION:draft-ietf-pkix-scvp -00.txt)
Date: Fri, 2 Jul 1999 09:40:28 -0400 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2448.0)
Content-Type: text/plain; charset="iso-8859-1"
Precedence: bulk
List-Archive: http://www.imc.org/ietf-pkix/mail-archive/
List-Unsubscribe: mailto:[e-mail]?body=unsubscribe
X-UIDL: 0f48ab1f446c74481b8e30956ee2e522

All,

The DER-enhanced SNACC ASN.1 freeware is freely available to everyone at
J.G. Van Dyke and Associates' (VDA) S/MIME Freeware Library (SFL) web page
(http://www.jgvandyke.com/services/infosec/sfl.htm).  The snaccvda07.zip
file contains SNACC v1.3 rev 0.07 ASN.1 Compiler and Library source code
compilable for Unix and MS Windows NT/95/98.  The C++ version of SNACC has
been enhanced by VDA to implement the Distinguished Encoding Rules.  Project
files and makefiles are included.  This file also includes a sample test
project demonstrating the use of the SNACC classes.  SNACC implements the
full set of ASN.1 encoding/decoding rules, but it is pretty darn small
already.

The SNACC ASN.1 library is totally unencumbered as documented in the
following excerpt from the SFL Public License. 

"+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

           SNACC Abstract Syntax Notation.1 (ASN.1) Software 

The SNACC ASN.1 software is composed of the SNACC Compiler and the SNACC 
Library.  The SNACC Compiler is covered by the attached GNU General Public 
License (GPL).  The GPL states that the subject software may be freely 
distributed if the distributor: provides all source code for the subject 
software; does not charge for the use of the subject software; and provides
a 
copy of the GPL along with the subject software. The SNACC Library software
is 
completely unencumbered.  None of the GNU public licenses apply to the SNACC

Library.

Under contract to the U.S. Government, J.G. Van Dyke and Associates, Inc
(VDA), 
has made enhancements to the SNACC Compiler and Library.  VDA has clearly
marked 
all enhancements made to the SNACC Compiler as required by the GNU GPL.  The
SFL 
Public License applies to the enhancements that VDA has made to the SNACC 
Compiler and Library.  VDA has met the requirements of the GNU GPL
including: 
providing all source code for the enhanced SNACC Compiler; freely
distributing 
the enhanced SNACC Compiler; and providing a copy of the GPL along with the 
enhanced SNACC Compiler. 

++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
++"

The GNU General Public License can be retrieved from
http://www.fsf.org/copyleft/gpl.html.  The SFL public license can be
retrieved from the aforementioned VDA SFL web page.

============================================================
John Pawling, [e-mail]                             
J.G. Van Dyke & Associates, Inc.
www.jgvandyke.com         
============================================================


Received: from localhost (daemon@localhost) by mail.proper.com (8.8.8/8.8.5) with SMTP id EAA18463; Fri, 2 Jul 1999 04:12:03 -0700 (PDT)
Received: by mail.imc.org (bulk_mailer v1.12); Fri, 2 Jul 1999 04:11:50 -0700
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 EAA18437 for <[e-mail]>; Fri, 2 Jul 1999 04:11:49 -0700 (PDT)
Received: from mail0.sse.ie (actually localhost) by mail0.sse.ie; Fri, 2 Jul 1999 12:03:35 +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 MAA26653; Fri, 2 Jul 1999 12:03:34 +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 MAA26768; Fri, 2 Jul 1999 12:03:20 +0100 (BST)
Message-Id: <[e-mail]>
X-Mailer: exmh version 1.6.9 8/22/96
To: [e-mail]
cc: [e-mail]
Subject: Re: I-D ACTION:draft-ietf-pkix-scvp-00.txt 
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Date: Fri, 02 Jul 1999 12:03:20 +0100
From: Stephen Farrell <[e-mail]>
Precedence: bulk
List-Archive: http://www.imc.org/ietf-pkix/mail-archive/
List-Unsubscribe: mailto:[e-mail]?body=unsubscribe
X-UIDL: f27b82a0cd958074e7b2ce4ce7632abb

Hi All,

I'm afraid that I haven't had time to read all the mails
on this , so forgive any repeats, but I have a number
of fairly major problems with this draft.

Starting with the goals:

> - Make it easier for applications to deploy PKI based systems

I'd like some examples of applications that will be deployed with
clients that *only* support scvp - if clients have to be able 
to work in either "full" or "scvp" mode, then scvp just adds 
complexity, and shouldn't be promoted.  To me this certainly 
seems to rule out almost all mainstream Internet applications. 
(I wouldn't regard appealing to possible applications as a 
good motivation - lets not give solutions to problems that 
aren't there yet.)

> - Enable the PKI to be used on low-end devices such as telephones

This seems spurious to me - a lot of the phones we make (being part
of Siemens) already do quite a lot of processing involving ASN.1
and crypto (its called GSM and we've made quite a *lot* of phones), 
they also have some serious DSPs in them, so I'd need convincing that
path processing complexity is such an issue. (Path construction
is a different case, but see below).

OTOH, a position that the entire PKI represented by PKIX is too 
heavy is defensible, (though wrong, I'd say), but presumably 
the draft wouldn't be in PKIX if that were the authors' position.  

> - Allow certralization of administering PKI policies

If this is a goal of the draft, (and I do agree that this is 
needed in a lot of situations), then the proposed solution fails
to meet the goal - if you allow clients to specify all the inputs
to the path validation algorithm and mandate that the servers
process according to 2459 then all you've done is moved the
CPU cycles. (Maybe I'm misreading the draft here though? Or maybe
it doesn't say?)

I also have a quite simple problem with the title: this 
doesn't look any simpler than cert path validation! 
(In fact, I'd be willing to sign a petition that no future
drafts should include the word "simple" in their titles
unless they're less than four pages:-).

However, I do think that one of the problems the draft does try 
to address is a serious problem for PKI end entities - path 
constuction.

On the face of it, there are two main hard issues for PKIX end 
entities - path validation and path constuction. Now, I'd
argue that path validation is by far the better understood 
(by client implementors) and that we should be looking at a 
protocol to help EEs with path construction, not a protocol 
which allows various mixtures of the two.

A protocol to assist with path construction also has much
less impact on security. (Basically, scvp as currently
presented has the potential to nullify a lot of the
security assumptions underlying a lot of deployed 
systems, so I'm quite wary of some aspects of this 
proposal, e.g. root self-certs flying about in unsigned 
messages!)

For help with path construction, I'd like a protocol where 
a client simply sends a cert plus some very constrained 
settings to a server and receives back (what the server 
thinks) is a good looking cert path, plus a reference so 
the client can ask the server later for another path for 
the same request (if the client doesn't like the first path
returned).

Interestingly, path construction is also suitable for
implementation on a server - the fact that it can be 
configured to point at the right LDAP, OCSP, whatever,...
servers and can maintain lots of state means that such
a server could get around all the problems clients have
with the possible existence of multiple (potentially) valid 
paths and sub-paths.

My suggestion then would be to progress along the following
lines:

- split this work: 
	- one part purely for assistance with path construction
	- and one part (or zero:-) to see if remote path validation 
	  can really be made "simple"
- loose lots of the optional fields (go for an 80% solution
  not the full whack:-)
- remove the "tiny" gunk entirely (I just don't buy the
  anti-ASN.1 arguments, we've been here too often already)

Regards,
Stephen.







Received: from localhost (daemon@localhost) by mail.proper.com (8.8.8/8.8.5) with SMTP id UAA24209; Thu, 1 Jul 1999 20:18:41 -0700 (PDT)
Received: by mail.imc.org (bulk_mailer v1.12); Thu, 1 Jul 1999 20:18:37 -0700
Received: from emerald.lightlink.com ([e-mail] [205.232.34.14]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id UAA24173 for <[e-mail]>; Thu, 1 Jul 1999 20:18:36 -0700 (PDT)
Received: from mduren (cable20-175.gte.net [24.96.49.175]) by emerald.lightlink.com (8.8.8/8.8.8) with SMTP id XAA25551; Thu, 1 Jul 1999 23:21:58 -0400
Message-ID: <001c01bec439$f33884a0$[e-mail]>
Reply-To: "Michael Duren" <[e-mail]>
From: "Michael Duren" <[e-mail]>
To: <[e-mail]>, <"[Denis.Pinkas"@bull.net]>, <[e-mail]>, <[e-mail]>
Cc: <[e-mail]>, <[e-mail]>, <[e-mail]>, <[e-mail]>, <[e-mail]>
Subject: Re: Time Stamp:  Usage of TDTs
Date: Thu, 1 Jul 1999 23:21:03 -0400
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 4.72.3110.1
X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3
Precedence: bulk
List-Archive: http://www.imc.org/ietf-pkix/mail-archive/
List-Unsubscribe: mailto:[e-mail]?body=unsubscribe
X-UIDL: e3df0fde8e74e4bc766b1c0ea7da9fc9

Thanks for the response.  I know what you mean about the time difference, so
I decided to stay up a bit later tonight.  (So please excuse a typo or tw0)

>Michael,
>
>Thinking about two companies - if they are really concerned about mutual
>trust, why would not they just use the same TSA? Which they both agree
upon,
>and is reliable and time-accurate.

How do you prove that a TSA is time-accurate?  I don't see anything in the
TST that allows this, just a signature?  Because the signature is valid,
does that mean the time is accurate?  Can this only be solved by placing
trust in a policy or by relying on out of band information?

>
>Also, if a company runs its own TDA, a TDT can be included into a TST
>upfront, by merging the TDT with the data before sending a request to the
>TSA. The TDT can be hashed together with data, or it can be just appended
to
>the hash.
>
><<Though I do not quite understand a particular value of a private TDA - if
>it is a TTP, then it should not be the company's own. If it is not a TTP,
>then who would trust it and why would I need to attach it to anything? And
>it can not attest to the accuracy of time produced by the TSA.
>Non-repudiation? can be done without TDT. Could you please explain?>>
>
>Another matter with a TDA producing verification for the quality of time by
>TSA: could it happen that a TDA decides not to verify the time quality of a
>particular TST? I guess so, otherwise why to have it at all, if it always
>OKs everything. In a situation like that, what should the TSA do? What
>should a client do, when it gets a TST that includes a
>'time-was-not-verified' TDT? Getting quite messy, don't you think?

Sure that could be messy.  (Lots of things are messy)  It could be that a
TST should have a TDT in it but does not (perhaps the request was denied, or
the TDA was out of service, or the TDT signature could be invalid).  But
this problem you have introduced is not brought about by the existence of a
TDA.  What ever mechanism that is being used to prove to the world that a
TSA's time is valid can fail or be questioned.  Perhaps a TSA is to undergo
a strict audit as part of some contractual obligation, what happens if the
auditor is late or fails to show up or if the actual time is shown to be
inaccurate; I think that is just as messy if not more so.  At least with the
proposed use of TDTs, the client can instantly verify the presence and
validity of the TDT information and then resubmit or incidate a problem
right away.  The result of an audit or out-of-band information regarding the
accuracy of a TSA's clock may not be readily available.  However, I am sure
that a company that has a TSA with an invalid clock will run out and tell
the world right away.

(BTW, it has not been suggested that the TDA holds any authority over the
time of a TSA).

>
>I appreciate that there could be quite exotic situations, however. It is
>just questionable if the standard should be overcomplicated to cater for
>something that might never be even used, or can be achieved by other means.
>But this is a matter of taste, I reckon.

Why would it take an "exotic situation" before NTA traceable time is
required?  I think Bill pointed out situations where this may be useful now.

Why is it unreasonable to include information in the Timestamping protocol
that allows clients to trace the time value in the stamp to some timing
authority?  If the TDT can contain time values that are traceable to a
Timing Authority, then why not define a protocol that allows those tokens to
be included in the timestamp?

The TDT is an optional field.

Hope you have not been waiting too long.

Mike Duren





Received: from localhost (daemon@localhost) by mail.proper.com (8.8.8/8.8.5) with SMTP id VAA03730; Thu, 1 Jul 1999 21:41:06 -0700 (PDT)
Received: by mail.imc.org (bulk_mailer v1.12); Thu, 1 Jul 1999 21:41:03 -0700
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 VAA03700 for <[e-mail]>; Thu, 1 Jul 1999 21:41:01 -0700 (PDT)
From: [e-mail]
Received: from sydneymail1.baltimore.com.au (sydneymail1.jp.zergo.com.au [192.168.71.5]) by stargate.zergo.com.au (8.9.1/8.8.7) with ESMTP id OAA12689; Fri, 2 Jul 1999 14:46:45 +1000
Received: by sydneymail1.jp.zergo.com.au with Internet Mail Service (5.5.2448.0) id <3B34YZFX>; Fri, 2 Jul 1999 14:43:23 +1000
Message-ID: <[e-mail]>
To: [e-mail], "[Denis.Pinkas"@bull.net], [e-mail], [e-mail]
Cc: [e-mail], [e-mail], [e-mail], [e-mail], [e-mail]
Subject: RE: Time Stamp:  Usage of TDTs
Date: Fri, 2 Jul 1999 14:43:23 +1000 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2448.0)
Content-Type: text/plain; charset="iso-8859-1"
Precedence: bulk
List-Archive: http://www.imc.org/ietf-pkix/mail-archive/
List-Unsubscribe: mailto:[e-mail]?body=unsubscribe
X-UIDL: 83dd5c74fd0f8fb724dd303fa86d6ec9

Mike, I appreciate your prompt reply. I hope you did not have to stay too
late.

[MD]
>How do you prove that a TSA is time-accurate?  I don't see anything in the
>TST that allows this, just a signature?  Because the signature is valid,
>does that mean the time is accurate?  Can this only be solved by placing
>trust in a policy or by relying on out of band information?

[MZ]
Hopefully so. Otherwise why don't I just go direct to the NIST-operated TSA,
which I'm sure provides highly accurate timing?

[MD]
>At least with the proposed use of TDTs, the client can instantly verify the
presence and validity of the TDT information >and then resubmit or incidate
a problem right away.  The result of an audit or out-of-band information
regarding the
>accuracy of a TSA's clock may not be readily available.  However, I am sure
that a company that has a TSA with an invalid >clock will run out and tell
the world right away.
>(BTW, it has not been suggested that the TDA holds any authority over the
time of a TSA).

[MZ]
TSA, by definition, is a Trusted Third Party. It means that you trust its
signature, its policy, and its diligence in abiding to its policy. What
makes you trust TDA more then TSA? Having a guard over the guard is a
burglar's delight :)
However, I do agree that some kind of a standard audit body may need to be
defined and established (NIST-based?) This TSA-auditor would periodically
and randomly check TSAs and issue 'quality ribbons', which the TSA can
attach to its policy. Clients should be able to see the results of the
audits and to initiate an audit if doubtful about quality of TSTs.

[MD]
>Why is it unreasonable to include information in the Timestamping protocol
that allows clients to trace the time value in >the stamp to some timing
authority?  If the TDT can contain time values that are traceable to a
Timing Authority, then why >not define a protocol that allows those tokens
to be included in the timestamp?
>The TDT is an optional field.

[MZ]
a TSA IS a timing authority from the client's prospective, or at least it
should be viewed as one. And you do not use the TSA as a source of a precise
timing anyway. At least the initial intention was not so. 
The prime usage of a TST is to compare the time in it to something else.
Consider two possible scenarios:
1) comparing a TST to a high resolution time value (the bid entered the
system at 15'32.1.3'):
For such a system most likely a single TSA will be used, and it is more
important to know that the ordering of TST is correct (who was the first).
Having a TDT would not help there, as each clock, whatever carefully
synchronised with NTA, has its own resolution, preventing any precise
comparison.
2)comparing a token to some 'human' time ('A document existed at 15.00
yesterday').
I do not think that synchronisation with NTA is critical here.

I'm trying to see a business case when knowing how precisely TSA clock is
synchronised with the NTA is critical, or relevant, rather then satisfying a
curiosity of the users. Please, help me out.

Sincerely
MichaelZ


Received: from localhost (daemon@localhost) by mail.proper.com (8.8.8/8.8.5) with SMTP id XAA10207; Thu, 1 Jul 1999 23:40:55 -0700 (PDT)
Received: by mail.imc.org (bulk_mailer v1.12); Thu, 1 Jul 1999 23:40:49 -0700
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 XAA10171 for <[e-mail]>; Thu, 1 Jul 1999 23:40:48 -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 IAA08305; Fri, 2 Jul 1999 08:44:24 +0200
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1 
Date: Fri, 02 Jul 1999 08:44:35 +0200
To: Hannu Nikkanen <[e-mail]>, <[e-mail]>
From: Stefan Santesson <[e-mail]>
Subject: Re: PolicyStatements ewxtension in Qualified Certificates
In-Reply-To: <[e-mail]>
References: <[e-mail]> <v04020a09b39070b60562@[128.89.0.110]> <[e-mail]> <v04020a11b38f168558d5@[128.33.238.33]> <[e-mail]> <v04020a10b38b45a34213@[128.33.238.203]> <[e-mail]> <v04020a0fb383271ddc78@[128.89.0.110]> <[e-mail]> <41ACC8CF2BF1D011AEDD00805F31E54C02F232CD@AUNT15>
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 XAA10174
Precedence: bulk
List-Archive: http://www.imc.org/ietf-pkix/mail-archive/
List-Unsubscribe: mailto:[e-mail]?body=unsubscribe
X-UIDL: fcb4b551cb6e383237ac0a7fc0ef4a40

There are 2 ways.

1) For names stored in the PersonalData field in the subjectAltName
extension you use different attributes for pseudonyms and real names.

2) For names stored in the subject field the identification of semantics is
indirect, either by examining the equivalent name in the personalData
field, if present, or by implicit knowledge identified by a policy identifier.

/Stefan

At 03:05 AM 7/2/99 +0300, Hannu Nikkanen wrote:
>Hi,
>
>how will you handle identification of "real" vs pseudonym?
>
>Hannu
>
>At 00:24 29.6.1999 +0200, Stefan Santesson wrote:
>>All,
>>
>>I conclude from various on-list and off-list discussions that the best way
>>to solve inclusion of statements related to legal frameworks in a Qualified
>>Certificate, is to provide this functionality in a private extension.
>>
>>Three statements has been discussed related to the EU-directive:
>>
>>1) Inclusion of a reliance limit (how much you should rely on the
>>certificate. Note that this has NOTHING to do with how much you should rely
>>on the certified subject).
>>2) Inclusion of a statement declaring that the certificate is a Qualified
>>Certificate according to a legal framework (In case of the EU-directive,
>>that the certificate meets Annex I and are issued according to Annex II)
>>2) Inclusion of a statement, limiting the area of use of the certificate.
>>
>>I have earlier posted a proposal for such an extension. The current
>>proposal is:
>>
>>    PolicyStatement  EXTENSION ::= {
>>      SYNTAX             PolicyStatementSyntax
>>      IDENTIFIED BY      id-pe-PolicyStatement }
>>
>>    id-pe-policyStatement          OBJECT IDENTIFIER ::= { id-pe 3 }
>>    -- This is  only a proposed OID. It is not assigned yet.
>>
>>    PolicyStatementSyntax ::= SEQUENCE OF Statement
>>   
>>    Statement ::= SEQUENCE {
>>        StatementId        OBJECTIDENTIFIER
>>        StatementInfo      ANY DEFINED BY StatementId OPTIONAL}
>>
>>As these types of statements are policy statements, the QC standard SHALL
>>require that included statements are not in conflict with any policy
>>identified in the policy extension.
>>
>>Stephen Kent replied to the last proposal with:
>>
>>At 05:58 PM 6/18/99 -0400, Stephen Kent wrote:
>>>Stefan,
>>>
>>>This would make folks happy who hated the use of policy qualifiers for
>>>this, and address the incorporation by reference concerns too. One
>>>question: why do we need the "Any Defined by: here?  I'd rather not leave
>>>the hole for folks to incorporate text directly, instead of by pointer and
>>>hash.  why not replace the statement by those two data items?
>>>
>>>Please bring it to the list.
>>>
>>>Steve
>>
>>The answer to this is that the StatmentInfo may be required in order to
>>make a good structure for several statements. I.e. one OID may define that
>>StatementInfo contains a reliance limit specified using the ISO structure
>>for monetary value  (expressed before), and another OID may define that the
>>StatementInfo contains information regarding restrictions of usage (e.g.
>>only for banking applications).
>>
>>So this is a 2 step approach, but can also be used as an 1 step approach in
>>cases where an exact statement can be identified by a single OID. In the
>>latter case the StatementInfo is omitted.
>>
>>Before I put this in the specification I would like some final reactions on
>>this.
>>
>>/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
>>-------------------------------------------------------------------

-------------------------------------------------------------------
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 localhost (daemon@localhost) by mail.proper.com (8.8.8/8.8.5) with SMTP id SAA10076; Thu, 1 Jul 1999 18:07:00 -0700 (PDT)
Received: by mail.imc.org (bulk_mailer v1.12); Thu, 1 Jul 1999 18:06:57 -0700
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 SAA10053; Thu, 1 Jul 1999 18:06:54 -0700 (PDT)
From: [e-mail]
Received: from sydneymail1.baltimore.com.au (sydneymail1.jp.zergo.com.au [192.168.71.5]) by stargate.zergo.com.au (8.9.1/8.8.7) with ESMTP id LAA09249; Fri, 2 Jul 1999 11:12:48 +1000
Received: by sydneymail1.jp.zergo.com.au with Internet Mail Service (5.5.2448.0) id <3B34YZBJ>; Fri, 2 Jul 1999 11:09:26 +1000
Message-ID: <[e-mail]>
To: [e-mail], [e-mail]
Subject: RE: I-D ACTION:draft-ietf-pkix-scvp-00.txt
Date: Fri, 2 Jul 1999 11:09:26 +1000 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2448.0)
Content-Type: text/plain; charset="iso-8859-1"
Precedence: bulk
List-Archive: http://www.imc.org/ietf-pkix/mail-archive/
List-Unsubscribe: mailto:[e-mail]?body=unsubscribe
X-UIDL: ce183d28a1b1254ebeb446b3d5cc008b

All, 
Since the discussion started, have we received any 'at last' greetings from
small device manufactures? They should be the first to reply and the
majority among the participants. Where are you, guys??? Aren't you that much
concerned about complexity of handling ASN.1?

Would love to hear from anybody from the 'small-devices' camp who was
stopped on their way by the science of ASN.1 parsing. I appreciate that
information could be proprietary, but just give us a hint. 

Otherwise, I'm not sure we are talking the reality here, proposing a
'simple' alternative to ASN.

Simple (shareware?) ASN.1 parser sounds cool indeed. Thanks for
volunteering, David.

Regards

Michael Zolotarev



-----Original Message-----
From: Paul Hoffman / IMC [mailto:[e-mail]]
Sent: Friday, July 02, 1999 5:07 AM
To: [e-mail]
Subject: RE: I-D ACTION:draft-ietf-pkix-scvp-00.txt


At 02:39 PM 7/1/1999 -0400, David P. Kemp wrote:
>Sorry, but the idea of a protocol that says "here is a certificate,
>give me the public key" just makes me gag.

Um, have you read the draft? The protocol gives back much more than that. 
Reading the draft may help prevent future gagging.

>   What device has enough oomph
>to run a protocol engine but not enough to extract the key from an
>X.509 cert?

Probably none; the protocol returns much more than the key. There are lots 
of devices who do not have the oomph to do good path validation with all of 
the constraints. Getting just the public key is not interesting, given that 
you want to validate it.

--Paul Hoffman, Director
--Internet Mail Consortium


Received: from localhost (daemon@localhost) by mail.proper.com (8.8.8/8.8.5) with SMTP id RAA09644; Thu, 1 Jul 1999 17:37:30 -0700 (PDT)
Received: by mail.imc.org (bulk_mailer v1.12); Thu, 1 Jul 1999 17:37:25 -0700
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 RAA09619 for <[e-mail]>; Thu, 1 Jul 1999 17:37:17 -0700 (PDT)
From: [e-mail]
Received: from sydneymail1.baltimore.com.au (sydneymail1.jp.zergo.com.au [192.168.71.5]) by stargate.zergo.com.au (8.9.1/8.8.7) with ESMTP id KAA08675; Fri, 2 Jul 1999 10:40:54 +1000
Received: by sydneymail1.jp.zergo.com.au with Internet Mail Service (5.5.2448.0) id <3B34YZAT>; Fri, 2 Jul 1999 10:37:32 +1000
Message-ID: <[e-mail]>
To: [e-mail], "[Denis.Pinkas"@bull.net], [e-mail], [e-mail]
Cc: [e-mail], [e-mail], [e-mail], [e-mail], [e-mail]
Subject: RE: Time Stamp:  Usage of TDTs
Date: Fri, 2 Jul 1999 10:37:31 +1000 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2448.0)
Content-Type: text/plain; charset="iso-8859-1"
Precedence: bulk
List-Archive: http://www.imc.org/ietf-pkix/mail-archive/
List-Unsubscribe: mailto:[e-mail]?body=unsubscribe
X-UIDL: 043c9d9ff8a641acbfdeb4edd7aba911

Michael,

Thinking about two companies - if they are really concerned about mutual
trust, why would not they just use the same TSA? Which they both agree upon,
and is reliable and time-accurate.

Also, if a company runs its own TDA, a TDT can be included into a TST
upfront, by merging the TDT with the data before sending a request to the
TSA. The TDT can be hashed together with data, or it can be just appended to
the hash. 

<<Though I do not quite understand a particular value of a private TDA - if
it is a TTP, then it should not be the company's own. If it is not a TTP,
then who would trust it and why would I need to attach it to anything? And
it can not attest to the accuracy of time produced by the TSA.
Non-repudiation? can be done without TDT. Could you please explain?>>

Another matter with a TDA producing verification for the quality of time by
TSA: could it happen that a TDA decides not to verify the time quality of a
particular TST? I guess so, otherwise why to have it at all, if it always
OKs everything. In a situation like that, what should the TSA do? What
should a client do, when it gets a TST that includes a
'time-was-not-verified' TDT? Getting quite messy, don't you think?

I appreciate that there could be quite exotic situations, however. It is
just questionable if the standard should be overcomplicated to cater for
something that might never be even used, or can be achieved by other means.
But this is a matter of taste, I reckon.

Waiting... 

MichaelZ

PS Pity it is 14+ hours time difference between most of you guys and me.
What is the benefit of having fast e-mail, after all? :-)


-----Original Message-----
From: Michael Duren [mailto:[e-mail]]
Sent: Friday, July 02, 1999 2:56 AM
To: [e-mail]; Denis.Pinkas; [e-mail]; Bill
Lattin
Cc: Chet Hosmer; David Robinson; Ron Holm; Greg Dowd; T. Mark Hastings
Subject: Re: Time Stamp: Usage of TDTs


I agree with Bill that a TDA could issue tokens in the same way that a TSA
does.  His point about liability and business issues is very true to life.

Going back to the definition of a TDT, the TDT to TSA relationship is many
to one.  The TDT concept allows for collaboration of temporal information
from more than one source.  Since the TDT is also signed, this collaboration
greatly strengthens the TSA trust model.  With this in mind, a TST can
include temporal information from more that one NTA-authenticated TDA.  In
addition, companies and organizations might have their own TDA.  Policies
then could be defined that specify what TDA's must be included in a given
timestamp.

To move to a real life example, if company X and Y are doing business and
those companies reside in different countries, would it make sense for them
to obtain timestamps that are traceable to their respective NTA?  Also,
perhaps one or both companies maintains their own TDA, would it be
reasonable for the timestamping standard to allow for inclusion of their own
TDTs in TSTs that involve their company?

Feedback is welcomed.

Sincerely,

Mike Duren



-----Original Message-----
From: Bill Lattin <[e-mail]>
To: [e-mail] <[e-mail]>; Denis.Pinkas
<"[Denis.Pinkas"@bull.net]>; [e-mail]
<[e-mail]>
Cc: T. Mark Hastings <[e-mail]>; [e-mail]
<[e-mail]>; [e-mail] <[e-mail]>;
[e-mail] <[e-mail]>; [e-mail] <[e-mail]>
Date: Thursday, July 01, 1999 10:41 AM
Subject: RE: Time Stamp: Usage of TDTs


>Michael,
>
>I suppose that if a TDA issuing this type of TDT wanted to perform the
other
>activities associated with a TSA it could; however, I don't necessarily see
>a merging of the two since the business issues associated with each
>(liability, customer support, application interfaces, policy support, etc)
>are quite different.  Also, not all applications requiring a time stamp nee
d
>that level of accuracy - hence the variation in service offerings I
>previously mentioned.
>
>Cheers,
>
>Bill
>
>> -----Original Message-----
>> From: [e-mail] [mailto:[e-mail]]
>> Sent: Wednesday, June 30, 1999 17:23
>> To: [e-mail]; Denis.Pinkas; [e-mail]
>> Cc: [e-mail]; [e-mail]; [e-mail];
>> [e-mail]
>> Subject: RE: Time Stamp: Usage of TDTs
>>
>>
>> Bill,
>>
>> Ok, another question: If one day NIST will implement TSA services itself,
>> would I, as a client, need a TDT in the TST produced by a NIST server? I
>> guess no.
>> In general case, if a TDA can attest to the quality of time (because it
>> knows it better, presumably), what stops it to provide TSA
>> services itself?
>> So the clients can go 'right to the source', and get a 100%
>> guaranteed pure
>> time reference, instead of having to worry about secondary verification,
>> etc.
>>
>> Waiting for replies...
>>
>> Regards
>> MichaelZ
>>
>>
>> -----Original Message-----
>> From: Bill Lattin [mailto:[e-mail]]
>> Sent: Thursday, July 01, 1999 7:12 AM
>> To: [e-mail]; "Denis.Pinkas[Denis.Pinkas"@bull.net];
>> [e-mail]
>> Cc: [e-mail]; [e-mail]; [e-mail];
>> [e-mail]
>> Subject: RE: Time Stamp: Usage of TDTs
>>
>>
>> Michael,
>>
>> Thanks for the feedback.
>>
>> Depending on the application, a client could be very interested in
>> "certified evidence" being located in a TST.  For example, in a currency
>> arbitrage or stock trade situation one coud envisage being able to prove
>> that a trade was placed at a certain time.  The real question is what
>> evidence is good enough?  Is it a contractual agreement that the local
>> TSA's clock is sufficently accurate and precise or is will there be a
>> mandate to use the clock from a National Timing Authority?
>>
>> The answer is both.  We are not advocating that this type of TDT replace
a
>> local TSA clock; both models are valid.  We just want to enable the use
of
>> the National Timing Authority clocks since we believe that a number of
>> applications will insist on having time traceable to them.  As a current
>> example (although one for which PKIX time stamps will be too late for the
>> initial phases) is the NASDAQ OATS system.  This order tracking system is
>> required to use timing from NIST (the US' NTA).  The healthcare system in
>> the US is also extremely sensitive to time, and we expect that many new
>> applications will need to be linked to an NTA timing source rather than a
>> local source.
>>
>> Further, I'm sure we all agree that the timeStampToken needs to be a
>> persistent data object.  For example, e-mail would normally be
>> considered to
>> have low requirements for time-stamp trust.  However, 3 years
>> down the road,
>> a given e-mail and its time of origin may be pivotal in a legal case.  If
>> the trust of the time in the timeStampToken can be embodied with
>> a party in
>> addition to the entity possessing the TSA, the timeStampToken can better
>> meet the requirement to be a persistent data object.
>>
>> You are right that a request of a single TDT does not guarantee future
>> performance from the TSA.  For applications that need
>> traceability to NIST,
>> a TDT will be needed per time stamp.  This is an important extra
>> benefit, a
>> TST with its own instance of a TDT can provide 'guaranteed' time
>> independent
>> of the clock within the TSA.  Other applications, which are not as
>> sensitive, can operate as you have suggested - by agreement on policy
that
>> the TSA is doing the right thing.
>>
>> The bottom line is that the use of a TDT in this manner enables a
>> new class
>> of applications which require explicit, provable traceability (with
>> associated audit trails) to an NTA.  The TSA operation is enhanced
because
>> it can offer multiple types of service.
>>
>> Cheers,
>>
>> Bill
>>
>>
>> > -----Original Message-----
>> > From: [e-mail] [mailto:[e-mail]]
>> > Sent: Tuesday, June 29, 1999 23:10
>> > To: [e-mail]; "Denis.Pinkas[Denis.Pinkas"@bull.net];
>> > [e-mail]
>> > Cc: [e-mail]; [e-mail]; [e-mail];
>> > [e-mail]
>> > Subject: RE: Time Stamp: Usage of TDTs
>> >
>> >
>> > Must admit it makes more sense now.
>> >
>> > However, the question is why would a TSA's client require or be
>> generally
>> > interested in a "certified evidence of the TSA's diligence"?.
>> This is what
>> > you propose, isn't it? Sorry if I misunderstood it.
>> >
>> > Would it be sufficient for the TSA just to claim (out of band,
>> using legal
>> > policy statement or else) that it is using such and such time
source(s),
>> > with a timePrecision field present in each TST?
>> >
>> > A client would then decide, based on the policy information (clock
>> > resolution, synchronization with NTA, reliability, etc), if that
>> > particular
>> > TSA is suitable for use.
>> >
>> > I can anticipate an argument that the TDT can be requested by the
client
>> > just once, to check how good is the TSA's timing. But this does not
>> > guarantee that the consequent TSTs will be issued using the
>> same clock, or
>> > using the same clock-to-NTA synchronisation. If this is
>> guaranteed by the
>> > TSA's policy, and we are going to trust to what the policy
>> > promises, then as
>> > well we can trust the rest of it (i.e. when/if it states that
>> the clock IS
>> > synchronised with NTA).
>> >
>> > Probably, there are business cases where having TDT in a time
>> > stamp would be
>> > a nice feature. Looking forward to hear more.
>> >
>> > Regards
>> > MichaelZ
>> >
>> >
>> > -----Original Message-----
>> > From: Bill Lattin [mailto:[e-mail]]
>> > Sent: Wednesday, June 30, 1999 5:21 AM
>> > To: [e-mail]
>> > Cc: Dave Robinson; Ron Holm; Mike Duren; Greg Dowd
>> > Subject: Time Stamp: Usage of TDTs
>> >
>> >
>> > All,
>> >
>> > Over the last few weeks, there has been considerable discussion
>> > on the need
>> > for TDAs and their corresponding TDTs.  Much of the debate has been on
>> > whether or not TDAs really add anything essential.  The heart
>> of the issue
>> > is whether or not the TSA is producing suitably trusted and
>> accurate time.
>> > It has been argued that if the time is accurate and trusted,
>> then TDAs are
>> > redundant (de la Vega and Zolotarev) and therefore should be
eliminated.
>> >
>> > Rather than use TDAs to provide secondary non-time information to
>> > substantiate a TST, an alternative use is for a TDT to convey traceable
>> > trusted time certification from a National Timing Authority (NTA) (e.g.
>> > NIST) to the TSAs.  Rather than conveying something indirect like stock
>> > market closing data, this new type of TDT could be used to show, in a
>> > non-repudiatable manner, that: (i) a TSA's clock is accurately
>> > synchronized
>> > to the NTA's clock ; and/or (ii) the time of creation of a TST
embedding
>> > such a TDT is traceable to the NTA.
>> >
>> > We are working with the S/Time group to create a protocol to reliably
>> > distribute time from an NTA to allow lower clocks in a timing
>> hierarchy to
>> > be accurately and reliably synchronized to the NTA's clock.
>> The result of
>> > this process is a digitally signed certification that a clock
>> is properly
>> > synchronized to the NTA.  This certification can be embedded in a TDT
to
>> > prove that the time in the TDT or TST comes from a clock which has been
>> > synchronized to an NTA.
>> >
>> > Use of a TDT in this manner accomplishes a number of things:
>> >
>> > 1.  It directly enhances the quality of the TST by providing both
>> > a link to
>> > UTC and traceability to NIST (or appropriate NTA);
>> > 2.  It can be used to synchronize multiple TSA's to an NTA so
>> > that the TSAs
>> > can produce timestamps per NIST UTC (for instance) rather than
>> their local
>> > clock.
>> > 3.  It will aid certain electronic commerce implementations since
>> > the TSA's
>> > clock can be shown to be directly traceable to an NTA.
>> >
>> > Thus, we urge the group not to abandon TDAs and TDTs, but to consider
an
>> > alternative use for them that would contribute additional,
>> > directly relevant
>> > timing information to enhance the operation of the TSA and the
>> quality of
>> > its TSTs.
>> >
>> > Regards,
>> >
>> > Bill
>> >
>>
>





Received: from localhost (daemon@localhost) by mail.proper.com (8.8.8/8.8.5) with SMTP id RAA09122; Thu, 1 Jul 1999 17:03:10 -0700 (PDT)
Received: by mail.imc.org (bulk_mailer v1.12); Thu, 1 Jul 1999 17:02:20 -0700
Received: from smtp.kolumbus.fi (smtp.kolumbus.fi [193.229.0.51]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id RAA09087 for <[e-mail]>; Thu, 1 Jul 1999 17:02:19 -0700 (PDT)
Received: from pchni (m15m9hel.dial.kolumbus.fi [193.229.114.15]) by smtp.kolumbus.fi (8.9.0/8.9.0) with SMTP id DAA06170; Fri, 2 Jul 1999 03:06:30 +0300 (EET DST)
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1 
Date: Fri, 02 Jul 1999 03:05:55 +0300
To: Stefan Santesson <[e-mail]>, <[e-mail]>
From: Hannu Nikkanen <[e-mail]>
Subject: Re: PolicyStatements ewxtension in Qualified Certificates
In-Reply-To: <[e-mail]>
References: <v04020a09b39070b60562@[128.89.0.110]> <[e-mail]> <v04020a11b38f168558d5@[128.33.238.33]> <[e-mail]> <v04020a10b38b45a34213@[128.33.238.203]> <[e-mail]> <v04020a0fb383271ddc78@[128.89.0.110]> <[e-mail]> <41ACC8CF2BF1D011AEDD00805F31E54C02F232CD@AUNT15>
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 RAA09088
Precedence: bulk
List-Archive: http://www.imc.org/ietf-pkix/mail-archive/
List-Unsubscribe: mailto:[e-mail]?body=unsubscribe
X-UIDL: c3b2551b2b92fe99ac1056549471e08c

Hi,

how will you handle identification of "real" vs pseudonym?

Hannu

At 00:24 29.6.1999 +0200, Stefan Santesson wrote:
>All,
>
>I conclude from various on-list and off-list discussions that the best way
>to solve inclusion of statements related to legal frameworks in a Qualified
>Certificate, is to provide this functionality in a private extension.
>
>Three statements has been discussed related to the EU-directive:
>
>1) Inclusion of a reliance limit (how much you should rely on the
>certificate. Note that this has NOTHING to do with how much you should rely
>on the certified subject).
>2) Inclusion of a statement declaring that the certificate is a Qualified
>Certificate according to a legal framework (In case of the EU-directive,
>that the certificate meets Annex I and are issued according to Annex II)
>2) Inclusion of a statement, limiting the area of use of the certificate.
>
>I have earlier posted a proposal for such an extension. The current
>proposal is:
>
>    PolicyStatement  EXTENSION ::= {
>      SYNTAX             PolicyStatementSyntax
>      IDENTIFIED BY      id-pe-PolicyStatement }
>
>    id-pe-policyStatement          OBJECT IDENTIFIER ::= { id-pe 3 }
>    -- This is  only a proposed OID. It is not assigned yet.
>
>    PolicyStatementSyntax ::= SEQUENCE OF Statement
>   
>    Statement ::= SEQUENCE {
>        StatementId        OBJECTIDENTIFIER
>        StatementInfo      ANY DEFINED BY StatementId OPTIONAL}
>
>As these types of statements are policy statements, the QC standard SHALL
>require that included statements are not in conflict with any policy
>identified in the policy extension.
>
>Stephen Kent replied to the last proposal with:
>
>At 05:58 PM 6/18/99 -0400, Stephen Kent wrote:
>>Stefan,
>>
>>This would make folks happy who hated the use of policy qualifiers for
>>this, and address the incorporation by reference concerns too. One
>>question: why do we need the "Any Defined by: here?  I'd rather not leave
>>the hole for folks to incorporate text directly, instead of by pointer and
>>hash.  why not replace the statement by those two data items?
>>
>>Please bring it to the list.
>>
>>Steve
>
>The answer to this is that the StatmentInfo may be required in order to
>make a good structure for several statements. I.e. one OID may define that
>StatementInfo contains a reliance limit specified using the ISO structure
>for monetary value  (expressed before), and another OID may define that the
>StatementInfo contains information regarding restrictions of usage (e.g.
>only for banking applications).
>
>So this is a 2 step approach, but can also be used as an 1 step approach in
>cases where an exact statement can be identified by a single OID. In the
>latter case the StatementInfo is omitted.
>
>Before I put this in the specification I would like some final reactions on
>this.
>
>/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 localhost (daemon@localhost) by mail.proper.com (8.8.8/8.8.5) with SMTP id MAA06213; Thu, 1 Jul 1999 12:05:16 -0700 (PDT)
Received: by mail.imc.org (bulk_mailer v1.12); Thu, 1 Jul 1999 12:05:16 -0700
Received: from aum (ip11.proper.com [165.227.249.11]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id MAA06190 for <[e-mail]>; Thu, 1 Jul 1999 12:05:14 -0700 (PDT)
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.56 (Beta)
Date: Thu, 01 Jul 1999 12:07:28 -0700
To: [e-mail]
From: Paul Hoffman / IMC <[e-mail]>
Subject: RE: I-D ACTION:draft-ietf-pkix-scvp-00.txt
In-Reply-To: <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Precedence: bulk
List-Archive: http://www.imc.org/ietf-pkix/mail-archive/
List-Unsubscribe: mailto:[e-mail]?body=unsubscribe
X-UIDL: 9ae720fe7876831efb299d96dda0810c
Status: O
X-Status:

At 02:39 PM 7/1/1999 -0400, David P. Kemp wrote:
>Sorry, but the idea of a protocol that says "here is a certificate,
>give me the public key" just makes me gag.

Um, have you read the draft? The protocol gives back much more than that. 
Reading the draft may help prevent future gagging.

>   What device has enough oomph
>to run a protocol engine but not enough to extract the key from an
>X.509 cert?

Probably none; the protocol returns much more than the key. There are lots 
of devices who do not have the oomph to do good path validation with all of 
the constraints. Getting just the public key is not interesting, given that 
you want to validate it.

--Paul Hoffman, Director
--Internet Mail Consortium



Received: from localhost (daemon@localhost) by mail.proper.com (8.8.8/8.8.5) with SMTP id LAA05630; Thu, 1 Jul 1999 11:39:32 -0700 (PDT)
Received: by mail.imc.org (bulk_mailer v1.12); Thu, 1 Jul 1999 11:39:30 -0700
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 LAA05603 for <[e-mail]>; Thu, 1 Jul 1999 11:39:28 -0700 (PDT)
Received: from stingray.missi.ncsc.mil (root@localhost) by stingray.missi.ncsc.mil with ESMTP id OAA07786 for <[e-mail]>; Thu, 1 Jul 1999 14:43:08 -0400 (EDT)
Received: from missi.ncsc.mil (depot.missi.ncsc.mil [144.51.60.1]) by stingray.missi.ncsc.mil with ESMTP id OAA07782 for <[e-mail]>; Thu, 1 Jul 1999 14:43:07 -0400 (EDT)
Received: from ara.missi.ncsc.mil (ara.missi.ncsc.mil [144.51.58.9]) by missi.ncsc.mil (8.8.8/8.8.8) with ESMTP id OAA26007 for <[e-mail]>; Thu, 1 Jul 1999 14:43:08 -0400 (EDT)
Received: from ara.missi.ncsc.mil (ara.missi.ncsc.mil [144.51.58.9]) by ara.missi.ncsc.mil (8.9.1b+Sun/8.9.1) with SMTP id OAA02913 for <[e-mail]>; Thu, 1 Jul 1999 14:39:47 -0400 (EDT)
Message-Id: <[e-mail]>
Date: Thu, 1 Jul 1999 14:39:47 -0400 (EDT)
From: "David P. Kemp" <[e-mail]>
Reply-To: "David P. Kemp" <[e-mail]>
Subject: RE: I-D ACTION:draft-ietf-pkix-scvp-00.txt
To: [e-mail]
MIME-Version: 1.0
Content-Type: TEXT/plain; charset=us-ascii
Content-MD5: B+RApTlnrvoBiuW7X2NEsg==
X-Mailer: dtmail 1.3.0 CDE Version 1.3 SunOS 5.7 sun4u sparc 
Precedence: bulk
List-Archive: http://www.imc.org/ietf-pkix/mail-archive/
List-Unsubscribe: mailto:[e-mail]?body=unsubscribe
X-UIDL: 645a700926b85beccff238dbf3418a54
Status: O
X-Status:

> From: Paul Hoffman / IMC <[e-mail]>
> 
> A single instance of a parser is not going to convince many people that 
> constrained ASN.1 is sufficient. A syntax that implementors can understand 
> well enough to write a parser is what is needed.

A single instance of just any parser (i.e. a commercial library) is not
sufficient.  But a single instance of an Open Source parser should be
sufficient for any developer who can type "configure; make" :-).
Competition in the marketplace, or in the Bazaar of ideas, will ensure
that if one implementor can do it on an ARM, the rest will follow.

Sorry, but the idea of a protocol that says "here is a certificate,
give me the public key" just makes me gag.  What device has enough oomph
to run a protocol engine but not enough to extract the key from an
X.509 cert?



Received: from localhost (daemon@localhost) by mail.proper.com (8.8.8/8.8.5) with SMTP id LAA05218; Thu, 1 Jul 1999 11:24:49 -0700 (PDT)
Received: by mail.imc.org (bulk_mailer v1.12); Thu, 1 Jul 1999 11:24:48 -0700
Received: from e1.ny.us.ibm.com (e2.ny.us.ibm.com [32.97.182.102]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id LAA05196 for <[e-mail]>; Thu, 1 Jul 1999 11:24:47 -0700 (PDT)
From: [e-mail]
Received: from northrelay02.pok.ibm.com (northrelay02.pok.ibm.com [9.117.200.22]) by e1.ny.us.ibm.com (8.9.3/8.9.3) with ESMTP id OAA68090; Thu, 1 Jul 1999 14:28:13 -0400
Received: from D51MTA05.pok.ibm.com (d51mta05.pok.ibm.com [9.117.200.33]) by northrelay02.pok.ibm.com (8.8.8m2/NCO v2.03) with SMTP id OAA234790; Thu, 1 Jul 1999 14:28:19 -0400
Received: by D51MTA05.pok.ibm.com(Lotus SMTP MTA v4.6.4  (830.2 3-23-1999))  id 852567A1.006573C7 ; Thu, 1 Jul 1999 14:28:07 -0400
X-Lotus-FromDomain: IBMUS
To: "David P. Kemp" <[e-mail]>
cc: [e-mail]
Message-ID: <[e-mail]>
Date: Thu, 1 Jul 1999 14:28:09 -0400
Subject: RE: I-D ACTION:draft-ietf-pkix-scvp-00.txt
Mime-Version: 1.0
Content-type: text/plain; charset=us-ascii
Content-Disposition: inline
Precedence: bulk
List-Archive: http://www.imc.org/ietf-pkix/mail-archive/
List-Unsubscribe: mailto:[e-mail]?body=unsubscribe
X-UIDL: 0cb59377a574afb98c335e39ce5a2348
Status: O
X-Status:

     Actually, I'm not sure that cutting down on OPTIONAL for primitive fields
is a big savings - I'd argue that it's DEFAULT that costs a lot.  If each
element at a given level has a unique tag (not normal in ASN.1, admittedly, but
not hard to arrange), and the caller asks for the pointer and length
corresponding to class C and tag T, OPTIONAL costs almost nothing - when you
don't find the requested tag, you just return { NULL, 0 }.  You could also have
another routine looking for the N'th occurrence of universal tag T (or class C
and tag T, for that matter) to accomodate most existing sequences (and almost
all SEQUENCE OF's and SET OF's), but that one would require that no occurrence
of tag T other than the last one be OPTIONAL.  Handling general cases of
OPTIONAL in the syntax might be harder, but designing to these rules would make
the structure easy to handle with a minimal parser.

          Tom Gindin




Received: from localhost (daemon@localhost) by mail.proper.com (8.8.8/8.8.5) with SMTP id LAA04927; Thu, 1 Jul 1999 11:05:43 -0700 (PDT)
Received: by mail.imc.org (bulk_mailer v1.12); Thu, 1 Jul 1999 11:05:40 -0700
Received: from aum (ip11.proper.com [165.227.249.11]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id LAA04905 for <[e-mail]>; Thu, 1 Jul 1999 11:05:39 -0700 (PDT)
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.56 (Beta)
Date: Thu, 01 Jul 1999 11:08:04 -0700
To: [e-mail]
From: Paul Hoffman / IMC <[e-mail]>
Subject: RE: I-D ACTION:draft-ietf-pkix-scvp-00.txt
In-Reply-To: <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Precedence: bulk
List-Archive: http://www.imc.org/ietf-pkix/mail-archive/
List-Unsubscribe: mailto:[e-mail]?body=unsubscribe
X-UIDL: f2eae7442091136e5d04eacbb3c58d61

At 01:51 PM 7/1/1999 -0400, David P. Kemp wrote:
>I agree that the perception that ASN.1 cannot be used in a tiny syntax
>is largely undeserved.

Maybe so, but it is a widespread perception.

>   I would be happy to write a small ASN.1 parser
>that should compare favorably in runtime and memory footprint with the
>software required to support the alternate encoding.

A single instance of a parser is not going to convince many people that 
constrained ASN.1 is sufficient. A syntax that implementors can understand 
well enough to write a parser is what is needed. If we can describe the 
ASN.1 syntax well enough to prove that such a parser is fairly easy to 
write, then there is a win, but I suspect that is impossible due to many 
things, including the lack of easily-findable documentation for creating 
ASN.1 interpreters.

>   Support for
>indefinite-length (non-DER) coding costs almost nothing so a DER
>restriction is not necessary, but using implicit tagging for
>context-tagged OPTIONAL elements will save a couple of bytes per
>element in the encoded data and one tiny subroutine in the code.
>Making every element non-OPTIONAL but potentially zero length would
>save more code.

We did not try to optimize for smallest messages; in fact, we didn't see 
that as a requirement at all. A single subroutine is also not important.

>Anyone care for a syntax bakeoff? :-)

We're quite open to any syntaxes that would make client vendors more likely 
to implement SVCP. That's precisely why we have two in the draft, and why 
all of the semantics are in a different section. If we can go with one and 
show how someone with little or no ASN.1 experience can create a program 
that writes requests and reads responses, that would be great. But I'm 
skeptical...

--Paul Hoffman, Director
--Internet Mail Consortium



Received: from localhost (daemon@localhost) by mail.proper.com (8.8.8/8.8.5) with SMTP id KAA04644; Thu, 1 Jul 1999 10:51:33 -0700 (PDT)
Received: by mail.imc.org (bulk_mailer v1.12); Thu, 1 Jul 1999 10:51:31 -0700
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 KAA04622 for <[e-mail]>; Thu, 1 Jul 1999 10:51:25 -0700 (PDT)
Received: from stingray.missi.ncsc.mil (root@localhost) by stingray.missi.ncsc.mil with ESMTP id NAA01733 for <[e-mail]>; Thu, 1 Jul 1999 13:55:01 -0400 (EDT)
Received: from missi.ncsc.mil (depot.missi.ncsc.mil [144.51.60.1]) by stingray.missi.ncsc.mil with ESMTP id NAA01722 for <[e-mail]>; Thu, 1 Jul 1999 13:55:00 -0400 (EDT)
Received: from ara.missi.ncsc.mil (ara.missi.ncsc.mil [144.51.58.9]) by missi.ncsc.mil (8.8.8/8.8.8) with ESMTP id NAA25382 for <[e-mail]>; Thu, 1 Jul 1999 13:55:01 -0400 (EDT)
Received: from ara.missi.ncsc.mil (ara.missi.ncsc.mil [144.51.58.9]) by ara.missi.ncsc.mil (8.9.1b+Sun/8.9.1) with SMTP id NAA02897 for <[e-mail]>; Thu, 1 Jul 1999 13:51:39 -0400 (EDT)
Message-Id: <[e-mail]>
Date: Thu, 1 Jul 1999 13:51:39 -0400 (EDT)
From: "David P. Kemp" <[e-mail]>
Reply-To: "David P. Kemp" <[e-mail]>
Subject: RE: I-D ACTION:draft-ietf-pkix-scvp-00.txt
To: [e-mail]
MIME-Version: 1.0
Content-Type: TEXT/plain; charset=us-ascii
Content-MD5: Icz6FX8TejF1vcvVhdm3jg==
X-Mailer: dtmail 1.3.0 CDE Version 1.3 SunOS 5.7 sun4u sparc 
Precedence: bulk
List-Archive: http://www.imc.org/ietf-pkix/mail-archive/
List-Unsubscribe: mailto:[e-mail]?body=unsubscribe
X-UIDL: 620aac8b9fb051d7817e58555a729414

I agree that the perception that ASN.1 cannot be used in a tiny syntax
is largely undeserved.  I would be happy to write a small ASN.1 parser
that should compare favorably in runtime and memory footprint with the
software required to support the alternate encoding.  Support for
indefinite-length (non-DER) coding costs almost nothing so a DER
restriction is not necessary, but using implicit tagging for
context-tagged OPTIONAL elements will save a couple of bytes per
element in the encoded data and one tiny subroutine in the code.
Making every element non-OPTIONAL but potentially zero length would
save more code.

Anyone care for a syntax bakeoff? :-)



>From: "Salter, Thomas A" <[e-mail]>
>
> Are you sure that the tiny syntax saves all that much parsing code?
> 
> It seems to me that you could accomplish much of what you want by
> restricting the protocol to a very small subset of ASN.1.  Suppose, for
> instance, that all protocol elements are implicitly tagged and encoded as
> DER.  Then the biggest difference between that and 'tiny' syntax is that the
> variable-length length field (and perhaps a variable length tag).
> 
> (I would only apply the DER restriction to elements parsed by the client;
> the client could encode using any BER encoding.)
> 
> My question is whether a 'tiny' parser is enough smaller than a parser for
> an ASN.1 subset to be worth inventing a new encoding scheme.  



Received: from localhost (daemon@localhost) by mail.proper.com (8.8.8/8.8.5) with SMTP id KAA04038; Thu, 1 Jul 1999 10:03:56 -0700 (PDT)
Received: by mail.imc.org (bulk_mailer v1.12); Thu, 1 Jul 1999 10:03:55 -0700
Received: from bbmail1.unisys.com (bbmail1.unisys.com [192.63.108.35]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id KAA04015 for <[e-mail]>; Thu, 1 Jul 1999 10:03:55 -0700 (PDT)
Received: from trsvrbk.tr.unisys.com (trsvrbk.tr.unisys.com [192.63.236.1]) by bbmail1.unisys.com (8.8.5/8.8.5) with ESMTP id RAA05369 for <[e-mail]>; Thu, 1 Jul 1999 17:07:04 GMT
Received: from us-tr-exch-2.tr.unisys.com by trsvrbk.tr.unisys.com (8.8.5/8.8.5) id RAA10551 ; Thu, 1 Jul 1999 17:06:03 GMT
Received: by us-tr-exch-2.tr.unisys.com with Internet Mail Service (5.5.2448.0) id <N9HRDW5J>; Thu, 1 Jul 1999 13:07:18 -0400
Message-ID: <[e-mail]>
From: "Salter, Thomas A" <[e-mail]>
To: [e-mail]
Subject: RE: I-D ACTION:draft-ietf-pkix-scvp-00.txt
Date: Thu, 1 Jul 1999 13:07:34 -0400 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2448.0)
Content-Type: text/plain; charset="iso-8859-1"
Precedence: bulk
List-Archive: http://www.imc.org/ietf-pkix/mail-archive/
List-Unsubscribe: mailto:[e-mail]?body=unsubscribe
X-UIDL: f9f91d6477bbcccf2e16e82f5ded54d3

Are you sure that the tiny syntax saves all that much parsing code?

It seems to me that you could accomplish much of what you want by
restricting the protocol to a very small subset of ASN.1.  Suppose, for
instance, that all protocol elements are implicitly tagged and encoded as
DER.  Then the biggest difference between that and 'tiny' syntax is that the
variable-length length field (and perhaps a variable length tag).

(I would only apply the DER restriction to elements parsed by the client;
the client could encode using any BER encoding.)

My question is whether a 'tiny' parser is enough smaller than a parser for
an ASN.1 subset to be worth inventing a new encoding scheme.  


Received: from localhost (daemon@localhost)  by mail.proper.com (8.8.8/8.8.5) with SMTP id JAA03554;  Thu, 1 Jul 1999 09:32:27 -0700 (PDT) 
Received: by mail.imc.org (bulk_mailer v1.12); Thu, 1 Jul 1999 09:32:25 -0700 
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 JAA03529  for <[e-mail]>; Thu, 1 Jul 1999 09:32:21 -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 SAA26871;  Thu, 1 Jul 1999 18:34:50 +0200 (MET DST) 
Message-ID: <[e-mail]> 
Date: Thu, 01 Jul 1999 18:32:54 +0200 
From: Petra Gloeckner <[e-mail]> 
X-Mailer: Mozilla 4.61 [en] (WinNT; I) 
X-Accept-Language: en 
MIME-Version: 1.0 
To: [e-mail] 
CC: Stefan Santesson <[e-mail]>, [e-mail] 
Subject: Re: Use of localityName attribute 
References: <v04020a09b39070b60562@[128.89.0.110]> <[e-mail]> 
Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------msAD3FA464DCD0AE73D42AD909" 
Precedence: bulk 
List-Archive:

The following are the message properties:


   Encrypted: No
   Signed: Yes
   Contents Altered after signing: No
   Signature Algorithm: SHA1


Hi David,


you're absolutely right. We need to add the localityName attribute.


Bye - Petra


David Chadwick wrote:
> 
> Stefan,
> 
> I need to request a change to the qualified certificate draft to allow
> the use of the localityName attribute to be used to unambiguously
> identify a subject and issuer in a DN. The UK National Health
> Service Standard for Directory Services requires the use of locality
> name to unambiguously identify different organisational units within
> the NHS. For example, there are literally dozens of St Mary's
> Hospitals within the UK NHS, so that O and OU are insufficient as
> differentiators. Consequently localityName, based on the UK Post
> Office defined localities, is used to differentiate between them (we
> do not use the full postal address as this is too cumbersome.)
> 
> As the QC draft stands at the moment, (as I read it), the use of
> localityName as currently defined by the NHS would not be allowed
> as a differentiator.
> 
> The offending sections are:
> 
> 3.1.1 Issuer -  allows for state or province name but not for
> localityName. We request that localityName be added to this section.
> 
> 3.1.2 Subject - allows postalAddress but not localityName and states
> "Other attributes may be present but MUST NOT be necessary to
> distinguish the subject name from other subject names within the
> issuer domain."
> 
> This effectively precludes localityName from being used to
> unambiguously differentiate between hospital. We request that
> localityName be added to the MAY list.
> 
> Regards
> David
> 
> ***************************************************
> 
> David Chadwick
> IT Institute, University of Salford, Salford M5 4WT
> Tel [phone]  Fax [phone]
> *NEW* Mobile [phone] *NEW*
> Email [e-mail]
> Home Page  http://www.salford.ac.uk/its024/chadwick.htm
> Understanding X.500  http://www.salford.ac.uk/its024/X500.htm
> X.500/LDAP Seminars http://www.salford.ac.uk/its024/seminars.htm
> Entrust key validation string MLJ9-DU5T-HV8J
> 
> ***************************************************  
List-Unsubscribe: mailto:[e-mail]?body=unsubscribe 
X-UIDL: 0b95fdd80c253eb9111f8be72ac20fa7 

<html><DIV><A href="file://C:\Temp\Re Use of localityName attribu.ems <0265.0002>" 
EUDORA="PLUGIN"><IMG alt="C:\Temp\Re Use of localityName attribu.ems" 
src="file://d:\mail\combined\icons\7df6a8f.jpg"> Re Use of localityName 
attribu.ems </A></DIV></html>
>From ???@??? Thu Jul 01 10:18:24 1999
Received: from localhost (daemon@localhost)
	by mail.proper.com (8.8.8/8.8.5) with SMTP id KAA03871;
	Thu, 1 Jul 1999 10:00:33 -0700 (PDT)
Received: by mail.imc.org (bulk_mailer v1.12); Thu, 1 Jul 1999 10:00:26 -0700
Received: from mail1.gte.net (mail1.gte.net [207.115.153.32])
	by mail.proper.com (8.8.8/8.8.5) with ESMTP id KAA03849
	for <[e-mail]>; Thu, 1 Jul 1999 10:00:26 -0700 (PDT)
Received: from desktop (1Cust157.tnt1.clearwater.fl.da.uu.net [153.37.163.157])
	by mail1.gte.net  with SMTP
	; id MAA00999
	Thu, 1 Jul 1999 12:01:50 -0500 (CDT)
Message-ID: <000a01bec3e2$91608680$af316018@desktop>
Reply-To: "Michael Duren" <[e-mail]>
From: "Michael Duren" <[e-mail]>
To: <[e-mail]>, "Denis.Pinkas" <"[Denis.Pinkas"@bull.net]>,
        <[e-mail]>, "Bill Lattin" <[e-mail]>
Cc: "Chet Hosmer" <[e-mail]>,
        "David Robinson" <[e-mail]>, "Ron Holm" <[e-mail]>,
        "Greg Dowd" <[e-mail]>,
        "T. Mark Hastings" <[e-mail]>
Subject: Re: Time Stamp:  Usage of TDTs
Date: Thu, 1 Jul 1999 12:55:40 -0400
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 4.72.3110.1
X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3
Precedence: bulk
List-Archive: http://www.imc.org/ietf-pkix/mail-archive/
List-Unsubscribe: mailto:[e-mail]?body=unsubscribe
X-UIDL: 8216d8b2b98da44e1bd1b691e4503239

I agree with Bill that a TDA could issue tokens in the same way that a TSA
does.  His point about liability and business issues is very true to life.

Going back to the definition of a TDT, the TDT to TSA relationship is many
to one.  The TDT concept allows for collaboration of temporal information
from more than one source.  Since the TDT is also signed, this collaboration
greatly strengthens the TSA trust model.  With this in mind, a TST can
include temporal information from more that one NTA-authenticated TDA.  In
addition, companies and organizations might have their own TDA.  Policies
then could be defined that specify what TDA's must be included in a given
timestamp.

To move to a real life example, if company X and Y are doing business and
those companies reside in different countries, would it make sense for them
to obtain timestamps that are traceable to their respective NTA?  Also,
perhaps one or both companies maintains their own TDA, would it be
reasonable for the timestamping standard to allow for inclusion of their own
TDTs in TSTs that involve their company?

Feedback is welcomed.

Sincerely,

Mike Duren



-----Original Message-----
From: Bill Lattin <[e-mail]>
To: [e-mail] <[e-mail]>; Denis.Pinkas
<"[Denis.Pinkas"@bull.net]>; [e-mail]
<[e-mail]>
Cc: T. Mark Hastings <[e-mail]>; [e-mail]
<[e-mail]>; [e-mail] <[e-mail]>;
[e-mail] <[e-mail]>; [e-mail] <[e-mail]>
Date: Thursday, July 01, 1999 10:41 AM
Subject: RE: Time Stamp: Usage of TDTs


>Michael,
>
>I suppose that if a TDA issuing this type of TDT wanted to perform the
other
>activities associated with a TSA it could; however, I don't necessarily see
>a merging of the two since the business issues associated with each
>(liability, customer support, application interfaces, policy support, etc)
>are quite different.  Also, not all applications requiring a time stamp nee
d
>that level of accuracy - hence the variation in service offerings I
>previously mentioned.
>
>Cheers,
>
>Bill
>
>> -----Original Message-----
>> From: [e-mail] [mailto:[e-mail]]
>> Sent: Wednesday, June 30, 1999 17:23
>> To: [e-mail]; Denis.Pinkas; [e-mail]
>> Cc: [e-mail]; [e-mail]; [e-mail];
>> [e-mail]
>> Subject: RE: Time Stamp: Usage of TDTs
>>
>>
>> Bill,
>>
>> Ok, another question: If one day NIST will implement TSA services itself,
>> would I, as a client, need a TDT in the TST produced by a NIST server? I
>> guess no.
>> In general case, if a TDA can attest to the quality of time (because it
>> knows it better, presumably), what stops it to provide TSA
>> services itself?
>> So the clients can go 'right to the source', and get a 100%
>> guaranteed pure
>> time reference, instead of having to worry about secondary verification,
>> etc.
>>
>> Waiting for replies...
>>
>> Regards
>> MichaelZ
>>
>>
>> -----Original Message-----
>> From: Bill Lattin [mailto:[e-mail]]
>> Sent: Thursday, July 01, 1999 7:12 AM
>> To: [e-mail]; "Denis.Pinkas[Denis.Pinkas"@bull.net];
>> [e-mail]
>> Cc: [e-mail]; [e-mail]; [e-mail];
>> [e-mail]
>> Subject: RE: Time Stamp: Usage of TDTs
>>
>>
>> Michael,
>>
>> Thanks for the feedback.
>>
>> Depending on the application, a client could be very interested in
>> "certified evidence" being located in a TST.  For example, in a currency
>> arbitrage or stock trade situation one coud envisage being able to prove
>> that a trade was placed at a certain time.  The real question is what
>> evidence is good enough?  Is it a contractual agreement that the local
>> TSA's clock is sufficently accurate and precise or is will there be a
>> mandate to use the clock from a National Timing Authority?
>>
>> The answer is both.  We are not advocating that this type of TDT replace
a
>> local TSA clock; both models are valid.  We just want to enable the use
of
>> the National Timing Authority clocks since we believe that a number of
>> applications will insist on having time traceable to them.  As a current
>> example (although one for which PKIX time stamps will be too late for the
>> initial phases) is the NASDAQ OATS system.  This order tracking system is
>> required to use timing from NIST (the US' NTA).  The healthcare system in
>> the US is also extremely sensitive to time, and we expect that many new
>> applications will need to be linked to an NTA timing source rather than a
>> local source.
>>
>> Further, I'm sure we all agree that the timeStampToken needs to be a
>> persistent data object.  For example, e-mail would normally be
>> considered to
>> have low requirements for time-stamp trust.  However, 3 years
>> down the road,
>> a given e-mail and its time of origin may be pivotal in a legal case.  If
>> the trust of the time in the timeStampToken can be embodied with
>> a party in
>> addition to the entity possessing the TSA, the timeStampToken can better
>> meet the requirement to be a persistent data object.
>>
>> You are right that a request of a single TDT does not guarantee future
>> performance from the TSA.  For applications that need
>> traceability to NIST,
>> a TDT will be needed per time stamp.  This is an important extra
>> benefit, a
>> TST with its own instance of a TDT can provide 'guaranteed' time
>> independent
>> of the clock within the TSA.  Other applications, which are not as
>> sensitive, can operate as you have suggested - by agreement on policy
that
>> the TSA is doing the right thing.
>>
>> The bottom line is that the use of a TDT in this manner enables a
>> new class
>> of applications which require explicit, provable traceability (with
>> associated audit trails) to an NTA.  The TSA operation is enhanced
because
>> it can offer multiple types of service.
>>
>> Cheers,
>>
>> Bill
>>
>>
>> > -----Original Message-----
>> > From: [e-mail] [mailto:[e-mail]]
>> > Sent: Tuesday, June 29, 1999 23:10
>> > To: [e-mail]; "Denis.Pinkas[Denis.Pinkas"@bull.net];
>> > [e-mail]
>> > Cc: [e-mail]; [e-mail]; [e-mail];
>> > [e-mail]
>> > Subject: RE: Time Stamp: Usage of TDTs
>> >
>> >
>> > Must admit it makes more sense now.
>> >
>> > However, the question is why would a TSA's client require or be
>> generally
>> > interested in a "certified evidence of the TSA's diligence"?.
>> This is what
>> > you propose, isn't it? Sorry if I misunderstood it.
>> >
>> > Would it be sufficient for the TSA just to claim (out of band,
>> using legal
>> > policy statement or else) that it is using such and such time
source(s),
>> > with a timePrecision field present in each TST?
>> >
>> > A client would then decide, based on the policy information (clock
>> > resolution, synchronization with NTA, reliability, etc), if that
>> > particular
>> > TSA is suitable for use.
>> >
>> > I can anticipate an argument that the TDT can be requested by the
client
>> > just once, to check how good is the TSA's timing. But this does not
>> > guarantee that the consequent TSTs will be issued using the
>> same clock, or
>> > using the same clock-to-NTA synchronisation. If this is
>> guaranteed by the
>> > TSA's policy, and we are going to trust to what the policy
>> > promises, then as
>> > well we can trust the rest of it (i.e. when/if it states that
>> the clock IS
>> > synchronised with NTA).
>> >
>> > Probably, there are business cases where having TDT in a time
>> > stamp would be
>> > a nice feature. Looking forward to hear more.
>> >
>> > Regards
>> > MichaelZ
>> >
>> >
>> > -----Original Message-----
>> > From: Bill Lattin [mailto:[e-mail]]
>> > Sent: Wednesday, June 30, 1999 5:21 AM
>> > To: [e-mail]
>> > Cc: Dave Robinson; Ron Holm; Mike Duren; Greg Dowd
>> > Subject: Time Stamp: Usage of TDTs
>> >
>> >
>> > All,
>> >
>> > Over the last few weeks, there has been considerable discussion
>> > on the need
>> > for TDAs and their corresponding TDTs.  Much of the debate has been on
>> > whether or not TDAs really add anything essential.  The heart
>> of the issue
>> > is whether or not the TSA is producing suitably trusted and
>> accurate time.
>> > It has been argued that if the time is accurate and trusted,
>> then TDAs are
>> > redundant (de la Vega and Zolotarev) and therefore should be
eliminated.
>> >
>> > Rather than use TDAs to provide secondary non-time information to
>> > substantiate a TST, an alternative use is for a TDT to convey traceable
>> > trusted time certification from a National Timing Authority (NTA) (e.g.
>> > NIST) to the TSAs.  Rather than conveying something indirect like stock
>> > market closing data, this new type of TDT could be used to show, in a
>> > non-repudiatable manner, that: (i) a TSA's clock is accurately
>> > synchronized
>> > to the NTA's clock ; and/or (ii) the time of creation of a TST
embedding
>> > such a TDT is traceable to the NTA.
>> >
>> > We are working with the S/Time group to create a protocol to reliably
>> > distribute time from an NTA to allow lower clocks in a timing
>> hierarchy to
>> > be accurately and reliably synchronized to the NTA's clock.
>> The result of
>> > this process is a digitally signed certification that a clock
>> is properly
>> > synchronized to the NTA.  This certification can be embedded in a TDT
to
>> > prove that the time in the TDT or TST comes from a clock which has been
>> > synchronized to an NTA.
>> >
>> > Use of a TDT in this manner accomplishes a number of things:
>> >
>> > 1.  It directly enhances the quality of the TST by providing both
>> > a link to
>> > UTC and traceability to NIST (or appropriate NTA);
>> > 2.  It can be used to synchronize multiple TSA's to an NTA so
>> > that the TSAs
>> > can produce timestamps per NIST UTC (for instance) rather than
>> their local
>> > clock.
>> > 3.  It will aid certain electronic commerce implementations since
>> > the TSA's
>> > clock can be shown to be directly traceable to an NTA.
>> >
>> > Thus, we urge the group not to abandon TDAs and TDTs, but to consider
an
>> > alternative use for them that would contribute additional,
>> > directly relevant
>> > timing information to enhance the operation of the TSA and the
>> quality of
>> > its TSTs.
>> >
>> > Regards,
>> >
>> > Bill
>> >
>>
>






Received: from localhost (daemon@localhost) by mail.proper.com (8.8.8/8.8.5) with SMTP id IAA02958; Thu, 1 Jul 1999 08:54:15 -0700 (PDT)
Received: by mail.imc.org (bulk_mailer v1.12); Thu, 1 Jul 1999 08:53:58 -0700
Received: from aum (ip11.proper.com [165.227.249.11]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id IAA02932; Thu, 1 Jul 1999 08:53:57 -0700 (PDT)
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.56 (Beta)
Date: Thu, 01 Jul 1999 08:56:38 -0700
To: "Ambarish Malpani" <[e-mail]>, <[e-mail]>
From: Paul Hoffman / IMC <[e-mail]>
Subject: RE: I-D ACTION:draft-ietf-pkix-scvp-00.txt
In-Reply-To: <00b301bec3ae$2a9dc0e0$[e-mail]>
References: <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Precedence: bulk
List-Archive: http://www.imc.org/ietf-pkix/mail-archive/
List-Unsubscribe: mailto:[e-mail]?body=unsubscribe
X-UIDL: 768bfa33825ccc305b668837f83f29e2

At 03:40 AM 7/1/1999 -0700, Ambarish Malpani wrote:
>(Paul, I think our example is broken - it doesn't reflect the
>RequestHash in the response).

Yipes! You're right. I had the RequestHash in the request but not in the 
response, which goes against the second MUST in section 3.18. I'll fix this.

--Paul Hoffman, Director
--Internet Mail Consortium



Received: from localhost (daemon@localhost) by mail.proper.com (8.8.8/8.8.5) with SMTP id IAA03022; Thu, 1 Jul 1999 08:54:44 -0700 (PDT)
Received: by mail.imc.org (bulk_mailer v1.12); Thu, 1 Jul 1999 08:54:43 -0700
Received: from aum (ip11.proper.com [165.227.249.11]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id IAA03000 for <[e-mail]>; Thu, 1 Jul 1999 08:54:42 -0700 (PDT)
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.56 (Beta)
Date: Thu, 01 Jul 1999 08:57:24 -0700
To: [e-mail]
From: Paul Hoffman / IMC <[e-mail]>
Subject: Fwd: I-D ACTION:draft-moskowitz-cmpinterop-00.txt
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Precedence: bulk
List-Archive: http://www.imc.org/ietf-pkix/mail-archive/
List-Unsubscribe: mailto:[e-mail]?body=unsubscribe
X-UIDL: dfcc5f72b2f7d1a13a85a9fad13da4f8

Another new draft that might interest a few folks in this group.

>To: IETF-Announce: ;
>From: [e-mail]
>Reply-to: [e-mail]
>Subject: I-D ACTION:draft-moskowitz-cmpinterop-00.txt
>Date: Thu, 01 Jul 1999 07:53:17 -0400
>Sender: [e-mail]
>
>A New Internet-Draft is available from the on-line Internet-Drafts 
>directories.
>
>
>         Title           : CMP Interoperability Testing:
>                           Results and Agreements
>         Author(s)       : R. Moskowitz
>         Filename        : draft-moskowitz-cmpinterop-00.txt
>         Pages           : 23
>         Date            : 30-Jun-99
>
>This memo describes the results of the first two interoperability
>tests of public key infrastructure (PKI) implementations based on
>RFC 2459, RFC 2510, and RFC 2511.  PKI implementations fall into
>three general classes: certification authorities (CAs), registration
>authorities (RAs), and PKI clients.  Interoperability testing
>focused on transactions to obtain and revoke certificates.
>
>A URL for this Internet-Draft is:
>http://www.ietf.org/internet-drafts/draft-moskowitz-cmpinterop-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-moskowitz-cmpinterop-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-moskowitz-cmpinterop-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.
>Content-Type: text/plain
>Content-ID:     <[e-mail]>
>
>ENCODING mime
>FILE /internet-drafts/draft-moskowitz-cmpinterop-00.txt
>
><ftp://ftp.ietf.org/internet-drafts/draft-moskowitz-cmpinterop-00.txt>




Received: from localhost (daemon@localhost) by mail.proper.com (8.8.8/8.8.5) with SMTP id HAA02034; Thu, 1 Jul 1999 07:36:42 -0700 (PDT)
Received: by mail.imc.org (bulk_mailer v1.12); Thu, 1 Jul 1999 07:36:24 -0700
Received: from harrier.prod.itd.earthlink.net (harrier.prod.itd.earthlink.net [207.217.121.12]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id HAA02009 for <[e-mail]>; Thu, 1 Jul 1999 07:36:23 -0700 (PDT)
Received: from lattin (1Cust82.tnt31.sfo3.da.uu.net [208.255.86.82]) by harrier.prod.itd.earthlink.net (8.9.3/8.9.3) with SMTP id HAA13327; Thu, 1 Jul 1999 07:39:54 -0700 (PDT)
From: "Bill Lattin" <[e-mail]>
To: <[e-mail]>, "Denis.Pinkas" <"[Denis.Pinkas"@bull.net]>, <[e-mail]>
Cc: "T. Mark Hastings" <[e-mail]>, <[e-mail]>, <[e-mail]>, <[e-mail]>, <[e-mail]>
Subject: RE: Time Stamp:  Usage of TDTs
Date: Thu, 1 Jul 1999 07:39:15 -0700
Message-ID: <000301bec3cf$7e4b4020$5256ffd0@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
Importance: Normal
In-Reply-To: <[e-mail]>
Precedence: bulk
List-Archive: http://www.imc.org/ietf-pkix/mail-archive/
List-Unsubscribe: mailto:[e-mail]?body=unsubscribe
X-UIDL: 6b020d95d755864ec74eb20bbbfca9df

Michael,

I suppose that if a TDA issuing this type of TDT wanted to perform the other
activities associated with a TSA it could; however, I don't necessarily see
a merging of the two since the business issues associated with each
(liability, customer support, application interfaces, policy support, etc)
are quite different.  Also, not all applications requiring a time stamp need
that level of accuracy - hence the variation in service offerings I
previously mentioned.

Cheers,

Bill

> -----Original Message-----
> From: [e-mail] [mailto:[e-mail]]
> Sent: Wednesday, June 30, 1999 17:23
> To: [e-mail]; Denis.Pinkas; [e-mail]
> Cc: [e-mail]; [e-mail]; [e-mail];
> [e-mail]
> Subject: RE: Time Stamp: Usage of TDTs
>
>
> Bill,
>
> Ok, another question: If one day NIST will implement TSA services itself,
> would I, as a client, need a TDT in the TST produced by a NIST server? I
> guess no.
> In general case, if a TDA can attest to the quality of time (because it
> knows it better, presumably), what stops it to provide TSA
> services itself?
> So the clients can go 'right to the source', and get a 100%
> guaranteed pure
> time reference, instead of having to worry about secondary verification,
> etc.
>
> Waiting for replies...
>
> Regards
> MichaelZ
>
>
> -----Original Message-----
> From: Bill Lattin [mailto:[e-mail]]
> Sent: Thursday, July 01, 1999 7:12 AM
> To: [e-mail]; "Denis.Pinkas[Denis.Pinkas"@bull.net];
> [e-mail]
> Cc: [e-mail]; [e-mail]; [e-mail];
> [e-mail]
> Subject: RE: Time Stamp: Usage of TDTs
>
>
> Michael,
>
> Thanks for the feedback.
>
> Depending on the application, a client could be very interested in
> "certified evidence" being located in a TST.  For example, in a currency
> arbitrage or stock trade situation one coud envisage being able to prove
> that a trade was placed at a certain time.  The real question is what
> evidence is good enough?  Is it a contractual agreement that the local
> TSA's clock is sufficently accurate and precise or is will there be a
> mandate to use the clock from a National Timing Authority?
>
> The answer is both.  We are not advocating that this type of TDT replace a
> local TSA clock; both models are valid.  We just want to enable the use of
> the National Timing Authority clocks since we believe that a number of
> applications will insist on having time traceable to them.  As a current
> example (although one for which PKIX time stamps will be too late for the
> initial phases) is the NASDAQ OATS system.  This order tracking system is
> required to use timing from NIST (the US' NTA).  The healthcare system in
> the US is also extremely sensitive to time, and we expect that many new
> applications will need to be linked to an NTA timing source rather than a
> local source.
>
> Further, I'm sure we all agree that the timeStampToken needs to be a
> persistent data object.  For example, e-mail would normally be
> considered to
> have low requirements for time-stamp trust.  However, 3 years
> down the road,
> a given e-mail and its time of origin may be pivotal in a legal case.  If
> the trust of the time in the timeStampToken can be embodied with
> a party in
> addition to the entity possessing the TSA, the timeStampToken can better
> meet the requirement to be a persistent data object.
>
> You are right that a request of a single TDT does not guarantee future
> performance from the TSA.  For applications that need
> traceability to NIST,
> a TDT will be needed per time stamp.  This is an important extra
> benefit, a
> TST with its own instance of a TDT can provide 'guaranteed' time
> independent
> of the clock within the TSA.  Other applications, which are not as
> sensitive, can operate as you have suggested - by agreement on policy that
> the TSA is doing the right thing.
>
> The bottom line is that the use of a TDT in this manner enables a
> new class
> of applications which require explicit, provable traceability (with
> associated audit trails) to an NTA.  The TSA operation is enhanced because
> it can offer multiple types of service.
>
> Cheers,
>
> Bill
>
>
> > -----Original Message-----
> > From: [e-mail] [mailto:[e-mail]]
> > Sent: Tuesday, June 29, 1999 23:10
> > To: [e-mail]; "Denis.Pinkas[Denis.Pinkas"@bull.net];
> > [e-mail]
> > Cc: [e-mail]; [e-mail]; [e-mail];
> > [e-mail]
> > Subject: RE: Time Stamp: Usage of TDTs
> >
> >
> > Must admit it makes more sense now.
> >
> > However, the question is why would a TSA's client require or be
> generally
> > interested in a "certified evidence of the TSA's diligence"?.
> This is what
> > you propose, isn't it? Sorry if I misunderstood it.
> >
> > Would it be sufficient for the TSA just to claim (out of band,
> using legal
> > policy statement or else) that it is using such and such time source(s),
> > with a timePrecision field present in each TST?
> >
> > A client would then decide, based on the policy information (clock
> > resolution, synchronization with NTA, reliability, etc), if that
> > particular
> > TSA is suitable for use.
> >
> > I can anticipate an argument that the TDT can be requested by the client
> > just once, to check how good is the TSA's timing. But this does not
> > guarantee that the consequent TSTs will be issued using the
> same clock, or
> > using the same clock-to-NTA synchronisation. If this is
> guaranteed by the
> > TSA's policy, and we are going to trust to what the policy
> > promises, then as
> > well we can trust the rest of it (i.e. when/if it states that
> the clock IS
> > synchronised with NTA).
> >
> > Probably, there are business cases where having TDT in a time
> > stamp would be
> > a nice feature. Looking forward to hear more.
> >
> > Regards
> > MichaelZ
> >
> >
> > -----Original Message-----
> > From: Bill Lattin [mailto:[e-mail]]
> > Sent: Wednesday, June 30, 1999 5:21 AM
> > To: [e-mail]
> > Cc: Dave Robinson; Ron Holm; Mike Duren; Greg Dowd
> > Subject: Time Stamp: Usage of TDTs
> >
> >
> > All,
> >
> > Over the last few weeks, there has been considerable discussion
> > on the need
> > for TDAs and their corresponding TDTs.  Much of the debate has been on
> > whether or not TDAs really add anything essential.  The heart
> of the issue
> > is whether or not the TSA is producing suitably trusted and
> accurate time.
> > It has been argued that if the time is accurate and trusted,
> then TDAs are
> > redundant (de la Vega and Zolotarev) and therefore should be eliminated.
> >
> > Rather than use TDAs to provide secondary non-time information to
> > substantiate a TST, an alternative use is for a TDT to convey traceable
> > trusted time certification from a National Timing Authority (NTA) (e.g.
> > NIST) to the TSAs.  Rather than conveying something indirect like stock
> > market closing data, this new type of TDT could be used to show, in a
> > non-repudiatable manner, that: (i) a TSA's clock is accurately
> > synchronized
> > to the NTA's clock ; and/or (ii) the time of creation of a TST embedding
> > such a TDT is traceable to the NTA.
> >
> > We are working with the S/Time group to create a protocol to reliably
> > distribute time from an NTA to allow lower clocks in a timing
> hierarchy to
> > be accurately and reliably synchronized to the NTA's clock.
> The result of
> > this process is a digitally signed certification that a clock
> is properly
> > synchronized to the NTA.  This certification can be embedded in a TDT to
> > prove that the time in the TDT or TST comes from a clock which has been
> > synchronized to an NTA.
> >
> > Use of a TDT in this manner accomplishes a number of things:
> >
> > 1.  It directly enhances the quality of the TST by providing both
> > a link to
> > UTC and traceability to NIST (or appropriate NTA);
> > 2.  It can be used to synchronize multiple TSA's to an NTA so
> > that the TSAs
> > can produce timestamps per NIST UTC (for instance) rather than
> their local
> > clock.
> > 3.  It will aid certain electronic commerce implementations since
> > the TSA's
> > clock can be shown to be directly traceable to an NTA.
> >
> > Thus, we urge the group not to abandon TDAs and TDTs, but to consider an
> > alternative use for them that would contribute additional,
> > directly relevant
> > timing information to enhance the operation of the TSA and the
> quality of
> > its TSTs.
> >
> > Regards,
> >
> > Bill
> >
>



Received: from localhost (daemon@localhost) by mail.proper.com (8.8.8/8.8.5) with SMTP id DAA28880; Thu, 1 Jul 1999 03:34:43 -0700 (PDT)
Received: by mail.imc.org (bulk_mailer v1.12); Thu, 1 Jul 1999 03:34:39 -0700
Received: from ns1.dmz.valicert.com (ns1.valicert.com [63.65.221.10]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id DAA28858 for <[e-mail]>; Thu, 1 Jul 1999 03:34:38 -0700 (PDT)
Received: from ns1.serverfarm.valicert.com (corporate-gw.valicert.com [63.65.221.2]) by ns1.dmz.valicert.com (8.9.2/8.9.2) with ESMTP id DAA26024 for <[e-mail]>; Thu, 1 Jul 1999 03:36:31 -0700 (PDT)
Received: from rhone (dhcp-3-128.engineering.valicert.com [192.168.3.128] (may be forged)) by ns1.serverfarm.valicert.com (8.9.2/8.9.2) with SMTP id DAA01993 for <[e-mail]>; Thu, 1 Jul 1999 03:37:46 -0700 (PDT)
From: "Ambarish Malpani" <[e-mail]>
To: <[e-mail]>
Subject: RE: I-D ACTION:draft-ietf-pkix-scvp-00.txt
Date: Thu, 1 Jul 1999 03:40:40 -0700
Message-ID: <00b301bec3ae$2a9dc0e0$[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
X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3
Importance: Normal
In-Reply-To: <[e-mail]>
Precedence: bulk
List-Archive: http://www.imc.org/ietf-pkix/mail-archive/
List-Unsubscribe: mailto:[e-mail]?body=unsubscribe
X-UIDL: 21029b3da627dd585bacf22486f7d17f

Unsigned requests are *not* insecure, as long as they contain
the RequestHash and the client verifies that it gets the same
RequestHash in the signed response.

(Paul, I think our example is broken - it doesn't reflect the
RequestHash in the response).

Ambarish


---------------------------------------------------------------------
Ambarish Malpani
Architect					         650.567.5457
ValiCert, Inc.				        [e-mail]
1215 Terra Bella Ave.		              http://www.valicert.com
Mountain View, CA 94043-1833


> -----Original Message-----
> From: Paul Hoffman / IMC [mailto:[e-mail]]
> Sent: Monday, June 28, 1999 8:17 PM
> To: [e-mail]
> Subject: Re: I-D ACTION:draft-ietf-pkix-scvp-00.txt
> 
> 
> At 08:07 PM 6/28/1999 -0700, Aram Perez wrote:
> > > It has the public key of the server built-in without a 
> cert. Remember, you
> > > don't need certs for root keys.
> >
> >This is fine but implies a limited number of SCVP servers.
> 
> A limited number that the client trusts. Absolutely. You 
> aren't going to 
> trust just anyone. Our expectation is that a typical client 
> might trust one 
> or two servers at a time. Of course, there's nothing in the 
> protocol that 
> limits the client to this.
> 
> >Believe me, I agree with specifying just one algorithm for 
> simplicity (and
> >interoperability) sake. It's just that I wanted someone else 
> to get beat up
> >like I was ;-)
> 
> We're open to such beating, and changing if necessary.
> 
> > >>4) Section 3.19 RequestSignature, 2nd paragraph. I would 
> suggest rewording
> > >>it as "Requests MUST include a RequestSignature item 
> unless the request is
> > >>done over an authenticated channel, such as..."
> > >
> > > That wording is equivalent to what we have, I think. I 
> prefer SHOULD to
> > > "MUST with exceptions" as a stylistic choice.
> >
> >I don't think that it is equivalent. With the original 
> wording I can send an
> >unsigned request over an unauthenticated channel and be 
> compliant but with
> >my wording I can't be compliant.
> 
> If you want to be insecure, you can. Again, our expectation is that 
> companies relying on SCVP will have their own SCVP servers. 
> They might want 
> to risk running the requests and responses over their 
> corporate networks. 
> Dumb, yes (given the small overhead of signing), but it should be 
> acceptable if they really want to do it even after the warnings.
> 
> > > We very explicitly did the opposite. *All* of the 
> semantics are in sections
> > > 2, 3, and 4; *only* the syntax is in sections 5 and 6. 
> The reason for this
> > > is to reduce confusion between the two syntaxes.
> >
> >In my cursory reading I missed this point. I would recommend 
> you highlight
> >this point to make it very clear and make sure all understand it.
> 
> Will do.
> 
> --Paul Hoffman, Director
> --Internet Mail Consortium
> 
> 


Received: from localhost (daemon@localhost) by mail.proper.com (8.8.8/8.8.5) with SMTP id DAA29139; Thu, 1 Jul 1999 03:44:32 -0700 (PDT)
Received: by mail.imc.org (bulk_mailer v1.12); Thu, 1 Jul 1999 03:44:31 -0700
Received: from ns1.dmz.valicert.com (ns1.valicert.com [63.65.221.10]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id DAA29116; Thu, 1 Jul 1999 03:44:30 -0700 (PDT)
Received: from ns1.serverfarm.valicert.com (corporate-gw.valicert.com [63.65.221.2]) by ns1.dmz.valicert.com (8.9.2/8.9.2) with ESMTP id DAA26066; Thu, 1 Jul 1999 03:46:33 -0700 (PDT)
Received: from rhone (dhcp-3-128.engineering.valicert.com [192.168.3.128] (may be forged)) by ns1.serverfarm.valicert.com (8.9.2/8.9.2) with SMTP id DAA02096; Thu, 1 Jul 1999 03:47:48 -0700 (PDT)
From: "Ambarish Malpani" <[e-mail]>
To: "'Carlisle Adams'" <[e-mail]>, "'Paul Hoffman / IMC'" <[e-mail]>
Cc: <[e-mail]>
Subject: RE: I-D ACTION:draft-ietf-pkix-scvp-00.txt
Date: Thu, 1 Jul 1999 03:50:42 -0700
Message-ID: <00b401bec3af$9137f810$[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
X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3
Importance: Normal
In-Reply-To: <[e-mail]>
Precedence: bulk
List-Archive: http://www.imc.org/ietf-pkix/mail-archive/
List-Unsubscribe: mailto:[e-mail]?body=unsubscribe
X-UIDL: 43ab5f9f14b2f90f914d31935d022a1c

Carlisle,
    If you are a small device that is trying to avoid the overhead
of understanding certs, it won't hurt too much if you tell it - here
is a key that you can trust for SCVP responses. You can build in a
lifetime for that trust - that doesn't need to be done in the form
of certs. Given that the usage of the cert is fixed - SCVP signing,
I am not sure that the device is going to benefit a whole bunch
by seeing the appropriate OIDs in the self-signed cert. Basically
you are trying to establish out of band trust for a key - whether
that is done with a self signed cert or in some other way doesn't
really matter a lot.

Regards,
Ambarish

---------------------------------------------------------------------
Ambarish Malpani
Architect					         650.567.5457
ValiCert, Inc.				        [e-mail]
1215 Terra Bella Ave.		              http://www.valicert.com
Mountain View, CA 94043-1833


> -----Original Message-----
> From: Carlisle Adams [mailto:[e-mail]]
> Sent: Tuesday, June 29, 1999 7:26 AM
> To: 'Paul Hoffman / IMC'
> Cc: [e-mail]
> Subject: RE: I-D ACTION:draft-ietf-pkix-scvp-00.txt
> 
> 
> Hi Paul,
> 
> > ----------
> > From: 	Paul Hoffman / IMC[SMTP:[e-mail]]
> > Sent: 	Monday, June 28, 1999 9:49 PM
> > To: 	[e-mail]
> > Subject: 	Re: I-D ACTION:draft-ietf-pkix-scvp-00.txt
> > 
> > At 06:24 PM 6/28/1999 -0700, Aram Perez wrote:
> > >1) I like the idea of SCVP but if the SCVP response is 
> signed, how does
> > the
> > >client verify the signature if it can't handle certs?
> > 
> > It has the public key of the server built-in without a 
> cert. Remember, you
> > 
> > don't need certs for root keys.
>  
> Quite true, if you expect the key to live forever and to be 
> unfettered with
> all those annoying policies, CPSs, key usages, key 
> identifiers, and so on.
> 
> If there is value in constraining the use and power of this 
> key in any way
> whatsoever (and there typically is), the utility of a self-signed cert
> really becomes apparent.
> 
> Just a thought...
> 
> Carlisle.
> 
> 
>