RE: Real-time Certificate Status Facility for OCSP - (RTCS)

[[e-mail] (Peter Gutmann)]

"Simon Tardell" <[e-mail]> writes:

>It is definitively an application level issue. Since you can bundle requests
>regarding certificates from wildely disparate CAs the responder must be able
>to indicate it knows the answer authoritatively to some of them but not all.
>Giving up on the whole bunch and going to the next doesn't solve anything,
>since the situation might be just the reverse there!
>
>So, yes, redundancy is possible, but only as long as you are only answering
>for one (physical) CA.

Oh, I see what you mean now.  The general idea with RTCS was that you're
serving queries straight from the CA cert store (well, obviously you're not
going to put the CA database directly online, but you know what I mean), so
the responses would be authoritative - in that design you either get a
response direct from the source or not.

In terms of handling bundling requests, the necessary status value can
trivially be added as a "no status info available" status, that's no problem.
My only slight concern is how necessary it would be in practice.  I know from
testing against deployed responders performed by myself and others that there
are various implementations which, if fed more than a single query, will
either reject the request or return info only for the first cert in the
request.  This indicates that this may be a somewhat rarely-used feature,
possibly driven mostly by a single large user (I know that a few
implementations added support for bundled queries only because they were
nagged about it by a certain large consortium whose name begins with an 'I'
:-).  So you've got something that may serve only a small user community, and
whose use may not match the "RT" part of "RTCS" too well.

I'd be interested in people's thoughts on this.  I'm quite happy to add it if
folks think it'll be useful (it's a single sentence to define a new status
value, statusNotAvailable), and it seems like a good idea to have it there.  I
guess dropping 'superseded' and adding 'statusNotAvailable' would address the
comments people have made recently?  I can also add some notes to the
rationale explaining that in some cases it may be OK performance-wise to go
via a transaction coordinator rather than straight to the horse's mouth, which
is why the statusNotAvailable response is provided - it's a bit like the SQL
Server or MySQL database errors you often see on web pages, the transaction
coordinator is up, but the backend that provides the info you need is down.

Peter.



Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h0VALWJ18447 for ietf-pkix-bks; Fri, 31 Jan 2003 02:21:32 -0800 (PST)
Received: from hermes.cs.auckland.ac.nz (hermes.cs.auckland.ac.nz [130.216.35.151]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h0VALUo18443 for <[e-mail]>; Fri, 31 Jan 2003 02:21:30 -0800 (PST)
Received: from medusa01.cs.auckland.ac.nz (medusa01.cs.auckland.ac.nz [130.216.34.60]) by hermes.cs.auckland.ac.nz (8.12.4/8.12.4) with ESMTP id h0VAK5VJ026761; Fri, 31 Jan 2003 23:20:05 +1300
Received: (from pgut001@localhost) by medusa01.cs.auckland.ac.nz (8.11.6/8.11.6) id h0VAM7G11062; Fri, 31 Jan 2003 23:22:07 +1300
Date: Fri, 31 Jan 2003 23:22:07 +1300
Message-Id: <[e-mail]>
From: [e-mail] (Peter Gutmann)
To: [e-mail], [e-mail], [e-mail], [e-mail]
Subject: RE: Real-time Certificate Status Facility for OCSP - (RTCS)
Cc: [e-mail], [e-mail], [e-mail]
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

"Simon Tardell" <[e-mail]> writes:

>It is definitively an application level issue. Since you can bundle requests
>regarding certificates from wildely disparate CAs the responder must be able
>to indicate it knows the answer authoritatively to some of them but not all.
>Giving up on the whole bunch and going to the next doesn't solve anything,
>since the situation might be just the reverse there!
>
>So, yes, redundancy is possible, but only as long as you are only answering
>for one (physical) CA.

Oh, I see what you mean now.  The general idea with RTCS was that you're
serving queries straight from the CA cert store (well, obviously you're not
going to put the CA database directly online, but you know what I mean), so
the responses would be authoritative - in that design you either get a
response direct from the source or not.

In terms of handling bundling requests, the necessary status value can
trivially be added as a "no status info available" status, that's no problem.
My only slight concern is how necessary it would be in practice.  I know from
testing against deployed responders performed by myself and others that there
are various implementations which, if fed more than a single query, will
either reject the request or return info only for the first cert in the
request.  This indicates that this may be a somewhat rarely-used feature,
possibly driven mostly by a single large user (I know that a few
implementations added support for bundled queries only because they were
nagged about it by a certain large consortium whose name begins with an 'I'
:-).  So you've got something that may serve only a small user community, and
whose use may not match the "RT" part of "RTCS" too well.

I'd be interested in people's thoughts on this.  I'm quite happy to add it if
folks think it'll be useful (it's a single sentence to define a new status
value, statusNotAvailable), and it seems like a good idea to have it there.  I
guess dropping 'superseded' and adding 'statusNotAvailable' would address the
comments people have made recently?  I can also add some notes to the
rationale explaining that in some cases it may be OK performance-wise to go
via a transaction coordinator rather than straight to the horse's mouth, which
is why the statusNotAvailable response is provided - it's a bit like the SQL
Server or MySQL database errors you often see on web pages, the transaction
coordinator is up, but the backend that provides the info you need is down.

Peter.


Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h0V9ntj14085 for ietf-pkix-bks; Fri, 31 Jan 2003 01:49:55 -0800 (PST)
Received: from hermes.cs.auckland.ac.nz (hermes.cs.auckland.ac.nz [130.216.35.151]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h0V9nro14077 for <[e-mail]>; Fri, 31 Jan 2003 01:49:53 -0800 (PST)
Received: from medusa01.cs.auckland.ac.nz (medusa01.cs.auckland.ac.nz [130.216.34.60]) by hermes.cs.auckland.ac.nz (8.12.4/8.12.4) with ESMTP id h0V9n5VJ026399; Fri, 31 Jan 2003 22:49:05 +1300
Received: (from pgut001@localhost) by medusa01.cs.auckland.ac.nz (8.11.6/8.11.6) id h0V9p5927740; Fri, 31 Jan 2003 22:51:05 +1300
Date: Fri, 31 Jan 2003 22:51:05 +1300
Message-Id: <[e-mail]>
From: [e-mail] (Peter Gutmann)
To: [e-mail], [e-mail]
Subject: Re: Real-time Certificate Status Facility for OCSP - (RTCS)
Cc: [e-mail], [e-mail], [e-mail]
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

[A bit of a flame, sorry folks]

Denis Pinkas <[e-mail]> writes:

>"invalid without being revoked" does not mean anything.

So you're saying the only way a certificate can ever be regarded as invalid is
if it's formally revoked by a CA?

>>and can be valid but OCSP can't tell you that because it can only say "not
>>revoked", which doesn't mean "valid" - see the endless debate on this over the
>>years).
>
>There is no such an endless debate, except from your side.

Anyone who bothers to search the PKIX archives can see how accurate Denis'
claims are.  

(It's amazing you can even make such a claim, when anyone who's been on the
 PKIX list for more than a few months has seen the OCSP-status debate crop up
 at least once.  You've even taken part in them yourself... a 30-second search
 of the archives dug up:
 
 Subject: Re: German Law and OCSP
 From: Denis Pinkas <Denis.Pinkas@xxxxxxxx>
 Date: Thu, 10 Feb 2000 16:59:24 +0100
 
 as one example (I don't have the '01 archives becuase they're too big, that
 was the last one from '00)).

>[Blah blah blah, lots more bogus whining and moaning] for example:

  Because the hash of a certificate is not included in the CRL, so using CRLs
  only would not be possible.

and then right after it you quote the very text which refutes your claim:

>   memcpy( response.certHash, request.certHash, 20 );

and so on and so on.  Look, I'm sorry, but you're grasping at any available
(or imaginary) straw here in an attempt to criticse RTCS.  It's obvious from
your messages (and others have commented on this as well) that you've barely
read the RTCS draft (if at all), and even then only to pick out bits to
complain about.  The posting of obviously incorrect claims such as the ones
cited above aren't helping your credibility much either.  It's simply a waste
of time me even responding to stuff like this - the excerpt above shows that
not only have you barely read RTCS, you're not reading the replies either,
except to pick out bits to criticise.

In the meantime I welcome intelligent debate with anyone else (the cert-HTTP
draft has been considerably improved by recent user feedback).

Peter.



Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h0V9QIv10746 for ietf-pkix-bks; Fri, 31 Jan 2003 01:26:18 -0800 (PST)
Received: from nalle.datum.nu (as6-6-8.s.bonet.se [217.215.37.231]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h0V9QGo10741 for <[e-mail]>; Fri, 31 Jan 2003 01:26:17 -0800 (PST)
Received: from stl (as3-3-6.apv.s.bonet.se [217.215.35.57]) by nalle.datum.nu (Postfix) with ESMTP id 14ECB10F715; Fri, 31 Jan 2003 10:26:11 +0100 (CET)
From: "Simon Tardell" <[e-mail]>
To: "'Peter Gutmann'" <[e-mail]>, <[e-mail]>, <[e-mail]>
Cc: <[e-mail]>, <[e-mail]>, <[e-mail]>
Subject: RE: Real-time Certificate Status Facility for OCSP - (RTCS)
Date: Fri, 31 Jan 2003 10:25:54 +0100
Message-ID: <02b301c2c90a$c16b8420$0a01a8c0@stl>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook, Build 10.0.3416
X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2600.0000
Importance: Normal
In-Reply-To: <[e-mail]>
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

It is definitively an application level issue. Since you can bundle
requests regarding certificates from wildely disparate CAs the responder
must be able to indicate it knows the answer authoritatively to some of
them but not all. Giving up on the whole bunch and going to the next
doesn't solve anything, since the situation might be just the reverse
there!

So, yes, redundancy is possible, but only as long as you are only
answering for one (physical) CA.

Simon 

Simon Tardell, cell [phone], [e-mail]


> -----Original Message-----
> From: [e-mail] 
> [mailto:[e-mail]] On Behalf Of Peter Gutmann
> Sent: den 31 januari 2003 04:10
> To: [e-mail]; [e-mail]; 
> [e-mail]; [e-mail]
> Cc: [e-mail]; [e-mail]; [e-mail]
> Subject: RE: Real-time Certificate Status Facility for OCSP - (RTCS)
> 
> 
> 
> "Simon Tardell" <[e-mail]> writes:
> 
> >If there is no "unknown" (=I don't have a clue) answer, then 
> the RTCS 
> >server always has to be the authoritative source of information. You 
> >can't have two of them to offer redundancy, because the 
> other one has 
> >no way to indicate that it is not sure that it is up to date. With a 
> >ternary response good/bad/gotosomeoneelse, redundancy is trivial.
> 
> Uhh... redundant failover is a network-level issue, not 
> something for the cert-status protocol.  RTCS is no better or 
> worse off than OCSP, if the server is down you go to the 
> backup, if not you use the primary.  There's no need for an 
> "unknown" response, you either get a yes/no from the server, 
> or you can't contact it and fall back to whatever alternative 
> you're using (redundant failover, DNS SRV (which has what I 
> thought was rather nice built-in load- balancing until 
> someone else delivered a long rant about how it wasn't the 
> place for it), or whatever).  The one I prefer, because it's 
> so easy to tie into the existing infrastructure, is an HTTP 
> 302 - you're talking HTTP anyway, may as well use the 
> facilities it provides.  I would hope that redundancy with 
> RTCS isn't impossible, because if it is the existing systems 
> doing it would suddenly vanish in a puff of nonreality :-).
> 
> Peter.
> 
> 



Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h0V4vBN11729 for ietf-pkix-bks; Thu, 30 Jan 2003 20:57:11 -0800 (PST)
Received: from mail-green.research.att.com (H-135-207-30-103.research.att.com [135.207.30.103]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h0V4vAo11725 for <[e-mail]>; Thu, 30 Jan 2003 20:57:10 -0800 (PST)
Received: from postal.research.att.com (postal.research.att.com [135.207.23.30]) by mail-green.research.att.com (Postfix) with ESMTP id 77DD41E1B8; Thu, 30 Jan 2003 23:57:06 -0500 (EST)
Received: from berkshire.research.att.com (guard.research.att.com [135.207.1.20]) by postal.research.att.com (8.8.7/8.8.7) with ESMTP id XAA03030; Thu, 30 Jan 2003 23:57:04 -0500 (EST)
Received: from research.att.com (localhost [127.0.0.1]) by berkshire.research.att.com (Postfix) with ESMTP id 958D87B4D; Thu, 30 Jan 2003 23:57:03 -0500 (EST)
X-Mailer: exmh version 2.5 07/13/2001 with nmh-1.0.4
From: "Steven M. Bellovin" <[e-mail]>
To: Tim Polk <[e-mail]>
Cc: "Jeff Schiller" <[e-mail]>, [e-mail], Stephen Kent <[e-mail]>, Carlisle Adams <[e-mail]>, Stephen Farrell <[e-mail]>
Subject: Re: Request for Consideration of RFC 
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Date: Thu, 30 Jan 2003 23:57:03 -0500
Message-Id: <[e-mail]>
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

I've updated both in draft-tracker.  They're now in state "publication 
requested".  The next step is for Jeff and/or I to review them.

		--Steve Bellovin, http://www.research.att.com/~smb (me)
		http://www.wilyhacker.com (2nd edition of "Firewalls" book)




Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h0V4ugH11721 for ietf-pkix-bks; Thu, 30 Jan 2003 20:56:42 -0800 (PST)
Received: from hermes.cs.auckland.ac.nz (hermes.cs.auckland.ac.nz [130.216.35.151]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h0V4ueo11717 for <[e-mail]>; Thu, 30 Jan 2003 20:56:40 -0800 (PST)
Received: from medusa01.cs.auckland.ac.nz (medusa01.cs.auckland.ac.nz [130.216.34.60]) by hermes.cs.auckland.ac.nz (8.12.4/8.12.4) with ESMTP id h0V4tNVJ023352; Fri, 31 Jan 2003 17:55:23 +1300
Received: (from pgut001@localhost) by medusa01.cs.auckland.ac.nz (8.11.6/8.11.6) id h0V4vKU25260; Fri, 31 Jan 2003 17:57:20 +1300
Date: Fri, 31 Jan 2003 17:57:20 +1300
Message-Id: <[e-mail]>
From: [e-mail] (Peter Gutmann)
To: [e-mail], [e-mail], [e-mail]
Subject: RE: Real-time Certificate Status Facility for OCSP - (RTCS)
Cc: [e-mail], [e-mail], [e-mail]
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

"Marc Poulaud" <[e-mail]> writes:

>How does a RP treating unknown as 'I cannot rely on this certificate' not
>work?

See the draft:

  This problem interacts badly with the one in section 2.1 in that an unknown
  response could mean anything from "I couldn't find a CRL for this
  certificate" to "I don't know the status of this certificate" to "This may
  well be a valid certificate but your software and mine disagree over how to
  generate the identifier", and there is no way to determine what the actual
  problem is.

In the most extreme case (the last one listed, which has occurred several
times in practice), every cert will return "unknown", so that (using your
interpretation) no cert can be used.  This is of little value to RP's :-).

>Peter - can you help me with a specific example of where having less
>ambiguity (than unknown) better informs the RP to the point they might act
>differently?

Well, see above.  In OCSP's case the "unknown" response is a bit like the joke
about Ken Thompson's car flashing a large "?" on the dashboard whenever
there's a problem - it's the OCSP responder throwing up its hands and running
around in circles screaming and shouting ("panic" would be a good alternative
name for this).  RTCS was designed specifically to avoid this, following the
standard CC-processing model: You get either a black-and-white yes or no
(a.k.a. "accepted/declined") reply, or you can't contact the server in which
case you presumably fall back to offline card-processing mechanisms, or
whatever your policy specifies for emergencies.  There's no need for an OCSP-
type "panic" response, because RTCS doesn't panic.

These problems with the ambiguous OCSP status values have already been debated
to death many times before on the list (see the list archives for more info).
With RTCS you don't have this problem, since the reply is unambiguous.

Incidentally, I suggested in one (off-list) message that if people are really
so keen to see a "panic" response then I could add some text to the draft
requiring that responders return this at random intervals to liven things up,
in the same way that you can get a BSOD kernel module for Linux for people who
really want that full Windows bug-compatibility :-).

Peter.



Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h0V39dV08761 for ietf-pkix-bks; Thu, 30 Jan 2003 19:09:39 -0800 (PST)
Received: from hermes.cs.auckland.ac.nz (hermes.cs.auckland.ac.nz [130.216.35.151]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h0V39bo08757 for <[e-mail]>; Thu, 30 Jan 2003 19:09:37 -0800 (PST)
Received: from medusa01.cs.auckland.ac.nz (medusa01.cs.auckland.ac.nz [130.216.34.60]) by hermes.cs.auckland.ac.nz (8.12.4/8.12.4) with ESMTP id h0V38AVJ021852; Fri, 31 Jan 2003 16:08:10 +1300
Received: (from pgut001@localhost) by medusa01.cs.auckland.ac.nz (8.11.6/8.11.6) id h0V3A3b06891; Fri, 31 Jan 2003 16:10:03 +1300
Date: Fri, 31 Jan 2003 16:10:03 +1300
Message-Id: <[e-mail]>
From: [e-mail] (Peter Gutmann)
To: [e-mail], [e-mail], [e-mail], [e-mail]
Subject: RE: Real-time Certificate Status Facility for OCSP - (RTCS)
Cc: [e-mail], [e-mail], [e-mail]
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

"Simon Tardell" <[e-mail]> writes:

>If there is no "unknown" (=I don't have a clue) answer, then the RTCS server
>always has to be the authoritative source of information. You can't have two
>of them to offer redundancy, because the other one has no way to indicate
>that it is not sure that it is up to date. With a ternary response
>good/bad/gotosomeoneelse, redundancy is trivial.

Uhh... redundant failover is a network-level issue, not something for the
cert-status protocol.  RTCS is no better or worse off than OCSP, if the server
is down you go to the backup, if not you use the primary.  There's no need for
an "unknown" response, you either get a yes/no from the server, or you can't
contact it and fall back to whatever alternative you're using (redundant
failover, DNS SRV (which has what I thought was rather nice built-in load-
balancing until someone else delivered a long rant about how it wasn't the
place for it), or whatever).  The one I prefer, because it's so easy to tie
into the existing infrastructure, is an HTTP 302 - you're talking HTTP anyway,
may as well use the facilities it provides.  I would hope that redundancy with
RTCS isn't impossible, because if it is the existing systems doing it would
suddenly vanish in a puff of nonreality :-).

Peter.



Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h0UMs3a28975 for ietf-pkix-bks; Thu, 30 Jan 2003 14:54:03 -0800 (PST)
Received: from postmark.nist.gov (pushme.nist.gov [129.6.16.92]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h0UMs1o28970 for <[e-mail]>; Thu, 30 Jan 2003 14:54:01 -0800 (PST)
Received: from krdp8.nist.gov (krdp8.ncsl.nist.gov [129.6.54.113]) by postmark.nist.gov (8.12.5/8.12.5) with ESMTP id h0UMrgV5012264; Thu, 30 Jan 2003 17:53:42 -0500 (EST)
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Version 5.1
Date: Thu, 30 Jan 2003 17:55:20 -0500
To: [e-mail], "Steven M. Bellovin" <[e-mail]>, "Jeff Schiller" <[e-mail]>
From: Tim Polk <[e-mail]>
Subject: Request for Consideration of RFC 2511bis by IESG
Cc: [e-mail], Stephen Kent <[e-mail]>, Carlisle Adams <[e-mail]>, Stephen Farrell <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Jeff & Steve,

The PKIX WG has completed Last Call and achieved rough consensus on the 
specification "Internet X.509 Public Key Infrastructure Certificate Request 
Message Format (CRMF)".  The current draft is 
<draft-ietf-pkix-rfc2511bis-05.txt>, and is available at

	http://www.ietf.org/internet-drafts/draft-ietf-pkix-rfc2511bis-05.txt

This specification updates and obsoletes RFC 2511.  The updated 
specification and reflects the results of interoperability testing between 
several independent implementations.  As the results of the 
interoperability testing have not yet been documented, we are currently 
requesting the IESG  cycle the specification at Proposed Standard.  Once 
the test results are available, we expect to request progression to Draft 
Standard without additional changes.

Thanks,

Tim Polk 



Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h0UMqVn28912 for ietf-pkix-bks; Thu, 30 Jan 2003 14:52:31 -0800 (PST)
Received: from postmark.nist.gov (pushme.nist.gov [129.6.16.92]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h0UMqTo28908 for <[e-mail]>; Thu, 30 Jan 2003 14:52:29 -0800 (PST)
Received: from krdp8.nist.gov (krdp8.ncsl.nist.gov [129.6.54.113]) by postmark.nist.gov (8.12.5/8.12.5) with ESMTP id h0UMq4V5011664; Thu, 30 Jan 2003 17:52:04 -0500 (EST)
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Version 5.1
Date: Thu, 30 Jan 2003 17:53:42 -0500
To: [e-mail], "Steven M. Bellovin" <[e-mail]>, "Jeff Schiller" <[e-mail]>
From: Tim Polk <[e-mail]>
Subject: Request for Consideration of RFC 2510bis by IESG
Cc: [e-mail], Stephen Kent <[e-mail]>, Carlisle Adams <[e-mail]>, Stephen Farrell <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Jeff & Steve,

The PKIX WG has completed Last Call and achieved rough consensus on the 
specification "Internet X.509 Public Key Infrastructure Certificate 
Management Protocols".  The current draft is 
<draft-ietf-pkix-rfc2510bis-07.txt>, and is available at

	http://www.ietf.org/internet-drafts/draft-ietf-pkix-rfc2510bis-07.txt

This specification updates and obsoletes RFC 2510.  The updated 
specification and reflects the results of interoperability testing between 
several independent implementations.  As the results of the 
interoperability testing have not yet been documented, we are currently 
requesting the IESG  cycle the specification at Proposed Standard.  Once 
the test results are available, we expect to request progression to Draft 
Standard without additional changes.

Thanks,

Tim Polk



Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h0UMKOa28090 for ietf-pkix-bks; Thu, 30 Jan 2003 14:20:24 -0800 (PST)
Received: from maild.telia.com (maild.telia.com [194.22.190.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h0UMKMo28086 for <[e-mail]>; Thu, 30 Jan 2003 14:20:22 -0800 (PST)
Received: from arport (h220n2fls31o1122.telia.com [212.181.142.220]) by maild.telia.com (8.12.5/8.12.5) with SMTP id h0UMK3Ul009097; Thu, 30 Jan 2003 23:20:04 +0100 (CET)
X-Original-Recipient: [e-mail]
Message-ID: <001201c2c8ac$6d6cc450$0500a8c0@arport>
From: "Anders Rundgren" <[e-mail]>
To: "Simon Tardell" <[e-mail]>, "'Peter Gutmann'" <[e-mail]>, <[e-mail]>, <[e-mail]>
Cc: <[e-mail]>, <[e-mail]>
References: <028101c2c8ab$61e89330$0a01a8c0@stl>
Subject: Re: Real-time Certificate Status Facility for OCSP - (RTCS)
Date: Thu, 30 Jan 2003 23:10:35 +0100
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.50.4133.2400
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Simon,
I assume that the "I don't know" thing is for independent responders
that are not directly hooked to the CA.   That seems to be out of scope.
Redundancy may though be in scope as anything like HTTP 500 or
time-out should force the client to look for other options (if there
are such...)

Anders


----- Original Message ----- 
From: "Simon Tardell" <[e-mail]>
To: "'Peter Gutmann'" <[e-mail]>; <[e-mail]>; <[e-mail]>
Cc: <[e-mail]>; <[e-mail]>; <[e-mail]>
Sent: Thursday, January 30, 2003 23:03
Subject: RE: Real-time Certificate Status Facility for OCSP - (RTCS)


> Denis Pinkas <[e-mail]> writes:
> 
> >>Having a status of Good would seem enough for an RP to rely on; any 
> >>other case means the RP can't rely on it (not present (which is 
> >>presumably
> >>'unknown') or revoked).
> >
> >Since I am not Epimetheus, I will keep close the Pandora box and let 
> >Peter answer that question.
> 
> Uhh, I'm not sure what there is to answer, since Marc has 
> summed it up nicely. In authenticated-dictionary terms it's 
> "Present/Not present".  In more specific cert-status terms 
> it's "Good/Not good", in financial-institution terms it's 
> "Accepted/Declined", etc etc.  The concept of "Unknown" 
> (which is required in OCSP because it can't provide an 
> unambiguous response) doesn't even feature here.

If there is no "unknown" (=I don't have a clue) answer, then the RTCS
server always has to be the authoritative source of information. You
can't have two of them to offer redundancy, because the other one has no
way to indicate that it is not sure that it is up to date. With a
ternary response good/bad/gotosomeoneelse, redundancy is trivial.

Simon


Simon Tardell, cell [phone], [e-mail]





Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h0UM3UW27550 for ietf-pkix-bks; Thu, 30 Jan 2003 14:03:30 -0800 (PST)
Received: from nalle.datum.nu (as6-6-8.s.bonet.se [217.215.37.231]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h0UM3Ro27546 for <[e-mail]>; Thu, 30 Jan 2003 14:03:27 -0800 (PST)
Received: from stl (as3-3-6.apv.s.bonet.se [217.215.35.57]) by nalle.datum.nu (Postfix) with ESMTP id E743D10F751; Thu, 30 Jan 2003 23:03:20 +0100 (CET)
From: "Simon Tardell" <[e-mail]>
To: "'Peter Gutmann'" <[e-mail]>, <[e-mail]>, <[e-mail]>
Cc: <[e-mail]>, <[e-mail]>, <[e-mail]>
Subject: RE: Real-time Certificate Status Facility for OCSP - (RTCS)
Date: Thu, 30 Jan 2003 23:03:12 +0100
Message-ID: <028101c2c8ab$61e89330$0a01a8c0@stl>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook, Build 10.0.3416
X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2600.0000
Importance: Normal
In-Reply-To: <[e-mail]>
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

> Denis Pinkas <[e-mail]> writes:
> 
> >>Having a status of Good would seem enough for an RP to rely on; any 
> >>other case means the RP can't rely on it (not present (which is 
> >>presumably
> >>'unknown') or revoked).
> >
> >Since I am not Epimetheus, I will keep close the Pandora box and let 
> >Peter answer that question.
> 
> Uhh, I'm not sure what there is to answer, since Marc has 
> summed it up nicely. In authenticated-dictionary terms it's 
> "Present/Not present".  In more specific cert-status terms 
> it's "Good/Not good", in financial-institution terms it's 
> "Accepted/Declined", etc etc.  The concept of "Unknown" 
> (which is required in OCSP because it can't provide an 
> unambiguous response) doesn't even feature here.

If there is no "unknown" (=I don't have a clue) answer, then the RTCS
server always has to be the authoritative source of information. You
can't have two of them to offer redundancy, because the other one has no
way to indicate that it is not sure that it is up to date. With a
ternary response good/bad/gotosomeoneelse, redundancy is trivial.

Simon


Simon Tardell, cell [phone], [e-mail]




Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h0UDlBa05621 for ietf-pkix-bks; Thu, 30 Jan 2003 05:47:11 -0800 (PST)
Received: from mta05-svc.ntlworld.com (mta05-svc.ntlworld.com [62.253.162.45]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h0UDl9o05613 for <[e-mail]>; Thu, 30 Jan 2003 05:47:09 -0800 (PST)
Received: from f67j40j ([213.106.136.127]) by mta05-svc.ntlworld.com (InterMail vM.4.01.03.27 201-229-121-127-20010626) with SMTP id <20030130134707.UOST900.mta05-svc.ntlworld.com@f67j40j>; Thu, 30 Jan 2003 13:47:07 +0000
From: "Marc Poulaud" <[e-mail]>
To: "Peter Gutmann" <[e-mail]>, <[e-mail]>
Cc: <[e-mail]>, <[e-mail]>, <[e-mail]>
Subject: RE: Real-time Certificate Status Facility for OCSP - (RTCS)
Date: Thu, 30 Jan 2003 13:47:03 -0000
MIME-Version: 1.0
Message-ID: <[e-mail]>
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0)
Content-Type: multipart/signed; boundary="----=_NextPart_000_026B_01C2C866.0E078B30"; protocol="application/x-pkcs7-signature"; micalg=SHA1
In-Reply-To: <[e-mail]>
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

This is a multi-part message in MIME format.

------=_NextPart_000_026B_01C2C866.0E078B30
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit

Peter,

Confession time - I've only just started reading your I-D on RTCS, and I'm
going to send you some comments on it.

I'll re-phrase my question:

How does a RP treating unknown as 'I cannot rely on this certificate' not
work?

I agree that having more information might help inform the RP and the SC
resolve the issue from a practical point of view, but the ambiguity you
talk of does not seem to materially affect what the RP will do in this
event. I did always think OK was a bit wishy-washy, but it's the context
around these states (and perhaps the specific business/contractual rules)
that determine the action by the RP (I think this is the point Carlisle
was making (Carlisle: aps if not)).

I suspect that the richness and unambiguity has to be a sufficient level
to enable the business (and systems) to work. Is OCSP high enough? Does
RTCS allow things to be done better/faster/cheaper? I'll read-all-bout-it
in the I-D :-)

Peter - can you help me with a specific example of where having less
ambiguity (than unknown) better informs the RP to the point they might act
differently?

Respectively,

Marc.
-----Original Message-----
From: [e-mail]
[mailto:[e-mail]]On Behalf Of Peter Gutmann
Sent: Thursday, January 30, 2003 11:11
To: [e-mail]; [e-mail]
Cc: [e-mail]; [e-mail]; [e-mail];
[e-mail]
Subject: Re: Real-time Certificate Status Facility for OCSP - (RTCS)


Denis Pinkas <[e-mail]> writes:

>>Having a status of Good would seem enough for an RP to rely on; any
other
>>case means the RP can't rely on it (not present (which is presumably
>>'unknown') or revoked).
>
>Since I am not Epimetheus, I will keep close the Pandora box and let
Peter
>answer that question.

Uhh, I'm not sure what there is to answer, since Marc has summed it up
nicely.
In authenticated-dictionary terms it's "Present/Not present".  In more
specific cert-status terms it's "Good/Not good", in financial-institution
terms it's "Accepted/Declined", etc etc.  The concept of "Unknown" (which
is
required in OCSP because it can't provide an unambiguous response) doesn't
even feature here.

Peter.

------=_NextPart_000_026B_01C2C866.0E078B30
Content-Type: application/x-pkcs7-signature;
	name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment;
	filename="smime.p7s"

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIKITCCAj0w
ggGmAhEAzbp/VvDf5LxU/iKss3KqVTANBgkqhkiG9w0BAQIFADBfMQswCQYDVQQGEwJVUzEXMBUG
A1UEChMOVmVyaVNpZ24sIEluYy4xNzA1BgNVBAsTLkNsYXNzIDEgUHVibGljIFByaW1hcnkgQ2Vy
dGlmaWNhdGlvbiBBdXRob3JpdHkwHhcNOTYwMTI5MDAwMDAwWhcNMjgwODAxMjM1OTU5WjBfMQsw
CQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xNzA1BgNVBAsTLkNsYXNzIDEgUHVi
bGljIFByaW1hcnkgQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkwgZ8wDQYJKoZIhvcNAQEBBQADgY0A
MIGJAoGBAOUZv22jVmEtmUhx9mfeuY3rt56GgAqRDvo4Ja9GiILlc6igmyRdDR/MZW4MsNBWhBiH
mgabEKFz37RYOWtuwfYV1aioP6oSBo0xrH+wNNePNGeICc0UEeJORVZpH3gCgNrcR5EpuzbJY1zF
4Ncth3uhtzKwezC6Ki8xqu6jZ9rbAgMBAAEwDQYJKoZIhvcNAQECBQADgYEATD+4i8Zo3+5DMw5d
6abLB4RNejP/khv0Nq3YlSI2aBFsfELM85wuxAc/FLAPT/+Qknb54rxK6Y/NoIAK98Up8YIiXbix
3YEjo3slFUYweRb46gVLlH8dwhzI47f0EEA8E8NfH1PoSOSGtHuhNbB7Jbq4046rPzidADQAmPPR
cZQwggNiMIICy6ADAgECAhAL2gsXwT+JjqsJdHq0zi4zMA0GCSqGSIb3DQEBAgUAMF8xCzAJBgNV
BAYTAlVTMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjE3MDUGA1UECxMuQ2xhc3MgMSBQdWJsaWMg
UHJpbWFyeSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTAeFw05ODA1MTIwMDAwMDBaFw0wODA1MTIy
MzU5NTlaMIHMMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1
c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNv
cnAuIEJ5IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xhc3MgMSBDQSBJ
bmRpdmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkMIGfMA0GCSqGSIb3DQEB
AQUAA4GNADCBiQKBgQC7WkSKBBa7Vf0DeootlE8VeDa4DUqyb5xUv7zodyqdufBou5XZMUFweoFL
uUgTVi3HCOGEQqvAopKrRFyqQvCCDgLpL/vCO7u+yScKXbawNkIztW5UiE+HSr8Z2vkV6A+Hthzj
zMaajn9qJJLj/OBluqexfu/J2zdqyErICQbkmQIDAQABo4GwMIGtMA8GA1UdEwQIMAYBAf8CAQAw
RwYDVR0gBEAwPjA8BgtghkgBhvhFAQcBATAtMCsGCCsGAQUFBwIBFh93d3cudmVyaXNpZ24uY29t
L3JlcG9zaXRvcnkvUlBBMDEGA1UdHwQqMCgwJqAkoCKGIGh0dHA6Ly9jcmwudmVyaXNpZ24uY29t
L3BjYTEuY3JsMAsGA1UdDwQEAwIBBjARBglghkgBhvhCAQEEBAMCAQYwDQYJKoZIhvcNAQECBQAD
gYEAAn2eb0VLOKC43ulTZCG85Ewrjx7+kkCs2Ao5aqEyISwHm6tZ/tJiGn1VOLA3c9z0B2ZjYr3h
U3BSh+eo2FLpWy2q4d7PrDFU1IsZyNgjqO8EKzJ9LBgcyHyJqC538kTRZQpNdLXu0xuSc3QuiTs1
E3LnQDGa07LEq+dWvovj+xUwggR2MIID36ADAgECAhB/l4yg+FrgmGLkay+Z3cRwMA0GCSqGSIb3
DQEBBAUAMIHMMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1
c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNv
cnAuIEJ5IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xhc3MgMSBDQSBJ
bmRpdmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkMB4XDTAyMTAwNzAwMDAw
MFoXDTAzMTAwNzIzNTk1OVowggEaMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMW
VmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0
b3J5L1JQQSBJbmNvcnAuIGJ5IFJlZi4sTElBQi5MVEQoYyk5ODEeMBwGA1UECxMVUGVyc29uYSBO
b3QgVmFsaWRhdGVkMTQwMgYDVQQLEytEaWdpdGFsIElEIENsYXNzIDEgLSBNaWNyb3NvZnQgRnVs
bCBTZXJ2aWNlMRUwEwYDVQQDFAxNYXJjIFBvdWxhdWQxKTAnBgkqhkiG9w0BCQEWGm1hcmMucG91
bGF1ZEBpLXNvbHZlLmNvLnVrMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDfd3CCaom3tU0P
mdCz0ggSdD8UNJMSVDPou1CJjsLvYpwUySsSQgUdYdFjvQmheBDL2z0T3dX1mvce5WJrDg5fcWQG
aUmQbubJ0qxdK5uT4IkNJx9s1PPDfOEj4PdJExyyG0Cbsvwo8Wyq+xnRlCcMzwm4D/XNnXqkrEZw
MifX+wIDAQABo4IBBjCCAQIwCQYDVR0TBAIwADCBrAYDVR0gBIGkMIGhMIGeBgtghkgBhvhFAQcB
ATCBjjAoBggrBgEFBQcCARYcaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL0NQUzBiBggrBgEFBQcC
AjBWMBUWDlZlcmlTaWduLCBJbmMuMAMCAQEaPVZlcmlTaWduJ3MgQ1BTIGluY29ycC4gYnkgcmVm
ZXJlbmNlIGxpYWIuIGx0ZC4gKGMpOTcgVmVyaVNpZ24wEQYJYIZIAYb4QgEBBAQDAgeAMDMGA1Ud
HwQsMCowKKAmoCSGImh0dHA6Ly9jcmwudmVyaXNpZ24uY29tL2NsYXNzMS5jcmwwDQYJKoZIhvcN
AQEEBQADgYEAh/j3ynKibKwqRZA4Y3KsDwboqp78AIi04ATWtK0MSq+qL2FIu7HORZrN9eJVwqkm
3lr4tNU/ld7bCqnd9zHO4FRyg17pDVwZ4/7Z3UR+wW6WLj2FXn+QPRPWuyeIpOz+LxPhn4HaBIS6
qaO6+glnQl0IX6axcAhLebO/J/hNIQAxggNWMIIDUgIBATCB4TCBzDEXMBUGA1UEChMOVmVyaVNp
Z24sIEluYy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0IE5ldHdvcmsxRjBEBgNVBAsTPXd3dy52
ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEgSW5jb3JwLiBCeSBSZWYuLExJQUIuTFREKGMpOTgx
SDBGBgNVBAMTP1ZlcmlTaWduIENsYXNzIDEgQ0EgSW5kaXZpZHVhbCBTdWJzY3JpYmVyLVBlcnNv
bmEgTm90IFZhbGlkYXRlZAIQf5eMoPha4Jhi5Gsvmd3EcDAJBgUrDgMCGgUAoIIByjAYBgkqhkiG
9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0wMzAxMzAxMzQ2NTZaMCMGCSqGSIb3
DQEJBDEWBBToid734Qva/BoiZ7TLNm6Io187GTB2BgkqhkiG9w0BCQ8xaTBnMAoGCCqGSIb3DQMH
MA4GCCqGSIb3DQMCAgIAgDAHBgUrDgMCBzAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDAHBgUrDgMC
GjAHBgUrDgMCGjAKBggqhkiG9w0CBTAKBggqhkiG9w0CBTCB8gYJKwYBBAGCNxAEMYHkMIHhMIHM
MRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29y
azFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIEJ5IFJl
Zi4sTElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xhc3MgMSBDQSBJbmRpdmlkdWFs
IFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkAhB/l4yg+FrgmGLkay+Z3cRwMA0GCSqG
SIb3DQEBAQUABIGAK+63ueljF95ceYmwd2C6MmbnxgeO5HrOokyLPlx6fvQUWxFPT0615aT5eIwZ
m1AnekTbtH2vgKcZaCWDKCQN81DN2+5GNkeEz7u2y2i0+CYCxvR7/lq91Z0jwwNz8VzPOuruXCZz
UffS+h9tFiSz8LcOO8nN/etmUHu58zQ+k7IAAAAAAAA=

------=_NextPart_000_026B_01C2C866.0E078B30--



Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h0UDBG201071 for ietf-pkix-bks; Thu, 30 Jan 2003 05:11:16 -0800 (PST)
Received: from odin2.bull.net (odin2.bull.net [192.90.70.84]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h0UDBDo01067 for <[e-mail]>; Thu, 30 Jan 2003 05:11:14 -0800 (PST)
Received: from clbull.frcl.bull.fr (clbull.frcl.bull.fr [129.182.8.31]) by odin2.bull.net (8.9.3/8.9.3) with ESMTP id OAA28328; Thu, 30 Jan 2003 14:12:59 +0100
Received: from bull.net (frcls4013.frcl.bull.fr [129.182.108.120]) by clbull.frcl.bull.fr (8.9.2/8.9.1) with ESMTP id OAA21454; Thu, 30 Jan 2003 14:11:17 +0100
Message-ID: <[e-mail]>
Date: Thu, 30 Jan 2003 14:11:04 +0100
From: Denis Pinkas <[e-mail]>
Organization: Bull SA.
User-Agent: Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.0.1) Gecko/20020823 Netscape/7.0
X-Accept-Language: en-us, en, fr
MIME-Version: 1.0
To: Peter Gutmann <[e-mail]>
CC: [e-mail], [e-mail]
Subject: Re: Real-time Certificate Status Facility for OCSP - (RTCS)
References: <[e-mail]>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Peter,

> Denis Pinkas <[e-mail]> writes:
> 
>>>Having a status of Good would seem enough for an RP to rely on; any other
>>>case means the RP can't rely on it (not present (which is presumably
>>>'unknown') or revoked).
>>
>>Since I am not Epimetheus, I will keep close the Pandora box and let Peter
>>answer that question.
> 
> Uhh, I'm not sure what there is to answer, since Marc has summed it up nicely.
> In authenticated-dictionary terms it's "Present/Not present".

This does not mean anything. RFC 3280 does not say what "present"
would mean. So if you ever get that status, you have no way to use it
with section 6 (Certificate Path Validation) from RFC 3280.

Denis

> In more
> specific cert-status terms it's "Good/Not good", in financial-institution
> terms it's "Accepted/Declined", etc etc.  The concept of "Unknown" (which is
> required in OCSP because it can't provide an unambiguous response) doesn't
> even feature here.
> 
> Peter.
> 




Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h0UD7kA00914 for ietf-pkix-bks; Thu, 30 Jan 2003 05:07:46 -0800 (PST)
Received: from odin2.bull.net (odin2.bull.net [192.90.70.84]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h0UD7ho00910 for <[e-mail]>; Thu, 30 Jan 2003 05:07:44 -0800 (PST)
Received: from clbull.frcl.bull.fr (clbull.frcl.bull.fr [129.182.8.31]) by odin2.bull.net (8.9.3/8.9.3) with ESMTP id OAA16308; Thu, 30 Jan 2003 14:09:24 +0100
Received: from bull.net (frcls4013.frcl.bull.fr [129.182.108.120]) by clbull.frcl.bull.fr (8.9.2/8.9.1) with ESMTP id OAA18760; Thu, 30 Jan 2003 14:07:35 +0100
Message-ID: <[e-mail]>
Date: Thu, 30 Jan 2003 14:07:21 +0100
From: Denis Pinkas <[e-mail]>
Organization: Bull SA.
User-Agent: Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.0.1) Gecko/20020823 Netscape/7.0
X-Accept-Language: en-us, en, fr
MIME-Version: 1.0
To: Peter Gutmann <[e-mail]>
CC: [e-mail], [e-mail], [e-mail]
Subject: Re: Real-time Certificate Status Facility for OCSP - (RTCS)
References: <[e-mail]>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Peter,

> Denis Pinkas <[e-mail]> writes:
> 
>>The point mentionned in the draft is the following: A conventional OCSP
>>responder answers the question "Is x excluded from D?", while an OCSP
>>responder with RTCS capability answers the question "Is x present in D?".
>>
>>"Present in D" does not say "revoked" or "not revoked".
> 
> 
> Right.  RTCS gives an unambiguous yes/no response, while OCSP gives a
> maybe/maybe not response (a cert can be invalid without being revoked, 

"invalid without being revoked" does not mean anything.

> and can be valid but OCSP can't tell you that because it can only say "not revoked",
> which doesn't mean "valid" - see the endless debate on this over the years).

There is no such an endless debate, except from your side.

>>In fact the data base is suppsoed to be cut into two pieces, one piece for
>>valid certificates and another piece for revoked certificate. 
> 
> 
> Huh?  Why on earth would you want to do that?  Or are you talking about the
> fact that this is what you have to do for OCSP?

So what means "present" ? Present as a "revoked or a non revoked 
certificate" ? If this is the case, then your are "inventing" a new model 
where you would not need to sign certificates anymore. This would mean that 
if the TBS (to be signed certificate structure") is present in the database, 
then the certificate is "valid". Is it what you mean ? This can certainly be 
the matter on a new WG, but this is not the matter of the PKIX WG.

>>>The extended reply returing a "replacement certificate" is though hard to see
>>>the point with.  Particularly as the likely scenario (which is?) is more
>>>generally addressed by Peter's (!) other draft, the HTTP CertStore.
>>
>>I concur.
> 
> 
> Users asked for it.  Since they're the real "consumers" of the RFC, I figured
> it'd be a good idea to have that in there (I know that it's a radical concept
> for PKIX to build something based on what users want, but I figured, what the
> heck :-).  I'm open to suggestions though, if there's a strong justification
> for doing one or the other it's no problem to change it.
> 
> 
>>The RTCS extended response in fact prevents the use of CRLs only in the
>>background since the certHash must be returned by the RTCS server. :-(
> 
> 
> Why would it prevent that?

Because the hash of a certificate is not included in the CRL, so using CRLs 
only would not be possible.

>   memcpy( response.certHash, request.certHash, 20 );
> 
> 
>>Furthermore, the basic response is incorrect since a BOOLEAN does not allow
>>to answer "unknown" status anymore.
> 
> 
> This is an artifact (bug, really) of OCSP.  

This is not a bug in OCSP. OCSP can be used as a front-end where in the back 
office either CRLs or other OCSP responders may be used. So in case, the 
front-end cannot locate the right CRL or the right OCSP responder, the 
answer has to be "unknown".

> I didn't think it was necessary to make it fully bug-compatible.  

This is not a bug in OCSP. You should read again the document.

Denis

 > This is sort of like complaining that Linux
> doesn't have a BSOD like Windows does, and that this makes it inferior.
> 
> 
>>The (only ?) "positive" idea of this contribution is to use a MAC to suppress
>>the signature of every response, but there is no concrete proposal for it.
> 
> 
> Oh, you seem to have missed section 2 of the draft.  You might want to re-read
> it to see which problems it addresses.
> 
> (Denis, did you actually read the draft, or did you just come up with a list
>  of assorted complaints and let fly?.  All of your complaints above, and more,
>  are addressed in the draft).
> 
> Peter.
> 




Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h0UBeR025895 for ietf-pkix-bks; Thu, 30 Jan 2003 03:40:27 -0800 (PST)
Received: from maile.telia.com (maile.telia.com [194.22.190.16]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h0UBano25813; Thu, 30 Jan 2003 03:36:50 -0800 (PST)
Received: from arport (h220n2fls31o1122.telia.com [212.181.142.220]) by maile.telia.com (8.12.5/8.12.5) with SMTP id h0UBakMc018754; Thu, 30 Jan 2003 12:36:46 +0100 (CET)
X-Original-Recipient: [e-mail]
Message-ID: <016801c2c853$837ccc30$0500a8c0@arport>
From: "Anders Rundgren" <[e-mail]>
To: "Peter Gutmann" <[e-mail]>, <[e-mail]>, <[e-mail]>
References: <[e-mail]>
Subject: Re: Encrypted mail in Limbo
Date: Thu, 30 Jan 2003 12:34:12 +0100
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.50.4133.2400
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Peter,
Actually I have some doubts about encrypted mail as a mass-
activity in general.  It far too complex to handle.  DOMSEC
would have been much better for the majority of messages.

Anyway, in order to aquire encryption keys in a reasonable
way from somebody you only have (an hopefully working)
e-mail address to, you should be able to search pre-defined
places using CertStore or go through DNS.

But I don't think that this will be a killer due to the privacy
issues, as well as to the fact that the user may have a TTP-
issued certificate.  Therefore I suggest a number of possible
additions:

1. a new URL-type: signed internet mail address (SIMA)
2. a new optional SMTP header: SIMA
3. a new SubjectAltName OtherName: SIMA

Then you have three ways of distributing (indirect) keys, 
automagically in ordinary mail, as explicit URL text in mails etc., 
and automagically through digitally signed messages.

Without any _MAJOR_ improvements in this area, I feel that
encryption certificate lookup will never become mainstream
exactly in the way as encrypted mail is not today.

Anders

----- Original Message ----- 
From: "Peter Gutmann" <[e-mail]>
To: <[e-mail]>; <[e-mail]>; <[e-mail]>; <[e-mail]>; <[e-mail]>
Sent: Thursday, January 30, 2003 11:28
Subject: Re: Encrypted mail in Limbo


"Anders Rundgren" <[e-mail]> writes:

>As you probably have noticed, "authenticated" URLs are very common in many
>places like for verifying e-mail addresses, often in connection to a certain
>registration event.
>
>In order to use other peoples' public keys for e-mail encryption, I claim
>that none of the proposed systems [1] work well except in very local (or very
>open) places due to privacy issues [2].
>
>The problem is how to distribute "semi-secret" information in a simple way.
>It seems like a signed mail-address MIME-type could be required for out-of-
>band distribution using a client "click" only.
>
>  566655fe76adr5fyyeed655:[e-mail]

Oh, I see what you mean now.  Hmm, I thought I had something in the text about
people using the HTTP-access thing as a static URL to identify a cert, but I
can't find any trace of it.  What I mean here is that a CA or helpdesk could
mail a user their cert URL (say certificates.blah.com/search.cgi?email=
luser%40blah.com) and all they have to do is click on it and they're done,
rather than hunt around some CA's web pages for it.  Since every browser and
most mail software can do an HTTP GET, this gets them their cert
automatically.  What you're proposing could easily go in the implementation
notes as another suggested way to do things, it's a nice variation on the
mailed-URL idea.  Or you could do your own RFC if you preferred that.  

I assume what you're proposing is that the user gets told to fetch:

  certificates.blah.com/search.cgi?x-certMAC=qwertyuiop

(using the 'x-' extension mechanism) by the CA, and the CA can map that to the
required cert, thus providing the privacy/authenticated-URL feature.  Or:

  certificates.blah.com/search.cgi?x-encryptedCertID=qwertyuiop

That's a cool idea, thanks for suggesting it.

Peter.



Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h0UBAcO25079 for ietf-pkix-bks; Thu, 30 Jan 2003 03:10:38 -0800 (PST)
Received: from hermes.cs.auckland.ac.nz (hermes.cs.auckland.ac.nz [130.216.35.151]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h0UBAao25074 for <[e-mail]>; Thu, 30 Jan 2003 03:10:37 -0800 (PST)
Received: from medusa01.cs.auckland.ac.nz (medusa01.cs.auckland.ac.nz [130.216.34.60]) by hermes.cs.auckland.ac.nz (8.12.4/8.12.4) with ESMTP id h0UB9GVJ006461; Fri, 31 Jan 2003 00:09:16 +1300
Received: (from pgut001@localhost) by medusa01.cs.auckland.ac.nz (8.11.6/8.11.6) id h0UBB4G06151; Fri, 31 Jan 2003 00:11:04 +1300
Date: Fri, 31 Jan 2003 00:11:04 +1300
Message-Id: <[e-mail]>
From: [e-mail] (Peter Gutmann)
To: [e-mail], [e-mail]
Subject: Re: Real-time Certificate Status Facility for OCSP - (RTCS)
Cc: [e-mail], [e-mail], [e-mail], [e-mail]
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Denis Pinkas <[e-mail]> writes:

>>Having a status of Good would seem enough for an RP to rely on; any other
>>case means the RP can't rely on it (not present (which is presumably
>>'unknown') or revoked).
>
>Since I am not Epimetheus, I will keep close the Pandora box and let Peter
>answer that question.

Uhh, I'm not sure what there is to answer, since Marc has summed it up nicely.
In authenticated-dictionary terms it's "Present/Not present".  In more
specific cert-status terms it's "Good/Not good", in financial-institution
terms it's "Accepted/Declined", etc etc.  The concept of "Unknown" (which is
required in OCSP because it can't provide an unambiguous response) doesn't
even feature here.

Peter.


Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h0UAmGm24036 for ietf-pkix-bks; Thu, 30 Jan 2003 02:48:16 -0800 (PST)
Received: from odin2.bull.net (odin2.bull.net [192.90.70.84]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h0UAmBo24031 for <[e-mail]>; Thu, 30 Jan 2003 02:48:11 -0800 (PST)
Received: from clbull.frcl.bull.fr (clbull.frcl.bull.fr [129.182.8.31]) by odin2.bull.net (8.9.3/8.9.3) with ESMTP id LAA15476; Thu, 30 Jan 2003 11:49:59 +0100
Received: from bull.net (frcls4013.frcl.bull.fr [129.182.108.120]) by clbull.frcl.bull.fr (8.9.2/8.9.1) with ESMTP id LAA23050; Thu, 30 Jan 2003 11:47:51 +0100
Message-ID: <[e-mail]>
Date: Thu, 30 Jan 2003 11:47:38 +0100
From: Denis Pinkas <[e-mail]>
Organization: Bull SA.
User-Agent: Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.0.1) Gecko/20020823 Netscape/7.0
X-Accept-Language: en-us, en, fr
MIME-Version: 1.0
To: Marc Poulaud <[e-mail]>
CC: Anders Rundgren <[e-mail]>, Peter Gutmann <[e-mail]>, Stephen Kent <[e-mail]>, [e-mail]
Subject: Re: Real-time Certificate Status Facility for OCSP - (RTCS)
References: <[e-mail]>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Marc,

> Denis,

> Ok, it might seem like a daft question, but I'm compelled to ask...

> How does being present help a RP (act differently)? Or what real world
> business problem does this solve? 

Since I am not Epimetheus, I will keep close the Pandora box and
let Peter answer that question.

Denis

> Having a status of Good would seem
> enough for an RP to rely on; any other case means the RP can't rely on it
> (not present (which is presumably 'unknown') or revoked).
> 
> Marc.
> -----Original Message-----
> From: [e-mail]
> [mailto:[e-mail]]On Behalf Of Denis Pinkas
> Sent: Wednesday, January 29, 2003 17:29
> To: Anders Rundgren
> Cc: Peter Gutmann; Stephen Kent; [e-mail]
> Subject: Re: Real-time Certificate Status Facility for OCSP - (RTCS)
> 
> 
> 
> Anders,
> 
> 
> 
>>Denis,
>>
>>For those who like me have not seen the document in question
>>here it is:
>>http://www.ietf.org/internet-drafts/draft-gutmann-ocsp-rtcs-00.txt
>>
>>It is hard to see any controversy in this very clean way of addressing
>>certificate status info.  The problem is rather YAP (Yet Another
> 
> Protocol).
> 
>><snip>
>>
>>>If it can be known that the certificate has really been issued, what
>>
> kind
> 
>>>of use will be done by a RP with that additional information ?
>>
>>
>>OK=>Valid => Rely on it.
> 
> 
> The point mentionned in the draft is the following:
> A conventional OCSP responder answers the question "Is x excluded
> from D?", while an OCSP responder with RTCS capability answers the
> question
> "Is x present in D?".
> 
> "Present in D" does not say "revoked" or "not revoked".
> 
> In fact the data base is suppsoed to be cut into two pieces, one piece for
> valid certificates and another piece for revoked certificate. This is
> implementation details. We are doing protocols able to answer questions
> like
> is the certificate revoked or not ?
> 
> 
>>The extended reply returing a "replacement
>>certificate" is though hard to see the point with.  Particularly as the
>>likely scenario (which is?) is more generally addressed by Peter's (!)
>>other draft, the HTTP CertStore.
> 
> 
> I concur.
> 
> 
>>>The topic has probably to do with the compromission of a CA key. RFC
>>
> 3280 is
> 
>>>pretty silent about the verification of a certification path in the past
>>>when a CA key has been compromised. But tackling the question could also
>>>result in a change in the current validation algorithm. Could we afford
>>
> two
> 
>>>different processing for certification path validation ? I do not think
>>
> so.
> 
>>
>>There is nothing of the kind mentioned in the draft.  RTCS is just a
>>simple status-function totally agnostic to any CA key compromises.
>>(unless there is something "between the lines" I didn't understand)
> 
> 
> Well in the intro: there is the argument "Is x present in D?" but I could
> not find the equivalent in the ASN.1 (that I did not fully decrypted
> before).
> 
> The RTCS extended response in fact prevents the use of CRLs only in the
> background since the certHash must be returned by the RTCS server. :-(
> 
> Furthermore, the basic response is incorrect since a BOOLEAN does not
> allow
> to answer "unknown" status anymore.
> 
> The (only ?) "positive" idea of this contribution is to use a MAC to
> suppress the signature of every response, but there is no concrete
> proposal
> for it.
> 
> Denis
> 
> 
> 
>>Are we reading the same document? :-)
> 
> 
>>Path-validation using RTCS would go to the same place as OCSP.
>>
>><snip>
>>
>>>In particular, would it still be possible to verify a certification path
>>>using CRLs only ?
>>
>>
>>>From RFC3280: The paragraph
>>
>>  "6.3  CRL Validation
>>
>>      This section describes the steps necessary to determine if a
>>      certificate is revoked or on hold status when CRLs are the
> 
> revocation
> 
>>      mechanism used by the certificate issuer"
>>
>>seems to indicate that there are no CRL requirements.
>>
>>
>>
>>>Would a consequence to have two different processings for
>>>certification path validation ?
>>
>>
>>Didn't OCSP bring us that already?
>>
>><snip>
>>
>>Anders
>>
>>
> 
> 




Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h0UARCc22045 for ietf-pkix-bks; Thu, 30 Jan 2003 02:27:12 -0800 (PST)
Received: from hermes.cs.auckland.ac.nz (hermes.cs.auckland.ac.nz [130.216.35.151]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h0UARAo22040; Thu, 30 Jan 2003 02:27:10 -0800 (PST)
Received: from medusa01.cs.auckland.ac.nz (medusa01.cs.auckland.ac.nz [130.216.34.60]) by hermes.cs.auckland.ac.nz (8.12.4/8.12.4) with ESMTP id h0UAR5VJ005886; Thu, 30 Jan 2003 23:27:05 +1300
Received: (from pgut001@localhost) by medusa01.cs.auckland.ac.nz (8.11.6/8.11.6) id h0UASqD14780; Thu, 30 Jan 2003 23:28:52 +1300
Date: Thu, 30 Jan 2003 23:28:52 +1300
Message-Id: <[e-mail]>
From: [e-mail] (Peter Gutmann)
To: [e-mail], [e-mail], [e-mail], [e-mail], [e-mail]
Subject: Re: Encrypted mail in Limbo
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

"Anders Rundgren" <[e-mail]> writes:

>As you probably have noticed, "authenticated" URLs are very common in many
>places like for verifying e-mail addresses, often in connection to a certain
>registration event.
>
>In order to use other peoples' public keys for e-mail encryption, I claim
>that none of the proposed systems [1] work well except in very local (or very
>open) places due to privacy issues [2].
>
>The problem is how to distribute "semi-secret" information in a simple way.
>It seems like a signed mail-address MIME-type could be required for out-of-
>band distribution using a client "click" only.
>
>  566655fe76adr5fyyeed655:[e-mail]

Oh, I see what you mean now.  Hmm, I thought I had something in the text about
people using the HTTP-access thing as a static URL to identify a cert, but I
can't find any trace of it.  What I mean here is that a CA or helpdesk could
mail a user their cert URL (say certificates.blah.com/search.cgi?email=
luser%40blah.com) and all they have to do is click on it and they're done,
rather than hunt around some CA's web pages for it.  Since every browser and
most mail software can do an HTTP GET, this gets them their cert
automatically.  What you're proposing could easily go in the implementation
notes as another suggested way to do things, it's a nice variation on the
mailed-URL idea.  Or you could do your own RFC if you preferred that.  

I assume what you're proposing is that the user gets told to fetch:

  certificates.blah.com/search.cgi?x-certMAC=qwertyuiop

(using the 'x-' extension mechanism) by the CA, and the CA can map that to the
required cert, thus providing the privacy/authenticated-URL feature.  Or:

  certificates.blah.com/search.cgi?x-encryptedCertID=qwertyuiop

That's a cool idea, thanks for suggesting it.

Peter.


Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h0U9efV15133 for ietf-pkix-bks; Thu, 30 Jan 2003 01:40:41 -0800 (PST)
Received: from hermes.cs.auckland.ac.nz (hermes.cs.auckland.ac.nz [130.216.35.151]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h0U9edo15122 for <[e-mail]>; Thu, 30 Jan 2003 01:40:39 -0800 (PST)
Received: from medusa01.cs.auckland.ac.nz (medusa01.cs.auckland.ac.nz [130.216.34.60]) by hermes.cs.auckland.ac.nz (8.12.4/8.12.4) with ESMTP id h0U9drVJ005285; Thu, 30 Jan 2003 22:39:53 +1300
Received: (from pgut001@localhost) by medusa01.cs.auckland.ac.nz (8.11.6/8.11.6) id h0U9feF21954; Thu, 30 Jan 2003 22:41:40 +1300
Date: Thu, 30 Jan 2003 22:41:40 +1300
Message-Id: <[e-mail]>
From: [e-mail] (Peter Gutmann)
To: [e-mail], [e-mail], [e-mail]
Subject: Re: Real-time Certificate Status Facility for OCSP - (RTCS)
Cc: [e-mail], [e-mail]
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

"Anders Rundgren" <[e-mail]> writes:

>Are we reading the same document? :-)

Given Denis' other reply, I don't think so :-).  I recently discovered that
there was another (long-expired) draft with the acronym RTCS whose contents
seem to be almost identical with OCSP.  Denis, if that's the one you were
commenting on, you may want to grab my one instead.

Peter.


Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h0U9aFO14162 for ietf-pkix-bks; Thu, 30 Jan 2003 01:36:15 -0800 (PST)
Received: from hermes.cs.auckland.ac.nz (hermes.cs.auckland.ac.nz [130.216.35.151]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h0U9aDo14154 for <[e-mail]>; Thu, 30 Jan 2003 01:36:13 -0800 (PST)
Received: from medusa01.cs.auckland.ac.nz (medusa01.cs.auckland.ac.nz [130.216.34.60]) by hermes.cs.auckland.ac.nz (8.12.4/8.12.4) with ESMTP id h0U9ZOVJ005234; Thu, 30 Jan 2003 22:35:24 +1300
Received: (from pgut001@localhost) by medusa01.cs.auckland.ac.nz (8.11.6/8.11.6) id h0U9bBB19379; Thu, 30 Jan 2003 22:37:11 +1300
Date: Thu, 30 Jan 2003 22:37:11 +1300
Message-Id: <[e-mail]>
From: [e-mail] (Peter Gutmann)
To: [e-mail], [e-mail]
Subject: Re: Real-time Certificate Status Facility for OCSP - (RTCS)
Cc: [e-mail]
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Denis Pinkas <[e-mail]> writes:

>Peter, are you Epimetheus or Prometheus ?

Ich bin ein engineer [0].

RTCS just works, no hassles, no dependence on synchronised clocks, CRLs, DN
structure, and half a dozen other things that cause no end of trouble with
OCSP.  I want to implement a protocol and move on, not have a guaranteed
lifetime career of trying to get it working (like some other stuff I could
name :-).  For example (as I mentioned in an earlier message) I wrote the
cert/database interface about 5 years ago and it's worked with zero problems
since then, the problem's solved and I can move on.  RTCS provides the same
capability when the problem is "This cert is three months old, is it still OK
now?".

Peter.

[0] "Engineers are people who are experts in technology. They design machines,
     computer programs, buildings, chemical processes, etc. They use science
     to make new, better things".


Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h0U9K0G12891 for ietf-pkix-bks; Thu, 30 Jan 2003 01:20:00 -0800 (PST)
Received: from maile.telia.com (maile.telia.com [194.22.190.16]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h0U9Jwo12886; Thu, 30 Jan 2003 01:19:58 -0800 (PST)
Received: from arport (h220n2fls31o1122.telia.com [212.181.142.220]) by maile.telia.com (8.12.5/8.12.5) with SMTP id h0U9Jt7n002980; Thu, 30 Jan 2003 10:19:55 +0100 (CET)
X-Original-Recipient: [e-mail]
Message-ID: <00f401c2c840$6539e3b0$0500a8c0@arport>
From: "Anders Rundgren" <[e-mail]>
To: <[e-mail]>, <[e-mail]>, "Peter Gutmann" <[e-mail]>, "Hallam-Baker, Phillip" <[e-mail]>
References: <[e-mail]>
Subject: Encrypted mail in Limbo
Date: Thu, 30 Jan 2003 10:17:21 +0100
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.50.4133.2400
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

As you probably have noticed, "authenticated" URLs are very
common in many places like for verifying e-mail addresses, often
in connection to a certain registration event.

In order to use other peoples' public keys for e-mail encryption,
I claim that none of the proposed systems [1] work well except in very
local (or very open) places due to privacy issues [2].

The problem is how to distribute "semi-secret" information in a
simple way.    It seems like a signed mail-address MIME-type could
be required for out-of-band distribution using a client "click" only.

  566655fe76adr5fyyeed655:[e-mail]

Anders R

1] LDAP, XKMS, HTTP CertStore

2] X.500 directories is a bad idea from a privacy point of view.
That is, you typically have a limited set of trusted parties that
you may need to send encrypted messages to.   These partnerships 
have been established in ad-hoc out-of-band ways.  However, to
distribute passwords, client certificates for partners to use for
accessing your public key would be awfully complicated. 
"Authenticated" (hmac-signed lookup data) represent a reasonable
compromise between security and privacy.  Semi-secret data...

Or do you think that corporatations will publish keys for anybody
to access?  I'm doubt they will, except for a few contact "persons"
like [e-mail] :-)



Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h0U9JSG12876 for ietf-pkix-bks; Thu, 30 Jan 2003 01:19:28 -0800 (PST)
Received: from hermes.cs.auckland.ac.nz (hermes.cs.auckland.ac.nz [130.216.35.151]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h0U9JQo12871 for <[e-mail]>; Thu, 30 Jan 2003 01:19:26 -0800 (PST)
Received: from medusa01.cs.auckland.ac.nz (medusa01.cs.auckland.ac.nz [130.216.34.60]) by hermes.cs.auckland.ac.nz (8.12.4/8.12.4) with ESMTP id h0U9IZVJ005049; Thu, 30 Jan 2003 22:18:35 +1300
Received: (from pgut001@localhost) by medusa01.cs.auckland.ac.nz (8.11.6/8.11.6) id h0U9KMd09986; Thu, 30 Jan 2003 22:20:22 +1300
Date: Thu, 30 Jan 2003 22:20:22 +1300
Message-Id: <[e-mail]>
From: [e-mail] (Peter Gutmann)
To: [e-mail], [e-mail]
Subject: Re: Real-time Certificate Status Facility for OCSP - (RTCS)
Cc: [e-mail], [e-mail], [e-mail]
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Denis Pinkas <[e-mail]> writes:

>The point mentionned in the draft is the following: A conventional OCSP
>responder answers the question "Is x excluded from D?", while an OCSP
>responder with RTCS capability answers the question "Is x present in D?".
>
>"Present in D" does not say "revoked" or "not revoked".

Right.  RTCS gives an unambiguous yes/no response, while OCSP gives a
maybe/maybe not response (a cert can be invalid without being revoked, and can
be valid but OCSP can't tell you that because it can only say "not revoked",
which doesn't mean "valid" - see the endless debate on this over the years).

>In fact the data base is suppsoed to be cut into two pieces, one piece for
>valid certificates and another piece for revoked certificate. 

Huh?  Why on earth would you want to do that?  Or are you talking about the
fact that this is what you have to do for OCSP?

>>The extended reply returing a "replacement certificate" is though hard to see
>>the point with.  Particularly as the likely scenario (which is?) is more
>>generally addressed by Peter's (!) other draft, the HTTP CertStore.
>
>I concur.

Users asked for it.  Since they're the real "consumers" of the RFC, I figured
it'd be a good idea to have that in there (I know that it's a radical concept
for PKIX to build something based on what users want, but I figured, what the
heck :-).  I'm open to suggestions though, if there's a strong justification
for doing one or the other it's no problem to change it.

>The RTCS extended response in fact prevents the use of CRLs only in the
>background since the certHash must be returned by the RTCS server. :-(

Why would it prevent that?

  memcpy( response.certHash, request.certHash, 20 );

>Furthermore, the basic response is incorrect since a BOOLEAN does not allow
>to answer "unknown" status anymore.

This is an artifact (bug, really) of OCSP.  I didn't think it was necessary to
make it fully bug-compatible.  This is sort of like complaining that Linux
doesn't have a BSOD like Windows does, and that this makes it inferior.

>The (only ?) "positive" idea of this contribution is to use a MAC to suppress
>the signature of every response, but there is no concrete proposal for it.

Oh, you seem to have missed section 2 of the draft.  You might want to re-read
it to see which problems it addresses.

(Denis, did you actually read the draft, or did you just come up with a list
 of assorted complaints and let fly?.  All of your complaints above, and more,
 are addressed in the draft).

Peter.


Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h0U8xsH11138 for ietf-pkix-bks; Thu, 30 Jan 2003 00:59:54 -0800 (PST)
Received: from hermes.cs.auckland.ac.nz (hermes.cs.auckland.ac.nz [130.216.35.151]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h0U8xqo11133 for <[e-mail]>; Thu, 30 Jan 2003 00:59:52 -0800 (PST)
Received: from medusa01.cs.auckland.ac.nz (medusa01.cs.auckland.ac.nz [130.216.34.60]) by hermes.cs.auckland.ac.nz (8.12.4/8.12.4) with ESMTP id h0U8xYVJ004833; Thu, 30 Jan 2003 21:59:34 +1300
Received: (from pgut001@localhost) by medusa01.cs.auckland.ac.nz (8.11.6/8.11.6) id h0U91KD31730; Thu, 30 Jan 2003 22:01:20 +1300
Date: Thu, 30 Jan 2003 22:01:20 +1300
Message-Id: <[e-mail]>
From: [e-mail] (Peter Gutmann)
To: [e-mail], [e-mail], [e-mail]
Subject: Re: Real-time Certificate Status Facility for OCSP - (RTCS)
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

"Anders Rundgren" <[e-mail]> writes:

>Further I do not understand how RTCS can be in conflict with DPV/DPD. From
>your description it seems that RTCS does not indicate that a certificate is
>"trusted", only that it is OK to use and rely on from the CA's point of view.

That's my feeling as well.  It returns a yes/no response because that's the
only thing an authenticated dictionary can return.  As the draft points out,
it doesn't say anything about whether you should trust the cert, whether it
complies with any particular policy, or any of the other stuff that DPD/DPV
needs, the client is saying "I got one of these but it's dated three months
ago, is it still safe to use now", and the CA (or whatever) looks in its
database and says "Yep, it's still on my list of good little certs".  The RTCS
response doesn't make any statement about having to trust it or under what
conditions to trust it or whatever, it's a pure authenticated dictionary and
no more.

There was actually a longish discussion in private mail about this before the
RTCS draft was published, my thoughts were that even something like the HTTP
certstore stuff can be seen as a (clunky) way of doing what RTCS does (send in
a request, it replies "Present" with certs or "Not present").  By that measure
almost anything that allows you to fetch a cert in some way could be claimed
to be a conflict with DPV/DPD.

(There were different opinions on this during the private discussion).

Peter.


Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h0U8vh010974 for ietf-pkix-bks; Thu, 30 Jan 2003 00:57:43 -0800 (PST)
Received: from maile.telia.com (maile.telia.com [194.22.190.16]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h0U8vfo10970 for <[e-mail]>; Thu, 30 Jan 2003 00:57:41 -0800 (PST)
Received: from arport (h220n2fls31o1122.telia.com [212.181.142.220]) by maile.telia.com (8.12.5/8.12.5) with SMTP id h0U8vbZB001948; Thu, 30 Jan 2003 09:57:38 +0100 (CET)
X-Original-Recipient: [e-mail]
Message-ID: <00e301c2c83d$481e9800$0500a8c0@arport>
From: "Anders Rundgren" <[e-mail]>
To: "Peter Gutmann" <[e-mail]>, <[e-mail]>
References: <[e-mail]>
Subject: Re: More comments on the kitchenSink extension
Date: Thu, 30 Jan 2003 09:55:04 +0100
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.50.4133.2400
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

The whole idea with putting legal stuff into certificates is
ill-founded as computers only "Compute" which is miles away
from "Think", and "Understand".  Average human beings BTW
don't understand legal information at all.  Only lawyers do.

On my bookshelf I have a very nice Swedish pamphlet telling
that before you start with PKI, you must hire a couple of lawyers
to get it right.  If userid/passwords (the only __REAL__ security
standard)  had such requirement we would have to shut down the
Internet indefinitely due to the lack of legal resources...

Anders

----- Original Message ----- 
From: "Peter Gutmann" <[e-mail]>
To: <[e-mail]>; <[e-mail]>; <[e-mail]>
Sent: Thursday, January 30, 2003 08:57
Subject: Re: More comments on the kitchenSink extension


"Anders Rundgren" <[e-mail]> writes:

>Now to keep everybody "happy", you should let your legal department create
>some really nice PEs, but whatever you do, don't mess around with those in
>your PKI-apps, simply by-pass them.

Funny you should say that, the person who sent me one of the two new samples
also included a request for a workaround so they wouldn't be rejected any
more, since all they wanted was to interoperate and it didn't really matter
what the policy contained.

Maybe the extension should be called policyIcing instead, to reflect its true
role.

Peter.



Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h0U7u3i28514 for ietf-pkix-bks; Wed, 29 Jan 2003 23:56:03 -0800 (PST)
Received: from hermes.cs.auckland.ac.nz (hermes.cs.auckland.ac.nz [130.216.35.151]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h0U7u2o28504 for <[e-mail]>; Wed, 29 Jan 2003 23:56:02 -0800 (PST)
Received: from medusa01.cs.auckland.ac.nz (medusa01.cs.auckland.ac.nz [130.216.34.60]) by hermes.cs.auckland.ac.nz (8.12.4/8.12.4) with ESMTP id h0U7tuVJ003989; Thu, 30 Jan 2003 20:55:56 +1300
Received: (from pgut001@localhost) by medusa01.cs.auckland.ac.nz (8.11.6/8.11.6) id h0U7vgY28454; Thu, 30 Jan 2003 20:57:42 +1300
Date: Thu, 30 Jan 2003 20:57:42 +1300
Message-Id: <[e-mail]>
From: [e-mail] (Peter Gutmann)
To: [e-mail], [e-mail], [e-mail]
Subject: Re: More comments on the kitchenSink extension
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

"Anders Rundgren" <[e-mail]> writes:

>Now to keep everybody "happy", you should let your legal department create
>some really nice PEs, but whatever you do, don't mess around with those in
>your PKI-apps, simply by-pass them.

Funny you should say that, the person who sent me one of the two new samples
also included a request for a workaround so they wouldn't be rejected any
more, since all they wanted was to interoperate and it didn't really matter
what the policy contained.

Maybe the extension should be called policyIcing instead, to reflect its true
role.

Peter.


Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h0U7Zgx24831 for ietf-pkix-bks; Wed, 29 Jan 2003 23:35:42 -0800 (PST)
Received: from maile.telia.com (maile.telia.com [194.22.190.16]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h0U7Zeo24827 for <[e-mail]>; Wed, 29 Jan 2003 23:35:41 -0800 (PST)
Received: from arport (h220n2fls31o1122.telia.com [212.181.142.220]) by maile.telia.com (8.12.5/8.12.5) with SMTP id h0U7ZVRP006444; Thu, 30 Jan 2003 08:35:32 +0100 (CET)
X-Original-Recipient: [e-mail]
Message-ID: <006001c2c831$cff68eb0$0500a8c0@arport>
From: "Anders Rundgren" <[e-mail]>
To: <[e-mail]>, "Peter Gutmann" <[e-mail]>
References: <[e-mail]>
Subject: Re: More comments on the kitchenSink extension
Date: Thu, 30 Jan 2003 08:32:58 +0100
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.50.4133.2400
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

And here are the votes from the Swedish jury...

Now when we have eliminated directories :-)  we swiftly
jump over to another PKI "trauma", policy extensions, also
known as "KitchenSink" extensions (P. Guttman).

We assume that the intent with PEs was to separate and identify
different "types" of certificates.  But certificates can be different
from at least two perspectives:

- Different entity types (ID, Web-server, e-mail etc)
- Different quality/assurance levels

As there is no standard for classifying certificates, just a format
and an RFC crammed with "good advices", universal shrink-wrap
SW packages like e-mail clients etc. do nothing but ignore PEs.

To create some order in this mess, commercial CAs therefore
usually have one CA-root for each certificate "product".

Then you "configure" your RP SW by installing appropriate
root certificates, instead of "tweaking" your RP software
(be it custom or shrink-wrap) for each new PE variant.

Rules of thumb: 
1. Simplicity works, complexity kills.
2. Lawyers as system-designers is a moderately good idea....

Now to keep everybody "happy", you should let your legal
department create some really nice PEs, but whatever you do,
don't mess around with those in your PKI-apps, simply by-pass them.

Anders R





----- Original Message ----- 
From: "Peter Gutmann" <[e-mail]>
To: <[e-mail]>
Sent: Thursday, January 30, 2003 07:37
Subject: More comments on the kitchenSink extension



I've been sent some more kitchenSink examples.  One is a cert with a policy of
{1 0 0 1}.  The other is a cert request asking for the cert to be issued under
two different policies.  

Please feel free to send me further kitchenSink examples.

(I really need to update the style guide again, although I don't think I'll
 enumerate all the oddities, just call the extension kitchenSink and add a
 long warning that you'll find examples containing anything you can think of,
 and many you couldn't).

Peter.



Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h0U6Zld16275 for ietf-pkix-bks; Wed, 29 Jan 2003 22:35:47 -0800 (PST)
Received: from hermes.cs.auckland.ac.nz (hermes.cs.auckland.ac.nz [130.216.35.151]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h0U6Zjo16271 for <[e-mail]>; Wed, 29 Jan 2003 22:35:45 -0800 (PST)
Received: from medusa01.cs.auckland.ac.nz (medusa01.cs.auckland.ac.nz [130.216.34.60]) by hermes.cs.auckland.ac.nz (8.12.4/8.12.4) with ESMTP id h0U6ZiVJ003123 for <[e-mail]>; Thu, 30 Jan 2003 19:35:44 +1300
Received: (from pgut001@localhost) by medusa01.cs.auckland.ac.nz (8.11.6/8.11.6) id h0U6bTw15856 for [e-mail]; Thu, 30 Jan 2003 19:37:29 +1300
Date: Thu, 30 Jan 2003 19:37:29 +1300
Message-Id: <[e-mail]>
From: [e-mail] (Peter Gutmann)
To: [e-mail]
Subject: More comments on the kitchenSink extension
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

I've been sent some more kitchenSink examples.  One is a cert with a policy of
{1 0 0 1}.  The other is a cert request asking for the cert to be issued under
two different policies.  

Please feel free to send me further kitchenSink examples.

(I really need to update the style guide again, although I don't think I'll
 enumerate all the oddities, just call the extension kitchenSink and add a
 long warning that you'll find examples containing anything you can think of,
 and many you couldn't).

Peter.


Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h0U5QTa14604 for ietf-pkix-bks; Wed, 29 Jan 2003 21:26:29 -0800 (PST)
Received: from hermes.cs.auckland.ac.nz (hermes.cs.auckland.ac.nz [130.216.35.151]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h0U5QRo14600 for <[e-mail]>; Wed, 29 Jan 2003 21:26:27 -0800 (PST)
Received: from medusa01.cs.auckland.ac.nz (medusa01.cs.auckland.ac.nz [130.216.34.60]) by hermes.cs.auckland.ac.nz (8.12.4/8.12.4) with ESMTP id h0U5QQVJ002373; Thu, 30 Jan 2003 18:26:26 +1300
Received: (from pgut001@localhost) by medusa01.cs.auckland.ac.nz (8.11.6/8.11.6) id h0U5S9w09355; Thu, 30 Jan 2003 18:28:09 +1300
Date: Thu, 30 Jan 2003 18:28:09 +1300
Message-Id: <[e-mail]>
From: [e-mail] (Peter Gutmann)
To: [e-mail], [e-mail]
Subject: Re: Authenticated CERTSTORE URLs
Cc: [e-mail]
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

"Anders Rundgren" <[e-mail]> writes:

>Assume that you do not "publish" certficates for everybody to see, but still
>allow coded out-of-band received URLs to do lookups.

I think in that case you should use whatever standard HTTP mechanisms you need
for it (passwords/MD5/SSL with client certs/whatever).  This is meant to be a
simple {key,value} lookup, and no more.

>A limitation in CERTSTORE is the exclusion of status information that a
>client can digest in a reasonable (=locale independent) way. Like "no such
>user", "no such certificate", and "invalid authentication - expired?"  (for
>the suggestion above).

Again, see above.  All you're doing is saying "Gimme the value associated with
this key".

Peter.


Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h0U4msd13827 for ietf-pkix-bks; Wed, 29 Jan 2003 20:48:54 -0800 (PST)
Received: from hermes.cs.auckland.ac.nz (hermes.cs.auckland.ac.nz [130.216.35.151]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h0U4mqo13823 for <[e-mail]>; Wed, 29 Jan 2003 20:48:53 -0800 (PST)
Received: from medusa01.cs.auckland.ac.nz (medusa01.cs.auckland.ac.nz [130.216.34.60]) by hermes.cs.auckland.ac.nz (8.12.4/8.12.4) with ESMTP id h0U4moVJ001878; Thu, 30 Jan 2003 17:48:50 +1300
Received: (from pgut001@localhost) by medusa01.cs.auckland.ac.nz (8.11.6/8.11.6) id h0U4oXB20589; Thu, 30 Jan 2003 17:50:33 +1300
Date: Thu, 30 Jan 2003 17:50:33 +1300
Message-Id: <[e-mail]>
From: [e-mail] (Peter Gutmann)
To: [e-mail], [e-mail], [e-mail]
Subject: RE: Lookup from DNS was: X.500, LDAP Considered harmful
Cc: [e-mail]
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

"Hallam-Baker, Phillip" <[e-mail]> writes:

>>Well, if by "all the current versions of Microsoft Windows" you mean
>>"Windows XP" then I agree with you, however it still only gives you
>>what, 10%? 15%? coverage (I don't know what the user base for XP is,
>>but the machine I'm using at the moment, for example, is still
>>running NT4 (there are all sorts of weird old boxes here), so it's
>>going to be awhile before you can just assume handling of SRV).
>
>Are you saying there is a problem with the W2K stack? 

WinLibResolv (or whatever MS calls it) wasn't stable until XP.

>I was under the impression that SRV was what kept most of the W2K systems
>hanging together.

The goop that keeps 'em going is really WINS (NetBIOS) and AD, not SRV.

I've been trying to find out more about what it'd take to do SRV under
Windows, apparently the WinLibResolv stuff was needed for AD and was added in
bits and pieces under Win2K, but the (stable) API wasn't exposed until XP (you
can find it in various forms under 2K, but can't really rely on it). 

libresovl should be portable to Windows (there's also the cygwin version
obviously), but to get things to work properly you generally need to use the
Windows sockets extensions, and even with a fully ported libresolv you don't
get WINS and AD tied in, which may be how the environment you're working in
happens to do things.  You could use something like adns (which is LGPLd and
safe to use), but that's just a libresolv port, is only a stub resolver,
doesn't do Win95, and doesn't appear to do SRV (anyone have any more
experience with this one?  I was tempted to use that, but didn't want to spend
ages messing around with something that might or might not work out in the
end).

Even with a bolt-on resolver, you still get, well, a bolt-on resolver.  From a
recent thread on the secprog list:

  That's probably one reason why people still keep using only libc stuff -
  requiring external libraries is annoying, distributing huge <new-capability>
  libraries with your sources is annoying, and stripping them down to bare
  minimals is also annoying.

Disclaimer: I'm not a libresolv-under-Windows expert, this is just what I got
by asking around (which got warnings like "DNS is a mess, and it's difficult
to produce a foolproof resolver implementation. a braindead one is simple,
sort of like anyone can do a simple MTA, but then look at what sendmail has to
do...", which is why I'd prefer to use the OS built-in implementation since
I'll be at least bug-compatible with the system's normal behaviour), and from
playing with it some months ago when I was working on the certs-over-HTTP
draft.

Peter.


Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h0TLhlG03180 for ietf-pkix-bks; Wed, 29 Jan 2003 13:43:47 -0800 (PST)
Received: from mta03-svc.ntlworld.com (mta03-svc.ntlworld.com [62.253.162.43]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h0TLhjo03175 for <[e-mail]>; Wed, 29 Jan 2003 13:43:45 -0800 (PST)
Received: from f67j40j ([213.106.136.127]) by mta03-svc.ntlworld.com (InterMail vM.4.01.03.27 201-229-121-127-20010626) with SMTP id <20030129214333.LZWS4699.mta03-svc.ntlworld.com@f67j40j>; Wed, 29 Jan 2003 21:43:33 +0000
From: "Marc Poulaud" <[e-mail]>
To: "Denis Pinkas" <[e-mail]>, "Anders Rundgren" <[e-mail]>
Cc: "Peter Gutmann" <[e-mail]>, "Stephen Kent" <[e-mail]>, <[e-mail]>
Subject: RE: Real-time Certificate Status Facility for OCSP - (RTCS)
Date: Wed, 29 Jan 2003 21:43:20 -0000
MIME-Version: 1.0
Message-ID: <[e-mail]>
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0)
Content-Type: multipart/signed; boundary="----=_NextPart_000_0181_01C2C7DF.6B6571C0"; protocol="application/x-pkcs7-signature"; micalg=SHA1
In-Reply-To: <[e-mail]>
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

This is a multi-part message in MIME format.

------=_NextPart_000_0181_01C2C7DF.6B6571C0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit

Denis,

Ok, it might seem like a daft question, but I'm compelled to ask...

How does being present help a RP (act differently)? Or what real world
business problem does this solve? Having a status of Good would seem
enough for an RP to rely on; any other case means the RP can't rely on it
(not present (which is presumably 'unknown') or revoked).

Marc.
-----Original Message-----
From: [e-mail]
[mailto:[e-mail]]On Behalf Of Denis Pinkas
Sent: Wednesday, January 29, 2003 17:29
To: Anders Rundgren
Cc: Peter Gutmann; Stephen Kent; [e-mail]
Subject: Re: Real-time Certificate Status Facility for OCSP - (RTCS)



Anders,


> Denis,
>
> For those who like me have not seen the document in question
> here it is:
> http://www.ietf.org/internet-drafts/draft-gutmann-ocsp-rtcs-00.txt
>
> It is hard to see any controversy in this very clean way of addressing
> certificate status info.  The problem is rather YAP (Yet Another
Protocol).
>
> <snip>
>
>>If it can be known that the certificate has really been issued, what
kind
>>of use will be done by a RP with that additional information ?
>
>
> OK=>Valid => Rely on it.

The point mentionned in the draft is the following:
A conventional OCSP responder answers the question "Is x excluded
from D?", while an OCSP responder with RTCS capability answers the
question
"Is x present in D?".

"Present in D" does not say "revoked" or "not revoked".

In fact the data base is suppsoed to be cut into two pieces, one piece for
valid certificates and another piece for revoked certificate. This is
implementation details. We are doing protocols able to answer questions
like
is the certificate revoked or not ?

> The extended reply returing a "replacement
> certificate" is though hard to see the point with.  Particularly as the
> likely scenario (which is?) is more generally addressed by Peter's (!)
> other draft, the HTTP CertStore.

I concur.

>>The topic has probably to do with the compromission of a CA key. RFC
3280 is
>>pretty silent about the verification of a certification path in the past
>>when a CA key has been compromised. But tackling the question could also
>>result in a change in the current validation algorithm. Could we afford
two
>>different processing for certification path validation ? I do not think
so.
>
>
> There is nothing of the kind mentioned in the draft.  RTCS is just a
> simple status-function totally agnostic to any CA key compromises.
> (unless there is something "between the lines" I didn't understand)

Well in the intro: there is the argument "Is x present in D?" but I could
not find the equivalent in the ASN.1 (that I did not fully decrypted
before).

The RTCS extended response in fact prevents the use of CRLs only in the
background since the certHash must be returned by the RTCS server. :-(

Furthermore, the basic response is incorrect since a BOOLEAN does not
allow
to answer "unknown" status anymore.

The (only ?) "positive" idea of this contribution is to use a MAC to
suppress the signature of every response, but there is no concrete
proposal
for it.

Denis


> Are we reading the same document? :-)

> Path-validation using RTCS would go to the same place as OCSP.
>
> <snip>
>
>>In particular, would it still be possible to verify a certification path
>>using CRLs only ?
>
>
>>From RFC3280: The paragraph
>
>   "6.3  CRL Validation
>
>       This section describes the steps necessary to determine if a
>       certificate is revoked or on hold status when CRLs are the
revocation
>       mechanism used by the certificate issuer"
>
> seems to indicate that there are no CRL requirements.
>
>
>>Would a consequence to have two different processings for
>>certification path validation ?
>
>
> Didn't OCSP bring us that already?
>
> <snip>
>
> Anders
>
>


------=_NextPart_000_0181_01C2C7DF.6B6571C0
Content-Type: application/x-pkcs7-signature;
	name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment;
	filename="smime.p7s"

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIKITCCAj0w
ggGmAhEAzbp/VvDf5LxU/iKss3KqVTANBgkqhkiG9w0BAQIFADBfMQswCQYDVQQGEwJVUzEXMBUG
A1UEChMOVmVyaVNpZ24sIEluYy4xNzA1BgNVBAsTLkNsYXNzIDEgUHVibGljIFByaW1hcnkgQ2Vy
dGlmaWNhdGlvbiBBdXRob3JpdHkwHhcNOTYwMTI5MDAwMDAwWhcNMjgwODAxMjM1OTU5WjBfMQsw
CQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xNzA1BgNVBAsTLkNsYXNzIDEgUHVi
bGljIFByaW1hcnkgQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkwgZ8wDQYJKoZIhvcNAQEBBQADgY0A
MIGJAoGBAOUZv22jVmEtmUhx9mfeuY3rt56GgAqRDvo4Ja9GiILlc6igmyRdDR/MZW4MsNBWhBiH
mgabEKFz37RYOWtuwfYV1aioP6oSBo0xrH+wNNePNGeICc0UEeJORVZpH3gCgNrcR5EpuzbJY1zF
4Ncth3uhtzKwezC6Ki8xqu6jZ9rbAgMBAAEwDQYJKoZIhvcNAQECBQADgYEATD+4i8Zo3+5DMw5d
6abLB4RNejP/khv0Nq3YlSI2aBFsfELM85wuxAc/FLAPT/+Qknb54rxK6Y/NoIAK98Up8YIiXbix
3YEjo3slFUYweRb46gVLlH8dwhzI47f0EEA8E8NfH1PoSOSGtHuhNbB7Jbq4046rPzidADQAmPPR
cZQwggNiMIICy6ADAgECAhAL2gsXwT+JjqsJdHq0zi4zMA0GCSqGSIb3DQEBAgUAMF8xCzAJBgNV
BAYTAlVTMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjE3MDUGA1UECxMuQ2xhc3MgMSBQdWJsaWMg
UHJpbWFyeSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTAeFw05ODA1MTIwMDAwMDBaFw0wODA1MTIy
MzU5NTlaMIHMMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1
c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNv
cnAuIEJ5IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xhc3MgMSBDQSBJ
bmRpdmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkMIGfMA0GCSqGSIb3DQEB
AQUAA4GNADCBiQKBgQC7WkSKBBa7Vf0DeootlE8VeDa4DUqyb5xUv7zodyqdufBou5XZMUFweoFL
uUgTVi3HCOGEQqvAopKrRFyqQvCCDgLpL/vCO7u+yScKXbawNkIztW5UiE+HSr8Z2vkV6A+Hthzj
zMaajn9qJJLj/OBluqexfu/J2zdqyErICQbkmQIDAQABo4GwMIGtMA8GA1UdEwQIMAYBAf8CAQAw
RwYDVR0gBEAwPjA8BgtghkgBhvhFAQcBATAtMCsGCCsGAQUFBwIBFh93d3cudmVyaXNpZ24uY29t
L3JlcG9zaXRvcnkvUlBBMDEGA1UdHwQqMCgwJqAkoCKGIGh0dHA6Ly9jcmwudmVyaXNpZ24uY29t
L3BjYTEuY3JsMAsGA1UdDwQEAwIBBjARBglghkgBhvhCAQEEBAMCAQYwDQYJKoZIhvcNAQECBQAD
gYEAAn2eb0VLOKC43ulTZCG85Ewrjx7+kkCs2Ao5aqEyISwHm6tZ/tJiGn1VOLA3c9z0B2ZjYr3h
U3BSh+eo2FLpWy2q4d7PrDFU1IsZyNgjqO8EKzJ9LBgcyHyJqC538kTRZQpNdLXu0xuSc3QuiTs1
E3LnQDGa07LEq+dWvovj+xUwggR2MIID36ADAgECAhB/l4yg+FrgmGLkay+Z3cRwMA0GCSqGSIb3
DQEBBAUAMIHMMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1
c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNv
cnAuIEJ5IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xhc3MgMSBDQSBJ
bmRpdmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkMB4XDTAyMTAwNzAwMDAw
MFoXDTAzMTAwNzIzNTk1OVowggEaMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMW
VmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0
b3J5L1JQQSBJbmNvcnAuIGJ5IFJlZi4sTElBQi5MVEQoYyk5ODEeMBwGA1UECxMVUGVyc29uYSBO
b3QgVmFsaWRhdGVkMTQwMgYDVQQLEytEaWdpdGFsIElEIENsYXNzIDEgLSBNaWNyb3NvZnQgRnVs
bCBTZXJ2aWNlMRUwEwYDVQQDFAxNYXJjIFBvdWxhdWQxKTAnBgkqhkiG9w0BCQEWGm1hcmMucG91
bGF1ZEBpLXNvbHZlLmNvLnVrMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDfd3CCaom3tU0P
mdCz0ggSdD8UNJMSVDPou1CJjsLvYpwUySsSQgUdYdFjvQmheBDL2z0T3dX1mvce5WJrDg5fcWQG
aUmQbubJ0qxdK5uT4IkNJx9s1PPDfOEj4PdJExyyG0Cbsvwo8Wyq+xnRlCcMzwm4D/XNnXqkrEZw
MifX+wIDAQABo4IBBjCCAQIwCQYDVR0TBAIwADCBrAYDVR0gBIGkMIGhMIGeBgtghkgBhvhFAQcB
ATCBjjAoBggrBgEFBQcCARYcaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL0NQUzBiBggrBgEFBQcC
AjBWMBUWDlZlcmlTaWduLCBJbmMuMAMCAQEaPVZlcmlTaWduJ3MgQ1BTIGluY29ycC4gYnkgcmVm
ZXJlbmNlIGxpYWIuIGx0ZC4gKGMpOTcgVmVyaVNpZ24wEQYJYIZIAYb4QgEBBAQDAgeAMDMGA1Ud
HwQsMCowKKAmoCSGImh0dHA6Ly9jcmwudmVyaXNpZ24uY29tL2NsYXNzMS5jcmwwDQYJKoZIhvcN
AQEEBQADgYEAh/j3ynKibKwqRZA4Y3KsDwboqp78AIi04ATWtK0MSq+qL2FIu7HORZrN9eJVwqkm
3lr4tNU/ld7bCqnd9zHO4FRyg17pDVwZ4/7Z3UR+wW6WLj2FXn+QPRPWuyeIpOz+LxPhn4HaBIS6
qaO6+glnQl0IX6axcAhLebO/J/hNIQAxggNWMIIDUgIBATCB4TCBzDEXMBUGA1UEChMOVmVyaVNp
Z24sIEluYy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0IE5ldHdvcmsxRjBEBgNVBAsTPXd3dy52
ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEgSW5jb3JwLiBCeSBSZWYuLExJQUIuTFREKGMpOTgx
SDBGBgNVBAMTP1ZlcmlTaWduIENsYXNzIDEgQ0EgSW5kaXZpZHVhbCBTdWJzY3JpYmVyLVBlcnNv
bmEgTm90IFZhbGlkYXRlZAIQf5eMoPha4Jhi5Gsvmd3EcDAJBgUrDgMCGgUAoIIByjAYBgkqhkiG
9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0wMzAxMjkyMTQzMTFaMCMGCSqGSIb3
DQEJBDEWBBTISbw7GzQbBJfHGeAUybencKiUpDB2BgkqhkiG9w0BCQ8xaTBnMAoGCCqGSIb3DQMH
MA4GCCqGSIb3DQMCAgIAgDAHBgUrDgMCBzAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDAHBgUrDgMC
GjAHBgUrDgMCGjAKBggqhkiG9w0CBTAKBggqhkiG9w0CBTCB8gYJKwYBBAGCNxAEMYHkMIHhMIHM
MRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29y
azFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIEJ5IFJl
Zi4sTElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xhc3MgMSBDQSBJbmRpdmlkdWFs
IFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkAhB/l4yg+FrgmGLkay+Z3cRwMA0GCSqG
SIb3DQEBAQUABIGAmuZjc5TQn78rFtaVBDBKENJ97ZMdZhX55OU415/SaDCL0KJpgvkvBfgRtAOX
v7CIMAM/xemMNdwpCiJ2G9+9PowLhmfvY9/a7ncA5GMEHhDJBuV7qB53lWAy+RSDMdkgl0zKpfPZ
EkbwBLDstw/ebUNcX+U28NmZixXVkxUazu8AAAAAAAA=

------=_NextPart_000_0181_01C2C7DF.6B6571C0--



Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h0THT0Q22667 for ietf-pkix-bks; Wed, 29 Jan 2003 09:29:00 -0800 (PST)
Received: from odin2.bull.net (odin2.bull.net [192.90.70.84]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h0THSwo22662 for <[e-mail]>; Wed, 29 Jan 2003 09:28:58 -0800 (PST)
Received: from clbull.frcl.bull.fr (clbull.frcl.bull.fr [129.182.8.31]) by odin2.bull.net (8.9.3/8.9.3) with ESMTP id SAA19602; Wed, 29 Jan 2003 18:30:52 +0100
Received: from bull.net (frcls4013.frcl.bull.fr [129.182.108.120]) by clbull.frcl.bull.fr (8.9.2/8.9.1) with ESMTP id SAA17232; Wed, 29 Jan 2003 18:29:06 +0100
Message-ID: <[e-mail]>
Date: Wed, 29 Jan 2003 18:28:56 +0100
From: Denis Pinkas <[e-mail]>
Organization: Bull SA.
User-Agent: Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.0.1) Gecko/20020823 Netscape/7.0
X-Accept-Language: en-us, en, fr
MIME-Version: 1.0
To: Anders Rundgren <[e-mail]>
CC: Peter Gutmann <[e-mail]>, Stephen Kent <[e-mail]>, [e-mail]
Subject: Re: Real-time Certificate Status Facility for OCSP - (RTCS)
References: <[e-mail]> <p05111a02ba5216ebeffb@[128.89.89.100]> <[e-mail]> <00a801c2c7ae$e5c2a1d0$0500a8c0@arport>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Anders,


> Denis,
> 
> For those who like me have not seen the document in question
> here it is:
> http://www.ietf.org/internet-drafts/draft-gutmann-ocsp-rtcs-00.txt
> 
> It is hard to see any controversy in this very clean way of addressing
> certificate status info.  The problem is rather YAP (Yet Another Protocol).
> 
> <snip>
> 
>>If it can be known that the certificate has really been issued, what kind
>>of use will be done by a RP with that additional information ?
> 
> 
> OK=>Valid => Rely on it.   

The point mentionned in the draft is the following:
A conventional OCSP responder answers the question "Is x excluded
from D?", while an OCSP responder with RTCS capability answers the question
"Is x present in D?".

"Present in D" does not say "revoked" or "not revoked".

In fact the data base is suppsoed to be cut into two pieces, one piece for 
valid certificates and another piece for revoked certificate. This is 
implementation details. We are doing protocols able to answer questions like 
is the certificate revoked or not ?

> The extended reply returing a "replacement
> certificate" is though hard to see the point with.  Particularly as the
> likely scenario (which is?) is more generally addressed by Peter's (!)
> other draft, the HTTP CertStore.

I concur.

>>The topic has probably to do with the compromission of a CA key. RFC 3280 is 
>>pretty silent about the verification of a certification path in the past 
>>when a CA key has been compromised. But tackling the question could also 
>>result in a change in the current validation algorithm. Could we afford two 
>>different processing for certification path validation ? I do not think so.
> 
> 
> There is nothing of the kind mentioned in the draft.  RTCS is just a
> simple status-function totally agnostic to any CA key compromises.
> (unless there is something "between the lines" I didn't understand)

Well in the intro: there is the argument "Is x present in D?" but I could 
not find the equivalent in the ASN.1 (that I did not fully decrypted before).

The RTCS extended response in fact prevents the use of CRLs only in the 
background since the certHash must be returned by the RTCS server. :-(

Furthermore, the basic response is incorrect since a BOOLEAN does not allow 
to answer "unknown" status anymore.

The (only ?) "positive" idea of this contribution is to use a MAC to 
suppress the signature of every response, but there is no concrete proposal 
for it.

Denis


> Are we reading the same document? :-)

> Path-validation using RTCS would go to the same place as OCSP.
> 
> <snip>
> 
>>In particular, would it still be possible to verify a certification path 
>>using CRLs only ?
> 
> 
>>From RFC3280: The paragraph
> 
>   "6.3  CRL Validation
> 
>       This section describes the steps necessary to determine if a
>       certificate is revoked or on hold status when CRLs are the revocation
>       mechanism used by the certificate issuer"
> 
> seems to indicate that there are no CRL requirements.
> 
> 
>>Would a consequence to have two different processings for
>>certification path validation ?
> 
> 
> Didn't OCSP bring us that already?
> 
> <snip>
> 
> Anders
> 
> 




Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h0TGgk219378 for ietf-pkix-bks; Wed, 29 Jan 2003 08:42:46 -0800 (PST)
Received: from peacock.verisign.com (peacock.verisign.com [65.205.251.73]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h0TGgio19373 for <[e-mail]>; Wed, 29 Jan 2003 08:42:44 -0800 (PST)
Received: from vhqpostal-gw2.verisign.com (verisign.com [65.205.251.56]) by peacock.verisign.com (8.12.1/) with ESMTP id h0TGgAq4008399; Wed, 29 Jan 2003 08:42:10 -0800 (PST)
Received: by vhqpostal-gw2.verisign.com with Internet Mail Service (5.5.2653.19) id <DQTLNNKG>; Wed, 29 Jan 2003 08:42:45 -0800
Message-ID: <[e-mail]>
From: "Hallam-Baker, Phillip" <[e-mail]>
To: [e-mail], [e-mail], [e-mail]
Cc: [e-mail]
Subject: RE: Lookup from DNS was: X.500, LDAP Considered harmful
Date: Wed, 29 Jan 2003 08:42:44 -0800
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
MIME-Version: 1.0
Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_0019_01C2C78A.6FB607D0"
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

This is a multi-part message in MIME format.

------=_NextPart_000_0019_01C2C78A.6FB607D0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit


> Well, if by "all the current versions of Microsoft Windows" you mean
> "Windows XP" then I agree with you, however it still only gives you
> what, 10%? 15%? coverage (I don't know what the user base for XP is,
> but the machine I'm using at the moment, for example, is still 
> running NT4 (there are all sorts of weird old boxes here), so it's
> going to be awhile before you can just assume handling of SRV).

Are you saying there is a problem with the W2K stack? I was under the
impression that SRV was what kept most of the W2K systems hanging
together.


> >The DNS stack can be supported at the client layer in any case.
> >This is what all the early W95 browsers did.
> 
> That's the Win3.1 approach.  Everyone who's ever used TCP/IP under
> Win3.1 knows how well that worked.

Yes, yes, it is still not a show stopper. If you are running on a 
system that does not support SRV you can delegate to a Locate or
validate server that does the work for you.

You need that capability in any case if you hope to build cross
certification paths reliably through the bridge CA. [If you don't
believe me explain how to find a path through the Canadian bridge
through the FBCA to the HEBCA bridge efficiently using X.500 lookups
alone]


I don't think that the problems with Win3.1 TCP/IP were due to people
reimplementing the stack themselves.

		Phill

------=_NextPart_000_0019_01C2C78A.6FB607D0
Content-Type: application/x-pkcs7-signature;
	name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment;
	filename="smime.p7s"

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINbTCCAj0w
ggGmAhEAulrJTAU7ktantt9O0FOSDTANBgkqhkiG9w0BAQIFADBfMQswCQYDVQQGEwJVUzEXMBUG
A1UEChMOVmVyaVNpZ24sIEluYy4xNzA1BgNVBAsTLkNsYXNzIDIgUHVibGljIFByaW1hcnkgQ2Vy
dGlmaWNhdGlvbiBBdXRob3JpdHkwHhcNOTYwMTI5MDAwMDAwWhcNMDQwMTA3MjM1OTU5WjBfMQsw
CQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xNzA1BgNVBAsTLkNsYXNzIDIgUHVi
bGljIFByaW1hcnkgQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkwgZ8wDQYJKoZIhvcNAQEBBQADgY0A
MIGJAoGBALZai6MNaiODgGvPOYf0IRMzBkwlou1VEpfFp4C5+oPBIKD6LxUNfKFga355LPoGDzqu
9htvsdL/LyhSX4N9S8R6t/hmH4BU/LfCjllKFFdG0ZqTvkGRA7sVgJNc6+fMCGw/PrNK/P9LbCPV
UIImRBmOI8Nx6hkkRwSedb/IpgAfAgMBAAEwDQYJKoZIhvcNAQECBQADgYEAtgAfk1ekB6dAzmVA
P1Ve7e/6VEmlMNYhfGGH7oOTC7+0M/KYrJ8Gv06ozhSBTMsETljDz1/ufNeab8tBird/gbj/hGHG
J0NlHQzssQAK3Ruku8d4ICiyot02lS7hVE+/YLl3aBGZI+jqUuiqAE5nTruQtUWbRuuOFu/EM1sz
PdUwggNDMIICrKADAgECAhAffl/nA9Hgv5kg3GuJDUsEMA0GCSqGSIb3DQEBBAUAMF8xCzAJBgNV
BAYTAlVTMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjE3MDUGA1UECxMuQ2xhc3MgMiBQdWJsaWMg
UHJpbWFyeSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTAeFw05OTAyMjUwMDAwMDBaFw0wNDAxMDUy
MzU5NTlaMIGtMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1
c3QgTmV0d29yazFJMEcGA1UECxNAVXNlIGlzIHN1YmplY3QgdG8gdGVybXMgYXQgaHR0cHM6Ly93
d3cudmVyaXNpZ24uY29tL3JwYS1rciAoYyk5OTEmMCQGA1UEAxMdVmVyaVNpZ24gQ2xhc3MgMiBQ
ZXJzb25uZWwgQ0EwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBAKcEbA+icrdKBi741yksNJ2C
vEiRSses+en8uVl4sVXAU1ixz28WO8FJ1cv0bszhzMu1xy5OiKo06bbQW3w+FVc04Ri8/931r2dZ
IArlPeqIikDSmokTKam21dunfuHnNyST/ZR0TXrkMm1M6FwWl6/dktlmihRm5OpaA6g9X/sLAgMB
AAGjgbAwga0wMQYDVR0fBCowKDAmoCSgIoYgaHR0cDovL2NybC52ZXJpc2lnbi5jb20vcGNhMi5j
cmwwEQYJYIZIAYb4QgEBBAQDAgEGMEcGA1UdIARAMD4wPAYLYIZIAYb4RQEHAQEwLTArBggrBgEF
BQcCARYfaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYS1rcjAPBgNVHRMECDAGAQH/AgEBMAsG
A1UdDwQEAwIBBjANBgkqhkiG9w0BAQQFAAOBgQB59xXN6GhRWWv8qaa94B77vPQ/kN/n+u3kVPdh
PVSLBrqXMloeqyzur3Orx13TP4/0zstOSGCiqGC2ON6gpvePKegRrMw5dlA83TlsC/Fa/QhUdt0W
bPcxcLi/CPfJJgaO37svGbG2uLToPEjoJ7GXKSBXA5ybZ/p9QMQ4fxiqmjCCA8QwggMtoAMCAQIC
EQCEzvIOADm1dVXaGYePUu2JMA0GCSqGSIb3DQEBBAUAMIGtMRcwFQYDVQQKEw5WZXJpU2lnbiwg
SW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFJMEcGA1UECxNAVXNlIGlzIHN1
YmplY3QgdG8gdGVybXMgYXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYS1rciAoYyk5OTEm
MCQGA1UEAxMdVmVyaVNpZ24gQ2xhc3MgMiBQZXJzb25uZWwgQ0EwHhcNOTkwMjI1MDAwMDAwWhcN
MDQwMTA0MjM1OTU5WjCBrDEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlT
aWduIFRydXN0IE5ldHdvcmsxSTBHBgNVBAsTQFVzZSBpcyBzdWJqZWN0IHRvIHRlcm1zIGF0IGh0
dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9ycGEta3IgKGMpOTkxJTAjBgNVBAMTHFZlcmlTaWduIENs
YXNzIDIgRW1wbG95ZWUgQ0EwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBAMCK0YdhouowA1Vr
CDbwl/oaVDUkH+h9ncjDc9PYRvWRLdk47ZTXsCZzKt6XUE3/Ihy9cACYDFgqsaRyj6W59y18YOO1
3+l9TiEhYdX8O1TJpAmcuyL5orpwYU+GRqL9BWTsCj+mWHZXuxZzRHzwpQ2XwGym8WMIJbEEF5Wg
jf5/AgMBAAGjgeIwgd8wKQYDVR0RBCIwIKQeMBwxGjAYBgNVBAMTEVByaXZhdGVMYWJlbDEtMTE4
MDgGA1UdHwQxMC8wLaAroCmGJ2h0dHA6Ly9jcmwudmVyaXNpZ24uY29tL1ZTQ2xhc3MySW50LmNy
bDARBglghkgBhvhCAQEEBAMCAQYwRwYDVR0gBEAwPjA8BgtghkgBhvhFAQcBATAtMCsGCCsGAQUF
BwIBFh9odHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBhLWtyMA8GA1UdEwQIMAYBAf8CAQAwCwYD
VR0PBAQDAgEGMA0GCSqGSIb3DQEBBAUAA4GBABlGztRrcI5YXIhCNa0WfaUJLKhTkPH2PYbX8M5y
FD0ivPLDM+3U/AWa4GMgdaMb71UZDwZzIQJhrqaeUSt43FvIhIvV17bP1fg+l5ixRIujmI6gS/aY
MZOz8AzdUXbKl+RWRMb7lKFIfSJDzKDGXHlV9WeBG2iYNCREsZjBOiheMIIEGTCCA4KgAwIBAgIQ
da9pAn9XoMlLtvoUDq8LyTANBgkqhkiG9w0BAQQFADCBrDEXMBUGA1UEChMOVmVyaVNpZ24sIElu
Yy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0IE5ldHdvcmsxSTBHBgNVBAsTQFVzZSBpcyBzdWJq
ZWN0IHRvIHRlcm1zIGF0IGh0dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9ycGEta3IgKGMpOTkxJTAj
BgNVBAMTHFZlcmlTaWduIENsYXNzIDIgRW1wbG95ZWUgQ0EwHhcNMDIwMjI3MDAwMDAwWhcNMDMw
MjI3MjM1OTU5WjBtMREwDwYDVQQKEwhWRVJJU0lHTjELMAkGA1UECxMCSFExEzARBgNVBAMTClJl
Y2lwaWVudHMxNjA0BgNVBAMTLXBiYWtlciAoSGFsbGFtLUJha2VyIFBoaWxsaXAsIFZlcmlTaWdu
LCBJbmMuKTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAtcA/okLsFi9brjmDsXQ6+g+R95B1
81Lq1EXkdzhY7XHxQ2QDq0sS2U4j9N1Ic6nHIiMq5dticztWpKdn6CrDx3Ovd5k+PACq/jSQo7NL
tlMJi7fsUrP7pM4izKu4JjSak6wRJUA4x85TSC1PLfd1u8oq16iqNJRhpEJ8VJUMRyECAwEAAaOC
AXgwggF0MAkGA1UdEwQCMAAwWQYDVR0fBFIwUDBOoEygSoZIaHR0cDovL29uc2l0ZWNybC52ZXJp
c2lnbi5jb20vVmVyaVNpZ25JbmNFeGNoYW5nZUVtcGxveWVlcy9MYXRlc3RDUkwuY3JsMAsGA1Ud
DwQEAwIFoDAeBgNVHREEFzAVgRNwYmFrZXJAdmVyaXNpZ24uY29tMIGsBgNVHSAEgaQwgaEwgZ4G
C2CGSAGG+EUBBwEBMIGOMCgGCCsGAQUFBwIBFhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vQ1BT
MGIGCCsGAQUFBwICMFYwFRYOVmVyaVNpZ24sIEluYy4wAwIBARo9VmVyaVNpZ24ncyBDUFMgaW5j
b3JwLiBieSByZWZlcmVuY2UgbGlhYi4gbHRkLiAoYyk5NyBWZXJpU2lnbjARBglghkgBhvhCAQEE
BAMCB4AwHQYDVR0lBBYwFAYIKwYBBQUHAwQGCCsGAQUFBwMCMA0GCSqGSIb3DQEBBAUAA4GBACCK
+gbdTcJB2wmWF5q8hbnP6slvVFehmjSX1Se+4Ff6a3Uiw8aOQLyNwnYUSOtHe12rTwAtWOhEgXHK
D4XY3tF7cofo5hM8dk8xsj9vV3z3fYARDr4nR2bZblPJ3MGmAFAYKW4pgX4Y6NU4VhAG2Hiuj18/
H4Cc5g5oqJp5dArUMYIC+DCCAvQCAQEwgcEwgawxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8w
HQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUkwRwYDVQQLE0BVc2UgaXMgc3ViamVjdCB0
byB0ZXJtcyBhdCBodHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBhLWtyIChjKTk5MSUwIwYDVQQD
ExxWZXJpU2lnbiBDbGFzcyAyIEVtcGxveWVlIENBAhB1r2kCf1egyUu2+hQOrwvJMAkGBSsOAwIa
BQCgggGMMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTAzMDEyOTE2
MzQ1MVowIwYJKoZIhvcNAQkEMRYEFK5YOECMqRFwUxJNMA3uY6S/6IHwMFgGCSqGSIb3DQEJDzFL
MEkwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwICAgCAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMAcG
BSsOAwIaMAoGCCqGSIb3DQIFMIHSBgkrBgEEAYI3EAQxgcQwgcEwgawxFzAVBgNVBAoTDlZlcmlT
aWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUkwRwYDVQQLE0BVc2Ug
aXMgc3ViamVjdCB0byB0ZXJtcyBhdCBodHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBhLWtyIChj
KTk5MSUwIwYDVQQDExxWZXJpU2lnbiBDbGFzcyAyIEVtcGxveWVlIENBAhB1r2kCf1egyUu2+hQO
rwvJMA0GCSqGSIb3DQEBAQUABIGAe2S2tb3gKUHNV6MJ/Ge7IkStyzSBzPiSCOpW4J2d2/33jFg7
vWdhiq9gfcFK9eYAC8cace9cKBFpbjD48jgRm/seaRqW4b/8KKPmBZ+3jrTl22MyuevOqw4rvGUm
fiLaSPNWXq+uNWrG7G/+CjHQ924SIw3uc7AwHr9Kf6jqrQoAAAAAAAA=

------=_NextPart_000_0019_01C2C78A.6FB607D0--



Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h0TFwcH17812 for ietf-pkix-bks; Wed, 29 Jan 2003 07:58:38 -0800 (PST)
Received: from mailc.telia.com (mailc.telia.com [194.22.190.4]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h0TFwao17808 for <[e-mail]>; Wed, 29 Jan 2003 07:58:37 -0800 (PST)
Received: from arport (h220n2fls31o1122.telia.com [212.181.142.220]) by mailc.telia.com (8.12.5/8.12.5) with SMTP id h0TFwJWl026041; Wed, 29 Jan 2003 16:58:23 +0100 (CET)
X-Original-Recipient: [e-mail]
Message-ID: <00a801c2c7ae$e5c2a1d0$0500a8c0@arport>
From: "Anders Rundgren" <[e-mail]>
To: "Peter Gutmann" <[e-mail]>, "Denis Pinkas" <[e-mail]>
Cc: "Stephen Kent" <[e-mail]>, <[e-mail]>
References: <[e-mail]> <p05111a02ba5216ebeffb@[128.89.89.100]> <[e-mail]>
Subject: Re: Real-time Certificate Status Facility for OCSP - (RTCS)
Date: Wed, 29 Jan 2003 16:55:46 +0100
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.50.4133.2400
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Denis,

For those who like me have not seen the document in question
here it is:
http://www.ietf.org/internet-drafts/draft-gutmann-ocsp-rtcs-00.txt

It is hard to see any controversy in this very clean way of addressing
certificate status info.  The problem is rather YAP (Yet Another Protocol).

<snip>

>If it can be known that the certificate has really been issued, what kind
>of use will be done by a RP with that additional information ?

OK=>Valid => Rely on it.   The extended reply returing a "replacement
certificate" is though hard to see the point with.  Particularly as the
likely scenario (which is?) is more generally addressed by Peter's (!)
other draft, the HTTP CertStore.

>The topic has probably to do with the compromission of a CA key. RFC 3280 is 
>pretty silent about the verification of a certification path in the past 
>when a CA key has been compromised. But tackling the question could also 
>result in a change in the current validation algorithm. Could we afford two 
>different processing for certification path validation ? I do not think so.

There is nothing of the kind mentioned in the draft.  RTCS is just a
simple status-function totally agnostic to any CA key compromises.
(unless there is something "between the lines" I didn't understand)

Are we reading the same document? :-)

Path-validation using RTCS would go to the same place as OCSP.

<snip>

>In particular, would it still be possible to verify a certification path 
>using CRLs only ?

>From RFC3280: The paragraph

  "6.3  CRL Validation

      This section describes the steps necessary to determine if a
      certificate is revoked or on hold status when CRLs are the revocation
      mechanism used by the certificate issuer"

seems to indicate that there are no CRL requirements.

>Would a consequence to have two different processings for
>certification path validation ?

Didn't OCSP bring us that already?

<snip>

Anders



Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h0TFfrk17142 for ietf-pkix-bks; Wed, 29 Jan 2003 07:41:53 -0800 (PST)
Received: from SOTTMXS01.entrust.com (mail.entrust.com [216.191.251.35]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h0TFfqo17138 for <[e-mail]>; Wed, 29 Jan 2003 07:41:52 -0800 (PST)
Received: by sottmxs01.entrust.com with Internet Mail Service (5.5.2656.59) id <DW6LTD8T>; Wed, 29 Jan 2003 10:41:48 -0500
Message-ID: <[e-mail]>
From: Carlisle Adams <[e-mail]>
To: "'[e-mail]'" <[e-mail]>
Subject: STRAWPOLL:  ABSTAIN (with explanation)
Date: Wed, 29 Jan 2003 10:41:43 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2656.59)
Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C2C7AC.EC4FCBB0"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

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

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

Hi,

On a conceptual level, I like the framework that OCSP started with:  a
request/response protocol to ask an authority questions about the status of
a certificate.  "Status" might mean "has this certificate been revoked?"
(most implementations of OCSP today are built to answer precisely this
question).  However, "status" along with a policy can mean "is this
certificate OK with respect to this policy?" and "status" along with a trust
anchor can mean "is this certificate OK with respect to this trust anchor?"
(i.e., is there a valid path connecting the two?).  This is not overloading
the word "status".  This word already means different things in different
contexts; whether something is "OK" or "not OK" depends entirely upon
context.  The goal of the OCSP framework was to choose a default meaning to
solve an immediate need in a simple way (unadorned "status" is equivalent to
"revocation status") and to allow other meanings to be indicated through the
extension mechanism so that future needs can be met relatively easily.  I
think this framework is powerful and conceptually attractive.

DVCS is also a powerful framework.  However, the scope of interactions it is
intended to address is much broader than OCSP, looking more at validating
and certifying arbitrary data (including signatures, certificates,
contracts, etc.).  Thus, although path validation and path discovery are
technically subsets of the interactions that DVCS can handle, I wonder if
developers/users will find the overall breadth too rich or confusing for
their DPD/DPV needs.

My strawpoll vote therefore leans toward OCSP.  However, the last version of
SCVP I read in any detail was several drafts ago, and I must confess that I
have not yet found time to read the CVP draft at all, never mind all the
corresponding compliance matrices.  In good conscience, then, I feel that I
have to abstain on this vote.

Of course, given the requirements spec that PKIX has published, any of the
candidates can be engineered to fit the bill.  So, in this sense, it does
not matter in the least which one we pick (as long as it is only one!).  I
like the idea of a single framework, rather than one protocol for revocation
status and a completely different protocol for other kinds of status, but I
can live with whatever outcome the WG members and chairs choose by rough
consensus.

Carlisle.


------_=_NextPart_001_01C2C7AC.EC4FCBB0
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.2653.12">
<TITLE>STRAWPOLL:  ABSTAIN (with explanation)</TITLE>
</HEAD>
<BODY>

<P><FONT COLOR=3D"#0000FF" FACE=3D"Times New Roman">Hi,</FONT>
</P>

<P><FONT COLOR=3D"#0000FF" FACE=3D"Times New Roman">On a conceptual =
level, I like the framework that OCSP started with:&nbsp; a =
request/response protocol to ask an authority questions about the =
status of a certificate.&nbsp; &quot;Status&quot; might mean &quot;has =
this certificate been revoked?&quot; (most implementations of OCSP =
today are built to answer precisely this question).&nbsp; However, =
&quot;status&quot; along with a policy can mean &quot;is this =
certificate OK with respect to this policy?&quot; and =
&quot;status&quot; along with a trust anchor can mean &quot;is this =
certificate OK with respect to this trust anchor?&quot; (i.e., is there =
a valid path connecting the two?).&nbsp; This is not overloading the =
word &quot;status&quot;.&nbsp; This word already means different things =
in different contexts; whether something is &quot;OK&quot; or &quot;not =
OK&quot; depends entirely upon context.&nbsp; The goal of the OCSP =
framework was to choose a default meaning to solve an immediate need in =
a simple way (unadorned &quot;status&quot; is equivalent to =
&quot;revocation status&quot;) and to allow other meanings to be =
indicated through the extension mechanism so that future needs can be =
met relatively easily.&nbsp; I think this framework is powerful and =
conceptually attractive.</FONT></P>

<P><FONT COLOR=3D"#0000FF" FACE=3D"Times New Roman">DVCS is also a =
powerful framework.&nbsp; However, the scope of interactions it is =
intended to address is much broader than OCSP, looking more at =
validating and certifying arbitrary data (including signatures, =
certificates, contracts, etc.).&nbsp; Thus, although path validation =
and path discovery are technically subsets of the interactions that =
DVCS can handle, I wonder if developers/users will find the overall =
breadth too rich or confusing for their DPD/DPV needs.</FONT></P>

<P><FONT COLOR=3D"#0000FF" FACE=3D"Times New Roman">My strawpoll vote =
therefore leans toward OCSP.&nbsp; However, the last version of SCVP I =
read in any detail was several drafts ago, and I must confess that I =
have not yet found time to read the CVP draft at all, never mind all =
the corresponding compliance matrices.&nbsp; In good conscience, then, =
I feel that I have to abstain on this vote.</FONT></P>

<P><FONT COLOR=3D"#0000FF" FACE=3D"Times New Roman">Of course, given =
the requirements spec that PKIX has published, any of the candidates =
can be engineered to fit the bill.&nbsp; So, in this sense, it does not =
matter in the least which one we pick (as long as it is only =
one!).&nbsp; I like the idea of a single framework, rather than one =
protocol for revocation status and a completely different protocol for =
other kinds of status, but I can live with whatever outcome the WG =
members and chairs choose by rough consensus.</FONT></P>

<P><FONT COLOR=3D"#0000FF" FACE=3D"Times New Roman">Carlisle.</FONT>
</P>

</BODY>
</HTML>
------_=_NextPart_001_01C2C7AC.EC4FCBB0--


Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h0TA4Wp27757 for ietf-pkix-bks; Wed, 29 Jan 2003 02:04:32 -0800 (PST)
Received: from odin2.bull.net (odin2.bull.net [192.90.70.84]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h0TA4Uo27753 for <[e-mail]>; Wed, 29 Jan 2003 02:04:31 -0800 (PST)
Received: from clbull.frcl.bull.fr (clbull.frcl.bull.fr [129.182.8.31]) by odin2.bull.net (8.9.3/8.9.3) with ESMTP id LAA30494; Wed, 29 Jan 2003 11:06:23 +0100
Received: from bull.net (frcls4013.frcl.bull.fr [129.182.108.120]) by clbull.frcl.bull.fr (8.9.2/8.9.1) with ESMTP id LAA15916; Wed, 29 Jan 2003 11:04:36 +0100
Message-ID: <[e-mail]>
Date: Wed, 29 Jan 2003 11:04:25 +0100
From: Denis Pinkas <[e-mail]>
Organization: Bull SA.
User-Agent: Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.0.1) Gecko/20020823 Netscape/7.0
X-Accept-Language: en-us, en, fr
MIME-Version: 1.0
To: Stephen Kent <[e-mail]>
CC: [e-mail]
Subject: Re: Real-time Certificate Status Facility for OCSP - (RTCS)
References: <[e-mail]> <p05111a02ba5216ebeffb@[128.89.89.100]>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Steve,

> Peter describes the function provided by the RTCS extensions to OCSP as 
> an "authenticated dictionary" service for certs. Peter and I discussed 
> his I-D prior to posting and the concern I expressed then is that X.500 
> (and PKIX) have no notion of such a service, per se. Of course 
> authenticated directory access is a good thing, but the presence of 
> absence of a cert in a directory is NOT an indication of its status, 
> either valid or revoked, in the X.500 model.

I fully share this view.

> The concern I raised in my e-mail exchanges with Peter is that by 
> extending the OCSP semantics from that of a revocation status protocol 
> (by allowing responses that go beyond revocation status to indicate the 
> presence of a cert in a database), RTCS into the realm of a delegated 
> cert validation protocol. RTCS tells the requester whether a cert exists 
> in a database maintained by a CA or a designee, where the database 
> contains only valid certs. This is not a revocation  status function; it 
> is a more general cert status function.

> It is fair to say that RTCS does not provide all of the facilities of a 
> DPV server as PKIX has defined. However, RTCS does provide validation of 
> individual certs (by virtue of indicating whether the cert in question 
> is valid or not) and that is a subset of the DPV service.  

No, it is not a subset of a DPV service. It could be considered as an 
addition to the OCSP service by providing additional information.
But here is the important question:

If it can be known that the certificate has really been issued, what kind
of use will be done by a RP with that additional information ?

The topic has probably to do with the compromission of a CA key. RFC 3280 is 
pretty silent about the verification of a certification path in the past 
when a CA key has been compromised. But tackling the question could also 
result in a change in the current validation algorithm. Could we afford two 
different processing for certification path validation ? I do not think so.

> A series of 
> requests to servers implementing RTCS mimics a subset of what a a DPV 
> server would provide, offering a new function not presently available 
> from any other X.500 or PKIX protocol.
> 
> Thus my concern was that RTCS competes with our DPV work and should be 
> considered relative to that ongoing activity.  It is up to the WG to 
> decide whether PKIX should consider RTCS as a separate work item 
> unrelated to our DPV work, consider it a competitor to that work, or 
> ignore it. In the first case we can add it to our list of work items, 
> essentially deciding that it is not in conflict with the DPV work. In 
> the second case we would probably reject it as it does not implement 
> many of the DPV requirements. In this case we would also be saying that 
> it should not proceed as an independent RFC, as it conflicts with the 
> DPV work item and we have vowed to not produce duplicate standards for 
> this function. In the third case we could allow it to proceed as an 
> independent work outside of PKIX, and it could become an RFC.
> 
> I'd like to initiate discussion on this issue of the right 
> categorization of this document, prior to any discussion of how well the 
> proposed mechanism performs the indicated function

Besides the categorization (it would be an additional function to OCSP),
it is more important to understand both the motivations for getting that
additional information and the consequences (which may be both advantages
and disadvantages) in the algorithm for the validation of a certification 
path, before going any further.

In particular, would it still be possible to verify a certification path 
using CRLs only ?

Would a consequence to have two different processings for certification path 
validation ?

We may well have a Pandora box in front of us.
Epimetheus did opened the box.

Peter, are you Epimetheus or Prometheus ?

Denis

> Steve




Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h0T95XU18543 for ietf-pkix-bks; Wed, 29 Jan 2003 01:05:33 -0800 (PST)
Received: from mailc.telia.com (mailc.telia.com [194.22.190.4]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h0T95Wo18537 for <[e-mail]>; Wed, 29 Jan 2003 01:05:32 -0800 (PST)
Received: from arport (h220n2fls31o1122.telia.com [212.181.142.220]) by mailc.telia.com (8.12.5/8.12.5) with SMTP id h0T95FF0015856; Wed, 29 Jan 2003 10:05:15 +0100 (CET)
X-Original-Recipient: [e-mail]
Message-ID: <003301c2c775$2ecdb750$0500a8c0@arport>
From: "Anders Rundgren" <[e-mail]>
To: <[e-mail]>, "Stephen Kent" <[e-mail]>
References: <[e-mail]> <p05111a02ba5216ebeffb@[128.89.89.100]>
Subject: Re: Real-time Certificate Status Facility for OCSP - (RTCS)
Date: Wed, 29 Jan 2003 10:02:42 +0100
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.50.4133.2400
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Steve,
I have not seen the posting of such a protocol.
Could you provide me with a link?

Please pardon me if the following is wacko due to lack of information!

The mechanism described, initially sounded like a very useful and
simple extension to OCSP,  making full justification to the term
"on-line". 

But while thinking a bit more, I don't see why you actually need new
semantics for describing the situation where a certificate is not in the
CA' s database.  Isn't this just one of the ways you can implement a CA?
There can hardly be a requirement that "useless" (revoked, expired, or
on_holded), certificates should be published.  Not even in X.500.

Further I do not understand how RTCS can be in conflict with DPV/DPD.
>From your description it seems that RTCS does not indicate that a
certificate is "trusted", only that it is OK to use and rely on from the CA's
point of view.

DPV/DPD's primary competitors is IMHO rather status quo, custom code,
and XKMS.  All three are up and running :-)

Anders



Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h0T2CRU18374 for ietf-pkix-bks; Tue, 28 Jan 2003 18:12:27 -0800 (PST)
Received: from hermes.cs.auckland.ac.nz (hermes.cs.auckland.ac.nz [130.216.35.151]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h0T2CPo18370 for <[e-mail]>; Tue, 28 Jan 2003 18:12:25 -0800 (PST)
Received: from medusa01.cs.auckland.ac.nz (medusa01.cs.auckland.ac.nz [130.216.34.60]) by hermes.cs.auckland.ac.nz (8.12.4/8.12.4) with ESMTP id h0T2CNVJ009611; Wed, 29 Jan 2003 15:12:23 +1300
Received: (from pgut001@localhost) by medusa01.cs.auckland.ac.nz (8.11.6/8.11.6) id h0T2DoB29408; Wed, 29 Jan 2003 15:13:50 +1300
Date: Wed, 29 Jan 2003 15:13:50 +1300
Message-Id: <[e-mail]>
From: [e-mail] (Peter Gutmann)
To: [e-mail], [e-mail], [e-mail]
Subject: RE: Lookup from DNS was: X.500, LDAP Considered harmful
Cc: [e-mail]
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

"Hallam-Baker, Phillip" <[e-mail]> writes:

>SRV is supported by all the current versions of Microsoft
>Windows so we don't need to talk about 99% being unable
>to use it.

Well, if by "all the current versions of Microsoft Windows" you mean
"Windows XP" then I agree with you, however it still only gives you
what, 10%? 15%? coverage (I don't know what the user base for XP is,
but the machine I'm using at the moment, for example, is still 
running NT4 (there are all sorts of weird old boxes here), so it's
going to be awhile before you can just assume handling of SRV).

>The DNS stack can be supported at the client layer in any case.
>This is what all the early W95 browsers did.

That's the Win3.1 approach.  Everyone who's ever used TCP/IP under
Win3.1 knows how well that worked.

Peter.


Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h0T1ktg17772 for ietf-pkix-bks; Tue, 28 Jan 2003 17:46:55 -0800 (PST)
Received: from peacock.verisign.com (peacock.verisign.com [65.205.251.73]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h0T1kno17767 for <[e-mail]>; Tue, 28 Jan 2003 17:46:49 -0800 (PST)
Received: from vhqpostal-gw2.verisign.com (verisign.com [65.205.251.56]) by peacock.verisign.com (8.12.1/) with ESMTP id h0T1jtq4016300; Tue, 28 Jan 2003 17:45:55 -0800 (PST)
Received: by vhqpostal-gw2.verisign.com with Internet Mail Service (5.5.2653.19) id <DQTLLKXH>; Tue, 28 Jan 2003 17:46:30 -0800
Message-ID: <[e-mail]>
From: "Hallam-Baker, Phillip" <[e-mail]>
To: Stephen Kent <[e-mail]>, [e-mail]
Subject: RE: Real-time Certificate Status Facility for OCSP - (RTCS)
Date: Tue, 28 Jan 2003 17:46:22 -0800
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
MIME-Version: 1.0
Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_0014_01C2C70E.361CC580"
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

This is a multi-part message in MIME format.

------=_NextPart_000_0014_01C2C70E.361CC580
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit


> I'd like to initiate discussion on this issue of the right 
> categorization of this document, prior to any discussion of how well 
> the proposed mechanism performs the indicated function

I think the points you make are well founded and indicate that
there is in fact a close relationship between OCSP and the 
directory / delegated discovery / delegated validation requirements.

What we really need is one PKIX platform that addresses these 
requirements as a whole and in a consistent fashion. 

Hence if this is a feature that the group thinks important to support
it really should be built on top of another protocol the group
has developed.


I am completely unconvinced that X.500 is an alternative for the reasons
set out at length in the 'considered harmful' thread. The problem
is that once we allowed cross certification, the topology of the trust
network ceased to be a match for the X.500/LDAP data model. X.500
is now in the category of 'attempted wheels proven by long experience 
to be in need of serious reinvention'.


I would prefer that the group complete work on the existing items and
close rather than stay arround as a permanent standing committee on
all things PKI in ASN.1 syntax. Otherwise there will be far more folk
comming with decorations.


		Phill

------=_NextPart_000_0014_01C2C70E.361CC580
Content-Type: application/x-pkcs7-signature;
	name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment;
	filename="smime.p7s"

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINbTCCAj0w
ggGmAhEAulrJTAU7ktantt9O0FOSDTANBgkqhkiG9w0BAQIFADBfMQswCQYDVQQGEwJVUzEXMBUG
A1UEChMOVmVyaVNpZ24sIEluYy4xNzA1BgNVBAsTLkNsYXNzIDIgUHVibGljIFByaW1hcnkgQ2Vy
dGlmaWNhdGlvbiBBdXRob3JpdHkwHhcNOTYwMTI5MDAwMDAwWhcNMDQwMTA3MjM1OTU5WjBfMQsw
CQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xNzA1BgNVBAsTLkNsYXNzIDIgUHVi
bGljIFByaW1hcnkgQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkwgZ8wDQYJKoZIhvcNAQEBBQADgY0A
MIGJAoGBALZai6MNaiODgGvPOYf0IRMzBkwlou1VEpfFp4C5+oPBIKD6LxUNfKFga355LPoGDzqu
9htvsdL/LyhSX4N9S8R6t/hmH4BU/LfCjllKFFdG0ZqTvkGRA7sVgJNc6+fMCGw/PrNK/P9LbCPV
UIImRBmOI8Nx6hkkRwSedb/IpgAfAgMBAAEwDQYJKoZIhvcNAQECBQADgYEAtgAfk1ekB6dAzmVA
P1Ve7e/6VEmlMNYhfGGH7oOTC7+0M/KYrJ8Gv06ozhSBTMsETljDz1/ufNeab8tBird/gbj/hGHG
J0NlHQzssQAK3Ruku8d4ICiyot02lS7hVE+/YLl3aBGZI+jqUuiqAE5nTruQtUWbRuuOFu/EM1sz
PdUwggNDMIICrKADAgECAhAffl/nA9Hgv5kg3GuJDUsEMA0GCSqGSIb3DQEBBAUAMF8xCzAJBgNV
BAYTAlVTMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjE3MDUGA1UECxMuQ2xhc3MgMiBQdWJsaWMg
UHJpbWFyeSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTAeFw05OTAyMjUwMDAwMDBaFw0wNDAxMDUy
MzU5NTlaMIGtMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1
c3QgTmV0d29yazFJMEcGA1UECxNAVXNlIGlzIHN1YmplY3QgdG8gdGVybXMgYXQgaHR0cHM6Ly93
d3cudmVyaXNpZ24uY29tL3JwYS1rciAoYyk5OTEmMCQGA1UEAxMdVmVyaVNpZ24gQ2xhc3MgMiBQ
ZXJzb25uZWwgQ0EwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBAKcEbA+icrdKBi741yksNJ2C
vEiRSses+en8uVl4sVXAU1ixz28WO8FJ1cv0bszhzMu1xy5OiKo06bbQW3w+FVc04Ri8/931r2dZ
IArlPeqIikDSmokTKam21dunfuHnNyST/ZR0TXrkMm1M6FwWl6/dktlmihRm5OpaA6g9X/sLAgMB
AAGjgbAwga0wMQYDVR0fBCowKDAmoCSgIoYgaHR0cDovL2NybC52ZXJpc2lnbi5jb20vcGNhMi5j
cmwwEQYJYIZIAYb4QgEBBAQDAgEGMEcGA1UdIARAMD4wPAYLYIZIAYb4RQEHAQEwLTArBggrBgEF
BQcCARYfaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYS1rcjAPBgNVHRMECDAGAQH/AgEBMAsG
A1UdDwQEAwIBBjANBgkqhkiG9w0BAQQFAAOBgQB59xXN6GhRWWv8qaa94B77vPQ/kN/n+u3kVPdh
PVSLBrqXMloeqyzur3Orx13TP4/0zstOSGCiqGC2ON6gpvePKegRrMw5dlA83TlsC/Fa/QhUdt0W
bPcxcLi/CPfJJgaO37svGbG2uLToPEjoJ7GXKSBXA5ybZ/p9QMQ4fxiqmjCCA8QwggMtoAMCAQIC
EQCEzvIOADm1dVXaGYePUu2JMA0GCSqGSIb3DQEBBAUAMIGtMRcwFQYDVQQKEw5WZXJpU2lnbiwg
SW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFJMEcGA1UECxNAVXNlIGlzIHN1
YmplY3QgdG8gdGVybXMgYXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYS1rciAoYyk5OTEm
MCQGA1UEAxMdVmVyaVNpZ24gQ2xhc3MgMiBQZXJzb25uZWwgQ0EwHhcNOTkwMjI1MDAwMDAwWhcN
MDQwMTA0MjM1OTU5WjCBrDEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlT
aWduIFRydXN0IE5ldHdvcmsxSTBHBgNVBAsTQFVzZSBpcyBzdWJqZWN0IHRvIHRlcm1zIGF0IGh0
dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9ycGEta3IgKGMpOTkxJTAjBgNVBAMTHFZlcmlTaWduIENs
YXNzIDIgRW1wbG95ZWUgQ0EwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBAMCK0YdhouowA1Vr
CDbwl/oaVDUkH+h9ncjDc9PYRvWRLdk47ZTXsCZzKt6XUE3/Ihy9cACYDFgqsaRyj6W59y18YOO1
3+l9TiEhYdX8O1TJpAmcuyL5orpwYU+GRqL9BWTsCj+mWHZXuxZzRHzwpQ2XwGym8WMIJbEEF5Wg
jf5/AgMBAAGjgeIwgd8wKQYDVR0RBCIwIKQeMBwxGjAYBgNVBAMTEVByaXZhdGVMYWJlbDEtMTE4
MDgGA1UdHwQxMC8wLaAroCmGJ2h0dHA6Ly9jcmwudmVyaXNpZ24uY29tL1ZTQ2xhc3MySW50LmNy
bDARBglghkgBhvhCAQEEBAMCAQYwRwYDVR0gBEAwPjA8BgtghkgBhvhFAQcBATAtMCsGCCsGAQUF
BwIBFh9odHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBhLWtyMA8GA1UdEwQIMAYBAf8CAQAwCwYD
VR0PBAQDAgEGMA0GCSqGSIb3DQEBBAUAA4GBABlGztRrcI5YXIhCNa0WfaUJLKhTkPH2PYbX8M5y
FD0ivPLDM+3U/AWa4GMgdaMb71UZDwZzIQJhrqaeUSt43FvIhIvV17bP1fg+l5ixRIujmI6gS/aY
MZOz8AzdUXbKl+RWRMb7lKFIfSJDzKDGXHlV9WeBG2iYNCREsZjBOiheMIIEGTCCA4KgAwIBAgIQ
da9pAn9XoMlLtvoUDq8LyTANBgkqhkiG9w0BAQQFADCBrDEXMBUGA1UEChMOVmVyaVNpZ24sIElu
Yy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0IE5ldHdvcmsxSTBHBgNVBAsTQFVzZSBpcyBzdWJq
ZWN0IHRvIHRlcm1zIGF0IGh0dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9ycGEta3IgKGMpOTkxJTAj
BgNVBAMTHFZlcmlTaWduIENsYXNzIDIgRW1wbG95ZWUgQ0EwHhcNMDIwMjI3MDAwMDAwWhcNMDMw
MjI3MjM1OTU5WjBtMREwDwYDVQQKEwhWRVJJU0lHTjELMAkGA1UECxMCSFExEzARBgNVBAMTClJl
Y2lwaWVudHMxNjA0BgNVBAMTLXBiYWtlciAoSGFsbGFtLUJha2VyIFBoaWxsaXAsIFZlcmlTaWdu
LCBJbmMuKTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAtcA/okLsFi9brjmDsXQ6+g+R95B1
81Lq1EXkdzhY7XHxQ2QDq0sS2U4j9N1Ic6nHIiMq5dticztWpKdn6CrDx3Ovd5k+PACq/jSQo7NL
tlMJi7fsUrP7pM4izKu4JjSak6wRJUA4x85TSC1PLfd1u8oq16iqNJRhpEJ8VJUMRyECAwEAAaOC
AXgwggF0MAkGA1UdEwQCMAAwWQYDVR0fBFIwUDBOoEygSoZIaHR0cDovL29uc2l0ZWNybC52ZXJp
c2lnbi5jb20vVmVyaVNpZ25JbmNFeGNoYW5nZUVtcGxveWVlcy9MYXRlc3RDUkwuY3JsMAsGA1Ud
DwQEAwIFoDAeBgNVHREEFzAVgRNwYmFrZXJAdmVyaXNpZ24uY29tMIGsBgNVHSAEgaQwgaEwgZ4G
C2CGSAGG+EUBBwEBMIGOMCgGCCsGAQUFBwIBFhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vQ1BT
MGIGCCsGAQUFBwICMFYwFRYOVmVyaVNpZ24sIEluYy4wAwIBARo9VmVyaVNpZ24ncyBDUFMgaW5j
b3JwLiBieSByZWZlcmVuY2UgbGlhYi4gbHRkLiAoYyk5NyBWZXJpU2lnbjARBglghkgBhvhCAQEE
BAMCB4AwHQYDVR0lBBYwFAYIKwYBBQUHAwQGCCsGAQUFBwMCMA0GCSqGSIb3DQEBBAUAA4GBACCK
+gbdTcJB2wmWF5q8hbnP6slvVFehmjSX1Se+4Ff6a3Uiw8aOQLyNwnYUSOtHe12rTwAtWOhEgXHK
D4XY3tF7cofo5hM8dk8xsj9vV3z3fYARDr4nR2bZblPJ3MGmAFAYKW4pgX4Y6NU4VhAG2Hiuj18/
H4Cc5g5oqJp5dArUMYIC+DCCAvQCAQEwgcEwgawxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8w
HQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUkwRwYDVQQLE0BVc2UgaXMgc3ViamVjdCB0
byB0ZXJtcyBhdCBodHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBhLWtyIChjKTk5MSUwIwYDVQQD
ExxWZXJpU2lnbiBDbGFzcyAyIEVtcGxveWVlIENBAhB1r2kCf1egyUu2+hQOrwvJMAkGBSsOAwIa
BQCgggGMMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTAzMDEyOTAx
NDUzN1owIwYJKoZIhvcNAQkEMRYEFMflgC/NW1aFkSejkuIKgIlhTKPmMFgGCSqGSIb3DQEJDzFL
MEkwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwICAgCAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMAcG
BSsOAwIaMAoGCCqGSIb3DQIFMIHSBgkrBgEEAYI3EAQxgcQwgcEwgawxFzAVBgNVBAoTDlZlcmlT
aWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUkwRwYDVQQLE0BVc2Ug
aXMgc3ViamVjdCB0byB0ZXJtcyBhdCBodHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBhLWtyIChj
KTk5MSUwIwYDVQQDExxWZXJpU2lnbiBDbGFzcyAyIEVtcGxveWVlIENBAhB1r2kCf1egyUu2+hQO
rwvJMA0GCSqGSIb3DQEBAQUABIGAZahoLtCC/WXlx4dCwjXo3aBu2lrD7xKo414vdHM/Dkz+EnV1
qyqvd8PsZ4K6o2rKMZ0Zv0TlkKttXpyTdvDsi4bxsyHZcxGclqlwpUf++ooVYDJvuE4XuBI3imP0
eURSfKjlsgwaRVRH++w/z0NNMT69EjILw17rZePGS2ZINQ8AAAAAAAA=

------=_NextPart_000_0014_01C2C70E.361CC580--



Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h0SMNYU13885 for ietf-pkix-bks; Tue, 28 Jan 2003 14:23:34 -0800 (PST)
Received: from gto-mailer1.bbn.com (gto-mailer1.bbn.com [128.33.0.36]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h0SMNRo13881 for <[e-mail]>; Tue, 28 Jan 2003 14:23:33 -0800 (PST)
Received: from [128.33.238.187] (tc238-187.bbn.com [128.33.238.187]) by gto-mailer1.bbn.com (8.9.3+Sun/8.9.3) with ESMTP id RAA29662 for <[e-mail]>; Tue, 28 Jan 2003 17:23:31 -0500 (EST)
Mime-Version: 1.0
X-Sender: [e-mail] (Unverified)
Message-Id: <p05111a02ba5216ebeffb@[128.89.89.100]>
In-Reply-To: <[e-mail]>
References: <[e-mail]>
Date: Tue, 28 Jan 2003 17:23:55 -0500
To: [e-mail]
From: Stephen Kent <[e-mail]>
Subject: Real-time Certificate Status Facility for OCSP - (RTCS)
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Peter describes the function provided by the RTCS extensions to OCSP 
as an "authenticated dictionary" service for certs. Peter and I 
discussed his I-D prior to posting and the concern I expressed then 
is that X.500 (and PKIX) have no notion of such a service, per se. Of 
course authenticated directory access is a good thing, but the 
presence of absence of a cert in a directory is NOT an indication of 
its status, either valid or revoked, in the X.500 model.

The concern I raised in my e-mail exchanges with Peter is that by 
extending the OCSP semantics from that of a revocation status 
protocol (by allowing responses that go beyond revocation status to 
indicate the presence of a cert in a database), RTCS into the realm 
of a delegated cert validation protocol. RTCS tells the requester 
whether a cert exists in a database maintained by a CA or a designee, 
where the database contains only valid certs. This is not a 
revocation  status function; it is a more general cert status 
function.

It is fair to say that RTCS does not provide all of the facilities of 
a DPV server as PKIX has defined. However, RTCS does provide 
validation of individual certs (by virtue of indicating whether the 
cert in question is valid or not) and that is a subset of the DPV 
service.  A series of requests to servers implementing RTCS mimics a 
subset of what a a DPV server would provide, offering a new function 
not presently available from any other X.500 or PKIX protocol.

Thus my concern was that RTCS competes with our DPV work and should 
be considered relative to that ongoing activity.  It is up to the WG 
to decide whether PKIX should consider RTCS as a separate work item 
unrelated to our DPV work, consider it a competitor to that work, or 
ignore it. In the first case we can add it to our list of work items, 
essentially deciding that it is not in conflict with the DPV work. In 
the second case we would probably reject it as it does not implement 
many of the DPV requirements. In this case we would also be saying 
that it should not proceed as an independent RFC, as it conflicts 
with the DPV work item and we have vowed to not produce duplicate 
standards for this function. In the third case we could allow it to 
proceed as an independent work outside of PKIX, and it could become 
an RFC.

I'd like to initiate discussion on this issue of the right 
categorization of this document, prior to any discussion of how well 
the proposed mechanism performs the indicated function

Steve


Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h0SGHYU01737 for ietf-pkix-bks; Tue, 28 Jan 2003 08:17:34 -0800 (PST)
Received: from pigeon.verisign.com (pigeon.verisign.com [65.205.251.71]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h0SGHXo01733 for <[e-mail]>; Tue, 28 Jan 2003 08:17:33 -0800 (PST)
Received: from vhqpostal-gw1.verisign.com (verisign.com [65.205.251.55]) by pigeon.verisign.com (8.12.1/) with ESMTP id h0SGFl3k008491; Tue, 28 Jan 2003 08:15:48 -0800 (PST)
Received: by vhqpostal-gw1.verisign.com with Internet Mail Service (5.5.2656.59) id <ZHLNNW6B>; Tue, 28 Jan 2003 08:17:33 -0800
Message-ID: <[e-mail]>
From: "Hallam-Baker, Phillip" <[e-mail]>
To: [e-mail], [e-mail]
Cc: [e-mail]
Subject: RE: Lookup from DNS was: X.500, LDAP Considered harmful
Date: Tue, 28 Jan 2003 08:17:30 -0800
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2656.59)
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=SHA1; boundary="----=_NextPart_000_008C_01C2C6BE.A39EE2A0"; protocol="application/x-pkcs7-signature"
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

This is a multi-part message in MIME format.

------=_NextPart_000_008C_01C2C6BE.A39EE2A0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit


> My main concern was that you'd end up mandating something 
> that would be impossible to do for 99% of the user base, 

That does not actually affect XKMS. If you can't use SRV on
your box you can delegate the query to a box that does have 
SRV support with an XKMS locate or validate service set up.

The only reason you would need local support for XKMS would
be if you wanted to use SRV to support auto-config on the
client so the client can automatically discover its local
XKMS information and registration servers. That is a neat
trick, but it is absolutely not a 'must have' issue.


SRV is supported by all the current versions of Microsoft 
Windows so we don't need to talk about 99% being unable
to use it.

In Windows the cryptographic subsystem is part of the O/S so
any extension of that system is going to require an O/S upgrade,
either a new O/S version or a service pack. So any upgrade that
allows following of SRV pointers can make any necessary fixes
to the DNS stack at the same time.

The DNS stack can be supported at the client layer in any case.
This is what all the early W95 browsers did.

The only real constraint is that the enterprise DNS system has
to support SRV records at least at the level of forwarding 
queries.


I agree that there may be legacy issues here. I don't think that
they are important as the worst that happens is that you are only
able to use the existing infrastructure which as we all agree (apart
from the directory vendor) does not work for PKI anyway.


		Phill

------=_NextPart_000_008C_01C2C6BE.A39EE2A0
Content-Type: application/x-pkcs7-signature;
	name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment;
	filename="smime.p7s"

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINbTCCAj0w
ggGmAhEAulrJTAU7ktantt9O0FOSDTANBgkqhkiG9w0BAQIFADBfMQswCQYDVQQGEwJVUzEXMBUG
A1UEChMOVmVyaVNpZ24sIEluYy4xNzA1BgNVBAsTLkNsYXNzIDIgUHVibGljIFByaW1hcnkgQ2Vy
dGlmaWNhdGlvbiBBdXRob3JpdHkwHhcNOTYwMTI5MDAwMDAwWhcNMDQwMTA3MjM1OTU5WjBfMQsw
CQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xNzA1BgNVBAsTLkNsYXNzIDIgUHVi
bGljIFByaW1hcnkgQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkwgZ8wDQYJKoZIhvcNAQEBBQADgY0A
MIGJAoGBALZai6MNaiODgGvPOYf0IRMzBkwlou1VEpfFp4C5+oPBIKD6LxUNfKFga355LPoGDzqu
9htvsdL/LyhSX4N9S8R6t/hmH4BU/LfCjllKFFdG0ZqTvkGRA7sVgJNc6+fMCGw/PrNK/P9LbCPV
UIImRBmOI8Nx6hkkRwSedb/IpgAfAgMBAAEwDQYJKoZIhvcNAQECBQADgYEAtgAfk1ekB6dAzmVA
P1Ve7e/6VEmlMNYhfGGH7oOTC7+0M/KYrJ8Gv06ozhSBTMsETljDz1/ufNeab8tBird/gbj/hGHG
J0NlHQzssQAK3Ruku8d4ICiyot02lS7hVE+/YLl3aBGZI+jqUuiqAE5nTruQtUWbRuuOFu/EM1sz
PdUwggNDMIICrKADAgECAhAffl/nA9Hgv5kg3GuJDUsEMA0GCSqGSIb3DQEBBAUAMF8xCzAJBgNV
BAYTAlVTMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjE3MDUGA1UECxMuQ2xhc3MgMiBQdWJsaWMg
UHJpbWFyeSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTAeFw05OTAyMjUwMDAwMDBaFw0wNDAxMDUy
MzU5NTlaMIGtMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1
c3QgTmV0d29yazFJMEcGA1UECxNAVXNlIGlzIHN1YmplY3QgdG8gdGVybXMgYXQgaHR0cHM6Ly93
d3cudmVyaXNpZ24uY29tL3JwYS1rciAoYyk5OTEmMCQGA1UEAxMdVmVyaVNpZ24gQ2xhc3MgMiBQ
ZXJzb25uZWwgQ0EwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBAKcEbA+icrdKBi741yksNJ2C
vEiRSses+en8uVl4sVXAU1ixz28WO8FJ1cv0bszhzMu1xy5OiKo06bbQW3w+FVc04Ri8/931r2dZ
IArlPeqIikDSmokTKam21dunfuHnNyST/ZR0TXrkMm1M6FwWl6/dktlmihRm5OpaA6g9X/sLAgMB
AAGjgbAwga0wMQYDVR0fBCowKDAmoCSgIoYgaHR0cDovL2NybC52ZXJpc2lnbi5jb20vcGNhMi5j
cmwwEQYJYIZIAYb4QgEBBAQDAgEGMEcGA1UdIARAMD4wPAYLYIZIAYb4RQEHAQEwLTArBggrBgEF
BQcCARYfaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYS1rcjAPBgNVHRMECDAGAQH/AgEBMAsG
A1UdDwQEAwIBBjANBgkqhkiG9w0BAQQFAAOBgQB59xXN6GhRWWv8qaa94B77vPQ/kN/n+u3kVPdh
PVSLBrqXMloeqyzur3Orx13TP4/0zstOSGCiqGC2ON6gpvePKegRrMw5dlA83TlsC/Fa/QhUdt0W
bPcxcLi/CPfJJgaO37svGbG2uLToPEjoJ7GXKSBXA5ybZ/p9QMQ4fxiqmjCCA8QwggMtoAMCAQIC
EQCEzvIOADm1dVXaGYePUu2JMA0GCSqGSIb3DQEBBAUAMIGtMRcwFQYDVQQKEw5WZXJpU2lnbiwg
SW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFJMEcGA1UECxNAVXNlIGlzIHN1
YmplY3QgdG8gdGVybXMgYXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYS1rciAoYyk5OTEm
MCQGA1UEAxMdVmVyaVNpZ24gQ2xhc3MgMiBQZXJzb25uZWwgQ0EwHhcNOTkwMjI1MDAwMDAwWhcN
MDQwMTA0MjM1OTU5WjCBrDEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlT
aWduIFRydXN0IE5ldHdvcmsxSTBHBgNVBAsTQFVzZSBpcyBzdWJqZWN0IHRvIHRlcm1zIGF0IGh0
dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9ycGEta3IgKGMpOTkxJTAjBgNVBAMTHFZlcmlTaWduIENs
YXNzIDIgRW1wbG95ZWUgQ0EwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBAMCK0YdhouowA1Vr
CDbwl/oaVDUkH+h9ncjDc9PYRvWRLdk47ZTXsCZzKt6XUE3/Ihy9cACYDFgqsaRyj6W59y18YOO1
3+l9TiEhYdX8O1TJpAmcuyL5orpwYU+GRqL9BWTsCj+mWHZXuxZzRHzwpQ2XwGym8WMIJbEEF5Wg
jf5/AgMBAAGjgeIwgd8wKQYDVR0RBCIwIKQeMBwxGjAYBgNVBAMTEVByaXZhdGVMYWJlbDEtMTE4
MDgGA1UdHwQxMC8wLaAroCmGJ2h0dHA6Ly9jcmwudmVyaXNpZ24uY29tL1ZTQ2xhc3MySW50LmNy
bDARBglghkgBhvhCAQEEBAMCAQYwRwYDVR0gBEAwPjA8BgtghkgBhvhFAQcBATAtMCsGCCsGAQUF
BwIBFh9odHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBhLWtyMA8GA1UdEwQIMAYBAf8CAQAwCwYD
VR0PBAQDAgEGMA0GCSqGSIb3DQEBBAUAA4GBABlGztRrcI5YXIhCNa0WfaUJLKhTkPH2PYbX8M5y
FD0ivPLDM+3U/AWa4GMgdaMb71UZDwZzIQJhrqaeUSt43FvIhIvV17bP1fg+l5ixRIujmI6gS/aY
MZOz8AzdUXbKl+RWRMb7lKFIfSJDzKDGXHlV9WeBG2iYNCREsZjBOiheMIIEGTCCA4KgAwIBAgIQ
da9pAn9XoMlLtvoUDq8LyTANBgkqhkiG9w0BAQQFADCBrDEXMBUGA1UEChMOVmVyaVNpZ24sIElu
Yy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0IE5ldHdvcmsxSTBHBgNVBAsTQFVzZSBpcyBzdWJq
ZWN0IHRvIHRlcm1zIGF0IGh0dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9ycGEta3IgKGMpOTkxJTAj
BgNVBAMTHFZlcmlTaWduIENsYXNzIDIgRW1wbG95ZWUgQ0EwHhcNMDIwMjI3MDAwMDAwWhcNMDMw
MjI3MjM1OTU5WjBtMREwDwYDVQQKEwhWRVJJU0lHTjELMAkGA1UECxMCSFExEzARBgNVBAMTClJl
Y2lwaWVudHMxNjA0BgNVBAMTLXBiYWtlciAoSGFsbGFtLUJha2VyIFBoaWxsaXAsIFZlcmlTaWdu
LCBJbmMuKTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAtcA/okLsFi9brjmDsXQ6+g+R95B1
81Lq1EXkdzhY7XHxQ2QDq0sS2U4j9N1Ic6nHIiMq5dticztWpKdn6CrDx3Ovd5k+PACq/jSQo7NL
tlMJi7fsUrP7pM4izKu4JjSak6wRJUA4x85TSC1PLfd1u8oq16iqNJRhpEJ8VJUMRyECAwEAAaOC
AXgwggF0MAkGA1UdEwQCMAAwWQYDVR0fBFIwUDBOoEygSoZIaHR0cDovL29uc2l0ZWNybC52ZXJp
c2lnbi5jb20vVmVyaVNpZ25JbmNFeGNoYW5nZUVtcGxveWVlcy9MYXRlc3RDUkwuY3JsMAsGA1Ud
DwQEAwIFoDAeBgNVHREEFzAVgRNwYmFrZXJAdmVyaXNpZ24uY29tMIGsBgNVHSAEgaQwgaEwgZ4G
C2CGSAGG+EUBBwEBMIGOMCgGCCsGAQUFBwIBFhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vQ1BT
MGIGCCsGAQUFBwICMFYwFRYOVmVyaVNpZ24sIEluYy4wAwIBARo9VmVyaVNpZ24ncyBDUFMgaW5j
b3JwLiBieSByZWZlcmVuY2UgbGlhYi4gbHRkLiAoYyk5NyBWZXJpU2lnbjARBglghkgBhvhCAQEE
BAMCB4AwHQYDVR0lBBYwFAYIKwYBBQUHAwQGCCsGAQUFBwMCMA0GCSqGSIb3DQEBBAUAA4GBACCK
+gbdTcJB2wmWF5q8hbnP6slvVFehmjSX1Se+4Ff6a3Uiw8aOQLyNwnYUSOtHe12rTwAtWOhEgXHK
D4XY3tF7cofo5hM8dk8xsj9vV3z3fYARDr4nR2bZblPJ3MGmAFAYKW4pgX4Y6NU4VhAG2Hiuj18/
H4Cc5g5oqJp5dArUMYIC+DCCAvQCAQEwgcEwgawxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8w
HQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUkwRwYDVQQLE0BVc2UgaXMgc3ViamVjdCB0
byB0ZXJtcyBhdCBodHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBhLWtyIChjKTk5MSUwIwYDVQQD
ExxWZXJpU2lnbiBDbGFzcyAyIEVtcGxveWVlIENBAhB1r2kCf1egyUu2+hQOrwvJMAkGBSsOAwIa
BQCgggGMMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTAzMDEyODE2
MTYwMVowIwYJKoZIhvcNAQkEMRYEFPJdhlHIZ9rIpMQjxKNPZIGVsAF+MFgGCSqGSIb3DQEJDzFL
MEkwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwICAgCAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMAcG
BSsOAwIaMAoGCCqGSIb3DQIFMIHSBgkrBgEEAYI3EAQxgcQwgcEwgawxFzAVBgNVBAoTDlZlcmlT
aWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUkwRwYDVQQLE0BVc2Ug
aXMgc3ViamVjdCB0byB0ZXJtcyBhdCBodHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBhLWtyIChj
KTk5MSUwIwYDVQQDExxWZXJpU2lnbiBDbGFzcyAyIEVtcGxveWVlIENBAhB1r2kCf1egyUu2+hQO
rwvJMA0GCSqGSIb3DQEBAQUABIGAUqT40Afctlwxq7cCl1Y3i8c460ckB27fOK+Ri17RsUzxZGN8
Ce8+OuULZzWcX65yPJZ3H6moTy/phsJA+nYZ0SwGgtkLhcSt0wPBPtGAIMUyuyAt/1sgEEkuxHXP
alHqR39xzBN4ONotz4ZxSNmCwfNvXKemrVDGEE858yfN5b4AAAAAAAA=

------=_NextPart_000_008C_01C2C6BE.A39EE2A0--



Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h0SFh0x00545 for ietf-pkix-bks; Tue, 28 Jan 2003 07:43:00 -0800 (PST)
Received: from maild.telia.com (maild.telia.com [194.22.190.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h0SFgxo00537 for <[e-mail]>; Tue, 28 Jan 2003 07:42:59 -0800 (PST)
Received: from arport (h220n2fls31o1122.telia.com [212.181.142.220]) by maild.telia.com (8.12.5/8.12.5) with SMTP id h0SFgx33000951 for <[e-mail]>; Tue, 28 Jan 2003 16:42:59 +0100 (CET)
X-Original-Recipient: <[e-mail]>
Message-ID: <054c01c2c6e3$95bf4010$0500a8c0@arport>
From: "Anders Rundgren" <[e-mail]>
To: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]>
Subject: STRAWPOLL: XKMS
Date: Tue, 28 Jan 2003 16:40:29 +0100
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.50.4133.2400
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

A non-conformant reply based on the fact that few IT-vendors
see any major advantages with multiple standards, particularly
when the [business] systems needing off-loaded [and centralized]
security operations typically speak XML. 

In addition to the fact that XKMS is already shipping, albeit in
an early version.

I have not checked the matrix in detail but it should not be too far
from the requirements.  Certificate policies seem to be missing
but this mechanism is generally much overrated as there is no
standardized way to classify certificates at all.  Just a format.

Payload size is BTW not the #1 problem, it is latency that
is the real killer if we are talking mobile clients.

AR












Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h0SDqN424482 for ietf-pkix-bks; Tue, 28 Jan 2003 05:52:23 -0800 (PST)
Received: from atlgeo3.geotrust.com (atlgeo3.geotrust.com [66.21.21.35]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h0SDqLo24478 for <[e-mail]>; Tue, 28 Jan 2003 05:52:22 -0800 (PST)
Received: by atlgeo3.atlanta.geotrust.com with Internet Mail Service (5.5.2653.19) id <C7SCSAK5>; Tue, 28 Jan 2003 08:48:16 -0500
Message-ID: <[e-mail]>
From: Kefeng Chen <[e-mail]>
To: "'[e-mail]'" <[e-mail]>
Subject: STRAWPOLL:OCSP
Date: Tue, 28 Jan 2003 08:48:15 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain; charset="iso-8859-1"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>


Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h0SCSwM18995 for ietf-pkix-bks; Tue, 28 Jan 2003 04:28:58 -0800 (PST)
Received: from dns1.pvt.cz (spider.pvt.cz [194.149.101.200]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h0SCSvo18990 for <[e-mail]>; Tue, 28 Jan 2003 04:28:57 -0800 (PST)
Received: from plzw01.pvt.cz (plzw01.pvt.cz [172.17.22.10]) by dns1.pvt.cz (8.11.2/8.11.2) with ESMTP id h0SCSq712437 for <[e-mail]>; Tue, 28 Jan 2003 13:28:52 +0100
content-class: urn:content-classes:message
Subject: STRAWPOLL:DVCS
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C2C6C8.D14447A6"
Date: Tue, 28 Jan 2003 13:28:52 +0100
Message-ID: <[e-mail]>
X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: STRAWPOLL:DVCS
Thread-Index: AcLGyNExuPG/y2RjQk2ep+5oj6vetA==
From: =?iso-8859-1?Q?Vohnoutov=E1_Marta?= <[e-mail]>
To: <[e-mail]>
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

This is a multi-part message in MIME format.

------_=_NextPart_001_01C2C6C8.D14447A6
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable



Marta Vohnoutov=E1 - System Engineer
PVT a.s. Pilsen		Slovansk=E1 alej 30,  317 66 Pilsen
	 	            Czech Republic
phone:			[phone]
mobile:			[phone]
fax:		            [phone]
e-mail:			[e-mail]
Talking to me leave your bad mood out of my door :-)



------_=_NextPart_001_01C2C6C8.D14447A6
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 =
6.0.5762.3">
<TITLE>STRAWPOLL:DVCS</TITLE>
</HEAD>
<BODY>
<!-- Converted from text/rtf format -->
<BR>
<BR>

<P><B><FONT COLOR=3D"#000080" SIZE=3D2 FACE=3D"Arial">Marta =
Vohnoutov<SPAN LANG=3D"cs"></SPAN></FONT><SPAN LANG=3D"cs"><FONT =
COLOR=3D"#000080" SIZE=3D2 FACE=3D"Arial CE">=E1</FONT></SPAN></B><SPAN =
LANG=3D"cs"> <FONT COLOR=3D"#000080" SIZE=3D2 FACE=3D"Arial CE">- System =
Engineer</FONT></SPAN>

<BR><SPAN LANG=3D"cs"><B><FONT SIZE=3D2 FACE=3D"Arial CE">PVT a.s. =
Pilsen</FONT></B> &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT =
SIZE=3D2 FACE=3D"Arial CE">Slovansk=E1 alej 30</FONT></SPAN><SPAN =
LANG=3D"en-us"></SPAN><SPAN LANG=3D"en-us"><FONT SIZE=3D2 =
FACE=3D"Arial">,&nbsp; 317 66</FONT></SPAN><SPAN =
LANG=3D"cs"></SPAN><SPAN LANG=3D"cs"> <FONT SIZE=3D2 FACE=3D"Arial =
CE">Pilsen</FONT></SPAN><SPAN LANG=3D"en-us"></SPAN><SPAN =
LANG=3D"en-us"><BR>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<FONT SIZE=3D2 =
FACE=3D"Arial"></FONT></SPAN><SPAN LANG=3D"cs"></SPAN><SPAN LANG=3D"cs"> =
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT SIZE=3D2 FACE=3D"Arial =
CE">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
Czech Republic</FONT></SPAN>

<BR><SPAN LANG=3D"cs"><FONT SIZE=3D2 FACE=3D"Arial CE">phone:&nbsp; =
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</FONT></SPAN><SPAN =
LANG=3D"en-us"></SPAN><SPAN LANG=3D"en-us"> <FONT SIZE=3D2 =
FACE=3D"Arial">[phone]</FONT></SPAN>

<BR><SPAN LANG=3D"cs"><FONT SIZE=3D2 FACE=3D"Arial CE">mobile: =
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</FONT></SPAN><SPAN =
LANG=3D"en-us"></SPAN><SPAN LANG=3D"en-us"> <FONT SIZE=3D2 =
FACE=3D"Arial">[phone]</FONT></SPAN>

<BR><SPAN LANG=3D"en-us"><FONT SIZE=3D2 =
FACE=3D"Arial">fax:&nbsp;&nbsp;&nbsp; =
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
[phone]</FONT></SPAN>

<BR><SPAN LANG=3D"en-us"><FONT SIZE=3D2 FACE=3D"Arial">e-mail: =
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
[e-mail]</FONT></SPAN>

<BR><SPAN LANG=3D"en-us"><B><FONT COLOR=3D"#000080" SIZE=3D2 =
FACE=3D"Arial">Talking to me leave your bad mood out of my door =
:-)</FONT></B></SPAN>
</P>
<BR>

</BODY>
</HTML>
------_=_NextPart_001_01C2C6C8.D14447A6--


Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h0SC4BJ15931 for ietf-pkix-bks; Tue, 28 Jan 2003 04:04:11 -0800 (PST)
Received: from nb2.stroeder.com (krl9-d9bb4c98.pool.mediaWays.net [217.187.76.152]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h0SC49o15922 for <[e-mail]>; Tue, 28 Jan 2003 04:04:09 -0800 (PST)
Received: from localhost (localhost.stroeder.com [127.0.0.1]) by nb2.stroeder.com (Postfix) with ESMTP id 752E723FAA for <[e-mail]>; Tue, 28 Jan 2003 13:04:04 +0100 (CET)
Received: from stroeder.com (localhost.stroeder.com [127.0.0.1]) by nb2.stroeder.com (Postfix) with ESMTP id D20C923EEB for <[e-mail]>; Tue, 28 Jan 2003 13:04:03 +0100 (CET)
Message-ID: <[e-mail]>
Date: Tue, 28 Jan 2003 13:04:03 +0100
From: =?ISO-8859-1?Q?Michael_Str=F6der?= <[e-mail]>
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.2.1) Gecko/20021130
X-Accept-Language: de-de, de, en-us, en
MIME-Version: 1.0
To: [e-mail]
Subject: Re: Lookup from DNS was: X.500, LDAP Considered harmful
References: <[e-mail]> <012a01c2c6b7$8bd0d8b0$0500a8c0@arport>
In-Reply-To: <012a01c2c6b7$8bd0d8b0$0500a8c0@arport>
X-Enigmail-Version: 0.71.0.0
X-Enigmail-Supports: pgp-inline, pgp-mime
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
X-Virus-Scanned: by AMaViS 0.3.12pre8
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Anders Rundgren wrote:
> It must be possible although a bit awkward to make a free-standing
> DNS SRV client-implementation of top of any Winsock-version. 
> That's what SUN does with their Java stuff.   Or rather it is what you have
> to do as an independent software vendor (ISV), _all_the_time_ in order
> to survive changes in APIs etc...

Yes. That's least of a problem. There are mature resolver modules for all 
programming environments with support for SRV RRs.

The biggest problem is making developers aware of and accept a standard. 
Application developers most times do not read RFCs or follow IETF mailing lists.

Ciao, Michael.



Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h0SARn912265 for ietf-pkix-bks; Tue, 28 Jan 2003 02:27:49 -0800 (PST)
Received: from maild.telia.com (maild.telia.com [194.22.190.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h0SARmo12261 for <[e-mail]>; Tue, 28 Jan 2003 02:27:48 -0800 (PST)
Received: from arport (h220n2fls31o1122.telia.com [212.181.142.220]) by maild.telia.com (8.12.5/8.12.5) with SMTP id h0SARigV005458; Tue, 28 Jan 2003 11:27:45 +0100 (CET)
X-Original-Recipient: [e-mail]
Message-ID: <012a01c2c6b7$8bd0d8b0$0500a8c0@arport>
From: "Anders Rundgren" <[e-mail]>
To: "Peter Gutmann" <[e-mail]>
Cc: <[e-mail]>
References: <[e-mail]>
Subject: Re: Lookup from DNS was: X.500, LDAP Considered harmful
Date: Tue, 28 Jan 2003 11:25:14 +0100
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.50.4133.2400
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Peter,
It must be possible although a bit awkward to make a free-standing
DNS SRV client-implementation of top of any Winsock-version. 
That's what SUN does with their Java stuff.   Or rather it is what you have
to do as an independent software vendor (ISV), _all_the_time_ in order
to survive changes in APIs etc...

Do I like it?  No.  Do I have a choice?  Not really.

Anders

----- Original Message ----- 
From: "Peter Gutmann" <[e-mail]>
To: <[e-mail]>; <[e-mail]>
Cc: <[e-mail]>
Sent: Tuesday, January 28, 2003 09:49
Subject: Re: Lookup from DNS was: X.500, LDAP Considered harmful


"Anders Rundgren" <[e-mail]> writes:

>Although I don't know all the details concerning the SRV-records, I think it
>is a mistake not to support this in a draft intended for the future.  Phill
>and XKMS-gang have no such hesitations at least, although they really want a
>NAPTR that does SRV+TXT in one bite.

My main concern was that you'd end up mandating something that would be
impossible to do for 99% of the user base, which means it'd end up ignored by
implementors, which is never a good thing for a standard (X9.42, anyone?). I'm
totally open to suggestions on this, perhaps a "Use DNS SRV if possible but be
prepared to have to use the following hack instead"?  Or supply a cutover date
as with UTF8Strings where you're expected to support DNS SRV after the given
date, maybe using an estimate of when > 50% of the user base have moved to XP.
Or maybe just specify the SRV info and leave it at that, using the theory that
having something written down for future use is better than nothing, even if
almsot no-one uses it at the moment.

Peter.



Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h0S9NI204992 for ietf-pkix-bks; Tue, 28 Jan 2003 01:23:18 -0800 (PST)
Received: from maild.telia.com (maild.telia.com [194.22.190.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h0S9NGo04986 for <[e-mail]>; Tue, 28 Jan 2003 01:23:16 -0800 (PST)
Received: from arport (h220n2fls31o1122.telia.com [212.181.142.220]) by maild.telia.com (8.12.5/8.12.5) with SMTP id h0S9NDeG000596; Tue, 28 Jan 2003 10:23:13 +0100 (CET)
X-Original-Recipient: [e-mail]
Message-ID: <00a801c2c6ae$883c5660$0500a8c0@arport>
From: "Anders Rundgren" <[e-mail]>
To: "Peter Gutmann" <[e-mail]>
Cc: <[e-mail]>
References: <[e-mail]>
Subject: Authenticated CERTSTORE URLs
Date: Tue, 28 Jan 2003 10:20:43 +0100
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.50.4133.2400
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Peter,
Assume that you do not "publish" certficates for everybody to
see, but still allow coded out-of-band received URLs to do lookups.

Like

http://host/csaspp?hmac=45665feedda44445a4fde3443&email=[e-mail]

Such a URL could be put in a user's EE-certificate and stored in an
e-mail client rather than storing the certificate itself.  The authentication
should stay intact over certificate renewals in order to be of any use.
Such URLs should maybe have a unique OID for the above to happen?

A regenerated key allows you to "vanish" in case your key has gone
more or less public.

Stupid, useful, possible?

Other:

A limitation in CERTSTORE is the exclusion of status information
that a client can digest in a reasonable (=locale independent) way.
Like "no such user", "no such certificate", and
"invalid authentication - expired?"  (for the suggestion above).

Anders



Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h0S9LNE04945 for ietf-pkix-bks; Tue, 28 Jan 2003 01:21:23 -0800 (PST)
Received: from maild.telia.com (maild.telia.com [194.22.190.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h0S9LMo04941 for <[e-mail]>; Tue, 28 Jan 2003 01:21:22 -0800 (PST)
Received: from arport (h220n2fls31o1122.telia.com [212.181.142.220]) by maild.telia.com (8.12.5/8.12.5) with SMTP id h0S9LIeG027883; Tue, 28 Jan 2003 10:21:18 +0100 (CET)
X-Original-Recipient: [e-mail]
Message-ID: <00a701c2c6ae$43baa5f0$0500a8c0@arport>
From: "Anders Rundgren" <[e-mail]>
To: "Peter Gutmann" <[e-mail]>
Cc: <[e-mail]>
References: <[e-mail]>
Subject: Re: Lookup from DNS was: X.500, LDAP Considered harmful
Date: Tue, 28 Jan 2003 10:18:47 +0100
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.50.4133.2400
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Peter,

One can see it like this:
If you are pointing at Windows, the user typically have Outlook
or Outlook express.  Now, if Microsoft is going to support
CERTSTORE they will naturally have to ship it with functioning
DNS support.  If that means an upgraded Winsock, it would certainly
not be the first time in history, when Microsoft upgraded the OS
as a part of an application install.

However, it would be better if somebody from the "source" commented
on this.

Anders

----- Original Message ----- 
From: "Peter Gutmann" <[e-mail]>
To: <[e-mail]>; <[e-mail]>
Cc: <[e-mail]>
Sent: Tuesday, January 28, 2003 09:49
Subject: Re: Lookup from DNS was: X.500, LDAP Considered harmful


"Anders Rundgren" <[e-mail]> writes:

>Although I don't know all the details concerning the SRV-records, I think it
>is a mistake not to support this in a draft intended for the future.  Phill
>and XKMS-gang have no such hesitations at least, although they really want a
>NAPTR that does SRV+TXT in one bite.

My main concern was that you'd end up mandating something that would be
impossible to do for 99% of the user base, which means it'd end up ignored by
implementors, which is never a good thing for a standard (X9.42, anyone?). I'm
totally open to suggestions on this, perhaps a "Use DNS SRV if possible but be
prepared to have to use the following hack instead"?  Or supply a cutover date
as with UTF8Strings where you're expected to support DNS SRV after the given
date, maybe using an estimate of when > 50% of the user base have moved to XP.
Or maybe just specify the SRV info and leave it at that, using the theory that
having something written down for future use is better than nothing, even if
almsot no-one uses it at the moment.

Peter.



Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h0S8luK29818 for ietf-pkix-bks; Tue, 28 Jan 2003 00:47:56 -0800 (PST)
Received: from hermes.cs.auckland.ac.nz (hermes.cs.auckland.ac.nz [130.216.35.151]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h0S8lso29801 for <[e-mail]>; Tue, 28 Jan 2003 00:47:54 -0800 (PST)
Received: from medusa01.cs.auckland.ac.nz (medusa01.cs.auckland.ac.nz [130.216.34.60]) by hermes.cs.auckland.ac.nz (8.12.4/8.12.4) with ESMTP id h0S8lmOr024913; Tue, 28 Jan 2003 21:47:48 +1300
Received: (from pgut001@localhost) by medusa01.cs.auckland.ac.nz (8.11.6/8.11.6) id h0S8n6t31800; Tue, 28 Jan 2003 21:49:06 +1300
Date: Tue, 28 Jan 2003 21:49:06 +1300
Message-Id: <[e-mail]>
From: [e-mail] (Peter Gutmann)
To: [e-mail], [e-mail]
Subject: Re: Lookup from DNS was: X.500, LDAP Considered harmful
Cc: [e-mail]
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

"Anders Rundgren" <[e-mail]> writes:

>Although I don't know all the details concerning the SRV-records, I think it
>is a mistake not to support this in a draft intended for the future.  Phill
>and XKMS-gang have no such hesitations at least, although they really want a
>NAPTR that does SRV+TXT in one bite.

My main concern was that you'd end up mandating something that would be
impossible to do for 99% of the user base, which means it'd end up ignored by
implementors, which is never a good thing for a standard (X9.42, anyone?). I'm
totally open to suggestions on this, perhaps a "Use DNS SRV if possible but be
prepared to have to use the following hack instead"?  Or supply a cutover date
as with UTF8Strings where you're expected to support DNS SRV after the given
date, maybe using an estimate of when > 50% of the user base have moved to XP.
Or maybe just specify the SRV info and leave it at that, using the theory that
having something written down for future use is better than nothing, even if
almsot no-one uses it at the moment.

Peter.


Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h0S8aAX26539 for ietf-pkix-bks; Tue, 28 Jan 2003 00:36:10 -0800 (PST)
Received: from maild.telia.com (maild.telia.com [194.22.190.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h0S8a8o26532 for <[e-mail]>; Tue, 28 Jan 2003 00:36:08 -0800 (PST)
Received: from arport (h220n2fls31o1122.telia.com [212.181.142.220]) by maild.telia.com (8.12.5/8.12.5) with SMTP id h0S8Zqp8019989; Tue, 28 Jan 2003 09:35:52 +0100 (CET)
X-Original-Recipient: [e-mail]
Message-ID: <009301c2c6a7$eba89fd0$0500a8c0@arport>
From: "Anders Rundgren" <[e-mail]>
To: "Hallam-Baker, Phillip" <[e-mail]>
Cc: "Tony Bartoletti" <[e-mail]>, <[e-mail]>, <[e-mail]>, <[e-mail]>, <[e-mail]>, "'Dean Povey'" <[e-mail]>
References: <[e-mail]>
Subject: Re: X.500, LDAP Considered harmful Was: OCSP/LDAP 
Date: Tue, 28 Jan 2003 09:33:21 +0100
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.50.4133.2400
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Going back to the subject line's "harmful", I have some
serious doubts regarding the original intent ("application"):

Except for path-validation, the other major reason of retrieving
somebody's certificate is for sending encrypted messages.

This assumes that privacy both with respect to the individual,
and to the organization that the individual may belong to is of
secondary importance.

That lookup and retrieval systems often require authentication
is not much of a blessing as this in a open Internet environment
makes "user" administration a true nightmare.

It would indeed have been wonderful to be able to search a
public directory where you could with the help of various
attributes, even be able to separate the "real" Slim Shady
from the "other" Slim Shady.  Unfortunately, both Slim Shadys
feel less enthusiastic about this...

The only really useful "open" lookup I can think of, particularly
in conjunction with DNS, is for retrieving keys to DOMSEC,
IPSEC, and similar non-personal communication.

Summary:
CIOs thinking about aligning their directory structures to
other organizations' should take a deep breath and put these
questions on the table: How wide is our circle of "allies"?
Will it stay like this for a considerable time?  How are we
going to manage possible temporary associations?  And if
we only have a relation between "departments"?

Anders R



Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h0S7WIX17975 for ietf-pkix-bks; Mon, 27 Jan 2003 23:32:18 -0800 (PST)
Received: from ns1.worldcall.net.pk ([203.81.192.10]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h0S7WGo17970 for <[e-mail]>; Mon, 27 Jan 2003 23:32:16 -0800 (PST)
Received: from ascertiafm ([203.81.195.74]) by ns1.worldcall.net.pk (8.12.2+Sun/8.12.2) with SMTP id h0SHXMv9019721 for <[e-mail]>; Tue, 28 Jan 2003 12:33:22 -0500 (GMT)
Message-ID: <004a01c2c69f$57161580$2500a8c0@ascertiafm>
From: <[e-mail]>
To: <[e-mail]>
Subject: STRAWPOLL: SCVP
Date: Tue, 28 Jan 2003 12:31:57 +0500
MIME-Version: 1.0
Content-Type: multipart/related; type="multipart/alternative"; boundary="----=_NextPart_000_0046_01C2C6C9.3F8CBF70"
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2800.1106
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

This is a multi-part message in MIME format.

------=_NextPart_000_0046_01C2C6C9.3F8CBF70
Content-Type: multipart/alternative;
	boundary="----=_NextPart_001_0047_01C2C6C9.3F8CBF70"


------=_NextPart_001_0047_01C2C6C9.3F8CBF70
Content-Type: text/plain;
	charset="Windows-1252"
Content-Transfer-Encoding: quoted-printable


Faisal Maqsood       Analyst

     a leading provider of real-time Certificate Validation solutions

 TrustFinderOCSP - provides the latest and most sophisticated OCSP =
(Online Certificate Status Protocol) server on the market.=20

ARP - is an essential plug-in for enabling OCSP client functionality in =
leading Microsoft=AE applications.


) Phone: [phone]
& Fax: [phone]
* Email: [e-mail]

Adding Trust to your PKI

www.ascertia.com

The opinions expressed are those of the individual and not the company. =
Internet communications are not secure and therefore the company does =
not accept legal responsibility for the contents of this message.  If =
the reader of this message is not the intended recipient, or the =
employee responsible for delivering this communication to the intended =
recipient, you are hereby notified that any disclosure, distribution or =
copying of this communication is strictly prohibited.=20




------=_NextPart_001_0047_01C2C6C9.3F8CBF70
Content-Type: text/html;
	charset="Windows-1252"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META http-equiv=3DContent-Type content=3D"text/html; =
charset=3Dwindows-1252"><BASE=20
href=3D"file://G:\_BackUp-FM\Email Signature\">
<META content=3D"MSHTML 6.00.2800.1106" name=3DGENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=3D#ffffff>
<DIV>&nbsp;</DIV>
<DIV>
<DIV class=3DSection1>
<DIV>
<P class=3DMsoNormal><FONT color=3D#008080 size=3D2><SPAN=20
style=3D"FONT-WEIGHT: 700"><EM><SPAN style=3D"FONT-FAMILY: Arial">Faisal =

Maqsood</SPAN></EM></SPAN></FONT><EM><B><I><FONT face=3DArial =
color=3Dteal=20
size=3D2><SPAN=20
style=3D"FONT-WEIGHT: bold; FONT-SIZE: 10pt; COLOR: teal; FONT-FAMILY: =
Arial; mso-no-proof: yes">&nbsp;&nbsp;</SPAN></FONT></I></B></EM><FONT=20
face=3DArial color=3Dblack size=3D1><SPAN=20
style=3D"FONT-SIZE: 7.5pt; COLOR: black; FONT-FAMILY: Arial; =
mso-no-proof: yes">&nbsp;&nbsp;&nbsp;&nbsp;=20
Analyst</SPAN></FONT></P>
<P><FONT face=3DArial size=3D1><SPAN=20
style=3D"FONT-SIZE: 7.5pt; FONT-FAMILY: Arial; mso-no-proof: yes"><IMG =
height=3D58=20
src=3D"cid:004501c2c69f$56b6b770$2500a8c0@ascertiafm" width=3D90=20
border=3D0>&nbsp;&nbsp;&nbsp;&nbsp; a leading provider of=20
real-time&nbsp;Certificate Validation solutions</SPAN></FONT></P>
<P>&nbsp;<FONT face=3D"Verdana, Arial, Helvetica, sans-serif" =
size=3D1><A=20
href=3D"http://www.ascertia.com/client/products/trust_finder.htm"=20
target=3D_blank>TrustFinderOCSP</A> - provides the latest and most =
sophisticated=20
OCSP (Online Certificate Status Protocol) server on the =
market.&nbsp;</FONT></P>
<P><FONT face=3D"Verdana, Arial, Helvetica, sans-serif" size=3D1><A=20
href=3D"http://www.ascertia.com/client/products/ocsp-revok-provider.htm" =

target=3D_blank>ARP </A>- is an essential plug-in for enabling OCSP =
client=20
functionality in leading Microsoft=AE applications.</FONT></P>
<P><FONT face=3DArial size=3D1><SPAN=20
style=3D"FONT-SIZE: 7.5pt; FONT-FAMILY: Arial; mso-no-proof: =
yes"><BR></SPAN></FONT><ST1:CITY><ST1:PLACE><SPAN=20
style=3D"FONT-WEIGHT: bold"><SPAN=20
style=3D"FONT-SIZE: 7.5pt; FONT-FAMILY: Arial; mso-no-proof: yes"><FONT =
face=3DArial=20
size=3D1><FONT size=3D3><FONT face=3DWingdings>)</FONT></FONT><FONT =
face=3DVerdana=20
size=3D2> </FONT></FONT></SPAN><FONT face=3DArial size=3D1><SPAN=20
style=3D"FONT-WEIGHT: bold; mso-no-proof: yes">Phone: [phone]=20
321<BR></SPAN></FONT><FONT face=3DArial size=3D1><SPAN=20
style=3D"FONT-SIZE: 7.5pt; FONT-FAMILY: Arial; mso-no-proof: yes"><FONT=20
face=3DWingdings size=3D3>&amp;</FONT><FONT face=3DVerdana size=3D2>=20
</FONT></SPAN></FONT><SPAN style=3D"FONT-WEIGHT: bold; mso-no-proof: =
yes"><FONT=20
face=3DArial size=3D1>Fax: [phone]</FONT></SPAN><SPAN=20
style=3D"FONT-SIZE: 7.5pt; FONT-FAMILY: Arial; mso-no-proof: yes"><FONT =
face=3DArial=20
size=3D1><FONT face=3DVerdana color=3D#808080 size=3D2><BR></FONT><FONT =
size=3D3><FONT=20
face=3DWingdings>*</FONT><FONT face=3D"Times New Roman">=20
</FONT></FONT></FONT></SPAN><FONT face=3DArial size=3D1><SPAN=20
style=3D"FONT-WEIGHT: bold; mso-no-proof: yes">Email: <A=20
style=3D"TEXT-DECORATION: none"=20
href=3D"mailto:[e-mail]">faisal.maqsood</A><A=20
style=3D"TEXT-DECORATION: none"=20
href=3D"mailto:[e-mail]">@ascertia.com</A></SPAN></FON=
T></SPAN></ST1:PLACE></ST1:CITY></P>
<P style=3D"TEXT-ALIGN: center" align=3Dcenter><FONT face=3D"Times New =
Roman"=20
color=3Dteal size=3D6><SPAN=20
style=3D"FONT-SIZE: 24pt; COLOR: teal; mso-no-proof: yes">Adding =
<EM><I><FONT=20
face=3D"Times New Roman">Trust</FONT></I></EM> to your =
PKI</SPAN></FONT><SPAN=20
style=3D"mso-no-proof: yes"><O:P></O:P></SPAN></P>
<P style=3D"TEXT-ALIGN: center" align=3Dcenter><FONT face=3D"Times New =
Roman"=20
size=3D3><SPAN style=3D"FONT-SIZE: 12pt; mso-no-proof: yes"><A=20
href=3D"http://www.ascertia.com/"><FONT face=3DArial size=3D2><SPAN=20
style=3D"FONT-SIZE: 10pt; FONT-FAMILY: =
Arial">www.ascertia.com</SPAN></FONT></A></SPAN></FONT></P>
<P><FONT face=3DArial color=3Dgray size=3D1><SPAN=20
style=3D"FONT-SIZE: 7.5pt; COLOR: gray; FONT-FAMILY: Arial; =
mso-no-proof: yes">The=20
opinions expressed are those of the individual and not the company. =
Internet=20
communications are not secure and therefore the company does not accept =
legal=20
responsibility for the contents of this message.&nbsp; If the reader of =
this=20
message is not the intended recipient, or the employee responsible for=20
delivering this communication to the intended recipient, you are hereby =
notified=20
that any disclosure, distribution or copying of this communication is =
strictly=20
prohibited.</SPAN></FONT><SPAN style=3D"mso-no-proof: yes">=20
</SPAN><O:P></O:P></P></DIV>
<P class=3DMsoNormal><FONT face=3D"Times New Roman" size=3D3><SPAN=20
style=3D"FONT-SIZE: 12pt"><O:P></O:P></SPAN></FONT></P></DIV></DIV>
<DIV>&nbsp;</DIV></BODY></HTML>

------=_NextPart_001_0047_01C2C6C9.3F8CBF70--

------=_NextPart_000_0046_01C2C6C9.3F8CBF70
Content-Type: application/octet-stream;
	name="Ascertia-Logo.gif"
Content-Transfer-Encoding: base64
Content-ID: <004501c2c69f$56b6b770$2500a8c0@ascertiafm>

R0lGODlhWgA6APcAAP///yQhIjmJyWhqbGS+a8jKzAWAxKDTnqiqrejp63el2MHiv6vD5dve5/Hy
897v3haY/Hf4CBMAYPoSAGj6EgAAAAAAePgSAAACAAAw+hIA24D7dxhE+Xf/////QPoSAFCa/Hdn
mvx3CgIAAID6EgAAAAAAAAATAAC4FQAAAAAAuPgSAIgGEwBs+RIA24D7d9CY+Hd4ARMAeAETAOyc
/HeoBxMACLgVAAAAAIgABAQAfPoSAAAEBAADAAAAAAAAAAAAAAAw+RIAXVnhd8BoVgABN/l3GAAA
AAAAAAAAAAAAWPkSACQAAADTQ/l3SA0TAAAAEwAkAAAA4FQTADD5EgAAAgAA6PoSANuA+3cYRPl3
//////j6EgAWmPx3SA0TAAAAAAAAAAAAqHNIAKD5EgAAAAAAmJj4dwAAEwBQbhcAAAAAAHz5EgCI
BhMAMPoSANuA+3fQmPh3/////0D6EgDsnPx32AcTAFhuFwBsbhcAWG4XAAEAAADQmPh3AwAAAAAA
AAAAAAgCDQAAALgAugBw1hMA33f4d5DR/HfEd/h32GATALhgEwBsbhcAAAAAAAAAAAA4+hIA24D7
d4h4+Hf/////SPoSAAAAEwAHAAAAAG4XAFhuFwABAAAAAWATABDQ/Hew+RIAgPoSAID6EgDbgPt3
iK74d/////+Q+hIAsI3odwAAEwAAAAAAAQAAAG1c4XcAAAAAAQAAAADg/X+wTBcAAAAAAFhuFwAA
AAAAKAEAAFT6EgAAAAAAsP8SAP0T6nfIjeh3/////4iu+HfcTUMAWG4XAAAAEwAAAAAAIAAAAKC8
cs/FIsIBAHgAbyQAAAAAPLZwq9nAAQAAAAAZAwAAAAATAA0AAABsb2dv4FQTACABAAAZuUAA3gII
AN4CCAA0+xIA24D7d3iu+Hf/////RPsSAH9J6XcAABMACAAUABgBAABtXOF3AAAAAAAAAAAAAAAA
AAAAAMTARAA5VRMAXMQVAD1VEwAFdEgA/////+BUEwAuwUQAOVUTACH5BAAAAAAALAAAAABaADoA
AAj+AAEIHEiwoMGDCBMqXMiwocOHECNKnEixosWLGDMuTNDAgcaPIAkyEGCgpAIGIVNeVFBSgMuS
KFXKfNiApMubLxXM3LmQJc6fBmLyHErwp1EDOokqdWC0qVKlDQw0xWngKdEEUqfetEpU60sBXId6
JSk0rEyvJROY3am1ZIO1M6NSLYnUI1yZPklKZfD27swCWff63dkgL9LBMhswYJmVpF3EH0fSpZr0
4IMFBxY8gOyQcdOglgmIHn1gM+eEeT+XFbhgtGvRC04fxIq2QEEHr3PLNphadcEDuV/H3j3QZtvK
AoO/PkC8+NjDA3ErJ91coPGp0AVKn06AeXUGjT/+9x0InLv35g5afkbOmjsB09/D34R50H11keq/
riZYfvn9goXRlZ0DBYw3UGuuDfefQQ0YCAACAQSA0AMPPLZgQxBK+BECA3Q4AAIIcRjAAA4KJOIA
thnkwAAjpqhihyAOVECEHboIQAEdqiVQAh5+iBCLEdJoUIZBMhhkhDYKBGSEMRLkQJADPEZkAAhI
GeF4DRwZoY4ELRlkklpSWZCXEY4ZJpcCHTkAQTMG2eSNET6WpZZrKsRindpt+WCZ0emZoYFIpjki
QRkeVKhBbVrIJp8J3UnQnGoduuOVewZgY6AACDmQpIQyumgAisroKaEejignpRziCcCTlt5YI0H+
TBaQoaqciqphQYnimuqoStJZkKYqBurAsL+GSSuvlR6Uq3ZT8kokkFHCemSSrCYpra+bIlurQMsK
OmKRZmroaKdHGlhtQjQioC4CNm4L562fPlYtgbwC2Wu0Too4aJ+tIoTpqgW56263CQS6rb0AjLtj
h73Cey6OJEobI7HkGooswQbXy+edj7VpG6fnZnipmAXva+LFKIM6UMkfayyuyQCU7BHIcVYKaL/A
JjtkyvJS2ubOVJ5oYboKC/ohkGimm+GbAvMs7dG8zqlmsUe+mXCYAWNdMaJOD0QmvDKSievUt6lp
7ZIoZg221yobxKKBDYh9kEfDhipQAwXYvSMcAiWuzG6oDiSAJq565z33sINfqPjijDfu+OMBAQA7

------=_NextPart_000_0046_01C2C6C9.3F8CBF70--



Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h0S7Kbf15999 for ietf-pkix-bks; Mon, 27 Jan 2003 23:20:37 -0800 (PST)
Received: from maild.telia.com (maild.telia.com [194.22.190.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h0S7KZo15995 for <[e-mail]>; Mon, 27 Jan 2003 23:20:35 -0800 (PST)
Received: from arport (h220n2fls31o1122.telia.com [212.181.142.220]) by maild.telia.com (8.12.5/8.12.5) with SMTP id h0S7KVFH027370; Tue, 28 Jan 2003 08:20:31 +0100 (CET)
X-Original-Recipient: [e-mail]
Message-ID: <001601c2c69d$63e93c30$0500a8c0@arport>
From: "Anders Rundgren" <[e-mail]>
To: "Peter Gutmann" <[e-mail]>
Cc: <[e-mail]>
References: <[e-mail]>
Subject: Re: Lookup from DNS was: X.500, LDAP Considered harmful
Date: Tue, 28 Jan 2003 08:18:00 +0100
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.50.4133.2400
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Peter,
Although I don't know all the details concerning the SRV-records,
I think it is a mistake not to support this in a draft intended for
the future.  Phill and XKMS-gang have no such hesitations
at least, although they really want a NAPTR that does SRV+TXT
in one bite.

Anders

----- Original Message ----- 
From: "Peter Gutmann" <[e-mail]>
To: <[e-mail]>; <[e-mail]>
Cc: <[e-mail]>; <[e-mail]>
Sent: Tuesday, January 28, 2003 03:08
Subject: Re: Lookup from DNS was: X.500, LDAP Considered harmful


"Anders Rundgren" <[e-mail]> writes:

>Note: This is not a part of the HTTP CertStore draft, but it could be :-)

It wouldn't help any:

  Another possible alternative is the use of DNS SRV records [36].
  Unfortunately the operating system used by the user group most desperately
  in need of handholding when it comes to technical issues has no support for
  anything beyond the most basic DNS address lookups, making it impossible to
  use DNS SRV with anything but very recent Win2K and XP systems. To make
  things even more entertaining, several of the function names and some of the
  function parameters changed at various times during the Win2K phase of
  development, and the behaviour of portions of the Windows sockets API
  changed in undocumented ways to match. This leads to the unfortunate
  situation in which a Unix sysadmin can make use of DNS SRV to avoid having
  to deal with technical configuration issues, but a Windows .95 user can .t.
  As a result, we can .t usefully rely on SRV for our needs.

The "well-known location" thing was an attemp to work around this problem.

Peter.



Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h0S4jNd07902 for ietf-pkix-bks; Mon, 27 Jan 2003 20:45:23 -0800 (PST)
Received: from ocasey.baltimore.com (ocasey.baltimore.com [193.41.17.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h0S4jMo07898 for <[e-mail]>; Mon, 27 Jan 2003 20:45:22 -0800 (PST)
Received: from Baltimore-FW1 ([172.19.1.1]) by ocasey.baltimore.com (8.11.6/8.9.3) with SMTP id h0S4YqA29444 for <[e-mail]>; Tue, 28 Jan 2003 04:34:52 GMT
Received: from  ([10.153.25.53]) by Baltimore-FW1; Tue, 28 Jan 2003 04:41:50 +0000 (GMT)
Received: from Baltimore-FW1 (wilde-i-1.ie.baltimore.com) by emeairlsw1.baltimore.com (Content Technologies SMTPRS 4.2.5) with SMTP id <[e-mail]> for <[e-mail]>; Tue, 28 Jan 2003 04:36:45 +0000
Received: from  ([10.153.25.10]) by Baltimore-FW1; Tue, 28 Jan 2003 04:41:48 +0000 (GMT)
Received: from emeairlbh1.ie.baltimore.com (emeairlbh1.ie.baltimore.com [10.153.25.54]) by bobcat.baltimore.ie (8.9.3/8.9.3) with ESMTP id EAA30305 for <[e-mail]>; Tue, 28 Jan 2003 04:45:22 GMT
Received: by emeairlbh1.ie.baltimore.com with Internet Mail Service (5.5.2653.19) id <49PDPAW2>; Tue, 28 Jan 2003 04:52:33 -0000
Message-ID: <[e-mail]>
From: Tom Biskupic <[e-mail]>
To: "'[e-mail]'" <[e-mail]>
Subject: STRAWPOLL:OCSP
Date: Tue, 28 Jan 2003 04:40:55 -0000
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain; charset="iso-8859-1"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

-----------------------------------------------------------------------------
The information contained in this message is confidential and is intended
for the addressee(s) only.  If you have received this message in error or
there are any problems please notify the originator immediately.  The 
unauthorised use, disclosure, copying or alteration of this message is 
strictly forbidden. Baltimore Technologies plc will not be liable for
direct, special, indirect or consequential damages arising from alteration
of the contents of this message by a third party or as a result of any 
virus being passed on.

This footnote confirms that this email message has been swept for Content
Security threats, including computer viruses.
http://www.baltimore.com



Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h0S4Qbj07580 for ietf-pkix-bks; Mon, 27 Jan 2003 20:26:37 -0800 (PST)
Received: from mx-s0.dreamwiz.com (mx-s0.dreamwiz.com [211.39.128.135]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h0S4QZo07576 for <[e-mail]>; Mon, 27 Jan 2003 20:26:36 -0800 (PST)
Received: from smtp0.dreamwiz.com (smtp0.dreamwiz.com [211.39.128.144]) by mx-s0.dreamwiz.com (8.12.5/8.12.5) with ESMTP id h0S4QT8h082270 for <[e-mail]>; Tue, 28 Jan 2003 13:26:34 +0900 (KST)
Received: from foreverkhopri ([211.252.151.23]) (authenticated bits=0) by smtp0.dreamwiz.com (8.12.5/8.12.5) with ESMTP id h0S4QNVr026143 for <[e-mail]>; Tue, 28 Jan 2003 13:26:29 +0900 (KST)
From: "Jong-Wook, Park" <[e-mail]>
To: <[e-mail]>
Subject: STRAWPOLL:SCVP
Date: Tue, 28 Jan 2003 13:26:24 +0900
Message-ID: <002e01c2c685$6f3d8d10$aa0310ac@foreverkhopri>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook, Build 10.0.3416
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000
Importance: Normal
X-DreamWiz-Peer-IP: 211.252.151.23
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Park, Jong-Wook

Korea Information Security Agency
Korea Certification Authority Central

4th FL., IT-Venture Tower B/D, 78, Garak-Dong, Songpa-Gu, Seoul, Korea
138-803
Tel : [phone]  
Fax : [phone]
Mobile : [phone]
E-mail : [e-mail] or [e-mail] 

Visit http://www.kisa.or.kr or http://www.rootca.or.kr for more info. 

Always Thanks !



Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h0S46Vh07092 for ietf-pkix-bks; Mon, 27 Jan 2003 20:06:31 -0800 (PST)
Received: from hermes.cs.auckland.ac.nz (hermes.cs.auckland.ac.nz [130.216.35.151]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h0S46To07088 for <[e-mail]>; Mon, 27 Jan 2003 20:06:30 -0800 (PST)
Received: from medusa01.cs.auckland.ac.nz (medusa01.cs.auckland.ac.nz [130.216.34.60]) by hermes.cs.auckland.ac.nz (8.12.4/8.12.4) with ESMTP id h0S46ROr021594; Tue, 28 Jan 2003 17:06:27 +1300
Received: (from pgut001@localhost) by medusa01.cs.auckland.ac.nz (8.11.6/8.11.6) id h0S47g020915; Tue, 28 Jan 2003 17:07:42 +1300
Date: Tue, 28 Jan 2003 17:07:42 +1300
Message-Id: <[e-mail]>
From: [e-mail] (Peter Gutmann)
To: [e-mail], [e-mail]
Subject: Re: CERTSTORE's 160 bit limit + PI
Cc: [e-mail]
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

[CCd back to the list in case other people have comments on this]

"Anders Rundgren" <[e-mail]> writes:

>Maybe it could be an idea to have a paragraph saying this obvious [:-)]
>thing.   Particularly since you impose so strict restrictions on the binary
>items.

Done:

  Further details of URI construction, size limits, and other details are
  given in [RFC2068].

>May I propose an additional textual attribute? "pi" A permanent identifier.
>There is quite a bunch of certificates that do not feature email addresses.
>Some 15 million only in Scandinavia.

Hmm, that's kind of a special-case identifier, and opens the door to everyone
wanting to have their own pet value included in the draft.  How about allowing
a private namespace starting with 'x-', or something similar?  This has been
done before with users who wanted special-case IDs, for example one COI-based
PKI which needed to look up certs by healthcare ID (the primary key in all of
their databases) did this.  It's a one-line addition to the interface code for
anyone who wants COI-specific IDs.  I'll include something in the
implementation notes section on this:

  In some cases users may require additional, application-specific attribute
  types.  For example, a healthcare application that uses a healthcare ID as
  the primary key for its databases may require the ability to perform
  certificate lookups based on this healthcare ID.  The formatting and use of
  such application-specific identifiers is beyond the scope of this document,
  however they should begin with 'x-' to ensure that they don't conflict with
  identifiers that may be defined in future versions of this specification.


Peter.


Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h0S27VR04672 for ietf-pkix-bks; Mon, 27 Jan 2003 18:07:31 -0800 (PST)
Received: from hermes.cs.auckland.ac.nz (hermes.cs.auckland.ac.nz [130.216.35.151]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h0S27To04668 for <[e-mail]>; Mon, 27 Jan 2003 18:07:29 -0800 (PST)
Received: from medusa01.cs.auckland.ac.nz (medusa01.cs.auckland.ac.nz [130.216.34.60]) by hermes.cs.auckland.ac.nz (8.12.4/8.12.4) with ESMTP id h0S27ROr019514; Tue, 28 Jan 2003 15:07:27 +1300
Received: (from pgut001@localhost) by medusa01.cs.auckland.ac.nz (8.11.6/8.11.6) id h0S28eD16042; Tue, 28 Jan 2003 15:08:40 +1300
Date: Tue, 28 Jan 2003 15:08:40 +1300
Message-Id: <[e-mail]>
From: [e-mail] (Peter Gutmann)
To: [e-mail], [e-mail]
Subject: Re: Lookup from DNS was: X.500, LDAP Considered harmful
Cc: [e-mail], [e-mail]
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

"Anders Rundgren" <[e-mail]> writes:

>Note: This is not a part of the HTTP CertStore draft, but it could be :-)

It wouldn't help any:

  Another possible alternative is the use of DNS SRV records [36].
  Unfortunately the operating system used by the user group most desperately
  in need of handholding when it comes to technical issues has no support for
  anything beyond the most basic DNS address lookups, making it impossible to
  use DNS SRV with anything but very recent Win2K and XP systems. To make
  things even more entertaining, several of the function names and some of the
  function parameters changed at various times during the Win2K phase of
  development, and the behaviour of portions of the Windows sockets API
  changed in undocumented ways to match. This leads to the unfortunate
  situation in which a Unix sysadmin can make use of DNS SRV to avoid having
  to deal with technical configuration issues, but a Windows .95 user can .t.
  As a result, we can .t usefully rely on SRV for our needs.

The "well-known location" thing was an attemp to work around this problem.

Peter.


Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h0S0Z2E03188 for ietf-pkix-bks; Mon, 27 Jan 2003 16:35:02 -0800 (PST)
Received: from nb2.stroeder.com (krl9-d9bb4eef.pool.mediaWays.net [217.187.78.239]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h0S0Z0o03183 for <[e-mail]>; Mon, 27 Jan 2003 16:35:00 -0800 (PST)
Received: from localhost (localhost.stroeder.com [127.0.0.1]) by nb2.stroeder.com (Postfix) with ESMTP id B78E940363; Tue, 28 Jan 2003 01:34:12 +0100 (CET)
Received: from stroeder.com (localhost.stroeder.com [127.0.0.1]) by nb2.stroeder.com (Postfix) with ESMTP id 133D43C9C4; Tue, 28 Jan 2003 01:34:12 +0100 (CET)
Message-ID: <[e-mail]>
Date: Tue, 28 Jan 2003 01:34:11 +0100
From: =?ISO-8859-1?Q?Michael_Str=F6der?= <[e-mail]>
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.2.1) Gecko/20021130
X-Accept-Language: de-de, de, en-us, en
MIME-Version: 1.0
To: Peter Gutmann <[e-mail]>
Cc: [e-mail]
Subject: Re: X.500, LDAP Considered harmful Was: OCSP/LDAP
References: <[e-mail]>
In-Reply-To: <[e-mail]>
X-Enigmail-Version: 0.71.0.0
X-Enigmail-Supports: pgp-inline, pgp-mime
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
X-Virus-Scanned: by AMaViS 0.3.12pre8
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Peter Gutmann wrote:
>>
>>ldap://host.domain/o=foo?userCertificate?sub?(key=bar)
> 
> Thankyou Michael, you've just agreed with me by expressing the exact
> {key,value} lookup I described as an LDAP query

Well, is that really news to you?

> (rather than the usual
> hierarchical filter that you're supposed to use with LDAP).

???

> LDAP is that half the time the LDAP admin has it turned
> off
> because the whole directory grinds to a halt if you run more than one
> global query at a time.

It seems brain-dead sys admins are maintaining your or your customer's 
systems. With misconfigured servers and/or implementing misbehaving 
applications you can grind any system to a halt, no matter which technology.

> Two points to note:
> 
> - LDAP is never used in this way.  It's always used with extraordinarily
>   complex filters that no normal human can figure out.

I don't know how the directories and applications you are working with look 
like. But in the scenarios I know most filters are pretty simple, except the 
ones produced by some strange PKI products of leading vendors.

>  When I was documenting
>   use of LDAP in the cryptlib manual, I went around a variety of CAs (the ones
>   that publish the filters you need to use on their web pages), and also asked
>   users for contributions - I wanted to include some examples that people
>   could cut and paste.

I think your fault was to ask PKI people instead asking directory people. 
Usually PKI people tend to make things even more complicated than directory 
people... ;-)

>   This is real-world experience talking here folks, from a worldwide user
>   base: {key,value} lookup works with zero problems, LDAP has endless
>   problems.

Simply not true. You're working with the wrong directory people I guess.

> I know I'm in very good company - [..] Larry
> Ellison [..] multimillion-dollar sailing yacht

Uumh, yeah! That beats me, I give up here admitting that I can't fight your 
strong arguments...

Ciao, Michael.



Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h0RKvPe27920 for ietf-pkix-bks; Mon, 27 Jan 2003 12:57:25 -0800 (PST)
Received: from brutesquadlabs.com (gtec136-m.isomedia.com [207.115.67.136] (may be forged)) by above.proper.com (8.11.6/8.11.3) with ESMTP id h0RKvNo27916 for <[e-mail]>; Mon, 27 Jan 2003 12:57:23 -0800 (PST)
Received: from DEXTER ([192.168.0.4]) by brutesquadlabs.com with ESMTP ; Mon, 27 Jan 2003 12:57:20 -0800
From: "Blake Ramsdell" <[e-mail]>
To: "=?iso-8859-1?Q?'Michael_Str=F6der'?=" <[e-mail]>, "'Hallam-Baker, Phillip'" <[e-mail]>
Cc: <[e-mail]>
Subject: RE: X.500, LDAP Considered harmful Was: OCSP/LDAP
Date: Mon, 27 Jan 2003 12:57:20 -0800
Message-ID: <!~!UENERkVCMDkAAQACAAAAAAAAAAAAAAAAABgAAAAAAAAARMPfbnbp50SwK3EZjypY2MKAAAAQAAAAkgeei6BDo02rIrCJtLI/[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook, Build 10.0.2627
In-reply-to: <[e-mail]>
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106
Importance: Normal
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id h0RKvNo27917
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

> -----Original Message-----
> From: [e-mail] 
> [mailto:[e-mail]] On Behalf Of Michael Ströder
> Sent: Monday, January 27, 2003 8:29 AM
> To: Hallam-Baker, Phillip
> Cc: [e-mail]
> Subject: Re: X.500, LDAP Considered harmful Was: OCSP/LDAP
> 
> Hallam-Baker, Phillip wrote:
> > 
> > They have got their fangs into PKI because they believe
> > that we are their killer application.
> 
> Uuh, anyone here still believe that PKI is a killer application?

Isn't this year the "year of PKI"?  It has been for the last five or
six, I seem to remember ;).

Blake



Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h0RHUDl21573 for ietf-pkix-bks; Mon, 27 Jan 2003 09:30:13 -0800 (PST)
Received: from maile.telia.com (maile.telia.com [194.22.190.16]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h0RHUCo21569 for <[e-mail]>; Mon, 27 Jan 2003 09:30:12 -0800 (PST)
Received: from arport (h220n2fls31o1122.telia.com [212.181.142.220]) by maile.telia.com (8.12.5/8.12.5) with SMTP id h0RHUDPj025732; Mon, 27 Jan 2003 18:30:13 +0100 (CET)
X-Original-Recipient: [e-mail]
Message-ID: <033e01c2c629$66f7a660$0500a8c0@arport>
From: "Anders Rundgren" <[e-mail]>
To: =?iso-8859-1?Q?Michael_Str=F6der?= <[e-mail]>, "Hallam-Baker, Phillip" <[e-mail]>
Cc: <[e-mail]>
References: <[e-mail]> <[e-mail]>
Subject: Re: X.500, LDAP Considered harmful Was: OCSP/LDAP
Date: Mon, 27 Jan 2003 18:27:44 +0100
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.50.4133.2400
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

>> They have got their fangs into PKI because they believe
>> that we are their killer application.

>Uuh, anyone here still believe that PKI is a killer application?

I believe PKI as a "killer application" has made a lot of people think
that PKI in some way stands above information systems.  This has
lead to very flawed uses of PKI, essentially only suitable for sending
signed and encryption mail between individuals.

When PKI finally is "degraded" to securing communication
in and between information systems, PKI will be a
"killer technology" at least.

For that to happen with must get rid of employee certificates which
is a monstrosity from an information-management point of view.
How much is that company badge of yours worth outside of
the company walls?  Rather little I assume.  But how come it
ever got "PKI-fied"?

Anders R



Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h0RGZ2x18029 for ietf-pkix-bks; Mon, 27 Jan 2003 08:35:02 -0800 (PST)
Received: from peacock.verisign.com (peacock.verisign.com [65.205.251.73]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h0RGZ1o18025 for <[e-mail]>; Mon, 27 Jan 2003 08:35:01 -0800 (PST)
Received: from vhqpostal-gw2.verisign.com (verisign.com [65.205.251.56]) by peacock.verisign.com (8.12.1/) with ESMTP id h0RGYSq4006910; Mon, 27 Jan 2003 08:34:28 -0800 (PST)
Received: by vhqpostal-gw2.verisign.com with Internet Mail Service (5.5.2653.19) id <DQTLHBLD>; Mon, 27 Jan 2003 08:35:02 -0800
Message-ID: <[e-mail]>
From: "Hallam-Baker, Phillip" <[e-mail]>
To: =?iso-8859-1?Q?=27Michael_Str=F6der=27?= <[e-mail]>, "Hallam-Baker, Phillip" <[e-mail]>
Cc: [e-mail]
Subject: RE: X.500, LDAP Considered harmful Was: OCSP/LDAP
Date: Mon, 27 Jan 2003 08:35:01 -0800
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
MIME-Version: 1.0
Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_0038_01C2C5F8.20DF94C0"
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

This is a multi-part message in MIME format.

------=_NextPart_000_0038_01C2C5F8.20DF94C0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

It will be once we drive a steak through the heart of
the Directory vampires.

	Phill

> -----Original Message-----
> From: Michael Str=F6der [mailto:[e-mail]]
> Sent: Monday, January 27, 2003 11:29 AM
> To: Hallam-Baker, Phillip
> Cc: [e-mail]
> Subject: Re: X.500, LDAP Considered harmful Was: OCSP/LDAP
>=20
>=20
> Hallam-Baker, Phillip wrote:
> >=20
> > They have got their fangs into PKI because they believe
> > that we are their killer application.
>=20
> Uuh, anyone here still believe that PKI is a killer application?
>=20
> Ciao, Michael.
>=20

------=_NextPart_000_0038_01C2C5F8.20DF94C0
Content-Type: application/x-pkcs7-signature;
	name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment;
	filename="smime.p7s"

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINbTCCAj0w
ggGmAhEAulrJTAU7ktantt9O0FOSDTANBgkqhkiG9w0BAQIFADBfMQswCQYDVQQGEwJVUzEXMBUG
A1UEChMOVmVyaVNpZ24sIEluYy4xNzA1BgNVBAsTLkNsYXNzIDIgUHVibGljIFByaW1hcnkgQ2Vy
dGlmaWNhdGlvbiBBdXRob3JpdHkwHhcNOTYwMTI5MDAwMDAwWhcNMDQwMTA3MjM1OTU5WjBfMQsw
CQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xNzA1BgNVBAsTLkNsYXNzIDIgUHVi
bGljIFByaW1hcnkgQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkwgZ8wDQYJKoZIhvcNAQEBBQADgY0A
MIGJAoGBALZai6MNaiODgGvPOYf0IRMzBkwlou1VEpfFp4C5+oPBIKD6LxUNfKFga355LPoGDzqu
9htvsdL/LyhSX4N9S8R6t/hmH4BU/LfCjllKFFdG0ZqTvkGRA7sVgJNc6+fMCGw/PrNK/P9LbCPV
UIImRBmOI8Nx6hkkRwSedb/IpgAfAgMBAAEwDQYJKoZIhvcNAQECBQADgYEAtgAfk1ekB6dAzmVA
P1Ve7e/6VEmlMNYhfGGH7oOTC7+0M/KYrJ8Gv06ozhSBTMsETljDz1/ufNeab8tBird/gbj/hGHG
J0NlHQzssQAK3Ruku8d4ICiyot02lS7hVE+/YLl3aBGZI+jqUuiqAE5nTruQtUWbRuuOFu/EM1sz
PdUwggNDMIICrKADAgECAhAffl/nA9Hgv5kg3GuJDUsEMA0GCSqGSIb3DQEBBAUAMF8xCzAJBgNV
BAYTAlVTMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjE3MDUGA1UECxMuQ2xhc3MgMiBQdWJsaWMg
UHJpbWFyeSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTAeFw05OTAyMjUwMDAwMDBaFw0wNDAxMDUy
MzU5NTlaMIGtMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1
c3QgTmV0d29yazFJMEcGA1UECxNAVXNlIGlzIHN1YmplY3QgdG8gdGVybXMgYXQgaHR0cHM6Ly93
d3cudmVyaXNpZ24uY29tL3JwYS1rciAoYyk5OTEmMCQGA1UEAxMdVmVyaVNpZ24gQ2xhc3MgMiBQ
ZXJzb25uZWwgQ0EwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBAKcEbA+icrdKBi741yksNJ2C
vEiRSses+en8uVl4sVXAU1ixz28WO8FJ1cv0bszhzMu1xy5OiKo06bbQW3w+FVc04Ri8/931r2dZ
IArlPeqIikDSmokTKam21dunfuHnNyST/ZR0TXrkMm1M6FwWl6/dktlmihRm5OpaA6g9X/sLAgMB
AAGjgbAwga0wMQYDVR0fBCowKDAmoCSgIoYgaHR0cDovL2NybC52ZXJpc2lnbi5jb20vcGNhMi5j
cmwwEQYJYIZIAYb4QgEBBAQDAgEGMEcGA1UdIARAMD4wPAYLYIZIAYb4RQEHAQEwLTArBggrBgEF
BQcCARYfaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYS1rcjAPBgNVHRMECDAGAQH/AgEBMAsG
A1UdDwQEAwIBBjANBgkqhkiG9w0BAQQFAAOBgQB59xXN6GhRWWv8qaa94B77vPQ/kN/n+u3kVPdh
PVSLBrqXMloeqyzur3Orx13TP4/0zstOSGCiqGC2ON6gpvePKegRrMw5dlA83TlsC/Fa/QhUdt0W
bPcxcLi/CPfJJgaO37svGbG2uLToPEjoJ7GXKSBXA5ybZ/p9QMQ4fxiqmjCCA8QwggMtoAMCAQIC
EQCEzvIOADm1dVXaGYePUu2JMA0GCSqGSIb3DQEBBAUAMIGtMRcwFQYDVQQKEw5WZXJpU2lnbiwg
SW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFJMEcGA1UECxNAVXNlIGlzIHN1
YmplY3QgdG8gdGVybXMgYXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYS1rciAoYyk5OTEm
MCQGA1UEAxMdVmVyaVNpZ24gQ2xhc3MgMiBQZXJzb25uZWwgQ0EwHhcNOTkwMjI1MDAwMDAwWhcN
MDQwMTA0MjM1OTU5WjCBrDEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlT
aWduIFRydXN0IE5ldHdvcmsxSTBHBgNVBAsTQFVzZSBpcyBzdWJqZWN0IHRvIHRlcm1zIGF0IGh0
dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9ycGEta3IgKGMpOTkxJTAjBgNVBAMTHFZlcmlTaWduIENs
YXNzIDIgRW1wbG95ZWUgQ0EwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBAMCK0YdhouowA1Vr
CDbwl/oaVDUkH+h9ncjDc9PYRvWRLdk47ZTXsCZzKt6XUE3/Ihy9cACYDFgqsaRyj6W59y18YOO1
3+l9TiEhYdX8O1TJpAmcuyL5orpwYU+GRqL9BWTsCj+mWHZXuxZzRHzwpQ2XwGym8WMIJbEEF5Wg
jf5/AgMBAAGjgeIwgd8wKQYDVR0RBCIwIKQeMBwxGjAYBgNVBAMTEVByaXZhdGVMYWJlbDEtMTE4
MDgGA1UdHwQxMC8wLaAroCmGJ2h0dHA6Ly9jcmwudmVyaXNpZ24uY29tL1ZTQ2xhc3MySW50LmNy
bDARBglghkgBhvhCAQEEBAMCAQYwRwYDVR0gBEAwPjA8BgtghkgBhvhFAQcBATAtMCsGCCsGAQUF
BwIBFh9odHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBhLWtyMA8GA1UdEwQIMAYBAf8CAQAwCwYD
VR0PBAQDAgEGMA0GCSqGSIb3DQEBBAUAA4GBABlGztRrcI5YXIhCNa0WfaUJLKhTkPH2PYbX8M5y
FD0ivPLDM+3U/AWa4GMgdaMb71UZDwZzIQJhrqaeUSt43FvIhIvV17bP1fg+l5ixRIujmI6gS/aY
MZOz8AzdUXbKl+RWRMb7lKFIfSJDzKDGXHlV9WeBG2iYNCREsZjBOiheMIIEGTCCA4KgAwIBAgIQ
da9pAn9XoMlLtvoUDq8LyTANBgkqhkiG9w0BAQQFADCBrDEXMBUGA1UEChMOVmVyaVNpZ24sIElu
Yy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0IE5ldHdvcmsxSTBHBgNVBAsTQFVzZSBpcyBzdWJq
ZWN0IHRvIHRlcm1zIGF0IGh0dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9ycGEta3IgKGMpOTkxJTAj
BgNVBAMTHFZlcmlTaWduIENsYXNzIDIgRW1wbG95ZWUgQ0EwHhcNMDIwMjI3MDAwMDAwWhcNMDMw
MjI3MjM1OTU5WjBtMREwDwYDVQQKEwhWRVJJU0lHTjELMAkGA1UECxMCSFExEzARBgNVBAMTClJl
Y2lwaWVudHMxNjA0BgNVBAMTLXBiYWtlciAoSGFsbGFtLUJha2VyIFBoaWxsaXAsIFZlcmlTaWdu
LCBJbmMuKTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAtcA/okLsFi9brjmDsXQ6+g+R95B1
81Lq1EXkdzhY7XHxQ2QDq0sS2U4j9N1Ic6nHIiMq5dticztWpKdn6CrDx3Ovd5k+PACq/jSQo7NL
tlMJi7fsUrP7pM4izKu4JjSak6wRJUA4x85TSC1PLfd1u8oq16iqNJRhpEJ8VJUMRyECAwEAAaOC
AXgwggF0MAkGA1UdEwQCMAAwWQYDVR0fBFIwUDBOoEygSoZIaHR0cDovL29uc2l0ZWNybC52ZXJp
c2lnbi5jb20vVmVyaVNpZ25JbmNFeGNoYW5nZUVtcGxveWVlcy9MYXRlc3RDUkwuY3JsMAsGA1Ud
DwQEAwIFoDAeBgNVHREEFzAVgRNwYmFrZXJAdmVyaXNpZ24uY29tMIGsBgNVHSAEgaQwgaEwgZ4G
C2CGSAGG+EUBBwEBMIGOMCgGCCsGAQUFBwIBFhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vQ1BT
MGIGCCsGAQUFBwICMFYwFRYOVmVyaVNpZ24sIEluYy4wAwIBARo9VmVyaVNpZ24ncyBDUFMgaW5j
b3JwLiBieSByZWZlcmVuY2UgbGlhYi4gbHRkLiAoYyk5NyBWZXJpU2lnbjARBglghkgBhvhCAQEE
BAMCB4AwHQYDVR0lBBYwFAYIKwYBBQUHAwQGCCsGAQUFBwMCMA0GCSqGSIb3DQEBBAUAA4GBACCK
+gbdTcJB2wmWF5q8hbnP6slvVFehmjSX1Se+4Ff6a3Uiw8aOQLyNwnYUSOtHe12rTwAtWOhEgXHK
D4XY3tF7cofo5hM8dk8xsj9vV3z3fYARDr4nR2bZblPJ3MGmAFAYKW4pgX4Y6NU4VhAG2Hiuj18/
H4Cc5g5oqJp5dArUMYIC+DCCAvQCAQEwgcEwgawxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8w
HQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUkwRwYDVQQLE0BVc2UgaXMgc3ViamVjdCB0
byB0ZXJtcyBhdCBodHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBhLWtyIChjKTk5MSUwIwYDVQQD
ExxWZXJpU2lnbiBDbGFzcyAyIEVtcGxveWVlIENBAhB1r2kCf1egyUu2+hQOrwvJMAkGBSsOAwIa
BQCgggGMMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTAzMDEyNzE2
MzUwMVowIwYJKoZIhvcNAQkEMRYEFBN2fCx/FKlIkDOhc6GxSO2t8/98MFgGCSqGSIb3DQEJDzFL
MEkwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwICAgCAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMAcG
BSsOAwIaMAoGCCqGSIb3DQIFMIHSBgkrBgEEAYI3EAQxgcQwgcEwgawxFzAVBgNVBAoTDlZlcmlT
aWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUkwRwYDVQQLE0BVc2Ug
aXMgc3ViamVjdCB0byB0ZXJtcyBhdCBodHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBhLWtyIChj
KTk5MSUwIwYDVQQDExxWZXJpU2lnbiBDbGFzcyAyIEVtcGxveWVlIENBAhB1r2kCf1egyUu2+hQO
rwvJMA0GCSqGSIb3DQEBAQUABIGAJFOTaf8sYuxM1MKN1Rrpf2eX/OEgzZ5mvxgkrp2vEUpzCsfk
L/lY8sueZrRZcqr6yIPzea7J5m2yxaBiYDkGMD5Vczl/YEkU3zgSTtf90/kAO74vyRKFqaX+uPTU
b3K4hAZRZq13ZQ5wChQ4B7SfAah4Ww3YSNzZax/eUdo7lmEAAAAAAAA=

------=_NextPart_000_0038_01C2C5F8.20DF94C0--



Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h0RGTiv17821 for ietf-pkix-bks; Mon, 27 Jan 2003 08:29:44 -0800 (PST)
Received: from nb2.stroeder.com (krl9-d9bb4f93.pool.mediaWays.net [217.187.79.147]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h0RGTgo17813 for <[e-mail]>; Mon, 27 Jan 2003 08:29:42 -0800 (PST)
Received: from localhost (localhost.stroeder.com [127.0.0.1]) by nb2.stroeder.com (Postfix) with ESMTP id 004704DC13; Mon, 27 Jan 2003 17:29:01 +0100 (CET)
Received: from stroeder.com (localhost.stroeder.com [127.0.0.1]) by nb2.stroeder.com (Postfix) with ESMTP id 51FC34BD6A; Mon, 27 Jan 2003 17:29:00 +0100 (CET)
Message-ID: <[e-mail]>
Date: Mon, 27 Jan 2003 17:29:00 +0100
From: =?ISO-8859-1?Q?Michael_Str=F6der?= <[e-mail]>
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.2.1) Gecko/20021130
X-Accept-Language: de-de, de, en-us, en
MIME-Version: 1.0
To: "Hallam-Baker, Phillip" <[e-mail]>
Cc: [e-mail]
Subject: Re: X.500, LDAP Considered harmful Was: OCSP/LDAP
References: <[e-mail]>
In-Reply-To: <[e-mail]>
X-Enigmail-Version: 0.71.0.0
X-Enigmail-Supports: pgp-inline, pgp-mime
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
X-Virus-Scanned: by AMaViS 0.3.12pre8
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Hallam-Baker, Phillip wrote:
> 
> They have got their fangs into PKI because they believe
> that we are their killer application.

Uuh, anyone here still believe that PKI is a killer application?

Ciao, Michael.



Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h0RG3HS16554 for ietf-pkix-bks; Mon, 27 Jan 2003 08:03:17 -0800 (PST)
Received: from edelweb.fr (edelweb.fr [212.234.46.16]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h0RG3Go16550 for <[e-mail]>; Mon, 27 Jan 2003 08:03:16 -0800 (PST)
Received: from champagne.edelweb.fr (localhost.edelweb.fr [127.0.0.1]) by edelweb.fr with ESMTP id RAA10496; Mon, 27 Jan 2003 17:03:10 +0100 (MET)
Received: from champagne.edelweb.fr (champagne.edelweb.fr [193.51.14.161]) by edelweb.fr (nospam/1.6); Mon, 27 Jan 2003 17:03:10 +0100 (MET)
Received: (from sylvest@localhost) by champagne.edelweb.fr (8.7.6/8.6.6) id RAA03954; Mon, 27 Jan 2003 17:03:09 +0100 (MET)
Date: Mon, 27 Jan 2003 17:03:09 +0100 (MET)
From: Peter Sylvester <[e-mail]>
Message-Id: <[e-mail]>
To: [e-mail], [e-mail]
Subject: Re: Rating of the DVCS Compliance Matrix
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Without having made an update like an RFC 3029bis the score isn't
that bad and several points just need a textual clarifications.

An interesting comparision would be to compare OCSP and
SCVP drafts of about one year ago.  :-) 

Some examples for RFC 3029bis:


1   If the DPV server does not support the client requested validation
   policy, then the DPV server MUST return an error.

2   If the DPV request does not specify a validation policy, the server
   response MUST indicate the validation policy that was used.


   - The 'requestPolicy' field SHOULD indicate the policy under which
     the validation is requested.  This field MUST be checked by the
     DVCS to verify agreement with its own policy.  The absence of this
     field indicates that any policy is acceptable.

   - The 'DVCSCertInfo.policy' field indicates the policy under which
     the DVCS operates.

 
The missing point in 3029 is that when the field is not accepted, 
the server returns an error    unacceptedPolicy    (15),
which is defined as in 3161 and CMPbis but was not available
at the time when the RFC was written. 

     -- the requested TSA policy is not supported by the TSA
 
> Point 2. Since policy is optional in the response, the "MUST" requirement is 
> not met.

the policy is optional in the response, since there is no requirement
to always return it. 

The requirement in 3379 allows that the field is optional both in the
request and the response. 

In 3029 there is a syntactical possibility that no policy is exchanged
at all. I'm happy to remedy this by adding a statement like
'The server SHOULD set the 'DVCSCertInfo.policy' field if the client
has not specified it in the request.' A SHOULD because there may be
very special cases where a client an a server agree on *THE*
policy, they simply don't need anything at all. 

  
> Point 19. Relaying is supported through embedded signed responses which 
> overload the client. So the requirement is not met.

The additional information provided is identical to the
information of the general structure. Thus, there is not an
additional burden of code, a client can also ignore this, and
just react to the status; a policy may still decide not to
return the information. 

> 
> Point 20. There are no explanations about how to detect loops. The 
> requirement is not met.
Well, indeed, it seems that the texts needs more clarification. The
examples in the description of 'requester' is not obvious. Since

I was at the origin of that requirement, here a text:  

- Each relay adds its own id and checks incoming requests for 
  its own name AND whether an outgoing request goes to one already in the list. 

- This general idea MAY have exceptions, e.g., when a relay does not
  want to indicate the identity of its client to another server
  it may remove the incoming value before relaying.  




Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h0RFstr16330 for ietf-pkix-bks; Mon, 27 Jan 2003 07:54:55 -0800 (PST)
Received: from peacock.verisign.com (peacock.verisign.com [65.205.251.73]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h0RFsso16326 for <[e-mail]>; Mon, 27 Jan 2003 07:54:54 -0800 (PST)
Received: from vhqpostal-gw2.verisign.com (verisign.com [65.205.251.56]) by peacock.verisign.com (8.12.1/) with ESMTP id h0RFsJq4028069; Mon, 27 Jan 2003 07:54:20 -0800 (PST)
Received: by vhqpostal-gw2.verisign.com with Internet Mail Service (5.5.2653.19) id <DQTLG7VC>; Mon, 27 Jan 2003 07:54:53 -0800
Message-ID: <[e-mail]>
From: "Hallam-Baker, Phillip" <[e-mail]>
To: "'Dean Povey'" <[e-mail]>, "Hallam-Baker, Phillip" <[e-mail]>
Cc: Tony Bartoletti <[e-mail]>, [e-mail], [e-mail], [e-mail], [e-mail], [e-mail]
Subject: RE: X.500, LDAP Considered harmful Was: OCSP/LDAP 
Date: Mon, 27 Jan 2003 07:54:49 -0800
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
MIME-Version: 1.0
Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_001D_01C2C5F2.834B41A0"
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

This is a multi-part message in MIME format.

------=_NextPart_000_001D_01C2C5F2.834B41A0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit

> >What is needed is an infrastructure that is linked to the DNS
> >system, a DNS linked PKI. The lookups supported should be in the
> >terms the applications care about. For example the UseKeyWith
> >semantics of XKMS. Similar semantics will no doubt be proposed
> >for supported by the PKIX equivalent DPV specification.
> >
> 
> While I don't disagree with your argument about X.500, there are real 
> practical problems with using DNS for storing Certificates 
> (if that is 
> indeed what you mean by a DNS linked PKI).  

Yes, that is why I have been arguing that the certificates 
should be stored in an XKMS repository that is linked to
the DNS and not in the DNS itself.

If you want to restrict yourself to the PKIX world you could
link a DPD/DPV server to the DNS in the same way, with a few
minimal changes to the protocol.


> RFC2538 
> notwithstanding, the 
> problem is that storing large objects like Certificates in 
> DNS generally 
> necessitates TCP transfers as they will exceed the magic 512 
> byte limit 
> at which servers will generally truncate packets. 

Actually that no longer holds with EDNS, but you still don't
want to join DNS and PKI at the hip except possibly for the case
of IPSEC keys.

Trying to make DNS work like a PKI has the same problem as
trying to work in the X.500 straightjacket. You have to deal
with lots of legacy stuff that does nothing but get in the 
way.

People go on and on about not re-inventing the wheel. However 
the problems of trying to re-use technology in inappropriate 
contexts causes far more harm in the long run. PKI has failled
to get value out of X.500 and LDAP for ten years, the answer
to this problem is not to go running off to misuse DNS in the
same way.

The SRV link does the job nicely.

> That said, I think the problem is largely solved by storing 
> certs on a 
> HTTP server, indexed on some interesting attributes that can 
> be specified 
> using standard HTTP GET uri?attr=value syntax.

This is almost what XKMS does. The one slight difference being
that we use XML and SOAP rather than the query syntax.


		Phill


------=_NextPart_000_001D_01C2C5F2.834B41A0
Content-Type: application/x-pkcs7-signature;
	name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment;
	filename="smime.p7s"

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINbTCCAj0w
ggGmAhEAulrJTAU7ktantt9O0FOSDTANBgkqhkiG9w0BAQIFADBfMQswCQYDVQQGEwJVUzEXMBUG
A1UEChMOVmVyaVNpZ24sIEluYy4xNzA1BgNVBAsTLkNsYXNzIDIgUHVibGljIFByaW1hcnkgQ2Vy
dGlmaWNhdGlvbiBBdXRob3JpdHkwHhcNOTYwMTI5MDAwMDAwWhcNMDQwMTA3MjM1OTU5WjBfMQsw
CQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xNzA1BgNVBAsTLkNsYXNzIDIgUHVi
bGljIFByaW1hcnkgQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkwgZ8wDQYJKoZIhvcNAQEBBQADgY0A
MIGJAoGBALZai6MNaiODgGvPOYf0IRMzBkwlou1VEpfFp4C5+oPBIKD6LxUNfKFga355LPoGDzqu
9htvsdL/LyhSX4N9S8R6t/hmH4BU/LfCjllKFFdG0ZqTvkGRA7sVgJNc6+fMCGw/PrNK/P9LbCPV
UIImRBmOI8Nx6hkkRwSedb/IpgAfAgMBAAEwDQYJKoZIhvcNAQECBQADgYEAtgAfk1ekB6dAzmVA
P1Ve7e/6VEmlMNYhfGGH7oOTC7+0M/KYrJ8Gv06ozhSBTMsETljDz1/ufNeab8tBird/gbj/hGHG
J0NlHQzssQAK3Ruku8d4ICiyot02lS7hVE+/YLl3aBGZI+jqUuiqAE5nTruQtUWbRuuOFu/EM1sz
PdUwggNDMIICrKADAgECAhAffl/nA9Hgv5kg3GuJDUsEMA0GCSqGSIb3DQEBBAUAMF8xCzAJBgNV
BAYTAlVTMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjE3MDUGA1UECxMuQ2xhc3MgMiBQdWJsaWMg
UHJpbWFyeSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTAeFw05OTAyMjUwMDAwMDBaFw0wNDAxMDUy
MzU5NTlaMIGtMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1
c3QgTmV0d29yazFJMEcGA1UECxNAVXNlIGlzIHN1YmplY3QgdG8gdGVybXMgYXQgaHR0cHM6Ly93
d3cudmVyaXNpZ24uY29tL3JwYS1rciAoYyk5OTEmMCQGA1UEAxMdVmVyaVNpZ24gQ2xhc3MgMiBQ
ZXJzb25uZWwgQ0EwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBAKcEbA+icrdKBi741yksNJ2C
vEiRSses+en8uVl4sVXAU1ixz28WO8FJ1cv0bszhzMu1xy5OiKo06bbQW3w+FVc04Ri8/931r2dZ
IArlPeqIikDSmokTKam21dunfuHnNyST/ZR0TXrkMm1M6FwWl6/dktlmihRm5OpaA6g9X/sLAgMB
AAGjgbAwga0wMQYDVR0fBCowKDAmoCSgIoYgaHR0cDovL2NybC52ZXJpc2lnbi5jb20vcGNhMi5j
cmwwEQYJYIZIAYb4QgEBBAQDAgEGMEcGA1UdIARAMD4wPAYLYIZIAYb4RQEHAQEwLTArBggrBgEF
BQcCARYfaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYS1rcjAPBgNVHRMECDAGAQH/AgEBMAsG
A1UdDwQEAwIBBjANBgkqhkiG9w0BAQQFAAOBgQB59xXN6GhRWWv8qaa94B77vPQ/kN/n+u3kVPdh
PVSLBrqXMloeqyzur3Orx13TP4/0zstOSGCiqGC2ON6gpvePKegRrMw5dlA83TlsC/Fa/QhUdt0W
bPcxcLi/CPfJJgaO37svGbG2uLToPEjoJ7GXKSBXA5ybZ/p9QMQ4fxiqmjCCA8QwggMtoAMCAQIC
EQCEzvIOADm1dVXaGYePUu2JMA0GCSqGSIb3DQEBBAUAMIGtMRcwFQYDVQQKEw5WZXJpU2lnbiwg
SW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFJMEcGA1UECxNAVXNlIGlzIHN1
YmplY3QgdG8gdGVybXMgYXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYS1rciAoYyk5OTEm
MCQGA1UEAxMdVmVyaVNpZ24gQ2xhc3MgMiBQZXJzb25uZWwgQ0EwHhcNOTkwMjI1MDAwMDAwWhcN
MDQwMTA0MjM1OTU5WjCBrDEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlT
aWduIFRydXN0IE5ldHdvcmsxSTBHBgNVBAsTQFVzZSBpcyBzdWJqZWN0IHRvIHRlcm1zIGF0IGh0
dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9ycGEta3IgKGMpOTkxJTAjBgNVBAMTHFZlcmlTaWduIENs
YXNzIDIgRW1wbG95ZWUgQ0EwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBAMCK0YdhouowA1Vr
CDbwl/oaVDUkH+h9ncjDc9PYRvWRLdk47ZTXsCZzKt6XUE3/Ihy9cACYDFgqsaRyj6W59y18YOO1
3+l9TiEhYdX8O1TJpAmcuyL5orpwYU+GRqL9BWTsCj+mWHZXuxZzRHzwpQ2XwGym8WMIJbEEF5Wg
jf5/AgMBAAGjgeIwgd8wKQYDVR0RBCIwIKQeMBwxGjAYBgNVBAMTEVByaXZhdGVMYWJlbDEtMTE4
MDgGA1UdHwQxMC8wLaAroCmGJ2h0dHA6Ly9jcmwudmVyaXNpZ24uY29tL1ZTQ2xhc3MySW50LmNy
bDARBglghkgBhvhCAQEEBAMCAQYwRwYDVR0gBEAwPjA8BgtghkgBhvhFAQcBATAtMCsGCCsGAQUF
BwIBFh9odHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBhLWtyMA8GA1UdEwQIMAYBAf8CAQAwCwYD
VR0PBAQDAgEGMA0GCSqGSIb3DQEBBAUAA4GBABlGztRrcI5YXIhCNa0WfaUJLKhTkPH2PYbX8M5y
FD0ivPLDM+3U/AWa4GMgdaMb71UZDwZzIQJhrqaeUSt43FvIhIvV17bP1fg+l5ixRIujmI6gS/aY
MZOz8AzdUXbKl+RWRMb7lKFIfSJDzKDGXHlV9WeBG2iYNCREsZjBOiheMIIEGTCCA4KgAwIBAgIQ
da9pAn9XoMlLtvoUDq8LyTANBgkqhkiG9w0BAQQFADCBrDEXMBUGA1UEChMOVmVyaVNpZ24sIElu
Yy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0IE5ldHdvcmsxSTBHBgNVBAsTQFVzZSBpcyBzdWJq
ZWN0IHRvIHRlcm1zIGF0IGh0dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9ycGEta3IgKGMpOTkxJTAj
BgNVBAMTHFZlcmlTaWduIENsYXNzIDIgRW1wbG95ZWUgQ0EwHhcNMDIwMjI3MDAwMDAwWhcNMDMw
MjI3MjM1OTU5WjBtMREwDwYDVQQKEwhWRVJJU0lHTjELMAkGA1UECxMCSFExEzARBgNVBAMTClJl
Y2lwaWVudHMxNjA0BgNVBAMTLXBiYWtlciAoSGFsbGFtLUJha2VyIFBoaWxsaXAsIFZlcmlTaWdu
LCBJbmMuKTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAtcA/okLsFi9brjmDsXQ6+g+R95B1
81Lq1EXkdzhY7XHxQ2QDq0sS2U4j9N1Ic6nHIiMq5dticztWpKdn6CrDx3Ovd5k+PACq/jSQo7NL
tlMJi7fsUrP7pM4izKu4JjSak6wRJUA4x85TSC1PLfd1u8oq16iqNJRhpEJ8VJUMRyECAwEAAaOC
AXgwggF0MAkGA1UdEwQCMAAwWQYDVR0fBFIwUDBOoEygSoZIaHR0cDovL29uc2l0ZWNybC52ZXJp
c2lnbi5jb20vVmVyaVNpZ25JbmNFeGNoYW5nZUVtcGxveWVlcy9MYXRlc3RDUkwuY3JsMAsGA1Ud
DwQEAwIFoDAeBgNVHREEFzAVgRNwYmFrZXJAdmVyaXNpZ24uY29tMIGsBgNVHSAEgaQwgaEwgZ4G
C2CGSAGG+EUBBwEBMIGOMCgGCCsGAQUFBwIBFhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vQ1BT
MGIGCCsGAQUFBwICMFYwFRYOVmVyaVNpZ24sIEluYy4wAwIBARo9VmVyaVNpZ24ncyBDUFMgaW5j
b3JwLiBieSByZWZlcmVuY2UgbGlhYi4gbHRkLiAoYyk5NyBWZXJpU2lnbjARBglghkgBhvhCAQEE
BAMCB4AwHQYDVR0lBBYwFAYIKwYBBQUHAwQGCCsGAQUFBwMCMA0GCSqGSIb3DQEBBAUAA4GBACCK
+gbdTcJB2wmWF5q8hbnP6slvVFehmjSX1Se+4Ff6a3Uiw8aOQLyNwnYUSOtHe12rTwAtWOhEgXHK
D4XY3tF7cofo5hM8dk8xsj9vV3z3fYARDr4nR2bZblPJ3MGmAFAYKW4pgX4Y6NU4VhAG2Hiuj18/
H4Cc5g5oqJp5dArUMYIC+DCCAvQCAQEwgcEwgawxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8w
HQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUkwRwYDVQQLE0BVc2UgaXMgc3ViamVjdCB0
byB0ZXJtcyBhdCBodHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBhLWtyIChjKTk5MSUwIwYDVQQD
ExxWZXJpU2lnbiBDbGFzcyAyIEVtcGxveWVlIENBAhB1r2kCf1egyUu2+hQOrwvJMAkGBSsOAwIa
BQCgggGMMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTAzMDEyNzE1
NTQ0OVowIwYJKoZIhvcNAQkEMRYEFBz8KrO2xDsIaT/Zds2exiDzfdWnMFgGCSqGSIb3DQEJDzFL
MEkwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwICAgCAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMAcG
BSsOAwIaMAoGCCqGSIb3DQIFMIHSBgkrBgEEAYI3EAQxgcQwgcEwgawxFzAVBgNVBAoTDlZlcmlT
aWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUkwRwYDVQQLE0BVc2Ug
aXMgc3ViamVjdCB0byB0ZXJtcyBhdCBodHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBhLWtyIChj
KTk5MSUwIwYDVQQDExxWZXJpU2lnbiBDbGFzcyAyIEVtcGxveWVlIENBAhB1r2kCf1egyUu2+hQO
rwvJMA0GCSqGSIb3DQEBAQUABIGABK6QRHBRpaiA6hyldlTty7wuO3aE5gBH3KdDzXXkomdSWwqn
6MjaWg69wx1IsUqYc6eoA4SAVaje8c/ePu8sxF6S+aBam1VwAzaQVes0ftW3Hp6S9MCAi3uY3YnZ
ScGI8fcc+98aIRmSdpeXHq/tyyOr0FDXlOevCu5XuxF7gVEAAAAAAAA=

------=_NextPart_000_001D_01C2C5F2.834B41A0--



Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h0RFiQ316061 for ietf-pkix-bks; Mon, 27 Jan 2003 07:44:26 -0800 (PST)
Received: from pigeon.verisign.com (pigeon.verisign.com [65.205.251.71]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h0RFiOo16057 for <[e-mail]>; Mon, 27 Jan 2003 07:44:24 -0800 (PST)
Received: from vhqpostal-gw1.verisign.com (verisign.com [65.205.251.55]) by pigeon.verisign.com (8.12.1/) with ESMTP id h0RFgf3k015227; Mon, 27 Jan 2003 07:42:41 -0800 (PST)
Received: by vhqpostal-gw1.verisign.com with Internet Mail Service (5.5.2656.59) id <ZHLNLP6G>; Mon, 27 Jan 2003 07:44:24 -0800
Message-ID: <[e-mail]>
From: "Hallam-Baker, Phillip" <[e-mail]>
To: =?iso-8859-1?Q?=27Michael_Str=F6der=27?= <[e-mail]>, Richard Levitte - VMS Whacker <[e-mail]>
Cc: [e-mail]
Subject: RE: X.500, LDAP Considered harmful Was: OCSP/LDAP
Date: Mon, 27 Jan 2003 07:44:20 -0800
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2656.59)
MIME-Version: 1.0
Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_0018_01C2C5F1.0D585C40"
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

This is a multi-part message in MIME format.

------=_NextPart_000_0018_01C2C5F1.0D585C40
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit

> One could imagine other forms of using dc-style LDAP DNs and 
> SRV RRs, e.g. 
> look at the domain part of an e-mail address and query the 
> SRV RR for it.

As the group knows I suggested that what, four years ago. The
problem is the following lookup

> Retrieve e.g. encryption cert for [e-mail]:
> 
> ldap://mydirectory.stroeder.com/dc=stroeder,dc=com?userCertifi
> cate?sub?(mail=[e-mail])
> -> certificate

This is only going to work if the LDAP DIT is configured to support
this query. No companies do this for their central directories

What this means is proposing LDAP as the certificate repository 
is doomed to fail since we are not proposing a use of LDAP that
is compatible with the LDAP enterprises have already deployed
we are proposing either a second LDAP to be bound to the first
with some sort of duct tape (perl, awk whatever) or we are 
proposing root canal treatment on some CIO's directory...

This is the equivalent of the 'i'm not hungry, ill just have
some of yours diet'. We pretend that PKI does not need a 
repository, then we go in and insist that existing systems
be reengineered to meet PKI need badly.

I don't want to discuss the technical argument of 'could'
however, I have seen where that has got us. 


> > I'm imagining it would be possible to have a network of 
> interconnected
> > LDAP servers through referals, kind of the way DNS servers are
> > interconnected today, with the only difference that the 
> "zones" would
> > be trees in the DN namespace.

That is not going to happen. But the reason we are being
force fed directories is that the people who tried to 
make it happen have still not given up.

They have got their fangs into PKI because they believe
that we are their killer application.

> Requires a naming authority for X.521 names though.

> > With such a network, one would need to know a few LDAP 
> roots, and the
> > rest is about walking until there are no more answers or 
> until one has
> > found what one was looking for...
> 
> Well, that was the basic idea of X.500...

Which has failled utterly. 


		Phill

------=_NextPart_000_0018_01C2C5F1.0D585C40
Content-Type: application/x-pkcs7-signature;
	name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment;
	filename="smime.p7s"

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINbTCCAj0w
ggGmAhEAulrJTAU7ktantt9O0FOSDTANBgkqhkiG9w0BAQIFADBfMQswCQYDVQQGEwJVUzEXMBUG
A1UEChMOVmVyaVNpZ24sIEluYy4xNzA1BgNVBAsTLkNsYXNzIDIgUHVibGljIFByaW1hcnkgQ2Vy
dGlmaWNhdGlvbiBBdXRob3JpdHkwHhcNOTYwMTI5MDAwMDAwWhcNMDQwMTA3MjM1OTU5WjBfMQsw
CQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xNzA1BgNVBAsTLkNsYXNzIDIgUHVi
bGljIFByaW1hcnkgQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkwgZ8wDQYJKoZIhvcNAQEBBQADgY0A
MIGJAoGBALZai6MNaiODgGvPOYf0IRMzBkwlou1VEpfFp4C5+oPBIKD6LxUNfKFga355LPoGDzqu
9htvsdL/LyhSX4N9S8R6t/hmH4BU/LfCjllKFFdG0ZqTvkGRA7sVgJNc6+fMCGw/PrNK/P9LbCPV
UIImRBmOI8Nx6hkkRwSedb/IpgAfAgMBAAEwDQYJKoZIhvcNAQECBQADgYEAtgAfk1ekB6dAzmVA
P1Ve7e/6VEmlMNYhfGGH7oOTC7+0M/KYrJ8Gv06ozhSBTMsETljDz1/ufNeab8tBird/gbj/hGHG
J0NlHQzssQAK3Ruku8d4ICiyot02lS7hVE+/YLl3aBGZI+jqUuiqAE5nTruQtUWbRuuOFu/EM1sz
PdUwggNDMIICrKADAgECAhAffl/nA9Hgv5kg3GuJDUsEMA0GCSqGSIb3DQEBBAUAMF8xCzAJBgNV
BAYTAlVTMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjE3MDUGA1UECxMuQ2xhc3MgMiBQdWJsaWMg
UHJpbWFyeSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTAeFw05OTAyMjUwMDAwMDBaFw0wNDAxMDUy
MzU5NTlaMIGtMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1
c3QgTmV0d29yazFJMEcGA1UECxNAVXNlIGlzIHN1YmplY3QgdG8gdGVybXMgYXQgaHR0cHM6Ly93
d3cudmVyaXNpZ24uY29tL3JwYS1rciAoYyk5OTEmMCQGA1UEAxMdVmVyaVNpZ24gQ2xhc3MgMiBQ
ZXJzb25uZWwgQ0EwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBAKcEbA+icrdKBi741yksNJ2C
vEiRSses+en8uVl4sVXAU1ixz28WO8FJ1cv0bszhzMu1xy5OiKo06bbQW3w+FVc04Ri8/931r2dZ
IArlPeqIikDSmokTKam21dunfuHnNyST/ZR0TXrkMm1M6FwWl6/dktlmihRm5OpaA6g9X/sLAgMB
AAGjgbAwga0wMQYDVR0fBCowKDAmoCSgIoYgaHR0cDovL2NybC52ZXJpc2lnbi5jb20vcGNhMi5j
cmwwEQYJYIZIAYb4QgEBBAQDAgEGMEcGA1UdIARAMD4wPAYLYIZIAYb4RQEHAQEwLTArBggrBgEF
BQcCARYfaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYS1rcjAPBgNVHRMECDAGAQH/AgEBMAsG
A1UdDwQEAwIBBjANBgkqhkiG9w0BAQQFAAOBgQB59xXN6GhRWWv8qaa94B77vPQ/kN/n+u3kVPdh
PVSLBrqXMloeqyzur3Orx13TP4/0zstOSGCiqGC2ON6gpvePKegRrMw5dlA83TlsC/Fa/QhUdt0W
bPcxcLi/CPfJJgaO37svGbG2uLToPEjoJ7GXKSBXA5ybZ/p9QMQ4fxiqmjCCA8QwggMtoAMCAQIC
EQCEzvIOADm1dVXaGYePUu2JMA0GCSqGSIb3DQEBBAUAMIGtMRcwFQYDVQQKEw5WZXJpU2lnbiwg
SW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFJMEcGA1UECxNAVXNlIGlzIHN1
YmplY3QgdG8gdGVybXMgYXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYS1rciAoYyk5OTEm
MCQGA1UEAxMdVmVyaVNpZ24gQ2xhc3MgMiBQZXJzb25uZWwgQ0EwHhcNOTkwMjI1MDAwMDAwWhcN
MDQwMTA0MjM1OTU5WjCBrDEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlT
aWduIFRydXN0IE5ldHdvcmsxSTBHBgNVBAsTQFVzZSBpcyBzdWJqZWN0IHRvIHRlcm1zIGF0IGh0
dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9ycGEta3IgKGMpOTkxJTAjBgNVBAMTHFZlcmlTaWduIENs
YXNzIDIgRW1wbG95ZWUgQ0EwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBAMCK0YdhouowA1Vr
CDbwl/oaVDUkH+h9ncjDc9PYRvWRLdk47ZTXsCZzKt6XUE3/Ihy9cACYDFgqsaRyj6W59y18YOO1
3+l9TiEhYdX8O1TJpAmcuyL5orpwYU+GRqL9BWTsCj+mWHZXuxZzRHzwpQ2XwGym8WMIJbEEF5Wg
jf5/AgMBAAGjgeIwgd8wKQYDVR0RBCIwIKQeMBwxGjAYBgNVBAMTEVByaXZhdGVMYWJlbDEtMTE4
MDgGA1UdHwQxMC8wLaAroCmGJ2h0dHA6Ly9jcmwudmVyaXNpZ24uY29tL1ZTQ2xhc3MySW50LmNy
bDARBglghkgBhvhCAQEEBAMCAQYwRwYDVR0gBEAwPjA8BgtghkgBhvhFAQcBATAtMCsGCCsGAQUF
BwIBFh9odHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBhLWtyMA8GA1UdEwQIMAYBAf8CAQAwCwYD
VR0PBAQDAgEGMA0GCSqGSIb3DQEBBAUAA4GBABlGztRrcI5YXIhCNa0WfaUJLKhTkPH2PYbX8M5y
FD0ivPLDM+3U/AWa4GMgdaMb71UZDwZzIQJhrqaeUSt43FvIhIvV17bP1fg+l5ixRIujmI6gS/aY
MZOz8AzdUXbKl+RWRMb7lKFIfSJDzKDGXHlV9WeBG2iYNCREsZjBOiheMIIEGTCCA4KgAwIBAgIQ
da9pAn9XoMlLtvoUDq8LyTANBgkqhkiG9w0BAQQFADCBrDEXMBUGA1UEChMOVmVyaVNpZ24sIElu
Yy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0IE5ldHdvcmsxSTBHBgNVBAsTQFVzZSBpcyBzdWJq
ZWN0IHRvIHRlcm1zIGF0IGh0dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9ycGEta3IgKGMpOTkxJTAj
BgNVBAMTHFZlcmlTaWduIENsYXNzIDIgRW1wbG95ZWUgQ0EwHhcNMDIwMjI3MDAwMDAwWhcNMDMw
MjI3MjM1OTU5WjBtMREwDwYDVQQKEwhWRVJJU0lHTjELMAkGA1UECxMCSFExEzARBgNVBAMTClJl
Y2lwaWVudHMxNjA0BgNVBAMTLXBiYWtlciAoSGFsbGFtLUJha2VyIFBoaWxsaXAsIFZlcmlTaWdu
LCBJbmMuKTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAtcA/okLsFi9brjmDsXQ6+g+R95B1
81Lq1EXkdzhY7XHxQ2QDq0sS2U4j9N1Ic6nHIiMq5dticztWpKdn6CrDx3Ovd5k+PACq/jSQo7NL
tlMJi7fsUrP7pM4izKu4JjSak6wRJUA4x85TSC1PLfd1u8oq16iqNJRhpEJ8VJUMRyECAwEAAaOC
AXgwggF0MAkGA1UdEwQCMAAwWQYDVR0fBFIwUDBOoEygSoZIaHR0cDovL29uc2l0ZWNybC52ZXJp
c2lnbi5jb20vVmVyaVNpZ25JbmNFeGNoYW5nZUVtcGxveWVlcy9MYXRlc3RDUkwuY3JsMAsGA1Ud
DwQEAwIFoDAeBgNVHREEFzAVgRNwYmFrZXJAdmVyaXNpZ24uY29tMIGsBgNVHSAEgaQwgaEwgZ4G
C2CGSAGG+EUBBwEBMIGOMCgGCCsGAQUFBwIBFhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vQ1BT
MGIGCCsGAQUFBwICMFYwFRYOVmVyaVNpZ24sIEluYy4wAwIBARo9VmVyaVNpZ24ncyBDUFMgaW5j
b3JwLiBieSByZWZlcmVuY2UgbGlhYi4gbHRkLiAoYyk5NyBWZXJpU2lnbjARBglghkgBhvhCAQEE
BAMCB4AwHQYDVR0lBBYwFAYIKwYBBQUHAwQGCCsGAQUFBwMCMA0GCSqGSIb3DQEBBAUAA4GBACCK
+gbdTcJB2wmWF5q8hbnP6slvVFehmjSX1Se+4Ff6a3Uiw8aOQLyNwnYUSOtHe12rTwAtWOhEgXHK
D4XY3tF7cofo5hM8dk8xsj9vV3z3fYARDr4nR2bZblPJ3MGmAFAYKW4pgX4Y6NU4VhAG2Hiuj18/
H4Cc5g5oqJp5dArUMYIC+DCCAvQCAQEwgcEwgawxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8w
HQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUkwRwYDVQQLE0BVc2UgaXMgc3ViamVjdCB0
byB0ZXJtcyBhdCBodHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBhLWtyIChjKTk5MSUwIwYDVQQD
ExxWZXJpU2lnbiBDbGFzcyAyIEVtcGxveWVlIENBAhB1r2kCf1egyUu2+hQOrwvJMAkGBSsOAwIa
BQCgggGMMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTAzMDEyNzE1
NDQyMlowIwYJKoZIhvcNAQkEMRYEFKLDQXBwsl7Lq6sLOXTPNi9yG2qKMFgGCSqGSIb3DQEJDzFL
MEkwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwICAgCAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMAcG
BSsOAwIaMAoGCCqGSIb3DQIFMIHSBgkrBgEEAYI3EAQxgcQwgcEwgawxFzAVBgNVBAoTDlZlcmlT
aWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUkwRwYDVQQLE0BVc2Ug
aXMgc3ViamVjdCB0byB0ZXJtcyBhdCBodHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBhLWtyIChj
KTk5MSUwIwYDVQQDExxWZXJpU2lnbiBDbGFzcyAyIEVtcGxveWVlIENBAhB1r2kCf1egyUu2+hQO
rwvJMA0GCSqGSIb3DQEBAQUABIGAlbtOeq3xoIhgodWJVlC/2a11x6Uz6zrHfv7BvmkNeFABNpqb
roH6vt/vfimEi9zMYv3uqGJKVS4EFl6ZdhjldO7m6dLEgHy/FFyqQrcaNRbVrNqU5Q6kcrVbNfYz
vPXcKvoDre/mddCHwxVq9kKBdgFg5jL+NGgohbg39/jeALMAAAAAAAA=

------=_NextPart_000_0018_01C2C5F1.0D585C40--



Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h0RFTIi15660 for ietf-pkix-bks; Mon, 27 Jan 2003 07:29:18 -0800 (PST)
Received: from peacock.verisign.com (peacock.verisign.com [65.205.251.73]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h0RFTHo15656 for <[e-mail]>; Mon, 27 Jan 2003 07:29:17 -0800 (PST)
Received: from vhqpostal-gw2.verisign.com (verisign.com [65.205.251.56]) by peacock.verisign.com (8.12.1/) with ESMTP id h0RFSaq4024414; Mon, 27 Jan 2003 07:28:36 -0800 (PST)
Received: by vhqpostal-gw2.verisign.com with Internet Mail Service (5.5.2653.19) id <DQTLG55M>; Mon, 27 Jan 2003 07:29:10 -0800
Message-ID: <[e-mail]>
From: "Hallam-Baker, Phillip" <[e-mail]>
To: "'Blake Ramsdell'" <[e-mail]>, =?iso-8859-1?Q?=27Mich?= =?iso-8859-1?Q?ael_Str=F6der=27?= <[e-mail]>, "'Peter Gutmann'" <[e-mail]>
Cc: [e-mail]
Subject: RE: X.500, LDAP Considered harmful Was: OCSP/LDAP
Date: Mon, 27 Jan 2003 07:29:06 -0800
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
MIME-Version: 1.0
Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_0013_01C2C5EE.ECD92FA0"
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

This is a multi-part message in MIME format.

------=_NextPart_000_0013_01C2C5EE.ECD92FA0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit


> You're missing Peter's point here -- the SELECT is not 
> necessarily meant
> to be SQL, 

This is the crux of the matter. The question the app wants
to ask is:

What key should I use to talk protocol X to identifier Y?


The simple fact is that it is much easier to implement this 
query, the one the app actually cares about than all the X.500
and LDAP mush.

Common name, Distingushed name, first name, last name SHOULD NOT
be searchable fields. There is no utility in making them
searchable. 

> For eight years I've been working with S/MIME, X.509 and related
> standards, and with the exception of adding SubjectKeyIdentifier, the
> criteria I've wanted to search on have not changed.  And I 
> still cannot
> do those searches today with anything other than my own database.

Try XKMS.


		Phill

------=_NextPart_000_0013_01C2C5EE.ECD92FA0
Content-Type: application/x-pkcs7-signature;
	name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment;
	filename="smime.p7s"

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINbTCCAj0w
ggGmAhEAulrJTAU7ktantt9O0FOSDTANBgkqhkiG9w0BAQIFADBfMQswCQYDVQQGEwJVUzEXMBUG
A1UEChMOVmVyaVNpZ24sIEluYy4xNzA1BgNVBAsTLkNsYXNzIDIgUHVibGljIFByaW1hcnkgQ2Vy
dGlmaWNhdGlvbiBBdXRob3JpdHkwHhcNOTYwMTI5MDAwMDAwWhcNMDQwMTA3MjM1OTU5WjBfMQsw
CQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xNzA1BgNVBAsTLkNsYXNzIDIgUHVi
bGljIFByaW1hcnkgQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkwgZ8wDQYJKoZIhvcNAQEBBQADgY0A
MIGJAoGBALZai6MNaiODgGvPOYf0IRMzBkwlou1VEpfFp4C5+oPBIKD6LxUNfKFga355LPoGDzqu
9htvsdL/LyhSX4N9S8R6t/hmH4BU/LfCjllKFFdG0ZqTvkGRA7sVgJNc6+fMCGw/PrNK/P9LbCPV
UIImRBmOI8Nx6hkkRwSedb/IpgAfAgMBAAEwDQYJKoZIhvcNAQECBQADgYEAtgAfk1ekB6dAzmVA
P1Ve7e/6VEmlMNYhfGGH7oOTC7+0M/KYrJ8Gv06ozhSBTMsETljDz1/ufNeab8tBird/gbj/hGHG
J0NlHQzssQAK3Ruku8d4ICiyot02lS7hVE+/YLl3aBGZI+jqUuiqAE5nTruQtUWbRuuOFu/EM1sz
PdUwggNDMIICrKADAgECAhAffl/nA9Hgv5kg3GuJDUsEMA0GCSqGSIb3DQEBBAUAMF8xCzAJBgNV
BAYTAlVTMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjE3MDUGA1UECxMuQ2xhc3MgMiBQdWJsaWMg
UHJpbWFyeSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTAeFw05OTAyMjUwMDAwMDBaFw0wNDAxMDUy
MzU5NTlaMIGtMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1
c3QgTmV0d29yazFJMEcGA1UECxNAVXNlIGlzIHN1YmplY3QgdG8gdGVybXMgYXQgaHR0cHM6Ly93
d3cudmVyaXNpZ24uY29tL3JwYS1rciAoYyk5OTEmMCQGA1UEAxMdVmVyaVNpZ24gQ2xhc3MgMiBQ
ZXJzb25uZWwgQ0EwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBAKcEbA+icrdKBi741yksNJ2C
vEiRSses+en8uVl4sVXAU1ixz28WO8FJ1cv0bszhzMu1xy5OiKo06bbQW3w+FVc04Ri8/931r2dZ
IArlPeqIikDSmokTKam21dunfuHnNyST/ZR0TXrkMm1M6FwWl6/dktlmihRm5OpaA6g9X/sLAgMB
AAGjgbAwga0wMQYDVR0fBCowKDAmoCSgIoYgaHR0cDovL2NybC52ZXJpc2lnbi5jb20vcGNhMi5j
cmwwEQYJYIZIAYb4QgEBBAQDAgEGMEcGA1UdIARAMD4wPAYLYIZIAYb4RQEHAQEwLTArBggrBgEF
BQcCARYfaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYS1rcjAPBgNVHRMECDAGAQH/AgEBMAsG
A1UdDwQEAwIBBjANBgkqhkiG9w0BAQQFAAOBgQB59xXN6GhRWWv8qaa94B77vPQ/kN/n+u3kVPdh
PVSLBrqXMloeqyzur3Orx13TP4/0zstOSGCiqGC2ON6gpvePKegRrMw5dlA83TlsC/Fa/QhUdt0W
bPcxcLi/CPfJJgaO37svGbG2uLToPEjoJ7GXKSBXA5ybZ/p9QMQ4fxiqmjCCA8QwggMtoAMCAQIC
EQCEzvIOADm1dVXaGYePUu2JMA0GCSqGSIb3DQEBBAUAMIGtMRcwFQYDVQQKEw5WZXJpU2lnbiwg
SW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFJMEcGA1UECxNAVXNlIGlzIHN1
YmplY3QgdG8gdGVybXMgYXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYS1rciAoYyk5OTEm
MCQGA1UEAxMdVmVyaVNpZ24gQ2xhc3MgMiBQZXJzb25uZWwgQ0EwHhcNOTkwMjI1MDAwMDAwWhcN
MDQwMTA0MjM1OTU5WjCBrDEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlT
aWduIFRydXN0IE5ldHdvcmsxSTBHBgNVBAsTQFVzZSBpcyBzdWJqZWN0IHRvIHRlcm1zIGF0IGh0
dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9ycGEta3IgKGMpOTkxJTAjBgNVBAMTHFZlcmlTaWduIENs
YXNzIDIgRW1wbG95ZWUgQ0EwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBAMCK0YdhouowA1Vr
CDbwl/oaVDUkH+h9ncjDc9PYRvWRLdk47ZTXsCZzKt6XUE3/Ihy9cACYDFgqsaRyj6W59y18YOO1
3+l9TiEhYdX8O1TJpAmcuyL5orpwYU+GRqL9BWTsCj+mWHZXuxZzRHzwpQ2XwGym8WMIJbEEF5Wg
jf5/AgMBAAGjgeIwgd8wKQYDVR0RBCIwIKQeMBwxGjAYBgNVBAMTEVByaXZhdGVMYWJlbDEtMTE4
MDgGA1UdHwQxMC8wLaAroCmGJ2h0dHA6Ly9jcmwudmVyaXNpZ24uY29tL1ZTQ2xhc3MySW50LmNy
bDARBglghkgBhvhCAQEEBAMCAQYwRwYDVR0gBEAwPjA8BgtghkgBhvhFAQcBATAtMCsGCCsGAQUF
BwIBFh9odHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBhLWtyMA8GA1UdEwQIMAYBAf8CAQAwCwYD
VR0PBAQDAgEGMA0GCSqGSIb3DQEBBAUAA4GBABlGztRrcI5YXIhCNa0WfaUJLKhTkPH2PYbX8M5y
FD0ivPLDM+3U/AWa4GMgdaMb71UZDwZzIQJhrqaeUSt43FvIhIvV17bP1fg+l5ixRIujmI6gS/aY
MZOz8AzdUXbKl+RWRMb7lKFIfSJDzKDGXHlV9WeBG2iYNCREsZjBOiheMIIEGTCCA4KgAwIBAgIQ
da9pAn9XoMlLtvoUDq8LyTANBgkqhkiG9w0BAQQFADCBrDEXMBUGA1UEChMOVmVyaVNpZ24sIElu
Yy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0IE5ldHdvcmsxSTBHBgNVBAsTQFVzZSBpcyBzdWJq
ZWN0IHRvIHRlcm1zIGF0IGh0dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9ycGEta3IgKGMpOTkxJTAj
BgNVBAMTHFZlcmlTaWduIENsYXNzIDIgRW1wbG95ZWUgQ0EwHhcNMDIwMjI3MDAwMDAwWhcNMDMw
MjI3MjM1OTU5WjBtMREwDwYDVQQKEwhWRVJJU0lHTjELMAkGA1UECxMCSFExEzARBgNVBAMTClJl
Y2lwaWVudHMxNjA0BgNVBAMTLXBiYWtlciAoSGFsbGFtLUJha2VyIFBoaWxsaXAsIFZlcmlTaWdu
LCBJbmMuKTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAtcA/okLsFi9brjmDsXQ6+g+R95B1
81Lq1EXkdzhY7XHxQ2QDq0sS2U4j9N1Ic6nHIiMq5dticztWpKdn6CrDx3Ovd5k+PACq/jSQo7NL
tlMJi7fsUrP7pM4izKu4JjSak6wRJUA4x85TSC1PLfd1u8oq16iqNJRhpEJ8VJUMRyECAwEAAaOC
AXgwggF0MAkGA1UdEwQCMAAwWQYDVR0fBFIwUDBOoEygSoZIaHR0cDovL29uc2l0ZWNybC52ZXJp
c2lnbi5jb20vVmVyaVNpZ25JbmNFeGNoYW5nZUVtcGxveWVlcy9MYXRlc3RDUkwuY3JsMAsGA1Ud
DwQEAwIFoDAeBgNVHREEFzAVgRNwYmFrZXJAdmVyaXNpZ24uY29tMIGsBgNVHSAEgaQwgaEwgZ4G
C2CGSAGG+EUBBwEBMIGOMCgGCCsGAQUFBwIBFhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vQ1BT
MGIGCCsGAQUFBwICMFYwFRYOVmVyaVNpZ24sIEluYy4wAwIBARo9VmVyaVNpZ24ncyBDUFMgaW5j
b3JwLiBieSByZWZlcmVuY2UgbGlhYi4gbHRkLiAoYyk5NyBWZXJpU2lnbjARBglghkgBhvhCAQEE
BAMCB4AwHQYDVR0lBBYwFAYIKwYBBQUHAwQGCCsGAQUFBwMCMA0GCSqGSIb3DQEBBAUAA4GBACCK
+gbdTcJB2wmWF5q8hbnP6slvVFehmjSX1Se+4Ff6a3Uiw8aOQLyNwnYUSOtHe12rTwAtWOhEgXHK
D4XY3tF7cofo5hM8dk8xsj9vV3z3fYARDr4nR2bZblPJ3MGmAFAYKW4pgX4Y6NU4VhAG2Hiuj18/
H4Cc5g5oqJp5dArUMYIC+DCCAvQCAQEwgcEwgawxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8w
HQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUkwRwYDVQQLE0BVc2UgaXMgc3ViamVjdCB0
byB0ZXJtcyBhdCBodHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBhLWtyIChjKTk5MSUwIwYDVQQD
ExxWZXJpU2lnbiBDbGFzcyAyIEVtcGxveWVlIENBAhB1r2kCf1egyUu2+hQOrwvJMAkGBSsOAwIa
BQCgggGMMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTAzMDEyNzE1
MjkwOFowIwYJKoZIhvcNAQkEMRYEFCx9Vb/8fiPMaV6stNV9Zy9yn6x2MFgGCSqGSIb3DQEJDzFL
MEkwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwICAgCAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMAcG
BSsOAwIaMAoGCCqGSIb3DQIFMIHSBgkrBgEEAYI3EAQxgcQwgcEwgawxFzAVBgNVBAoTDlZlcmlT
aWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUkwRwYDVQQLE0BVc2Ug
aXMgc3ViamVjdCB0byB0ZXJtcyBhdCBodHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBhLWtyIChj
KTk5MSUwIwYDVQQDExxWZXJpU2lnbiBDbGFzcyAyIEVtcGxveWVlIENBAhB1r2kCf1egyUu2+hQO
rwvJMA0GCSqGSIb3DQEBAQUABIGAMDXB6IMlK+CfJiuG45+aQphA2AZeLjWvS2H4ZFGUXkaalJ2O
mKCfFDo+kTQjDbsg2fOX4p7mI/3kym462wynZSGHQhRzDfMDXYVYySrbMxosvzwHkn6crpoYvX68
7CeKLHRRC9WsKvpzTWmxxGDsBplv2GJu9d96It8wKuCrC9AAAAAAAAA=

------=_NextPart_000_0013_01C2C5EE.ECD92FA0--



Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h0RDZeM08376 for ietf-pkix-bks; Mon, 27 Jan 2003 05:35:40 -0800 (PST)
Received: from nic.lp.se (nic.lp.se [212.247.5.91]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h0RDZco08371 for <[e-mail]>; Mon, 27 Jan 2003 05:35:38 -0800 (PST)
Received: from localhost (217.215.93.181) by nic.lp.se (MX V5.3 VnHj) with ESMTP; Mon, 27 Jan 2003 14:33:45 +0100
Date: Mon, 27 Jan 2003 14:30:34 +0100 (CET)
Message-ID: <[e-mail]>
To: [e-mail]
CC: [e-mail], [e-mail]
Subject: Re: X.500, LDAP Considered harmful Was: OCSP/LDAP
From: Richard Levitte - VMS Whacker <[e-mail]>
In-Reply-To: <[e-mail]>
References: <[e-mail]> <[e-mail]>
X-URL: http://www.lp.se/
X-Waved: dead chicken, GNU emacs 21.2.2, Mew version 3.1
X-Mew: See http://www.mew.org/
X-Mailer: Mew version 3.1 on Emacs 21.2 / Mule 5.0 (SAKAKI)
MIME-Version: 1.0
Content-Type: Text/Plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

In message <[e-mail]> on Mon, 27 Jan 2003 12:29:05 +0100 (CET), Richard Levitte - VMS Whacker <[e-mail]> said:

levitte> Peter, I've no trouble understanding what you say, and (as you mention
levitte> in another post) you're entirely correct, for (key,value) lookups,
levitte> there's really no difference between LDAP or RDBMs.

As someone reminded me privately: except for performance differences,
of course.

-- 
Richard Levitte     | http://richard.levitte.org/ | Spannv. 38, I
Levitte Programming | http://www.lp.se/           | S-168 35 Bromma
T: [phone] |                             | SWEDEN
     "Price, performance, quality...  choose the two you like"


Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h0RBtrF01822 for ietf-pkix-bks; Mon, 27 Jan 2003 03:55:53 -0800 (PST)
Received: from druss.secaron.de (druss.secaron.de [195.145.99.123]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h0RBtpo01818 for <[e-mail]>; Mon, 27 Jan 2003 03:55:51 -0800 (PST)
Received: by druss.secaron.de (Postfix, from userid 104) id BD25E51F26; Mon, 27 Jan 2003 12:55:43 +0100 (MET)
Received: from druss.secaron.de (localhost [127.0.0.1]) by druss-vscan.secaron.de (Postfix) with ESMTP id 7322951F28 for <[e-mail]>; Mon, 27 Jan 2003 12:55:41 +0100 (MET)
Received: from marvin.munich.secaron.de (marvin.munich.secaron.de [192.168.1.20]) by druss.secaron.de (Postfix) with ESMTP id E2CF651F26 for <[e-mail]>; Mon, 27 Jan 2003 12:55:40 +0100 (MET)
Received: from sytrust.com ([192.168.2.3]) by marvin.munich.secaron.de (Lotus Domino Release 5.0.11) with ESMTP id 2003012712553985:8297 ; Mon, 27 Jan 2003 12:55:39 +0100 
Message-ID: <[e-mail]>
Date: Mon, 27 Jan 2003 12:41:59 +0000
From: Florian Oelmaier <[e-mail]>
Organization: SyTrust GmbH
User-Agent: Mozilla/5.0 (X11; U; Linux i686; de-AT; rv:1.1) Gecko/20020826
X-Accept-Language: de-de, en-us, en
MIME-Version: 1.0
To: [e-mail]
Subject: STRAWPOLL: OCSP
References: <[e-mail]>
X-MIMETrack: Itemize by SMTP Server on Marvin/Secaron(Release 5.0.11  |July 24, 2002) at 01/27/2003 12:55:39 PM, Serialize by Router on Marvin/Secaron(Release 5.0.11  |July 24, 2002) at 01/27/2003 12:55:40 PM, Serialize complete at 01/27/2003 12:55:40 PM
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset=us-ascii; format=flowed
X-Spam-Status: No, hits=-100.1 required=7.0 tests=AWL,NOSPAM_INC,REFERENCES,SPAM_PHRASE_00_01,SUBJ_ALL_CAPS, UPPERCASE_50_75,USER_AGENT,USER_AGENT_MOZILLA_UA, USER_IN_WHITELIST,X_ACCEPT_LANG version=2.43
X-Spam-Level: 
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>


Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h0RBd2i01330 for ietf-pkix-bks; Mon, 27 Jan 2003 03:39:02 -0800 (PST)
Received: from nic.lp.se (nic.lp.se [212.247.5.91]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h0RBcxo01326 for <[e-mail]>; Mon, 27 Jan 2003 03:39:01 -0800 (PST)
Received: from localhost (217.215.93.181) by nic.lp.se (MX V5.3 VnHj) with ESMTP; Mon, 27 Jan 2003 12:37:05 +0100
Date: Mon, 27 Jan 2003 12:33:54 +0100 (CET)
Message-ID: <[e-mail]>
To: [e-mail]
CC: [e-mail]
Subject: Re: X.500, LDAP Considered harmful Was: OCSP/LDAP
From: Richard Levitte - VMS Whacker <[e-mail]>
In-Reply-To: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]>
X-URL: http://www.lp.se/
X-Waved: dead chicken, GNU emacs 21.2.2, Mew version 3.1
X-Mew: See http://www.mew.org/
X-Mailer: Mew version 3.1 on Emacs 21.2 / Mule 5.0 (SAKAKI)
MIME-Version: 1.0
Content-Type: Text/Plain; charset=iso-8859-1
Content-Transfer-Encoding: 8bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

In message <[e-mail]> on Mon, 27 Jan 2003 01:56:54 +0100, Michael Ströder <[e-mail]> said:

michael> > I'm imagining it would be possible to have a network of interconnected
michael> > LDAP servers through referals, kind of the way DNS servers are
michael> > interconnected today, with the only difference that the "zones" would
michael> > be trees in the DN namespace.
michael> 
michael> Requires a naming authority for X.521 names though.

For the top level (whatever that would be), yes.  The rest of it would
be delegated to others (I'd assume they'd be called naming auhtorities
as well, right?).  We have that for DNS, I don't see that this would
be much different, except that the accepted names would be different
and probably broader (no, I haven't given that part much thought)...

-- 
Richard Levitte     | http://richard.levitte.org/ | Spannv. 38, I
Levitte Programming | http://www.lp.se/           | S-168 35 Bromma
T: [phone] |                             | SWEDEN
     "Price, performance, quality...  choose the two you like"


Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h0RBYKg01087 for ietf-pkix-bks; Mon, 27 Jan 2003 03:34:20 -0800 (PST)
Received: from nic.lp.se (nic.lp.se [212.247.5.91]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h0RBYIo01078 for <[e-mail]>; Mon, 27 Jan 2003 03:34:19 -0800 (PST)
Received: from localhost (217.215.93.181) by nic.lp.se (MX V5.3 VnHj) with ESMTP; Mon, 27 Jan 2003 12:32:16 +0100
Date: Mon, 27 Jan 2003 12:29:05 +0100 (CET)
Message-ID: <[e-mail]>
To: [e-mail]
CC: [e-mail], [e-mail]
Subject: Re: X.500, LDAP Considered harmful Was: OCSP/LDAP
From: Richard Levitte - VMS Whacker <[e-mail]>
In-Reply-To: <[e-mail]>
References: <[e-mail]>
X-URL: http://www.lp.se/
X-Waved: dead chicken, GNU emacs 21.2.2, Mew version 3.1
X-Mew: See http://www.mew.org/
X-Mailer: Mew version 3.1 on Emacs 21.2 / Mule 5.0 (SAKAKI)
MIME-Version: 1.0
Content-Type: Text/Plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

In message <[e-mail]> on Mon, 27 Jan 2003 17:19:03 +1300, [e-mail] (Peter Gutmann) said:

pgut001> [Warning: The previous reply was short and to the point.  This reply is a bit
pgut001>  of a longer rant, although it should be entertaining :-).  At least the first
pgut001>  half is mostly technical]

Lovely rant :-).

Peter, I've no trouble understanding what you say, and (as you mention
in another post) you're entirely correct, for (key,value) lookups,
there's really no difference between LDAP or RDBMs.

The argument that I'd like to make is another, and it's based on a
wish (I'm not ready to call it anything else, yet) to be able to do 
certification path discovery without having to store every single
existing certificate in my own database (meaning I'd need to be able
to find out where the certificate I'm looking for is stored, and I'd
need to know exactly how to extract the desired certificate from that
store):

- a minor point is that except for the LDAP schema drafts and your
  CERTSTORE draft, there's a lack of anything even remotely looking
  like a standard for certificate storage/extraction.  I would have no
  problem with yet another draft defining a schema for SQL-accessible
  RDBMs, but will be satisfied with what is there otherwise...
- more importantly, there's a lack of anything defining how discovery
  should work, except for the DC-style DNs.  There's talk of DPD, but
  that's a draft on how to put the problem on someone else, which is
  definitely not the same thing...

The only technology that I can think of would work for certificate
lookup based on DNs is LDAP (and I've written some thoughts on that in
an earlier post).  It seems to me that any other type of lookup will
be tied to whatever servers are configured with the application using
them, and that'll hardly cover all possible CAs in the world,
especially if mesh PKIs start to become more common-place...

-- 
Richard Levitte     | http://richard.levitte.org/ | Spannv. 38, I
Levitte Programming | http://www.lp.se/           | S-168 35 Bromma
T: [phone] |                             | SWEDEN
     "Price, performance, quality...  choose the two you like"


Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h0RBIAm28788 for ietf-pkix-bks; Mon, 27 Jan 2003 03:18:10 -0800 (PST)
Received: from ns1.worldcall.net.pk ([203.81.192.10]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h0RBI7o28784 for <[e-mail]>; Mon, 27 Jan 2003 03:18:07 -0800 (PST)
Received: from IdentrusVA1 ([203.81.193.98]) by ns1.worldcall.net.pk (8.12.2+Sun/8.12.2) with SMTP id h0RLJEis019015 for <[e-mail]>; Mon, 27 Jan 2003 16:19:14 -0500 (GMT)
Message-ID: <008401c2c5f5$6fe28210$0600a8c0@IdentrusVA1>
From: "Wahaj" <[e-mail]>
To: <[e-mail]>
Subject: STRAWPOLL:SCVP
Date: Mon, 27 Jan 2003 16:15:40 +0500
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=SHA1; boundary="----=_NextPart_000_007D_01C2C61F.566942E0"; protocol="application/x-pkcs7-signature"
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2800.1106
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

This is a multi-part message in MIME format.

------=_NextPart_000_007D_01C2C61F.566942E0
Content-Type: multipart/related;
	type="multipart/alternative";
	boundary="----=_NextPart_001_007E_01C2C61F.566942E0"


------=_NextPart_001_007E_01C2C61F.566942E0
Content-Type: multipart/alternative;
	boundary="----=_NextPart_002_007F_01C2C61F.566942E0"


------=_NextPart_002_007F_01C2C61F.566942E0
Content-Type: text/plain;
	charset="Windows-1252"
Content-Transfer-Encoding: quoted-printable




Muhammed Wahaj Khan       CTO

     a leading provider of real-time Certificate Validation solutions

 TrustFinderOCSP - provides the latest and most sophisticated OCSP =
(Online Certificate Status Protocol) server on the market.=20

ARP - is an essential plug-in for enabling OCSP client functionality in =
leading Microsoft=AE applications.


) Phone: [phone]
& Fax: [phone]
* Email: [e-mail]

Adding Trust to your PKI

www.ascertia.com

The opinions expressed are those of the individual and not the company. =
Internet communications are not secure and therefore the company does =
not accept legal responsibility for the contents of this message.  If =
the reader of this message is not the intended recipient, or the =
employee responsible for delivering this communication to the intended =
recipient, you are hereby notified that any disclosure, distribution or =
copying of this communication is strictly prohibited.=20




------=_NextPart_002_007F_01C2C61F.566942E0
Content-Type: text/html;
	charset="Windows-1252"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META http-equiv=3DContent-Type content=3D"text/html; =
charset=3Dwindows-1252"><BASE=20
href=3D"file://F:\Data\Document\General\Ascertia\Ascertia Email =
signature\">
<META content=3D"MSHTML 6.00.2800.1106" name=3DGENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=3D#ffffff>
<DIV>&nbsp;</DIV>
<DIV>
<DIV class=3DSection1>
<DIV>
<P class=3DMsoNormal><FONT face=3D"Times New Roman" =
color=3D#008080><SPAN=20
style=3D"FONT-WEIGHT: 700"><SPAN=20
style=3D"FONT-FAMILY: Arial"></SPAN></SPAN></FONT>&nbsp;</P>
<P class=3DMsoNormal><FONT color=3D#008080 size=3D2><SPAN=20
style=3D"FONT-WEIGHT: 700"><EM><SPAN style=3D"FONT-FAMILY: =
Arial">Muhammed Wahaj=20
Khan</SPAN></EM></SPAN></FONT><EM><B><I><FONT face=3DArial color=3Dteal =
size=3D2><SPAN=20
style=3D"FONT-WEIGHT: bold; FONT-SIZE: 10pt; COLOR: teal; FONT-FAMILY: =
Arial; mso-no-proof: yes">&nbsp;&nbsp;</SPAN></FONT></I></B></EM><FONT=20
face=3DArial color=3Dblack size=3D1><SPAN=20
style=3D"FONT-SIZE: 7.5pt; COLOR: black; FONT-FAMILY: Arial; =
mso-no-proof: yes">&nbsp;&nbsp;&nbsp;&nbsp;=20
CTO</SPAN></FONT></P>
<P><FONT face=3DArial size=3D1><SPAN=20
style=3D"FONT-SIZE: 7.5pt; FONT-FAMILY: Arial; mso-no-proof: yes"><IMG =
height=3D58=20
src=3D"cid:007c01c2c5f5$6cd12360$0600a8c0@IdentrusVA1" width=3D90=20
border=3D0>&nbsp;&nbsp;&nbsp;&nbsp; a leading provider of=20
real-time&nbsp;Certificate Validation solutions</SPAN></FONT></P>
<P>&nbsp;<FONT face=3D"Verdana, Arial, Helvetica, sans-serif" =
size=3D1><A=20
href=3D"http://www.ascertia.com/client/products/trust_finder.htm"=20
target=3D_blank>TrustFinderOCSP</A> - provides the latest and most =
sophisticated=20
OCSP (Online Certificate Status Protocol) server on the =
market.&nbsp;</FONT></P>
<P><FONT face=3D"Verdana, Arial, Helvetica, sans-serif" size=3D1><A=20
href=3D"http://www.ascertia.com/client/products/ocsp-revok-provider.htm" =

target=3D_blank>ARP </A>- is an essential plug-in for enabling OCSP =
client=20
functionality in leading Microsoft=AE applications.</FONT></P>
<P><FONT face=3DArial size=3D1><SPAN=20
style=3D"FONT-SIZE: 7.5pt; FONT-FAMILY: Arial; mso-no-proof: =
yes"><BR></SPAN></FONT><ST1:CITY><ST1:PLACE><SPAN=20
style=3D"FONT-WEIGHT: bold"><SPAN=20
style=3D"FONT-SIZE: 7.5pt; FONT-FAMILY: Arial; mso-no-proof: yes"><FONT =
face=3DArial=20
size=3D1><FONT size=3D3><FONT face=3DWingdings>)</FONT></FONT><FONT =
face=3DVerdana=20
size=3D2> </FONT></FONT></SPAN><FONT face=3DArial size=3D1><SPAN=20
style=3D"FONT-WEIGHT: bold; mso-no-proof: yes">Phone: [phone]=20
321<BR></SPAN></FONT><FONT face=3DArial size=3D1><SPAN=20
style=3D"FONT-SIZE: 7.5pt; FONT-FAMILY: Arial; mso-no-proof: yes"><FONT=20
face=3DWingdings size=3D3>&amp;</FONT><FONT face=3DVerdana size=3D2>=20
</FONT></SPAN></FONT><SPAN style=3D"FONT-WEIGHT: bold; mso-no-proof: =
yes"><FONT=20
face=3DArial size=3D1>Fax: [phone]</FONT></SPAN><SPAN=20
style=3D"FONT-SIZE: 7.5pt; FONT-FAMILY: Arial; mso-no-proof: yes"><FONT =
face=3DArial=20
size=3D1><FONT face=3DVerdana color=3D#808080 size=3D2><BR></FONT><FONT =
size=3D3><FONT=20
face=3DWingdings>*</FONT><FONT face=3D"Times New Roman">=20
</FONT></FONT></FONT></SPAN><FONT face=3DArial size=3D1><SPAN=20
style=3D"FONT-WEIGHT: bold; mso-no-proof: yes">Email: <A=20
style=3D"TEXT-DECORATION: none" =
href=3D"mailto:[e-mail]">wahaj.khan</A><A=20
style=3D"TEXT-DECORATION: none"=20
href=3D"mailto:[e-mail]">@ascertia.com</A></SPAN></FONT></SPAN><=
/ST1:PLACE></ST1:CITY></P>
<P style=3D"TEXT-ALIGN: center" align=3Dcenter><FONT face=3D"Times New =
Roman"=20
color=3Dteal size=3D6><SPAN=20
style=3D"FONT-SIZE: 24pt; COLOR: teal; mso-no-proof: yes">Adding =
<EM><I><FONT=20
face=3D"Times New Roman">Trust</FONT></I></EM> to your =
PKI</SPAN></FONT><SPAN=20
style=3D"mso-no-proof: yes"><O:P></O:P></SPAN></P>
<P style=3D"TEXT-ALIGN: center" align=3Dcenter><FONT face=3D"Times New =
Roman"=20
size=3D3><SPAN style=3D"FONT-SIZE: 12pt; mso-no-proof: yes"><A=20
href=3D"http://www.ascertia.com/"><FONT face=3DArial size=3D2><SPAN=20
style=3D"FONT-SIZE: 10pt; FONT-FAMILY: =
Arial">www.ascertia.com</SPAN></FONT></A></SPAN></FONT></P>
<P><FONT face=3DArial color=3Dgray size=3D1><SPAN=20
style=3D"FONT-SIZE: 7.5pt; COLOR: gray; FONT-FAMILY: Arial; =
mso-no-proof: yes">The=20
opinions expressed are those of the individual and not the company. =
Internet=20
communications are not secure and therefore the company does not accept =
legal=20
responsibility for the contents of this message.&nbsp; If the reader of =
this=20
message is not the intended recipient, or the employee responsible for=20
delivering this communication to the intended recipient, you are hereby =
notified=20
that any disclosure, distribution or copying of this communication is =
strictly=20
prohibited.</SPAN></FONT><SPAN style=3D"mso-no-proof: yes">=20
</SPAN><O:P></O:P></P></DIV>
<P class=3DMsoNormal><FONT face=3D"Times New Roman" size=3D3><SPAN=20
style=3D"FONT-SIZE: 12pt"><O:P></O:P></SPAN></FONT></P></DIV></DIV>
<DIV>&nbsp;</DIV></BODY></HTML>

------=_NextPart_002_007F_01C2C61F.566942E0--

------=_NextPart_001_007E_01C2C61F.566942E0
Content-Type: application/octet-stream;
	name="Ascertia-Logo.gif"
Content-Transfer-Encoding: base64
Content-ID: <007c01c2c5f5$6cd12360$0600a8c0@IdentrusVA1>

R0lGODlhWgA6APcAAP///yQhIjmJyWhqbGS+a8jKzAWAxKDTnqiqrejp63el2MHiv6vD5dve5/Hy
897v3haY/Hf4CBMAYPoSAGj6EgAAAAAAePgSAAACAAAw+hIA24D7dxhE+Xf/////QPoSAFCa/Hdn
mvx3CgIAAID6EgAAAAAAAAATAAC4FQAAAAAAuPgSAIgGEwBs+RIA24D7d9CY+Hd4ARMAeAETAOyc
/HeoBxMACLgVAAAAAIgABAQAfPoSAAAEBAADAAAAAAAAAAAAAAAw+RIAXVnhd8BoVgABN/l3GAAA
AAAAAAAAAAAAWPkSACQAAADTQ/l3SA0TAAAAEwAkAAAA4FQTADD5EgAAAgAA6PoSANuA+3cYRPl3
//////j6EgAWmPx3SA0TAAAAAAAAAAAAqHNIAKD5EgAAAAAAmJj4dwAAEwBQbhcAAAAAAHz5EgCI
BhMAMPoSANuA+3fQmPh3/////0D6EgDsnPx32AcTAFhuFwBsbhcAWG4XAAEAAADQmPh3AwAAAAAA
AAAAAAgCDQAAALgAugBw1hMA33f4d5DR/HfEd/h32GATALhgEwBsbhcAAAAAAAAAAAA4+hIA24D7
d4h4+Hf/////SPoSAAAAEwAHAAAAAG4XAFhuFwABAAAAAWATABDQ/Hew+RIAgPoSAID6EgDbgPt3
iK74d/////+Q+hIAsI3odwAAEwAAAAAAAQAAAG1c4XcAAAAAAQAAAADg/X+wTBcAAAAAAFhuFwAA
AAAAKAEAAFT6EgAAAAAAsP8SAP0T6nfIjeh3/////4iu+HfcTUMAWG4XAAAAEwAAAAAAIAAAAKC8
cs/FIsIBAHgAbyQAAAAAPLZwq9nAAQAAAAAZAwAAAAATAA0AAABsb2dv4FQTACABAAAZuUAA3gII
AN4CCAA0+xIA24D7d3iu+Hf/////RPsSAH9J6XcAABMACAAUABgBAABtXOF3AAAAAAAAAAAAAAAA
AAAAAMTARAA5VRMAXMQVAD1VEwAFdEgA/////+BUEwAuwUQAOVUTACH5BAAAAAAALAAAAABaADoA
AAj+AAEIHEiwoMGDCBMqXMiwocOHECNKnEixosWLGDMuTNDAgcaPIAkyEGCgpAIGIVNeVFBSgMuS
KFXKfNiApMubLxXM3LmQJc6fBmLyHErwp1EDOokqdWC0qVKlDQw0xWngKdEEUqfetEpU60sBXId6
JSk0rEyvJROY3am1ZIO1M6NSLYnUI1yZPklKZfD27swCWff63dkgL9LBMhswYJmVpF3EH0fSpZr0
4IMFBxY8gOyQcdOglgmIHn1gM+eEeT+XFbhgtGvRC04fxIq2QEEHr3PLNphadcEDuV/H3j3QZtvK
AoO/PkC8+NjDA3ErJ91coPGp0AVKn06AeXUGjT/+9x0InLv35g5afkbOmjsB09/D34R50H11keq/
riZYfvn9goXRlZ0DBYw3UGuuDfefQQ0YCAACAQSA0AMPPLZgQxBK+BECA3Q4AAIIcRjAAA4KJOIA
thnkwAAjpqhihyAOVECEHboIQAEdqiVQAh5+iBCLEdJoUIZBMhhkhDYKBGSEMRLkQJADPEZkAAhI
GeF4DRwZoY4ELRlkklpSWZCXEY4ZJpcCHTkAQTMG2eSNET6WpZZrKsRindpt+WCZ0emZoYFIpjki
QRkeVKhBbVrIJp8J3UnQnGoduuOVewZgY6AACDmQpIQyumgAisroKaEejignpRziCcCTlt5YI0H+
TBaQoaqciqphQYnimuqoStJZkKYqBurAsL+GSSuvlR6Uq3ZT8kokkFHCemSSrCYpra+bIlurQMsK
OmKRZmroaKdHGlhtQjQioC4CNm4L562fPlYtgbwC2Wu0Too4aJ+tIoTpqgW56263CQS6rb0AjLtj
h73Cey6OJEobI7HkGooswQbXy+edj7VpG6fnZnipmAXva+LFKIM6UMkfayyuyQCU7BHIcVYKaL/A
JjtkyvJS2ubOVJ5oYboKC/ohkGimm+GbAvMs7dG8zqlmsUe+mXCYAWNdMaJOD0QmvDKSievUt6lp
7ZIoZg221yobxKKBDYh9kEfDhipQAwXYvSMcAiWuzG6oDiSAJq565z33sINfqPjijDfu+OMBAQA7

------=_NextPart_001_007E_01C2C61F.566942E0--

------=_NextPart_000_007D_01C2C61F.566942E0
Content-Type: application/x-pkcs7-signature;
	name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment;
	filename="smime.p7s"

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIGCTCCAuMw
ggJMoAMCAQICAQEwDQYJKoZIhvcNAQEFBQAwezELMAkGA1UEBhMCVUsxETAPBgNVBAoTCEFzY2Vy
dGlhMRUwEwYDVQQLEwxBc2NlcnRpYSBQS0kxGTAXBgNVBAMTEEFzY2VydGlhIFJvb3QgQ0ExJzAl
BgkqhkiG9w0BCQEWGGFkbWlucm9vdGNhQGFzY2VydGlhLmNvbTAeFw0wMjA3MzExMDQyMjlaFw0x
MjA3MzExMDQyMjlaMHsxCzAJBgNVBAYTAlVLMREwDwYDVQQKEwhBc2NlcnRpYTEVMBMGA1UECxMM
QXNjZXJ0aWEgUEtJMRkwFwYDVQQDExBBc2NlcnRpYSBSb290IENBMScwJQYJKoZIhvcNAQkBFhhh
ZG1pbnJvb3RjYUBhc2NlcnRpYS5jb20wgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBAKPOw9Uj
Ro/Gs1yBG76D73OPuDPwTrc9Oh7UaSwKIBqdj1ZrROjjC5FUcewytif6FR4TbowqTztVSBDuh0ol
/zjpGtOecCtwwMelAktq3+TGBau2jZ7ynGqkHiWRHCF1YTIi2vtC9Rm5sb8pYGijSJIcjNUHKWa3
qkhfDWc2QvD9AgMBAAGjdzB1MA4GA1UdDwEB/wQEAwIBBjAdBgNVHQ4EFgQUonkJqqjLq2pqB8Qk
9B+S/FlXdeIwNgYIKwYBBQUHAQEEKjAoMCYGCCsGAQUFBzABhhp3d3cudGVzdHRydXN0ZmluZGVy
LmNvbTo4MzAMBgNVHRMEBTADAQH/MA0GCSqGSIb3DQEBBQUAA4GBADld9Iem7OAUQMc6KVJv2nCY
I3tTiHWTfV3gN08IAniRUY8um5euOkaclHBKR7QTEK8Ih6jhtAHeenhg4m5ARfix6oj/D2Fn4O7A
ZKYM7yZErAZzuPBpRMhyoJqiGWOSZp/BeQfXzdMfvH8o6TeHGP2XPF1n5H+ieFkJvDlos/loMIID
HjCCAoegAwIBAgIBCTANBgkqhkiG9w0BAQUFADB7MQswCQYDVQQGEwJVSzERMA8GA1UEChMIQXNj
ZXJ0aWExFTATBgNVBAsTDEFzY2VydGlhIFBLSTEZMBcGA1UEAxMQQXNjZXJ0aWEgUm9vdCBDQTEn
MCUGCSqGSIb3DQEJARYYYWRtaW5yb290Y2FAYXNjZXJ0aWEuY29tMB4XDTAyMDgwNTEyMDg0NVoX
DTA0MDgwNTEyMDg0NVowdDELMAkGA1UEBhMCVUsxETAPBgNVBAoTCEFzY2VydGlhMRUwEwYDVQQL
EwxBc2NlcnRpYSBQS0kxEzARBgNVBAMTCldhaGFqIEtoYW4xJjAkBgkqhkiG9w0BCQEWF3dhaGFq
LmtoYW5AYXNjZXJ0aWEuY29tMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQCw0kHNigCJzc/h
XcSv0ExHdrlEewl7nqo9mh2y8JsMLQ/STyE/1W1WeWgmiOaGh+hZvJVOPvByLt9Xoqvedv735Pjk
H9XeRXNyzaxp1nAX7TV5PtfBR9c/liG8/9/+8kd4C7BQRAY3fEOCeEWzyQ48wUxc6ISN3ugZ0cZ6
A3bP2wIDAQABo4G4MIG1MA4GA1UdDwEB/wQEAwID+DAdBgNVHQ4EFgQUSjLsB6eMVPNf98lVyYmT
v32Y7uUwKwYDVR0fBCQwIjAgoB6gHIYabGRhcDovL3Rlc3R0cnVzdGZpbmRlci5jb20wNgYIKwYB
BQUHAQEEKjAoMCYGCCsGAQUFBzABhhp3d3cudGVzdHRydXN0ZmluZGVyLmNvbTo4MzAfBgNVHSME
GDAWgBSieQmqqMuramoHxCT0H5L8WVd14jANBgkqhkiG9w0BAQUFAAOBgQB+e/amrUF9Ffgh1nUb
H3XS0T8hSjSFe4xdO8l96/Y+P7A05cOtD9hGjZ9+aAbxek7CoYIWX0Zw2ShyWs26c7W5xvdsTpG5
T1bMb8zVlowlsjvwdnc1Uf2zS9OPJRo9RTdQUirstRb99MEFMgErJZeC4E1sSmK0/MjuCMwKgcVD
5jGCAeQwggHgAgEBMIGAMHsxCzAJBgNVBAYTAlVLMREwDwYDVQQKEwhBc2NlcnRpYTEVMBMGA1UE
CxMMQXNjZXJ0aWEgUEtJMRkwFwYDVQQDExBBc2NlcnRpYSBSb290IENBMScwJQYJKoZIhvcNAQkB
FhhhZG1pbnJvb3RjYUBhc2NlcnRpYS5jb20CAQkwCQYFKw4DAhoFAKCBujAYBgkqhkiG9w0BCQMx
CwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0wMzAxMjcxMTE1NDBaMCMGCSqGSIb3DQEJBDEW
BBTmDEZmsccxiDc12LvrtJ2S3WXMYjBbBgkqhkiG9w0BCQ8xTjBMMAoGCCqGSIb3DQMHMA4GCCqG
SIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDAHBgUrDgMC
HTANBgkqhkiG9w0BAQEFAASBgEjCuyHMnnc0NTrt9vu97I0C+Ar/dSywR5Z1Ovrk87R1ESuIQzBp
Fx6VMMFIzBBwtJzfROoFaQyrEV1JaR838+UNCi0wBGP83FME+1uqq54xMGRL3nqVdmVuetVApjZF
bBr/s2x37HP8XecIgPFFCppyBhwW2NYlhpAhtE/Xb4ZkAAAAAAAA

------=_NextPart_000_007D_01C2C61F.566942E0--



Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h0RAJop26910 for ietf-pkix-bks; Mon, 27 Jan 2003 02:19:50 -0800 (PST)
Received: from odin2.bull.net (odin2.bull.net [192.90.70.84]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h0RAJno26902 for <[e-mail]>; Mon, 27 Jan 2003 02:19:49 -0800 (PST)
Received: from clbull.frcl.bull.fr (clbull.frcl.bull.fr [129.182.8.31]) by odin2.bull.net (8.9.3/8.9.3) with ESMTP id LAA31276 for <[e-mail]>; Mon, 27 Jan 2003 11:21:33 +0100
Received: from bull.net (frcls4013.frcl.bull.fr [129.182.108.120]) by clbull.frcl.bull.fr (8.9.2/8.9.1) with ESMTP id LAA24422 for <[e-mail]>; Mon, 27 Jan 2003 11:19:45 +0100
Message-ID: <[e-mail]>
Date: Mon, 27 Jan 2003 11:19:40 +0100
From: Denis Pinkas <[e-mail]>
Organization: Bull SA.
User-Agent: Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.0.1) Gecko/20020823 Netscape/7.0
X-Accept-Language: en-us, en, fr
MIME-Version: 1.0
To: pkix <[e-mail]>
Subject: STRAWPOLL: ABSTAIN
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

It would be interresting to get the rating of all the proposals against the 
  matrix. I have done that exercise for three proposals. Since I am the 
author of one of the four proposals it would not be fair that I do that 
rating for my own proposal.

I do not claim that the ratings I did contain no error; but at least they 
provide some indications and arguments.

Once all ratings will be done (and read), then I would believe that we can 
see better how the various proposals fit with the matrix.

Hence the reason why I abstain for the time being.

Denis



Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h0RAIgp26742 for ietf-pkix-bks; Mon, 27 Jan 2003 02:18:42 -0800 (PST)
Received: from odin2.bull.net (odin2.bull.net [192.90.70.84]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h0RAIfo26734 for <[e-mail]>; Mon, 27 Jan 2003 02:18:41 -0800 (PST)
Received: from clbull.frcl.bull.fr (clbull.frcl.bull.fr [129.182.8.31]) by odin2.bull.net (8.9.3/8.9.3) with ESMTP id LAA20856 for <[e-mail]>; Mon, 27 Jan 2003 11:20:30 +0100
Received: from bull.net (frcls4013.frcl.bull.fr [129.182.108.120]) by clbull.frcl.bull.fr (8.9.2/8.9.1) with ESMTP id LAA13886 for <[e-mail]>; Mon, 27 Jan 2003 11:18:42 +0100
Message-ID: <[e-mail]>
Date: Mon, 27 Jan 2003 11:18:36 +0100
From: Denis Pinkas <[e-mail]>
Organization: Bull SA.
User-Agent: Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.0.1) Gecko/20020823 Netscape/7.0
X-Accept-Language: en-us, en, fr
MIME-Version: 1.0
To: pkix <[e-mail]>
Subject: Rating of the SCVP Compliance Matrix
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id h0RAIgo26737
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Rating of the SCVP Compliance Matrix

The following rating is my own rating.

SUMMARY

The following points are met: 1, 4, 5, 6, 8, 9, 10, 11, 12, 17, 23, 26, 27, 
28, 29, 30, 31, 32, 33, 34.
The following points are met, but not in an optimum way: 13, 16.
The following points are not correctly met or partly met: 2, 7, 15, 24, 35.
The following points are not met: 3, 14, 18, 19, 20, 21, 22, 25.

The overall rating is: 22/35 or 27/35 depending on the way to count “not 
correctly met or partly met”.

GENERAL COMMENT

There is an over-use (or abuse of use) of OIDs everywhere, in this document. 
In many places tags or enumerated values could be used instead. This would 
make the syntax simpler, and easier to debug.

EXPLANATIONS

Point 1. The requirement is met.

Point 2. The use of the server default policy does not allow to know which 
policy has been used. The requirement is only partly met.

Point 3. The use of a mixture of policy and other parameters (valPolicy and 
trustAnchors) does not allow to support, as indicated in the matrix, an OID 
followed by additional parameters. The requirement is not met.

Point 4. The requirement is met.

Point 5. The requirement is met.

Point 6. The requirement is met.

Point 7. The use of trust anchors is not appropriate. They are not 
independent of the policy but under the policy. The requirement is not 
correctly met.

Point 8. The requirement is met.

Point 9. The fact that the server always return the certificate is not easy 
for light clients that will have to verify that it matches the ESSCertID if 
ESSCertID is being used. Nevertheless, the requirement is met.

Point 10. The requirement is met.

Point 11. The requirement is met.

Point 12. The requirement is met.

Point 13. The text states:  "The octet string value for the proof of 
revocation status,  { id-swb 2 }, contains the RevocationInfo type." There 
is a small error here: RevocationInfo has to be replaced by RevocationInfos. 
I believe that this is the intended left error to make sure that the 
specification has really been read. :-)

The answer is signed but this is far from optimum since the signed answer is 
quite big when it is for multiple certificates and the certification path 
(including the revocation information) is also provided. In many cases, a 
relying party would like to store the signed answer for just one certificate 
and thus be able to provide the proof that the checking was done without the 
need to communicate the answers for other certificates. In case of a 
dispute, the relying party would then need to provide the certification path 
(including the revocation information) but this does not mean that two 
signed answers should be provided, one with the certification path 
(including the revocation information) and one without. There exists a 
technique allowing to get a single proof and to also protect the 
certification path (including the revocation information). This technique is 
being used in CVP: the hash of the certification path (including the 
revocation information) is included in an individual signed answer.

The requirement is met, but not in an optimum way.

Point 14. The requirement is not met since the requestor item serves for 
three different purposes.

Point 15. RequestReference is a CHOICE between requestHash and fullRequest. 
However there is no indication to know when each option shall be used. If 
requestHash is used, then the information is not sufficient. If fullRequest 
is used then the response is rather big and includes useless information. 
Ideally a combination of requestHash and of CertReference and the policy 
(with optional parameters when needed) would do the job. The requirement is 
partly met.

Point 16. The full OCSP response (for multiple certificate queries) is 
signed but not individual responses (for a single certificate). This forbids 
storing individual signed responses to prove later on that the individual 
response was correct. The functionality is supported, but not in an optimum way.

Point 17. The requirement is met.

Point 18. The requestor is unrelated to the authentication of the client. 
The requirement is not met.

Point 19. The requestor item is used to detect relay loops, but it is also 
used for another purpose. This currently forbids that the identifier 
includes any zero octets. The requirement is not met.

Point 20. The use of uses the requestor item to detect relay loops is not 
appropriate, since requestor serves for two and even three different 
purposes. The requirement is not met.

Point 21. SCVP does not support referrals. The requirement is not met.

Point 22. The requirement is not met since requestor serves for two and even 
three different purposes.

Point 23. The requirement is met.

Point 24. The use of the server default policy does not allow to know which 
policy has been used. The requirement is only partly met.

Point 25. The use of a mixture of policy and other parameters (valPolicy and 
trustAnchors) does not allow to support, as indicated in the matrix, an OID 
followed by additional parameters. The requirement is not met.

Point 26. The requirement is met.

Point 27. The requirement is met.

Point 28. The requirement is met.

Point 29. The requirement is met.

Point 30. The requirement is met.

Point 31. The requirement is met.

Point 32. The requirement is met.

Point 33. The requirement is met.

Point 34. The requirement is met.

Point 35. On one side SCVP defines the syntax of a validation policy as an 
OID followed by optional parameters, but on other side SCVPO defines a 
default policy which does not conform to this. The requirement is partly 
met, or will be met if the default policy concept is withdrawn.

Denis



Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h0RAIID26675 for ietf-pkix-bks; Mon, 27 Jan 2003 02:18:18 -0800 (PST)
Received: from odin2.bull.net (odin2.bull.net [192.90.70.84]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h0RAICo26658 for <[e-mail]>; Mon, 27 Jan 2003 02:18:14 -0800 (PST)
Received: from clbull.frcl.bull.fr (clbull.frcl.bull.fr [129.182.8.31]) by odin2.bull.net (8.9.3/8.9.3) with ESMTP id LAA27232 for <[e-mail]>; Mon, 27 Jan 2003 11:20:03 +0100
Received: from bull.net (frcls4013.frcl.bull.fr [129.182.108.120]) by clbull.frcl.bull.fr (8.9.2/8.9.1) with ESMTP id LAA15208 for <[e-mail]>; Mon, 27 Jan 2003 11:18:14 +0100
Message-ID: <[e-mail]>
Date: Mon, 27 Jan 2003 11:18:09 +0100
From: Denis Pinkas <[e-mail]>
Organization: Bull SA.
User-Agent: Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.0.1) Gecko/20020823 Netscape/7.0
X-Accept-Language: en-us, en, fr
MIME-Version: 1.0
To: pkix <[e-mail]>
Subject: Rating of the DVCS Compliance Matrix
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Rating of the DVCS Compliance Matrix

The following rating is my own rating.

SUMMARY

The requirements that are met correspond to the following points:
6, 9, 15, 16, 17 and 18. The overall rating is thus: 6/35.

EXPLANATIONS

Since DVCS does not distinguish between DPV and DPD, DPD is not supported as 
requested by RFC 3379. So the conformance points 23 to 35 should be rated 0.

For the other conformance points:

Point 1. If the policy field is missing, "any policy" is not acceptable. The 
requirement is not met.

Point 2. Since policy is optional in the response, the "MUST" requirement is 
not met.

Point 3. The description of TargEtcChain is insufficient to under stand how 
the structure SHALL be used to support the feature.

Point 4. No handling is indicated.

Point 5. No specific error returned.

Point 6. Rather complicated, but the functionality is there.

Point 7. There is no concept of useful certificates, CRLs or OCSP responses. 
On the contrary in page 20 what is provided MUST be used. The point is not met.

Point 8. The text does not say it.

Point 9. The requirement is met.

Point 10. The requirement is not met, since the PKIstatus does not allow to 
report all the cases.

Point 11. The requirement is not met, since the PKIstatus does not allow to 
report all the cases.

Point 12. The chaining of nonces as described does not work. Nonce is an 
integer and a concatenation of nonces as integers does not work. The 
requirement is not met.

Point 13. There is no way to make to request this feature. The requirement 
is  not met.

Point 14. It is unclear how the requestPolicy in DVCSRequestInformation and 
policy in DVCSCertInfo work together. They seem to conflict.

Point 15. The requirement is supported, but since the full request is 
copied, this is not optimum.

Point 16. The full response (for multiple certificates) is signed but not 
individual responses (for a single certificate). This forbids storing 
individual signed responses to prove later on that the individual response 
was correct. The functionality is supported, but not in an optimum way.

Point 17. The requirement is met.

Point 18. The requirement is met.

Point 19. Relaying is supported through embedded signed responses which 
overload the client. So the requirement is not met.

Point 20. There are no explanations about how to detect loops. The 
requirement is not met.

Point 21. The requirement is not met.

Point 22. There is no support of re-direction. The requirement is not met.

Denis




Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h0RAHVw26557 for ietf-pkix-bks; Mon, 27 Jan 2003 02:17:31 -0800 (PST)
Received: from odin2.bull.net (odin2.bull.net [192.90.70.84]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h0RAHQo26537 for <[e-mail]>; Mon, 27 Jan 2003 02:17:27 -0800 (PST)
Received: from clbull.frcl.bull.fr (clbull.frcl.bull.fr [129.182.8.31]) by odin2.bull.net (8.9.3/8.9.3) with ESMTP id LAA23548 for <[e-mail]>; Mon, 27 Jan 2003 11:19:14 +0100
Received: from bull.net (frcls4013.frcl.bull.fr [129.182.108.120]) by clbull.frcl.bull.fr (8.9.2/8.9.1) with ESMTP id LAA13880 for <[e-mail]>; Mon, 27 Jan 2003 11:17:25 +0100
Message-ID: <[e-mail]>
Date: Mon, 27 Jan 2003 11:17:19 +0100
From: Denis Pinkas <[e-mail]>
Organization: Bull SA.
User-Agent: Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.0.1) Gecko/20020823 Netscape/7.0
X-Accept-Language: en-us, en, fr
MIME-Version: 1.0
To: pkix <[e-mail]>
Subject: Rating of the "DPV and DPD over OCSP" Compliance Matrix
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Rating of the "DPV and DPD over OCSP" Compliance Matrix

The following rating is my own rating.

SUMMARY

The overall rating is: 14/35.
The following points are met: 5, 6, 8, 9, 12, 16, 17, 18, 23, 26, 27, 28, 31 
and 33.


GENERAL COMMENTS

The DPV service is supported as an extension to OCSP. This means that the 
server MUST always support OCSP (i.e. provide the revocation status of the 
certificate) and provide a usual OCSP response with a major status relative 
to that OCSP request. However, a DPV server may well support certificate 
validation only using CRLs and no OCSP information at all. So it SHALL 
always provide an OCSP response, even if only CRLs are provided for the 
certificate to be validated.

If the major status from RFC 2560 is unknown, then it is quite artificial to 
support DPD through OCSP since the certification path could be returned, but 
not the revocation status of the certificate.

It should also be noticed that OCSP responses are always signed, whereas 
this is not a requirement for DPD (neither for DPV).

Renaming OCSP "ORS" for " On-line revocation Service" is not acceptable 
since this would confuse the PKIX community.


EXPLANATIONS

Point 1. "unsupportedPolicy" is not currently supported. The requirement is 
not met.

Point 2. ExtendedOCSP response indicates which policy has been used. 
However, a NULL OID is allowed which does not allow to know which policy has 
been used. In addition, if the policy includes parameters, these parameters 
are not indicated in the response. The requirement is not met.

Point 3. Trust points may not be enough. Since it is not possible to add 
additional parameters, this way to specify the parameters of the policy is 
not sufficient. revInfo from the request is not explained. Does it relate to 
useful certificates ? The requirement is not met.

Point 4. Not supported: the requirement is not met.

Point 5. The requirement is met.

Point 6. The requirement is met.

Point 7. revInfo is indeed part of the ExtendedOCSPRequest but not 
pathParams as indicated. DPVOptions is not part of the ExtendedOCSPRequest 
but of the ExtendedOCSPResponse. DPVOptions is not defined. The requirement 
is not met

Point 8. The requirement is met through the basic OCSP response.

Point 9. The requirement is met.

Point 10. The RFC2560 status does NOT govern production of errors for this 
extension. The requirement cannot be met by changing the meaning of the 
basic OCSP response. It could have been met if a separate status was 
provided in the ExtendedOCSPResponse. Since this is not the case, the 
requirement is not met.

Point 11. There is no detailed description of Reasons which is an octet 
string. The requirement is not met.

Point 12. The requirement is met.

Point 13. Flags allows to select what to be returned. However the way it is 
done is not appropriate for DPV since a single flag should be used to return 
all what is necessary to be compliant with the policy. The client being 
ignorant of the content of the policy cannot determine specifically what is 
to be returned. The requirement is not met.

Point 14. Since token is an OCTET STRING, it is not appropriate for a text 
field. The name of that field is not appropriate either. The requirement is 
not met.

Point 15. The requirement is met, but not using the explanations that are 
provided. There are met using paramHash, policy and reqCert from the basic 
OCSP. There are not met using DPVOptions which is left unspecified.

Point 16. The full OCSP response (for multiple certificate queries) is 
signed but not individual responses (for a single certificate). This forbids 
storing individual signed responses to prove later on that the individual 
response was correct. The functionality is supported, but not in an optimum way.

Point 17. The requirement is met.

Point 18. The requirement is met.

Point 19. The requirement is not met.

Point 20. The requirement is not met.

Point 21. The requirement is not met.

Point 22. The requirement is not met.

Point 23. The flags for Flags enable to request various information, but it 
is not specified that this is fully independent from validation, e.g. that 
the server shall not validate the certificate but only return the 
certification path. It seems that numPath present is the way to identify a 
DPD request from a DPV request. The requirement is met, but the text should 
be improved.

Point 24. Reporting errors relative to the extension through the major 
status of RFC 2560 not appropriate. The requirement is not met.

Point 25. More elaborated policies cannot be fully supported only using 
trust points. The requirement is not met.

Point 26. The requirement is met.

Point 27. The requirement is met.

Point 28. The requirement is met, not in an optimum way since all paths (up 
to the number that has been requested) are returned at once.

Point 29. The presence or absence of some fields does not allow to support 
all the options that are mentioned. Some additional flags or status are 
needed. The requirement is not met.

Point 30. RFC2560 does not enable responder signatures, but mandates them. 
The requirement is not met.

Point 31. The explanations that are provided about the use of lower layer 
security are not appropriate. However, since RFC 250 support optional 
signatures from the client, the requirement is met.

Point 32. The requirement is not met.

Point 33. No response provided. However, it may be supposed that this 
requirement is met.

Point 34. The requirement is not met.

Point 35. The requirement is not met.

Denis



Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h0R8hm014705 for ietf-pkix-bks; Mon, 27 Jan 2003 00:43:48 -0800 (PST)
Received: from maile.telia.com (maile.telia.com [194.22.190.16]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h0R8hlo14693 for <[e-mail]>; Mon, 27 Jan 2003 00:43:47 -0800 (PST)
Received: from arport (h220n2fls31o1122.telia.com [212.181.142.220]) by maile.telia.com (8.12.5/8.12.5) with SMTP id h0R8hfZj013312; Mon, 27 Jan 2003 09:43:41 +0100 (CET)
X-Original-Recipient: [e-mail]
Message-ID: <004301c2c5df$d8eec220$0500a8c0@arport>
From: "Anders Rundgren" <[e-mail]>
To: =?iso-8859-1?Q?Michael_Str=F6der?= <[e-mail]>
Cc: "Peter Gutmann" <[e-mail]>, <[e-mail]>
References: <[e-mail]>            <[e-mail]> <[e-mail]> <[e-mail]>
Subject: Lookup from DNS was: X.500, LDAP Considered harmful
Date: Mon, 27 Jan 2003 09:41:12 +0100
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.50.4133.2400
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Michael,

>One could imagine other forms of using dc-style LDAP DNs and SRV RRs, e.g. 
>look at the domain part of an e-mail address and query the SRV RR for it.

>Send encrypted S/MIME e-mail to [e-mail]:

>look up SRV RR for _ldap._tcp.stroeder.com
-> mydirectory.stroeder.com 389 0 0

>Retrieve e.g. encryption cert for [e-mail]:

>ldap://mydirectory.stroeder.com/dc=stroeder,dc=com?userCertificate?sub?(mail=[e-mail])
>-> certificate


And the following would be the equivalent using this "other" system.

definitions in "stroeder.com" DNS:

   _certs._tcp   SRV   0  1  1  certstore.stroeder.com
   certstore      A     62.119.75.13
   certstore      TXT   https://certstore.stroeder.com/certapp

Note that _certs._tcp is just a handle, as the associated TXT-record
contains the actual URL

After DNS lookup you would query: 
"https://certstore.stroeder.com/certapp?email=[e-mail]"

Note: This is not a part of the HTTP CertStore draft, but it could be :-)

cheers,
Anders




Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h0R6keG23782 for ietf-pkix-bks; Sun, 26 Jan 2003 22:46:40 -0800 (PST)
Received: from nic.lp.se (nic.lp.se [212.247.5.91]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h0R6kco23777 for <[e-mail]>; Sun, 26 Jan 2003 22:46:39 -0800 (PST)
Received: from localhost (217.215.93.181) by nic.lp.se (MX V5.3 VnHj) with ESMTP; Mon, 27 Jan 2003 07:44:54 +0100
Date: Mon, 27 Jan 2003 07:39:04 +0100 (CET)
Message-ID: <[e-mail]>
To: [e-mail]
CC: [e-mail]
Subject: Re: X.500, LDAP Considered harmful Was: OCSP/LDAP
From: Richard Levitte - VMS Whacker <[e-mail]>
In-Reply-To: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]>
X-URL: http://www.lp.se/
X-Waved: dead chicken, GNU emacs 21.2.2, Mew version 3.1
X-Mew: See http://www.mew.org/
X-Mailer: Mew version 3.1 on Emacs 21.2 / Mule 5.0 (SAKAKI)
MIME-Version: 1.0
Content-Type: Text/Plain; charset=iso-8859-1
Content-Transfer-Encoding: 8bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

In message <[e-mail]> on Mon, 27 Jan 2003 01:56:54 +0100, Michael Ströder <[e-mail]> said:

michael> > The real problem with such a network would be searching for anything
michael> > else than DNs.
michael> 
michael> ???

For example, say we want to find all records that match a certain
value with the attribute x509SubjectKeyIdentifier (from
draft-klasen-ldap-x509certificate-schema-01.txt), would that be
searchable in the imagined LDAP network?

-- 
Richard Levitte     | http://richard.levitte.org/ | Spannv. 38, I
Levitte Programming | http://www.lp.se/           | S-168 35 Bromma
T: [phone] |                             | SWEDEN
     "Price, performance, quality...  choose the two you like"


Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h0R6OJs23226 for ietf-pkix-bks; Sun, 26 Jan 2003 22:24:19 -0800 (PST)
Received: from hermes.cs.auckland.ac.nz (hermes.cs.auckland.ac.nz [130.216.35.151]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h0R6OHo23222 for <[e-mail]>; Sun, 26 Jan 2003 22:24:18 -0800 (PST)
Received: from medusa01.cs.auckland.ac.nz (medusa01.cs.auckland.ac.nz [130.216.34.60]) by hermes.cs.auckland.ac.nz (8.12.4/8.12.4) with ESMTP id h0R6OEOr003811; Mon, 27 Jan 2003 19:24:14 +1300
Received: (from pgut001@localhost) by medusa01.cs.auckland.ac.nz (8.11.6/8.11.6) id h0R6PEq00790; Mon, 27 Jan 2003 19:25:14 +1300
Date: Mon, 27 Jan 2003 19:25:14 +1300
Message-Id: <[e-mail]>
From: [e-mail] (Peter Gutmann)
To: [e-mail], [e-mail]
Subject: RE: X.500, LDAP Considered harmful Was: OCSP/LDAP
Cc: [e-mail], [e-mail], [e-mail]
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

"Blake Ramsdell" <[e-mail]> writes:

>But I'm not sure we can say with a straight face that this isn't beating LDAP
>with a hammer to make it more like we want it.

I've just looked at draft-klasen-ldap-x509certificate-schema-01 and it seems
to be an RFC describing how to make an LDAP directory act like an RDBMS.  So
for example:

ldap:///?caCertificate?sub?
   	(&(objectClass=x509certificate)(x509subjectKeyIdentifier=%5CE6
   	 %5C7A%5CD9%5C16%5C95%5C4A%5CE1%5C12%5C9F%5C22%5C09%5C6A%5C43%
   	 5C83%5C78%5C25%5C70%5C52%5CE0%5C19))

is SELECT certificate WHERE sKID = ..., and so on.

I don't know whether I should laugh or cry.

Peter.


Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h0R62YK22671 for ietf-pkix-bks; Sun, 26 Jan 2003 22:02:34 -0800 (PST)
Received: from brutesquadlabs.com (gtec136-m.isomedia.com [207.115.67.136] (may be forged)) by above.proper.com (8.11.6/8.11.3) with ESMTP id h0R62Yo22667 for <[e-mail]>; Sun, 26 Jan 2003 22:02:34 -0800 (PST)
Received: from DEXTER ([192.168.0.4]) by brutesquadlabs.com with ESMTP ; Sun, 26 Jan 2003 22:02:30 -0800
From: "Blake Ramsdell" <[e-mail]>
To: "'Richard Levitte - VMS Whacker'" <[e-mail]>
Cc: <[e-mail]>, <[e-mail]>, <[e-mail]>
Subject: RE: X.500, LDAP Considered harmful Was: OCSP/LDAP
Date: Sun, 26 Jan 2003 22:03:01 -0800
Message-ID: <!~!UENERkVCMDkAAQACAAAAAAAAAAAAAAAAABgAAAAA[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook, Build 10.0.2627
In-reply-to: <[e-mail]>
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106
Importance: Normal
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

> -----Original Message-----
> From: [e-mail] 
> [mailto:[e-mail]] On Behalf Of Richard 
> Levitte - VMS Whacker
> Sent: Sunday, January 26, 2003 8:34 AM
> To: [e-mail]
> Cc: [e-mail]; [e-mail]; [e-mail]
> Subject: Re: X.500, LDAP Considered harmful Was: OCSP/LDAP
> 
> I see two things that could provide this today: HTTP and LDAP.  The
> former via draft-ietf-pkix-certstore-http-03, the latter via RFC 2587
> and draft-klasen-ldap-x509certificate-schema-01 (which, BTW, contains
> the attributes I was looking for), just as examples.  And from that
> point of view, since LDAP repositories are searchable on attribute
> values, I'm not sure it's that bad.  Of course, proper DNs will help
> as well...

Well, the HTTP seems fairly new, and I have actually already implemented
it in about 15 minutes on top of my proprietary certificate database.
Now, it's not widely deployed yet, but it's certainly easy to implement
;).  Parse query, call database, return results.

The LDAP citation that you (and Michael) point out was something that I
hadn't seen, so that answers my "how do I make this query" question.

Now to find a server that implements either of these.  Well, the HTTP
one I just wrote myself, so an LDAP one would be useful.

> For me, the above is more sufficient than anything based on SQL that
> I've seen so far...

Yeah, but don't tell anyone -- my certstore implementation is SQL
underneath.

I think that the certstore "facade" makes the most sense in the long
run, and you just bridge that as necessary to LDAP or a SQL server, and
hide your shame about which one you use.

> I must be missing something.  What exactly is LDAP not designed to do
> in this context?

My understanding of the philosophy is that it's a hierarchical directory
based on DN attributes, each leaf entry containing some number of
attributes corresponding to the entity represented by that leaf.  You
can search relative to a RDN base, providing search criteria in the form
of attribute=value pairs that are attributes that occur in the node that
you're searching for, and specify which attributes of that node you'd
like returned.

As I understand this LDAP draft, it says that each certificate be in its
own entry in the directory, and these entries will have additional
attributes that are equality-searchable for the queries that we've been
talking about.  So the certificates become the leaves of the directory,
instead of a higher-level logical entity which owns the certificates.
Not sure this is really a problem, and it's not the first such deviation
from the original intent (subject DNs of certificates have nothing to do
in most cases with the DN representing that entity in the directory).
But I'm not sure we can say with a straight face that this isn't beating
LDAP with a hammer to make it more like we want it.

Blake



Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h0R5isJ22288 for ietf-pkix-bks; Sun, 26 Jan 2003 21:44:54 -0800 (PST)
Received: from nymelsmtp.internet.ny.fdms.firstdata.com (nymelsmtp01.firstdata.com [198.184.0.23]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h0R5iqo22284 for <[e-mail]>; Sun, 26 Jan 2003 21:44:52 -0800 (PST)
Subject: Re: X.500, LDAP Considered harmful Was: OCSP/LDAP
To: Dean Povey <[e-mail]>
Cc: [e-mail], [e-mail], Tony Bartoletti <[e-mail]>, [e-mail], "Hallam-Baker, Phillip" <[e-mail]>, [e-mail], [e-mail]
X-Mailer: Lotus Notes Release 5.0.5  September 22, 2000
Message-ID: <[e-mail]>
From: [e-mail]
Date: Sun, 26 Jan 2003 22:46:09 -0700
X-MIMETrack: Serialize by Router on NYMELSMTP/NY/FDMS/FDC(Release 5.0.8 |June 18, 2001) at 01/27/2003 12:46:37 AM
MIME-Version: 1.0
Content-type: text/plain; charset=us-ascii
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

my original suggestion for SSL "certificates" stored in DNS .... was to
just use signed something slightly more than signed public keys. as opposed
to full x.509 asn.1 encoded certificates ... and piggyback it with the
ip-address response. that easily fits within the 512-byte limit. if you
want additional information .... you do the more detailed queries for the
additional information associated with a domain name ... however you don't
get all the additional information that might be bound to a domain name
unless you expressly ask for it.

to some extent because certificates bind information statically at some
point in the past with possibly no real anticipation for all the uses it
might be put ... there is a tendency to try and pack as much as possible
in the static binding. going to a much more dynamic infrastructure would
mitigate significantly trying to maximize value of a static information
certificate binding (and thereby creating worst case payload bloat for all
cases).

nslookup example  ...

> help
Commands:   (identifiers are shown in uppercase, [] means optional)
NAME            - print info about the host/domain NAME using default
server
NAME1 NAME2     - as above, but use NAME2 as server
help or ?       - print info on common commands
set OPTION      - set an option
    all                 - print options, current server and host
    [no]debug           - print debugging information
    [no]d2              - print exhaustive debugging information
    [no]defname         - append domain name to each query
    [no]recurse         - ask for recursive answer to query
    [no]search          - use domain search list
    [no]vc              - always use a virtual circuit
    domain=NAME         - set default domain name to NAME
    srchlist=N1[/N2/.../N6] - set domain to N1 and search list to N1,N2,
etc.
    root=NAME           - set root server to NAME
    retry=X             - set number of retries to X
    timeout=X           - set initial time-out interval to X seconds
    type=X              - set query type (ex.
A,ANY,CNAME,MX,NS,PTR,SOA,SRV)
    querytype=X         - same as type
    class=X             - set query class (ex. IN (Internet), ANY)
    [no]msxfr           - use MS fast zone transfer
    ixfrver=X           - current version to use in IXFR transfer request
server NAME     - set default server to NAME, using current default server
lserver NAME    - set default server to NAME, using initial server
finger [USER]   - finger the optional NAME at the current default host
root            - set current default server to the root
ls [opt] DOMAIN [> FILE] - list addresses in DOMAIN (optional: output to
FILE)
    -a          -  list canonical names and aliases
    -d          -  list all records
    -t TYPE     -  list records of the given type (e.g. A,CNAME,MX,NS,PTR
etc.)
view FILE           - sort an 'ls' output file and view it with pg

============================

also some discussion in rfc2151/fyi30, Internet & TCP/IP Tools & Utilities,
Section 3. Finding Information About Internet Hosts and Domains).
http://www.garlic.com/~lynn/rfcidx7.htm#2151

2151
A Primer On Internet and TCP/IP Tools and Utilities, Kessler G., Shepard
S., 1997/06/10 (52pp) (.txt=114130) (FYI-30) (Obsoletes 1739)

from above:

One additional query is shown in the dialogue below. NSLOOKUP examines
information that is stored by the DNS. The default NSLOOKUP queries examine
basic address records (called "A records") to reconcile the host name and
IP address, although other information is also available. In the final
query below, for example, the user wants to know where electronic mail
addressed to the hill.com domain
actually gets delivered, since hill.com is not the true name of an actual
host. This is accomplished by changing the query type to look for mail
exchange (MX) records by issuing a set type command (which must be in lower
case). The query shows that mail addressed to hill.com is actually sent to
a mail server called mail.hill.com. If that system is not available, mail
delivery will be attempted to first mailme.hill.com and then to
netcomsv.netcom.com; the order of these attempts is controlled by the
"preference" value. This query also returns the name of the domain's name
servers and all associated IP addresses.

The DNS is beyond the scope of this introduction, although more information
about the concepts and structure of the DNS can be found in STD 13/RFC 1034
[19], RFC 1591 [21], and Kessler [16]. The help command can be issued at
the program prompt for information about NSLOOKUP's more advanced commands.

===

http://www.garlic.com/~lynn/rfcidx3.htm#1035

1035 S
Domain names - implementation and specification, Mockapetris P., 1987/11/01
(55pp) (.txt=122549) (STD-13) (Updated by 1101, 1183, 1876, 1982, 1995,
1996, 2136, 2181, 2308, 2535, 2845, 3425) (DOMAIN)

http://www.garlic.com/~lynn/rfcidx5.htm#1591

1591
Domain Name System Structure and Delegation, Postel J., 1994/03/03 (7pp)
(.txt=16481)

somewhat related discussions:
http://www.garlic.com/~lynn/aepay10.htm#78 ssl certs
http://www.garlic.com/~lynn/aepay10.htm#79 ssl certs
http://www.garlic.com/~lynn/aepay10.htm#80 Invisible Ink, E-signatures slow
to broadly catch on (addenda)
http://www.garlic.com/~lynn/aepay10.htm#81 SSL certs & baby steps
http://www.garlic.com/~lynn/aepay10.htm#82 SSL certs & baby steps (addenda)
http://www.garlic.com/~lynn/aepay10.htm#83 SSL certs & baby steps
http://www.garlic.com/~lynn/aepay10.htm#84 Invisible Ink, E-signatures slow
to broadly catch on (addenda)

--
Internet trivia, 20th anv: http://www.garlic.com/~lynn/rfcietff.htm


[e-mail] on 1/26/2003 6:10 pm wrote:


While I don't disagree with your argument about X.500, there are real
practical problems with using DNS for storing Certificates (if that is
indeed what you mean by a DNS linked PKI).  RFC2538 notwithstanding, the
problem is that storing large objects like Certificates in DNS generally
necessitates TCP transfers as they will exceed the magic 512 byte limit
at which servers will generally truncate packets. Using TCP means that DNS
which is a generally stateless service, now has to keep connection state
with clients opening up all sorts of room for DOS and simple performance
problems with what is a critical service. In addition, it is common for
admins to configure firewalls so that TCP DNS is filtered to prevent zone
transfers.




Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h0R4N3Y20060 for ietf-pkix-bks; Sun, 26 Jan 2003 20:23:03 -0800 (PST)
Received: from hermes.cs.auckland.ac.nz (hermes.cs.auckland.ac.nz [130.216.35.151]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h0R4N1o20055 for <[e-mail]>; Sun, 26 Jan 2003 20:23:01 -0800 (PST)
Received: from medusa01.cs.auckland.ac.nz (medusa01.cs.auckland.ac.nz [130.216.34.60]) by hermes.cs.auckland.ac.nz (8.12.4/8.12.4) with ESMTP id h0R4N0Or002481; Mon, 27 Jan 2003 17:23:00 +1300
Received: (from pgut001@localhost) by medusa01.cs.auckland.ac.nz (8.11.6/8.11.6) id h0R4O0r28034; Mon, 27 Jan 2003 17:24:00 +1300
Date: Mon, 27 Jan 2003 17:24:00 +1300
Message-Id: <[e-mail]>
From: [e-mail] (Peter Gutmann)
To: [e-mail], [e-mail]
Subject: Re: X.500, LDAP Considered harmful Was: OCSP/LDAP
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

=?ISO-8859-1?Q?Michael_Str=F6der?= <[e-mail]> writes:
>Blake Ramsdell wrote:
>>You're missing Peter's point here
>
>I don't.

Yes you do.  Trust me, as the person who wrote the post, you're missing its
point completely :-).  My point was that examining the problem that needs
solving, seeing that it's an application of {key,value} lookup (which I
expressed in SQL-like notation because it's the natural way to express these
things), and then finding the best technology to do this, is the way to go
forward.

>Maybe the use-cases should be cleanly modeled.

They are (see my ACSAC paper, which goes into a lot more detail, including
things like real-world deployment issues), and my earlier post.  To quote the
earlier rant:

  cryptlib supports any kind of cert storage mechanism that you can think of
  (flat files, DBMS, Berkeley DB, LDAP, PGP keyrings, PKCS #11, etc etc etc,
  including some semi-proprietary backends like named segments in flash
  memory).  The most frequently-used one is the DBMS interface (that is, the
  {key,value} lookup model), although there's a fair bit of usage of LDAP as
  well.  In terms of difficulty encountered in using it, no-one has ever,
  *ever* reported a single problem with the {key,value} interface (beyond
  compiling/linking, e.g. using an old version of the Oracle libs or
  something).  In contrast LDAP is the most problematic cert-storage interface
  there is, with an almost continuous flow of questions about the magic
  formulae needed to locate a cert (see above), problems with storing certs
  when the DN doesn't agree with the directory schema, or schema A doesn't
  agree with schema B, and every other LDAP problem that people on this list
  are all too familiar with.  Some people never get cert storage with LDAP
  working at all, and give up.
  
  This is real-world experience talking here folks, from a worldwide user
  base: {key,value} lookup works with zero problems, LDAP has endless
  problems.  I don't care about database or X.500 ideology or theology or
  proctology, the fact is that in practice one approach works and the other
  doesn't, and no amount of whining about "Well in theory we could maybe make
  it work some of the time, and here's an imaginary problem where yours won't
  work and ours will" is going to change that.

Peter.


Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h0R4I5g19913 for ietf-pkix-bks; Sun, 26 Jan 2003 20:18:05 -0800 (PST)
Received: from hermes.cs.auckland.ac.nz (hermes.cs.auckland.ac.nz [130.216.35.151]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h0R4I3o19908 for <[e-mail]>; Sun, 26 Jan 2003 20:18:03 -0800 (PST)
Received: from medusa01.cs.auckland.ac.nz (medusa01.cs.auckland.ac.nz [130.216.34.60]) by hermes.cs.auckland.ac.nz (8.12.4/8.12.4) with ESMTP id h0R4I2Or002426; Mon, 27 Jan 2003 17:18:02 +1300
Received: (from pgut001@localhost) by medusa01.cs.auckland.ac.nz (8.11.6/8.11.6) id h0R4J3e27779; Mon, 27 Jan 2003 17:19:03 +1300
Date: Mon, 27 Jan 2003 17:19:03 +1300
Message-Id: <[e-mail]>
From: [e-mail] (Peter Gutmann)
To: [e-mail], [e-mail]
Subject: Re: X.500, LDAP Considered harmful Was: OCSP/LDAP
Cc: [e-mail]
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

[Warning: The previous reply was short and to the point.  This reply is a bit
 of a longer rant, although it should be entertaining :-).  At least the first
 half is mostly technical]

=?ISO-8859-1?Q?Michael_Str=F6der?= <[e-mail]> writes:
>I see no reason why
>
>SELECT cert FROM foo WHERE key = bar
>
>(note that you left out the host connection part)
>
>is less complex than
>
>ldap://host.domain/o=foo?userCertificate?sub?(key=bar)

Thankyou Michael, you've just agreed with me by expressing the exact
{key,value} lookup I described as an LDAP query (rather than the usual
hierarchical filter that you're supposed to use with LDAP).  The only
difference between doing it with a real {key,value} lookup system (e.g.
Berkeley DB, DBMS) and LDAP is that half the time the LDAP admin has it turned
off because the whole directory grinds to a halt if you run more than one
global query at a time.

Two points to note:

- LDAP is never used in this way.  It's always used with extraordinarily
  complex filters that no normal human can figure out.  When I was documenting
  use of LDAP in the cryptlib manual, I went around a variety of CAs (the ones
  that publish the filters you need to use on their web pages), and also asked
  users for contributions - I wanted to include some examples that people
  could cut and paste.  The filters ranged in size from two lines to complete
  paragraphs, and all were completely different and to all but a select few
  X.500 cogniscenti, utterly incomprehensible, making them essentially useless
  as examples.  In the end I inserted a few of the shorter ones to show what a
  typical filter would look like, but couldn't do much more with them.
  
  One user who sent in some filters suggested that CAs were using these as
  access control mechanisms, since only the people who knew the correct magic
  incantation could ever locate a cert, and the only way to do that was to
  have the CA tell you what the incantation was.

- If you're concerned about efficiency, an LDAP directory can never, ever be
  better than a {key,value} lookup (e.g. Berkeley DB or a DBMS, NDS is a bit
  of an exception here).  The reason for this is that the client takes a basic
  SELECT foo WHERE key = bar query, reformats it as a complex LDAP filter, and
  sends it to a server that has to then translate the LDAP filter back into
  the original SELECT foo WHERE key = bar form for the {key,value} lookup, and
  then submit it to the underlying database, typically Berkeley DB (small-
  scale LDAP) or a DBMS (industrial-strength LDAP).  No matter how efficient
  you make the LDAP process, the extra bloat and overhead always make it less
  efficient than a direct query to the underlying database without the LDAP
  four-year-old-eating-peas process getting in the way.

A data point on usability:

  cryptlib supports any kind of cert storage mechanism that you can think of
  (flat files, DBMS, Berkeley DB, LDAP, PGP keyrings, PKCS #11, etc etc etc,
  including some semi-proprietary backends like named segments in flash
  memory).  The most frequently-used one is the DBMS interface (that is, the
  {key,value} lookup model), although there's a fair bit of usage of LDAP as
  well.  In terms of difficulty encountered in using it, no-one has ever,
  *ever* reported a single problem with the {key,value} interface (beyond
  compiling/linking, e.g. using an old version of the Oracle libs or
  something).  In contrast LDAP is the most problematic cert-storage interface
  there is, with an almost continuous flow of questions about the magic
  formulae needed to locate a cert (see above), problems with storing certs
  when the DN doesn't agree with the directory schema, or schema A doesn't
  agree with schema B, and every other LDAP problem that people on this list
  are all too familiar with.  Some people never get cert storage with LDAP
  working at all, and give up.
  
  This is real-world experience talking here folks, from a worldwide user
  base: {key,value} lookup works with zero problems, LDAP has endless
  problems.  I don't care about database or X.500 ideology or theology or
  proctology, the fact is that in practice one approach works and the other
  doesn't, and no amount of whining about "Well in theory we could maybe make
  it work some of the time, and here's an imaginary problem where yours won't
  work and ours will" is going to change that.

>>The
>>analogy I've used is that it's like watching a friend of mine's four-year-old
>>eat peas with a fork, she uses her fingers to put the peas on the fork, moves
>>it up to her mouth, then uses her fingers to move the peas off the fork into
>>her mouth, and everyone gets to say how clever she is to use a fork at her
>>age.  Certs in X.500 directories are the same thing.
>
>Peter, normally you're certainly doing better. Sorry, I file your postings
>about this topic under "Peter Gutmann's personal aversions against X.500
>directories". ;-)

This isn't any specific aversion to X.500 ("I was molested by a hierarchical
database as a child, your honour") but an aversion to, well, I'm not sure if
there's a specific term that exists to describe avoiding the obvious,
straightforward solution and instead choosing a complex, suboptimal one
because your ideology demands it, but purely for easy identification purposes
I'll label it "braindamage" here.  I'd be equally opposed to it if you said we
should use DCE for certificate distribution, or DCOM, or trained chimpanzees.
So although I'm flattered that you've singled me out for personal attention,
what you should really refer to is "everyone who knows anything about
databases' aversion to hierarchical databases, for the simple reason that they
don't work very well".  Although you've singled me out for special attention,
I know I'm in very good company - everyone who knows database technology
agrees with me.  In fact, the world's second largest (or largest, depending on
how the stock stands) software company exists solely from selling non-
hierarchical databases to anyone with a chequebook or credit card.  Larry
Ellison currently has a yacht^H^H^Hsmall ocean liner tied up down at the
waterfront here and is funding a multimillion-dollar sailing yacht that we'll
hopefully beat on the water, and that wasn't funded from building hierarchical
databases (I assume the X.500 creators aspire to one day owning a dingy on a
duckpond somwhere :-).  I know which way the wind's blowing, and it's not a
coincidence that we're racing against a yacht called Oracle and not one called
X.500 (actually I believe there was a ship called X.500, built in about 1912
and rediscovered in 1985 just in time for inclusion in OSI).

Peter.



Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h0R3weJ19245 for ietf-pkix-bks; Sun, 26 Jan 2003 19:58:40 -0800 (PST)
Received: from hermes.cs.auckland.ac.nz (hermes.cs.auckland.ac.nz [130.216.35.151]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h0R3wco19232 for <[e-mail]>; Sun, 26 Jan 2003 19:58:38 -0800 (PST)
Received: from medusa01.cs.auckland.ac.nz (medusa01.cs.auckland.ac.nz [130.216.34.60]) by hermes.cs.auckland.ac.nz (8.12.4/8.12.4) with ESMTP id h0R3wXOr002247; Mon, 27 Jan 2003 16:58:33 +1300
Received: (from pgut001@localhost) by medusa01.cs.auckland.ac.nz (8.11.6/8.11.6) id h0R3xSn27040; Mon, 27 Jan 2003 16:59:28 +1300
Date: Mon, 27 Jan 2003 16:59:28 +1300
Message-Id: <[e-mail]>
From: [e-mail] (Peter Gutmann)
To: [e-mail], [e-mail], [e-mail]
Subject: RE: X.500, LDAP Considered harmful Was: OCSP/LDAP
Cc: [e-mail]
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

"Blake Ramsdell" <[e-mail]> writes:

>You're missing Peter's point here -- the SELECT is not necessarily meant to
>be SQL, it's meant to convey that the single useful problem that a
>certificate database (be it X.500, SQL, whatever) solves is to return some
>number of certificates that exactly matches some search criteria.

This was exactly my point.  The process I went through in my ACSAC paper 
(http://www.cryptoapps.com/~peter/09a_cert_store.pdf if you want a copy) was:

  - Define the problem
  - Examine possible solutions
  - Take the best solution to the problem
  - Implement it and report results

OK, now that's "Scientific Method 101", but I mention it in order to contrast
the approach that lead to LDAP:

  - Decide on a way to do things
  - Wait for people to figure out how to make it happen.  Forever, if
    necessary.

Again, the exact details of the process are given in the ACSAC paper,
including various supplementary considerations like security and
accountability issues.

Peter.


Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h0R2qZH17529 for ietf-pkix-bks; Sun, 26 Jan 2003 18:52:35 -0800 (PST)
Received: from hermes.cs.auckland.ac.nz (hermes.cs.auckland.ac.nz [130.216.35.151]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h0R2qWo17525 for <[e-mail]>; Sun, 26 Jan 2003 18:52:33 -0800 (PST)
Received: from medusa01.cs.auckland.ac.nz (medusa01.cs.auckland.ac.nz [130.216.34.60]) by hermes.cs.auckland.ac.nz (8.12.4/8.12.4) with ESMTP id h0R2qUOr001661; Mon, 27 Jan 2003 15:52:30 +1300
Received: (from pgut001@localhost) by medusa01.cs.auckland.ac.nz (8.11.6/8.11.6) id h0R2rUd24480; Mon, 27 Jan 2003 15:53:30 +1300
Date: Mon, 27 Jan 2003 15:53:30 +1300
Message-Id: <[e-mail]>
From: [e-mail] (Peter Gutmann)
To: [e-mail], [e-mail], [e-mail]
Subject: Re: CERTSTORE's 160 bit limit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

"Anders Rundgren" <[e-mail]> writes:

>From the 03-draft I cannot deduct what length-limitations there
>are on the "name" and "email" search attributes.

It's defined in RFC 2068:

  The GET method is used in combination with a query URI to retrieve
  certificates from the underlying certificate store [RFC2068].

I didn't set any explicit length value because it's defined implicitly by RFC
2068.

Peter.


Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h0R1alN15828 for ietf-pkix-bks; Sun, 26 Jan 2003 17:36:47 -0800 (PST)
Received: from osprey.wedgetail.com (starling.wedgetail.com [202.83.95.124]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h0R1ajo15824 for <[e-mail]>; Sun, 26 Jan 2003 17:36:45 -0800 (PST)
Received: from coot.wedgetail.com (coot.wedgetail.com [10.10.10.4]) by osprey.wedgetail.com (8.12.5/8.12.5) with ESMTP id h0R1aWBk021725; Mon, 27 Jan 2003 11:36:32 +1000 (EST)
Message-Id: <[e-mail]>
X-Mailer: exmh exmh 2.5 (2001-07-13) with nmh-1.0.4
From: Dean Povey <[e-mail]>
To: "Hallam-Baker, Phillip" <[e-mail]>, Tony Bartoletti <[e-mail]>, [e-mail], [e-mail], [e-mail], [e-mail], [e-mail]
Subject: Re: X.500, LDAP Considered harmful Was: OCSP/LDAP 
In-reply-to: Your message of "Mon, 27 Jan 2003 11:10:39 +1000."
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Date: Mon, 27 Jan 2003 11:36:32 +1000
X-Scanned-By: MIMEDefang 2.15 (www dot roaringpenguin dot com slash mimedefang)
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

On Mon, 27 Jan 2003 11:10:39 +1000, Dean Povey wrote: 

>That said, I think the problem is largely solved by storing certs on a 
>HTTP server, indexed on some interesting attributes that can be specified 
>using standard HTTP GET uri?attr=value syntax.  With redirects this can 
>easily link directories for scalability and decentralised management.  All 
>that is required is to standardize the attributes and the replies.  The 
>major benefit is that this can be very easily supported in applications.  
>This was more or less the approach taken with PGP Keyservers, which have 
>proved to be very successful

Er, I had completely forgotten about Peter's "Certificate Store Access via
HTTP" draft which does pretty much exactly this. So, yes Peter, my point
exactly :-).

Mea Culpa.
-- 
Dean Povey,             |em: [e-mail]|Security for Network Devices
Wedgetail Communications|ph:  [phone]   |uPKI: Embedded/C PKI
Level 14, 388 Queen St, |fax: [phone]   |uSSL: Embedded/C SSL
Brisbane, Australia     |www: www.wedgetail.com |JCSI: Java security




Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h0R1B1Z15392 for ietf-pkix-bks; Sun, 26 Jan 2003 17:11:01 -0800 (PST)
Received: from osprey.wedgetail.com (starling.wedgetail.com [202.83.95.124]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h0R1Axo15384 for <[e-mail]>; Sun, 26 Jan 2003 17:10:59 -0800 (PST)
Received: from coot.wedgetail.com (coot.wedgetail.com [10.10.10.4]) by osprey.wedgetail.com (8.12.5/8.12.5) with ESMTP id h0R1AdBk021546; Mon, 27 Jan 2003 11:10:39 +1000 (EST)
Message-Id: <[e-mail]>
X-Mailer: exmh exmh 2.5 (2001-07-13) with nmh-1.0.4
From: Dean Povey <[e-mail]>
To: "Hallam-Baker, Phillip" <[e-mail]>
cc: Tony Bartoletti <[e-mail]>, [e-mail], [e-mail], [e-mail], [e-mail], [e-mail]
Subject: Re: X.500, LDAP Considered harmful Was: OCSP/LDAP 
In-reply-to: Your message of "Fri, 24 Jan 2003 14:42:46 PST." <[e-mail]> 
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Date: Mon, 27 Jan 2003 11:10:39 +1000
X-Scanned-By: MIMEDefang 2.15 (www dot roaringpenguin dot com slash mimedefang)
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

>What is needed is an infrastructure that is linked to the DNS
>system, a DNS linked PKI. The lookups supported should be in the
>terms the applications care about. For example the UseKeyWith
>semantics of XKMS. Similar semantics will no doubt be proposed
>for supported by the PKIX equivalent DPV specification.
>

While I don't disagree with your argument about X.500, there are real 
practical problems with using DNS for storing Certificates (if that is 
indeed what you mean by a DNS linked PKI).  RFC2538 notwithstanding, the 
problem is that storing large objects like Certificates in DNS generally 
necessitates TCP transfers as they will exceed the magic 512 byte limit 
at which servers will generally truncate packets. Using TCP means that DNS 
which is a generally stateless service, now has to keep connection state 
with clients opening up all sorts of room for DOS and simple performance 
problems with what is a critical service. In addition, it is common for 
admins to configure firewalls so that TCP DNS is filtered to prevent zone 
transfers.

That said, I think the problem is largely solved by storing certs on a 
HTTP server, indexed on some interesting attributes that can be specified 
using standard HTTP GET uri?attr=value syntax.  With redirects this can 
easily link directories for scalability and decentralised management.  All 
that is required is to standardize the attributes and the replies.  The 
major benefit is that this can be very easily supported in applications.  
This was more or less the approach taken with PGP Keyservers, which have 
proved to be very successful.
-- 
Dean Povey,             |em: [e-mail]|Security for Network Devices
Wedgetail Communications|ph:  [phone]   |uPKI: Embedded/C PKI
Level 14, 388 Queen St, |fax: [phone]   |uSSL: Embedded/C SSL
Brisbane, Australia     |www: www.wedgetail.com |JCSI: Java security




Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h0R0vV015237 for ietf-pkix-bks; Sun, 26 Jan 2003 16:57:31 -0800 (PST)
Received: from nb2.stroeder.com (krl9-d9bb4f93.pool.mediaWays.net [217.187.79.147]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h0R0vSo15233 for <[e-mail]>; Sun, 26 Jan 2003 16:57:29 -0800 (PST)
Received: from localhost (localhost.stroeder.com [127.0.0.1]) by nb2.stroeder.com (Postfix) with ESMTP id 2C2724F25B; Mon, 27 Jan 2003 01:56:56 +0100 (CET)
Received: from stroeder.com (localhost.stroeder.com [127.0.0.1]) by nb2.stroeder.com (Postfix) with ESMTP id 4E5854F218; Mon, 27 Jan 2003 01:56:55 +0100 (CET)
Message-ID: <[e-mail]>
Date: Mon, 27 Jan 2003 01:56:54 +0100
From: =?ISO-8859-1?Q?Michael_Str=F6der?= <[e-mail]>
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.2.1) Gecko/20021130
X-Accept-Language: de-de, de, en-us, en
MIME-Version: 1.0
To: Richard Levitte - VMS Whacker <[e-mail]>
Cc: [e-mail]
Subject: Re: X.500, LDAP Considered harmful Was: OCSP/LDAP
References: <[e-mail]>            <[e-mail]> <[e-mail]>
In-Reply-To: <[e-mail]>
X-Enigmail-Version: 0.71.0.0
X-Enigmail-Supports: pgp-inline, pgp-mime
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
X-Virus-Scanned: by AMaViS 0.3.12pre8
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id h0R0vUo15234
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Richard Levitte - VMS Whacker wrote:
> In message <[e-mail]> on Sun, 26 Jan 2003 18:48:14 +0100, Michael Ströder <[e-mail]> said:
> 
> michael> For LDAP there is a way using dc-style DNs and SRV RRs to
> michael> locate the directory. Some people insist on dc-style DNs not
> michael> widely used though (which is IMHO not true).
> 
> I'm not sure I agree with you (that it's not true).  I've seen masses
> of certificates with "classic" DNs, and none in DC-style (although
> there are enough people telling me they do exist for me to believe it
> :-)).

One could imagine other forms of using dc-style LDAP DNs and SRV RRs, e.g. 
look at the domain part of an e-mail address and query the SRV RR for it.

Send encrypted S/MIME e-mail to [e-mail]:

look up SRV RR for _ldap._tcp.stroeder.com
-> mydirectory.stroeder.com 389 0 0

Retrieve e.g. encryption cert for [e-mail]:

ldap://mydirectory.stroeder.com/dc=stroeder,dc=com?userCertificate?sub?(mail=[e-mail])
-> certificate

Note that in this example the subject DN in the cert can be anything.

> I'm imagining it would be possible to have a network of interconnected
> LDAP servers through referals, kind of the way DNS servers are
> interconnected today, with the only difference that the "zones" would
> be trees in the DN namespace.

Requires a naming authority for X.521 names though.

> With such a network, one would need to know a few LDAP roots, and the
> rest is about walking until there are no more answers or until one has
> found what one was looking for...

Well, that was the basic idea of X.500...

> The real problem with such a network would be searching for anything
> else than DNs.

???

Ciao, Michael.



Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h0QNEsv13849 for ietf-pkix-bks; Sun, 26 Jan 2003 15:14:54 -0800 (PST)
Received: from nic.lp.se (nic.lp.se [212.247.5.91]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h0QNEqo13845 for <[e-mail]>; Sun, 26 Jan 2003 15:14:53 -0800 (PST)
Received: from localhost (217.215.93.181) by nic.lp.se (MX V5.3 VnHj) with ESMTP; Mon, 27 Jan 2003 00:13:01 +0100
Date: Mon, 27 Jan 2003 00:09:58 +0100 (CET)
Message-ID: <[e-mail]>
To: [e-mail]
CC: [e-mail]
Subject: Re: X.500, LDAP Considered harmful Was: OCSP/LDAP
From: Richard Levitte - VMS Whacker <[e-mail]>
In-Reply-To: <[e-mail]>
References: <[e-mail]> <[e-mail]>
X-URL: http://www.lp.se/
X-Waved: dead chicken, GNU emacs 21.2.2, Mew version 3.1
X-Mew: See http://www.mew.org/
X-Mailer: Mew version 3.1 on Emacs 21.2 / Mule 5.0 (SAKAKI)
MIME-Version: 1.0
Content-Type: Text/Plain; charset=iso-8859-1
Content-Transfer-Encoding: 8bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

In message <[e-mail]> on Sun, 26 Jan 2003 18:48:14 +0100, Michael Ströder <[e-mail]> said:

michael> For LDAP there is a way using dc-style DNs and SRV RRs to
michael> locate the directory. Some people insist on dc-style DNs not
michael> widely used though (which is IMHO not true).

I'm not sure I agree with you (that it's not true).  I've seen masses
of certificates with "classic" DNs, and none in DC-style (although
there are enough people telling me they do exist for me to believe it
:-)).

However, that's beside the point.  Yes, of course, using DC-style DNs,
finding the repository is rather trivial.  But what about the rest of
the certs (the rather huge amount, I believe)?

I'm imagining it would be possible to have a network of interconnected
LDAP servers through referals, kind of the way DNS servers are
interconnected today, with the only difference that the "zones" would
be trees in the DN namespace.  I realise there would be difficulties
with this, but I don't see it as impossible (at least yet).
With such a network, one would need to know a few LDAP roots, and the
rest is about walking until there are no more answers or until one has
found what one was looking for...

The real problem with such a network would be searching for anything
else than DNs.  I've no idea if this is solvable (I may be missing
something in my LDAP education, for all I know), or if that just means
that the only way to search for a specific certificate in such a
network would be through subject or issuer+serialnumber, at least to
do things like validation.

Is this worth exploring or am I about to slam my head into a very
thick brick wall thinking about this (or both?)?

(note that some searches can still be made in basis of host names and
attributes on specific attributes.  Searching for an email address
(say [e-mail]) could start with finding out the LDAP repository
for random.tld, and then ask it directly)

-- 
Richard Levitte     | http://richard.levitte.org/ | Spannv. 38, I
Levitte Programming | http://www.lp.se/           | S-168 35 Bromma
T: [phone] |                             | SWEDEN
     "Price, performance, quality...  choose the two you like"


Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h0QKabV10957 for ietf-pkix-bks; Sun, 26 Jan 2003 12:36:37 -0800 (PST)
Received: from nb2.stroeder.com (krl9-d9bb4f93.pool.mediaWays.net [217.187.79.147]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h0QKaZo10953 for <[e-mail]>; Sun, 26 Jan 2003 12:36:36 -0800 (PST)
Received: from localhost (localhost.stroeder.com [127.0.0.1]) by nb2.stroeder.com (Postfix) with ESMTP id C111B4F218; Sun, 26 Jan 2003 21:35:58 +0100 (CET)
Received: from stroeder.com (localhost.stroeder.com [127.0.0.1]) by nb2.stroeder.com (Postfix) with ESMTP id 291474A1E6; Sun, 26 Jan 2003 21:35:58 +0100 (CET)
Message-ID: <[e-mail]>
Date: Sun, 26 Jan 2003 21:35:57 +0100
From: =?ISO-8859-1?Q?Michael_Str=F6der?= <[e-mail]>
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.2.1) Gecko/20021130
X-Accept-Language: de-de, de, en-us, en
MIME-Version: 1.0
To: Anders Rundgren <[e-mail]>
Cc: [e-mail]
Subject: Re: X.500, LDAP Considered harmful Was: OCSP/LDAP
References: <!~!UENERkVCMDkAAQACAAAAAAAAAAAAAAAAABgAAAAA[e-mail]> <[e-mail]> <002201c2c56c$2b0c4740$0500a8c0@arport> <[e-mail]> <005901c2c573$d9748c00$0500a8c0@arport>
In-Reply-To: <005901c2c573$d9748c00$0500a8c0@arport>
X-Enigmail-Version: 0.71.0.0
X-Enigmail-Supports: pgp-inline, pgp-mime
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
X-Virus-Scanned: by AMaViS 0.3.12pre8
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Anders Rundgren wrote:
> How do you explain the often very heated discussions on the PKIX-list
> regarding subject DNs as "pointers into DITs" versus "a bunch of attributes"?

It's an unnecessary academic discussion.

> Is this a problem in X.500/LDAP or isn't it?

It isn't provided you don't want to have the problem.

> This problem does not seem to be present in CertStore at least.

Yes.

Ciao, Michael.



Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h0QJoZn10134 for ietf-pkix-bks; Sun, 26 Jan 2003 11:50:35 -0800 (PST)
Received: from mailb.telia.com (mailb.telia.com [194.22.194.6]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h0QJoYo10119 for <[e-mail]>; Sun, 26 Jan 2003 11:50:34 -0800 (PST)
Received: from arport (h220n2fls31o1122.telia.com [212.181.142.220]) by mailb.telia.com (8.12.5/8.12.5) with SMTP id h0QJoY6R010793; Sun, 26 Jan 2003 20:50:34 +0100 (CET)
X-Original-Recipient: [e-mail]
Message-ID: <005901c2c573$d9748c00$0500a8c0@arport>
From: "Anders Rundgren" <[e-mail]>
To: =?iso-8859-1?Q?Michael_Str=F6der?= <[e-mail]>
Cc: <[e-mail]>
References: <!~!UENERkVCMDkAAQACAAAAAAAAAAAAAAAAABgAAAAA[e-mail]> <[e-mail]> <002201c2c56c$2b0c4740$0500a8c0@arport> <[e-mail]>
Subject: Re: X.500, LDAP Considered harmful Was: OCSP/LDAP
Date: Sun, 26 Jan 2003 20:48:06 +0100
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.50.4133.2400
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Michael,
How do you explain the often very heated discussions on the PKIX-list
regarding subject DNs as "pointers into DITs" versus "a bunch of attributes"?

Is this a problem in X.500/LDAP or isn't it?   This problem does not
seem to be present in CertStore at least.

Anders



Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h0QJDZj09556 for ietf-pkix-bks; Sun, 26 Jan 2003 11:13:35 -0800 (PST)
Received: from nb2.stroeder.com (krl9-d9bb4f5a.pool.mediaWays.net [217.187.79.90]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h0QJDXo09552 for <[e-mail]>; Sun, 26 Jan 2003 11:13:33 -0800 (PST)
Received: from localhost (localhost.stroeder.com [127.0.0.1]) by nb2.stroeder.com (Postfix) with ESMTP id CCE064BB2A; Sun, 26 Jan 2003 20:12:58 +0100 (CET)
Received: from stroeder.com (localhost.stroeder.com [127.0.0.1]) by nb2.stroeder.com (Postfix) with ESMTP id D5CFC4A1E9; Sun, 26 Jan 2003 20:12:57 +0100 (CET)
Message-ID: <[e-mail]>
Date: Sun, 26 Jan 2003 20:12:57 +0100
From: =?ISO-8859-1?Q?Michael_Str=F6der?= <[e-mail]>
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.2.1) Gecko/20021130
X-Accept-Language: de-de, de, en-us, en
MIME-Version: 1.0
To: Anders Rundgren <[e-mail]>
Cc: [e-mail]
Subject: Re: X.500, LDAP Considered harmful Was: OCSP/LDAP
References: <!~!UENERkVCMDkAAQACAAAAAAAAAAAAAAAAABgAAAAA[e-mail]> <[e-mail]> <002201c2c56c$2b0c4740$0500a8c0@arport>
In-Reply-To: <002201c2c56c$2b0c4740$0500a8c0@arport>
X-Enigmail-Version: 0.71.0.0
X-Enigmail-Supports: pgp-inline, pgp-mime
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
X-Virus-Scanned: by AMaViS 0.3.12pre8
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Anders Rundgren wrote:
> My knowledge of LDAP is limited but isn't it designed to support
> a tree-shaped directory where the subject DN of a certificate
> is supposed to match a directory entry?

You MAY retrieve an LDAP entry by specifying a search with DN of the entry 
as the search base. But you can also do a key by value search in the whole 
subtree.

>  Using CertStore you
> would not build a tree-shaped directory but a "flat"
> attribute-based structure like the following:

It would be absolutely trivial to implement draft-ietf-pkix-certstore-http 
working against an LDAP backend.

> I believe the tree-directory puts additional requirements on
> subject DNs that does not necessarily match the needs of RPs.

Not necessarily. Note that you can also use a flat name space in the 
directory if you give up the pseudo requirement that the subject DN and the 
directory DN has to be the same.

> How does LDAP cope with DN collisions?

Just give each entry another DN. ;-)

> The RDBMS-variant can optionally cope with arbitrary duplicates.

If you want to address a certain table row later you won't let the RDBMS do 
this automagically. You will define some sort of naming rules.

> When you store a cert in the structure above, you "suck" out all the
> "goodies" and store it in a prepared state for _blistering_ performance.

Which approach are you talking about? This mainly applies to all approaches, 
I think.

> The drawback with this scheme is that it is less suitable for
> moving certificates from one database (organization) to
> another (organization).

Inter-server sync processes can work in many ways.
That's not an issue here.

> It only increases the risk that you use an outdated key.

No matter which database technology you use for searching/retrieving the 
certificate each implementation actually doing something with the key has to 
take full care about certificate validation.

> The things we can read about making directory schemas
> match between organizations is not exactly encouraging.
> CertStore plus dynamic lookup seems to eliminate
> this documented mess.

Both technologies address different needs. I don't see any reason why they 
shouldn't coexist.

Note that LDAP is already implemented in wide-spread client applications. 
IMHO draft-klasen-ldap-x509certificate-schema works well with existing 
client and server implementations.

Ciao, Michael.



Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h0QIthm08954 for ietf-pkix-bks; Sun, 26 Jan 2003 10:55:43 -0800 (PST)
Received: from mailb.telia.com (mailb.telia.com [194.22.194.6]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h0QIteo08950 for <[e-mail]>; Sun, 26 Jan 2003 10:55:40 -0800 (PST)
Received: from arport (h220n2fls31o1122.telia.com [212.181.142.220]) by mailb.telia.com (8.12.5/8.12.5) with SMTP id h0QItZ6R010088; Sun, 26 Jan 2003 19:55:36 +0100 (CET)
X-Original-Recipient: [e-mail]
Message-ID: <002201c2c56c$2b0c4740$0500a8c0@arport>
From: "Anders Rundgren" <[e-mail]>
To: <[e-mail]>, =?iso-8859-1?Q?Michael_Str=F6der?= <[e-mail]>
Cc: "Peter Gutmann" <[e-mail]>, "Blake Ramsdell" <[e-mail]>
References: <!~!UENERkVCMDkAAQACAAAAAAAAAAAAAAAAABgAAAAA[e-mail]> <[e-mail]>
Subject: Re: X.500, LDAP Considered harmful Was: OCSP/LDAP
Date: Sun, 26 Jan 2003 19:53:08 +0100
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 5.50.4133.2400
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Michael,
My knowledge of LDAP is limited but isn't it designed to support
a tree-shaped directory where the subject DN of a certificate
is supposed to match a directory entry?  Using CertStore you
would not build a tree-shaped directory but a "flat"
attribute-based structure like the following:

TABLE (
  certblob binary(1000),   -- this is it...
  certHash    binary(20),
  email        varchar (255),
  iHash        binary(20),
  iAndSHash    binary(20),
  name         varchar(255),
  sHash       binary(20),
  sKIDHash  binary(20)
)

I believe the tree-directory puts additional requirements on
subject DNs that does not necessarily match the needs of RPs.

How does LDAP cope with DN collisions?  The RDBMS-variant
can optionally cope with arbitrary duplicates.

When you store a cert in the structure above, you "suck" out all the
"goodies" and store it in a prepared state for _blistering_ performance.

The drawback with this scheme is that it is less suitable for
moving certificates from one database (organization) to
another (organization).  But why should you do that?
It only increases the risk that you use an outdated key.

The things we can read about making directory schemas
match between organizations is not exactly encouraging.
CertStore plus dynamic lookup seems to eliminate
this documented mess.

Anders


----- Original Message -----
From: "Michael Ströder" <[e-mail]>
To: <[e-mail]>
Sent: Sunday, January 26, 2003 13:38
Subject: Re: X.500, LDAP Considered harmful Was: OCSP/LDAP



Blake Ramsdell wrote:
>
> You're missing Peter's point here

I don't.

> -- the SELECT is not necessarily meant
> to be SQL, it's meant to convey that the single useful problem that a
> certificate database (be it X.500, SQL, whatever) solves is to return
> some number of certificates that exactly matches some search criteria.

Nope. Peter was definitely talking about complexity of X.500 filters vs. SQL
statements. I tried to explain that
1. it's equally complex
2. Peter ignored important issues
3. LDAP is already implemented in wide-spread application e.g. MUAs (still
some issues though)

Please note that I don't have a personal preference or aversion against any
technology. But I have aversions against people arguing against something
which at least is partially implemented and proposing something new for
which there's still is not even an I-D claiming to have the right solution
for all the issues.

> How exactly do you format
> the examples that I've given in such a way to query an LDAP server?

Did you read draft-klasen-ldap-x509certificate-schema? Some people here are
more in favour of combining certificate matching rules and
draft-ietf-ldapext-matchedval though.

> "I need to get one or more certificates that meet this exact criteria."

Yepp. Who doesn't?

> Which I don't think can be done with LDAP, and if it can, then it's in
> the form of an overly complex query that varies depending on the schema.

It's equally complex with any sort of database:
- access protocol
- schema
- security considerations, privacy aspects
...

> The only effective certificate database I've even
> been able to manage is one that indexes on the fields that I've given,
> and in fact is based on a general-purpose relational database, populated
> with certificates that came along with S/MIME messages.

Well, you're welcome to write an I-D for deploying a relational database as
certificate store. I guess in the end it will have the same issues like
directories.

> For eight years I've been working with S/MIME, X.509 and related
> standards, and with the exception of adding SubjectKeyIdentifier, the
> criteria I've wanted to search on have not changed.  And I still cannot
> do those searches today with anything other than my own database.

Yes, since people are talking about instead implementing it. :-(

Maybe the use-cases should be cleanly modeled. Otherwise we won't come to a
consent.

Ciao, Michael.




Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h0QHmpO05231 for ietf-pkix-bks; Sun, 26 Jan 2003 09:48:51 -0800 (PST)
Received: from nb2.stroeder.com (krl9-d9bb4f5a.pool.mediaWays.net [217.187.79.90]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h0QHmno05227 for <[e-mail]>; Sun, 26 Jan 2003 09:48:50 -0800 (PST)
Received: from localhost (localhost.stroeder.com [127.0.0.1]) by nb2.stroeder.com (Postfix) with ESMTP id 3DC064745B for <[e-mail]>; Sun, 26 Jan 2003 18:48:15 +0100 (CET)
Received: from stroeder.com (localhost.stroeder.com [127.0.0.1]) by nb2.stroeder.com (Postfix) with ESMTP id 8B1C921287 for <[e-mail]>; Sun, 26 Jan 2003 18:48:14 +0100 (CET)
Message-ID: <[e-mail]>
Date: Sun, 26 Jan 2003 18:48:14 +0100
From: =?ISO-8859-1?Q?Michael_Str=F6der?= <[e-mail]>
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.2.1) Gecko/20021130
X-Accept-Language: de-de, de, en-us, en
MIME-Version: 1.0
To: [e-mail]
Subject: Re: X.500, LDAP Considered harmful Was: OCSP/LDAP
References: <[e-mail]>
In-Reply-To: <[e-mail]>
X-Enigmail-Version: 0.71.0.0
X-Enigmail-Supports: pgp-inline, pgp-mime
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
X-Virus-Scanned: by AMaViS 0.3.12pre8
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Tom Gindin wrote:
> If the issuer has an LDAP directory which supports component
> matching or the PKI matching rules, the problem we're left with in using
> LDAP is still how to find the directory (or directories) with certificates
> from a given issuer.

Just for the records: Same problem with any kind of database.

Note that people solely posting SQL statements leave out this part (locate 
database and connect to the database) completely.

For LDAP there is a way using dc-style DNs and SRV RRs to locate the 
directory. Some people insist on dc-style DNs not widely used though (which 
is IMHO not true).

Ciao, Michael.



Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h0QHDTN04697 for ietf-pkix-bks; Sun, 26 Jan 2003 09:13:29 -0800 (PST)
Received: from e2.ny.us.ibm.com (e2.ny.us.ibm.com [32.97.182.102]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h0QHDQo04693 for <[e-mail]>; Sun, 26 Jan 2003 09:13:26 -0800 (PST)
Received: from northrelay02.pok.ibm.com (northrelay02.pok.ibm.com [9.56.224.150]) by e2.ny.us.ibm.com (8.12.2/8.12.2) with ESMTP id h0QHDEuv210002; Sun, 26 Jan 2003 12:13:15 -0500
Received: from d01ml062.pok.ibm.com (d01av02.pok.ibm.com [9.56.224.216]) by northrelay02.pok.ibm.com (8.12.3/NCO/VER6.4) with ESMTP id h0QHDBFs099314; Sun, 26 Jan 2003 12:13:11 -0500
Importance: Normal
Sensitivity: 
Subject: RE: X.500, LDAP Considered harmful Was: OCSP/LDAP
To: "Blake Ramsdell" <[e-mail]>
Cc: "'Richard Levitte - VMS Whacker'" <[e-mail]>, <[e-mail]>, <[e-mail]>, <[e-mail]>
X-Mailer: Lotus Notes Release 5.0.7  March 21, 2001
Message-ID: <[e-mail]>
From: "Tom Gindin" <[e-mail]>
Date: Sun, 26 Jan 2003 12:13:02 -0500
X-MIMETrack: Serialize by Router on D01ML062/01/M/IBM(Release 5.0.11 +SPRs MIAS5EXFG4, MIAS5AUFPV and DHAG4Y6R7W, MATTEST |November 8th, 2002) at 01/26/2003 12:13:14 PM
MIME-Version: 1.0
Content-type: text/plain; charset=us-ascii
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

      In the LDAP PKI schema draft, section 7, the filter examples all deal
with matching certificates using serial number and issuer (1-5) or e-mail
address outside the DN (6).   These do involve relatively unusual matching
techniques (either component matching or PKI-specific matching rules) which
probably don't exist yet on most servers.  Also, this draft is now 7 months
old.
      These features are making some progress in LDAP, even if IMHO not
enough.  If the issuer has an LDAP directory which supports component
matching or the PKI matching rules, the problem we're left with in using
LDAP is still how to find the directory (or directories) with certificates
from a given issuer.

            Tom Gindin


"Blake Ramsdell" <[e-mail]>@mail.imc.org on 01/26/2003
03:50:20 AM

Sent by:    [e-mail]


To:    "'Richard Levitte - VMS Whacker'" <[e-mail]>
cc:    <[e-mail]>, <[e-mail]>,
       <[e-mail]>
Subject:    RE: X.500, LDAP Considered harmful Was: OCSP/LDAP



> -----Original Message-----
> From: Richard Levitte - VMS Whacker [mailto:[e-mail]]
> Sent: Sunday, January 26, 2003 12:10 AM
> To: [e-mail]
> Cc: [e-mail]; [e-mail]; [e-mail]
> Subject: Re: X.500, LDAP Considered harmful Was: OCSP/LDAP
>
> The real question is, if someone would need to, how do they search in
> your database?  What's the schema?  Is it standardised in any way, or
> does every database repository come with it's own, making it a
> configuration hell to make sure one can work with each of them?

They can't -- I'm just pointing out that since I'm not aware of any
standard, consistent way to present the queries I've listed to a
directory and get back the certificates I need, I gave up and made my
own proprietary solution.  I would absolutely love to have a published,
standard way of looking things up in a directory using these queries.
Once again, this could be something that I'm missing.

My point is not that relational databases are the salvation -- I
couldn't care less what you use on the back end.  I'm saying that in
order to find a certificate that matches a certain criteria, you should
be able to present the criteria, and get back the matching
certificate(s).  I think this is the essence of Peter's position also.

> As for me, I don't really care what the access method to repositories
> are, as long as there's a schema I can follow and the repository has
> usefull content (or referals to useful content).

I think we are on exactly the same page -- I don't care what the
protocol is, or what the schema is, or anything else -- I just want my
questions answered consistently.  I am still not convinced that LDAP
provides this today, or if sufficient efforts are underway to modify it
to support these types of queries.

Phill and Peter (and potentially others) have pointed out that LDAP has
a different design philosophy, and we're trying to make it do things
that it wasn't really designed to do.  We seem to be telling ourselves
that it's best to jam it into LDAP because "that's the standard", and
presumably we are deluded enough to believe that maintaining LDAP
compatibility is somehow virtuous.  The queries that have been presented
seem to be contrary to the normal operation and philosophy of LDAP
(specifically IssuerAndSerialNumber and SubjectKeyIdentifier).  If the
best answer is to modify or profile LDAP in some way, then I've got no
complaints -- I just want my queries answered.

Blake






Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h0QH3cB04491 for ietf-pkix-bks; Sun, 26 Jan 2003 09:03:38 -0800 (PST)
Received: from mailb.telia.com (mailb.telia.com [194.22.194.6]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h0QH3ao04485 for <[e-mail]>; Sun, 26 Jan 2003 09:03:37 -0800 (PST)
Received: from arport (h220n2fls31o1122.telia.com [212.181.142.220]) by mailb.telia.com (8.12.5/8.12.5) with SMTP id h0QH3U6R015798; Sun, 26 Jan 2003 18:03:30 +0100 (CET)
X-Original-Recipient: [e-mail]
Message-ID: <000001c2c55c$82564470$0500a8c0@arport>
From: "Anders Rundgren" <[e-mail]>
To: <[e-mail]>, "Peter Gutmann" <[e-mail]>
References: <[e-mail]>
Subject: CERTSTORE's 160 bit limit
Date: Sun, 26 Jan 2003 09:20:47 +0100
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.50.4133.2400
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Peter,

>From the 03-draft I cannot deduct what length-limitations there
are on the "name" and "email" search attributes.

Anders



Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h0QGdWc29903 for ietf-pkix-bks; Sun, 26 Jan 2003 08:39:32 -0800 (PST)
Received: from nic.lp.se (nic.lp.se [212.247.5.91]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h0QGdUo29898 for <[e-mail]>; Sun, 26 Jan 2003 08:39:30 -0800 (PST)
Received: from localhost (217.215.93.181) by nic.lp.se (MX V5.3 VnHj) with ESMTP; Sun, 26 Jan 2003 17:37:26 +0100
Date: Sun, 26 Jan 2003 17:34:24 +0100 (CET)
Message-ID: <[e-mail]>
To: [e-mail]
CC: [e-mail], [e-mail], [e-mail]
Subject: Re: X.500, LDAP Considered harmful Was: OCSP/LDAP
From: Richard Levitte - VMS Whacker <[e-mail]>
In-Reply-To: <!~!UENERkVCMDkAAQACAAAAAAAAAAAAAAAAABgAAAAA[e-mail]>
References: <[e-mail]> <!~!UENERkVCMDkAAQACAAAAAAAAAAAAAAAAABgAAAAA[e-mail]>
X-URL: http://www.lp.se/
X-Waved: dead chicken, GNU emacs 21.2.2, Mew version 3.1
X-Mew: See http://www.mew.org/
X-Mailer: Mew version 3.1 on Emacs 21.2 / Mule 5.0 (SAKAKI)
MIME-Version: 1.0
Content-Type: Text/Plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

In message <!~!UENERkVCMDkAAQACAAAAAAAAAAAAAAAAABgAAAAA[e-mail]> on Sun, 26 Jan 2003 00:50:20 -0800, "Blake Ramsdell" <[e-mail]> said:

blake> My point is not that relational databases are the salvation -- I
blake> couldn't care less what you use on the back end.  I'm saying that in
blake> order to find a certificate that matches a certain criteria, you should
blake> be able to present the criteria, and get back the matching
blake> certificate(s).  I think this is the essence of Peter's position also.

And I took it as "let's toss LDAP and use RDBMs, because that works,
at least for me".  My appologies for the misunderstanding...

blake> > As for me, I don't really care what the access method to repositories
blake> > are, as long as there's a schema I can follow and the repository has
blake> > usefull content (or referals to useful content).
blake> 
blake> I think we are on exactly the same page -- I don't care what the
blake> protocol is, or what the schema is, or anything else -- I just want my
blake> questions answered consistently.  I am still not convinced that LDAP
blake> provides this today, or if sufficient efforts are underway to modify it
blake> to support these types of queries.

I see two things that could provide this today: HTTP and LDAP.  The
former via draft-ietf-pkix-certstore-http-03, the latter via RFC 2587
and draft-klasen-ldap-x509certificate-schema-01 (which, BTW, contains
the attributes I was looking for), just as examples.  And from that
point of view, since LDAP repositories are searchable on attribute
values, I'm not sure it's that bad.  Of course, proper DNs will help
as well...

For me, the above is more sufficient than anything based on SQL that
I've seen so far...

blake> Phill and Peter (and potentially others) have pointed out that
blake> LDAP has a different design philosophy, and we're trying to
blake> make it do things that it wasn't really designed to do.

I must be missing something.  What exactly is LDAP not designed to do
in this context?

-- 
Richard Levitte     | http://richard.levitte.org/ | Spannv. 38, I
Levitte Programming | http://www.lp.se/           | S-168 35 Bromma
T: [phone] |                             | SWEDEN
     "Price, performance, quality...  choose the two you like"


Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h0QCcpc17712 for ietf-pkix-bks; Sun, 26 Jan 2003 04:38:51 -0800 (PST)
Received: from nb2.stroeder.com (krl9-d9bb4f5a.pool.mediaWays.net [217.187.79.90]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h0QCcno17708 for <[e-mail]>; Sun, 26 Jan 2003 04:38:49 -0800 (PST)
Received: from localhost (localhost.stroeder.com [127.0.0.1]) by nb2.stroeder.com (Postfix) with ESMTP id B051D47346 for <[e-mail]>; Sun, 26 Jan 2003 13:38:44 +0100 (CET)
Received: from stroeder.com (localhost.stroeder.com [127.0.0.1]) by nb2.stroeder.com (Postfix) with ESMTP id 1A2012A5F4 for <[e-mail]>; Sun, 26 Jan 2003 13:38:44 +0100 (CET)
Message-ID: <[e-mail]>
Date: Sun, 26 Jan 2003 13:38:43 +0100
From: =?ISO-8859-1?Q?Michael_Str=F6der?= <[e-mail]>
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.2.1) Gecko/20021130
X-Accept-Language: de-de, de, en-us, en
MIME-Version: 1.0
To: [e-mail]
Subject: Re: X.500, LDAP Considered harmful Was: OCSP/LDAP
References: <!~!UENERkVCMDkAAQACAAAAAAAAAAAAAAAAABgAAAAA[e-mail]>
In-Reply-To: <!~!UENERkVCMDkAAQACAAAAAAAAAAAAAAAAABgAAAAA[e-mail]>
X-Enigmail-Version: 0.71.0.0
X-Enigmail-Supports: pgp-inline, pgp-mime
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
X-Virus-Scanned: by AMaViS 0.3.12pre8
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Blake Ramsdell wrote:
> 
> You're missing Peter's point here

I don't.

> -- the SELECT is not necessarily meant
> to be SQL, it's meant to convey that the single useful problem that a
> certificate database (be it X.500, SQL, whatever) solves is to return
> some number of certificates that exactly matches some search criteria.

Nope. Peter was definitely talking about complexity of X.500 filters vs. SQL 
statements. I tried to explain that
1. it's equally complex
2. Peter ignored important issues
3. LDAP is already implemented in wide-spread application e.g. MUAs (still 
some issues though)

Please note that I don't have a personal preference or aversion against any 
technology. But I have aversions against people arguing against something 
which at least is partially implemented and proposing something new for 
which there's still is not even an I-D claiming to have the right solution 
for all the issues.

> How exactly do you format
> the examples that I've given in such a way to query an LDAP server?

Did you read draft-klasen-ldap-x509certificate-schema? Some people here are 
more in favour of combining certificate matching rules and 
draft-ietf-ldapext-matchedval though.

> "I need to get one or more certificates that meet this exact criteria."

Yepp. Who doesn't?

> Which I don't think can be done with LDAP, and if it can, then it's in
> the form of an overly complex query that varies depending on the schema.

It's equally complex with any sort of database:
- access protocol
- schema
- security considerations, privacy aspects
...

> The only effective certificate database I've even
> been able to manage is one that indexes on the fields that I've given,
> and in fact is based on a general-purpose relational database, populated
> with certificates that came along with S/MIME messages.

Well, you're welcome to write an I-D for deploying a relational database as 
certificate store. I guess in the end it will have the same issues like 
directories.

> For eight years I've been working with S/MIME, X.509 and related
> standards, and with the exception of adding SubjectKeyIdentifier, the
> criteria I've wanted to search on have not changed.  And I still cannot
> do those searches today with anything other than my own database.

Yes, since people are talking about instead implementing it. :-(

Maybe the use-cases should be cleanly modeled. Otherwise we won't come to a 
consent.

Ciao, Michael.



Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h0Q8nw024281 for ietf-pkix-bks; Sun, 26 Jan 2003 00:49:58 -0800 (PST)
Received: from brutesquadlabs.com (gtec136-m.isomedia.com [207.115.67.136] (may be forged)) by above.proper.com (8.11.6/8.11.3) with ESMTP id h0Q8nwo24273 for <[e-mail]>; Sun, 26 Jan 2003 00:49:58 -0800 (PST)
Received: from DEXTER ([192.168.0.4]) by brutesquadlabs.com with ESMTP ; Sun, 26 Jan 2003 00:49:51 -0800
From: "Blake Ramsdell" <[e-mail]>
To: "'Richard Levitte - VMS Whacker'" <[e-mail]>
Cc: <[e-mail]>, <[e-mail]>, <[e-mail]>
Subject: RE: X.500, LDAP Considered harmful Was: OCSP/LDAP
Date: Sun, 26 Jan 2003 00:50:20 -0800
Message-ID: <!~!UENERkVCMDkAAQACAAAAAAAAAAAAAAAAABgAAAAA[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook, Build 10.0.2627
In-reply-to: <[e-mail]>
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106
Importance: Normal
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

> -----Original Message-----
> From: Richard Levitte - VMS Whacker [mailto:[e-mail]] 
> Sent: Sunday, January 26, 2003 12:10 AM
> To: [e-mail]
> Cc: [e-mail]; [e-mail]; [e-mail]
> Subject: Re: X.500, LDAP Considered harmful Was: OCSP/LDAP
> 
> The real question is, if someone would need to, how do they search in
> your database?  What's the schema?  Is it standardised in any way, or
> does every database repository come with it's own, making it a
> configuration hell to make sure one can work with each of them?

They can't -- I'm just pointing out that since I'm not aware of any
standard, consistent way to present the queries I've listed to a
directory and get back the certificates I need, I gave up and made my
own proprietary solution.  I would absolutely love to have a published,
standard way of looking things up in a directory using these queries.
Once again, this could be something that I'm missing.

My point is not that relational databases are the salvation -- I
couldn't care less what you use on the back end.  I'm saying that in
order to find a certificate that matches a certain criteria, you should
be able to present the criteria, and get back the matching
certificate(s).  I think this is the essence of Peter's position also.

> As for me, I don't really care what the access method to repositories
> are, as long as there's a schema I can follow and the repository has
> usefull content (or referals to useful content).

I think we are on exactly the same page -- I don't care what the
protocol is, or what the schema is, or anything else -- I just want my
questions answered consistently.  I am still not convinced that LDAP
provides this today, or if sufficient efforts are underway to modify it
to support these types of queries.

Phill and Peter (and potentially others) have pointed out that LDAP has
a different design philosophy, and we're trying to make it do things
that it wasn't really designed to do.  We seem to be telling ourselves
that it's best to jam it into LDAP because "that's the standard", and
presumably we are deluded enough to believe that maintaining LDAP
compatibility is somehow virtuous.  The queries that have been presented
seem to be contrary to the normal operation and philosophy of LDAP
(specifically IssuerAndSerialNumber and SubjectKeyIdentifier).  If the
best answer is to modify or profile LDAP in some way, then I've got no
complaints -- I just want my queries answered.

Blake



Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h0Q8FHS19032 for ietf-pkix-bks; Sun, 26 Jan 2003 00:15:17 -0800 (PST)
Received: from nic.lp.se (nic.lp.se [212.247.5.91]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h0Q8FEo19012 for <[e-mail]>; Sun, 26 Jan 2003 00:15:15 -0800 (PST)
Received: from localhost (217.215.93.181) by nic.lp.se (MX V5.3 VnHj) with ESMTP; Sun, 26 Jan 2003 09:12:55 +0100
Date: Sun, 26 Jan 2003 09:09:54 +0100 (CET)
Message-ID: <[e-mail]>
To: [e-mail]
CC: [e-mail], [e-mail], [e-mail]
Subject: Re: X.500, LDAP Considered harmful Was: OCSP/LDAP
From: Richard Levitte - VMS Whacker <[e-mail]>
In-Reply-To: <!~!UENERkVCMDkAAQACAAAAAAAAAAAAAAAAABgAAAAA[e-mail]>
References: <[e-mail]> <!~!UENERkVCMDkAAQACAAAAAAAAAAAAAAAAABgAAAAA[e-mail]>
X-URL: http://www.lp.se/
X-Waved: dead chicken, GNU emacs 21.2.2, Mew version 3.1
X-Mew: See http://www.mew.org/
X-Mailer: Mew version 3.1 on Emacs 21.2 / Mule 5.0 (SAKAKI)
MIME-Version: 1.0
Content-Type: Text/Plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

In message <!~!UENERkVCMDkAAQACAAAAAAAAAAAAAAAAABgAAAAA[e-mail]> on Sat, 25 Jan 2003 16:36:32 -0800, "Blake Ramsdell" <[e-mail]> said:

blake> For eight years I've been working with S/MIME, X.509 and related
blake> standards, and with the exception of adding SubjectKeyIdentifier, the
blake> criteria I've wanted to search on have not changed.  And I still cannot
blake> do those searches today with anything other than my own database.

I think we're getting to the point that everyone is making.  'I still
cannot do searches today with anything other than my own database'
says it all.  It's quite true, and it applies to relational databases
as much as LDAP directories the way they're handled today.

The real question is, if someone would need to, how do they search in
your database?  What's the schema?  Is it standardised in any way, or
does every database repository come with it's own, making it a
configuration hell to make sure one can work with each of them?

Sounds to me like exactly the same problem as the ones you point out
for repositories in LDAP directories...

And still, with LDAP, there's work going on to create sensible schemas
(that I can see.  If someone has done something similar for relational
databases, I can't remember seeing it) to be used.  Granted, there may
be things missing (I haven't looked, but I can think of
SubjectKetIdentifier as something that may be missing).  What stops
anyone from proposing?

For a few specifics:

searching in IssuerAndSerialNumber: I agree, tricky.  No real standard
as far as I know.  Intuition would make me look at serialNumber=x,{CA-dn}
(The CA subject with the serial number tucket in front of it), but I'm
sure there are all kinds of more or less imaginative ways to do
this...

Failing DN search: I'm sorry, someone didn't populate the directory
properly, and that should be used as a rebuttal to LDAP?  You realise
what's going to happen with unpopulated RDBMs, don't you :-)...


As for me, I don't really care what the access method to repositories
are, as long as there's a schema I can follow and the repository has
usefull content (or referals to useful content).

-- 
Richard Levitte     | http://richard.levitte.org/ | Spannv. 38, I
Levitte Programming | http://www.lp.se/           | S-168 35 Bromma
T: [phone] |                             | SWEDEN
     "Price, performance, quality...  choose the two you like"


Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h0Q0acZ07705 for ietf-pkix-bks; Sat, 25 Jan 2003 16:36:38 -0800 (PST)
Received: from brutesquadlabs.com (gtec136-m.isomedia.com [207.115.67.136] (may be forged)) by above.proper.com (8.11.6/8.11.3) with ESMTP id h0Q0abo07699 for <[e-mail]>; Sat, 25 Jan 2003 16:36:37 -0800 (PST)
Received: from DEXTER ([192.168.0.4]) by brutesquadlabs.com with ESMTP ; Sat, 25 Jan 2003 16:36:33 -0800
From: "Blake Ramsdell" <[e-mail]>
To: "=?iso-8859-1?Q?'Michael_Str=F6der'?=" <[e-mail]>, "'Peter Gutmann'" <[e-mail]>
Cc: <[e-mail]>
Subject: RE: X.500, LDAP Considered harmful Was: OCSP/LDAP
Date: Sat, 25 Jan 2003 16:36:32 -0800
Message-ID: <!~!UENERkVCMDkAAQACAAAAAAAAAAAAAAAAABgAAAAA[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook, Build 10.0.2627
In-reply-to: <[e-mail]>
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106
Importance: Normal
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id h0Q0aco07702
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

> -----Original Message-----
> From: [e-mail] 
> [mailto:[e-mail]] On Behalf Of Michael Ströder
> Sent: Saturday, January 25, 2003 11:54 AM
> To: Peter Gutmann
> Cc: [e-mail]
> Subject: Re: X.500, LDAP Considered harmful Was: OCSP/LDAP
> 
> Peter Gutmann wrote:
> > 
> > I pointed that out in my ACSAC paper a few years ago: You 
> take a simple query
> > "SELECT cert FROM foo WHERE key = bar" and then the client 
> dresses it up as an
> > incredibly complex X.500 filter which the server has to do 
> more work to
> > translate back into an SQL-equivalent query to actually 
> fetch the key.
> 
> That's simply not true. I wouldn't claim that X.500 or LDAP 
> directories are 
> a really simple thing. But neither are relational databases 
> if you want a 
> standardized schema, access protocol, etc.

You're missing Peter's point here -- the SELECT is not necessarily meant
to be SQL, it's meant to convey that the single useful problem that a
certificate database (be it X.500, SQL, whatever) solves is to return
some number of certificates that exactly matches some search criteria.
To use S/MIME as an example, this is one of two criteria:

1. SubjectKeyIdentifier
2. IssuerAndSerialNumber

And potentially a third:

3. Email address


And with PKIX as an example for the purpose of certificate path
construction, you need to have:

1. Subject (Name)
2. SubjectKeyIdentifier (overlaps with S/MIME)

And I think that's it.

> ldap://host.domain/o=foo?userCertificate?sub?(key=bar)
> 
> (including definition of the connection part)

I'm glad you were able to get the connection part in there, and that's a
great weight off my mind (it's a configuration parameter -- who cares
what the values are or how they're encoded?)  How exactly do you format
the examples that I've given in such a way to query an LDAP server?
This is the essence of Peter's argument:

"I need to get one or more certificates that meet this exact criteria."

Which I don't think can be done with LDAP, and if it can, then it's in
the form of an overly complex query that varies depending on the schema.

How do I search on IssuerAndSerialNumber?  How do I search on
SubjectKeyIdentifier?

> Peter, normally you're certainly doing better. Sorry, I file 
> your postings 
> about this topic under "Peter Gutmann's personal aversions 
> against X.500 
> directories". ;-)

I seem to have the same aversion.  The only search I've even gotten to
work is based on email address (ironically enough).  I even failed with
the subject DN search (also, ironically enough), since that is typically
searching for intermediate CA certificates which are not found in some
(most?) directories.  The only effective certificate database I've even
been able to manage is one that indexes on the fields that I've given,
and in fact is based on a general-purpose relational database, populated
with certificates that came along with S/MIME messages.

This "never been able to make the queries work" can certainly be chalked
up to Blake is a Chimp in some cases (I suspect that in some universe
the subject search should work, but I have not found that universe yet),
but I'm not sure that I'm alone here.

For eight years I've been working with S/MIME, X.509 and related
standards, and with the exception of adding SubjectKeyIdentifier, the
criteria I've wanted to search on have not changed.  And I still cannot
do those searches today with anything other than my own database.

Corrections / flames / putdowns welcome, especially corrections and
well-written putdowns.

Blake



Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h0PJs0E04169 for ietf-pkix-bks; Sat, 25 Jan 2003 11:54:00 -0800 (PST)
Received: from nb2.stroeder.com (krl9-d9bb4f13.pool.mediaWays.net [217.187.79.19]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h0PJrvo04165 for <[e-mail]>; Sat, 25 Jan 2003 11:53:59 -0800 (PST)
Received: from localhost (localhost.stroeder.com [127.0.0.1]) by nb2.stroeder.com (Postfix) with ESMTP id 6EC644A816; Sat, 25 Jan 2003 20:53:50 +0100 (CET)
Received: from stroeder.com (localhost.stroeder.com [127.0.0.1]) by nb2.stroeder.com (Postfix) with ESMTP id A976B47933; Sat, 25 Jan 2003 20:53:49 +0100 (CET)
Message-ID: <[e-mail]>
Date: Sat, 25 Jan 2003 20:53:49 +0100
From: =?ISO-8859-1?Q?Michael_Str=F6der?= <[e-mail]>
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.2.1) Gecko/20021130
X-Accept-Language: de-de, de, en-us, en
MIME-Version: 1.0
To: Peter Gutmann <[e-mail]>
Cc: [e-mail]
Subject: Re: X.500, LDAP Considered harmful Was: OCSP/LDAP
References: <[e-mail]>
In-Reply-To: <[e-mail]>
X-Enigmail-Version: 0.71.0.0
X-Enigmail-Supports: pgp-inline, pgp-mime
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
X-Virus-Scanned: by AMaViS 0.3.12pre8
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Peter Gutmann wrote:
> 
> I pointed that out in my ACSAC paper a few years ago: You take a simple query
> "SELECT cert FROM foo WHERE key = bar" and then the client dresses it up as an
> incredibly complex X.500 filter which the server has to do more work to
> translate back into an SQL-equivalent query to actually fetch the key.

That's simply not true. I wouldn't claim that X.500 or LDAP directories are 
a really simple thing. But neither are relational databases if you want a 
standardized schema, access protocol, etc.

I see no reason why

SELECT cert FROM foo WHERE key = bar

(note that you left out the host connection part)

is less complex than

ldap://host.domain/o=foo?userCertificate?sub?(key=bar)

(including definition of the connection part)

In both examples the application has to be configured to know
- the host to connect to
- foo
- key
- bar

In the DB example the application has additionally to know about table 
column 'cert' and the application has to be programmed to be capable to even 
access the proprietary database product. To me this looks more complex than 
the LDAP example.

Note that certificate retrieval via LDAP works in wide-spread MUAs since 
years. I simply don't understand why companies don't use it. Well, the 
answer is probably that companies do not deploy X.509-based PKI...

My impression is, especially when reviewing the discussion about the draft 
for LDAP PKI schema, that people here are talking things more complex than 
they are. Especially when implementing LDAP PKI schema one would *not* have 
to change the client (in opposite to many false statements on this list).

> The
> analogy I've used is that it's like watching a friend of mine's four-year-old
> eat peas with a fork, she uses her fingers to put the peas on the fork, moves
> it up to her mouth, then uses her fingers to move the peas off the fork into
> her mouth, and everyone gets to say how clever she is to use a fork at her
> age.  Certs in X.500 directories are the same thing.

Peter, normally you're certainly doing better. Sorry, I file your postings 
about this topic under "Peter Gutmann's personal aversions against X.500 
directories". ;-)

Ciao, Michael.



Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h0PF6Qi27063 for ietf-pkix-bks; Sat, 25 Jan 2003 07:06:26 -0800 (PST)
Received: from mailb.telia.com (mailb.telia.com [194.22.194.6]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h0PF6Po27059 for <[e-mail]>; Sat, 25 Jan 2003 07:06:25 -0800 (PST)
Received: from arport (h127n2fls31o1122.telia.com [212.181.142.127]) by mailb.telia.com (8.12.5/8.12.5) with SMTP id h0PF696R024694; Sat, 25 Jan 2003 16:06:10 +0100 (CET)
X-Original-Recipient: [e-mail]
Message-ID: <006b01c2c482$f4ec61c0$0500a8c0@arport>
From: "Anders Rundgren" <[e-mail]>
To: "Hallam-Baker, Phillip" <[e-mail]>, "Peter Gutmann" <[e-mail]>
Cc: <[e-mail]>
References: <[e-mail]>
Subject: Re: X.500, LDAP Considered harmful Was: OCSP/LDAP
Date: Sat, 25 Jan 2003 16:03:44 +0100
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.50.4133.2400
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

>"Hallam-Baker, Phillip" <[e-mail]> writes:

>>First let us dispense with the system designed for use by humans. We have a
>>system, it is called the Web, everyone else lost, get over it.

>>In conclusion it is time for the PKI world to seriously consider 
>>whether X.500 and LDAP provide the right certificate repository
>>structure for PKI. For myself I consider them harmful.

>"Peter Gutmann" <[e-mail]> writes:
>Yup.  That's what the motivation was for my certs-over-HTTP RFC.

And the very same ideas spurred me to write the Plug-and-Play PKI for
Web Services proposal, augmenting PKI with the naming system used
on the Web (i.e. URLs), instead of waiting another 15 years or so for
ISO to get the global X.500 registry up and running.

By also loosen-up the ties between PKI and the hierarchical X.500
data model, you get a direct link to the relational database systems,
which are powering just about every serious Web-app there is.

<snip>

Guys,
In spite of pretty different backgrounds, targets, and means, I feel that we
share a common view that the PKI world must take some additional steps
towards the Web world in order to ever become an integral part of the it.

                                       Let's Go!

Anders Rundgren

PS Pardon the "plug" DS





Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h0PDVfq22804 for ietf-pkix-bks; Sat, 25 Jan 2003 05:31:41 -0800 (PST)
Received: from mail.hackmasters.net (ppp-217-133-8-148.dialup.tiscali.it [217.133.8.148]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h0PDVco22800 for <[e-mail]>; Sat, 25 Jan 2003 05:31:39 -0800 (PST)
Received: from localhost (localhost.localdomain [127.0.0.1]) by mail.hackmasters.net (Postfix) with ESMTP id 05DE7F357 for <[e-mail]>; Sat, 25 Jan 2003 14:40:52 +0100 (CET)
Received: by mail.hackmasters.net (Postfix, from userid 509) id 6ADDAF360; Sat, 25 Jan 2003 14:40:50 +0100 (CET)
Received: from hackmasters.net (galadriel.mpnet.hackmasters.net [10.5.122.180]) by mail.hackmasters.net (Postfix) with ESMTP id AC9FEF357 for <[e-mail]>; Sat, 25 Jan 2003 14:40:49 +0100 (CET)
Message-ID: <[e-mail]>
Date: Sat, 25 Jan 2003 14:37:01 +0100
From: Massimiliano Pala <[e-mail]>
Organization: OpenCA
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.2.1) Gecko/20021130
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: pkix <[e-mail]>
Subject: STRAWPOLL:OCSP
References: <[e-mail]> <[e-mail]>
In-Reply-To: <[e-mail]>
Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms060908090306000402060303"
X-Virus-Scanned: by AMaViS perl-11
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

This is a cryptographically signed message in MIME format.

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

-- 

C'you,

	Massimiliano Pala

--o-------------------------------------------------------------------------
Massimiliano Pala [OpenCA Project Manager]                [e-mail]
                                                  Tel.:   [phone]
http://www.openca.org                            Fax:    +39   178  221 8225
http://openca.sourceforge.net                    Mobile: [phone]

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

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIOZjCC
By8wggYXoAMCAQICASwwDQYJKoZIhvcNAQEEBQAwgYoxIjAgBgkqhkiG9w0BCQEWE3BraS5j
aWNhaWFAdW5pbW8uaXQxJzAlBgNVBAMTHlVuaW1vcmUgRW50ZSBkaSBDZXJ0aWZpY2F6aW9u
ZTEuMCwGA1UEChMlVW5pdmVyc2l0YScgZGkgTW9kZW5hIGUgUmVnZ2lvIEVtaWxpYTELMAkG
A1UEBhMCSVQwHhcNMDIwNzI0MTUyNjI2WhcNMDMxMjMxMjM1OTU5WjCBqTEaMBgGA1UEAxMR
TWFzc2ltaWxpYW5vIFBhbGExNTAzBgNVBAsTLERpcGFydGltZW50byBkaSBJbmdlZ25lcmlh
IGRlbGwnSW5mb3JtYXppb25lMRcwFQYDVQQLEw5TZWRlIGRpIE1vZGVuYTEuMCwGA1UEChMl
VW5pdmVyc2l0YScgZGkgTW9kZW5hIGUgUmVnZ2lvIEVtaWxpYTELMAkGA1UEBhMCSVQwgZ8w
DQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBANSesg80BGzryvQlplD0MJ2YWlSEUAZpiFmywpOm
l//lWMnhONmC/q0TrO7j9Bb195dNzCMuXFgvV49Sy1iyHAjDhpysFvm/xZbAS3j8prXNN23K
S3Oa7Zz2GrQpCHgupCPQL2cy+ARVwwFod2GOSCVoUACkndit964K/bfsGvyLAgMBAAGjggQB
MIID/TAMBgNVHRMBAf8EAjAAMBEGCWCGSAGG+EIBAQQEAwIFoDAOBgNVHQ8BAf8EBAMCA/gw
HQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMB0GA1UdDgQWBBT6aSO5yTMPTf9OdcWo
14pKLqEHMDCBtwYDVR0jBIGvMIGsgBRFHaYA4ZfoyU2aaUnZYMiYf4lFA6GBkKSBjTCBijEi
MCAGCSqGSIb3DQEJARYTcGtpLmNpY2FpYUB1bmltby5pdDEnMCUGA1UEAxMeVW5pbW9yZSBF
bnRlIGRpIENlcnRpZmljYXppb25lMS4wLAYDVQQKEyVVbml2ZXJzaXRhJyBkaSBNb2RlbmEg
ZSBSZWdnaW8gRW1pbGlhMQswCQYDVQQGEwJJVIIBADBqBglghkgBhvhCAQ0EXRZbUHJvZ2V0
dG8gUG9zdGEgRWxldHRyb25pY2EgU2ljdXJhIA0KVW5pdmVyc2l0YScgZGkgTW9kZW5hIGUg
UmVnZ2lvIEVtaWxpYSANCkMuSS5DLkEuSS5BLiANCjAiBgNVHREEGzAZgRdtYWR3b2xmQGhh
Y2ttYXN0ZXJzLm5ldDA0BgNVHRIELTArgRNwa2kuY2ljYWlhQHVuaW1vLml0hhRodHRwOi8v
cGtpLnVuaW1vLml0LzA/BggrBgEFBQcBAQQzMDEwLwYIKwYBBQUHMAKGI2h0dHA6Ly9wa2ku
dW5pbW8uaXQvY2EvaXNzdWVycy5odG1sMDIGA1UdHwQrMCkwJ6AloCOGIWh0dHA6Ly9wa2ku
dW5pbW8uaXQvY3JsL2NhY3JsLmNybDAwBglghkgBhvhCAQQEIxYhaHR0cDovL3BraS51bmlt
by5pdC9jcmwvY2FjcmwuY3JsMDAGCWCGSAGG+EIBAwQjFiFodHRwOi8vcGtpLnVuaW1vLml0
L2NybC9jYWNybC5jcmwwKgYJYIZIAYb4QgEHBB0WG2h0dHA6Ly9wa2kudW5pbW8uaXQvcmVu
ZXdhbDArBglghkgBhvhCAQgEHhYcaHR0cDovL3BraS51bmltby5pdC9jcHMvMS4xLzCB2QYD
VR0gBIHRMIHOMEMGCisGAQQBqQcBAQEwNTAzBggrBgEFBQcCARYnaHR0cDovL3d3dy5ldXJv
cGtpLm9yZy9jYS9yb290L2Nwcy8xLjEvMEEGCisGAQQBqQcCAQEwMzAxBggrBgEFBQcCARYl
aHR0cDovL3d3dy5ldXJvcGtpLm9yZy9jYS9pdC9jcHMvMS4xLzBEBgorBgEEAegTAQEBMDYw
NAYIKwYBBQUHAgEWKGh0dHA6Ly9tYWlsLnVuaW1vLml0L2Zpcm1hL2Nwc21vZGVuYS5odG0w
DQYJKoZIhvcNAQEEBQADggEBABn8ViNg4MPNRzEFFF4BsmRMP1YbUHbS+NmFvvys0D3xueex
Ie6HU+tkv9hz8++0MbLPnRY2qKpZXfWTbIOkrHLGVVHUkiZXFzfxsDMgcB4MWmSmhRVLfPqr
RZKAjIevO0JKIksq2xutAUqX5jkqZoGHpPv9JCiSI+cDRqOOW2Fh3JBGkcULKybrdwrSN6+S
NoTyTXR+ryeTBUXxu9rIbjrJdH3rKS7rz3ZkP2PKuFOb+Vbp829ALph1SJOLQrUnmJouLOSL
oVHW4zJK4zcAiNyMHua3HveLRkVINT9eDBeYBRPdn1k+LqdXqkXiEUPA+EIKeA23F5nQkqxI
mVVpaaYwggcvMIIGF6ADAgECAgEsMA0GCSqGSIb3DQEBBAUAMIGKMSIwIAYJKoZIhvcNAQkB
FhNwa2kuY2ljYWlhQHVuaW1vLml0MScwJQYDVQQDEx5Vbmltb3JlIEVudGUgZGkgQ2VydGlm
aWNhemlvbmUxLjAsBgNVBAoTJVVuaXZlcnNpdGEnIGRpIE1vZGVuYSBlIFJlZ2dpbyBFbWls
aWExCzAJBgNVBAYTAklUMB4XDTAyMDcyNDE1MjYyNloXDTAzMTIzMTIzNTk1OVowgakxGjAY
BgNVBAMTEU1hc3NpbWlsaWFubyBQYWxhMTUwMwYDVQQLEyxEaXBhcnRpbWVudG8gZGkgSW5n
ZWduZXJpYSBkZWxsJ0luZm9ybWF6aW9uZTEXMBUGA1UECxMOU2VkZSBkaSBNb2RlbmExLjAs
BgNVBAoTJVVuaXZlcnNpdGEnIGRpIE1vZGVuYSBlIFJlZ2dpbyBFbWlsaWExCzAJBgNVBAYT
AklUMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDUnrIPNARs68r0JaZQ9DCdmFpUhFAG
aYhZssKTppf/5VjJ4TjZgv6tE6zu4/QW9feXTcwjLlxYL1ePUstYshwIw4acrBb5v8WWwEt4
/Ka1zTdtyktzmu2c9hq0KQh4LqQj0C9nMvgEVcMBaHdhjkglaFAApJ3YrfeuCv237Br8iwID
AQABo4IEATCCA/0wDAYDVR0TAQH/BAIwADARBglghkgBhvhCAQEEBAMCBaAwDgYDVR0PAQH/
BAQDAgP4MB0GA1UdJQQWMBQGCCsGAQUFBwMCBggrBgEFBQcDBDAdBgNVHQ4EFgQU+mkjuckz
D03/TnXFqNeKSi6hBzAwgbcGA1UdIwSBrzCBrIAURR2mAOGX6MlNmmlJ2WDImH+JRQOhgZCk
gY0wgYoxIjAgBgkqhkiG9w0BCQEWE3BraS5jaWNhaWFAdW5pbW8uaXQxJzAlBgNVBAMTHlVu
aW1vcmUgRW50ZSBkaSBDZXJ0aWZpY2F6aW9uZTEuMCwGA1UEChMlVW5pdmVyc2l0YScgZGkg
TW9kZW5hIGUgUmVnZ2lvIEVtaWxpYTELMAkGA1UEBhMCSVSCAQAwagYJYIZIAYb4QgENBF0W
W1Byb2dldHRvIFBvc3RhIEVsZXR0cm9uaWNhIFNpY3VyYSANClVuaXZlcnNpdGEnIGRpIE1v
ZGVuYSBlIFJlZ2dpbyBFbWlsaWEgDQpDLkkuQy5BLkkuQS4gDQowIgYDVR0RBBswGYEXbWFk
d29sZkBoYWNrbWFzdGVycy5uZXQwNAYDVR0SBC0wK4ETcGtpLmNpY2FpYUB1bmltby5pdIYU
aHR0cDovL3BraS51bmltby5pdC8wPwYIKwYBBQUHAQEEMzAxMC8GCCsGAQUFBzAChiNodHRw
Oi8vcGtpLnVuaW1vLml0L2NhL2lzc3VlcnMuaHRtbDAyBgNVHR8EKzApMCegJaAjhiFodHRw
Oi8vcGtpLnVuaW1vLml0L2NybC9jYWNybC5jcmwwMAYJYIZIAYb4QgEEBCMWIWh0dHA6Ly9w
a2kudW5pbW8uaXQvY3JsL2NhY3JsLmNybDAwBglghkgBhvhCAQMEIxYhaHR0cDovL3BraS51
bmltby5pdC9jcmwvY2FjcmwuY3JsMCoGCWCGSAGG+EIBBwQdFhtodHRwOi8vcGtpLnVuaW1v
Lml0L3JlbmV3YWwwKwYJYIZIAYb4QgEIBB4WHGh0dHA6Ly9wa2kudW5pbW8uaXQvY3BzLzEu
MS8wgdkGA1UdIASB0TCBzjBDBgorBgEEAakHAQEBMDUwMwYIKwYBBQUHAgEWJ2h0dHA6Ly93
d3cuZXVyb3BraS5vcmcvY2Evcm9vdC9jcHMvMS4xLzBBBgorBgEEAakHAgEBMDMwMQYIKwYB
BQUHAgEWJWh0dHA6Ly93d3cuZXVyb3BraS5vcmcvY2EvaXQvY3BzLzEuMS8wRAYKKwYBBAHo
EwEBATA2MDQGCCsGAQUFBwIBFihodHRwOi8vbWFpbC51bmltby5pdC9maXJtYS9jcHNtb2Rl
bmEuaHRtMA0GCSqGSIb3DQEBBAUAA4IBAQAZ/FYjYODDzUcxBRReAbJkTD9WG1B20vjZhb78
rNA98bnnsSHuh1PrZL/Yc/PvtDGyz50WNqiqWV31k2yDpKxyxlVR1JImVxc38bAzIHAeDFpk
poUVS3z6q0WSgIyHrztCSiJLKtsbrQFKl+Y5KmaBh6T7/SQokiPnA0ajjlthYdyQRpHFCysm
63cK0jevkjaE8k10fq8nkwVF8bvayG46yXR96yku6892ZD9jyrhTm/lW6fNvQC6YdUiTi0K1
J5iaLizki6FR1uMySuM3AIjcjB7mtx73i0ZFSDU/XgwXmAUT3Z9ZPi6nV6pF4hFDwPhCCngN
txeZ0JKsSJlVaWmmMYIDNjCCAzICAQEwgZAwgYoxIjAgBgkqhkiG9w0BCQEWE3BraS5jaWNh
aWFAdW5pbW8uaXQxJzAlBgNVBAMTHlVuaW1vcmUgRW50ZSBkaSBDZXJ0aWZpY2F6aW9uZTEu
MCwGA1UEChMlVW5pdmVyc2l0YScgZGkgTW9kZW5hIGUgUmVnZ2lvIEVtaWxpYTELMAkGA1UE
BhMCSVQCASwwCQYFKw4DAhoFAKCCAfswGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkq
hkiG9w0BCQUxDxcNMDMwMTI1MTMzNzAxWjAjBgkqhkiG9w0BCQQxFgQUC2Lj9Vrt2fYq8P2d
n52WPaobOqswUgYJKoZIhvcNAQkPMUUwQzAKBggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAw
DQYIKoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZIhvcNAwICASgwgaEGCSsGAQQBgjcQBDGB
kzCBkDCBijEiMCAGCSqGSIb3DQEJARYTcGtpLmNpY2FpYUB1bmltby5pdDEnMCUGA1UEAxMe
VW5pbW9yZSBFbnRlIGRpIENlcnRpZmljYXppb25lMS4wLAYDVQQKEyVVbml2ZXJzaXRhJyBk
aSBNb2RlbmEgZSBSZWdnaW8gRW1pbGlhMQswCQYDVQQGEwJJVAIBLDCBowYLKoZIhvcNAQkQ
AgsxgZOggZAwgYoxIjAgBgkqhkiG9w0BCQEWE3BraS5jaWNhaWFAdW5pbW8uaXQxJzAlBgNV
BAMTHlVuaW1vcmUgRW50ZSBkaSBDZXJ0aWZpY2F6aW9uZTEuMCwGA1UEChMlVW5pdmVyc2l0
YScgZGkgTW9kZW5hIGUgUmVnZ2lvIEVtaWxpYTELMAkGA1UEBhMCSVQCASwwDQYJKoZIhvcN
AQEBBQAEgYAro+UlHy1zxu8PRZ3V/qlMmYm3LOwkV9E3Qtg2V8Ft+92uG6Bsmxsnf4U1dhIQ
BUIqJbiwzL8nIXp30XIqChiVNO8BxXORocrPVD2MCw5a9r8GP+oD8kopYqcqZOuC21pD9+7S
Xs8l5txTiDUxyifMPH63ypExwxOraaBoHOVBLAAAAAAAAA==
--------------ms060908090306000402060303--



Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h0P5YvL12186 for ietf-pkix-bks; Fri, 24 Jan 2003 21:34:57 -0800 (PST)
Received: from sccrmhc01.attbi.com (sccrmhc01.attbi.com [204.127.202.61]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h0P5Yuo12182 for <[e-mail]>; Fri, 24 Jan 2003 21:34:56 -0800 (PST)
Received: from sesione (<unknown.domain>[12.242.154.153]) by sccrmhc01.attbi.com (sccrmhc01) with SMTP id <2003012505345400100bpei5e>; Sat, 25 Jan 2003 05:34:55 +0000
From: "Khaja Ahmed" <[e-mail]>
To: <[e-mail]>, <[e-mail]>, <[e-mail]>
Subject: STRAWPOLL:SCVP
Date: Fri, 24 Jan 2003 21:36:30 -0800
Message-ID: <[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0)
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106
Importance: Normal
In-Reply-To: <[e-mail]>
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>


Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h0P4c2o11237 for ietf-pkix-bks; Fri, 24 Jan 2003 20:38:02 -0800 (PST)
Received: from hermes.cs.auckland.ac.nz (hermes.cs.auckland.ac.nz [130.216.35.151]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h0P4c0o11233 for <[e-mail]>; Fri, 24 Jan 2003 20:38:00 -0800 (PST)
Received: from medusa01.cs.auckland.ac.nz (medusa01.cs.auckland.ac.nz [130.216.34.60]) by hermes.cs.auckland.ac.nz (8.12.4/8.12.4) with ESMTP id h0P4buOr008045; Sat, 25 Jan 2003 17:37:56 +1300
Received: (from pgut001@localhost) by medusa01.cs.auckland.ac.nz (8.11.6/8.11.6) id h0P4cP312042; Sat, 25 Jan 2003 17:38:25 +1300
Date: Sat, 25 Jan 2003 17:38:25 +1300
Message-Id: <[e-mail]>
From: [e-mail] (Peter Gutmann)
To: [e-mail], [e-mail], [e-mail], [e-mail], [e-mail]
Subject: Re: X.500, LDAP Considered harmful Was: OCSP/LDAP
Cc: [e-mail], [e-mail]
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

"Hallam-Baker, Phillip" <[e-mail]> writes:

>First let us dispense with the system designed for use by humans. We have a
>system, it is called the Web, everyone else lost, get over it.

Yup.  That's what the motivation was for my certs-over-HTTP RFC.

>The hierachical organization of the directory does not help the email
>application at all. In fact it is exactly the type of annoyance that led for
>the need for HTTP over FTP. The application knows exactly the question it
>wants to answer but that is not the question the directory will accept,
>instead we have to pay proper homage to the X.500 data model by navigating
>arround it a bit.
>
>The directory does not want to answer the question at all, instead it wants
>to play 20 questions with the client. So while what the client wants to ask
>is 'what is the email address of [e-mail]' what the
>directory wants to be asked is 'do you have any american', yes, 'do you have
>any americans working for first data', 'do you have any...' and so on.

I pointed that out in my ACSAC paper a few years ago: You take a simple query
"SELECT cert FROM foo WHERE key = bar" and then the client dresses it up as an
incredibly complex X.500 filter which the server has to do more work to
translate back into an SQL-equivalent query to actually fetch the key.  The
analogy I've used is that it's like watching a friend of mine's four-year-old
eat peas with a fork, she uses her fingers to put the peas on the fork, moves
it up to her mouth, then uses her fingers to move the peas off the fork into
her mouth, and everyone gets to say how clever she is to use a fork at her
age.  Certs in X.500 directories are the same thing.

Peter.


Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h0OMgmC02794 for ietf-pkix-bks; Fri, 24 Jan 2003 14:42:48 -0800 (PST)
Received: from peacock.verisign.com (peacock.verisign.com [65.205.251.73]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h0OMglo02790 for <[e-mail]>; Fri, 24 Jan 2003 14:42:47 -0800 (PST)
Received: from vhqpostal-gw2.verisign.com (verisign.com [65.205.251.56]) by peacock.verisign.com (8.12.1/) with ESMTP id h0OMgFq4009134; Fri, 24 Jan 2003 14:42:15 -0800 (PST)
Received: by vhqpostal-gw2.verisign.com with Internet Mail Service (5.5.2653.19) id <DQTLCVPR>; Fri, 24 Jan 2003 14:42:48 -0800
Message-ID: <[e-mail]>
From: "Hallam-Baker, Phillip" <[e-mail]>
To: Tony Bartoletti <[e-mail]>, [e-mail], [e-mail], [e-mail]
Cc: [e-mail], [e-mail]
Subject: X.500, LDAP Considered harmful Was: OCSP/LDAP
Date: Fri, 24 Jan 2003 14:42:46 -0800
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
MIME-Version: 1.0
Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; boundary="----=_NextPart_000_00D1_01C2C3CF.ED40D1D0"; micalg=SHA1
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

This is a multi-part message in MIME format.

------=_NextPart_000_00D1_01C2C3CF.ED40D1D0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit


The real question is why it has taken the industry so long to
ask this question.

There are two types of information retrieval system that
have utility. Systems designed for use by humans and systems
designed for use by machines. The Web is an example of the
former, the DNS an example of the latter.

The problem with X.500 and its descendants is that they try
to be both at the same time and end up succeeding at neither.

First let us dispense with the system designed for use by humans.
We have a system, it is called the Web, everyone else lost, get 
over it.

When a directory is used it is being used by an application such 
as email to service an actual transaction. My outlook client
is querying the GAL in response to my attempts to compose email.

Consider the question that an email client is going to ask
a certificate repository. It is not going to ask for 'C=US
O=Hopeless ...'. The question is going to be asked in the context
of a specific problem that a specific application needs to
answer. That specific context is going to be an email address
and an email application such as S/MIME or PGP.

The hierachical organization of the directory does not help
the email application at all. In fact it is exactly the type
of annoyance that led for the need for HTTP over FTP. The 
application knows exactly the question it wants to answer 
but that is not the question the directory will accept, instead
we have to pay proper homage to the X.500 data model by navigating
arround it a bit.

The directory does not want to answer the question at all, instead
it wants to play 20 questions with the client. So while what 
the client wants to ask is 'what is the email address of
[e-mail]' what the directory wants to be asked
is 'do you have any american', yes, 'do you have any americans
working for first data', 'do you have any...' and so on.

The other practical problem with directories is that they will
never reach beyond the enterprise firewall. Except in the Federal
Government enterprises guard their org charts as company
confidential information. The Federal govt would do the same but
the head hunters thought up a ruse called FOIA.

At one time there was a theory called 'border directories'. Under
this theory, organizations would decant the certificate information
from their PKI directory and publish it outside the firewall. The
teensy problems with this theory being that first it required a
duplicate directory system which was not cheap and secondly CIOs
still get nervous about putting even abstractions of sensitive
data on external IT services whose principal purpose is providing 
indexing and searching functions.

Directories have failed to move beyond the firewall, so why are
they still being plugged as the solution for PKI? The answer if
you have not worked it out yet is that the objective here is to 
deploy  X.500 which in turn will enable the transition to OSI to 
finaly begin. The idea is that PKI is to be the killer app for
X.500 even though only thing this scheme has killed to date is
plenty of attempts at PKI deployments.

What is needed is an infrastructure that is linked to the DNS
system, a DNS linked PKI. The lookups supported should be in the
terms the applications care about. For example the UseKeyWith
semantics of XKMS. Similar semantics will no doubt be proposed
for supported by the PKIX equivalent DPV specification.

The justification for introducing directory systems was based on
a falacy, namely that using email addresses was somehow less
secure than using real world names. This is clearly not the case.
I may or may not be the only Phillip Hallam-Baker at VeriSign,
however I will certainly be the only [e-mail] no matter
who they hire in the future. Equally some of the female employees
have changed their surnames several times over the past 5 years
but their old email addresses still work.

Trying to 'make it easy' has been the source of more security
problems than it could possibly have corrected. Only yesterday
I received a message sent to [e-mail] because
someone had tried to send an email to Sam and the auto-expansion
had kicked in and gone off searching the GAL when it had no business
to.

In conclusion it is time for the PKI world to seriously consider 
whether X.500 and LDAP provide the right certificate repository
structure for PKI. For myself I consider them harmful.

		Phill
 
> At 06:52 PM 1/8/2003 +1300, Peter Gutmann wrote:
> 
> >Other person: "Why is X.500 so special?  Why is no-one else 
> doing this?"
> >
> >Me: "Get your favourite book on database technology and look up
> >      'Hierarchical databases'".
> >
> >[Time passes]
> >
> >Other person: "I looked in several books.  Many didn't 
> mention it at all,
> >                and one had a half-page historical note 
> saying it's something
> >                that was obsoleted by better technology more 
> than two decades
> >                ago".
> >
> >Me: "Exactly".
> 
> 
> Heh.  Actually, hierarchical databases can be superlative to 
> most all other 
> technologies, when one has a static taxonomy to support.  Trying to 
> represent (no less manage) a dynamically changing global 
> namespace with 
> scores of independent geopolitical naming authorities with a 
> hierarchical 
> database is rather ... ridiculous. :)
> 
> Cheers!  ____tony____
> 

------=_NextPart_000_00D1_01C2C3CF.ED40D1D0
Content-Type: application/x-pkcs7-signature;
	name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment;
	filename="smime.p7s"

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINbTCCAj0w
ggGmAhEAulrJTAU7ktantt9O0FOSDTANBgkqhkiG9w0BAQIFADBfMQswCQYDVQQGEwJVUzEXMBUG
A1UEChMOVmVyaVNpZ24sIEluYy4xNzA1BgNVBAsTLkNsYXNzIDIgUHVibGljIFByaW1hcnkgQ2Vy
dGlmaWNhdGlvbiBBdXRob3JpdHkwHhcNOTYwMTI5MDAwMDAwWhcNMDQwMTA3MjM1OTU5WjBfMQsw
CQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xNzA1BgNVBAsTLkNsYXNzIDIgUHVi
bGljIFByaW1hcnkgQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkwgZ8wDQYJKoZIhvcNAQEBBQADgY0A
MIGJAoGBALZai6MNaiODgGvPOYf0IRMzBkwlou1VEpfFp4C5+oPBIKD6LxUNfKFga355LPoGDzqu
9htvsdL/LyhSX4N9S8R6t/hmH4BU/LfCjllKFFdG0ZqTvkGRA7sVgJNc6+fMCGw/PrNK/P9LbCPV
UIImRBmOI8Nx6hkkRwSedb/IpgAfAgMBAAEwDQYJKoZIhvcNAQECBQADgYEAtgAfk1ekB6dAzmVA
P1Ve7e/6VEmlMNYhfGGH7oOTC7+0M/KYrJ8Gv06ozhSBTMsETljDz1/ufNeab8tBird/gbj/hGHG
J0NlHQzssQAK3Ruku8d4ICiyot02lS7hVE+/YLl3aBGZI+jqUuiqAE5nTruQtUWbRuuOFu/EM1sz
PdUwggNDMIICrKADAgECAhAffl/nA9Hgv5kg3GuJDUsEMA0GCSqGSIb3DQEBBAUAMF8xCzAJBgNV
BAYTAlVTMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjE3MDUGA1UECxMuQ2xhc3MgMiBQdWJsaWMg
UHJpbWFyeSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTAeFw05OTAyMjUwMDAwMDBaFw0wNDAxMDUy
MzU5NTlaMIGtMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1
c3QgTmV0d29yazFJMEcGA1UECxNAVXNlIGlzIHN1YmplY3QgdG8gdGVybXMgYXQgaHR0cHM6Ly93
d3cudmVyaXNpZ24uY29tL3JwYS1rciAoYyk5OTEmMCQGA1UEAxMdVmVyaVNpZ24gQ2xhc3MgMiBQ
ZXJzb25uZWwgQ0EwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBAKcEbA+icrdKBi741yksNJ2C
vEiRSses+en8uVl4sVXAU1ixz28WO8FJ1cv0bszhzMu1xy5OiKo06bbQW3w+FVc04Ri8/931r2dZ
IArlPeqIikDSmokTKam21dunfuHnNyST/ZR0TXrkMm1M6FwWl6/dktlmihRm5OpaA6g9X/sLAgMB
AAGjgbAwga0wMQYDVR0fBCowKDAmoCSgIoYgaHR0cDovL2NybC52ZXJpc2lnbi5jb20vcGNhMi5j
cmwwEQYJYIZIAYb4QgEBBAQDAgEGMEcGA1UdIARAMD4wPAYLYIZIAYb4RQEHAQEwLTArBggrBgEF
BQcCARYfaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYS1rcjAPBgNVHRMECDAGAQH/AgEBMAsG
A1UdDwQEAwIBBjANBgkqhkiG9w0BAQQFAAOBgQB59xXN6GhRWWv8qaa94B77vPQ/kN/n+u3kVPdh
PVSLBrqXMloeqyzur3Orx13TP4/0zstOSGCiqGC2ON6gpvePKegRrMw5dlA83TlsC/Fa/QhUdt0W
bPcxcLi/CPfJJgaO37svGbG2uLToPEjoJ7GXKSBXA5ybZ/p9QMQ4fxiqmjCCA8QwggMtoAMCAQIC
EQCEzvIOADm1dVXaGYePUu2JMA0GCSqGSIb3DQEBBAUAMIGtMRcwFQYDVQQKEw5WZXJpU2lnbiwg
SW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFJMEcGA1UECxNAVXNlIGlzIHN1
YmplY3QgdG8gdGVybXMgYXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYS1rciAoYyk5OTEm
MCQGA1UEAxMdVmVyaVNpZ24gQ2xhc3MgMiBQZXJzb25uZWwgQ0EwHhcNOTkwMjI1MDAwMDAwWhcN
MDQwMTA0MjM1OTU5WjCBrDEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlT
aWduIFRydXN0IE5ldHdvcmsxSTBHBgNVBAsTQFVzZSBpcyBzdWJqZWN0IHRvIHRlcm1zIGF0IGh0
dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9ycGEta3IgKGMpOTkxJTAjBgNVBAMTHFZlcmlTaWduIENs
YXNzIDIgRW1wbG95ZWUgQ0EwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBAMCK0YdhouowA1Vr
CDbwl/oaVDUkH+h9ncjDc9PYRvWRLdk47ZTXsCZzKt6XUE3/Ihy9cACYDFgqsaRyj6W59y18YOO1
3+l9TiEhYdX8O1TJpAmcuyL5orpwYU+GRqL9BWTsCj+mWHZXuxZzRHzwpQ2XwGym8WMIJbEEF5Wg
jf5/AgMBAAGjgeIwgd8wKQYDVR0RBCIwIKQeMBwxGjAYBgNVBAMTEVByaXZhdGVMYWJlbDEtMTE4
MDgGA1UdHwQxMC8wLaAroCmGJ2h0dHA6Ly9jcmwudmVyaXNpZ24uY29tL1ZTQ2xhc3MySW50LmNy
bDARBglghkgBhvhCAQEEBAMCAQYwRwYDVR0gBEAwPjA8BgtghkgBhvhFAQcBATAtMCsGCCsGAQUF
BwIBFh9odHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBhLWtyMA8GA1UdEwQIMAYBAf8CAQAwCwYD
VR0PBAQDAgEGMA0GCSqGSIb3DQEBBAUAA4GBABlGztRrcI5YXIhCNa0WfaUJLKhTkPH2PYbX8M5y
FD0ivPLDM+3U/AWa4GMgdaMb71UZDwZzIQJhrqaeUSt43FvIhIvV17bP1fg+l5ixRIujmI6gS/aY
MZOz8AzdUXbKl+RWRMb7lKFIfSJDzKDGXHlV9WeBG2iYNCREsZjBOiheMIIEGTCCA4KgAwIBAgIQ
da9pAn9XoMlLtvoUDq8LyTANBgkqhkiG9w0BAQQFADCBrDEXMBUGA1UEChMOVmVyaVNpZ24sIElu
Yy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0IE5ldHdvcmsxSTBHBgNVBAsTQFVzZSBpcyBzdWJq
ZWN0IHRvIHRlcm1zIGF0IGh0dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9ycGEta3IgKGMpOTkxJTAj
BgNVBAMTHFZlcmlTaWduIENsYXNzIDIgRW1wbG95ZWUgQ0EwHhcNMDIwMjI3MDAwMDAwWhcNMDMw
MjI3MjM1OTU5WjBtMREwDwYDVQQKEwhWRVJJU0lHTjELMAkGA1UECxMCSFExEzARBgNVBAMTClJl
Y2lwaWVudHMxNjA0BgNVBAMTLXBiYWtlciAoSGFsbGFtLUJha2VyIFBoaWxsaXAsIFZlcmlTaWdu
LCBJbmMuKTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAtcA/okLsFi9brjmDsXQ6+g+R95B1
81Lq1EXkdzhY7XHxQ2QDq0sS2U4j9N1Ic6nHIiMq5dticztWpKdn6CrDx3Ovd5k+PACq/jSQo7NL
tlMJi7fsUrP7pM4izKu4JjSak6wRJUA4x85TSC1PLfd1u8oq16iqNJRhpEJ8VJUMRyECAwEAAaOC
AXgwggF0MAkGA1UdEwQCMAAwWQYDVR0fBFIwUDBOoEygSoZIaHR0cDovL29uc2l0ZWNybC52ZXJp
c2lnbi5jb20vVmVyaVNpZ25JbmNFeGNoYW5nZUVtcGxveWVlcy9MYXRlc3RDUkwuY3JsMAsGA1Ud
DwQEAwIFoDAeBgNVHREEFzAVgRNwYmFrZXJAdmVyaXNpZ24uY29tMIGsBgNVHSAEgaQwgaEwgZ4G
C2CGSAGG+EUBBwEBMIGOMCgGCCsGAQUFBwIBFhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vQ1BT
MGIGCCsGAQUFBwICMFYwFRYOVmVyaVNpZ24sIEluYy4wAwIBARo9VmVyaVNpZ24ncyBDUFMgaW5j
b3JwLiBieSByZWZlcmVuY2UgbGlhYi4gbHRkLiAoYyk5NyBWZXJpU2lnbjARBglghkgBhvhCAQEE
BAMCB4AwHQYDVR0lBBYwFAYIKwYBBQUHAwQGCCsGAQUFBwMCMA0GCSqGSIb3DQEBBAUAA4GBACCK
+gbdTcJB2wmWF5q8hbnP6slvVFehmjSX1Se+4Ff6a3Uiw8aOQLyNwnYUSOtHe12rTwAtWOhEgXHK
D4XY3tF7cofo5hM8dk8xsj9vV3z3fYARDr4nR2bZblPJ3MGmAFAYKW4pgX4Y6NU4VhAG2Hiuj18/
H4Cc5g5oqJp5dArUMYIC+DCCAvQCAQEwgcEwgawxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8w
HQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUkwRwYDVQQLE0BVc2UgaXMgc3ViamVjdCB0
byB0ZXJtcyBhdCBodHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBhLWtyIChjKTk5MSUwIwYDVQQD
ExxWZXJpU2lnbiBDbGFzcyAyIEVtcGxveWVlIENBAhB1r2kCf1egyUu2+hQOrwvJMAkGBSsOAwIa
BQCgggGMMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTAzMDEyNDIy
NDIxMlowIwYJKoZIhvcNAQkEMRYEFCCRG191aCL18RxhrU+bA0JAmjwdMFgGCSqGSIb3DQEJDzFL
MEkwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwICAgCAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMAcG
BSsOAwIaMAoGCCqGSIb3DQIFMIHSBgkrBgEEAYI3EAQxgcQwgcEwgawxFzAVBgNVBAoTDlZlcmlT
aWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUkwRwYDVQQLE0BVc2Ug
aXMgc3ViamVjdCB0byB0ZXJtcyBhdCBodHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBhLWtyIChj
KTk5MSUwIwYDVQQDExxWZXJpU2lnbiBDbGFzcyAyIEVtcGxveWVlIENBAhB1r2kCf1egyUu2+hQO
rwvJMA0GCSqGSIb3DQEBAQUABIGAJNI7Mebkpx8dSabWQcJ9AXMAGjDTxBwUNdqkUJBH68toPb/U
5wYwzMu78Mrax7J5EYEXuyJdGJjwVsDIy8sPst7ve0QStdVxRh6YOZ8Xui6mVw5HeoRAKSlVxgFt
DN1HC7Vb/wAnbUhADpn4OLCjxewGYR60GTM7X5ds++YXqYQAAAAAAAA=

------=_NextPart_000_00D1_01C2C3CF.ED40D1D0--



Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h0OKECv27627 for ietf-pkix-bks; Fri, 24 Jan 2003 12:14:12 -0800 (PST)
Received: from postmark.nist.gov (pushme.nist.gov [129.6.16.92]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h0OKEBo27623 for <[e-mail]>; Fri, 24 Jan 2003 12:14:11 -0800 (PST)
Received: from ofb.nist.gov (ofb.ncsl.nist.gov [129.6.54.187]) by postmark.nist.gov (8.12.5/8.12.5) with ESMTP id h0OKDnuo019103; Fri, 24 Jan 2003 15:13:49 -0500 (EST)
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Version 5.1
Date: Fri, 24 Jan 2003 15:13:13 -0500
To: [e-mail]
From: Christopher Brown <[e-mail]>
Subject: Re: Progress report: RFC 3280/3281 Interop testing
Cc: Tim Polk <[e-mail]>
In-Reply-To: <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"; format=flowed
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id h0OKEBo27624
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

>------------------------------- remaining features for RFC 3280 and 3281 
>----------------------
>
>CERTIFICATE FIELD #2: subject
>*       empty subject DN with critical altSubjectName (need 1 example ­ 
>have MISPC)
>**** COMPLETE ****



>CERTIFICATE FIELD #6: subjectAltName
>b)      OtherName
>**** COMPLETE ****


Thanks Steve Henson and David Cross



Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h0OK4vc27178 for ietf-pkix-bks; Fri, 24 Jan 2003 12:04:57 -0800 (PST)
Received: from email.authentidate.de (mailgw.wisnet.de [213.61.157.66]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h0OK4to27158 for <[e-mail]>; Fri, 24 Jan 2003 12:04:55 -0800 (PST)
Received: from pD9521BE3.dip.t-dialin.net ([217.82.27.227]) by email.authentidate.de (AuthentiCom SMTP Server Isaf-2.0-20020306-RC2) with ESMTP id 137 (using TLSv1/SSLv3 with RSA_WITH_RC4_128_MD5 verified FAIL) for <[e-mail]>; Fri, 24 Jan 2003 21:04:45 +0100 (CET)
X-Authentication-Warning: email.authentidate.de: Host pD9521BE3.dip.t-dialin.net [217.82.27.227] claimed to be mystery.inexnet.de
X-Authentication-Sasl-User: al
X-Authentication-Sasl-Mechanism: CRAM-MD5
Subject: STRAWPOLL:OCSP
From: Andreas Laumann <[e-mail]>
To: "'[e-mail]'" <[e-mail]>
In-Reply-To: <[e-mail]>
References: <[e-mail]>
Content-Type: text/plain
Organization: Authentidate International AG
Message-Id: <[e-mail]>
Mime-Version: 1.0
X-Mailer: Ximian Evolution 1.1.1 (Preview Release)
Date: 24 Jan 2003 20:56:22 +0100
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>


Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h0OJe2O26321 for ietf-pkix-bks; Fri, 24 Jan 2003 11:40:02 -0800 (PST)
Received: from mail-green.research.att.com (mail-green.research.att.com [135.207.30.103]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h0OJe1o26315 for <[e-mail]>; Fri, 24 Jan 2003 11:40:01 -0800 (PST)
Received: from postal.research.att.com (postal.research.att.com [135.207.23.30]) by mail-green.research.att.com (Postfix) with ESMTP id E778A1E042; Fri, 24 Jan 2003 14:39:57 -0500 (EST)
Received: from berkshire.research.att.com (postal.research.att.com [135.207.23.30]) by postal.research.att.com (8.8.7/8.8.7) with ESMTP id OAA02616; Fri, 24 Jan 2003 14:39:52 -0500 (EST)
Received: from research.att.com (localhost [127.0.0.1]) by berkshire.research.att.com (Postfix) with ESMTP id 3E76D7B4D; Fri, 24 Jan 2003 14:39:51 -0500 (EST)
X-Mailer: exmh version 2.5 07/13/2001 with nmh-1.0.4
From: "Steven M. Bellovin" <[e-mail]>
To: [e-mail]
Cc: "Jeffrey I. Schiller" <[e-mail]>, "Santosh Chokhani" <[e-mail]>, "Warwick Ford" <[e-mail]>, "Randy V. Sabett" <[e-mail]>, "Charles (Chas) R. Merrill" <[e-mail]>, "Stephen S. Wu" <[e-mail]>, "IETF PKIX WG List" <[e-mail]>
Subject: Re: IESG Comments on draft-ietf-pkix-ipki-new-rfc2527-01.txt 
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Date: Fri, 24 Jan 2003 14:39:51 -0500
Message-Id: <[e-mail]>
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

In message <[e-mail]>, "Alice Sturgeon
" writes:
>There are lots of people, including me, who are looking forward to this new
>RFC being issued.  We should really try to get past the stumbling blocks.
>On the first point, I would only note that RFC 2527 does not have a security
>considerations section.  Is it mandatory that informational RFCs have a
>security considerations section?  Having said that, both the effective RFC
>and the I-D deal extensively with security, and the considerations emanating
>from the provisions of this subject (in both the RFC and the I-D) seem, to
>me, blindingly obvious.  Nonetheless, it would not be difficult to distill
>some of the most important security concepts and put them into a discrete
>section.  Another question: is it appropriate to reference other standards,
>in this context to point readers in the direction of extensive and detailed
>security guidance?  Security considerations would note that developing and
>implementing a CP and CPS imply a total secure environment with controls
>commensurate to the level of assurance and applications to be used.  I'd
>reference some of the ISO standards that help in that regard, such as ISO
>Technical Report 13335 Guidelines on the management of IT security, or ISO
>17799 Code of practice for information security management, as examples.

It's absolutely appropriate.

My own view is that a Security Considerations section should discuss 
residual vulnerabilities, especially non-obvious ones, and the 
appropriate countermasures.  The issue of a total secure environment is 
an obvious candidate.

>On the second point, the authors of the revision did a mapping as is
>recommended in the message below.  This was done for revision purposes, in
>April 2001; I believe the intent was to offer a mapping for those who had
>CPs/CPSs based on RFC 2527, to facilitate a conversion and comparison
>between CPs/CPSs based on the 1999 RFC and those based on the revision, but
>it was planned to offer this separately from the new RFC.  Note that there
>was some argument that, once XML-type tagging is used for automating this
>type of document, then the manual mapping would be unnecessary.  If it
>thought to be desirable, then the mapping that was done (almost two years
>ago now) is probably still available and valid, but I defer to the authors
>on that point.  It should not be overly difficult to extract from the
>mapping the substantive changes that have been made.

A detailed field-by-field mapping isn't necessarily what's called for 
here, though it wouldn't hurt.  A general description of the nature of 
the changes would be useful.

		--Steve Bellovin, http://www.research.att.com/~smb (me)
		http://www.wilyhacker.com (2nd edition of "Firewalls" book)




Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h0OI4SL22580 for ietf-pkix-bks; Fri, 24 Jan 2003 10:04:28 -0800 (PST)
Received: from tomts9-srv.bellnexxia.net (tomts9.bellnexxia.net [209.226.175.53]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h0OI4Ro22576 for <[e-mail]>; Fri, 24 Jan 2003 10:04:27 -0800 (PST)
Received: from asturgeonpc ([209.217.116.67]) by tomts9-srv.bellnexxia.net (InterMail vM.5.01.04.19 201-253-122-122-119-20020516) with SMTP id <20030124180428.CBHK10918.tomts9-srv.bellnexxia.net@asturgeonpc> for <[e-mail]>; Fri, 24 Jan 2003 13:04:28 -0500
Reply-To: <[e-mail]>
From: "Alice Sturgeon" <[e-mail]>
To: "Pkix" <[e-mail]>
Subject: STRAWPOLL:SCVP
Date: Fri, 24 Jan 2003 13:08:54 -0500
Message-ID: <[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0)
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400
Importance: Normal
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Alice Sturgeon
Chair
Canadian Advisory Committee - Information Technology Security
ISO/IEC JTC1 SC 27 
and
System Policy Architect
SPYRUS
Phone:     [phone]
Cell:         613-291-0331


 




Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h0OHuI222166 for ietf-pkix-bks; Fri, 24 Jan 2003 09:56:18 -0800 (PST)
Received: from ocasey.baltimore.com (ocasey.baltimore.com [193.41.17.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h0OHuHo22162 for <[e-mail]>; Fri, 24 Jan 2003 09:56:17 -0800 (PST)
Received: from Baltimore-FW1 ([172.19.1.1]) by ocasey.baltimore.com (8.11.6/8.9.3) with SMTP id h0OHk1A27197 for <[e-mail]>; Fri, 24 Jan 2003 17:46:01 GMT
Received: from  ([10.153.25.53]) by Baltimore-FW1; Fri, 24 Jan 2003 17:52:40 +0000 (GMT)
Received: from Baltimore-FW1 (wilde-i-1.ie.baltimore.com) by emeairlsw1.baltimore.com (Content Technologies SMTPRS 4.2.5) with SMTP id <[e-mail]> for <[e-mail]>; Fri, 24 Jan 2003 17:47:34 +0000
Received: from  ([10.153.25.10]) by Baltimore-FW1; Fri, 24 Jan 2003 17:52:38 +0000 (GMT)
Received: from sequoia.baltimore.ie (sequoia.ie.baltimore.com [10.153.4.55]) by bobcat.baltimore.ie (8.9.3/8.9.3) with ESMTP id RAA23041 for <[e-mail]>; Fri, 24 Jan 2003 17:56:08 GMT
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Version 4.3.1
Date: Fri, 24 Jan 2003 17:56:08 +0000
To: [e-mail]
From: Eamonn Maher <[e-mail]>
Subject: STRAWPOLL:OCSP
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

-----------------------------------------------------------------------------
The information contained in this message is confidential and is intended
for the addressee(s) only.  If you have received this message in error or
there are any problems please notify the originator immediately.  The 
unauthorised use, disclosure, copying or alteration of this message is 
strictly forbidden. Baltimore Technologies plc will not be liable for
direct, special, indirect or consequential damages arising from alteration
of the contents of this message by a third party or as a result of any 
virus being passed on.

This footnote confirms that this email message has been swept for Content
Security threats, including computer viruses.
http://www.baltimore.com



Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h0OHRBi19247 for ietf-pkix-bks; Fri, 24 Jan 2003 09:27:11 -0800 (PST)
Received: from pigeon.verisign.com (pigeon.verisign.com [65.205.251.71]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h0OHRAo19242 for <[e-mail]>; Fri, 24 Jan 2003 09:27:10 -0800 (PST)
Received: from vhqpostal-gw1.verisign.com (verisign.com [65.205.251.55]) by pigeon.verisign.com (8.12.1/) with ESMTP id h0OHPS3k013515 for <[e-mail]>; Fri, 24 Jan 2003 09:25:28 -0800 (PST)
Received: by vhqpostal-gw1.verisign.com with Internet Mail Service (5.5.2656.59) id <ZHLNHPSM>; Fri, 24 Jan 2003 09:27:11 -0800
Message-ID: <[e-mail]>
From: "Ford, Warwick" <[e-mail]>
To: "'[e-mail]'" <[e-mail]>
Subject: STRAWPOLL:OCSP
Date: Fri, 24 Jan 2003 09:27:11 -0800
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2656.59)
Content-Type: text/plain; charset="iso-8859-1"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>


Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h0OH9jj17550 for ietf-pkix-bks; Fri, 24 Jan 2003 09:09:45 -0800 (PST)
Received: from az25ege02.gd-decisionsystems.com (az25ege02.gd-decisionsystems.com [65.121.28.21]) by above.proper.com (8.11.6/8.11.3) with SMTP id h0OH9io17545 for <[e-mail]>; Fri, 24 Jan 2003 09:09:44 -0800 (PST)
Received: from az25egi01.gddsi.com ([10.240.16.60]) by az25ege02 with InterScan Messaging Security Suite for SMTP; Fri, 24 Jan 2003 10:17:11 -0700
Received: from az25exf01.gddsi.com ([10.240.12.50]) by az25egi02.gddsi.com with InterScan Messaging Security Suite for SMTP; Fri, 24 Jan 2003 10:09:36 -0700
Received: from AZ25EXM01N2.gddsi.com ([10.240.12.42]) by az25exf01.gddsi.com with Microsoft SMTPSVC(5.0.2195.4905); Fri, 24 Jan 2003 10:09:08 -0700
X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3
content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Subject: Strawpoll: OCSP
Date: Fri, 24 Jan 2003 10:08:26 -0700
Message-ID: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: Strawpoll: OCSP
Thread-Index: AcLDyzV74usWRts6TqObe/aWoVra9w==
From: "Covey Carlin-p56287" <[e-mail]>
To: <[e-mail]>
X-OriginalArrivalTime: 24 Jan 2003 17:09:09.0154 (UTC) FILETIME=[4F08A820:01C2C3CB]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id h0OH9io17547
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>


Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h0OGCgF14506 for ietf-pkix-bks; Fri, 24 Jan 2003 08:12:42 -0800 (PST)
Received: from pigeon.verisign.com (pigeon.verisign.com [65.205.251.71]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h0OGCfo14502 for <[e-mail]>; Fri, 24 Jan 2003 08:12:41 -0800 (PST)
Received: from vhqpostal-gw1.verisign.com (verisign.com [65.205.251.55]) by pigeon.verisign.com (8.12.1/) with ESMTP id h0OGB03k001819 for <[e-mail]>; Fri, 24 Jan 2003 08:11:00 -0800 (PST)
Received: by vhqpostal-gw1.verisign.com with Internet Mail Service (5.5.2656.59) id <ZHLNHKR1>; Fri, 24 Jan 2003 08:12:42 -0800
Message-ID: <[e-mail]>
From: "Hallam-Baker, Phillip" <[e-mail]>
To: [e-mail]
Subject: STRAWPOLL:OCSP
Date: Fri, 24 Jan 2003 08:12:33 -0800
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2656.59)
MIME-Version: 1.0
Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; boundary="----=_NextPart_000_00A1_01C2C399.05458550"; micalg=SHA1
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

This is a multi-part message in MIME format.

------=_NextPart_000_00A1_01C2C399.05458550
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit


------=_NextPart_000_00A1_01C2C399.05458550
Content-Type: application/x-pkcs7-signature;
	name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment;
	filename="smime.p7s"

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINbTCCAj0w
ggGmAhEAulrJTAU7ktantt9O0FOSDTANBgkqhkiG9w0BAQIFADBfMQswCQYDVQQGEwJVUzEXMBUG
A1UEChMOVmVyaVNpZ24sIEluYy4xNzA1BgNVBAsTLkNsYXNzIDIgUHVibGljIFByaW1hcnkgQ2Vy
dGlmaWNhdGlvbiBBdXRob3JpdHkwHhcNOTYwMTI5MDAwMDAwWhcNMDQwMTA3MjM1OTU5WjBfMQsw
CQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xNzA1BgNVBAsTLkNsYXNzIDIgUHVi
bGljIFByaW1hcnkgQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkwgZ8wDQYJKoZIhvcNAQEBBQADgY0A
MIGJAoGBALZai6MNaiODgGvPOYf0IRMzBkwlou1VEpfFp4C5+oPBIKD6LxUNfKFga355LPoGDzqu
9htvsdL/LyhSX4N9S8R6t/hmH4BU/LfCjllKFFdG0ZqTvkGRA7sVgJNc6+fMCGw/PrNK/P9LbCPV
UIImRBmOI8Nx6hkkRwSedb/IpgAfAgMBAAEwDQYJKoZIhvcNAQECBQADgYEAtgAfk1ekB6dAzmVA
P1Ve7e/6VEmlMNYhfGGH7oOTC7+0M/KYrJ8Gv06ozhSBTMsETljDz1/ufNeab8tBird/gbj/hGHG
J0NlHQzssQAK3Ruku8d4ICiyot02lS7hVE+/YLl3aBGZI+jqUuiqAE5nTruQtUWbRuuOFu/EM1sz
PdUwggNDMIICrKADAgECAhAffl/nA9Hgv5kg3GuJDUsEMA0GCSqGSIb3DQEBBAUAMF8xCzAJBgNV
BAYTAlVTMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjE3MDUGA1UECxMuQ2xhc3MgMiBQdWJsaWMg
UHJpbWFyeSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTAeFw05OTAyMjUwMDAwMDBaFw0wNDAxMDUy
MzU5NTlaMIGtMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1
c3QgTmV0d29yazFJMEcGA1UECxNAVXNlIGlzIHN1YmplY3QgdG8gdGVybXMgYXQgaHR0cHM6Ly93
d3cudmVyaXNpZ24uY29tL3JwYS1rciAoYyk5OTEmMCQGA1UEAxMdVmVyaVNpZ24gQ2xhc3MgMiBQ
ZXJzb25uZWwgQ0EwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBAKcEbA+icrdKBi741yksNJ2C
vEiRSses+en8uVl4sVXAU1ixz28WO8FJ1cv0bszhzMu1xy5OiKo06bbQW3w+FVc04Ri8/931r2dZ
IArlPeqIikDSmokTKam21dunfuHnNyST/ZR0TXrkMm1M6FwWl6/dktlmihRm5OpaA6g9X/sLAgMB
AAGjgbAwga0wMQYDVR0fBCowKDAmoCSgIoYgaHR0cDovL2NybC52ZXJpc2lnbi5jb20vcGNhMi5j
cmwwEQYJYIZIAYb4QgEBBAQDAgEGMEcGA1UdIARAMD4wPAYLYIZIAYb4RQEHAQEwLTArBggrBgEF
BQcCARYfaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYS1rcjAPBgNVHRMECDAGAQH/AgEBMAsG
A1UdDwQEAwIBBjANBgkqhkiG9w0BAQQFAAOBgQB59xXN6GhRWWv8qaa94B77vPQ/kN/n+u3kVPdh
PVSLBrqXMloeqyzur3Orx13TP4/0zstOSGCiqGC2ON6gpvePKegRrMw5dlA83TlsC/Fa/QhUdt0W
bPcxcLi/CPfJJgaO37svGbG2uLToPEjoJ7GXKSBXA5ybZ/p9QMQ4fxiqmjCCA8QwggMtoAMCAQIC
EQCEzvIOADm1dVXaGYePUu2JMA0GCSqGSIb3DQEBBAUAMIGtMRcwFQYDVQQKEw5WZXJpU2lnbiwg
SW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFJMEcGA1UECxNAVXNlIGlzIHN1
YmplY3QgdG8gdGVybXMgYXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYS1rciAoYyk5OTEm
MCQGA1UEAxMdVmVyaVNpZ24gQ2xhc3MgMiBQZXJzb25uZWwgQ0EwHhcNOTkwMjI1MDAwMDAwWhcN
MDQwMTA0MjM1OTU5WjCBrDEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlT
aWduIFRydXN0IE5ldHdvcmsxSTBHBgNVBAsTQFVzZSBpcyBzdWJqZWN0IHRvIHRlcm1zIGF0IGh0
dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9ycGEta3IgKGMpOTkxJTAjBgNVBAMTHFZlcmlTaWduIENs
YXNzIDIgRW1wbG95ZWUgQ0EwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBAMCK0YdhouowA1Vr
CDbwl/oaVDUkH+h9ncjDc9PYRvWRLdk47ZTXsCZzKt6XUE3/Ihy9cACYDFgqsaRyj6W59y18YOO1
3+l9TiEhYdX8O1TJpAmcuyL5orpwYU+GRqL9BWTsCj+mWHZXuxZzRHzwpQ2XwGym8WMIJbEEF5Wg
jf5/AgMBAAGjgeIwgd8wKQYDVR0RBCIwIKQeMBwxGjAYBgNVBAMTEVByaXZhdGVMYWJlbDEtMTE4
MDgGA1UdHwQxMC8wLaAroCmGJ2h0dHA6Ly9jcmwudmVyaXNpZ24uY29tL1ZTQ2xhc3MySW50LmNy
bDARBglghkgBhvhCAQEEBAMCAQYwRwYDVR0gBEAwPjA8BgtghkgBhvhFAQcBATAtMCsGCCsGAQUF
BwIBFh9odHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBhLWtyMA8GA1UdEwQIMAYBAf8CAQAwCwYD
VR0PBAQDAgEGMA0GCSqGSIb3DQEBBAUAA4GBABlGztRrcI5YXIhCNa0WfaUJLKhTkPH2PYbX8M5y
FD0ivPLDM+3U/AWa4GMgdaMb71UZDwZzIQJhrqaeUSt43FvIhIvV17bP1fg+l5ixRIujmI6gS/aY
MZOz8AzdUXbKl+RWRMb7lKFIfSJDzKDGXHlV9WeBG2iYNCREsZjBOiheMIIEGTCCA4KgAwIBAgIQ
da9pAn9XoMlLtvoUDq8LyTANBgkqhkiG9w0BAQQFADCBrDEXMBUGA1UEChMOVmVyaVNpZ24sIElu
Yy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0IE5ldHdvcmsxSTBHBgNVBAsTQFVzZSBpcyBzdWJq
ZWN0IHRvIHRlcm1zIGF0IGh0dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9ycGEta3IgKGMpOTkxJTAj
BgNVBAMTHFZlcmlTaWduIENsYXNzIDIgRW1wbG95ZWUgQ0EwHhcNMDIwMjI3MDAwMDAwWhcNMDMw
MjI3MjM1OTU5WjBtMREwDwYDVQQKEwhWRVJJU0lHTjELMAkGA1UECxMCSFExEzARBgNVBAMTClJl
Y2lwaWVudHMxNjA0BgNVBAMTLXBiYWtlciAoSGFsbGFtLUJha2VyIFBoaWxsaXAsIFZlcmlTaWdu
LCBJbmMuKTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAtcA/okLsFi9brjmDsXQ6+g+R95B1
81Lq1EXkdzhY7XHxQ2QDq0sS2U4j9N1Ic6nHIiMq5dticztWpKdn6CrDx3Ovd5k+PACq/jSQo7NL
tlMJi7fsUrP7pM4izKu4JjSak6wRJUA4x85TSC1PLfd1u8oq16iqNJRhpEJ8VJUMRyECAwEAAaOC
AXgwggF0MAkGA1UdEwQCMAAwWQYDVR0fBFIwUDBOoEygSoZIaHR0cDovL29uc2l0ZWNybC52ZXJp
c2lnbi5jb20vVmVyaVNpZ25JbmNFeGNoYW5nZUVtcGxveWVlcy9MYXRlc3RDUkwuY3JsMAsGA1Ud
DwQEAwIFoDAeBgNVHREEFzAVgRNwYmFrZXJAdmVyaXNpZ24uY29tMIGsBgNVHSAEgaQwgaEwgZ4G
C2CGSAGG+EUBBwEBMIGOMCgGCCsGAQUFBwIBFhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vQ1BT
MGIGCCsGAQUFBwICMFYwFRYOVmVyaVNpZ24sIEluYy4wAwIBARo9VmVyaVNpZ24ncyBDUFMgaW5j
b3JwLiBieSByZWZlcmVuY2UgbGlhYi4gbHRkLiAoYyk5NyBWZXJpU2lnbjARBglghkgBhvhCAQEE
BAMCB4AwHQYDVR0lBBYwFAYIKwYBBQUHAwQGCCsGAQUFBwMCMA0GCSqGSIb3DQEBBAUAA4GBACCK
+gbdTcJB2wmWF5q8hbnP6slvVFehmjSX1Se+4Ff6a3Uiw8aOQLyNwnYUSOtHe12rTwAtWOhEgXHK
D4XY3tF7cofo5hM8dk8xsj9vV3z3fYARDr4nR2bZblPJ3MGmAFAYKW4pgX4Y6NU4VhAG2Hiuj18/
H4Cc5g5oqJp5dArUMYIC+DCCAvQCAQEwgcEwgawxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8w
HQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUkwRwYDVQQLE0BVc2UgaXMgc3ViamVjdCB0
byB0ZXJtcyBhdCBodHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBhLWtyIChjKTk5MSUwIwYDVQQD
ExxWZXJpU2lnbiBDbGFzcyAyIEVtcGxveWVlIENBAhB1r2kCf1egyUu2+hQOrwvJMAkGBSsOAwIa
BQCgggGMMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTAzMDEyNDE2
MDkxMFowIwYJKoZIhvcNAQkEMRYEFH5vANSPAI9GltC/AQ5GUiedsb5sMFgGCSqGSIb3DQEJDzFL
MEkwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwICAgCAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMAcG
BSsOAwIaMAoGCCqGSIb3DQIFMIHSBgkrBgEEAYI3EAQxgcQwgcEwgawxFzAVBgNVBAoTDlZlcmlT
aWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUkwRwYDVQQLE0BVc2Ug
aXMgc3ViamVjdCB0byB0ZXJtcyBhdCBodHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBhLWtyIChj
KTk5MSUwIwYDVQQDExxWZXJpU2lnbiBDbGFzcyAyIEVtcGxveWVlIENBAhB1r2kCf1egyUu2+hQO
rwvJMA0GCSqGSIb3DQEBAQUABIGANSUXYRlJRjfcvj5Y/PMVmsyfwe+IgIo+Q3xV0jBzM/BxZI6x
F9can4K8mE3nOrjz4xW94KpSbX+BPHyH3wlH2zilYcb09TIhYvb8PPbPUbefoSVPsf6dXn+DyQRg
T7QDumRKjAId3yZezNqdBVOlj/dOxWNsNoz2xWDTvXTDH2gAAAAAAAA=

------=_NextPart_000_00A1_01C2C399.05458550--



Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h0OFtvK13300 for ietf-pkix-bks; Fri, 24 Jan 2003 07:55:57 -0800 (PST)
Received: from osf1.gmu.edu (osf1.gmu.edu [129.174.1.13]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h0OFtto13294 for <[e-mail]>; Fri, 24 Jan 2003 07:55:55 -0800 (PST)
Received: from phessecpq (gemini@[129.174.244.115]) by osf1.gmu.edu (8.8.8/8.8.8) with ESMTP id KAA155984 for <[e-mail]>; Fri, 24 Jan 2003 10:55:51 -0500 (EST)
Reply-To: <[e-mail]>
From: "Peter Hesse" <[e-mail]>
To: <[e-mail]>
Subject: STRAWPOLL: SCVP
Date: Fri, 24 Jan 2003 10:55:50 -0500
Organization: Gemini Security Solutions, Inc.
Message-ID: <004b01c2c3c1$145e1610$6501a8c0@phessecpq>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_004C_01C2C397.2B880E10"
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook, Build 10.0.4024
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106
Importance: Normal
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

This is a multi-part message in MIME format.

------=_NextPart_000_004C_01C2C397.2B880E10
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit

 

------=_NextPart_000_004C_01C2C397.2B880E10
Content-Type: text/html;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Dus-ascii">
<TITLE>Message</TITLE>

<META content=3D"MSHTML 6.00.2800.1126" name=3DGENERATOR></HEAD>
<BODY>
<DIV>&nbsp;</DIV></BODY></HTML>

------=_NextPart_000_004C_01C2C397.2B880E10--



Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h0OEpoK07344 for ietf-pkix-bks; Fri, 24 Jan 2003 06:51:50 -0800 (PST)
Received: from CORPSRV1.Alacris.com ([64.26.153.194]) by above.proper.com (8.11.6/8.11.3) with SMTP id h0OEpno07338 for <[e-mail]>; Fri, 24 Jan 2003 06:51:50 -0800 (PST)
content-class: urn:content-classes:message
Subject: STRAWPOLL:OCSP
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Date: Fri, 24 Jan 2003 09:51:41 -0500
X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0
Message-ID: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: STRAWPOLL:OCSP
Thread-Index: AcLDIf9txSg/MFoPRka6pDyOnhs4BQAlhFHw
From: "Denis Issoupov" <[e-mail]>
To: "pkix" <[e-mail]>
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id h0OEpoo07340
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>


Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h0OEmbT07223 for ietf-pkix-bks; Fri, 24 Jan 2003 06:48:37 -0800 (PST)
Received: from gto-mailer1.bbn.com (cam-mailer1.bbn.com [128.33.0.36]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h0OEmXo07215 for <[e-mail]>; Fri, 24 Jan 2003 06:48:33 -0800 (PST)
Received: from [128.89.88.34] (comsec.bbn.com [128.89.88.34]) by gto-mailer1.bbn.com (8.9.3+Sun/8.9.3) with ESMTP id JAA06500; Fri, 24 Jan 2003 09:48:24 -0500 (EST)
Mime-Version: 1.0
X-Sender: [e-mail] (Unverified)
Message-Id: <p05111a09ba5239fbea40@[128.89.89.100]>
In-Reply-To:  <[e-mail]>
References:  <[e-mail]>
Date: Mon, 20 Jan 2003 18:44:54 -0500
To: "James Jing" <[e-mail]>
From: Stephen Kent <[e-mail]>
Subject: RE: "Basic" path-validation question
Cc: <[e-mail]>
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

At 12:53 PM +1100 1/20/03, James Jing wrote:
>So you really want to check whether a certificate is valid for A 
>PURPOSE. I suppose this is beyond general path validation, but it 
>definitely is a real-world issue.
>
>My suggested approach would be to query your validation 
>server/library by indicating how the certificate is going to be 
>used, perhaps using a policy identifier.

Yes this is completely within the province of the DPD/DPV specs, 
where an application can specify the policy relative to which a cert 
should be validated.

Steve



Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h0OELih06061 for ietf-pkix-bks; Fri, 24 Jan 2003 06:21:44 -0800 (PST)
Received: from sonne.sit.fraunhofer.de (sonne.darmstadt.gmd.de [141.12.62.20]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h0OELho06054 for <[e-mail]>; Fri, 24 Jan 2003 06:21:43 -0800 (PST)
Received: from sit.fraunhofer.de (pc-rogerrabbit [141.12.35.140]) by sonne.sit.fraunhofer.de (8.8.8/8.8.5) with ESMTP id PAA07354 for <[e-mail]>; Fri, 24 Jan 2003 15:21:33 +0100 (MET)
Message-ID: <[e-mail]>
Date: Fri, 24 Jan 2003 15:22:47 +0100
From: Brian Hunter <[e-mail]>
X-Mailer: Mozilla 4.76 [en] (Windows NT 5.0; U)
X-Accept-Language: en
MIME-Version: 1.0
To: [e-mail]
Subject: STRAWPOLL:CVP
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

 


Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h0OAJeU18256 for ietf-pkix-bks; Fri, 24 Jan 2003 02:19:40 -0800 (PST)
Received: from firewall.andxor.com (firewall.andxor.it [195.223.2.2]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h0OAJbo18247 for <[e-mail]>; Fri, 24 Jan 2003 02:19:38 -0800 (PST)
Received: from com-and.com (lello.andxor.it [195.223.2.223]) by firewall.andxor.com (8.12.3/8.12.3) with ESMTP id h0OAJV5D053639 for <[e-mail]>; Fri, 24 Jan 2003 11:19:33 +0100 (CET) (envelope-from [e-mail])
Message-ID: <[e-mail]>
Date: Fri, 24 Jan 2003 11:21:31 +0100
From: "Ing. Raffaello Galli" <[e-mail]>
Organization: C&A   - Improving Your Security -
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0rc2) Gecko/20020512 Netscape/7.0b1
X-Accept-Language: en-us, en, it
MIME-Version: 1.0
CC: [e-mail]
Subject: STRAWPOLL:DVCS
References: <[e-mail]> <[e-mail]> <[e-mail]>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>


Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h0O9AVi09120 for ietf-pkix-bks; Fri, 24 Jan 2003 01:10:31 -0800 (PST)
Received: from dns1.pvt.cz (spider.pvt.cz [194.149.101.200]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h0O9ATo09114 for <[e-mail]>; Fri, 24 Jan 2003 01:10:29 -0800 (PST)
Received: from BRNW01.pvt.cz (brnw01.pvt.cz [172.17.41.49]) by dns1.pvt.cz (8.11.2/8.11.2) with ESMTP id h0O9ASZ23035 for <[e-mail]>; Fri, 24 Jan 2003 10:10:28 +0100
Content-Class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-2"
Subject: STRAWPOLL:DVCS
X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3
Date: Fri, 24 Jan 2003 10:10:27 +0100
Message-ID: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: STRAWPOLL:DVCS
thread-index: AcLDJCNJrAV8+f5gQRuKa6F/IsLkvAAY8QCQ
From: "Pinkava Jaroslav" <[e-mail]>
To: <[e-mail]>
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id h0O9AUo09116
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Jaroslav Pinkava
http://www.pvt.cz
http://www.ica.cz 





Ing. Jaroslav Pinkava, CSc., 
PVT a.s.
Veveøí 102 
602 00, Brno
telefon: [phone]
fax:    [phone]




Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h0O4jim03196 for ietf-pkix-bks; Thu, 23 Jan 2003 20:45:44 -0800 (PST)
Received: from flora.securenet.com.au (ns1.isecure.com.au [202.125.0.72]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h0O4jdo03187 for <[e-mail]>; Thu, 23 Jan 2003 20:45:42 -0800 (PST)
Received: from leal.securenet.com.au (leal.securenet.com.au [202.125.0.94]) by flora.securenet.com.au (8.12.5/8.12.5/Debian-1) with ESMTP id h0O4jeI1029640 for <[e-mail]>; Fri, 24 Jan 2003 15:45:40 +1100
Received: (from root@localhost) by leal.securenet.com.au (8.12.6/8.12.6) id h0O4jdd9026545 for <[e-mail]>; Fri, 24 Jan 2003 15:45:39 +1100 (EST)
Received: from nodnsquery(10.11.3.10) by leal.securenet.com.au via csmap (V6.0) id srcAAAtHaa2Z; Fri, 24 Jan 03 15:45:39 +1100
Received: from atlas.securenet.com.au (localhost [127.0.0.1]) by gibbons.securenet.com.au (8.12.3/8.12.3/Debian -4) with ESMTP id h0O4jdMI025642 for <[e-mail]>; Fri, 24 Jan 2003 15:45:39 +1100
Received: from AMALTHEA.securenet.com.au ([192.168.100.40]) by atlas.securenet.com.au with Microsoft SMTPSVC(5.0.2195.4905); Fri, 24 Jan 2003 15:45:37 +1100
content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Subject: STRAWPOLL:SCVP
X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3
Date: Fri, 24 Jan 2003 15:42:59 +1100
Message-ID: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: STRAWPOLL:SCVP
Thread-Index: AcLDY3m0pRH0SAm9SgmN13WqTB6wYg==
From: "James Jing" <[e-mail]>
To: <[e-mail]>
X-OriginalArrivalTime: 24 Jan 2003 04:45:37.0239 (UTC) FILETIME=[7042A670:01C2C363]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id h0O4jho03192
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

With a priviso that SCVP gets cleaned up.

Dr James Jing
Manager, Core Technologies
SecureNet Limited
Tel [phone]
Fax [phone]
Mob [phone]
Email [e-mail]




Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h0O4ht503071 for ietf-pkix-bks; Thu, 23 Jan 2003 20:43:55 -0800 (PST)
Received: from ozspyrusmail.spyrus.com.au (179.55.220.203.comindico.com.au [203.220.55.179] (may be forged)) by above.proper.com (8.11.6/8.11.3) with ESMTP id h0O4hso03066 for <[e-mail]>; Thu, 23 Jan 2003 20:43:54 -0800 (PST)
Message-ID: <E3D323E11EA4804EAF95CE1834EAA9ED0215CB@OZSPYRUSMAIL>
From: aLUNZ Scott <[e-mail]>
To: "'[e-mail]'" <[e-mail]>
Subject: STRAWPOLL:SCVP
Date: Fri, 24 Jan 2003 14:43:50 +1000
MIME-Version: 1.0
Content-Type: text/plain
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>


Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h0O2oYB27863 for ietf-pkix-bks; Thu, 23 Jan 2003 18:50:34 -0800 (PST)
Received: from c001.snv.cp.net (h020.c001.snv.cp.net [209.228.32.134]) by above.proper.com (8.11.6/8.11.3) with SMTP id h0O2oWo27854 for <[e-mail]>; Thu, 23 Jan 2003 18:50:32 -0800 (PST)
Received: (cpmta 7972 invoked from network); 23 Jan 2003 18:50:35 -0800
Received: from 67.119.2.132 (HELO C1788576A) by smtp.infoliance.com (209.228.32.134) with SMTP; 23 Jan 2003 18:50:35 -0800
X-Sent: 24 Jan 2003 02:50:35 GMT
From: "Stephen Wu" <[e-mail]>
To: <[e-mail]>
Subject: Strawpoll: OCSP
Date: Thu, 23 Jan 2003 18:50:30 -0800
Message-ID: <006901c2c353$5c68a920$c801a8c0@C1788576A>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_006A_01C2C310.4E46EFC0"
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook, Build 10.0.3416
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

This is a multi-part message in MIME format.

------=_NextPart_000_006A_01C2C310.4E46EFC0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit

 

------=_NextPart_000_006A_01C2C310.4E46EFC0
Content-Type: text/html;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Dus-ascii">
<TITLE>Message</TITLE>

<META content=3D"MSHTML 6.00.2800.1126" name=3DGENERATOR></HEAD>
<BODY>
<DIV>&nbsp;</DIV></BODY></HTML>

------=_NextPart_000_006A_01C2C310.4E46EFC0--



Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h0O2VkR26941 for ietf-pkix-bks; Thu, 23 Jan 2003 18:31:46 -0800 (PST)
Received: from kraid.nerim.net (smtp-102.nerim.net [62.4.16.102]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h0O2Vho26931 for <[e-mail]>; Thu, 23 Jan 2003 18:31:43 -0800 (PST)
Received: from jupiter.cry.pto (cryptolog.net1.nerim.net [80.65.224.225]) by kraid.nerim.net (Postfix) with ESMTP id 021A146EE0; Thu, 23 Jan 2003 15:17:49 +0100 (CET)
Received: from localhost (localhost [127.0.0.1]) by jupiter.cry.pto (Postfix) with ESMTP id BE51443C0; Thu, 23 Jan 2003 15:30:29 +0100 (CET)
Received: from callisto.cry.pto (callisto.cry.pto [10.0.1.4]) by jupiter.cry.pto (Postfix) with SMTP id 5ADF343BF; Thu, 23 Jan 2003 15:30:29 +0100 (CET)
Received: by callisto.cry.pto (sSMTP sendmail emulation); Thu, 23 Jan 2003 15:30:29 +0100
From: "Julien Stern" <[e-mail]>
Date: Thu, 23 Jan 2003 15:30:29 +0100
To: Russ Housley <[e-mail]>
Cc: [e-mail]
Subject: Re: What to do with incorrectly encoded X509 extensions ?
Message-ID: <[e-mail]>
References: <[e-mail]> <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <[e-mail]>
User-Agent: Mutt/1.4i
X-Virus-Scanned: by AMaViS new-20020517
X-Razor-id: 0648fd5a100dd099ac573a692173eacc54756e4a
X-Spam-Status: No, hits=-14.1 tests=IN_REP_TO,QUOTED_EMAIL_TEXT,REFERENCES,SPAM_PHRASE_01_02,USER_AGENT,USER_AGENT_MUTT
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Russ:

Thank a lot for your answer. I'll check from time to time to
see if they are updated.

However, this specific certificate raised the question of what to
do when an extension is incorrect (ASN.1 wise).

If a non-critical extension, say Certificate Policies or Authority
Key Identifier for example, is understood by our software but is
not correctly encoded, should we consider the whole certificate is
invalid or should we just ignore the extension, just as if we did not
understand the corresponding OID?

Both decisions seem to make sense to me:
- in the first case the rationale is that the certificate does not
  respect the profile and should therefore be dismissed
- in the second case the rationale is that we try to do our best
  to accomodate weird certificates and simply dismiss the extension
  as it is non-critical anyway

Does the standard specify the required behavior in some place I've
missed? Or should this decision be taken by the application?

Sincerely,

--
Julien Stern
Cryptolog International

On Thu, Jan 23, 2003 at 09:06:17AM -0500, Russ Housley wrote:
> Julien:
> 
> These example certificates are old.  They match RFC 2459, which has a known 
> problem in it.  We belive that the examples in RFC 3280 correct this 
> problem.  We are working to get the binary versions of the RFC 3280 
> certificates and CRLs to Paul for posting on his web page.
> 
> Russ
> 
> At 12:25 PM 1/22/2003 +0100, Julien Stern wrote:
> 
> >Hi all,
> >
> >it seems that the sample certificate pkix-ex3.ber which can be
> >downloaded from http://www.imc.org/ietf-pkix/index.html has extensions
> >which are not correct ASN.1 wise (some non-optional fields are missing).
> >
> >More specifically the Certificate Policies Extension seems to contains an
> >incorrect DER encoding within the octet string (missing 'qualifier'
> >field in a PolicyQualifierInfo).
> >
> >If an extension is critical, and does not decode correctly,
> >I assume the only option is to reject the whole certificate.
> >
> >In the present case, the extension is marked non-critical, so one option is
> >to ignore it, just when an OID is not understood. However, the situation
> >here is slightly different: the extension is understood, but invalid
> >with respect to the standard. So should I simply ignore this extension
> >or dismiss the whole certificate ?
> >
> >Sincerely,
> >
> >--
> >Julien Stern
> >Cryptolog International
> 


Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h0O1piY24183 for ietf-pkix-bks; Thu, 23 Jan 2003 17:51:44 -0800 (PST)
Received: from peacock.verisign.com (peacock.verisign.com [65.205.251.73]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h0O1pho24176 for <[e-mail]>; Thu, 23 Jan 2003 17:51:43 -0800 (PST)
Received: from vhqpostal-gw2.verisign.com (verisign.com [65.205.251.56]) by peacock.verisign.com (8.12.1/) with ESMTP id h0O1p8q6002230 for <[e-mail]>; Thu, 23 Jan 2003 17:51:13 -0800 (PST)
Received: by vhqpostal-gw2.verisign.com with Internet Mail Service (5.5.2653.19) id <DQTK04CP>; Thu, 23 Jan 2003 17:51:39 -0800
Message-ID: <[e-mail]>
From: "Deacon, Alex" <[e-mail]>
To: [e-mail]
Subject: STRAWPOLL:OCSP
Date: Thu, 23 Jan 2003 17:52:09 -0800
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain; charset="iso-8859-1"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>


Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h0O1TgJ22952 for ietf-pkix-bks; Thu, 23 Jan 2003 17:29:42 -0800 (PST)
Received: from infobro.com ([e-mail] [63.71.25.39]) by above.proper.com (8.11.6/8.11.3) with SMTP id h0O1Tfo22947 for <[e-mail]>; Thu, 23 Jan 2003 17:29:41 -0800 (PST)
Received: from red (unverified [207.199.136.153]) by infobro.com (EMWAC SMTPRS 0.83) with SMTP id <[e-mail]>; Thu, 23 Jan 2003 20:04:08 -0500
Received: by localhost with Microsoft MAPI; Thu, 23 Jan 2003 20:04:06 -0500
Message-ID: <[e-mail]>
From: "Eric D. Williams" <[e-mail]>
To: "'David P. Kemp'" <[e-mail]>
Cc: "[e-mail]" <[e-mail]>, "[e-mail]" <[e-mail]>, Stephen Kent <[e-mail]>
Subject: Voting rationale (was RE: STRAWPOLL:ABSTAIN)
Date: Thu, 23 Jan 2003 20:04:04 -0500
Organization: Information Brokers, Inc.
X-Mailer: Microsoft Internet E-mail/MAPI - 8.0.0.4211
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

All;

To me this is acceptable.  I will re-submit my vote with rational.

On Thursday, January 23, 2003 4:59 PM, David P. Kemp 
[SMTP:[e-mail]] wrote:
>
> Denis Pinkas wrote:
> >
> > > To simplify the task for the co-chairs, I would appreciate if the Subject
> > > line
> > > could specify both the strawpoll and vote, as in STRAWPOLL:xxx, where xxx
> > > is "CVP", "OCSP", or "SCVP".  (As I recall, this worked nicely for
> > > previous
> > > strawpolls.)
> >
> > This is too simplistic. Some text to support the vote should be included
> > (at least to prove that the matrixes and the drafts have been read). :-)
> >
>
> I have to agree with Denis here.  A WG process based on the number of warm
> bodies submitting rationale-less votes does not inspire confidence.  If
> each of the voters had a history of contributing to the discussion, the straw
> poll would have meaning.  With neither a history of discussion nor a
> rationale
> attached to the vote, it has none.
>
> Dave


Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h0NNP4Y16533 for ietf-pkix-bks; Thu, 23 Jan 2003 15:25:04 -0800 (PST)
Received: from petasus.ch.intel.com (petasus.ch.intel.com [143.182.124.5]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h0NNP2o16528 for <[e-mail]>; Thu, 23 Jan 2003 15:25:02 -0800 (PST)
Received: from fmsmsxvs043.fm.intel.com (fmsmsxvs043.fm.intel.com [132.233.42.129]) by petasus.ch.intel.com (8.11.6/8.11.6/d: solo.mc,v 1.49 2003/01/13 19:45:39 dmccart Exp $) with SMTP id h0NNPbc17760 for <[e-mail]>; Thu, 23 Jan 2003 23:25:37 GMT
Received: from fmsmsx019.fm.intel.com ([132.233.42.130]) by fmsmsxvs043.fm.intel.com (NAVGW 2.5.2.11) with SMTP id M2003012315230131896 ; Thu, 23 Jan 2003 15:23:01 -0800
Received: by fmsmsx019.fm.intel.com with Internet Mail Service (5.5.2653.19) id <DN1NZVSJ>; Thu, 23 Jan 2003 15:24:59 -0800
Message-ID: <[e-mail]>
From: "Walker, Jesse" <[e-mail]>
To: [e-mail], [e-mail]
Cc: [e-mail]
Subject: STRAWPOLL:SCVP
Date: Thu, 23 Jan 2003 15:24:50 -0800
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
content-class: urn:content-classes:message
Content-Type: text/plain; charset="iso-8859-1"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>


Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h0NMr5O14829 for ietf-pkix-bks; Thu, 23 Jan 2003 14:53:05 -0800 (PST)
Received: from sfemail.bankofamerica.com (sfemail.bankofamerica.com [171.159.64.14]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h0NMr4o14823 for <[e-mail]>; Thu, 23 Jan 2003 14:53:04 -0800 (PST)
Received: from sfimail.bankofamerica.com (sfimail.bankofamerica.com [171.182.72.13]) by sfemail.bankofamerica.com (8.11.1/8.11.1) with ESMTP id h0NMr2s08582 for <[e-mail]>; Thu, 23 Jan 2003 22:53:02 GMT
Received: from smtpsw03 (smtpsw03.bankofamerica.com [165.48.14.143]) by sfimail.bankofamerica.com (8.11.1/8.11.1) with ESMTP id h0NMr1h02919 for <[e-mail]>; Thu, 23 Jan 2003 22:53:01 GMT
Content-return: allowed
Date: Thu, 23 Jan 2003 14:53:00 -0800
From: "Hicks, Mack" <[e-mail]>
Subject: STRAWPOLL:OCSP
To: [e-mail]
Message-id: <[e-mail]>
MIME-version: 1.0
X-Mailer: Internet Mail Service (5.5.2655.55)
Content-type: text/plain; charset=iso-8859-1
Content-transfer-encoding: 7BIT
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Mack Hicks, SVP  
Bank of America  760-318-9345



Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h0NMaqU14000 for ietf-pkix-bks; Thu, 23 Jan 2003 14:36:52 -0800 (PST)
Received: from tholian.rsasecurity.com (tholian.securitydynamics.com [204.167.114.129]) by above.proper.com (8.11.6/8.11.3) with SMTP id h0NMaoo13996 for <[e-mail]>; Thu, 23 Jan 2003 14:36:50 -0800 (PST)
Received: from no.name.available by tholian.rsasecurity.com via smtpd (for mail.imc.org [208.184.76.43]) with SMTP; 23 Jan 2003 22:36:54 UT
Received: from ebola.securitydynamics.com (ebola.securid.com [192.80.211.4]) by sdtihq24.securid.com (Pro-8.9.3/Pro-8.9.3) with ESMTP id RAA02371; Thu, 23 Jan 2003 17:36:42 -0500 (EST)
Received: from exrsa01.rsa.com (localhost [127.0.0.1]) by ebola.securitydynamics.com (8.10.2+Sun/8.10.2) with ESMTP id h0NMXVN13387; Thu, 23 Jan 2003 17:33:31 -0500 (EST)
Received: by exrsa01.rsa.com with Internet Mail Service (5.5.2653.19) id <Y7601BYF>; Thu, 23 Jan 2003 14:36:39 -0800
Message-ID: <[e-mail]>
From: "Yee, Peter" <[e-mail]>
To: "'David P. Kemp'" <[e-mail]>
Cc: [e-mail], [e-mail], Stephen Kent <[e-mail]>
Subject: RE: STRAWPOLL:ABSTAIN
Date: Thu, 23 Jan 2003 14:47:13 -0800
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain; charset="iso-8859-1"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

>With neither a history of discussion nor a rationale
>attached to the vote, it has none.
>
>Dave

Any less so than looking at room full of bodies raising hands at an
IETF meeting?  At least in the context you actually can enumerate
each and every one of the virtual "hands" that are being raised.

						-Peter


Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h0NMSAl13602 for ietf-pkix-bks; Thu, 23 Jan 2003 14:28:10 -0800 (PST)
Received: from yancy.pkiclue.com (IDENT:root@[209.172.115.117]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h0NMS8o13598 for <[e-mail]>; Thu, 23 Jan 2003 14:28:08 -0800 (PST)
Received: from rt-dt.pkiclue.com (IDENT:root@LOCALHOST [127.0.0.1]) by yancy.pkiclue.com (8.9.3/8.9.3) with ESMTP id OAA31047 for <[e-mail]>; Thu, 23 Jan 2003 14:32:19 -0800
Message-Id: <5.1.1.6.2.20030123142639.0355b4e8@127.0.0.1>
X-Sender: pkiclue@127.0.0.1
X-Mailer: QUALCOMM Windows Eudora Version 5.1.1
Date: Thu, 23 Jan 2003 14:27:09 -0800
To: [e-mail]
From: Rodney Thayer <[e-mail]>
Subject: STRAWPOLL:OCSP
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>


Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h0NM0KU11910 for ietf-pkix-bks; Thu, 23 Jan 2003 14:00:20 -0800 (PST)
Received: from stingray.missi.ncsc.mil (stingray.missi.ncsc.mil [144.51.50.20]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h0NM0Io11904 for <[e-mail]>; Thu, 23 Jan 2003 14:00:18 -0800 (PST)
Message-ID: <[e-mail]>
Date: Thu, 23 Jan 2003 16:58:41 -0500
From: "David P. Kemp" <[e-mail]>
X-Mailer: Mozilla 4.79 [en] (X11; U; SunOS 5.7 sun4u)
X-Accept-Language: en
MIME-Version: 1.0
CC: [e-mail], [e-mail], Stephen Kent <[e-mail]>
Subject: STRAWPOLL:ABSTAIN
References: <[e-mail]> <[e-mail]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Denis Pinkas wrote:
> 
> > To simplify the task for the co-chairs, I would appreciate if the Subject line
> > could specify both the strawpoll and vote, as in STRAWPOLL:xxx, where xxx
> > is "CVP", "OCSP", or "SCVP".  (As I recall, this worked nicely for previous
> > strawpolls.)
> 
> This is too simplistic. Some text to support the vote should be included
> (at least to prove that the matrixes and the drafts have been read). :-)
> 

I have to agree with Denis here.  A WG process based on the number of warm
bodies submitting rationale-less votes does not inspire confidence.  If
each of the voters had a history of contributing to the discussion, the straw
poll would have meaning.  With neither a history of discussion nor a rationale
attached to the vote, it has none.

Dave


Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h0NLs0Q11570 for ietf-pkix-bks; Thu, 23 Jan 2003 13:54:00 -0800 (PST)
Received: from wildpackets-1.mtvwca1-dc1.genuity.net (wildpackets-1.mtvwca1-dc1.genuity.net [128.167.66.160]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h0NLrxo11566 for <[e-mail]>; Thu, 23 Jan 2003 13:53:59 -0800 (PST)
X-WildPackets-Host: <wildpackets-1.mtvwca1-dc1.genuity.net>
X-WildPackets-Rcpt: <[e-mail]>
X-WildPackets-Sndr: <[e-mail]>
Received: from Garynotebook (mail.wildpackets.com [192.216.124.1]) by wildpackets-1.mtvwca1-dc1.genuity.net (8.12.5/8.12.5) with ESMTP id h0NLrxGJ011175 for <[e-mail]>; Thu, 23 Jan 2003 13:54:00 -0800 (PST)
From: "Gary Visser" <[e-mail]>
To: <[e-mail]>
Subject: Strawpoll:SCVP
Date: Thu, 23 Jan 2003 13:53:52 -0800
Message-ID: <000e01c2c329$eb8a2590$9e03040a@Garynotebook>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook, Build 10.0.4510
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106
Importance: Normal
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>


Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h0NLhBq10971 for ietf-pkix-bks; Thu, 23 Jan 2003 13:43:11 -0800 (PST)
Received: from stingray.missi.ncsc.mil (stingray.missi.ncsc.mil [144.51.50.20]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h0NLhAo10966 for <[e-mail]>; Thu, 23 Jan 2003 13:43:10 -0800 (PST)
Message-ID: <[e-mail]>
From: "Fillingham,  David W." <[e-mail]>
To: [e-mail]
Subject: STRAWPOLL:SCVP
Date: Thu, 23 Jan 2003 16:41:46 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain; charset="iso-8859-1"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>


Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h0NLJmA09697 for ietf-pkix-bks; Thu, 23 Jan 2003 13:19:48 -0800 (PST)
Received: from tomts9-srv.bellnexxia.net (tomts9.bellnexxia.net [209.226.175.53]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h0NLJgo09687 for <[e-mail]>; Thu, 23 Jan 2003 13:19:42 -0800 (PST)
Received: from asturgeonpc ([209.226.116.191]) by tomts9-srv.bellnexxia.net (InterMail vM.5.01.04.19 201-253-122-122-119-20020516) with SMTP id <20030123211943.XYQL10918.tomts9-srv.bellnexxia.net@asturgeonpc>; Thu, 23 Jan 2003 16:19:43 -0500
Reply-To: <[e-mail]>
From: "Alice Sturgeon" <[e-mail]>
To: "Jeffrey I. Schiller" <[e-mail]>, "Santosh Chokhani" <[e-mail]>, "Warwick Ford" <[e-mail]>, "Randy V. Sabett" <[e-mail]>, "Charles \(Chas\) R. Merrill" <[e-mail]>, "Stephen S. Wu" <[e-mail]>
Cc: "IETF PKIX WG List" <[e-mail]>, "Steven M. Bellovin" <[e-mail]>
Subject: RE: IESG Comments on draft-ietf-pkix-ipki-new-rfc2527-01.txt
Date: Thu, 23 Jan 2003 16:24:07 -0500
Message-ID: <[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0)
In-Reply-To: <[e-mail]>
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

There are lots of people, including me, who are looking forward to this new
RFC being issued.  We should really try to get past the stumbling blocks.
On the first point, I would only note that RFC 2527 does not have a security
considerations section.  Is it mandatory that informational RFCs have a
security considerations section?  Having said that, both the effective RFC
and the I-D deal extensively with security, and the considerations emanating
from the provisions of this subject (in both the RFC and the I-D) seem, to
me, blindingly obvious.  Nonetheless, it would not be difficult to distill
some of the most important security concepts and put them into a discrete
section.  Another question: is it appropriate to reference other standards,
in this context to point readers in the direction of extensive and detailed
security guidance?  Security considerations would note that developing and
implementing a CP and CPS imply a total secure environment with controls
commensurate to the level of assurance and applications to be used.  I'd
reference some of the ISO standards that help in that regard, such as ISO
Technical Report 13335 Guidelines on the management of IT security, or ISO
17799 Code of practice for information security management, as examples.
On the second point, the authors of the revision did a mapping as is
recommended in the message below.  This was done for revision purposes, in
April 2001; I believe the intent was to offer a mapping for those who had
CPs/CPSs based on RFC 2527, to facilitate a conversion and comparison
between CPs/CPSs based on the 1999 RFC and those based on the revision, but
it was planned to offer this separately from the new RFC.  Note that there
was some argument that, once XML-type tagging is used for automating this
type of document, then the manual mapping would be unnecessary.  If it
thought to be desirable, then the mapping that was done (almost two years
ago now) is probably still available and valid, but I defer to the authors
on that point.  It should not be overly difficult to extract from the
mapping the substantive changes that have been made.


Alice


Alice Sturgeon
Chair
Canadian Advisory Committee - Information Technology Security
ISO/IEC JTC1 SC 27
and
System Policy Architect
SPYRUS
Phone:     [phone]
Cell:         613-291-0331




-----Original Message-----
From: [e-mail] [mailto:[e-mail]]On
Behalf Of Jeffrey I. Schiller
Sent: January 23, 2003 1:41 PM
To: Santosh Chokhani; Warwick Ford; Randy V. Sabett; Charles (Chas) R.
Merrill; Stephen S. Wu
Cc: IETF PKIX WG List; Steven M. Bellovin
Subject: IESG Comments on draft-ietf-pkix-ipki-new-rfc2527-01.txt

As you are no doubt aware, draft-ietf-pkix-ipki-new-rfc2527-01.txt has
been held up at the IESG. Although the individual who is holding it up
was not on today's call (I am pushing on him to either generate
concrete comments or to remove his objection).

However other members of the IESG raised some issues on today's call
that it would be good to address:

1. There is no Security Considerations section. We really need to have
    one.

2. It would be nice to have a "Changes since RFC2527" Section. Now I
    know that this document is just about a complete rewrite of 2527,
    so a section by section narrative would not make sense. However
    what would be helpful would be a simple description of what the
    differences are. I.e., If I am operating a PKI in compliance with
    2527, what do I have to change, if anything, to be in compliance
    with this document.

I am confident that we will get this document unstuck and published,
but the changes above would be nice. Thanks.

                         -Jeff



Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h0NK20T05046 for ietf-pkix-bks; Thu, 23 Jan 2003 12:02:00 -0800 (PST)
Received: from lakemtao04.cox.net (lakemtao04.cox.net [68.1.17.241]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h0NK1wo05037 for <[e-mail]>; Thu, 23 Jan 2003 12:01:59 -0800 (PST)
Received: from sgupta ([68.100.200.151]) by lakemtao04.cox.net (InterMail vM.5.01.04.05 201-253-122-122-105-20011231) with SMTP id <20030123200156.LVX22825.lakemtao04.cox.net@sgupta> for <[e-mail]>; Thu, 23 Jan 2003 15:01:56 -0500
From: "Sarbari Gupta" <[e-mail]>
To: <[e-mail]>
Subject: STRAWPOLL: SCVP
Date: Thu, 23 Jan 2003 15:01:09 -0500
Message-ID: <[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0)
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4807.1700
In-Reply-To: <[e-mail]>
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>


Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h0NJohr04423 for ietf-pkix-bks; Thu, 23 Jan 2003 11:50:43 -0800 (PST)
Received: from mail2.microsoft.com (mail2.microsoft.com [131.107.3.124]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h0NJogo04418 for <[e-mail]>; Thu, 23 Jan 2003 11:50:42 -0800 (PST)
Received: from INET-VRS-02.redmond.corp.microsoft.com ([157.54.8.110]) by mail2.microsoft.com with Microsoft SMTPSVC(5.0.2195.5329); Thu, 23 Jan 2003 11:50:39 -0800
Received: from 157.54.8.23 by INET-VRS-02.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Thu, 23 Jan 2003 11:50:39 -0800
Received: from RED-IMC-02.redmond.corp.microsoft.com ([157.54.9.107]) by inet-hub-01.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.5600); Thu, 23 Jan 2003 11:50:39 -0800
Received: from WIN-IMC-02.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.84]) by RED-IMC-02.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.5600); Thu, 23 Jan 2003 11:50:39 -0800
Received: from WIN-MSG-10.wingroup.windeploy.ntdev.microsoft.com ([157.54.12.81]) by WIN-IMC-02.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(6.0.3718.0); Thu, 23 Jan 2003 11:50:38 -0800
X-MimeOLE: Produced By Microsoft Exchange V6.5.6830.0
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="------------InterScan_NT_MIME_Boundary"
Subject: STRAWPOLL:SCVP
Date: Thu, 23 Jan 2003 11:50:38 -0800
Message-ID: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: STRAWPOLL:SCVP
Thread-Index: AcLDGLPYHjahgjdFRPKSDr5KGQ2ZNw==
From: "Ryan M. Hurst" <[e-mail]>
To: <[e-mail]>
X-OriginalArrivalTime: 23 Jan 2003 19:50:39.0073 (UTC) FILETIME=[B4433510:01C2C318]
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

This is a multi-part message in MIME format.

--------------InterScan_NT_MIME_Boundary
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C2C318.B3DF4DC9"

------_=_NextPart_001_01C2C318.B3DF4DC9
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable



------_=_NextPart_001_01C2C318.B3DF4DC9
Content-Type: text/html;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Dus-ascii">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
6.5.6830.0">
<TITLE>STRAWPOLL:SCVP</TITLE>
</HEAD>
<BODY>
<!-- Converted from text/rtf format -->
<BR>

</BODY>
</HTML>
------_=_NextPart_001_01C2C318.B3DF4DC9--

--------------InterScan_NT_MIME_Boundary--



Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h0NJiOX04108 for ietf-pkix-bks; Thu, 23 Jan 2003 11:44:24 -0800 (PST)
Received: from mail.coastside.net (mail.coastside.net [207.213.212.6]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h0NJiNo04102 for <[e-mail]>; Thu, 23 Jan 2003 11:44:23 -0800 (PST)
Received: from MMyersLapTop (ppp213-66.coastside.net [207.213.213.66]) by mail.coastside.net  with SMTP id h0NJiM81008750 for <[e-mail]>; Thu, 23 Jan 2003 11:44:23 -0800 (PST)
From: "Michael Myers" <[e-mail]>
To: "pkix" <[e-mail]>
Subject: STRAWPOLL:OCSP
Date: Thu, 23 Jan 2003 12:39:35 -0800
Message-ID: <[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0)
Importance: Normal
In-Reply-To: <[e-mail]>
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

 


Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h0NJQfj03217 for ietf-pkix-bks; Thu, 23 Jan 2003 11:26:41 -0800 (PST)
Received: from nic.lp.se (nic.lp.se [212.247.5.91]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h0NJQdo03213 for <[e-mail]>; Thu, 23 Jan 2003 11:26:39 -0800 (PST)
Received: from localhost (130.237.234.215) by nic.lp.se (MX V5.3 VnHj) with ESMTP for <[e-mail]>; Thu, 23 Jan 2003 20:24:40 +0100
Date: Thu, 23 Jan 2003 20:21:50 +0100 (CET)
Message-ID: <[e-mail]>
To: [e-mail]
Subject: STRAWPOLL:DVCS
From: Richard Levitte - VMS Whacker <[e-mail]>
X-URL: http://www.lp.se/
X-Waved: dead chicken, GNU emacs 21.2.2, Mew version 3.1
X-Mew: See http://www.mew.org/
X-Mailer: Mew version 3.1 on Emacs 21.2 / Mule 5.0 (SAKAKI)
MIME-Version: 1.0
Content-Type: Text/Plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

-- 
Richard Levitte     | http://richard.levitte.org/ | Spannv. 38, I
Levitte Programming | http://www.lp.se/           | S-168 35 Bromma
T: [phone] |                             | SWEDEN
     "Price, performance, quality...  choose the two you like"


Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h0NIwU801894 for ietf-pkix-bks; Thu, 23 Jan 2003 10:58:30 -0800 (PST)
Received: from mail-blue.research.att.com (mail-blue.research.att.com [135.207.30.102]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h0NIwSo01879 for <[e-mail]>; Thu, 23 Jan 2003 10:58:28 -0800 (PST)
Received: from postal.research.att.com (postal.research.att.com [135.207.23.30]) by mail-blue.research.att.com (Postfix) with ESMTP id 2B7134CE07; Thu, 23 Jan 2003 13:58:25 -0500 (EST)
Received: from berkshire.research.att.com (postal.research.att.com [135.207.23.30]) by postal.research.att.com (8.8.7/8.8.7) with ESMTP id NAA06442; Thu, 23 Jan 2003 13:58:20 -0500 (EST)
Received: from research.att.com (localhost [127.0.0.1]) by berkshire.research.att.com (Postfix) with ESMTP id 311247B4D; Thu, 23 Jan 2003 13:58:20 -0500 (EST)
X-Mailer: exmh version 2.5 07/13/2001 with nmh-1.0.4
From: "Steven M. Bellovin" <[e-mail]>
To: "Jeffrey I. Schiller" <[e-mail]>
Cc: Denis Pinkas <[e-mail]>, Nick Pope <[e-mail]>, John Ross <[e-mail]>, IETF PKIX WG List <[e-mail]>
Subject: Re: Issues with draft-ietf-pkix-pr-tsa-02.txt 
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Date: Thu, 23 Jan 2003 13:58:20 -0500
Message-Id: <[e-mail]>
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

In message <[e-mail]>, "Jeffrey I. Schiller" writes:
>
>This is an OpenPGP/MIME signed message (RFC 2440 and 3156)
>--------------enigB9467F14EC880BFF33D80C3D
>Content-Type: text/plain; charset=us-ascii; format=flowed
>Content-Transfer-Encoding: 7bit
>
>The IESG discussed this document on today's telechat. Two issues were
>raised.
>
>1. There needs to be a Security Considerations section!
>
>2. Is this document identical to its ETSI equivalent? Do we have
>    permission from ETSI to publish this as an IETF document? Do we
>    need permission?
>

On that last point, the I-D boilerplate says that we don't have such 
permission; that has to be changed.


		--Steve Bellovin, http://www.research.att.com/~smb (me)
		http://www.wilyhacker.com (2nd edition of "Firewalls" book)




Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h0NIt9n01728 for ietf-pkix-bks; Thu, 23 Jan 2003 10:55:09 -0800 (PST)
Received: from jis.mit.edu (JIS.MIT.EDU [18.7.21.84]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h0NIt8o01722 for <[e-mail]>; Thu, 23 Jan 2003 10:55:08 -0800 (PST)
Received: from mit.edu (localhost [127.0.0.1]) by jis.mit.edu (8.9.2/8.9.3) with ESMTP id NAA20053; Thu, 23 Jan 2003 13:54:56 -0500 (EST)
Message-ID: <[e-mail]>
Date: Thu, 23 Jan 2003 13:54:55 -0500
From: "Jeffrey I. Schiller" <[e-mail]>
Organization: Massachusetts Institute of Technology
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.0) Gecko/20020607
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Denis Pinkas <[e-mail]>, Nick Pope <[e-mail]>, John Ross <[e-mail]>
CC: IETF PKIX WG List <[e-mail]>, "Steven M. Bellovin" <[e-mail]>
Subject: Issues with draft-ietf-pkix-pr-tsa-02.txt
X-Enigmail-Version: 0.63.3.0
X-Enigmail-Supports: pgp-inline, pgp-mime
Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enigB9467F14EC880BFF33D80C3D"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

This is an OpenPGP/MIME signed message (RFC 2440 and 3156)
--------------enigB9467F14EC880BFF33D80C3D
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit

The IESG discussed this document on today's telechat. Two issues were
raised.

1. There needs to be a Security Considerations section!

2. Is this document identical to its ETSI equivalent? Do we have
    permission from ETSI to publish this as an IETF document? Do we
    need permission?

                 -Jeff

--------------enigB9467F14EC880BFF33D80C3D
Content-Type: application/pgp-signature

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.7 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQE+MDp/8CBzV/QUlSsRAszrAKCe8dDW5LzzCx1xsYSw2Aj5+K0uqgCfd39F
MCUeCCzprrALeDUeHeWevbo=
=itPP
-----END PGP SIGNATURE-----

--------------enigB9467F14EC880BFF33D80C3D--



Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h0NIfrV01053 for ietf-pkix-bks; Thu, 23 Jan 2003 10:41:53 -0800 (PST)
Received: from jis.mit.edu (JIS.MIT.EDU [18.7.21.84]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h0NIfpo01047 for <[e-mail]>; Thu, 23 Jan 2003 10:41:51 -0800 (PST)
Received: from mit.edu (localhost [127.0.0.1]) by jis.mit.edu (8.9.2/8.9.3) with ESMTP id NAA19771; Thu, 23 Jan 2003 13:41:29 -0500 (EST)
Message-ID: <[e-mail]>
Date: Thu, 23 Jan 2003 13:41:28 -0500
From: "Jeffrey I. Schiller" <[e-mail]>
Organization: Massachusetts Institute of Technology
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.0) Gecko/20020607
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Santosh Chokhani <[e-mail]>, Warwick Ford <[e-mail]>, "Randy V. Sabett" <[e-mail]>, "Charles (Chas) R. Merrill" <[e-mail]>, "Stephen S. Wu" <[e-mail]>
CC: IETF PKIX WG List <[e-mail]>, "Steven M. Bellovin" <[e-mail]>
Subject: IESG Comments on draft-ietf-pkix-ipki-new-rfc2527-01.txt
X-Enigmail-Version: 0.63.3.0
X-Enigmail-Supports: pgp-inline, pgp-mime
Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enigD50197855BA608F713ABCD0D"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

This is an OpenPGP/MIME signed message (RFC 2440 and 3156)
--------------enigD50197855BA608F713ABCD0D
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit

As you are no doubt aware, draft-ietf-pkix-ipki-new-rfc2527-01.txt has
been held up at the IESG. Although the individual who is holding it up
was not on today's call (I am pushing on him to either generate
concrete comments or to remove his objection).

However other members of the IESG raised some issues on today's call
that it would be good to address:

1. There is no Security Considerations section. We really need to have
    one.

2. It would be nice to have a "Changes since RFC2527" Section. Now I
    know that this document is just about a complete rewrite of 2527,
    so a section by section narrative would not make sense. However
    what would be helpful would be a simple description of what the
    differences are. I.e., If I am operating a PKI in compliance with
    2527, what do I have to change, if anything, to be in compliance
    with this document.

I am confident that we will get this document unstuck and published,
but the changes above would be nice. Thanks.

                         -Jeff

--------------enigD50197855BA608F713ABCD0D
Content-Type: application/pgp-signature

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.7 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQE+MDdY8CBzV/QUlSsRAljvAKCLdkvUU47DxvFGNDpnNvRLaaZdmwCfbXhy
9QcqwuEls5hOdKBLIn8eQig=
=WN6q
-----END PGP SIGNATURE-----

--------------enigD50197855BA608F713ABCD0D--



Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h0NEGIL09519 for ietf-pkix-bks; Thu, 23 Jan 2003 06:16:18 -0800 (PST)
Received: from ocasey.baltimore.com (ocasey.baltimore.com [193.41.17.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h0NEGFo09514 for <[e-mail]>; Thu, 23 Jan 2003 06:16:15 -0800 (PST)
Received: from Baltimore-FW2 ([172.19.1.2]) by ocasey.baltimore.com (8.11.6/8.9.3) with SMTP id h0NE69A23867 for <[e-mail]>; Thu, 23 Jan 2003 14:06:09 GMT
Received: from  ([10.153.25.53]) by Baltimore-FW2; Thu, 23 Jan 2003 14:14:29 +0000 (GMT)
Received: from Baltimore-FW2 (wilde-i-2.ie.baltimore.com) by emeairlsw1.baltimore.com (Content Technologies SMTPRS 4.2.5) with SMTP id <[e-mail]> for <[e-mail]>; Thu, 23 Jan 2003 14:07:34 +0000
Received: from  ([10.153.25.10]) by Baltimore-FW2; Thu, 23 Jan 2003 14:14:27 +0000 (GMT)
Received: from baltimore.ie (wks159-25.ie.baltimore.com [10.153.25.159]) by bobcat.baltimore.ie (8.9.3/8.9.3) with ESMTP id OAA02168 for <[e-mail]>; Thu, 23 Jan 2003 14:16:07 GMT
Message-ID: <[e-mail]>
Date: Thu, 23 Jan 2003 14:16:08 +0000
From: Stephen Farrell <[e-mail]>
Reply-To: [e-mail]
Organization: Baltimore Technologies Ltd.
X-Mailer: Mozilla 4.7 [en] (WinNT; I)
X-Accept-Language: en
MIME-Version: 1.0
To: pkix <[e-mail]>
Subject: STRAWPOLL:OCSP
References: <[e-mail]>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

 


-----------------------------------------------------------------------------
The information contained in this message is confidential and is intended
for the addressee(s) only.  If you have received this message in error or
there are any problems please notify the originator immediately.  The 
unauthorised use, disclosure, copying or alteration of this message is 
strictly forbidden. Baltimore Technologies plc will not be liable for
direct, special, indirect or consequential damages arising from alteration
of the contents of this message by a third party or as a result of any 
virus being passed on.

This footnote confirms that this email message has been swept for Content
Security threats, including computer viruses.
http://www.baltimore.com



Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h0NE6t808934 for ietf-pkix-bks; Thu, 23 Jan 2003 06:06:55 -0800 (PST)
Received: from smtp6.mindspring.com (smtp6.mindspring.com [207.69.200.110]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h0NE6so08928 for <[e-mail]>; Thu, 23 Jan 2003 06:06:54 -0800 (PST)
Received: from user-0c8h20e.cable.mindspring.com ([24.136.136.14] helo=asn-1.com) by smtp6.mindspring.com with esmtp (Exim 3.33 #1) id 18bi0N-0002Vp-00 for [e-mail]; Thu, 23 Jan 2003 09:06:55 -0500
Message-ID: <[e-mail]>
Date: Thu, 23 Jan 2003 09:05:57 -0500
From: "Phillip H. Griffin" <[e-mail]>
Organization: http://asn-1.com
User-Agent: Mozilla/5.0 (Windows; U; Win 9x 4.90; en-US; rv:1.0.1) Gecko/20020823 Netscape/7.0
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: "[IETF PKIX]" <[e-mail]>
Subject: STRAWPOLL:OCSP
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>


Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h0NE6NL08909 for ietf-pkix-bks; Thu, 23 Jan 2003 06:06:23 -0800 (PST)
Received: from woodstock.binhost.com (woodstock.binhost.com [207.228.252.5]) by above.proper.com (8.11.6/8.11.3) with SMTP id h0NE6Mo08905 for <[e-mail]>; Thu, 23 Jan 2003 06:06:22 -0800 (PST)
Received: (qmail 6607 invoked from network); 23 Jan 2003 14:05:55 -0000
Received: from unknown (HELO Russ-Laptop.vigilsec.com) (141.156.36.143) by woodstock.binhost.com with SMTP; 23 Jan 2003 14:05:55 -0000
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9
Date: Thu, 23 Jan 2003 09:06:17 -0500
To: "Julien Stern" <[e-mail]>, [e-mail]
From: Russ Housley <[e-mail]>
Subject: Re: What to do with incorrectly encoded X509 extensions ?
In-Reply-To: <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Julien:

These example certificates are old.  They match RFC 2459, which has a known 
problem in it.  We belive that the examples in RFC 3280 correct this 
problem.  We are working to get the binary versions of the RFC 3280 
certificates and CRLs to Paul for posting on his web page.

Russ

At 12:25 PM 1/22/2003 +0100, Julien Stern wrote:

>Hi all,
>
>it seems that the sample certificate pkix-ex3.ber which can be
>downloaded from http://www.imc.org/ietf-pkix/index.html has extensions
>which are not correct ASN.1 wise (some non-optional fields are missing).
>
>More specifically the Certificate Policies Extension seems to contains an
>incorrect DER encoding within the octet string (missing 'qualifier'
>field in a PolicyQualifierInfo).
>
>If an extension is critical, and does not decode correctly,
>I assume the only option is to reject the whole certificate.
>
>In the present case, the extension is marked non-critical, so one option is
>to ignore it, just when an OID is not understood. However, the situation
>here is slightly different: the extension is understood, but invalid
>with respect to the standard. So should I simply ignore this extension
>or dismiss the whole certificate ?
>
>Sincerely,
>
>--
>Julien Stern
>Cryptolog International



Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h0NDv7O08483 for ietf-pkix-bks; Thu, 23 Jan 2003 05:57:07 -0800 (PST)
Received: from smtp.comcast.net (smtp.comcast.net [24.153.64.2]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h0NDv6o08478 for <[e-mail]>; Thu, 23 Jan 2003 05:57:06 -0800 (PST)
Received: from icomcast.net (lb-ldap-155.icomcast.net [172.20.3.155]) by mtaout07.icomcast.net (iPlanet Messaging Server 5.2 HotFix 1.09 (built Jan  7 2003)) with ESMTP id <[e-mail]> for [e-mail]; Thu, 23 Jan 2003 08:55:53 -0500 (EST)
Received: from [172.20.3.76] by msgstore01.icomcast.net (mshttpd); Thu, 23 Jan 2003 08:55:49 -0500
Date: Thu, 23 Jan 2003 08:55:49 -0500
From: ALFRED ARSENAULT <[e-mail]>
Subject: STRAWPOLL: SCVP
To: [e-mail]
Message-id: <[e-mail]>
MIME-version: 1.0
X-Mailer: iPlanet Messenger Express 5.2 HotFix 1.09 (built Jan  7 2003)
Content-type: text/plain; charset=us-ascii
Content-language: en
Content-transfer-encoding: 7BIT
Content-disposition: inline
X-Accept-Language: en
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>


Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h0NCDA028902 for ietf-pkix-bks; Thu, 23 Jan 2003 04:13:10 -0800 (PST)
Received: from smtp6.mindspring.com (smtp6.mindspring.com [207.69.200.110]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h0NCD8o28897 for <[e-mail]>; Thu, 23 Jan 2003 04:13:08 -0800 (PST)
Received: from user-0c8h20e.cable.mindspring.com ([24.136.136.14] helo=asn-1.com) by smtp6.mindspring.com with esmtp (Exim 3.33 #1) id 18bgEH-0002DS-00 for [e-mail]; Thu, 23 Jan 2003 07:13:09 -0500
Message-ID: <[e-mail]>
Date: Thu, 23 Jan 2003 07:12:11 -0500
From: "Phillip H. Griffin" <[e-mail]>
Organization: http://asn-1.com
User-Agent: Mozilla/5.0 (Windows; U; Win 9x 4.90; en-US; rv:1.0.1) Gecko/20020823 Netscape/7.0
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: [e-mail]
Subject: STRAWPOLL:DVP/DPD
References: <[e-mail]> <[e-mail]>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>


Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h0NC2qH28238 for ietf-pkix-bks; Thu, 23 Jan 2003 04:02:52 -0800 (PST)
Received: from firewall.andxor.com (firewall.andxor.it [195.223.2.2]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h0NC2no28232 for <[e-mail]>; Thu, 23 Jan 2003 04:02:50 -0800 (PST)
Received: from com-and.com (giovanni.andxor.it [195.223.2.228]) by firewall.andxor.com (8.12.3/8.12.3) with ESMTP id h0NC2k5E048076 for <[e-mail]>; Thu, 23 Jan 2003 13:02:49 +0100 (CET) (envelope-from [e-mail])
Message-ID: <[e-mail]>
Date: Thu, 23 Jan 2003 13:02:46 +0100
From: Giovanni Frustaci <[e-mail]>
Organization: C&A
X-Mailer: Mozilla 4.7 [en] (Win95; U)
X-Accept-Language: en
MIME-Version: 1.0
CC: [e-mail]
Subject: STRAWPOLL:DVCS
References: <[e-mail]> <[e-mail]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>


Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h0NApAt22807 for ietf-pkix-bks; Thu, 23 Jan 2003 02:51:10 -0800 (PST)
Received: from firewall.andxor.com (firewall.andxor.it [195.223.2.2]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h0NAp7o22794 for <[e-mail]>; Thu, 23 Jan 2003 02:51:08 -0800 (PST)
Received: from foobar.andxor.it (foobar.andxor.it [195.223.2.236]) by firewall.andxor.com (8.12.3/8.12.3) with ESMTP id h0NAp75C047279 for <[e-mail]>; Thu, 23 Jan 2003 11:51:07 +0100 (CET) (envelope-from [e-mail])
Received: (from adg@localhost) by foobar.andxor.it (8.11.6/8.11.6) id h0NAwBn14201 for [e-mail]; Thu, 23 Jan 2003 11:58:11 +0100
Date: Thu, 23 Jan 2003 11:58:10 +0100
From: Alfonso De Gregorio <[e-mail]>
To: [e-mail]
Subject: STRAWPOLL:DVCS
Message-ID: <[e-mail]>
Reply-To: [e-mail]
References: <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5.1i
In-Reply-To: <[e-mail]>; from [e-mail] on Wed, Jan 22, 2003 at 01:54:34PM -0800
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>


Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h0NAoUZ22692 for ietf-pkix-bks; Thu, 23 Jan 2003 02:50:30 -0800 (PST)
Received: from odin2.bull.net (odin2.bull.net [192.90.70.84]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h0NAoJo22662 for <[e-mail]>; Thu, 23 Jan 2003 02:50:20 -0800 (PST)
Received: from clbull.frcl.bull.fr (clbull.frcl.bull.fr [129.182.8.31]) by odin2.bull.net (8.9.3/8.9.3) with ESMTP id LAA25084; Thu, 23 Jan 2003 11:52:00 +0100
Received: from bull.net (frcls4013.frcl.bull.fr [129.182.108.120]) by clbull.frcl.bull.fr (8.9.2/8.9.1) with ESMTP id LAA12442; Thu, 23 Jan 2003 11:50:25 +0100
Message-ID: <[e-mail]>
Date: Thu, 23 Jan 2003 11:50:12 +0100
From: Denis Pinkas <[e-mail]>
Organization: Bull SA.
User-Agent: Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.0.1) Gecko/20020823 Netscape/7.0
X-Accept-Language: en-us, en, fr
MIME-Version: 1.0
To: Richard Levitte - VMS Whacker <[e-mail]>
CC: [e-mail]
Subject: Re: Strawpoll for DPD/DPV protocols
References: <[e-mail]> <[e-mail]>
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id h0NAoTo22688
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Richard,

> In message <[e-mail]> on 
 > Tue, 21 Jan 2003 17:17:03 -0500, [e-mail] said:
> 
> DPV and DPD over OCSP, available at 
> http://www.ietf.org/internet-drafts/draft-ietf-pkix-ocsp-dpvdpd-00.txt> and
> I've a hard time finding a compliance matrix for this one.  Was one
> ever submitted?  In any case, if there is one, I'd really appreciate
> it if someone could send me a copy.

It was sent on January 15 by Mike Myers. It is copied below.

======================================================================

Topic 1: Basic Protocol

1. If the DPV server does not support the client requested  validation 
policy, then the DPV server MUST return an error. (4.1. Basic Protocol)

Errors are returned via RFC2560 encapsulation. An error state for
unsuportedPolicy can be folded into the ongoing work for OCSPv2.

2. If the DPV request does not specify a validation policy, the  server 
response MUST indicate the validation policy that was used.  (4.1. Basic 
Protocol)

"If a DPV request does not indicate a validation policy, DPV responders
SHALL include the DPV extended response OID and syntax in their
responses and SHALL identify in the policy field of that syntax the OID
identifying the policy in effect when the response was produced."

3. The protocol MUST allow the client to include these policy dependent 
parameters in the DPV request; however, it is expected that most clients 
will simply reference a validation policy for a given application or accept 
the DPV server's default validation policy. (4.1. Basic Protocol)

[For the candidate protocol, state the provisions it includes for such 
parameters.]

As it relates to DPV requests, the ExtendedOCSPRequest enables
specification of initialPolicySet, trustPoints and a token field related to 
the nature or reason for the query.

4. The DPV server MUST obtain revocation status information for the 
validation time in the client request. (4.1. Basic Protocol)

[a. Indicate how a conformant server for the candidate protocol deals  with 
other than "current time" validation requests.]

  [b. For the candidate protocol, indicate which revocation status methods a 
conformant server is required to support. A DPV server must support some 
revocation status methods, but the methods used by different CAs may differ, 
suggesting that a server needs to be prepared to deal with several such 
methods. A server may need to be configured to use specific methods for 
specific CAs. How does the candidate protocol accommodate this need?]

Need to address this.

5. If the revocation status information for the requested validation time is 
unavailable, then the DPV server MUST return a status indicating that the 
certificate is invalid.
Additional information about the reason for invalidity MAY also be provided. 
(4.1 Basic Protocol)

The invalid state is addressed.  Reasons are enabled.

6. The certificate to be validated MUST either be directly provided in the 
request or unambiguously referenced, such as the CA distinguished name, 
certificate serial number, and the hash of the certificate, like ESSCertID 
as defined in [ESS] or OtherSigningCertificate as defined in [ES-F]. (4.1 
Basic Protocol)

  [For the candidate protocol, specify which formats for certificate 
references MUST be supported by conformant clients and servers. The lists 
may differ for clients vs. servers, e.g., servers may bear the burden of 
having to accept a larger range of reference types, to ease the burden on 
clients.]

CertID syntax in [RFC2560] enables such a means.  Collateral WG efforts
on expanding this syntax will enable other mechanisms.

7. The DPV client MUST be able to provide to the validation server, 
associated with each certificate to be validated, useful certificates, as 
well as useful revocation information. (4.1 Basic Protocol)

[For the candidate protocol, indicate which forms of revocationstatus info a 
conformant client is allowed to provide, and whatforms of revocation status 
data a conformant server MUST beprepared to accept from a client.]

pathParams and revInfo are available in  DPVOptions.

3379 does not assert a requirement for normative specification of minimal
server-side requirements governing revocation data forms or formats.
Further WG consensus on this is point is anticipated.

8. The DPV server MUST have the certificate to be validated.  When the 
certificate is not provided in the request, the server MUST obtain the 
certificate and then verify that the certificate is indeed the one being 
unambiguous referenced by the client. (4.1 Basic Protocol)

[For the candidate protocol, specify what mechanisms a conformantserver MUST
implement in support of this requirement, e.g., retrieval of a certificate 
via LDAP queries.]

The cited text isinterpreted as an obvious fact.

3379 asserts no requirement for a normative specification of minimal
server-side certificate retrival mechanisms  Further WG consensus on this
is point is anticipated.
.

9. The DPV server MUST include either the certificate or an unambiguous 
reference to the certificate (in case of a CA key compromise) in the DPV 
response. (4.1 Basic Protocol)

Certificate reference is enabled via BasicOCSPResponse syntax of RFC2560.

10. The DPV response MUST indicate one of the following status alternatives:

    1.	the certificate is valid according to the validation policy.

    2.	the certificate is not valid according to the validation policy.

    3.	the validity of the certificate is unknown according to the 
validation policy.

    4.	the validity could not be determined due to an error.

  (source for 10: 4.1 Basic Protocol)

The valid, invalid and unknown states are addressed.  RFC2560 governs
production of errors.

11. When the certificate is not valid according to the validation policy, 
then the reason
MUST also be indicated.  Invalidity reasons include:

    1.	the DPV server cannot determine the validity of the certificate 
because a certification path cannot be constructed.

    2.	the DPV server successfully constructed a certification path,    but 
it was not valid according to the validation algorithm in  [PKIX-1].

    3.	the certificate is not valid at this time.  If another request could 
be made later on, the certificate could possibly be determined as valid. 
This condition may occur before a certificate validity period has begun or 
while a certificate is suspended.  (Source for 11: 4.1 Basic Protocol)

[For the candidate protocol, indicate what if any, other invalidity reasons 
are reportable by a conformant server.]

The OCTET STRING Reasons associated with the invalid state enables
responders to indicate reasons to requestors.  On the basis of prior
experience, it is anticipated that: 1) the full spectrum of such reasons may
be broad, owing to mission-specific needs; and yet 2) there might be a
core set worthy of standardization but that dialog has yet to occur.

12. The protocol MUST prevent replay attacks, and the replay prevention 
mechanism employed by the protocol MUST NOT rely on synchronized clocks. 
(4.1 Basic Protocol)

[For the candidate protocol, describe the means by which conformant clients 
and servers detect and reject replay attacks.]

RFC2560 governs the use of replay detection via the use of nonces.

13. The DPV request MUST allow the client to request that the server include 
in its response additional information which will allow relying parties not 
trusting the DPV server to be confident that the certificate validation has 
correctly been performed.

[…]When the certificate is valid according to the validation policy, the 
server MUST, upon request, include that information in the response. 
However, the server MAY omit that information when the certificate is 
invalid or when it cannot determine the validity. (4.1 Basic Protocol)

[For the candidate protocol, specify the additional information that a 
conformant server MUST be able to provide and indicate how the set of 
information to be returned is determined, e.g., if it may vary depending on 
the client or other parameters.]

Requestors can ask responders to return one or more of: certification
path; revocation information; a time stamp; or policy identifier

The DPV/DPD requirements RFC does not assert a requirement for
normative specification of minimal server-side suypport for additional
information  It was assumed this is a deployment-specific issue.

Return of validation policy OID is enabled.

14. The DPV server MUST be able, upon request, copy a text field  provided 
by the client into the DPV response. (4.1 Basic Protocol)

The token field in Parameters syntax is defined for this purpose.

15. The DPV response MUST be bound to the DPV request so that the client can 
be sure that all the parameters from the request have been taken into 
consideration by the DPV server to build the response.  This can be 
accomplished by including a one-way hash of the request in the  response.

[For the candidate protocol, describe how this binding is effected.]

"If a value for requestExtensions is present in the DPV request  (thus
indicating the presence of requestor-specified parameters),  responders
shall perform a hash across this value using the SHA-1 algorithm AND
include this resulting value in the paramHash field."

In some environments it may be necessary to present only a DPV response to 
another relying party without the corresponding request. In this case the 
response MUST be self contained.  This  can be accomplished by repeating 
only the important components  from the request in the response. (4.1 Basic 
Protocol)

"If the returnReq bit is set, responders SHALL return in reqContents field
the contents of the received DPVOptions . . ."

16. For the client to be confident that the certificate validation was 
handled by the expected DPV server, the DPV response MUST be authenticated, 
unless an error is reported (such as a badly formatted request or unknown 
validation policy).

[For the candidate protocol, specify the response message authentication 
mechanisms that a conformant server MUST support, and those that a 
conformant client MUST support.
Note that clients might be required to support fewer mechanisms, or might be 
required to support only one mechanism from a set, while a server might be 
required to support all of the mechanisms in the set, e.g., as a means of 
ensuring interoperation.]

For the client to be able prove to a third party that trusts the same DPV 
server that the certificate validation was handled correctly, the DPV 
response MUST be digitally signed, unless an error is reported. The DPV 
server's certificate MUST authenticate the DPV server. (4.1 Basic Protocol)

"In instances where it is important to authenticate the identity of a
responder prior to acceptance of its response, lower layer security
protocols could be used to establish the identity of the intended responder.
Note that authoritative DPV responses are required to be digitally signed.
Thus, to the extent the identity contained in the certificate used to 
validate a response is an acceptable form of response authentication, this 
method may suffice."

17. The DPV server MAY require client authentication, therefore, the DPV 
request MUST be able to be authenticated. (4.1 Basic Protocol)

[For the candidate protocol, describe the request message authentication 
mechanisms that a conformant server MUST support, and those that a 
conformant client MUST support, to ensure a minimal level of 
interoperability. Note that clients might be required to support
fewer mechanisms, or might be required to support only one mechanism from a 
set, while a server might be required to support all of the mechanisms in 
the set, e.g., as a means of ensuring interoperation.]

See above.

18. When the DPV request is authenticated, the client SHOULD be able to 
include a client identifier in the request for the DPV server to copy into 
the response.  Mechanisms for matching this identifier with the 
authenticated identity depends on local DPV server conditions and/or the 
validation policy.  The DPV server MAY choose to blindly copy
the identifier, omit the identifier, or return an error response. (4.1 Basic 
Protocol)

[For the candidate protocol, describe provisions for confidentiality, if any.]

"If requestorName is included TBSRequest element, responders SHALL
include this value in the reqID field of  ExtendedOCSPResponse.  Where
client authentication is important to the responder's policy (e.g.
authorization to access the service), lower-layer protocol  MAY be used to
establish this authentication.  If used, responders SHOULD copy the
client-auth identity into the reqID field."

Topic 2: Relay and Redirection

19. Protocols designed to satisfy these requirements MAY include optional 
fields and/or extensions to support relaying, re-direction or multicasting. 
  […]  If the protocol supports such features, the protocol MUST include 
provisions for DPV clients and DPV servers that do not support such 
features, allowing them to conform to the basic set of
requirements. (4.2. Relaying, Re-direction and Multicasting)

[For the candidate protocol, describe any relay, referral, or multicasting 
facilities required of conformant server.]

No specific mechanisms are defined.  Current OCSP deployment practice
has shown that relaying and referral needs can be addressed.

20. When a server supports a relay mechanism, a mechanism to detect loops or 
repetition MUST be provided. (4.2. Relaying, Re-direction and Multicasting)

See above re: 19.

21. When a protocol provides the capability for a DPV server to redirect a 
request to another DPV server (that is, the protocol chooses to provide a 
referral mechanism), a mechanism to provide information to be used for the 
re-direction SHOULD be supported. If such re-direction information is sent 
back to clients, then the protocol MUST allow conforming clients to ignore 
it. (4.2. Relaying, Re-direction and Multicasting)

[For the candidate protocol, describe what strategy is employed to deal with 
redirection by a conformant server and what redirectionfeatures are mandated 
for a conformant client.]

See above re: 19.

22. Optional parameters in the protocol request and/or response MAY be 
provide support for relaying, re-direction or multicasting.  DPV clients 
that ignore any such optional parameters MUST be able to use the DPV 
service.  DPV servers that ignore any such optional parameters MUST still be 
able to offer the DPV service, although they might not
be able to overcome the limitations imposed by the network topology.  In 
this way, protocol implementers do not need to understand the syntax or 
semantics of any such optional parameters. (4.2. Relaying, Re-direction and 
Multicasting)

See above re: 19.

Topic 3: DPD Requirements

23. Clients MUST be able to specify whether they want, in addition to the 
certification path, the revocation information associated with the path, for 
the end-entity certificate, for the CA certificates, or for both. (5. 
Delegated Path Discovery Protocol)

[For the candidate protocol, specify what revocation status data types MUST be
supported by a conformant server.]

Requestors are able specify via the Flags field of ExtendedOCSPRequest
whether they wish to receive EE and/or CA revocation Information.  The
ExtendedOCSPResponse syntax and its DPD usage specification further
enables clients to request CRLs and/or OCSP.

24. If the DPD server does not support the client requested path discovery 
policy, the DPD server MUST return an error. (5. Delegated Path Discovery 
Protocol)

Errors are reported via the RFC2560 envelope.

25. The DPD request MUST allow more elaborated path discovery policies to be
referenced. (5. Delegated Path Discovery Protocol)

[For the candidate protocol, specify the parameters for path discovery that 
a conformant server MUST support, i.e., the minimum path discovery policy 
supported, and specify what optional path discovery parameters a server 
SHOULD/MAY support.]

The ExtendedOCSPRequest syntax and its DPD usage specification enables this.

26. If the trust anchor is a self-signed certificate, that self-signed 
certificate MUST NOT be included.  In addition, if requested, the revocation 
information associated with each  certificate in the path MUST also be 
returned. (5. Delegated Path Discovery Protocol)

[For the candidate protocol, specify the types of revocation status data 
that a conformant server MUST support.]

"[If] the trust anchor is a self-signed certificate . . . that certificate 
SHALL NOT be included in the path."

27. By default, the DPD server MUST return a single certification path for 
each end-entity certificate in the DPD request. (5. Delegated Path Discovery 
Protocol)

"Responders aware of multiple candidate paths that satisfy requestor-
specified parameters (if any) SHALL include in their responses the lesser
of the number of qualified paths or the number of paths specified by the
requestor in numPaths.  If the requestor did not specify numPaths then, by
default, the responder MUST return a single certification path for each
end-entity certificate in the DPD request."

28. Therefore, the DPD client MUST have a means of obtaining more than one
certification path for each end-entity certificate in the DPD request.  At 
the same time, the mechanism for obtaining additional certification paths 
MUST NOT impose protocol state on the DPD server. (5. Delegated Path 
Discovery Protocol)

[For the candidate protocol, provide a state machine description of DPD 
operation, to demonstrate that this requirement is met.]

See above re: 27.

29. Path discovery MUST be performed according to the path discovery policy. 
  The DPD response MUST indicate one of the following status alternatives:

    1.	one or more certification paths was found according to the  path 
discovery policy, with all of the requested revocation information present.

    2.	one or more certification paths was found according to the  path 
discovery policy, with a subset of the requested revocation information present.

    3.	one or more certification paths was found according to the path 
discovery policy, with none of the requested revocation  information present.

    4.	no certification path was found according to the path  discovery policy.

    5.	path construction could not be performed due to an error.

(Source for 29: 5. Delegated Path Discovery Protocol)

"Responders SHALL develop a path or paths correspondent to a
requestor-specified path discovery policy when such is indicated in the
request."

"Requestors can derive these states from a DPD response as follows.
Errors are reported as OCSPResponseStatus (see [RFC2560]) in which
case no path data is present in the response.  A value of successful in
OCSPResponseStatus indicates the presence of pathInfo in
ExtendedOCSPResponse.  This value may be NULL, indicating that no
paths were discovered.  Requestors that did not request revInfo will not
receive revInfo. Else each certificate in each path returned via the
pathInfo structure may or may not have revInfo associated with it.
Absence of revInfo for a given certificate in the pathInfo structure enables
requestor determination of the first three states noted above."

30.   For the client to be confident that all of the elements from the 
response originate from the expected DPD server, an authenticated response 
MAY be required.  For example, the server might sign  the response or data 
authentication might also be achieved using a lower-layer security protocol. 
(5. Delegated Path Discovery  Protocol)

[For the candidate protocol, specify whether conformant servers MUST be 
capable of generating authenticated responses, what authentication 
mechanisms they MUST support, and what authentication mechanisms conformant 
clients MUST support. Note that clients might be required to support fewer 
mechanisms, or might be required to support only one mechanism from a set, 
while a server might be required to support all of the mechanisms in the 
set, e.g., as a means of ensuring interoperation.]

RFC2560 enables responder signatures.

31. The DPD server MAY require client authentication, allowing the DPD 
request MUST to be authenticated. (5. Delegated Path Discovery Protocol)

[For the candidate protocol, specify whether conformant servers MUST be 
capable of authenticating requests, what authentication mechanisms they MUST 
support, and what authentication mechanisms conformant clients MUST support. 
Note that clients might be required to support fewer mechanisms, or might be 
required to support only one mechanism from a set, while a server might be 
required to support all of the mechanisms in the set, e.g., as a means of 
ensuring interoperation..]

"Where client authentication is important to the responder's policy (e.g.
authorization to access the service), a lower-layer protocol may be used to
establish this authentication.  If used, responders SHOULD copy the
client-auth identity into the reqID field of ExtendedOCSPResponse."

32. Using a separate request/response pair, the DPV or DPD client MUST be 
able to obtain references for the default policy or for all  of the policies 
supported by the server. (6. DPV and DPD Policy Query)

Policy Discovery Protocol (PDP) is not addressed.

33. In order to succeed, one valid certification path (none of the 
certificates in the path are expired or revoked) MUST be found between an 
end-entity certificate and a trust anchor and all constraints that apply to 
the certification path MUST be verified. (7. Validation Policy)

34. The validation policy MUST specify the source of revocation information:

    1.	full CRLs (or full Authority Revocation Lists) have to be collected.

    2.	OCSP responses, using [OCSP], have to be collected.

    3.	delta CRLs and the relevant associated full CRLs (or full  Authority 
Revocation Lists) are to be collected.

    4.	any available revocation information has to be collected.

    5.	no revocation information need be collected.

(Source for 34: 7.3. Revocation Requirements)

Policy Discovery Protocol (PDP) is not addressed.

35. The validation policy MUST specify the source of revocation information:

    - full CRLs (or full Authority Revocation Lists) have to be collected.

    - OCSP responses, using [OCSP], have to be collected.

    - delta CRLs and the relevant associated full CRLs (or full Authority 
Revocation Lists) are to be collected.

    - any available revocation information has to be collected.

    - no revocation information need be collected.

(source for 35: 7. Validation Policy)

[For the candidate protocol, describe the path validation and path discovery 
policy parameters that a conformant server MUST or  SHOULD support, e.g., 
trust anchor names, keys, name  constraints and policy constraints for trust 
anchors, path depth limits, key usage constraints, extended key usage 
constraints,  required/allowed revocation status data types, etc.]

Policy Discovery Protocol (PDP) is not addressed.





Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h0NAnqb22585 for ietf-pkix-bks; Thu, 23 Jan 2003 02:49:52 -0800 (PST)
Received: from firewall.andxor.com (firewall.andxor.it [195.223.2.2]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h0NAnmo22573 for <[e-mail]>; Thu, 23 Jan 2003 02:49:49 -0800 (PST)
Received: from tho.andxor.com (tho.andxor.it [195.223.2.222]) by firewall.andxor.com (8.12.3/8.12.3) with ESMTP id h0NAnb5C047256 for <[e-mail]>; Thu, 23 Jan 2003 11:49:38 +0100 (CET) (envelope-from [e-mail])
Received: (from tho@localhost) by tho.andxor.com (8.11.6/8.11.6) id h0NAnbB18821 for [e-mail]; Thu, 23 Jan 2003 10:49:37 GMT (envelope-from tho)
Date: Thu, 23 Jan 2003 10:49:36 +0000
From: tho <[e-mail]>
To: [e-mail]
Subject: STRAWPOLL:DVCS
Message-ID: <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5i
X-Operating-System: FreeBSD
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

  


Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h0NA6I818996 for ietf-pkix-bks; Thu, 23 Jan 2003 02:06:18 -0800 (PST)
Received: from nic.lp.se (nic.lp.se [212.247.5.91]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h0NA6Fo18991 for <[e-mail]>; Thu, 23 Jan 2003 02:06:16 -0800 (PST)
Received: from localhost (130.237.234.215) by nic.lp.se (MX V5.3 VnHj) with ESMTP for <[e-mail]>; Thu, 23 Jan 2003 11:04:16 +0100
Date: Thu, 23 Jan 2003 11:01:27 +0100 (CET)
Message-ID: <[e-mail]>
To: [e-mail]
Subject: Re: Strawpoll for DPD/DPV protocols
From: Richard Levitte - VMS Whacker <[e-mail]>
In-Reply-To: <[e-mail]>
References: <[e-mail]>
X-URL: http://www.lp.se/
X-Waved: dead chicken, GNU emacs 21.2.2, Mew version 3.1
X-Mew: See http://www.mew.org/
X-Mailer: Mew version 3.1 on Emacs 21.2 / Mule 5.0 (SAKAKI)
MIME-Version: 1.0
Content-Type: Text/Plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

In message <[e-mail]> on Tue, 21 Jan 2003 17:17:03 -0500, [e-mail] said:

wpolk> *  DPV and DPD over OCSP, available at <http://www.ietf.org/internet-
wpolk> drafts/draft-ietf-pkix-ocsp-dpvdpd-00.txt>; and

I've a hard time finding a compliance matrix for this one.  Was one
ever submitted?  In any case, if there is one, I'd really appreciate
it if someone could send me a copy.

-- 
Richard Levitte     | http://richard.levitte.org/ | Spannv. 38, I
Levitte Programming | http://www.lp.se/           | S-168 35 Bromma
T: [phone] |                             | SWEDEN
     "Price, performance, quality...  choose the two you like"


Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h0N2Y0G08415 for ietf-pkix-bks; Wed, 22 Jan 2003 18:34:00 -0800 (PST)
Received: from hermes.cs.auckland.ac.nz (hermes.cs.auckland.ac.nz [130.216.35.151]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h0N2Xwo08410 for <[e-mail]>; Wed, 22 Jan 2003 18:33:58 -0800 (PST)
Received: from medusa01.cs.auckland.ac.nz (medusa01.cs.auckland.ac.nz [130.216.34.60]) by hermes.cs.auckland.ac.nz (8.12.4/8.12.4) with ESMTP id h0N2XrOr027296; Thu, 23 Jan 2003 15:33:53 +1300
Received: (from pgut001@localhost) by medusa01.cs.auckland.ac.nz (8.11.6/8.11.6) id h0N2XsY13812; Thu, 23 Jan 2003 15:33:54 +1300
Date: Thu, 23 Jan 2003 15:33:54 +1300
Message-Id: <[e-mail]>
From: [e-mail] (Peter Gutmann)
To: [e-mail], [e-mail]
Subject: RE: STRAWPOLL:SCVP
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

"Michael Myers" <[e-mail]> writes:

>I see no text when I read the above thread.  Other PKIX text messages are OK.

This is easily fixed:

1. Go to http://www.imc.org/ietf-pkix/mail-archive/maillist.html.
2. Find a thread with the topic "SCVP" or "DPD/DPV".  Any thread will do
   (apart from the first one, which is the current thread).
3. Cut and paste the thread contents into the current thread.  Now you
   have the text to go with the headers.

Peter.


Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h0N09dB03992 for ietf-pkix-bks; Wed, 22 Jan 2003 16:09:39 -0800 (PST)
Received: from mail.coastside.net (mail.coastside.net [207.213.212.6]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h0N09bo03988 for <[e-mail]>; Wed, 22 Jan 2003 16:09:37 -0800 (PST)
Received: from MMyersLapTop (ppp213-56.coastside.net [207.213.213.56]) by mail.coastside.net  with SMTP id h0N09b81001027 for <[e-mail]>; Wed, 22 Jan 2003 16:09:38 -0800 (PST)
From: "Michael Myers" <[e-mail]>
To: <[e-mail]>
Subject: RE: STRAWPOLL:SCVP
Date: Wed, 22 Jan 2003 17:04:51 -0800
Message-ID: <[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0)
Importance: Normal
In-Reply-To: <!~!UENERkVCMDkAAQACAAAAAAAAAAAAAAAAABgAAAAA[e-mail]>
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

I see no text when I read the above thread.  Other PKIX text
messages are OK.

Mike



Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h0MMa9R01340 for ietf-pkix-bks; Wed, 22 Jan 2003 14:36:09 -0800 (PST)
Received: from imr5.us.db.com (imr5.us.db.com [160.83.65.196]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h0MMa6o01335 for <[e-mail]>; Wed, 22 Jan 2003 14:36:06 -0800 (PST)
Received: from sdbo1005.db.com by imr5.us.db.com  id h0MMXtDk026816; Wed, 22 Jan 2003 17:35:57 -0500 (EST)
Subject: STRAWPOLL: SCVP
To: [e-mail]
X-Mailer: Lotus Notes Release 5.0.8  June 18, 2001
Message-ID: <[e-mail]>
From: "Frank Balluffi" <[e-mail]>
Date: Wed, 22 Jan 2003 17:35:33 -0500
X-MIMETrack: Serialize by Router on sdbo1005/DBNA/DeuBaInt/DeuBa(Release 5.0.9a |January 7, 2002) at 01/22/2003 05:35:50 PM
MIME-Version: 1.0
Content-type: text/plain; charset=us-ascii
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

--

This e-mail may contain confidential and/or privileged information. If you are not the intended recipient (or have received this e-mail in error) please notify the sender immediately and destroy this e-mail. Any unauthorized copying, disclosure or distribution of the material in this e-mail is strictly forbidden.




Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h0MMJKO00594 for ietf-pkix-bks; Wed, 22 Jan 2003 14:19:20 -0800 (PST)
Received: from brutesquadlabs.com (gtec136-m.isomedia.com [207.115.67.136] (may be forged)) by above.proper.com (8.11.6/8.11.3) with ESMTP id h0MMJKo00589 for <[e-mail]>; Wed, 22 Jan 2003 14:19:20 -0800 (PST)
Received: from DEXTER ([192.168.0.4]) by brutesquadlabs.com with ESMTP ; Wed, 22 Jan 2003 14:19:17 -0800
From: "Blake Ramsdell" <[e-mail]>
To: <[e-mail]>, <[e-mail]>
Cc: <[e-mail]>
Subject: STRAWPOLL:SCVP
Date: Wed, 22 Jan 2003 14:19:17 -0800
Message-ID: <!~!UENERkVCMDkAAQACAAAAAAAAAAAAAAAAABgAAAAA[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook, Build 10.0.2627
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106
Importance: Normal
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

--
Blake Ramsdell | Brute Squad Labs | http://www.brutesquadlabs.com 



Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h0MLsat29102 for ietf-pkix-bks; Wed, 22 Jan 2003 13:54:36 -0800 (PST)
Received: from tholian.rsasecurity.com (tholian.securitydynamics.com [204.167.114.129]) by above.proper.com (8.11.6/8.11.3) with SMTP id h0MLsZo29097 for <[e-mail]>; Wed, 22 Jan 2003 13:54:35 -0800 (PST)
Received: from no.name.available by tholian.rsasecurity.com via smtpd (for mail.imc.org [208.184.76.43]) with SMTP; 22 Jan 2003 21:54:38 UT
Received: from ebola.securitydynamics.com (ebola.securid.com [192.80.211.4]) by sdtihq24.securid.com (Pro-8.9.3/Pro-8.9.3) with ESMTP id QAA01444 for <[e-mail]>; Wed, 22 Jan 2003 16:54:37 -0500 (EST)
Received: from exrsa01.rsa.com (localhost [127.0.0.1]) by ebola.securitydynamics.com (8.10.2+Sun/8.10.2) with ESMTP id h0MLpSY10771 for <[e-mail]>; Wed, 22 Jan 2003 16:51:28 -0500 (EST)
Received: by exrsa01.rsa.com with Internet Mail Service (5.5.2653.19) id <Y760D975>; Wed, 22 Jan 2003 13:54:35 -0800
Message-ID: <[e-mail]>
From: "Jacoby, Jeffrey" <[e-mail]>
To: "'[e-mail]'" <[e-mail]>
Subject: STRAWPOLL:SCVP
Date: Wed, 22 Jan 2003 13:54:34 -0800
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain; charset="iso-8859-1"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>


Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h0MKAdm25188 for ietf-pkix-bks; Wed, 22 Jan 2003 12:10:39 -0800 (PST)
Received: from edelweb.fr (edelweb.fr [212.234.46.16]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h0MKAbo25183 for <[e-mail]>; Wed, 22 Jan 2003 12:10:37 -0800 (PST)
Received: from champagne.edelweb.fr (localhost.edelweb.fr [127.0.0.1]) by edelweb.fr with ESMTP id VAA19554; Wed, 22 Jan 2003 21:10:35 +0100 (MET)
Received: from champagne.edelweb.fr (champagne.edelweb.fr [193.51.14.161]) by edelweb.fr (nospam/1.6); Wed, 22 Jan 2003 21:10:35 +0100 (MET)
Received: (from sylvest@localhost) by champagne.edelweb.fr (8.7.6/8.6.6) id VAA16287; Wed, 22 Jan 2003 21:10:34 +0100 (MET)
Date: Wed, 22 Jan 2003 21:10:34 +0100 (MET)
From: Peter Sylvester <[e-mail]>
Message-Id: <[e-mail]>
To: [e-mail], [e-mail]
Subject: Re: Strawpoll for DPD/DPV protocols
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

> Folks,
> 
> It is time for this co-chair to eat some crow.
> 
> I totally blew it in my strawpoll message.  I missed Peter Sylvester's 
> compliance matrix for DVCS (submitted on December 24). I was on vacation at 
> the time, and didn't do a thorough job of catching up on the list.  Since I 
> hadn't seen the compliance matrix, I did not include DVCS as a 
> candidate.  I should have followed up with Peter to confirm that *before* 
> sending the strawpoll message, but I did not.
> 
> DVCS is a fourth strong candidate for consideration in the the DPD/DPV 
> strawpoll.  Please review RFC 3029 "Data Validation and Certification 
> Server Protocols" and the compliance matrix as you prepare to vote.
> 
> If DVCS is your preferred protocol, please use the subject line 
> STRAWPOLL:DVCS to vote for DVCS.
> 
> Now *I* have a choice to make - barbecue or teriyaki?
> 

Thansk for the fast correction...  oysters or sashimi ?


Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h0MJiTp24033 for ietf-pkix-bks; Wed, 22 Jan 2003 11:44:29 -0800 (PST)
Received: from postmark.nist.gov (pullyou.nist.gov [129.6.16.93]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h0MJiRo24029 for <[e-mail]>; Wed, 22 Jan 2003 11:44:27 -0800 (PST)
Received: from krdp8.nist.gov (krdp8.ncsl.nist.gov [129.6.54.113]) by postmark.nist.gov (8.12.5/8.12.5) with ESMTP id h0MJiDpg027028 for <[e-mail]>; Wed, 22 Jan 2003 14:44:13 -0500 (EST)
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Version 5.1
X-Priority: 1 (Highest)
Date: Wed, 22 Jan 2003 14:45:58 -0500
To: [e-mail]
From: Tim Polk <[e-mail]>
Subject: Re: Strawpoll for DPD/DPV protocols
In-Reply-To: <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Folks,

It is time for this co-chair to eat some crow.

I totally blew it in my strawpoll message.  I missed Peter Sylvester's 
compliance matrix for DVCS (submitted on December 24). I was on vacation at 
the time, and didn't do a thorough job of catching up on the list.  Since I 
hadn't seen the compliance matrix, I did not include DVCS as a 
candidate.  I should have followed up with Peter to confirm that *before* 
sending the strawpoll message, but I did not.

DVCS is a fourth strong candidate for consideration in the the DPD/DPV 
strawpoll.  Please review RFC 3029 "Data Validation and Certification 
Server Protocols" and the compliance matrix as you prepare to vote.

If DVCS is your preferred protocol, please use the subject line 
STRAWPOLL:DVCS to vote for DVCS.

Now *I* have a choice to make - barbecue or teriyaki?

Thanks,

Tim Polk

At 05:17 PM 1/21/2003 -0500, [e-mail] wrote:



>Folks,
>
>As discussed at the last meeting and on the list, it is imperative that the
>PKIX working group progress a single DPD/DPV protocol.  Three strong 
>proposals
>are on the table (listed in alphabetical order):
>
>*  Certificate Validation Protocol (CVP), available at
><http://www.ietf.org/internet-drafts/draft-ietf-pkix-ocsp-dpvdpd-00.txt>;
>*  DPV and DPD over OCSP, available at <http://www.ietf.org/internet-
>drafts/draft-ietf-pkix-ocsp-dpvdpd-00.txt>; and
>*  Simple Certificate Validation Protocol (SCVP), available at
><http://www.ietf.org/internet-drafts/draft-ietf-pkix-scvp-11.txt>.
>
>The working groups needs to make the difficult decision, and select the one
>and only PKIX protocol for DPD/DPV.  Our primary guide in the development 
>of a
>DPD/DPV protocol is the requirements document RFC 3379.  Each of the editing
>teams has submitted a "compliance matrix" describing how their protocol
>satisfies requirements specified in 3379.  I want to encourage each of you to
>take this decision seriously.  The editors have all invested a great deal of
>time and effort in these documents, and we owe them that much.
>
>I am asking that each of you review, at a minimum, the compliance matrix
>submitted by each team *before* voting.  The compliance matrix was a major
>pain for the editors and is our best yardstick for 3379 compliance.  Better
>yet, if you haven't reviewed the latest draft for one of the specifications,
>please take this opportunity to do so as well!  Informed voters make a better
>strawpoll result...
>
>Since some of the compliance matrices were submitted recently, I would 
>like to
>hold the voting open through Monday, January 27.  (Hopefully, this is enough
>time to get informed if you aren't already!)
>
>To simplify the task for the co-chairs, I would appreciate if the Subject 
>line
>could specify both the strawpoll and vote, as in STRAWPOLL:xxx, where xxx
>is "CVP", "OCSP", or "SCVP".  (As I recall, this worked nicely for previous
>strawpolls.)
>
>Thanks,
>
>Tim Polk



Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h0MJfQo23920 for ietf-pkix-bks; Wed, 22 Jan 2003 11:41:26 -0800 (PST)
Received: from edelweb.fr (edelweb.fr [212.234.46.16]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h0MJfOo23915 for <[e-mail]>; Wed, 22 Jan 2003 11:41:24 -0800 (PST)
Received: from champagne.edelweb.fr (localhost.edelweb.fr [127.0.0.1]) by edelweb.fr with ESMTP id UAA19333 for <[e-mail]>; Wed, 22 Jan 2003 20:41:26 +0100 (MET)
Received: from champagne.edelweb.fr (champagne.edelweb.fr [193.51.14.161]) by edelweb.fr (nospam/1.6); Wed, 22 Jan 2003 20:41:26 +0100 (MET)
Received: (from sylvest@localhost) by champagne.edelweb.fr (8.7.6/8.6.6) id UAA16117 for [e-mail]; Wed, 22 Jan 2003 20:41:24 +0100 (MET)
Date: Wed, 22 Jan 2003 20:41:24 +0100 (MET)
From: Peter Sylvester <[e-mail]>
Message-Id: <[e-mail]>
To: [e-mail]
Subject: strawpoll:DVCS
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>


Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h0MIasm21573 for ietf-pkix-bks; Wed, 22 Jan 2003 10:36:54 -0800 (PST)
Received: from postmark.nist.gov (pullyou.nist.gov [129.6.16.93]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h0MIapo21569 for <[e-mail]>; Wed, 22 Jan 2003 10:36:52 -0800 (PST)
Received: from krdp8.nist.gov (krdp8.ncsl.nist.gov [129.6.54.113]) by postmark.nist.gov (8.12.5/8.12.5) with ESMTP id h0MIaUpg024017; Wed, 22 Jan 2003 13:36:30 -0500 (EST)
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Version 5.1
Date: Wed, 22 Jan 2003 13:38:15 -0500
To: [e-mail]
From: Tim Polk <[e-mail]>
Subject: Progress report: RFC 3280/3281 Interop testing
Cc: [e-mail]
Mime-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"; format=flowed
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id h0MIaro21570
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Folks,

This message is both a progress report on the RFC 3280 and 3281 testing and 
a request for your assistance in completing that testing.

We are working from a matrix initially developed by Jim Schaad.  Chris 
Brown here at NIST is performing the certificate and CRL feature testing, 
with assistance from Nelson Hastings and David Cooper.  We are also working 
with DigitalNet (formerly Getronics) and DoD to develop tests for the path 
validation algorithm.  David Cooper is the NIST lead for that project.

The certificate and CRL feature testing is largely complete.  We have 
generated two examples for most features from at least two independent 
implementations.  However, we need to obtain examples for a few remaining 
features.

The list is appended at the end of this message.  The list is divided into 
nine certificate fields and 10 CRL "fields", with a number of 
subcategories.  We are looking for folks that have an implementation which 
satisfies these requirements, and can generate some examples for 
us.  Examples don't need to implement all of the subcategories; examples 
that satisfy any one of them are acceptable!

If you can help, please send email to Chris Brown.  I cc'ed him on this 
message so that you will all have his email address.  Chris will need to 
obtain at a minimum the certificate or CRL, but a path associated with the 
certificate would be even more helpful.  Please specify 
which   implementation was used to generate the example(s).

When the path validation tests are complete, we will be looking for 
volunteers to execute those tests as well.  I will update the list on that 
part of the testing once we are ready to go.

Thanks,

Tim Polk



------------------------------- remaining features for RFC 3280 and 3281 
----------------------

CERTIFICATE FIELD #1: Names (subject or issuer acceptable)
	Need one example each for names including the following attributes
a)	dNqualifier
b)	givenName
c)	initials
d)	pseudonym
e)	generationQualifier
f)	domainComponents

CERTIFICATE FIELD #2: subject
*	empty subject DN with critical altSubjectName (need 1 example – have MISPC)

CERTIFICATE FIELD #3: SubjectPublicKey
a)	DSA public key with parameters omitted
b)	elliptic key with parameters present
c)	elliptic curve key with NULL parameters (need 1 example: have Entrust)
d)	Diffie-Hellman

CERTIFICATE FIELD #4: Signature field
*	ECDSA signature (need 1 example: have Entrust)

CERTIFICATE FIELD #5: Certificate policy extension
*	CPS pointer qualifier (need 1 example: have openSSL)

CERTIFICATE FIELD #6: SubjectAltName
a)	IPv6 addresses (have one example from David; Chris will complete using 
OpenSSL)
b)	OtherName
c)	resolution – Chris will generate with openSSL given DER encoding which 
David will provide; David will generate examples with MISPC

CERTFICATE FIELD #7: CRL distribution points
a)	CA != issuer [indirect CRLs]
b)	CRLissuer field that has multiple names, and distribution point has a 
non-relative name


CERTIFICATE FIELD #8: authority information access extension
*	id-ca-issuers where location is a DN

CERTIFICATE FIELD #9: subject information access
a)	id-ca-repository and
	1.	location is URI
	2.	location is DAP
	3.	location is rfc822

CRL FIELD #1: SignatureAlgorithm
*	ECDSA with parameters NULL (1 example – have Entrust)

CRL FIELD #2: Issuer Name
a)	Distinguished name qualifier, state or province name, common name, 
serial number (1 example – have OpenSSL)
b)	Locality, title, surname(2 examples), given name, initials, pseudonym, 
generation qualifier (1 example – have OpenSSL)
c)	Use BMPString (2 examples)
d)	Use UTF8String (2 examples)

CRL FIELD #3: This Update
*	Date >= 2050, encoded as GeneralizedTime (2 examples)

CRL FIELD #4: Next Update
*	Date >= 2050, encoded as GeneralizedTime (2 examples)

CRL FIELD #5: Issuer Alternative Name
a)	IpV4 address (iPlanet encoded w/ 8 octet bytes ???? ) DNS Name ( 1 
example – have iPlanet)
b)	IpV6 address,  other name (2 examples)


CRL #6: CRL Number
a)	Delta and CRLs on the same scope must share one numbering sequence (1 
example – have iPlanet)
b)	Delta and CRL on same scope issued at same time must have same number (2 
examples)

CRL #7: Delta Indicator
*	(need 2 examples)
a)	MUST list as removeFromHold in delta if held since base but now not held
b)	MUST list as removeFromCRL if certificate has expired and was revoked
c)	MUST include revoked and expired certificate on delta until it appears 
on at least one full CRL
*	(1 example – have iPlanet)
d)	All referenced base CRLs must be full CRLs
e)	Delta CRLs MUST contain this extension as crititcal
f)	Base and Delta MUST omit CDP or have identical CDPs
g)	Use same key for Base and Delta CRLs
h)	MUST include cert on delta if status changed since base

CRL #8: Issuing Distribution Point
a)	If onlySomeReasons omitted, CRL MUST have all reasons (1 example – have 
Entrust)
b)	CRL issuer MUST assert indirectCRL for non_CA issued CRLs (1 example – 
have iPlanet)

CRL #9: Freshest CRL
*	All tests (2 examples)
a)	Extension must be non-critical
b)	Extension must not be present in delta CRLs
c)	Omit reasons and CRLIssuer from extension

CRL #10: CRL Entry Extensions
a)	Hold Instruction Code (1 example – have OpenSSL)
b)	Certificate Issuer (2 examples)



Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h0MIOQ521169 for ietf-pkix-bks; Wed, 22 Jan 2003 10:24:26 -0800 (PST)
Received: from mail2.microsoft.com (mail2.microsoft.com [131.107.3.124]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h0MIOOo21165 for <[e-mail]>; Wed, 22 Jan 2003 10:24:24 -0800 (PST)
Received: from INET-VRS-02.redmond.corp.microsoft.com ([157.54.8.110]) by mail2.microsoft.com with Microsoft SMTPSVC(5.0.2195.5329); Wed, 22 Jan 2003 10:24:18 -0800
Received: from 157.54.5.25 by INET-VRS-02.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Wed, 22 Jan 2003 10:24:18 -0800
Received: from RED-IMC-01.redmond.corp.microsoft.com ([157.54.9.102]) by INET-HUB-03.redmond.corp.microsoft.com with Microsoft SMTPSVC(6.0.3710.0); Wed, 22 Jan 2003 10:24:18 -0800
Received: from WIN-IMC-02.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.84]) by RED-IMC-01.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.5600); Wed, 22 Jan 2003 10:24:17 -0800
Received: from WIN-MSG-01.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.52]) by WIN-IMC-02.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(6.0.3718.0); Wed, 22 Jan 2003 10:24:17 -0800
X-MimeOLE: Produced By Microsoft Exchange V6.5.6830.0
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="------------InterScan_NT_MIME_Boundary"
Subject: strawpoll:SCVP
Date: Wed, 22 Jan 2003 10:24:23 -0800
Message-ID: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: strawpoll:SCVP
thread-index: AcLCQ3Mh8Njg/H68QaacFSBC00twkw==
From: "Trevor Freeman" <[e-mail]>
To: <[e-mail]>
X-OriginalArrivalTime: 22 Jan 2003 18:24:17.0659 (UTC) FILETIME=[797C6CB0:01C2C243]
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

This is a multi-part message in MIME format.

--------------InterScan_NT_MIME_Boundary
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C2C243.7D1C5A01"

------_=_NextPart_001_01C2C243.7D1C5A01
Content-Type: text/plain;
	charset="US-ASCII"
Content-Transfer-Encoding: quoted-printable

=20


------_=_NextPart_001_01C2C243.7D1C5A01
Content-Type: text/html;
	charset="US-ASCII"
Content-Transfer-Encoding: quoted-printable

<html>

<head>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Dus-ascii">


<meta name=3DGenerator content=3D"Microsoft Word 10 (filtered)">

<style>
<!--
 /* Font Definitions */
 @font-face
	{font-family:"MS Mincho";
	panose-1:2 2 6 9 4 2 5 8 3 4;}
@font-face
	{font-family:"\@MS Mincho";
	panose-1:2 2 6 9 4 2 5 8 3 4;}
 /* Style Definitions */
 p.MsoNormal, li.MsoNormal, div.MsoNormal
	{margin:0in;
	margin-bottom:.0001pt;
	font-size:12.0pt;
	font-family:"Times New Roman";}
a:link, span.MsoHyperlink
	{color:blue;
	text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
	{color:purple;
	text-decoration:underline;}
span.EmailStyle17
	{font-family:Arial;
	color:windowtext;}
@page Section1
	{size:8.5in 11.0in;
	margin:1.0in 1.25in 1.0in 1.25in;}
div.Section1
	{page:Section1;}
-->
</style>

</head>

<body lang=3DEN-US link=3Dblue vlink=3Dpurple>

<div class=3DSection1>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span lang=3DEN-GB =
style=3D'font-size:
10.0pt;font-family:Arial'>&nbsp;</span></font></p>

</div>

</body>

</html>
=00
------_=_NextPart_001_01C2C243.7D1C5A01--

--------------InterScan_NT_MIME_Boundary--



Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h0MICQO20794 for ietf-pkix-bks; Wed, 22 Jan 2003 10:12:26 -0800 (PST)
Received: from ssymexc.anassoc.com ([204.95.114.85]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h0MICOo20789 for <[e-mail]>; Wed, 22 Jan 2003 10:12:24 -0800 (PST)
X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0
content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Subject: STRAWPOLL:SCVP
Date: Wed, 22 Jan 2003 13:12:21 -0500
Message-ID: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: STRAWPOLL:SCVP
Thread-Index: AcLCQc3b/xk1d944Tbe5jxf8uo0KBg==
From: "Yuriy Dzambasow" <[e-mail]>
To: "PKIX (E-mail)" <[e-mail]>
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id h0MICOo20790
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>


Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h0MGcIm15420 for ietf-pkix-bks; Wed, 22 Jan 2003 08:38:18 -0800 (PST)
Received: from tholian.rsasecurity.com (tholian.securitydynamics.com [204.167.114.129]) by above.proper.com (8.11.6/8.11.3) with SMTP id h0MGcCo15416 for <[e-mail]>; Wed, 22 Jan 2003 08:38:13 -0800 (PST)
Received: from no.name.available by tholian.rsasecurity.com via smtpd (for mail.imc.org [208.184.76.43]) with SMTP; 22 Jan 2003 16:38:14 UT
Received: from ebola.securitydynamics.com (ebola.securid.com [192.80.211.4]) by sdtihq24.securid.com (Pro-8.9.3/Pro-8.9.3) with ESMTP id LAA23309; Wed, 22 Jan 2003 11:38:13 -0500 (EST)
Received: from exrsa01.rsa.com (localhost [127.0.0.1]) by ebola.securitydynamics.com (8.10.2+Sun/8.10.2) with ESMTP id h0MGZ3f24929; Wed, 22 Jan 2003 11:35:03 -0500 (EST)
Received: by exrsa01.rsa.com with Internet Mail Service (5.5.2653.19) id <Y760D894>; Wed, 22 Jan 2003 08:38:10 -0800
Message-ID: <[e-mail]>
From: "Yee, Peter" <[e-mail]>
To: "'[e-mail]'" <[e-mail]>, "'[e-mail]'" <[e-mail]>
Cc: "'[e-mail]'" <[e-mail]>
Subject: STRAWPOLL:SCVP
Date: Wed, 22 Jan 2003 08:48:43 -0800
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain; charset="iso-8859-1"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>


Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h0MGGQF14666 for ietf-pkix-bks; Wed, 22 Jan 2003 08:16:26 -0800 (PST)
Received: from edelweb.fr (edelweb.fr [212.234.46.16]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h0MGGNo14661 for <[e-mail]>; Wed, 22 Jan 2003 08:16:23 -0800 (PST)
Received: from champagne.edelweb.fr (localhost.edelweb.fr [127.0.0.1]) by edelweb.fr with ESMTP id RAA18064 for <[e-mail]>; Wed, 22 Jan 2003 17:16:23 +0100 (MET)
Received: from champagne.edelweb.fr (champagne.edelweb.fr [193.51.14.161]) by edelweb.fr (nospam/1.6); Wed, 22 Jan 2003 17:16:23 +0100 (MET)
Received: (from sylvest@localhost) by champagne.edelweb.fr (8.7.6/8.6.6) id RAA15106 for [e-mail]; Wed, 22 Jan 2003 17:16:22 +0100 (MET)
Date: Wed, 22 Jan 2003 17:16:22 +0100 (MET)
From: Peter Sylvester <[e-mail]>
Message-Id: <[e-mail]>
To: [e-mail]
Subject: DVCS Compliance Matrix
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

in case, that some Christmas monster has eaten this message. 


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


Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h0MGBBU14490 for ietf-pkix-bks; Wed, 22 Jan 2003 08:11:11 -0800 (PST)
Received: from edelweb.fr (edelweb.fr [212.234.46.16]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h0MGBAo14486 for <[e-mail]>; Wed, 22 Jan 2003 08:11:10 -0800 (PST)
Received: from champagne.edelweb.fr (localhost.edelweb.fr [127.0.0.1]) by edelweb.fr with ESMTP id RAA18036; Wed, 22 Jan 2003 17:11:08 +0100 (MET)
Received: from champagne.edelweb.fr (champagne.edelweb.fr [193.51.14.161]) by edelweb.fr (nospam/1.6); Wed, 22 Jan 2003 17:11:08 +0100 (MET)
Received: (from sylvest@localhost) by champagne.edelweb.fr (8.7.6/8.6.6) id RAA15084; Wed, 22 Jan 2003 17:11:07 +0100 (MET)
Date: Wed, 22 Jan 2003 17:11:07 +0100 (MET)
From: Peter Sylvester <[e-mail]>
Message-Id: <[e-mail]>
To: [e-mail], [e-mail]
Subject: Re: Strawpoll for DPD/DPV protocols
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

I think that I have send a mail with another proposal. It seems
that the number of blacklists is growing :-) 


Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h0MFC1f12266 for ietf-pkix-bks; Wed, 22 Jan 2003 07:12:01 -0800 (PST)
Received: from ns.malpani.biz (adsl-63-194-89-166.dsl.snfc21.pacbell.net [63.194.89.166]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h0MFC0o12259 for <[e-mail]>; Wed, 22 Jan 2003 07:12:00 -0800 (PST)
Received: from nt1 (nt1.malpani.biz [192.168.25.13]) by ns.malpani.biz (8.12.5/8.12.5) with SMTP id h0MFBjZp001796; Wed, 22 Jan 2003 07:11:45 -0800
From: "Ambarish Malpani" <[e-mail]>
To: <[e-mail]>, <[e-mail]>
Cc: <[e-mail]>
Subject: STRAWPOLL:SCVP
Date: Wed, 22 Jan 2003 07:12:52 -0800
Message-ID: <[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0)
In-Reply-To: <[e-mail]>
X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1106
Importance: Normal
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

---------------------------------------------------------------------
Ambarish Malpani                                         650.759.9045
Malpani Consulting Services                      [e-mail]
http://www.malpani.biz




Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h0MF5wS12098 for ietf-pkix-bks; Wed, 22 Jan 2003 07:05:58 -0800 (PST)
Received: from infobro.com ([e-mail] [63.71.25.39]) by above.proper.com (8.11.6/8.11.3) with SMTP id h0MF5vo12094 for <[e-mail]>; Wed, 22 Jan 2003 07:05:57 -0800 (PST)
Received: from red (unverified [207.199.136.153]) by infobro.com (EMWAC SMTPRS 0.83) with SMTP id <[e-mail]>; Wed, 22 Jan 2003 09:38:30 -0500
Received: by localhost with Microsoft MAPI; Wed, 22 Jan 2003 09:38:28 -0500
Message-ID: <[e-mail]>
From: "Eric D. Williams" <[e-mail]>
To: "[e-mail]" <[e-mail]>
Subject: Re: STRAWPOLL:SCVP
Date: Wed, 22 Jan 2003 09:35:15 -0500
Organization: Information Brokers, Inc.
X-Mailer: Microsoft Internet E-mail/MAPI - 8.0.0.4211
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>


Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h0MBRsB28501 for ietf-pkix-bks; Wed, 22 Jan 2003 03:27:54 -0800 (PST)
Received: from edelweb.fr (edelweb.fr [212.234.46.16]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h0MBRqo28492 for <[e-mail]>; Wed, 22 Jan 2003 03:27:52 -0800 (PST)
Received: from champagne.edelweb.fr (localhost.edelweb.fr [127.0.0.1]) by edelweb.fr with ESMTP id MAA16557 for <[e-mail]>; Wed, 22 Jan 2003 12:27:51 +0100 (MET)
Received: from champagne.edelweb.fr (champagne.edelweb.fr [193.51.14.161]) by edelweb.fr (nospam/1.6); Wed, 22 Jan 2003 12:27:51 +0100 (MET)
Received: (from sylvest@localhost) by champagne.edelweb.fr (8.7.6/8.6.6) id MAA13966 for [e-mail]; Wed, 22 Jan 2003 12:27:50 +0100 (MET)
Date: Wed, 22 Jan 2003 12:27:50 +0100 (MET)
From: Peter Sylvester <[e-mail]>
Message-Id: <[e-mail]>
To: [e-mail]
Subject: Re: Strawpoll for DPD/DPV protocols
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Some thoughts in a brainstorming way: 

- There is a lot of overlap in concrete techniques used by
  there various protocols.

- The proposals specify a protocol using concrete data units
  and not necessarily as an abstarct protocol mapped to
  concrete syntaxes.

- There are different choices for some major protocol elements,
  i.e., transport, pretection of transport of data units,
  different elements in the payload.

- There is an inflation of different ways to identify certificates
  which is more or less obscured by concrete syntxes and not
  explained by requirements. 

-  There is a variety of possible relationships depending
  on the intent of the usage of the protocol. This can
  range from a very thin client that is close to a server
  and can use some simple authentication method to
  some asynchronous email based client / server comm.

- The different possible trust relationships between
  clients and server are not clear.

- The different needs for transport of payload protection for these
  cases are not always clear. 

The technical differences, in particular the different ways to
secure payloads and to address identification and authentication
which somehow almost looks like layer violation make me feel
that we might want to establish some general principles of
best known techniques for certain aspects. 

It seems that 80% or more of each proposal cover issues that do not
have anything to do with the underlying problem but with 
'lower layers', or, one might consider to a maximum already
existing techniques.  

I'd like to start with a small description of some points without
trying to be complete in any way. these points are rather
independant of this particular protocol, they apply to
others as well. 

Or, does this remind me to CMC vs CMP? 


- payload identification.

  It is always a difficult thing to find a syntax when you see
  just a pure piece of DER encoded data. One always needs an
  external indication, e.g; mime type, or an implicit
  convention. 

  On the other hand, there is at least one known technique that
  simplifies the detection of syntaxes, i.e. the usage of
  a CMS ContentInfo. By exchanging data uniots which are
  encapsulated in a CMS ContentInfo, this removes some requirements
  to the lower transport, and IMO allows more robust implementation
  since the sending partner can indicate in a clear way
  and independantly of the transport the intended syntax.

- payload security

  Due to the various different situations for clients and servers
  and the trasport protocols, different ways to protect the payload
  are possible. 

  Again, it seems that the variety of mechanisms with total
  encapsulaton provided by CMS be a good way to protect
  the payload by various ways. In particular, in certain
  circumstances, a signature protection may not be necessary,
  other faster authentication mechanism may be appropriate.

  Other protocols in PKIX and elsewhere have already shown that
  some ad hoc special methods may create some problems; in
  particular to get the implementions right. benfitting
  from existing implmentations of SMIME and the experiences
  seem not a bad thing to me.

  There is a sub issues of identification and binding of
  authentication in the response. Again, SMIME provides
  a standadised mechnism in ESS.

- Identification of transaction participants

  It seems useful to me to have a clear separation of 
  the authentication identifications and the identifications
  that can be used in the payloads to indicate the
  participating identities, in particular if the
  communication is secured by means that use different
  identifiers. 

- transport issues:

  A well known defacto way for protocols is to use HTTP or
  HTTPS as a lower layer. On the other hand, the complexity
  of this should not be underestimated. for example, to what
  degree should a client accept redirections or textual
  responses.

- ASN1 issues: 

  Protocol proposers should provide a proof that they
  have read ASN1 specification, and have specified
  and implemented using it. :-) This is rather a flame.

- using of Extension.

  technical:

  The usage of the ASN1 definition of Extension borrowed
  from X509 is, mildly saying, a very stupid thing.
  First, the definition itself in X509 shows an absolute
  lack of possibilities of ASN1 i.e. the encapsulation of
  an ASN1 structure in an string instead of of using
  .. in old terms .. ANY DEFINED BY  (oops, another flame).
  Well, ten years ago, some decoder/coder writers were
  no lonnger available to maintain broken tools ...

  But, more important, the definition is made in order
  to support a ONE WAY communication between the issuer
  of the certificate. Even with that, the meaning of
  critical has already been changed in a significant
  way.

  At, one might not add any particular meaning to
  critical, thus the field becomes superfluous.

  Furthermore, we have already seen that even the
  usage of extensions in a standard protocol 
  has created some incomplete spec (Nonce in OCSP). 

  one might consider to simply use a CMS
  contentInfo. 

  logical: 

  An overly use of optional extension does not really
  simplify the interoperability. 

  In an extreme, one could argue that the whole
  PDUs should simply be a particalur profile 
  of 'Extensions'. 

-- 
regards
Peter Sylvester

 

   
  



Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h0MBPJI28114 for ietf-pkix-bks; Wed, 22 Jan 2003 03:25:19 -0800 (PST)
Received: from kraid.nerim.net (smtp-102.nerim.net [62.4.16.102]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h0MBPHo28106 for <[e-mail]>; Wed, 22 Jan 2003 03:25:17 -0800 (PST)
Received: from jupiter.cry.pto (cryptolog.net1.nerim.net [80.65.224.225]) by kraid.nerim.net (Postfix) with ESMTP id 5A4A440F60 for <[e-mail]>; Wed, 22 Jan 2003 12:12:35 +0100 (CET)
Received: from localhost (localhost [127.0.0.1]) by jupiter.cry.pto (Postfix) with ESMTP id 1E5DF40C5 for <[e-mail]>; Wed, 22 Jan 2003 12:25:14 +0100 (CET)
Received: from callisto.cry.pto (callisto.cry.pto [10.0.1.4]) by jupiter.cry.pto (Postfix) with SMTP id B481240B6 for <[e-mail]>; Wed, 22 Jan 2003 12:25:13 +0100 (CET)
Received: by callisto.cry.pto (sSMTP sendmail emulation); Wed, 22 Jan 2003 12:25:13 +0100
From: "Julien Stern" <[e-mail]>
Date: Wed, 22 Jan 2003 12:25:13 +0100
To: [e-mail]
Subject: What to do with incorrectly encoded X509 extensions ?
Message-ID: <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.4i
X-Virus-Scanned: by AMaViS new-20020517
X-Razor-id: 3ba6ebb7d139fb4ef72d8f6ea86bd0fc6a3a35e6
X-Spam-Status: No, hits=-4.6 tests=SPAM_PHRASE_00_01,USER_AGENT,USER_AGENT_MUTT
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Hi all,

it seems that the sample certificate pkix-ex3.ber which can be
downloaded from http://www.imc.org/ietf-pkix/index.html has extensions
which are not correct ASN.1 wise (some non-optional fields are missing).

More specifically the Certificate Policies Extension seems to contains an
incorrect DER encoding within the octet string (missing 'qualifier'
field in a PolicyQualifierInfo).

If an extension is critical, and does not decode correctly,
I assume the only option is to reject the whole certificate.

In the present case, the extension is marked non-critical, so one option is
to ignore it, just when an OID is not understood. However, the situation
here is slightly different: the extension is understood, but invalid
with respect to the standard. So should I simply ignore this extension
or dismiss the whole certificate ?

Sincerely,

--
Julien Stern
Cryptolog International


Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h0M8hHE12315 for ietf-pkix-bks; Wed, 22 Jan 2003 00:43:17 -0800 (PST)
Received: from odin2.bull.net (odin2.bull.net [192.90.70.84]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h0M8hDo12293 for <[e-mail]>; Wed, 22 Jan 2003 00:43:13 -0800 (PST)
Received: from clbull.frcl.bull.fr (clbull.frcl.bull.fr [129.182.8.31]) by odin2.bull.net (8.9.3/8.9.3) with ESMTP id JAA17946; Wed, 22 Jan 2003 09:44:34 +0100
Received: from bull.net (frcls4013.frcl.bull.fr [129.182.108.120]) by clbull.frcl.bull.fr (8.9.2/8.9.1) with ESMTP id JAA23908; Wed, 22 Jan 2003 09:42:57 +0100
Message-ID: <[e-mail]>
Date: Wed, 22 Jan 2003 09:42:46 +0100
From: Denis Pinkas <[e-mail]>
Organization: Bull SA.
User-Agent: Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.0.1) Gecko/20020823 Netscape/7.0
X-Accept-Language: en-us, en, fr
MIME-Version: 1.0
To: [e-mail]
CC: [e-mail], Stephen Kent <[e-mail]>
Subject: Re: Strawpoll for DPD/DPV protocols
References: <[e-mail]>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Tim,

> Folks,

> As discussed at the last meeting and on the list, it is imperative that the 
> PKIX working group progress a single DPD/DPV protocol.  Three strong proposals 
> are on the table (listed in alphabetical order):
> 
> *  Certificate Validation Protocol (CVP), available at 
> <http://www.ietf.org/internet-drafts/draft-ietf-pkix-ocsp-dpvdpd-00.txt>;

This URL is wrong since it points to the next proposal. :-(
The right URL is: http://www.imc.org/draft-ietf-pkix-cvp

This is draft-ietf-pkix-cvp-02.txt from January 2003.
The draft has been updated to fully comply with the matrix.

> *  DPV and DPD over OCSP, available at <http://www.ietf.org/internet-
> drafts/draft-ietf-pkix-ocsp-dpvdpd-00.txt>; and

> *  Simple Certificate Validation Protocol (SCVP), available at 
> <http://www.ietf.org/internet-drafts/draft-ietf-pkix-scvp-11.txt>.

> The working groups needs to make the difficult decision, and select the one 
> and only PKIX protocol for DPD/DPV.  Our primary guide in the development of a 
> DPD/DPV protocol is the requirements document RFC 3379.  Each of the editing 
> teams has submitted a "compliance matrix" describing how their protocol 
> satisfies requirements specified in 3379.  

Tim, you got the CVP matrix since it was copied directly to you, but the 
mailing list did not get it. I have sent the URL provided by Paul, so that 
anybody can get it:

http://www.imc.org/ietf-pkix/CVP-Compliance.txt

 > I want to encourage each of you to
> take this decision seriously.  The editors have all invested a great deal of 
> time and effort in these documents, and we owe them that much.

> I am asking that each of you review, at a minimum, the compliance matrix 
> submitted by each team *before* voting.  

Thank you Tim for the advise, since we already got three votes and it is 
doubtful whether the matrix for CVP has been reviewed *before* voting by 
these three voters.

That matrix highlights major benefits when compared with an alternative 
proposal.

I am wondering whether a strawpoll without any argument makes sense.

 > The compliance matrix was a major pain for the editors

Indeed.

> and is our best yardstick for 3379 compliance.  Better 
> yet, if you haven't reviewed the latest draft for one of the specifications, 
> please take this opportunity to do so as well!  Informed voters make a better 
> strawpoll result...
> 
> Since some of the compliance matrices were submitted recently, I would like to 
> hold the voting open through Monday, January 27.  (Hopefully, this is enough 
> time to get informed if you aren't already!)

Given the size of the matrixes, I would think that one more week would be 
adequate.

> To simplify the task for the co-chairs, I would appreciate if the Subject line 
> could specify both the strawpoll and vote, as in STRAWPOLL:xxx, where xxx 
> is "CVP", "OCSP", or "SCVP".  (As I recall, this worked nicely for previous 
> strawpolls.)

This is too simplistic. Some text to support the vote should be included
(at least to prove that the matrixes and the drafts have been read). :-)

Denis

> Thanks,

> Tim Polk




Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h0M8PU208590 for ietf-pkix-bks; Wed, 22 Jan 2003 00:25:30 -0800 (PST)
Received: from odin2.bull.net (odin2.bull.net [192.90.70.84]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h0M8PSo08579 for <[e-mail]>; Wed, 22 Jan 2003 00:25:29 -0800 (PST)
Received: from clbull.frcl.bull.fr (clbull.frcl.bull.fr [129.182.8.31]) by odin2.bull.net (8.9.3/8.9.3) with ESMTP id JAA12522 for <[e-mail]>; Wed, 22 Jan 2003 09:27:13 +0100
Received: from bull.net (frcls4013.frcl.bull.fr [129.182.108.120]) by clbull.frcl.bull.fr (8.9.2/8.9.1) with ESMTP id JAA18170 for <[e-mail]>; Wed, 22 Jan 2003 09:25:35 +0100
Message-ID: <[e-mail]>
Date: Wed, 22 Jan 2003 09:25:25 +0100
From: Denis Pinkas <[e-mail]>
Organization: Bull SA.
User-Agent: Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.0.1) Gecko/20020823 Netscape/7.0
X-Accept-Language: en-us, en, fr
MIME-Version: 1.0
To: pkix <[e-mail]>
Subject: RFC 3379 compliance matrix for CVP
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

The RFC 3379 compliance matrix for CVP has been posted to the list yesterday 
on Tuesday 21, but since it was a too long message, it has been rejected by 
the server and Paul Hoffman has kindly provided a URL so that anybody can 
fetch it. It is available at:

http://www.imc.org/ietf-pkix/CVP-Compliance.txt

While filling in the matrix, I made some corrections to the draft and a new
draft has been sent last week and published on Monday: 
draft-ietf-pkix-cvp-02.txt

It is available at:
http://www.imc.org/draft-ietf-pkix-cvp

Note that Tim just raised a strawpoll indicated the wrong URL for CVP. :-(

Denis



Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h0M1J1H17086 for ietf-pkix-bks; Tue, 21 Jan 2003 17:19:01 -0800 (PST)
Received: from mta01.mail.mel.aone.net.au (mta01.mail.au.uu.net [203.2.192.81]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h0M1J0o17082 for <[e-mail]>; Tue, 21 Jan 2003 17:19:00 -0800 (PST)
Received: from packbell ([203.103.158.158]) by mta01.mail.mel.aone.net.au with SMTP id <20030122012204.ZWKO20706.mta01.mail.mel.aone.net.au@packbell> for <[e-mail]>; Wed, 22 Jan 2003 12:22:04 +1100
Message-ID: <002b01c2c1b5$4e4f0cc0$9e9e67cb@packbell>
From: "Les Mitchell" <[e-mail]>
To: <[e-mail]>
References: <00cb01c2c1a8$44796c70$40a35b0c@Chokhani>
Subject: Re: STRAWPOLL:SCVP
Date: Wed, 22 Jan 2003 12:26:35 +1100
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 6.00.2800.1106
X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1106
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>


Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h0LNqmb15073 for ietf-pkix-bks; Tue, 21 Jan 2003 15:52:48 -0800 (PST)
Received: from mtiwmhc12.worldnet.att.net (mtiwmhc12.worldnet.att.net [204.127.131.116]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h0LNqko15069 for <[e-mail]>; Tue, 21 Jan 2003 15:52:47 -0800 (PST)
Received: from Chokhani ([12.91.131.197]) by mtiwmhc12.worldnet.att.net (InterMail vM.5.01.05.12 201-253-122-126-112-20020820) with ESMTP id <20030121235244.XCZC12483.mtiwmhc12.worldnet.att.net@Chokhani> for <[e-mail]>; Tue, 21 Jan 2003 23:52:44 +0000
From: "Santosh Chokhani" <[e-mail]>
To: <[e-mail]>
Subject: STRAWPOLL:SCVP
Date: Tue, 21 Jan 2003 18:53:15 -0500
Message-ID: <00cb01c2c1a8$44796c70$40a35b0c@Chokhani>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook, Build 10.0.4510
Importance: Normal
In-Reply-To: <[e-mail]>
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>


Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h0LMZvw13001 for ietf-pkix-bks; Tue, 21 Jan 2003 14:35:57 -0800 (PST)
Received: from ausyms50.ca.com ([155.35.248.106]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h0LMZso12991 for <[e-mail]>; Tue, 21 Jan 2003 14:35:54 -0800 (PST)
Received: from ausyms80.ca.com ([155.35.201.10]) by ausyms50.ca.com with Microsoft SMTPSVC(5.0.2195.4905); Wed, 22 Jan 2003 09:35:51 +1100
Received: from mail pickup service by ausyms80.ca.com with Microsoft SMTPSVC; Wed, 22 Jan 2003 09:35:49 +1100
Received: from usilms81.ca.com ([141.202.201.51]) by ausyms80.ca.com with Microsoft SMTPSVC(5.0.2195.4905); Tue, 21 Jan 2003 01:44:16 +1100
Received: from usilms53.ca.com ([141.202.248.39]) by usilms81.ca.com with Microsoft SMTPSVC(5.0.2195.5329); Mon, 20 Jan 2003 09:44:12 -0500
Received: from above.proper.com ([208.184.76.45]) by usilms53.ca.com with Microsoft SMTPSVC(5.0.2195.5329); Mon, 20 Jan 2003 09:44:12 -0500
Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h0KDqfg09344 for ietf-pkix-bks; Mon, 20 Jan 2003 05:52:41 -0800 (PST)
Received: from hubie.hubbardind.com (mail.hubbardsupply.com [65.245.100.65]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h0KDqdo09340 for <[e-mail]>; Mon, 20 Jan 2003 05:52:39 -0800 (PST)
Received: by HUBIE.hubbardsupply.com with Internet Mail Service (5.5.2653.19) id <Y0ST05N1>; Mon, 20 Jan 2003 08:52:40 -0500
Message-ID: <[e-mail]>
From: Roger Younglove <[e-mail]>
To: "'Richard Levitte - VMS Whacker'" <[e-mail]>
Cc: [e-mail]
Subject: RE: "Basic" path-validation question
Date: Mon, 20 Jan 2003 08:52:38 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C2C08B.31C9A180"
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
X-OriginalArrivalTime: 20 Jan 2003 14:44:12.0270 (UTC) FILETIME=[65A278E0:01C2C092]
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

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

------_=_NextPart_001_01C2C08B.31C9A180
Content-Type: text/plain

Richard,
Comment inserted
 
Roger Younglove, CISSP
Principal Consultant
NetWorks Group
O. 810.225.4800 ex. 2245
M. 810.599.0879
E. [e-mail]
www.networksgroup.com
 
 
-----Original Message-----
From: Richard Levitte - VMS Whacker [mailto:[e-mail]] 
Sent: Friday, January 17, 2003 4:49 PM
To: [e-mail]
Cc: [e-mail]; [e-mail]
Subject: Re: "Basic" path-validation question
 
 
In message <[e-mail]> on Fri, 17 Jan 2003 14:38:46
+0100, Jean-Marc Desperrier <[e-mail]> said:
 
jean-marc.desperrier> What is broken is the application, if it
jean-marc.desperrier> *requires* to install both RootCA and CA1 in
jean-marc.desperrier> order to trust EE_type1.
 
Yet, most software do that, *or* install just RootCA and expect to get
every intermediate CA certificate along with the messages sent to it
(that happens with S/MIME, and many SSL-enabled servers present a
whole chain except for the root itself).  From a purely PKI point of
view, both methods are broken, all needed certificates should be
retrievable from one or several publically available stores...
 
jean-marc.desperrier> It should be possible to install only CA1 as a
jean-marc.desperrier> trust anchor, there is no requirement in the
jean-marc.desperrier> path-validation that the trust anchor be
jean-marc.desperrier> self-signed.
 
Actually, I've heard quite different opinions on that.  Some people
assume that the trust anchors are self-signed.  I see no real problem
with that kind of thinking...  If nothing else, you can always set up
your own small CA, certify any other CA you trust with your CA's key,
and have your CA as trust anchor...
 
Roger> Then what you have in affect is a Bridge CA connecting the path of
trust between the CAs that you trust. This would not be a trust anchor. It
would require agreements between all of your trusted CAs because it would
also affect them by extending their individual paths of trust to each other
and they may not wish to do that.
 
jean-marc.desperrier> If the application is OpenSSL, you were talking
jean-marc.desperrier> with someone who is supposed to be able to do
jean-marc.desperrier> something about it :-)
 
I've certain plans in this area for OpenSSL.  I hope to have most of
it ready for 0.9.8.  As it is right now, it has rather crappy
verification routines, as well as the lookup of certificates (it's
in-memory, and lacks of certain needed features).  No policy checking
(as far as I've been able to see and test), and no support for trees
of certificate chains (i.e. it doesn't support the possibility for any
specific subject to have more than one valid certificate at a time...
 
-- 
Richard Levitte     | http://richard.levitte.org/ | Spannv. 38, I
Levitte Programming | http://www.lp.se/           | S-168 35 Bromma
T: [phone] |                             | SWEDEN
     "Price, performance, quality...  choose the two you like"

------_=_NextPart_001_01C2C08B.31C9A180
Content-Type: text/html
Content-Transfer-Encoding: quoted-printable

<html xmlns:o=3D"urn:schemas-microsoft-com:office:office" =
xmlns:w=3D"urn:schemas-microsoft-com:office:word" =
xmlns=3D"http://www.w3.org/TR/REC-html40">

<head>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Dus-ascii">


<meta name=3DProgId content=3DWord.Document>
<meta name=3DGenerator content=3D"Microsoft Word 10">
<meta name=3DOriginator content=3D"Microsoft Word 10">
<link rel=3DFile-List href=3D"cid:filelist.xml@01C2C061.4EC41830">
<!--[if gte mso 9]><xml>
 <o:OfficeDocumentSettings>
  <o:DoNotRelyOnCSS/>
 </o:OfficeDocumentSettings>
</xml><![endif]--><!--[if gte mso 9]><xml>
 <w:WordDocument>
  <w:View>Normal</w:View>
  <w:SpellingState>Clean</w:SpellingState>
  <w:GrammarState>Clean</w:GrammarState>
  <w:DocumentKind>DocumentEmail</w:DocumentKind>
  <w:EnvelopeVis/>
  <w:Compatibility>
   <w:BreakWrappedTables/>
   <w:SnapToGridInCell/>
   <w:WrapTextWithPunct/>
   <w:UseAsianBreakRules/>
  </w:Compatibility>
  <w:BrowserLevel>MicrosoftInternetExplorer4</w:BrowserLevel>
 </w:WordDocument>
</xml><![endif]-->
<style>
<!--
 /* Style Definitions */
 p.MsoNormal, li.MsoNormal, div.MsoNormal
	{mso-style-parent:"";
	margin:0in;
	margin-bottom:.0001pt;
	mso-pagination:widow-orphan;
	font-size:12.0pt;
	font-family:"Times New Roman";
	mso-fareast-font-family:"Times New Roman";}
a:link, span.MsoHyperlink
	{color:blue;
	text-decoration:underline;
	text-underline:single;}
a:visited, span.MsoHyperlinkFollowed
	{color:purple;
	text-decoration:underline;
	text-underline:single;}
p.MsoPlainText, li.MsoPlainText, div.MsoPlainText
	{margin:0in;
	margin-bottom:.0001pt;
	mso-pagination:widow-orphan;
	font-size:10.0pt;
	font-family:"Courier New";
	mso-fareast-font-family:"Times New Roman";}
span.GramE
	{mso-style-name:"";
	mso-gram-e:yes;}
@page Section1
	{size:8.5in 11.0in;
	margin:1.0in 77.95pt 1.0in 77.95pt;
	mso-header-margin:.5in;
	mso-footer-margin:.5in;
	mso-paper-source:0;}
div.Section1
	{page:Section1;}
-->
</style>
<!--[if gte mso 10]>
<style>
 /* Style Definitions */=20
 table.MsoNormalTable
	{mso-style-name:"Table Normal";
	mso-tstyle-rowband-size:0;
	mso-tstyle-colband-size:0;
	mso-style-noshow:yes;
	mso-style-parent:"";
	mso-padding-alt:0in 5.4pt 0in 5.4pt;
	mso-para-margin:0in;
	mso-para-margin-bottom:.0001pt;
	mso-pagination:widow-orphan;
	font-size:10.0pt;
	font-family:"Times New Roman";}
</style>
<![endif]-->
</head>

<body lang=3DEN-US link=3Dblue vlink=3Dpurple =
style=3D'tab-interval:.5in'>

<div class=3DSection1>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:
10.0pt'>Richard,<o:p></o:p></span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:
10.0pt'>Comment inserted<o:p></o:p></span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:
10.0pt'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:
10.0pt;mso-no-proof:yes'>Roger Younglove, =
CISSP<o:p></o:p></span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:
10.0pt;mso-no-proof:yes'>Principal =
Consultant<o:p></o:p></span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:
10.0pt;mso-no-proof:yes'>NetWorks Group<o:p></o:p></span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
lang=3DFR
style=3D'font-size:10.0pt;mso-ansi-language:FR;mso-no-proof:yes'>O. =
810.225.4800
ex. 2245<o:p></o:p></span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
lang=3DFR
style=3D'font-size:10.0pt;mso-ansi-language:FR;mso-no-proof:yes'>M. =
810.599.0879<o:p></o:p></span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
lang=3DFR
style=3D'font-size:10.0pt;mso-ansi-language:FR;mso-no-proof:yes'>E.
[e-mail]<o:p></o:p></span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:
10.0pt;mso-no-proof:yes'>www.networksgroup.com<o:p></o:p></span></font><=
/p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:
10.0pt;mso-no-proof:yes'><span =
style=3D'mso-spacerun:yes'>&nbsp;</span><o:p></o:p></span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:
10.0pt'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:
10.0pt'>-----Original Message-----<br>
From: Richard Levitte - VMS Whacker [mailto:[e-mail]] <br>
Sent: Friday, January 17, 2003 4:49 PM<br>
To: [e-mail]<br>
Cc: [e-mail]; [e-mail]<br>
Subject: Re: &quot;Basic&quot; path-validation =
question<o:p></o:p></span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:
10.0pt'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:
10.0pt'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:
10.0pt'>In message &lt;[e-mail]&gt; on Fri, 17 Jan =
2003
14:38:46 +0100, Jean-Marc Desperrier =
&lt;[e-mail]&gt;
said:<o:p></o:p></span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:
10.0pt'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:
10.0pt'>jean-marc.desperrier&gt; What is broken is the application, if =
it<o:p></o:p></span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:
10.0pt'>jean-marc.desperrier&gt; *requires* to install both RootCA and =
CA1 in<o:p></o:p></span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:
10.0pt'>jean-marc.desperrier&gt; order to trust =
EE_type1.<o:p></o:p></span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:
10.0pt'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:
10.0pt'>Yet, most software do that, *or* install just RootCA and expect =
to get<o:p></o:p></span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:
10.0pt'>every intermediate CA certificate along with the messages sent =
to it<o:p></o:p></span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:
10.0pt'>(that happens with S/MIME, and many SSL-enabled servers present =
a<o:p></o:p></span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:
10.0pt'>whole chain except for the root itself).<span
style=3D'mso-spacerun:yes'>&nbsp; </span>From a purely PKI point =
of<o:p></o:p></span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:
10.0pt'>view, both methods are broken, all needed certificates should =
be<o:p></o:p></span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:
10.0pt'>retrievable from one or several publically available =
stores...<o:p></o:p></span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:
10.0pt'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:
10.0pt'>jean-marc.desperrier&gt; It should be possible to install only =
CA1 as a<o:p></o:p></span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:
10.0pt'>jean-marc.desperrier&gt; trust anchor, there is no requirement =
in the<o:p></o:p></span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:
10.0pt'>jean-marc.desperrier&gt; path-validation that the trust anchor =
be<o:p></o:p></span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:
10.0pt'>jean-marc.desperrier&gt; =
self-signed.<o:p></o:p></span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:
10.0pt'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:
10.0pt'>Actually, I've heard quite different opinions on that.<span
style=3D'mso-spacerun:yes'>&nbsp; </span>Some =
people<o:p></o:p></span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:
10.0pt'>assume that the trust anchors are self-signed.<span
style=3D'mso-spacerun:yes'>&nbsp; </span>I see no real =
problem<o:p></o:p></span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:
10.0pt'>with that kind of thinking...<span =
style=3D'mso-spacerun:yes'>&nbsp;
</span>If nothing else, you can always set =
up<o:p></o:p></span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:
10.0pt'>your own small CA, certify any other CA you trust with your =
CA's key,<o:p></o:p></span></font></p>

<p class=3DMsoPlainText><span class=3DGramE><font size=3D2 =
face=3D"Courier New"><span
style=3D'font-size:10.0pt'>and</span></font></span> have your CA as =
trust
anchor...<o:p></o:p></p>

<p class=3DMsoPlainText><font size=3D2 color=3Dblack face=3D"Courier =
New"><span
style=3D'font-size:10.0pt;color:black'><o:p>&nbsp;</o:p></span></font></=
p>

<p class=3DMsoPlainText><i style=3D'mso-bidi-font-style:normal'><font =
size=3D2
color=3Dblack face=3D"Courier New"><span =
style=3D'font-size:10.0pt;color:black;
font-style:italic;mso-bidi-font-style:normal'>Roger&gt; Then what you =
have in
affect is a Bridge CA connecting the path of trust between the CAs that =
you
trust. This would not be a trust anchor. It would require agreements =
between
all of your trusted CAs because it would also affect them by extending =
their
individual paths of trust to each other and they may not wish to do =
that.<o:p></o:p></span></font></i></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:
10.0pt'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:
10.0pt'>jean-marc.desperrier&gt; If the application is OpenSSL, you =
were
talking<o:p></o:p></span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:
10.0pt'>jean-marc.desperrier&gt; with someone who is supposed to be =
able to do<o:p></o:p></span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:
10.0pt'>jean-marc.desperrier&gt; something about it =
:-)<o:p></o:p></span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:
10.0pt'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:
10.0pt'>I've certain plans in this area for OpenSSL.<span
style=3D'mso-spacerun:yes'>&nbsp; </span>I hope to have most =
of<o:p></o:p></span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:
10.0pt'>it ready for 0.9.8.<span style=3D'mso-spacerun:yes'>&nbsp; =
</span>As it
is right now, it has rather crappy<o:p></o:p></span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:
10.0pt'>verification routines, as well as the lookup of certificates =
(it's<o:p></o:p></span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:
10.0pt'>in-memory, and lacks of certain needed features).<span
style=3D'mso-spacerun:yes'>&nbsp; </span>No policy =
checking<o:p></o:p></span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:
10.0pt'>(as far as I've been able to see and test), and no support for =
trees<o:p></o:p></span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:
10.0pt'>of certificate chains (i.e. it doesn't support the possibility =
for any<o:p></o:p></span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:
10.0pt'>specific subject to have more than one valid certificate at a =
time...<o:p></o:p></span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:
10.0pt'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:
10.0pt'>-- <o:p></o:p></span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:
10.0pt'>Richard Levitte<span =
style=3D'mso-spacerun:yes'>&nbsp;&nbsp;&nbsp;&nbsp;
</span>| http://richard.levitte.org/ | Spannv. 38, =
I<o:p></o:p></span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:
10.0pt'>Levitte Programming | http://www.lp.se/<span
style=3D'mso-spacerun:yes'>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp;
</span>| S-168 35 Bromma<o:p></o:p></span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:
10.0pt'>T: [phone] |<span
style=3D'mso-spacerun:yes'>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
</span>| SWEDEN<o:p></o:p></span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:
10.0pt'><span style=3D'mso-spacerun:yes'>&nbsp;&nbsp;&nbsp;&nbsp;
</span>&quot;Price, performance, quality...<span
style=3D'mso-spacerun:yes'>&nbsp; </span>choose the two you =
like&quot;<o:p></o:p></span></font></p>

</div>

</body>

</html>

------_=_NextPart_001_01C2C08B.31C9A180--


Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h0LMYRl12956 for ietf-pkix-bks; Tue, 21 Jan 2003 14:34:27 -0800 (PST)
Received: from woodstock.binhost.com (woodstock.binhost.com [207.228.252.5]) by above.proper.com (8.11.6/8.11.3) with SMTP id h0LMYQo12951 for <[e-mail]>; Tue, 21 Jan 2003 14:34:26 -0800 (PST)
Received: (qmail 10775 invoked from network); 21 Jan 2003 22:34:01 -0000
Received: from unknown (HELO Russ-Laptop.vigilsec.com) (141.156.47.100) by woodstock.binhost.com with SMTP; 21 Jan 2003 22:34:01 -0000
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9
Date: Tue, 21 Jan 2003 17:34:25 -0500
To: [e-mail], [e-mail]
From: Russ Housley <[e-mail]>
Subject: STRAWPOLL:SCVP
Cc: [e-mail]
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>


Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h0LMHPa12365 for ietf-pkix-bks; Tue, 21 Jan 2003 14:17:25 -0800 (PST)
Received: from postmark.nist.gov (pullyou.nist.gov [129.6.16.93]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h0LMHNo12361 for <[e-mail]>; Tue, 21 Jan 2003 14:17:23 -0800 (PST)
Received: from calendar.nist.gov (calendar-ether.nist.gov [129.6.16.10]) by postmark.nist.gov (8.12.5/8.12.5) with ESMTP id h0LMH3pf003285 for <[e-mail]>; Tue, 21 Jan 2003 17:17:04 -0500 (EST)
Received: from calendar.nist.gov (localhost [127.0.0.1]) by calendar.nist.gov (8.12.2/8.12.2) with ESMTP id h0LMH3Op002746 for <[e-mail]>; Tue, 21 Jan 2003 17:17:03 -0500 (EST)
Received: (from nobody@localhost) by calendar.nist.gov (8.12.2/8.12.2/Submit) id h0LMH3V6002745 for [e-mail]; Tue, 21 Jan 2003 17:17:03 -0500 (EST)
X-Authentication-Warning: calendar.nist.gov: nobody set sender to [e-mail] using -f
Received: from 141.156.185.88 ( [141.156.185.88]) as user [e-mail] by imp.nist.gov with HTTP; Tue, 21 Jan 2003 17:17:03 -0500
Message-ID: <[e-mail]>
Date: Tue, 21 Jan 2003 17:17:03 -0500
From: [e-mail]
To: [e-mail]
Subject: Strawpoll for DPD/DPV protocols
MIME-Version: 1.0
Content-Type: text/plain
Content-Transfer-Encoding: 8bit
User-Agent: Internet Messaging Program (IMP) 2.3.7-cvs
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Folks,

As discussed at the last meeting and on the list, it is imperative that the 
PKIX working group progress a single DPD/DPV protocol.  Three strong proposals 
are on the table (listed in alphabetical order):

*  Certificate Validation Protocol (CVP), available at 
<http://www.ietf.org/internet-drafts/draft-ietf-pkix-ocsp-dpvdpd-00.txt>;
*  DPV and DPD over OCSP, available at <http://www.ietf.org/internet-
drafts/draft-ietf-pkix-ocsp-dpvdpd-00.txt>; and
*  Simple Certificate Validation Protocol (SCVP), available at 
<http://www.ietf.org/internet-drafts/draft-ietf-pkix-scvp-11.txt>.

The working groups needs to make the difficult decision, and select the one 
and only PKIX protocol for DPD/DPV.  Our primary guide in the development of a 
DPD/DPV protocol is the requirements document RFC 3379.  Each of the editing 
teams has submitted a "compliance matrix" describing how their protocol 
satisfies requirements specified in 3379.  I want to encourage each of you to 
take this decision seriously.  The editors have all invested a great deal of 
time and effort in these documents, and we owe them that much.

I am asking that each of you review, at a minimum, the compliance matrix 
submitted by each team *before* voting.  The compliance matrix was a major 
pain for the editors and is our best yardstick for 3379 compliance.  Better 
yet, if you haven't reviewed the latest draft for one of the specifications, 
please take this opportunity to do so as well!  Informed voters make a better 
strawpoll result...

Since some of the compliance matrices were submitted recently, I would like to 
hold the voting open through Monday, January 27.  (Hopefully, this is enough 
time to get informed if you aren't already!)

To simplify the task for the co-chairs, I would appreciate if the Subject line 
could specify both the strawpoll and vote, as in STRAWPOLL:xxx, where xxx 
is "CVP", "OCSP", or "SCVP".  (As I recall, this worked nicely for previous 
strawpolls.)

Thanks,

Tim Polk


Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h0LKvWu10761 for ietf-pkix-bks; Tue, 21 Jan 2003 12:57:32 -0800 (PST)
Received: from mtiwmhc12.worldnet.att.net (mtiwmhc12.worldnet.att.net [204.127.131.116]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h0LKvVo10757 for <[e-mail]>; Tue, 21 Jan 2003 12:57:31 -0800 (PST)
Received: from Chokhani ([12.91.131.197]) by mtiwmhc12.worldnet.att.net (InterMail vM.5.01.05.12 201-253-122-126-112-20020820) with ESMTP id <20030121205727.QGXA12483.mtiwmhc12.worldnet.att.net@Chokhani> for <[e-mail]>; Tue, 21 Jan 2003 20:57:27 +0000
From: "Santosh Chokhani" <[e-mail]>
To: <[e-mail]>
Subject: RE: RFC 2527 Revision
Date: Tue, 21 Jan 2003 15:58:00 -0500
Message-ID: <007e01c2c18f$c8d03e90$40a35b0c@Chokhani>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook, Build 10.0.4510
Importance: Normal
In-Reply-To: <3E2D8599.20257.1A05C1B@localhost>
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

All:

I have a briefing we presented at last year's RSA conference that gives a
summary of differences.

Rather than inundate the list, I will send this briefing to Stefan.

-----Original Message-----
From: [e-mail] [mailto:[e-mail]] On
Behalf Of Stefan Kelm
Sent: Tuesday, January 21, 2003 11:39 AM
To: [e-mail]
Subject: Re: RFC 2527 Revision



Dear List,

> I have a question on the status of the CP/CPS drafts.
> There was a draft written for CP/CPS dated January 3rd, 2002, by 
> Chokhani et al. Has that draft been approved as a new RFC to replace 
> 2527 ??  Can any one shed some light on the status of the document??  
> Thanks, Vijay

on a similar note, is there an overview on the main differences between 
2527 and draft-01? I couldn't find anything in the archives nor in the 
draft.  

Cheers,

	Stefan.

-------------------------------------------------------
Dipl.-Inform. Stefan Kelm
Security Consultant

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

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



Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h0LGcl803081 for ietf-pkix-bks; Tue, 21 Jan 2003 08:38:47 -0800 (PST)
Received: from rom.antech.de (dns.antech.de [194.45.12.2]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h0LGcjo03074 for <[e-mail]>; Tue, 21 Jan 2003 08:38:46 -0800 (PST)
Received: from Serbius.secorvo.de (kasiski.secorvo.de [194.45.12.203]) by rom.antech.de (8.9.3/8.9.3) with ESMTP id SAA21948 for <[e-mail]>; Tue, 21 Jan 2003 18:25:29 +0100
From: "Stefan Kelm" <[e-mail]>
Organization: Secorvo Security Consulting GmbH
To: [e-mail]
Date: Tue, 21 Jan 2003 17:38:33 +0100
MIME-Version: 1.0
Subject: Re: RFC 2527 Revision
Reply-to: [e-mail]
Message-ID: <3E2D8599.20257.1A05C1B@localhost>
In-reply-to: <[e-mail]>
X-mailer: Pegasus Mail for Windows (v4.02)
Content-type: text/plain; charset=US-ASCII
Content-transfer-encoding: 7BIT
Content-description: Mail message body
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Dear List,

> I have a question on the status of the CP/CPS drafts.
> There was a draft written for CP/CPS dated January 3rd, 2002, by Chokhani
> et al. Has that draft been approved as a new RFC to replace 2527 ??  Can
> any one shed some light on the status of the document??  Thanks, Vijay

on a similar note, is there an overview on the main differences between 
2527 and draft-01? I couldn't find anything in the archives nor in the 
draft.  

Cheers,

	Stefan.

-------------------------------------------------------
Dipl.-Inform. Stefan Kelm
Security Consultant

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

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



Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h0LCuDO22285 for ietf-pkix-bks; Tue, 21 Jan 2003 04:56:13 -0800 (PST)
Received: from ietf.org (odin.ietf.org [132.151.1.176]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h0LCuCo22281 for <[e-mail]>; Tue, 21 Jan 2003 04:56:12 -0800 (PST)
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA27696; Tue, 21 Jan 2003 07:52:45 -0500 (EST)
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-cvp-02.txt
Date: Tue, 21 Jan 2003 07:52:45 -0500
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

--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 Validation Protocol
	Author(s)	: D. Pinkas
	Filename	: draft-ietf-pkix-cvp-02.txt
	Pages		: 31
	Date		: 2003-1-20
	
This document defines a protocol called Certificate Validation Protocol 
(CVP) that can be used to:
(1) query the validation or discovery policies supported by 
a CVP server, 
(2) validate one or more public key certificates according to a 
single validation policy, or
(3) obtain one or more certification paths for one or more certificates 
according to a single discovery policy.

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

To remove yourself from the IETF Announcement list, send a message to 
ietf-announce-request with the word unsubscribe in the body of the message.

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-cvp-02.txt".

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


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

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

--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"

--OtherAccess
Content-Type: Message/External-body;
	access-type="mail-server";
	server="[e-mail]"

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

ENCODING mime
FILE /internet-drafts/draft-ietf-pkix-cvp-02.txt

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

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

--OtherAccess--

--NextPart--




Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h0KJWZJ24607 for ietf-pkix-bks; Mon, 20 Jan 2003 11:32:35 -0800 (PST)
Received: from mail3.microsoft.com (mail3.microsoft.com [131.107.3.123]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h0KJWXo24603 for <[e-mail]>; Mon, 20 Jan 2003 11:32:33 -0800 (PST)
Received: from INET-VRS-03.redmond.corp.microsoft.com ([157.54.5.27]) by mail3.microsoft.com with Microsoft SMTPSVC(5.0.2195.5600); Mon, 20 Jan 2003 11:32:30 -0800
Received: from 157.54.8.23 by INET-VRS-03.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Mon, 20 Jan 2003 11:32:30 -0800
Received: from red-imc-04.redmond.corp.microsoft.com ([157.54.2.168]) by inet-hub-01.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.5600); Mon, 20 Jan 2003 11:32:30 -0800
Received: from WIN-IMC-02.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.84]) by red-imc-04.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.5600); Mon, 20 Jan 2003 11:32:30 -0800
Received: from WIN-MSG-01.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.52]) by WIN-IMC-02.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(6.0.3718.0); Mon, 20 Jan 2003 11:32:29 -0800
X-MimeOLE: Produced By Microsoft Exchange V6.5.6830.0
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"
Subject: RE: Best rollover practise
Date: Mon, 20 Jan 2003 11:32:29 -0800
Message-ID: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: Best rollover practise
thread-index: AcLAmb0I/8ejOnBnSLKEP+/VQ4w6sQAHmHeg
From: "Trevor Freeman" <[e-mail]>
To: "Joel S. Kazin" <[e-mail]>, "Haaino Beljaars" <[e-mail]>, <[e-mail]>
X-OriginalArrivalTime: 20 Jan 2003 19:32:29.0889 (UTC) FILETIME=[ABD1AB10:01C2C0BA]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id h0KJWYo24604
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

It always amazes me to see views on basic issues like root rollover
where there is still little consensus.

Q1. Theoretically you can issue either a 25 or a 50 day certificate.
There is certainly no commercial product consensus on whether you roll
your root first then issue the 50 day certificate or issue the
certificate and then roll your root.

Q2. Theoretically yes, but again it's up to the product.

Q3. Depends on if you roll your root key as well as your certificate. IN
both cases you have from the time you roll your root till the old root
expires to distribute the new root. 

Trevor

-----Original Message-----
From: Joel S. Kazin [mailto:[e-mail]] 
Sent: Monday, January 20, 2003 7:23 AM
To: Haaino Beljaars; [e-mail]
Subject: Re: Best rollover practise


At 08:31 PM 1/19/2003 +0100, Haaino Beljaars wrote:

>Hi,
>
>Hope somebody can tell me more about 'rollover' practises.
>
>I have the following example: I have a Root CA which has a validity
time of
>100 days, which issues directly to end-users. The end-users get an
end-user
>certificate which has a validity time of 50 days (this is no be change
the
>half of the Root CA validity time). During the life time of the Root CA
an
>end-user can receive a maximum of two end-user certificates.
>
>My questions are:
>* if I issue an end-user certificate on the 25th day of the life time
of the
>Root CA, and the end-user comes back for an update of his certificate
(on
>day 75), should I issue an end-user certificate of 50 days or 25 days?

25 days.

>* May I issue certificates which have a longer life time then the
issuing CA
>if I know that at the end of the life time of the CA I'll perform an
>rollover on the CA?

No.

>* An other scenario could be that I already rollover the issuing CA on
day
>50 of the Root CA lifetime, and start issuing end-user certificates
from
>that CA instead. But then I have 2 CA which seem to the outside world
as the
>same.

You will have two CA certificates. Commercial products, i.e., Entrust,
have 
the old CA certificate signed by the private key associated with the new
CA 
Certificate.


>Any suggestions?
>
>Best regards,
>Haaino

Senior Consultant
Technical Consulting Practice, Northeast Region
Schlumberger Network Solutions

[e-mail]
www.slb.com/nws

35 Waterview Blvd.
Suite 210
Parsippany, NJ 07054-1200
USA

Phone  [phone]
Mobile  [phone]



Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h0KHDVX20541 for ietf-pkix-bks; Mon, 20 Jan 2003 09:13:31 -0800 (PST)
Received: from mailg.telia.com (mailg.telia.com [194.22.194.26]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h0KHDUo20537 for <[e-mail]>; Mon, 20 Jan 2003 09:13:30 -0800 (PST)
Received: from arport (h127n2fls31o1122.telia.com [212.181.142.127]) by mailg.telia.com (8.12.5/8.12.5) with SMTP id h0KHDV9d013699; Mon, 20 Jan 2003 18:13:31 +0100 (CET)
X-Original-Recipient: [e-mail]
Message-ID: <004b01c2c0a6$efe7b880$0500a8c0@arport>
From: "Anders Rundgren" <[e-mail]>
To: "Richard Levitte - VMS Whacker" <[e-mail]>
Cc: <[e-mail]>
References: <002101c2c06f$676facb0$0500a8c0@arport>            <[e-mail]>            <000e01c2c097$bf53cc90$0500a8c0@arport> <[e-mail]>
Subject: Re: "Basic" path-validation question
Date: Mon, 20 Jan 2003 18:11:13 +0100
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.50.4133.2400
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Richard,

<snip>
>> The "intent" is rather to send the de-funct X.500
>> global naming-system where it belongs, acknowledged
>> by a quite a few people of this list...
>> The mechanism works as an additional layer on top of
>> RFC3280.

>Well, in that case, you're going away from X.509 rather sharply.

Hum, ISO have had 15 years to establish a working global registry...
After a while, ISO gave in and added DCs based on DNS. 
Still this is both a very little used "feature" in certificates, as well as
a de-facto non-standard solution, as URIs are used as identifiers by
the rest of the IT-industry.

In the meantime [more or less] local name-spaces have been
successfully established.  The Swedish ID-certificate is an example.
I doubt that they will change that into using DCs.  Using the proposed
mechanism they will never have to either as it augments certificates
with a global URI name-space [for those situations which need it].

So the question really boils down to: How is PKI going to achieve a
global name-space based on DNS [=the only working naming-system]?
That there are "standards" for that is no guarantee for this to happen IMO.
Life is complicated :-|

<snip>

Anders




Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h0KHBfR20515 for ietf-pkix-bks; Mon, 20 Jan 2003 09:11:41 -0800 (PST)
Received: from email.certplus.com ([195.101.88.80]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h0KHBdo20511 for <[e-mail]>; Mon, 20 Jan 2003 09:11:39 -0800 (PST)
Received: from carbone.certplus.com (facteur.certplus.com [172.16.1.81]) by email.certplus.com (8.12.2+Sun/8.12.2) with ESMTP id h0KHBcft018047; Mon, 20 Jan 2003 18:11:38 +0100 (CET)
Received: from certplus.com ([192.168.212.166]) by carbone.certplus.com with Microsoft SMTPSVC(5.0.2195.2966); Mon, 20 Jan 2003 18:11:39 +0100
Message-ID: <[e-mail]>
Date: Mon, 20 Jan 2003 18:15:12 +0100
From: Jean-Marc Desperrier <[e-mail]>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.3b) Gecko/20030105
X-Accept-Language: ja, en-us, en, fr
MIME-Version: 1.0
To: [e-mail]
CC: Roger Younglove <[e-mail]>, "'Richard Levitte - VMS Whacker'" <[e-mail]>
Subject: Re: "Basic" path-validation question
References: <[e-mail]>
In-Reply-To: <[e-mail]>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
X-OriginalArrivalTime: 20 Jan 2003 17:11:39.0718 (UTC) FILETIME=[FF1FE660:01C2C0A6]
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Roger Younglove wrote in answer to message from Richard Levitte :
> jean-marc.desperrier> It should be possible to install only CA1 as a
> jean-marc.desperrier> trust anchor, there is no requirement in the
> jean-marc.desperrier> path-validation that the trust anchor be
> jean-marc.desperrier> self-signed.
> 
> Actually, I've heard quite different opinions on that.  Some people
> assume that the trust anchors are self-signed.  I see no real problem
> with that kind of thinking...  

I've been rereading RFC3280 about that, we are both right, the trust 
anchor does not need to be self-signed, but there is also no requirement 
on the application to accept any another form :

6.1.1  Inputs
(d)  trust anchor information, describing a CA that serves as a
       trust anchor for the certification path.  The trust anchor
       information includes:

          (1)  the trusted issuer name,

          (2)  the trusted public key algorithm,

          (3)  the trusted public key, and

          (4)  optionally, the trusted public key parameters associated
          with the public key.

       The trust anchor information may be provided to the path
       processing procedure in the form of a self-signed certificate.
       The trusted anchor information is trusted because it was delivered
       to the path processing procedure by some trustworthy out-of-band
       procedure.

So the trust anchor can be provided in any form that is seen fit, and 
might not even be a X509 certificate.
But the text does require that an application accepts trust anchors in 
any specific form, only suggesting self-signed certificates.
So as it's the one form that's explicity described, it's no surprise 
it's often the only one that is supported.

> If nothing else, you can always set up
> your own small CA, certify any other CA you trust with your CA's key,
> and have your CA as trust anchor...
> 
> / Roger> Then what you have in affect is a Bridge CA connecting the path 
> of trust between the CAs that you trust. This would not be a trust 
> anchor. It would require agreements between all of your trusted CAs 
> because it would also affect them by extending their individual paths of 
> trust to each other and they may not wish to do that. /

The trust anchor is anything that is provided as input to the validation 
algorithm, using OOB mecanism.
Even if you use one that looks like a bridge CA, it is not distributed 
on-line, so it does not affect their path of trust outside of your 
private use.



Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h0KFvHt15934 for ietf-pkix-bks; Mon, 20 Jan 2003 07:57:17 -0800 (PST)
Received: from nic.lp.se (nic.lp.se [212.247.5.91]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h0KFvFo15930 for <[e-mail]>; Mon, 20 Jan 2003 07:57:15 -0800 (PST)
Received: from localhost (217.215.93.181) by nic.lp.se (MX V5.3 VnHj) with ESMTP; Mon, 20 Jan 2003 16:55:34 +0100
Date: Mon, 20 Jan 2003 16:52:53 +0100 (CET)
Message-ID: <[e-mail]>
To: [e-mail]
CC: [e-mail]
Subject: Re: "Basic" path-validation question
From: Richard Levitte - VMS Whacker <[e-mail]>
In-Reply-To: <000e01c2c097$bf53cc90$0500a8c0@arport>
References: <002101c2c06f$676facb0$0500a8c0@arport> <[e-mail]> <000e01c2c097$bf53cc90$0500a8c0@arport>
X-URL: http://www.lp.se/
X-Waved: dead chicken, GNU emacs 21.2.2, Mew version 3.1
X-Mew: See http://www.mew.org/
X-Mailer: Mew version 3.1 on Emacs 21.2 / Mule 5.0 (SAKAKI)
MIME-Version: 1.0
Content-Type: Text/Plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

In message <000e01c2c097$bf53cc90$0500a8c0@arport> on Mon, 20 Jan 2003 16:22:30 +0100, "Anders Rundgren" <[e-mail]> said:

anders.rundgren> >Did I understand what you said correctly?
anders.rundgren> 
anders.rundgren> Well, the intention was just a single CA-hierarchy

OK.

anders.rundgren> >That sounds just like reinventing policies and name
anders.rundgren> >constraints. 
anders.rundgren> 
anders.rundgren> No, policies and name-constraints work _within_ a CA
anders.rundgren> (hierachy).

I'd like to argue that (eh, the implication that it only works within
a hierarchy), but I recognise that it takes some work (i.e. a bit of
reading through long documents with varied legal status).

anders.rundgren> This name-space-thing is _between_fully_ idependent
anders.rundgren> CAs that do not even know the others' existance.
anders.rundgren> This allows a "good" CA to be protected from a "bad"
anders.rundgren> CA infringing on the good CA's name-space.

If I do what I'd ideally like to do, using my own small CA (which,
contrary to what some seem to think, is not the same as a bridge CA,
at least as far as I understand them) to certify, for my own purposes
only, other CAs, then in each such certification, I can also say that
I only accept certificates signed by them within specific name trees.
That's one way to use name constraints.

I realise that what I would do isn't something the average user would
do.  In effect, the way root CAs are handled in browsers today is an
expression of complete trust, by having no restrictions whatsoever in
the hierarchy below them.

Let me ask you, exactly where would that name-space extension be?

anders.rundgren> Why would anybody accept a "bad" CA? Well:
anders.rundgren> - How can you have any opnion about a company CA on
anders.rundgren>   the other side of the globe?

Depends.  Do I do business with them?  Then I believe that I will
sooner or later get to know them to a certain part.

anders.rundgren> - Do you have any option but to accept their
anders.rundgren>   credentials if you are going to do business with
anders.rundgren>   them?

Perhaps not.  Also, I might have several levels of acceptance, or to
get back to that, trust.  If we're talking about certification (which
I assume we are), I trust they are running a CA for their own
purposes, or this point is moot.  If they do, what stops me from
signing a certificate for their CA, while expressing very little
trust, through policy mappings for example.

anders.rundgren> <PolicyExtensionRant>
anders.rundgren> In the type of scenario mentioned above I don't see
anders.rundgren> much use of policy-extensions as they cannot be
anders.rundgren> verified, and in local scenarios, policy should
anders.rundgren> already be "implicit", "known" etc.  which in my
anders.rundgren> opinion renders this a "rather" overrated mechanism.
anders.rundgren> A quick look on my Thawt web-server path also
anders.rundgren> indicated the total absence of any "policyjunk"-
anders.rundgren> extensions.
anders.rundgren> </PolicyExtensionRant>

Sure, Thawte has no policies.  From where I stand, that means they
trust anything (like having an anyPolicy policy in the certificate).

Now, granted, there seems to be no way, today, to express in popular
software what restrictions you want to put on different CAs, either
policy-wise or name-wise (or in any other way).  The only way that I
know is to do what I'm going to, have your own CA, and do one-way
certification with all the restrictions or freedoms that you'd like.

anders.rundgren> The "intent" is rather to send the de-funct X.500
anders.rundgren> global naming-system where it belongs, acknowledged
anders.rundgren> by a quite a few people of this list...
anders.rundgren> The mechanism works as an additional layer on top of
anders.rundgren> RFC3280.

Well, in that case, you're going away from X.509 rather sharply.
Perhaps it would be better to look at something else, rather than
further obfuscating something that seems to be obfuscated for a large
number of people already?  Then again, that wouldn't work with today's
software...

No offence meant, BTW...

-- 
Richard Levitte     | http://richard.levitte.org/ | Spannv. 38, I
Levitte Programming | http://www.lp.se/           | S-168 35 Bromma
T: [phone] |                             | SWEDEN
     "Price, performance, quality...  choose the two you like"


Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h0KFTfn15304 for ietf-pkix-bks; Mon, 20 Jan 2003 07:29:41 -0800 (PST)
Received: from mail.slb.com (nammta01.sugar-land.nam.slb.com [163.188.150.130]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h0KFTdo15300 for <[e-mail]>; Mon, 20 Jan 2003 07:29:39 -0800 (PST)
Received: from conversion-daemon.nammta01.sugar-land.nam.slb.com by nammta01.sugar-land.nam.slb.com (iPlanet Messaging Server 5.2 HotFix 1.06 (built Nov 15 2002)) id <[e-mail]> for [e-mail]; Mon, 20 Jan 2003 15:27:08 +0000 (GMT)
Received: from namems01.sugar-land.oilfield.slb.com (namems01.sugar-land.oilfield.slb.com [163.188.150.131]) by nammta01.sugar-land.nam.slb.com (iPlanet Messaging Server 5.2 HotFix 1.06 (built Nov 15 2002)) with ESMTP id <[e-mail]> for [e-mail]; Mon, 20 Jan 2003 15:26:31 +0000 (GMT)
Received: from conversion-daemon.namems01.sugar-land.oilfield.slb.com by namems01.sugar-land.oilfield.slb.com (iPlanet Messaging Server 5.1 HotFix 1.7 (built Nov  1 2002)) id <[e-mail]> for [e-mail]; Mon, 20 Jan 2003 15:26:07 +0000 (GMT)
Received: from SCHLUMBE-OITRVU.parsippany.sns.slb.com (vpnpool298.houston.sinet.slb.com [163.188.125.42]) by namems01.sugar-land.oilfield.slb.com (iPlanet Messaging Server 5.1 HotFix 1.7 (built Nov  1 2002)) with ESMTP id <[e-mail]>; Mon, 20 Jan 2003 15:23:16 +0000 (GMT)
Content-return: prohibited
Date: Mon, 20 Jan 2003 10:23:14 -0500
From: "Joel S. Kazin" <[e-mail]>
Subject: Re: Best rollover practise
In-reply-to: <000b01c2bff1$6654eb20$0201a8c0@windowsxp>
X-Sender: jkazin@163.188.150.131
To: Haaino Beljaars <[e-mail]>, [e-mail]
Message-id: <5.1.1.1.2.20030120101837.00aa6208@163.188.150.131>
MIME-version: 1.0
X-Mailer: QUALCOMM Windows Eudora Version 5.1.1
Content-type: text/plain; charset=us-ascii; format=flowed
Content-transfer-encoding: 7BIT
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

At 08:31 PM 1/19/2003 +0100, Haaino Beljaars wrote:

>Hi,
>
>Hope somebody can tell me more about 'rollover' practises.
>
>I have the following example: I have a Root CA which has a validity time of
>100 days, which issues directly to end-users. The end-users get an end-user
>certificate which has a validity time of 50 days (this is no be change the
>half of the Root CA validity time). During the life time of the Root CA an
>end-user can receive a maximum of two end-user certificates.
>
>My questions are:
>* if I issue an end-user certificate on the 25th day of the life time of the
>Root CA, and the end-user comes back for an update of his certificate (on
>day 75), should I issue an end-user certificate of 50 days or 25 days?

25 days.

>* May I issue certificates which have a longer life time then the issuing CA
>if I know that at the end of the life time of the CA I'll perform an
>rollover on the CA?

No.

>* An other scenario could be that I already rollover the issuing CA on day
>50 of the Root CA lifetime, and start issuing end-user certificates from
>that CA instead. But then I have 2 CA which seem to the outside world as the
>same.

You will have two CA certificates. Commercial products, i.e., Entrust, have 
the old CA certificate signed by the private key associated with the new CA 
Certificate.


>Any suggestions?
>
>Best regards,
>Haaino

Senior Consultant
Technical Consulting Practice, Northeast Region
Schlumberger Network Solutions

[e-mail]
www.slb.com/nws

35 Waterview Blvd.
Suite 210
Parsippany, NJ 07054-1200
USA

Phone  [phone]
Mobile  [phone]



Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h0KFOmG15188 for ietf-pkix-bks; Mon, 20 Jan 2003 07:24:48 -0800 (PST)
Received: from mailg.telia.com (mailg.telia.com [194.22.194.26]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h0KFOlo15183 for <[e-mail]>; Mon, 20 Jan 2003 07:24:47 -0800 (PST)
Received: from arport (h127n2fls31o1122.telia.com [212.181.142.127]) by mailg.telia.com (8.12.5/8.12.5) with SMTP id h0KFOl9d019793; Mon, 20 Jan 2003 16:24:47 +0100 (CET)
X-Original-Recipient: [e-mail]
Message-ID: <000e01c2c097$bf53cc90$0500a8c0@arport>
From: "Anders Rundgren" <[e-mail]>
To: "Richard Levitte - VMS Whacker" <[e-mail]>
Cc: <[e-mail]>
References: <003801c2bed3$bbcd5c50$0500a8c0@arport>            <[e-mail]>            <002101c2c06f$676facb0$0500a8c0@arport> <[e-mail]>
Subject: Re: "Basic" path-validation question
Date: Mon, 20 Jan 2003 16:22:30 +0100
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.50.4133.2400
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Richard,

>> The point of having a root-certificate according to the sketch I
>> posted, should be that the root is supposed to be long-lived (using
>> a longer key maybe) compared to sub-CAs which should make
>> sub-CA renewals somewhat easier (?) for RPs to handle.  Right?

>Usually, the point of installing any CA certificate is that one would
>trust it and the hierarchy below it...

Sure, but that does not answer the question I put.  I.e. the "value"
of a root-subCA arrangement.

<snip>

>Did I understand what you said correctly?

Well, the intention was just a single CA-hierarchy

>> To make this somewhat clearer: I'm plotting with a scheme (I-D),
>> where a trust administrator must explicitly "accept" a CA that
>> has a "trust-store" mark as a part of an extension mechanism.
>> The extension mechanism also manages name-spaces,  by adding a
>> new dimension (and control) to the name-space embraced by EEs,
>> allowing either "Sharing" or "Galvanic isolation" between CAs.

>That sounds just like reinventing policies and name constraints.

No, policies and name-constraints work _within_ a CA (hierachy).

This name-space-thing is _between_fully_ idependent CAs that
do not even know the others' existance.  This allows a "good"
CA to be protected from a "bad" CA infringing on the good CA's
name-space.  Why would anybody accept a "bad" CA? Well:
- How can you have any opnion about a company CA on the
  other side of the globe?
- Do you have any option but to accept their credentials if you
  are going to do business with them?

<PolicyExtensionRant>
In the type of scenario mentioned above I don't see much use of
policy-extensions as they cannot be verified, and in local scenarios,
policy should already be "implicit", "known" etc.  which in my
opinion renders this a "rather" overrated mechanism.  A quick look
on my Thawt web-server path also indicated the total absence of any
"policyjunk"-extensions.
</PolicyExtensionRant>

>I can only see confusion out of that, since people will then wonder what
>to use, if one should use differemt mechanism in different domains,
>and what happens if both mechanisms to do the same thing are used in
>the same certificate.  I fear it will just send X.509 and the
>corresponding RFCs down the path of uselessness...

The "intent" is rather to send the de-funct X.500 global naming-system
where it belongs, acknowledged by a quite a few people of this list...
The mechanism works as an additional layer on top of RFC3280.

>Then again, perhaps I misunderstand what you're after...

To some extent yes.  But, e-mail has its limitations and PKI
is very complex.

Anders




Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h0KDvI309395 for ietf-pkix-bks; Mon, 20 Jan 2003 05:57:18 -0800 (PST)
Received: from nic.lp.se (nic.lp.se [212.247.5.91]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h0KDvGo09391 for <[e-mail]>; Mon, 20 Jan 2003 05:57:16 -0800 (PST)
Received: from localhost (217.215.93.181) by nic.lp.se (MX V5.3 VnHj) with ESMTP; Mon, 20 Jan 2003 14:55:23 +0100
Date: Mon, 20 Jan 2003 14:52:43 +0100 (CET)
Message-ID: <[e-mail]>
To: [e-mail]
CC: [e-mail], [e-mail]
Subject: Re: "Basic" path-validation question
From: Richard Levitte - VMS Whacker <[e-mail]>
In-Reply-To: <002101c2c06f$676facb0$0500a8c0@arport>
References: <003801c2bed3$bbcd5c50$0500a8c0@arport> <[e-mail]> <002101c2c06f$676facb0$0500a8c0@arport>
X-URL: http://www.lp.se/
X-Waved: dead chicken, GNU emacs 21.2.2, Mew version 3.1
X-Mew: See http://www.mew.org/
MIME-Version: 1.0
Content-Type: Text/Plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
X-Mailer: Mew version 3.1 on Emacs 21.2 / Mule 5.0 (SAKAKI)
Content-Type: Text/Plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

In message <002101c2c06f$676facb0$0500a8c0@arport> on Mon, 20 Jan 2003 11:33:35 +0100, "Anders Rundgren" <[e-mail]> said:

anders.rundgren> The point of having a root-certificate according to the sketch I
anders.rundgren> posted, should be that the root is supposed to be long-lived (using
anders.rundgren> a longer key maybe) compared to sub-CAs which should make
anders.rundgren> sub-CA renewals somewhat easier (?) for RPs to handle.  Right?

Usually, the point of installing any CA certificate is that one would
trust it and the hierachy below it...

anders.rundgren> Or is the only really valid argument for have a root like the one
anders.rundgren> shown, is that multiple more or less independent CAs can be
anders.rundgren> "trusted" with just one RP "install" procedure.

It wasn't apparent that the diagram you showed was of more or less
independent CAs.  It could as well have been a hierarchy that you can
trust as a single entity (as long as you can verify a path from an EE
cert back to the root).

So, it sounds like you have a number of independent CAs, and you want
them to be under some kind of umbrella structure.  I believe that most
PKI people would call that "cross-certification", and that the root is
another independent CA that has expressed trust in the CAs you want to
have under that umbrella by cross-certifying (possibly just one-way,
is there a more proper term for that?), with policy mappings to
express the kind of trust to put into each of those CAs.  And in that
case, it's perfectly valid to have the root as trust anchor.

Did I understand what you said correctly?

anders.rundgren> To make this somewhat clearer: I'm plotting with a scheme (I-D),
anders.rundgren> where a trust administrator must explicitly "accept" a CA that
anders.rundgren> has a "trust-store" mark as a part of an extension mechanism.
anders.rundgren> The extension mechanism also manages name-spaces,  by adding a
anders.rundgren> new dimension (and control) to the name-space embraced by EEs,
anders.rundgren> allowing either "Sharing" or "Galvanic isolation" between CAs.

That sounds just like reinventing policies and name constraints.  I
can only see confusion out of that, since people will then wonder what
to use, if one should use differemt mechanism in different domains,
and what happens if both mechanisms to do the same thing are used in
the same certificate.  I fear it will just send X.509 and the
corresponding RFCs down the path of uselessness...

Then again, perhaps I misunderstand what you're after...

-- 
Richard Levitte     | http://richard.levitte.org/ | Spannv. 38, I
Levitte Programming | http://www.lp.se/           | S-168 35 Bromma
T: [phone] |                             | SWEDEN
     "Price, performance, quality...  choose the two you like"


Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h0KDqfg09344 for ietf-pkix-bks; Mon, 20 Jan 2003 05:52:41 -0800 (PST)
Received: from hubie.hubbardind.com (mail.hubbardsupply.com [65.245.100.65]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h0KDqdo09340 for <[e-mail]>; Mon, 20 Jan 2003 05:52:39 -0800 (PST)
Received: by HUBIE.hubbardsupply.com with Internet Mail Service (5.5.2653.19) id <Y0ST05N1>; Mon, 20 Jan 2003 08:52:40 -0500
Message-ID: <[e-mail]>
From: Roger Younglove <[e-mail]>
To: "'Richard Levitte - VMS Whacker'" <[e-mail]>
Cc: [e-mail]
Subject: RE: "Basic" path-validation question
Date: Mon, 20 Jan 2003 08:52:38 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C2C08B.31C9A180"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

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

------_=_NextPart_001_01C2C08B.31C9A180
Content-Type: text/plain

Richard,
Comment inserted
 
Roger Younglove, CISSP
Principal Consultant
NetWorks Group
O. 810.225.4800 ex. 2245
M. 810.599.0879
E. [e-mail]
www.networksgroup.com
 
 
-----Original Message-----
From: Richard Levitte - VMS Whacker [mailto:[e-mail]] 
Sent: Friday, January 17, 2003 4:49 PM
To: [e-mail]
Cc: [e-mail]; [e-mail]
Subject: Re: "Basic" path-validation question
 
 
In message <[e-mail]> on Fri, 17 Jan 2003 14:38:46
+0100, Jean-Marc Desperrier <[e-mail]> said:
 
jean-marc.desperrier> What is broken is the application, if it
jean-marc.desperrier> *requires* to install both RootCA and CA1 in
jean-marc.desperrier> order to trust EE_type1.
 
Yet, most software do that, *or* install just RootCA and expect to get
every intermediate CA certificate along with the messages sent to it
(that happens with S/MIME, and many SSL-enabled servers present a
whole chain except for the root itself).  From a purely PKI point of
view, both methods are broken, all needed certificates should be
retrievable from one or several publically available stores...
 
jean-marc.desperrier> It should be possible to install only CA1 as a
jean-marc.desperrier> trust anchor, there is no requirement in the
jean-marc.desperrier> path-validation that the trust anchor be
jean-marc.desperrier> self-signed.
 
Actually, I've heard quite different opinions on that.  Some people
assume that the trust anchors are self-signed.  I see no real problem
with that kind of thinking...  If nothing else, you can always set up
your own small CA, certify any other CA you trust with your CA's key,
and have your CA as trust anchor...
 
Roger> Then what you have in affect is a Bridge CA connecting the path of
trust between the CAs that you trust. This would not be a trust anchor. It
would require agreements between all of your trusted CAs because it would
also affect them by extending their individual paths of trust to each other
and they may not wish to do that.
 
jean-marc.desperrier> If the application is OpenSSL, you were talking
jean-marc.desperrier> with someone who is supposed to be able to do
jean-marc.desperrier> something about it :-)
 
I've certain plans in this area for OpenSSL.  I hope to have most of
it ready for 0.9.8.  As it is right now, it has rather crappy
verification routines, as well as the lookup of certificates (it's
in-memory, and lacks of certain needed features).  No policy checking
(as far as I've been able to see and test), and no support for trees
of certificate chains (i.e. it doesn't support the possibility for any
specific subject to have more than one valid certificate at a time...
 
-- 
Richard Levitte     | http://richard.levitte.org/ | Spannv. 38, I
Levitte Programming | http://www.lp.se/           | S-168 35 Bromma
T: [phone] |                             | SWEDEN
     "Price, performance, quality...  choose the two you like"

------_=_NextPart_001_01C2C08B.31C9A180
Content-Type: text/html
Content-Transfer-Encoding: quoted-printable

<html xmlns:o=3D"urn:schemas-microsoft-com:office:office" =
xmlns:w=3D"urn:schemas-microsoft-com:office:word" =
xmlns=3D"http://www.w3.org/TR/REC-html40">

<head>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Dus-ascii">


<meta name=3DProgId content=3DWord.Document>
<meta name=3DGenerator content=3D"Microsoft Word 10">
<meta name=3DOriginator content=3D"Microsoft Word 10">
<link rel=3DFile-List href=3D"cid:filelist.xml@01C2C061.4EC41830">
<!--[if gte mso 9]><xml>
 <o:OfficeDocumentSettings>
  <o:DoNotRelyOnCSS/>
 </o:OfficeDocumentSettings>
</xml><![endif]--><!--[if gte mso 9]><xml>
 <w:WordDocument>
  <w:View>Normal</w:View>
  <w:SpellingState>Clean</w:SpellingState>
  <w:GrammarState>Clean</w:GrammarState>
  <w:DocumentKind>DocumentEmail</w:DocumentKind>
  <w:EnvelopeVis/>
  <w:Compatibility>
   <w:BreakWrappedTables/>
   <w:SnapToGridInCell/>
   <w:WrapTextWithPunct/>
   <w:UseAsianBreakRules/>
  </w:Compatibility>
  <w:BrowserLevel>MicrosoftInternetExplorer4</w:BrowserLevel>
 </w:WordDocument>
</xml><![endif]-->
<style>
<!--
 /* Style Definitions */
 p.MsoNormal, li.MsoNormal, div.MsoNormal
	{mso-style-parent:"";
	margin:0in;
	margin-bottom:.0001pt;
	mso-pagination:widow-orphan;
	font-size:12.0pt;
	font-family:"Times New Roman";
	mso-fareast-font-family:"Times New Roman";}
a:link, span.MsoHyperlink
	{color:blue;
	text-decoration:underline;
	text-underline:single;}
a:visited, span.MsoHyperlinkFollowed
	{color:purple;
	text-decoration:underline;
	text-underline:single;}
p.MsoPlainText, li.MsoPlainText, div.MsoPlainText
	{margin:0in;
	margin-bottom:.0001pt;
	mso-pagination:widow-orphan;
	font-size:10.0pt;
	font-family:"Courier New";
	mso-fareast-font-family:"Times New Roman";}
span.GramE
	{mso-style-name:"";
	mso-gram-e:yes;}
@page Section1
	{size:8.5in 11.0in;
	margin:1.0in 77.95pt 1.0in 77.95pt;
	mso-header-margin:.5in;
	mso-footer-margin:.5in;
	mso-paper-source:0;}
div.Section1
	{page:Section1;}
-->
</style>
<!--[if gte mso 10]>
<style>
 /* Style Definitions */=20
 table.MsoNormalTable
	{mso-style-name:"Table Normal";
	mso-tstyle-rowband-size:0;
	mso-tstyle-colband-size:0;
	mso-style-noshow:yes;
	mso-style-parent:"";
	mso-padding-alt:0in 5.4pt 0in 5.4pt;
	mso-para-margin:0in;
	mso-para-margin-bottom:.0001pt;
	mso-pagination:widow-orphan;
	font-size:10.0pt;
	font-family:"Times New Roman";}
</style>
<![endif]-->
</head>

<body lang=3DEN-US link=3Dblue vlink=3Dpurple =
style=3D'tab-interval:.5in'>

<div class=3DSection1>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:
10.0pt'>Richard,<o:p></o:p></span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:
10.0pt'>Comment inserted<o:p></o:p></span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:
10.0pt'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:
10.0pt;mso-no-proof:yes'>Roger Younglove, =
CISSP<o:p></o:p></span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:
10.0pt;mso-no-proof:yes'>Principal =
Consultant<o:p></o:p></span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:
10.0pt;mso-no-proof:yes'>NetWorks Group<o:p></o:p></span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
lang=3DFR
style=3D'font-size:10.0pt;mso-ansi-language:FR;mso-no-proof:yes'>O. =
810.225.4800
ex. 2245<o:p></o:p></span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
lang=3DFR
style=3D'font-size:10.0pt;mso-ansi-language:FR;mso-no-proof:yes'>M. =
810.599.0879<o:p></o:p></span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
lang=3DFR
style=3D'font-size:10.0pt;mso-ansi-language:FR;mso-no-proof:yes'>E.
[e-mail]<o:p></o:p></span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:
10.0pt;mso-no-proof:yes'>www.networksgroup.com<o:p></o:p></span></font><=
/p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:
10.0pt;mso-no-proof:yes'><span =
style=3D'mso-spacerun:yes'>&nbsp;</span><o:p></o:p></span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:
10.0pt'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:
10.0pt'>-----Original Message-----<br>
From: Richard Levitte - VMS Whacker [mailto:[e-mail]] <br>
Sent: Friday, January 17, 2003 4:49 PM<br>
To: [e-mail]<br>
Cc: [e-mail]; [e-mail]<br>
Subject: Re: &quot;Basic&quot; path-validation =
question<o:p></o:p></span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:
10.0pt'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:
10.0pt'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:
10.0pt'>In message &lt;[e-mail]&gt; on Fri, 17 Jan =
2003
14:38:46 +0100, Jean-Marc Desperrier =
&lt;[e-mail]&gt;
said:<o:p></o:p></span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:
10.0pt'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:
10.0pt'>jean-marc.desperrier&gt; What is broken is the application, if =
it<o:p></o:p></span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:
10.0pt'>jean-marc.desperrier&gt; *requires* to install both RootCA and =
CA1 in<o:p></o:p></span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:
10.0pt'>jean-marc.desperrier&gt; order to trust =
EE_type1.<o:p></o:p></span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:
10.0pt'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:
10.0pt'>Yet, most software do that, *or* install just RootCA and expect =
to get<o:p></o:p></span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:
10.0pt'>every intermediate CA certificate along with the messages sent =
to it<o:p></o:p></span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:
10.0pt'>(that happens with S/MIME, and many SSL-enabled servers present =
a<o:p></o:p></span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:
10.0pt'>whole chain except for the root itself).<span
style=3D'mso-spacerun:yes'>&nbsp; </span>From a purely PKI point =
of<o:p></o:p></span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:
10.0pt'>view, both methods are broken, all needed certificates should =
be<o:p></o:p></span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:
10.0pt'>retrievable from one or several publically available =
stores...<o:p></o:p></span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:
10.0pt'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:
10.0pt'>jean-marc.desperrier&gt; It should be possible to install only =
CA1 as a<o:p></o:p></span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:
10.0pt'>jean-marc.desperrier&gt; trust anchor, there is no requirement =
in the<o:p></o:p></span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:
10.0pt'>jean-marc.desperrier&gt; path-validation that the trust anchor =
be<o:p></o:p></span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:
10.0pt'>jean-marc.desperrier&gt; =
self-signed.<o:p></o:p></span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:
10.0pt'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:
10.0pt'>Actually, I've heard quite different opinions on that.<span
style=3D'mso-spacerun:yes'>&nbsp; </span>Some =
people<o:p></o:p></span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:
10.0pt'>assume that the trust anchors are self-signed.<span
style=3D'mso-spacerun:yes'>&nbsp; </span>I see no real =
problem<o:p></o:p></span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:
10.0pt'>with that kind of thinking...<span =
style=3D'mso-spacerun:yes'>&nbsp;
</span>If nothing else, you can always set =
up<o:p></o:p></span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:
10.0pt'>your own small CA, certify any other CA you trust with your =
CA's key,<o:p></o:p></span></font></p>

<p class=3DMsoPlainText><span class=3DGramE><font size=3D2 =
face=3D"Courier New"><span
style=3D'font-size:10.0pt'>and</span></font></span> have your CA as =
trust
anchor...<o:p></o:p></p>

<p class=3DMsoPlainText><font size=3D2 color=3Dblack face=3D"Courier =
New"><span
style=3D'font-size:10.0pt;color:black'><o:p>&nbsp;</o:p></span></font></=
p>

<p class=3DMsoPlainText><i style=3D'mso-bidi-font-style:normal'><font =
size=3D2
color=3Dblack face=3D"Courier New"><span =
style=3D'font-size:10.0pt;color:black;
font-style:italic;mso-bidi-font-style:normal'>Roger&gt; Then what you =
have in
affect is a Bridge CA connecting the path of trust between the CAs that =
you
trust. This would not be a trust anchor. It would require agreements =
between
all of your trusted CAs because it would also affect them by extending =
their
individual paths of trust to each other and they may not wish to do =
that.<o:p></o:p></span></font></i></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:
10.0pt'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:
10.0pt'>jean-marc.desperrier&gt; If the application is OpenSSL, you =
were
talking<o:p></o:p></span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:
10.0pt'>jean-marc.desperrier&gt; with someone who is supposed to be =
able to do<o:p></o:p></span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:
10.0pt'>jean-marc.desperrier&gt; something about it =
:-)<o:p></o:p></span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:
10.0pt'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:
10.0pt'>I've certain plans in this area for OpenSSL.<span
style=3D'mso-spacerun:yes'>&nbsp; </span>I hope to have most =
of<o:p></o:p></span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:
10.0pt'>it ready for 0.9.8.<span style=3D'mso-spacerun:yes'>&nbsp; =
</span>As it
is right now, it has rather crappy<o:p></o:p></span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:
10.0pt'>verification routines, as well as the lookup of certificates =
(it's<o:p></o:p></span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:
10.0pt'>in-memory, and lacks of certain needed features).<span
style=3D'mso-spacerun:yes'>&nbsp; </span>No policy =
checking<o:p></o:p></span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:
10.0pt'>(as far as I've been able to see and test), and no support for =
trees<o:p></o:p></span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:
10.0pt'>of certificate chains (i.e. it doesn't support the possibility =
for any<o:p></o:p></span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:
10.0pt'>specific subject to have more than one valid certificate at a =
time...<o:p></o:p></span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:
10.0pt'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:
10.0pt'>-- <o:p></o:p></span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:
10.0pt'>Richard Levitte<span =
style=3D'mso-spacerun:yes'>&nbsp;&nbsp;&nbsp;&nbsp;
</span>| http://richard.levitte.org/ | Spannv. 38, =
I<o:p></o:p></span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:
10.0pt'>Levitte Programming | http://www.lp.se/<span
style=3D'mso-spacerun:yes'>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp;
</span>| S-168 35 Bromma<o:p></o:p></span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:
10.0pt'>T: [phone] |<span
style=3D'mso-spacerun:yes'>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
</span>| SWEDEN<o:p></o:p></span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:
10.0pt'><span style=3D'mso-spacerun:yes'>&nbsp;&nbsp;&nbsp;&nbsp;
</span>&quot;Price, performance, quality...<span
style=3D'mso-spacerun:yes'>&nbsp; </span>choose the two you =
like&quot;<o:p></o:p></span></font></p>

</div>

</body>

</html>

------_=_NextPart_001_01C2C08B.31C9A180--


Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h0KD9td07790 for ietf-pkix-bks; Mon, 20 Jan 2003 05:09:55 -0800 (PST)
Received: from email.certplus.com ([195.101.88.80]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h0KD9ro07786 for <[e-mail]>; Mon, 20 Jan 2003 05:09:53 -0800 (PST)
Received: from carbone.certplus.com (facteur.certplus.com [172.16.1.81]) by email.certplus.com (8.12.2+Sun/8.12.2) with ESMTP id h0KD9hft017156; Mon, 20 Jan 2003 14:09:43 +0100 (CET)
Received: from certplus.com ([192.168.212.166]) by carbone.certplus.com with Microsoft SMTPSVC(5.0.2195.2966); Mon, 20 Jan 2003 14:07:42 +0100
Message-ID: <[e-mail]>
Date: Mon, 20 Jan 2003 14:11:17 +0100
From: Jean-Marc Desperrier <[e-mail]>
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.3b) Gecko/20030101
X-Accept-Language: fr, en, en-us, ja
MIME-Version: 1.0
To: Peter Gutmann <[e-mail]>
CC: [e-mail], [e-mail]
Subject: Re: (Un)managing non-existent DNs in enrolments
References: <[e-mail]>
In-Reply-To: <[e-mail]>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
X-OriginalArrivalTime: 20 Jan 2003 13:07:42.0078 (UTC) FILETIME=[EA6949E0:01C2C084]
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Peter Gutmann a dit :

>This is going from the basic philosophy that "DNs are a lost cause, so we just
>treat them as meaningless blobs with a uniqueness constraint".  This works
>just fine in practice.
>  
>
The japanese report on their PKI Challenge shows some interesting ugly 
results of CA accepting names without proper validation.




Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h0KBAY628925 for ietf-pkix-bks; Mon, 20 Jan 2003 03:10:34 -0800 (PST)
Received: from hermes.cs.auckland.ac.nz (hermes.cs.auckland.ac.nz [130.216.35.151]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h0KBAWo28920 for <[e-mail]>; Mon, 20 Jan 2003 03:10:32 -0800 (PST)
Received: from medusa01.cs.auckland.ac.nz (medusa01.cs.auckland.ac.nz [130.216.34.60]) by hermes.cs.auckland.ac.nz (8.12.4/8.12.4) with ESMTP id h0KBAQcf005881; Tue, 21 Jan 2003 00:10:26 +1300
Received: (from pgut001@localhost) by medusa01.cs.auckland.ac.nz (8.11.6/8.11.6) id h0KBAQj16782; Tue, 21 Jan 2003 00:10:26 +1300
Date: Tue, 21 Jan 2003 00:10:26 +1300
Message-Id: <[e-mail]>
From: [e-mail] (Peter Gutmann)
To: [e-mail], [e-mail]
Subject: Re: (Un)managing non-existent DNs in enrolments
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

[e-mail] writes:

>I am interested in hearing from CA operators as to how they would handle this.

In case you can't already predict in advance how I'm going to respond to this
:-), my reaction would be:

- Verify that the CN and email (and possibly other bits, depending on local
  policy) are valid (that is, that the requestor is authorised to use them,
  that they don't duplicate someone else's values, etc etc).

- Issue and publish the cert.

This is going from the basic philosophy that "DNs are a lost cause, so we just
treat them as meaningless blobs with a uniqueness constraint".  This works
just fine in practice.

Peter.



Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h0KAikj27300 for ietf-pkix-bks; Mon, 20 Jan 2003 02:44:46 -0800 (PST)
Received: from mail3.consignia.com (mail3.consignia.com [144.87.143.83]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h0KAiio27296 for <[e-mail]>; Mon, 20 Jan 2003 02:44:45 -0800 (PST)
Received: from postoffice.co.uk (unknown [144.87.146.16]) by mail3.consignia.com (Postfix) with SMTP id 78C3A18FA17 for <[e-mail]>; Mon, 20 Jan 2003 10:44:37 +0000 (GMT)
Received: by postoffice.co.uk(Lotus SMTP MTA v4.6.6  (890.1 7-16-1999))  id 00256CB4.003B0944 ; Mon, 20 Jan 2003 10:44:49 +0000
X-Lotus-FromDomain: POSTOFFICE
From: [e-mail]
To: [e-mail]
Message-ID: <[e-mail]>
Date: Mon, 20 Jan 2003 10:44:18 +0000
Subject: (Un)managing non-existent DNs in enrolments
Mime-Version: 1.0
Content-type: text/plain; charset=us-ascii
Content-Disposition: inline
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

During the recent interop trials on the PKI Challenge we had some first-hand
experience of the implications for PKI in persisting with a non-global DN
space.

We knew that there would be some insurmountable Directory issues but
we tried to mitigate the problems by prescribing a DIT and naming structure
for the project. Even so not everybody involved in the trials stuck to the spec.
Hardly surprising given the prevailing economic conditions that the project
was working with. One of the more interesting outcomes of the trials was that
enrolment requests from domains with alien DITs could not be published.
The requested DN was not valid within the DIT for the CA performing the
enrolment. While this meant that the EE cert could not be  browsed it also
meant that the published credentials could not be managed by any tool that
used the Directory as its source of reference. Thus, such tools could not
revoke the certificates that its own CA had published.

Clearly these are not protocol issues as such but it does pose some
serious questions about how a CA should handle an enrolment request
that includes a non-existent DN. Should it;

i) Reject it because it's against the CP
ii) Accept the DN and extend the DIT to accommodate (dangerous)
iii) Override the DN and publish to a catch-all bin
iv) Publish under the lowest possible policy

I am interested in hearing from CA operators as to how they would handle this.

Chris

This  email  and  any  attachments  are confidential and intended for the addressee
only.   If  you are not the named recipient, you must not use, disclose, reproduce,
copy  or  distribute the contents of this communication.  If you have received this
in error, please contact the sender and then delete this email from your system.




Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h0KAa7d26209 for ietf-pkix-bks; Mon, 20 Jan 2003 02:36:07 -0800 (PST)
Received: from mailg.telia.com (mailg.telia.com [194.22.194.26]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h0KAa4o26198 for <[e-mail]>; Mon, 20 Jan 2003 02:36:05 -0800 (PST)
Received: from arport (h127n2fls31o1122.telia.com [212.181.142.127]) by mailg.telia.com (8.12.5/8.12.5) with SMTP id h0KAZr19009989; Mon, 20 Jan 2003 11:35:57 +0100 (CET)
X-Original-Recipient: [e-mail]
Message-ID: <002101c2c06f$676facb0$0500a8c0@arport>
From: "Anders Rundgren" <[e-mail]>
To: "Jean-Marc Desperrier" <[e-mail]>, <[e-mail]>
References: <011001c2be23$22209a50$0500a8c0@arport>            <[e-mail]>            <001901c2be38$99928e80$0500a8c0@arport> <[e-mail]> <003801c2bed3$bbcd5c50$0500a8c0@arport> <[e-mail]>
Subject: Re: "Basic" path-validation question
Date: Mon, 20 Jan 2003 11:33:35 +0100
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.50.4133.2400
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Jean-Marc,
I understand what you are saying and I don't disagree with
it either.  May I put some other associated questions?

The point of having a root-certificate according to the sketch I
posted, should be that the root is supposed to be long-lived (using
a longer key maybe) compared to sub-CAs which should make
sub-CA renewals somewhat easier (?) for RPs to handle.  Right?

Or is the only really valid argument for have a root like the one
shown, is that multiple more or less independent CAs can be
"trusted" with just one RP "install" procedure.

To make this somewhat clearer: I'm plotting with a scheme (I-D),
where a trust administrator must explicitly "accept" a CA that
has a "trust-store" mark as a part of an extension mechanism.
The extension mechanism also manages name-spaces,  by adding a
new dimension (and control) to the name-space embraced by EEs,
allowing either "Sharing" or "Galvanic isolation" between CAs.

Cheers,
Anders


----- Original Message ----- 
From: "Jean-Marc Desperrier" <[e-mail]>
To: <[e-mail]>
Sent: Sunday, January 19, 2003 20:39
Subject: Re: "Basic" path-validation question



Anders Rundgren a dit :

>>RFC3280 says nothing on how you get hold of the certificates
>>you use for validation, so yes, it's outside the scope of that
>>RFC (unless I've done a miserable job reading it).
>>    
>>
>I think you have done a good job reading it, which means that my
>"basic" question apparently is completely outside of the realm of
>PKIX-standards.  Close to UNBELIEVABLE  IMNSHO.
>
Very believable, because your question is not basic.

The premice on which you start is that the organisation can not be 
tailored to easier what you want to do, and that they will not be an 
application level input restricting which kind of certificate you want 
to trust. It's no so surprising you end up with no solution.

What you started with was distributing a root CA and one of its sub-CA.
This mean you prived two trust anchors, and they are added to each 
other, the second can not somehow restrict the application of the first.
In fact, as the root CA includes all the domain of the sub-CA, it was 
not necessary to provide the sub-CA.
If you don't want to trust everything the root signs, then *don't* 
distribute the root, or you MUST  use a higher level mechanism to 
restrict what is trusted.
This is the way X509 PKI works, and it has the definitive advantage of 
being simple !

If it was needed to distribute the subCA in addition to the root, 
because the clients don't always provide the full path to the root, then 
when the subCA is replaced, the clients will still not provide the full 
path, so you will *need* to distribute the new sub-CA.

So you won nothing by distributing the root.
If you want to trust only the domain of the subCA, then only distribute 
the sub-CA.

If you want to be able to renew easily the sub-CA, then one solution can 
be to create an intermediate CA between the root and the current sub, 
that only signs the sub-CA you want to trust.
This is what I meant by tailoring the organisation to easier what you 
want to do.

But in fact your true question is how to distribute easily new trust 
anchors, and this is not part of RFC3280.

I've seen some people seriously try to find an answer to this, they came 
up with the following kind of solutions, and I don't really see another 
way to do it :
- Have in the application one special trusted certificat that signs a 
list of the CA that are part of your trust anchors in the RFC3280 
meaning, and then a distribution channel to distribute new versions of 
that signed message.

You can use a SET-like chain mechanism to be able to regularly renew 
that special certificate.

Describing that kind of mechanism could make a very valid informational 
RFC :-).






Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h0KAQsT25726 for ietf-pkix-bks; Mon, 20 Jan 2003 02:26:54 -0800 (PST)
Received: from smtp013.mail.yahoo.com (smtp013.mail.yahoo.com [216.136.173.57]) by above.proper.com (8.11.6/8.11.3) with SMTP id h0KAQqo25721 for <[e-mail]>; Mon, 20 Jan 2003 02:26:52 -0800 (PST)
Received: from pc199.baltimore.com.hk (HELO evechow) (chow?eve@203.85.185.199 with login) by smtp.mail.vip.sc5.yahoo.com with SMTP; 20 Jan 2003 10:26:52 -0000
Message-ID: <016501c2c06d$fc37d180$[e-mail]>
From: "Eve Chow - Yahoo" <[e-mail]>
To: "Roger Younglove" <[e-mail]>, "IETF PKIX" <[e-mail]>
References: <[e-mail]>
Subject: Re: about CRLdp 
Date: Mon, 20 Jan 2003 18:23:25 +0800
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_0162_01C2C0B1.05A6D840"
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2800.1106
X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1106
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

This is a multi-part message in MIME format.

------=_NextPart_000_0162_01C2C0B1.05A6D840
Content-Type: text/plain;
	charset="big5"
Content-Transfer-Encoding: quoted-printable

Dear Roger ,=20

Thanks ! I think this make sense since each CRL has its own counter .

 I have further discussion with customer on the CRLdp , in which the =
gentlemen express concern that setting up CRLdp will trigger MS product =
( outlook , express , IE ) automatically lookup the CRL distribution =
point , this will create extra loading to the CRL point  ( in this case =
on single LDAP ) . Any comment on this statement ? If that is true , are =
there any get-around to prevent MS product to auto lookup the CRLdp ?=20

In general , I have heard lots pros about delta / partition CRL - I =
wonder if anyone in the list can also share the cons side in deployment =
.

Many thanks !=20

Eve=20
  ----- Original Message -----=20
  From: Roger Younglove=20
  To: 'Eve Chow - Yahoo' ; IETF PKIX=20
  Sent: Friday, January 17, 2003 10:20 PM
  Subject: RE: about CRLdp=20


  Eve,

  I would have the full CRL increment N to identify the full CRL that =
would be:

  Full CRL number N , CRLDP 1 =3D N1 ,CRLDP 2 =3D N2,CRLDP 3 =3D N3  and =
 Next full CRL =3D N+1 with CRLDP 1 =3D (N+1) 1, CRLDP2 =3D (N=3D1)2, =
does this make sense?

  =20

  Roger Younglove, CISSP

  Principal Consultant

  NetWorks Group

  O. 810.225.4800 ex. 2245

  M. 810.599.0879

  E. [e-mail]

  www.networksgroup.com

  =20

  -----Original Message-----
  From: Eve Chow - Yahoo [mailto:[e-mail]]=20
  Sent: Friday, January 17, 2003 3:44 AM
  To: IETF PKIX
  Subject: about CRLdp=20

  =20

  Dear all ,

  =20

  I have a question about the CRLdp usage - suppose I setup m CRLdp , =
how will the CRL number in CRL count up  ?

  eg. m=3D 3 CRLDP  for CRL partition.

  so the full CRL will have number N ,CRLDP 1 =3D N+1 ,CRLDP 2 =3D =
N+2,CRLDP 3 =3D N+3  and  Next full CRL =3D N+ 4 ?

  Regards,

  Eve Chow , CISSP, CISA

  Project Manager

  Baltimore Technologies Limited

  =20

  =20

------=_NextPart_000_0162_01C2C0B1.05A6D840
Content-Type: text/html;
	charset="big5"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML xmlns=3D"http://www.w3.org/TR/REC-html40" xmlns:v =3D=20
"urn:schemas-microsoft-com:vml" xmlns:o =3D=20
"urn:schemas-microsoft-com:office:office" xmlns:w =3D=20
"urn:schemas-microsoft-com:office:word" xmlns:st1 =3D=20
"urn:schemas-microsoft-com:office:smarttags"><HEAD>
<META http-equiv=3DContent-Type content=3D"text/html; charset=3Dbig5">
<META content=3DWord.Document name=3DProgId>
<META content=3D"MSHTML 6.00.2800.1106" name=3DGENERATOR>
<META content=3D"Microsoft Word 10" name=3DOriginator><LINK=20
href=3D"cid:filelist.xml@01C2BE09.A79A8520" =
rel=3DFile-List><o:SmartTagType=20
name=3D"time"=20
namespaceuri=3D"urn:schemas-microsoft-com:office:smarttags"></o:SmartTagT=
ype><o:SmartTagType=20
name=3D"date"=20
namespaceuri=3D"urn:schemas-microsoft-com:office:smarttags"></o:SmartTagT=
ype><!--[if gte mso 9]><xml>
 <o:OfficeDocumentSettings>
  <o:DoNotRelyOnCSS/>
 </o:OfficeDocumentSettings>
</xml><![endif]--><!--[if gte mso 9]><xml>
 <w:WordDocument>
  <w:SpellingState>Clean</w:SpellingState>
  <w:GrammarState>Clean</w:GrammarState>
  <w:DocumentKind>DocumentEmail</w:DocumentKind>
  <w:EnvelopeVis/>
  <w:BrowserLevel>MicrosoftInternetExplorer4</w:BrowserLevel>
 </w:WordDocument>
</xml><![endif]--><!--[if !mso]>
<STYLE>st1\:* {
	BEHAVIOR: url(#default#ieooui)
}
</STYLE>
<![endif]-->
<STYLE>
<!--
 /* Font Definitions */
 @font-face
	{font-family:Tahoma;
	panose-1:2 11 6 4 3 5 4 4 2 4;
	mso-font-charset:0;
	mso-generic-font-family:swiss;
	mso-font-pitch:variable;
	mso-font-signature:553679495 -2147483648 8 0 66047 0;}
 /* Style Definitions */
 p.MsoNormal, li.MsoNormal, div.MsoNormal
	{mso-style-parent:"";
	margin:0in;
	margin-bottom:.0001pt;
	mso-pagination:widow-orphan;
	font-size:12.0pt;
	font-family:"Times New Roman";
	mso-fareast-font-family:"Times New Roman";}
a:link, span.MsoHyperlink
	{color:blue;
	text-decoration:underline;
	text-underline:single;}
a:visited, span.MsoHyperlinkFollowed
	{color:purple;
	text-decoration:underline;
	text-underline:single;}
p.MsoAutoSig, li.MsoAutoSig, div.MsoAutoSig
	{margin:0in;
	margin-bottom:.0001pt;
	mso-pagination:widow-orphan;
	font-size:12.0pt;
	font-family:"Times New Roman";
	mso-fareast-font-family:"Times New Roman";}
p
	{mso-margin-top-alt:auto;
	margin-right:0in;
	mso-margin-bottom-alt:auto;
	margin-left:0in;
	mso-pagination:widow-orphan;
	font-size:12.0pt;
	font-family:"Times New Roman";
	mso-fareast-font-family:"Times New Roman";}
span.EmailStyle18
	{mso-style-type:personal-reply;
	mso-style-noshow:yes;
	mso-ansi-font-size:10.0pt;
	mso-bidi-font-size:10.0pt;
	font-family:Arial;
	mso-ascii-font-family:Arial;
	mso-hansi-font-family:Arial;
	mso-bidi-font-family:Arial;
	color:navy;}
span.GramE
	{mso-style-name:"";
	mso-gram-e:yes;}
@page Section1
	{size:8.5in 11.0in;
	margin:1.0in 1.25in 1.0in 1.25in;
	mso-header-margin:.5in;
	mso-footer-margin:.5in;
	mso-paper-source:0;}
div.Section1
	{page:Section1;}
-->
</STYLE>
<!--[if gte mso 10]>
<style>
 /* Style Definitions */=20
 table.MsoNormalTable
	{mso-style-name:"Table Normal";
	mso-tstyle-rowband-size:0;
	mso-tstyle-colband-size:0;
	mso-style-noshow:yes;
	mso-style-parent:"";
	mso-padding-alt:0in 5.4pt 0in 5.4pt;
	mso-para-margin:0in;
	mso-para-margin-bottom:.0001pt;
	mso-pagination:widow-orphan;
	font-size:10.0pt;
	font-family:"Times New Roman";}
</style>
<![endif]--><!--[if gte mso 9]><xml>
 <o:shapedefaults v:ext=3D"edit" spidmax=3D"1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
 <o:shapelayout v:ext=3D"edit">
  <o:idmap v:ext=3D"edit" data=3D"1" />
 </o:shapelayout></xml><![endif]--></HEAD>
<BODY lang=3DEN-US style=3D"tab-interval: .5in" vLink=3Dpurple =
link=3Dblue=20
bgColor=3Dwhite>
<DIV><FONT face=3DArial size=3D2>Dear Roger , </FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>Thanks ! I think this make sense since =
each CRL has=20
its own counter .</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>&nbsp;I have&nbsp;further discussion =
with customer=20
on the CRLdp , in which the gentlemen express&nbsp;concern =
that&nbsp;setting up=20
CRLdp will&nbsp;trigger MS product ( outlook , express , IE ) =
automatically=20
lookup the CRL distribution point , this will create extra loading to =
the CRL=20
point&nbsp; ( in this case on&nbsp;single LDAP ) . Any comment on this =
statement=20
? If that is true , are there any get-around to prevent MS product to =
auto=20
lookup the CRLdp ? </FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>In general , I have heard lots pros =
about delta /=20
partition CRL - I wonder if anyone in the list can also share the cons =
side in=20
deployment .</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>Many thanks ! </FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>Eve </FONT></DIV>
<BLOCKQUOTE dir=3Dltr=20
style=3D"PADDING-RIGHT: 0px; PADDING-LEFT: 5px; MARGIN-LEFT: 5px; =
BORDER-LEFT: #000000 2px solid; MARGIN-RIGHT: 0px">
  <DIV style=3D"FONT: 10pt arial">----- Original Message ----- </DIV>
  <DIV=20
  style=3D"BACKGROUND: #e4e4e4; FONT: 10pt arial; font-color: =
black"><B>From:</B>=20
  <A title=[e-mail]=20
  href=3D"mailto:[e-mail]">Roger Younglove</A> =
</DIV>
  <DIV style=3D"FONT: 10pt arial"><B>To:</B> <A =
title=[e-mail]=20
  href=3D"mailto:[e-mail]">'Eve Chow - Yahoo'</A> ; <A=20
  title=[e-mail] href=3D"mailto:[e-mail]">IETF =
PKIX</A> </DIV>
  <DIV style=3D"FONT: 10pt arial"><B>Sent:</B> Friday, January 17, 2003 =
10:20=20
  PM</DIV>
  <DIV style=3D"FONT: 10pt arial"><B>Subject:</B> RE: about CRLdp </DIV>
  <DIV><BR></DIV>
  <DIV class=3DSection1>
  <P class=3DMsoNormal><FONT face=3DArial size=3D2><SPAN=20
  style=3D"FONT-SIZE: 10pt; FONT-FAMILY: Arial; mso-bidi-font-size: =
12.0pt">Eve,<o:p></o:p></SPAN></FONT></P>
  <P class=3DMsoNormal><FONT face=3DArial size=3D2><SPAN=20
  style=3D"FONT-SIZE: 10pt; FONT-FAMILY: Arial; mso-bidi-font-size: =
12.0pt">I=20
  would have the full CRL increment N to identify the full CRL that =
would=20
  be:<o:p></o:p></SPAN></FONT></P>
  <P class=3DMsoNormal><FONT face=3DArial size=3D2><SPAN=20
  style=3D"FONT-SIZE: 10pt; FONT-FAMILY: Arial; mso-bidi-font-size: =
12.0pt">Full=20
  CRL</SPAN></FONT><FONT face=3DArial size=3D2><SPAN=20
  style=3D"FONT-SIZE: 10pt; FONT-FAMILY: Arial; mso-bidi-font-size: =
12.0pt; mso-bidi-font-family: 'Times New Roman'">=20
  number <SPAN class=3DGramE>N ,</SPAN> CRLDP 1 =3D N1 ,CRLDP 2 =3D =
N2,CRLDP 3 =3D=20
  N3&nbsp; and&nbsp; Next full CRL =3D N+1 with CRLDP 1 =3D (N+1) 1, =
CRLDP2 =3D=20
  (N=3D1)2, does this make sense?</SPAN></FONT><FONT face=3DArial =
size=3D2><SPAN=20
  style=3D"FONT-SIZE: 10pt; FONT-FAMILY: Arial; mso-bidi-font-size: =
12.0pt"><o:p></o:p></SPAN></FONT></P>
  <P class=3DMsoNormal><FONT face=3DArial size=3D2><SPAN=20
  style=3D"FONT-SIZE: 10pt; FONT-FAMILY: =
Arial"><o:p>&nbsp;</o:p></SPAN></FONT></P>
  <DIV>
  <P class=3DMsoAutoSig><FONT face=3D"Times New Roman" color=3Dnavy =
size=3D3><SPAN=20
  style=3D"FONT-SIZE: 12pt; COLOR: navy; mso-no-proof: yes">Roger =
Younglove,=20
  CISSP<o:p></o:p></SPAN></FONT></P>
  <P class=3DMsoAutoSig><FONT face=3D"Times New Roman" color=3Dnavy =
size=3D3><SPAN=20
  style=3D"FONT-SIZE: 12pt; COLOR: navy; mso-no-proof: yes">Principal=20
  Consultant<o:p></o:p></SPAN></FONT></P>
  <P class=3DMsoAutoSig><FONT face=3D"Times New Roman" color=3Dnavy =
size=3D3><SPAN=20
  style=3D"FONT-SIZE: 12pt; COLOR: navy; mso-no-proof: yes">NetWorks=20
  Group<o:p></o:p></SPAN></FONT></P>
  <P class=3DMsoAutoSig><FONT face=3D"Times New Roman" color=3Dnavy =
size=3D3><SPAN=20
  lang=3DFR=20
  style=3D"FONT-SIZE: 12pt; COLOR: navy; mso-no-proof: yes; =
mso-ansi-language: FR">O.=20
  810.225.4800 ex. 2245<o:p></o:p></SPAN></FONT></P>
  <P class=3DMsoAutoSig><FONT face=3D"Times New Roman" color=3Dnavy =
size=3D3><SPAN=20
  lang=3DFR=20
  style=3D"FONT-SIZE: 12pt; COLOR: navy; mso-no-proof: yes; =
mso-ansi-language: FR">M.=20
  810.599.0879<o:p></o:p></SPAN></FONT></P>
  <P class=3DMsoAutoSig><FONT face=3D"Times New Roman" color=3Dnavy =
size=3D3><SPAN=20
  lang=3DFR=20
  style=3D"FONT-SIZE: 12pt; COLOR: navy; mso-no-proof: yes; =
mso-ansi-language: FR">E.=20
  <A=20
  =
href=3D"mailto:[e-mail]">[e-mail]=
</A><o:p></o:p></SPAN></FONT></P>
  <P class=3DMsoAutoSig><FONT face=3D"Times New Roman" color=3Dnavy =
size=3D3><SPAN=20
  style=3D"FONT-SIZE: 12pt; COLOR: navy; mso-no-proof: yes"><A=20
  =
href=3D"http://www.networksgroup.com">www.networksgroup.com</A><o:p></o:p=
></SPAN></FONT></P></DIV>
  <P class=3DMsoNormal><FONT face=3DArial color=3Dnavy size=3D2><SPAN=20
  style=3D"FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: =
Arial"><o:p>&nbsp;</o:p></SPAN></FONT></P>
  <P class=3DMsoNormal style=3D"MARGIN-LEFT: 0.5in"><FONT face=3DTahoma =
size=3D2><SPAN=20
  style=3D"FONT-SIZE: 10pt; FONT-FAMILY: Tahoma">-----Original=20
  Message-----<BR><B><SPAN style=3D"FONT-WEIGHT: bold">From:</SPAN></B> =
Eve Chow -=20
  Yahoo [mailto:[e-mail]] <BR><B><SPAN=20
  style=3D"FONT-WEIGHT: bold">Sent:</SPAN></B> </SPAN></FONT><st1:date =
Year=3D"2003"=20
  Day=3D"17" Month=3D"1"><FONT face=3DTahoma size=3D2><SPAN=20
  style=3D"FONT-SIZE: 10pt; FONT-FAMILY: Tahoma">Friday, January 17,=20
  2003</SPAN></FONT></st1:date><FONT face=3DTahoma size=3D2><SPAN=20
  style=3D"FONT-SIZE: 10pt; FONT-FAMILY: Tahoma"> =
</SPAN></FONT><st1:time=20
  Minute=3D"44" Hour=3D"3"><FONT face=3DTahoma size=3D2><SPAN=20
  style=3D"FONT-SIZE: 10pt; FONT-FAMILY: Tahoma">3:44=20
  AM</SPAN></FONT></st1:time><FONT face=3DTahoma size=3D2><SPAN=20
  style=3D"FONT-SIZE: 10pt; FONT-FAMILY: Tahoma"><BR><B><SPAN=20
  style=3D"FONT-WEIGHT: bold">To:</SPAN></B> IETF PKIX<BR><B><SPAN=20
  style=3D"FONT-WEIGHT: bold">Subject:</SPAN></B> about CRLdp =
</SPAN></FONT></P>
  <P class=3DMsoNormal style=3D"MARGIN-LEFT: 0.5in"><FONT face=3D"Times =
New Roman"=20
  size=3D3><SPAN style=3D"FONT-SIZE: =
12pt"><o:p>&nbsp;</o:p></SPAN></FONT></P>
  <DIV>
  <P class=3DMsoNormal style=3D"MARGIN-LEFT: 0.5in"><FONT face=3D"Times =
New Roman"=20
  size=3D2><SPAN style=3D"FONT-SIZE: 10pt">Dear all=20
  ,</SPAN></FONT><o:p></o:p></P></DIV>
  <DIV>
  <P class=3DMsoNormal style=3D"MARGIN-LEFT: 0.5in"><FONT face=3D"Times =
New Roman"=20
  size=3D3><SPAN style=3D"FONT-SIZE: =
12pt">&nbsp;<o:p></o:p></SPAN></FONT></P></DIV>
  <DIV>
  <P class=3DMsoNormal style=3D"MARGIN-LEFT: 0.5in"><FONT face=3D"Times =
New Roman"=20
  size=3D2><SPAN style=3D"FONT-SIZE: 10pt">I have a question about the =
CRLdp usage -=20
  suppose I setup m CRLdp , how will the CRL number in CRL&nbsp;count up =

  &nbsp;?<o:p></o:p></SPAN></FONT></P></DIV>
  <DIV>
  <P style=3D"MARGIN-LEFT: 0.5in"><FONT face=3D"Times New Roman" =
size=3D2><SPAN=20
  style=3D"FONT-SIZE: 10pt">eg. m=3D 3 CRLDP&nbsp; for CRL=20
  partition.<o:p></o:p></SPAN></FONT></P>
  <P style=3D"MARGIN-LEFT: 0.5in"><FONT face=3D"Times New Roman" =
size=3D2><SPAN=20
  style=3D"FONT-SIZE: 10pt">so the full CRL will have number N ,CRLDP 1 =
=3D N+1=20
  ,CRLDP 2 =3D N+2,CRLDP 3 =3D N+3&nbsp; and&nbsp; Next full CRL =3D =
N+&nbsp;4=20
  ?<o:p></o:p></SPAN></FONT></P>
  <P style=3D"MARGIN-LEFT: 0.5in"><FONT face=3DArial size=3D2><SPAN=20
  style=3D"FONT-SIZE: 10pt; FONT-FAMILY: =
Arial">Regards,<o:p></o:p></SPAN></FONT></P>
  <P style=3D"MARGIN-LEFT: 0.5in"><FONT face=3DArial size=3D2><SPAN=20
  style=3D"FONT-SIZE: 10pt; FONT-FAMILY: Arial">Eve Chow , CISSP,=20
  CISA<o:p></o:p></SPAN></FONT></P>
  <P style=3D"MARGIN-LEFT: 0.5in"><FONT face=3DArial size=3D2><SPAN=20
  style=3D"FONT-SIZE: 10pt; FONT-FAMILY: Arial">Project=20
  Manager<o:p></o:p></SPAN></FONT></P>
  <P style=3D"MARGIN-LEFT: 0.5in"><FONT face=3DArial size=3D2><SPAN=20
  style=3D"FONT-SIZE: 10pt; FONT-FAMILY: Arial">Baltimore Technologies=20
  Limited<o:p></o:p></SPAN></FONT></P>
  <P style=3D"MARGIN-LEFT: 0.5in"><FONT face=3D"Times New Roman" =
size=3D2><SPAN=20
  style=3D"FONT-SIZE: 10pt">&nbsp;<o:p></o:p></SPAN></FONT></P>
  <P style=3D"MARGIN-LEFT: 0.5in"><FONT face=3D"Times New Roman" =
size=3D2><SPAN=20
  style=3D"FONT-SIZE: =
10pt">&nbsp;<o:p></o:p></SPAN></FONT></P></DIV></DIV></BLOCKQUOTE></BODY>=
</HTML>

------=_NextPart_000_0162_01C2C0B1.05A6D840--



Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h0K8qqn16724 for ietf-pkix-bks; Mon, 20 Jan 2003 00:52:52 -0800 (PST)
Received: from odin2.bull.net (odin2.bull.net [192.90.70.84]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h0K8qpo16717 for <[e-mail]>; Mon, 20 Jan 2003 00:52:51 -0800 (PST)
Received: from clbull.frcl.bull.fr (clbull.frcl.bull.fr [129.182.8.31]) by odin2.bull.net (8.9.3/8.9.3) with ESMTP id JAA17720; Mon, 20 Jan 2003 09:54:28 +0100
Received: from bull.net (frcls4013.frcl.bull.fr [129.182.108.120]) by clbull.frcl.bull.fr (8.9.2/8.9.1) with ESMTP id JAA19440; Mon, 20 Jan 2003 09:52:41 +0100
Message-ID: <[e-mail]>
Date: Mon, 20 Jan 2003 09:52:37 +0100
From: Denis Pinkas <[e-mail]>
Organization: Bull SA.
User-Agent: Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.0.1) Gecko/20020823 Netscape/7.0
X-Accept-Language: en-us, en, fr
MIME-Version: 1.0
To: Jean-Marc Desperrier <[e-mail]>
CC: [e-mail]
Subject: Re: "Basic" path-validation question
References: <011001c2be23$22209a50$0500a8c0@arport>            <[e-mail]>            <001901c2be38$99928e80$0500a8c0@arport> <[e-mail]> <003801c2bed3$bbcd5c50$0500a8c0@arport> <[e-mail]>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Jean-Marc,

(text deleted)

> But in fact your true question is how to distribute easily new trust 
> anchors, and this is not part of RFC3280.

This is part of RFC 2510 PKI Certificate Management Protocols.
See section 2.4 "Root CA key update".

> I've seen some people seriously try to find an answer to this, they came 
> up with the following kind of solutions, and I don't really see another 
> way to do it :

> - Have in the application one special trusted certificat that signs a 
> list of the CA that are part of your trust anchors in the RFC3280 
> meaning, and then a distribution channel to distribute new versions of 
> that signed message.

> You can use a SET-like chain mechanism to be able to regularly renew 
> that special certificate.

> Describing that kind of mechanism could make a very valid informational 
> RFC :-).

RFC 2510 is Standards Track.

Denis






Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h0K6vww25484 for ietf-pkix-bks; Sun, 19 Jan 2003 22:57:58 -0800 (PST)
Received: from nic.lp.se (nic.lp.se [212.247.5.91]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h0K6vuo25479 for <[e-mail]>; Sun, 19 Jan 2003 22:57:56 -0800 (PST)
Received: from localhost (217.215.93.181) by nic.lp.se (MX V5.3 VnHj) with ESMTP; Mon, 20 Jan 2003 07:56:00 +0100
Date: Mon, 20 Jan 2003 07:53:21 +0100 (CET)
Message-ID: <[e-mail]>
To: [e-mail]
CC: [e-mail]
Subject: Re: Another certificate policy question
From: Richard Levitte - VMS Whacker <[e-mail]>
In-Reply-To: <[e-mail]>
References: <[e-mail]>
X-URL: http://www.lp.se/
X-Waved: dead chicken, GNU emacs 21.2.2, Mew version 3.1
X-Mew: See http://www.mew.org/
X-Mailer: Mew version 3.1 on Emacs 21.2 / Mule 5.0 (SAKAKI)
MIME-Version: 1.0
Content-Type: Text/Plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

In message <[e-mail]> on Mon, 20 Jan 2003 14:49:59 +1300, [e-mail] (Peter Gutmann) said:

pgut001> Richard Levitte - VMS Whacker <[e-mail]> writes:
pgut001> >You can always invalidate the path...
pgut001> 
pgut001> Hmm, that'd be a bad idea, for two reasons.  Firstly, any
pgut001> user will see a cert being rejected for this reason as "The
pgut001> software is broken" rather than "The cert is invalid", and
pgut001> switch to software that ignores it, a class which appears to
pgut001> include everything else out there.  Secondly, it's a tragedy
pgut001> of the commons problem: Since everything else (apparently)
pgut001> ignores this stuff completely, I'm not going to stick my neck
pgut001> out and reject a cert because of it.

"tragedy" is the word.  It's also prepetuating certain errors, and we
might never see an improvement.

I'm suddenly quite depressed...

-- 
Richard Levitte     | http://richard.levitte.org/ | Spannv. 38, I
Levitte Programming | http://www.lp.se/           | S-168 35 Bromma
T: [phone] |                             | SWEDEN
     "Price, performance, quality...  choose the two you like"


Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h0K1xYj19402 for ietf-pkix-bks; Sun, 19 Jan 2003 17:59:34 -0800 (PST)
Received: from hermes.cs.auckland.ac.nz (hermes.cs.auckland.ac.nz [130.216.35.151]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h0K1xXo19398 for <[e-mail]>; Sun, 19 Jan 2003 17:59:33 -0800 (PST)
Received: from medusa01.cs.auckland.ac.nz (medusa01.cs.auckland.ac.nz [130.216.34.60]) by hermes.cs.auckland.ac.nz (8.12.4/8.12.4) with ESMTP id h0K1xVmv031501; Mon, 20 Jan 2003 14:59:31 +1300
Received: (from pgut001@localhost) by medusa01.cs.auckland.ac.nz (8.11.6/8.11.6) id h0K1xVS21494; Mon, 20 Jan 2003 14:59:31 +1300
Date: Mon, 20 Jan 2003 14:59:31 +1300
Message-Id: <[e-mail]>
From: [e-mail] (Peter Gutmann)
To: [e-mail], [e-mail], [e-mail]
Subject: Re: Another certificate policy question
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

"Joel S. Kazin" <[e-mail]> writes:

>There is a slight discrepancy between the text of RFC 3280 and the ASN.1
>notation for the type.
>
>  "This specification defines two policy qualifier types for use by
>    certificate policy writers and certificate issuers.  The qualifier
>    types are the CPS Pointer and User Notice qualifiers.
>
>    The CPS Pointer qualifier contains a pointer to a Certification
>    Practice Statement (CPS) published by the CA.  The pointer is in the
>    form of a URI.  Processing requirements for this qualifier are a
>    local matter.  No action is mandated by this specification regardless
>    of the criticality value asserted for the extension." (RFC 3280)
>
>The RFC clearly is talking about a single CPS pointer.

Hmm, I'm not so sure.  It says there's a single CPS pointer in the CPSuri, but
since the qualifiers are a SEQUENCE OF you could in theory have hundreds of
them.

[Insert standard gripe pointing out that if PKIX RFCs used currently valid
 ASN.1, this wouldn't be a problem since you could specify a uniqueness
 constraint in the ASN.1 to make it clear]

>In any event such a certificate is an error. 

I think opinion is divided on this matter.

Peter.


Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h0K1vN019372 for ietf-pkix-bks; Sun, 19 Jan 2003 17:57:23 -0800 (PST)
Received: from figg.securenet.com.au (ns2.isecure.com.au [202.125.4.72]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h0K1vKo19368 for <[e-mail]>; Sun, 19 Jan 2003 17:57:22 -0800 (PST)
Received: from iron.securenet.com.au (iron.securenet.com.au [202.125.4.94]) by figg.securenet.com.au (8.12.5/8.12.5/Debian-1) with ESMTP id h0K1v7Oq031741; Mon, 20 Jan 2003 12:57:08 +1100
Received: (from uucp@localhost) by iron.securenet.com.au (8.12.6/8.12.6) id h0K1v7to003397; Mon, 20 Jan 2003 12:57:07 +1100 (EST)
X-Authentication-Warning: iron.securenet.com.au: uucp set sender to <[e-mail]> using -f
Received: from nodnsquery(10.11.3.10) by iron.securenet.com.au via csmap (V6.0) id srcAAApQaGOg; Mon, 20 Jan 03 12:57:07 +1100
Received: from atlas.securenet.com.au (localhost [127.0.0.1]) by gibbons.securenet.com.au (8.12.3/8.12.3/Debian -4) with ESMTP id h0K1toI2016832; Mon, 20 Jan 2003 12:57:00 +1100
Received: from AMALTHEA.securenet.com.au ([192.168.100.30]) by atlas.securenet.com.au with Microsoft SMTPSVC(5.0.2195.4905); Mon, 20 Jan 2003 12:56:11 +1100
content-class: urn:content-classes:message
Subject: RE: "Basic" path-validation question
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Date: Mon, 20 Jan 2003 12:53:33 +1100
X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3
Message-ID: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: "Basic" path-validation question
Thread-Index: AcK+MQomQwPRyxXKQ3myZ/sT26ktKwB9YXzw
From: "James Jing" <[e-mail]>
To: "Anders Rundgren" <[e-mail]>, <[e-mail]>
X-OriginalArrivalTime: 20 Jan 2003 01:56:11.0082 (UTC) FILETIME=[1B1B32A0:01C2C027]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id h0K1vNo19369
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

So you really want to check whether a certificate is valid for A PURPOSE. I suppose this is beyond general path validation, but it definitely is a real-world issue.

My suggested approach would be to query your validation server/library by indicating how the certificate is going to be used, perhaps using a policy identifier. 

Regards

James Jing


-----Original Message-----
From: Anders Rundgren [mailto:[e-mail]]
Sent: Friday, 17 January 2003 11:22 PM
To: Richard Levitte - VMS Whacker; [e-mail]
Subject: Re: "Basic" path-validation question



>> Below we have a little scheme where an RP have
>> "accepted" CA1 by "installing" the RootCA and CA1
>> in the trust-store:
>> 
>>      /CA1->EE_type1 (class 3 id)
>> RootCA-CA2->EE_type2 (low assurance e-mail)
>>      \CA3->EE_type3 (web-server-cert)
>> 
>> Now, the RP receives a message containing a path
>> of CA3 + EE_type3.
>> 
>> What should a conforming path-validation say about this?

>Since the RP already has RootCA in it's store, and supposedly trusts
>it, and it verifies CA3 which in turn verifies EE_type3, the path is
>validated.  No problemo.  Or did I miss something?

Nema problema.  Except for the fact that the RP probably only agreed
to accept class 3 id's and now got fooled by the path-validation.

Isn't this what we engineers call "broken" eh?

<snip>

Anders



Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h0K1o5K19278 for ietf-pkix-bks; Sun, 19 Jan 2003 17:50:05 -0800 (PST)
Received: from hermes.cs.auckland.ac.nz (hermes.cs.auckland.ac.nz [130.216.35.151]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h0K1o3o19274 for <[e-mail]>; Sun, 19 Jan 2003 17:50:03 -0800 (PST)
Received: from medusa01.cs.auckland.ac.nz (medusa01.cs.auckland.ac.nz [130.216.34.60]) by hermes.cs.auckland.ac.nz (8.12.4/8.12.4) with ESMTP id h0K1o0mv031332; Mon, 20 Jan 2003 14:50:00 +1300
Received: (from pgut001@localhost) by medusa01.cs.auckland.ac.nz (8.11.6/8.11.6) id h0K1nxT20264; Mon, 20 Jan 2003 14:49:59 +1300
Date: Mon, 20 Jan 2003 14:49:59 +1300
Message-Id: <[e-mail]>
From: [e-mail] (Peter Gutmann)
To: [e-mail], [e-mail]
Subject: Re: Another certificate policy question
Cc: [e-mail]
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Richard Levitte - VMS Whacker <[e-mail]> writes:
>In message <[e-mail]> on Fri, 17 Jan 2003 18:21:41 +1300, [e-mail] (Peter Gutmann) said:
>pgut001> Actually it's not really a question, more a
>pgut001> thinking-out-loud: I've just been sent yet another odd cert
>pgut001> which has a single policy OID but two different CPSes
>pgut001> associated with it as qualifiers.  This is valid according to
>pgut001> the RFC, but seems a bit odd.
>
>That *is* odd...  Do they cover different things, or do they specify roughly
>the same things but differently?

They're not in English, so they could both be saying "Death to the foreign
devils" for all I know.

>pgut001> I shudder to think what would be required to meaningfully
>pgut001> process some of the kitchenSinks I've seen if the critical
>pgut001> flag was set on them.
>
>You can always invalidate the path...

Hmm, that'd be a bad idea, for two reasons.  Firstly, any user will see a cert
being rejected for this reason as "The software is broken" rather than "The
cert is invalid", and switch to software that ignores it, a class which
appears to include everything else out there.  Secondly, it's a tragedy of the
commons problem: Since everything else (apparently) ignores this stuff
completely, I'm not going to stick my neck out and reject a cert because of
it.  For something critical like basicConstraints and, well, xxxConstraints in
general, I will risk having the software perceived as broken for rejecting
invalid certs that other software accepts, but for the kitchenSink add-ons,
where no-one can figure out the semantics anyway and I don't think anyone
apart from lawyers wanting to demonstrate due diligence even care, I'll just
follow the herd and accept any old thing.

Peter.


Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h0JJaLd12871 for ietf-pkix-bks; Sun, 19 Jan 2003 11:36:21 -0800 (PST)
Received: from email.certplus.com ([195.101.88.80]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h0JJaKo12867 for <[e-mail]>; Sun, 19 Jan 2003 11:36:20 -0800 (PST)
Received: from carbone.certplus.com (facteur.certplus.com [172.16.1.81]) by email.certplus.com (8.12.2+Sun/8.12.2) with ESMTP id h0JJaBft015088 for <[e-mail]>; Sun, 19 Jan 2003 20:36:11 +0100 (CET)
Received: from certplus.com ([192.168.212.166]) by carbone.certplus.com with Microsoft SMTPSVC(5.0.2195.2966); Sun, 19 Jan 2003 20:36:12 +0100
Message-ID: <[e-mail]>
Date: Sun, 19 Jan 2003 20:39:48 +0100
From: Jean-Marc Desperrier <[e-mail]>
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.3b) Gecko/20030101
X-Accept-Language: fr, en, en-us, ja
MIME-Version: 1.0
To: [e-mail]
Subject: Re: "Basic" path-validation question
References: <011001c2be23$22209a50$0500a8c0@arport>            <[e-mail]>            <001901c2be38$99928e80$0500a8c0@arport> <[e-mail]> <003801c2bed3$bbcd5c50$0500a8c0@arport>
In-Reply-To: <003801c2bed3$bbcd5c50$0500a8c0@arport>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-OriginalArrivalTime: 19 Jan 2003 19:36:12.0382 (UTC) FILETIME=[0605A7E0:01C2BFF2]
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Anders Rundgren a dit :

>>RFC3280 says nothing on how you get hold of the certificates
>>you use for validation, so yes, it's outside the scope of that
>>RFC (unless I've done a miserable job reading it).
>>    
>>
>I think you have done a good job reading it, which means that my
>"basic" question apparently is completely outside of the realm of
>PKIX-standards.  Close to UNBELIEVABLE  IMNSHO.
>
Very believable, because your question is not basic.

The premice on which you start is that the organisation can not be 
tailored to easier what you want to do, and that they will not be an 
application level input restricting which kind of certificate you want 
to trust. It's no so surprising you end up with no solution.

What you started with was distributing a root CA and one of its sub-CA.
This mean you prived two trust anchors, and they are added to each 
other, the second can not somehow restrict the application of the first.
In fact, as the root CA includes all the domain of the sub-CA, it was 
not necessary to provide the sub-CA.
If you don't want to trust everything the root signs, then *don't* 
distribute the root, or you MUST  use a higher level mechanism to 
restrict what is trusted.
This is the way X509 PKI works, and it has the definitive advantage of 
being simple !

If it was needed to distribute the subCA in addition to the root, 
because the clients don't always provide the full path to the root, then 
when the subCA is replaced, the clients will still not provide the full 
path, so you will *need* to distribute the new sub-CA.

So you won nothing by distributing the root.
If you want to trust only the domain of the subCA, then only distribute 
the sub-CA.

If you want to be able to renew easily the sub-CA, then one solution can 
be to create an intermediate CA between the root and the current sub, 
that only signs the sub-CA you want to trust.
This is what I meant by tailoring the organisation to easier what you 
want to do.

But in fact your true question is how to distribute easily new trust 
anchors, and this is not part of RFC3280.

I've seen some people seriously try to find an answer to this, they came 
up with the following kind of solutions, and I don't really see another 
way to do it :
- Have in the application one special trusted certificat that signs a 
list of the CA that are part of your trust anchors in the RFC3280 
meaning, and then a distribution channel to distribute new versions of 
that signed message.

You can use a SET-like chain mechanism to be able to regularly renew 
that special certificate.

Describing that kind of mechanism could make a very valid informational 
RFC :-).




Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h0JJNWj12570 for ietf-pkix-bks; Sun, 19 Jan 2003 11:23:32 -0800 (PST)
Received: from aeteurope.nl (mail.totaalnet.nl [212.136.40.4]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h0JJNUo12566 for <[e-mail]>; Sun, 19 Jan 2003 11:23:31 -0800 (PST)
Received: from windowsxp [212.187.10.40] by aeteurope.nl with ESMTP (SMTPD32-7.13) id ABA2276D012A; Sun, 19 Jan 2003 20:25:22 +0100
Message-ID: <000b01c2bff1$6654eb20$0201a8c0@windowsxp>
From: "Haaino Beljaars" <[e-mail]>
To: <[e-mail]>
Subject: Best rollover practise
Date: Sun, 19 Jan 2003 20:31:43 +0100
Organization: A.E.T. Europe B.V.
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 6.00.2800.1106
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Hi,

Hope somebody can tell me more about 'rollover' practises.

I have the following example: I have a Root CA which has a validity time of
100 days, which issues directly to end-users. The end-users get an end-user
certificate which has a validity time of 50 days (this is no be change the
half of the Root CA validity time). During the life time of the Root CA an
end-user can receive a maximum of two end-user certificates.

My questions are:
* if I issue an end-user certificate on the 25th day of the life time of the
Root CA, and the end-user comes back for an update of his certificate (on
day 75), should I issue an end-user certificate of 50 days or 25 days?
* May I issue certificates which have a longer life time then the issuing CA
if I know that at the end of the life time of the CA I'll perform an
rollover on the CA?
* An other scenario could be that I already rollover the issuing CA on day
50 of the Root CA lifetime, and start issuing end-user certificates from
that CA instead. But then I have 2 CA which seem to the outside world as the
same.

Any suggestions?

Best regards,
Haaino



Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h0INb2f09947 for ietf-pkix-bks; Sat, 18 Jan 2003 15:37:02 -0800 (PST)
Received: from web40614.mail.yahoo.com (web40614.mail.yahoo.com [66.218.78.151]) by above.proper.com (8.11.6/8.11.3) with SMTP id h0INb0o09941 for <[e-mail]>; Sat, 18 Jan 2003 15:37:00 -0800 (PST)
Message-ID: <[e-mail]>
Received: from [12.254.35.162] by web40614.mail.yahoo.com via HTTP; Sat, 18 Jan 2003 15:36:58 PST
Date: Sat, 18 Jan 2003 15:36:58 -0800 (PST)
From: Camile Howe <[e-mail]>
Subject: Re: "Basic" path-validation question
To: Anders Rundgren <[e-mail]>, Richard Levitte - VMS Whacker <[e-mail]>
Cc: [e-mail], [e-mail]
In-Reply-To: <003801c2bed3$bbcd5c50$0500a8c0@arport>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Design "faith" to support a policy-mechanism to permit
automation...

<<<excerpt> of a Anders/Richard snip>>>
> Well, the PnP PKI specification which I sent to you
> is an indication
> of what I'm looking for.  However, I don't have much
> faith in the
> policy-mechanism as the foundation for "automation",
> I rather see
> that a trust-administrator (not a user) surfs to
> SuckerTrust's
> web-site and after reading some 10 lines or so,
> clicks on the link
> that starts downloading the path for the SuckerTrust
> "Premimum ID".

anders - Believe that this above referenced,
"admin-reliant" approach would preclude
wide-usage/acceptance since it sounds too admin
maintenance intensive...This thread sounds like we're
relying heavily on a "admin in the middle"...as
default, rather than the exception? 
 "trust-administrator (not a user) surfs to
SuckerTrust's web-site" should be an exception
required when a "new" vendor ID comes out ... I can't
perceive (large-scale company) Admins expending the
"implied" maintenance time on adding "trusted
IDs/certs".  e.g. Our company (165,000 nodes plus)
relies heavily on centralized management and would
expect our forum to come up with "centralized and
automation approach" that reduces administrator time
and potential errors (this has potential to get to the
core of securing network).    

elieve a PKI standard library with automation built-in
has to be the goal.  Sure...I agree it ultimately gets
down to an admin making the decision as to what the
applications/PKI standard library references, but
surely this is done from a centralized location such a
file referenced by the applications/PKI library API
(API supports the policy-mechanism for apps to
automate), so the admin pre-configures these upfront
and adds to this repository as required.  
If we look towards (allow for) a design of this type
then the "automated decision" can be embedded in the
applications deployed... believe we can gain
industry-wide support and usage... 
>From the cadre of business/industry forums I
follow.....Suspect that shortly the future holds ...
web-centric (CD distribution) centralized management
of "registered" companies so admins can go to a common
place where they know the IDs are in fact,
pre-screened, registered and validated vendor IDs they
can download on a large scale, rather than doing one
at at a time.

Or am I mis-understanding the "intended"
implementation?

Camile

--- Anders Rundgren <[e-mail]> wrote:
> 
> Richard,
> 
> <snip>
> 

> >Actually, the problem goes one step further; it
> goes to the user or
> >the local admin.  A trust can't be decided upon by
> the application or
> >by the PKI library you use, or even by the OS.  It
> has to go back to
> >the user (or admin), and the user (or admin) has to
> decide where to
> >put his or her trust.  The way I udnerstand PKI,
> trust is ultimately
> >placed upon policies and trust anchors that
> implement those policies.
> >What is called "Class 3" is really a question of
> the policy attached
> >to those certificates.  The same thing goes for
> "Premium grade".  Are
> >those two supposed to be the same?  How would you
> know that unless you
> >read the policies they are the names for?
> 
> You seem to have the answers already :-)  Mines are
> identical...
> 

> >Just out of curiosity, what exactly were you
> thinking of doing?  Some
> >kind of automatic parse of some name somewhere into
> which you would
> >put some level of trust?  Or were you going to
> define some kind of
> >standard extension that would express something
> called "Class 3" and
> >decide for everyone exactly what that means?  Or
> something else?
> 
> Well, the PnP PKI specification which I sent to you
> is an indication
> of what I'm looking for.  However, I don't have much
> faith in the
> policy-mechanism as the foundation for "automation",
> I rather see
> that a trust-administrator (not a user) surfs to
> SuckerTrust's
> web-site and after reading some 10 lines or so,
> clicks on the link
> that starts downloading the path for the SuckerTrust
> "Premimum ID".
> 
> >What is really needed is to have a standard PKI
> library that supports
> >some kind of configuration at user and admin level,
> that would define
> >exactly what trust the user or admin places in
> different policies and
> >trust anchors.  If all applications use that same
> library, that trust
> >configuration would apply on all those
> applications.
> 
> I agree but I want to extend this to the realm of
> standard if possible.
> 
> >Hmm, I'm getting ideas for OpenSSL here...
> 
> Input is always appreciated!
> 
> The only REAL alternative to improvements in the
> area of trust 
> administration is IMHO that we forget about the
> whole issue and
> starts to rely on a very limited set of TTP issuers
> whos roots
> are pre-installed by software vendors.
> 
> If the requirement is that users must understand PKI
> to use it,
> PKI will never work on a mojor scale.  Users should
> not even
> have to know what a PKI is!!! 
> "Trust-administrators" may know
> just a little bit more...
> 
> cheers
> Anders
> 


__________________________________________________
Do you Yahoo!?
Yahoo! Mail Plus - Powerful. Affordable. Sign up now.
http://mailplus.yahoo.com


Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h0I9TB105615 for ietf-pkix-bks; Sat, 18 Jan 2003 01:29:11 -0800 (PST)
Received: from mailb.telia.com (mailb.telia.com [194.22.194.6]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h0I9T8o05600 for <[e-mail]>; Sat, 18 Jan 2003 01:29:08 -0800 (PST)
Received: from arport (h119n2fls31o1122.telia.com [212.181.142.119]) by mailb.telia.com (8.12.5/8.12.5) with SMTP id h0I9T65U006565; Sat, 18 Jan 2003 10:29:06 +0100 (CET)
X-Original-Recipient: [e-mail]
Message-ID: <003801c2bed3$bbcd5c50$0500a8c0@arport>
From: "Anders Rundgren" <[e-mail]>
To: "Richard Levitte - VMS Whacker" <[e-mail]>
Cc: <[e-mail]>, <[e-mail]>
References: <011001c2be23$22209a50$0500a8c0@arport>            <[e-mail]>            <001901c2be38$99928e80$0500a8c0@arport> <[e-mail]>
Subject: Re: "Basic" path-validation question
Date: Sat, 18 Jan 2003 10:26:51 +0100
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.50.4133.2400
X-MIMEOLE: Produced By Microsoft MimeOLE V5.50.4133.2400
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Richard,

<snip>

>> If this "automation" is outside of RFC3280 is though
>> outside of my knowledge.

>RFC3280 says nothing on how you get hold of the certificates
>you use for validation, so yes, it's outside the scope of that
>RFC (unless I've done a miserable job reading it).

I think you have done a good job reading it, which means that my
"basic" question apparently is completely outside of the realm of
PKIX-standards.  Close to UNBELIEVABLE  IMNSHO.

>> Rickard: I can hardly see that policy-extensions
>> would solve this without moving the problem into
>> "app-space".  E.g. "Class 3" is one CAs way of
>> expressing things,  "Premium grade" is another likely
>> form.

>Actually, the problem goes one step further; it goes to the user or
>the local admin.  A trust can't be decided upon by the application or
>by the PKI library you use, or even by the OS.  It has to go back to
>the user (or admin), and the user (or admin) has to decide where to
>put his or her trust.  The way I udnerstand PKI, trust is ultimately
>placed upon policies and trust anchors that implement those policies.
>What is called "Class 3" is really a question of the policy attached
>to those certificates.  The same thing goes for "Premium grade".  Are
>those two supposed to be the same?  How would you know that unless you
>read the policies they are the names for?

You seem to have the answers already :-)  Mines are identical...

>I might some day define a policy that I call "Class 3".  Will that be
>the same as what you call "Class 3"?  I have strong doubts about that.

Me too.

>Just out of curiosity, what exactly were you thinking of doing?  Some
>kind of automatic parse of some name somewhere into which you would
>put some level of trust?  Or were you going to define some kind of
>standard extension that would express something called "Class 3" and
>decide for everyone exactly what that means?  Or something else?

Well, the PnP PKI specification which I sent to you is an indication
of what I'm looking for.  However, I don't have much faith in the
policy-mechanism as the foundation for "automation", I rather see
that a trust-administrator (not a user) surfs to SuckerTrust's
web-site and after reading some 10 lines or so, clicks on the link
that starts downloading the path for the SuckerTrust "Premimum ID".

>What is really needed is to have a standard PKI library that supports
>some kind of configuration at user and admin level, that would define
>exactly what trust the user or admin places in different policies and
>trust anchors.  If all applications use that same library, that trust
>configuration would apply on all those applications.

I agree but I want to extend this to the realm of standard if possible.

>Hmm, I'm getting ideas for OpenSSL here...

Input is always appreciated!

The only REAL alternative to improvements in the area of trust 
administration is IMHO that we forget about the whole issue and
starts to rely on a very limited set of TTP issuers whos roots
are pre-installed by software vendors.

If the requirement is that users must understand PKI to use it,
PKI will never work on a mojor scale.  Users should not even
have to know what a PKI is!!!  "Trust-administrators" may know
just a little bit more...

cheers
Anders



Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h0HM7OZ29309 for ietf-pkix-bks; Fri, 17 Jan 2003 14:07:24 -0800 (PST)
Received: from nic.lp.se (nic.lp.se [212.247.5.91]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h0HM7Mo29305 for <[e-mail]>; Fri, 17 Jan 2003 14:07:22 -0800 (PST)
Received: from localhost (217.215.93.181) by nic.lp.se (MX V5.3 VnHj) with ESMTP; Fri, 17 Jan 2003 23:05:38 +0100
Date: Fri, 17 Jan 2003 23:03:11 +0100 (CET)
Message-ID: <[e-mail]>
To: [e-mail]
CC: [e-mail], [e-mail]
Subject: Re: "Basic" path-validation question
From: Richard Levitte - VMS Whacker <[e-mail]>
In-Reply-To: <001901c2be38$99928e80$0500a8c0@arport>
References: <011001c2be23$22209a50$0500a8c0@arport> <[e-mail]> <001901c2be38$99928e80$0500a8c0@arport>
X-URL: http://www.lp.se/
X-Waved: dead chicken, GNU emacs 21.2.2, Mew version 3.1
X-Mew: See http://www.mew.org/
X-Mailer: Mew version 3.1 on Emacs 21.2 / Mule 5.0 (SAKAKI)
MIME-Version: 1.0
Content-Type: Text/Plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

In message <001901c2be38$99928e80$0500a8c0@arport> on Fri, 17 Jan 2003 15:55:34 +0100, "Anders Rundgren" <[e-mail]> said:

anders.rundgren> Jean-Marc,
anders.rundgren> 
anders.rundgren> >It should be possible to install only CA1 as a trust
anders.rundgren> >anchor, there is no requirement in the
anders.rundgren> >path-validation that the trust anchor be
anders.rundgren> >self-signed. 
anders.rundgren> 
anders.rundgren> Although possible, this will make CA1 renewals
anders.rundgren> require reinstallation which it does not necessarily
anders.rundgren> require if it is connected to a higher-level root.

A very valid point which is often forgotten.

anders.rundgren> If this "automation" is outside of RFC3280 is though
anders.rundgren> outside of my knowledge.

RFC3280 says nothing on how you get hold of the certificates you use
for validation, so yes, it's outside the scope of that RFC (unless
I've done a miserable job reading it).

anders.rundgren> Rickard: I can hardly see that policy-extensions
anders.rundgren> would solve this without moving the problem into
anders.rundgren> "app-space".  E.g. "Class 3" is one CAs way of
anders.rundgren> expressing things,  "Premium grade" is another likely
anders.rundgren> form.

Actually, the problem goes one step further; it goes to the user or
the local admin.  A trust can't be decided upon by the application or
by the PKI library you use, or even by the OS.  It has to go back to
the user (or admin), and the user (or admin) has to decide where to
put his or her trust.  The way I udnerstand PKI, trust is ultimately
placed upon policies and trust anchors that implement those policies.
What is called "Class 3" is really a question of the policy attached
to those certificates.  The same thing goes for "Premium grade".  Are
those two supposed to be the same?  How would you know that unless you
read the policies they are the names for?

I might some day define a policy that I call "Class 3".  Will that be
the same as what you call "Class 3"?  I have strong doubts about that.

Just out of curiosity, what exactly were you thinking of doing?  Some
kind of automatic parse of some name somewhere into which you would
put some level of trust?  Or were you going to define some kind of
standard extension that would express something called "Class 3" and
decide for everyone exactly what that means?  Or something else?

What is really needed is to have a standard PKI library that supports
some kind of configuration at user and admin level, that would define
exactly what trust the user or admin places in different policies and
trust anchors.  If all applications use that same library, that trust
configuration would apply on all those applications.

Hmm, I'm getting ideas for OpenSSL here...

-- 
Richard Levitte     | http://richard.levitte.org/ | Spannv. 38, I
Levitte Programming | http://www.lp.se/           | S-168 35 Bromma
T: [phone] |                             | SWEDEN
     "Price, performance, quality...  choose the two you like"


Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h0HLrgD29025 for ietf-pkix-bks; Fri, 17 Jan 2003 13:53:42 -0800 (PST)
Received: from nic.lp.se (nic.lp.se [212.247.5.91]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h0HLrdo29020 for <[e-mail]>; Fri, 17 Jan 2003 13:53:40 -0800 (PST)
Received: from localhost (217.215.93.181) by nic.lp.se (MX V5.3 VnHj) with ESMTP; Fri, 17 Jan 2003 22:51:43 +0100
Date: Fri, 17 Jan 2003 22:49:17 +0100 (CET)
Message-ID: <[e-mail]>
To: [e-mail]
CC: [e-mail], [e-mail]
Subject: Re: "Basic" path-validation question
From: Richard Levitte - VMS Whacker <[e-mail]>
In-Reply-To: <[e-mail]>
References: <[e-mail]> <011001c2be23$22209a50$0500a8c0@arport> <[e-mail]>
X-URL: http://www.lp.se/
X-Waved: dead chicken, GNU emacs 21.2.2, Mew version 3.1
X-Mew: See http://www.mew.org/
X-Mailer: Mew version 3.1 on Emacs 21.2 / Mule 5.0 (SAKAKI)
MIME-Version: 1.0
Content-Type: Text/Plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

In message <[e-mail]> on Fri, 17 Jan 2003 14:38:46 +0100, Jean-Marc Desperrier <[e-mail]> said:

jean-marc.desperrier> What is broken is the application, if it
jean-marc.desperrier> *requires* to install both RootCA and CA1 in
jean-marc.desperrier> order to trust EE_type1.

Yet, most software do that, *or* install just RootCA and expect to get
every intermediate CA certificate along with the messages sent to it
(that happens with S/MIME, and many SSL-enabled servers present a
whole chain except for the root itself).  From a purely PKI point of
view, both methods are broken, all needed certificates should be
retrievable from one or several publically available stores...

jean-marc.desperrier> It should be possible to install only CA1 as a
jean-marc.desperrier> trust anchor, there is no requirement in the
jean-marc.desperrier> path-validation that the trust anchor be
jean-marc.desperrier> self-signed.

Actually, I've heard quite different opinions on that.  Some people
assume that the trust anchors are self-signed.  I see no real problem
with that kind of thinking...  If nothing else, you can always set up
your own small CA, certify any other CA you trust with your CA's key,
and have your CA as trust anchor...

jean-marc.desperrier> If the application is OpenSSL, you were talking
jean-marc.desperrier> with someone who is supposed to be able to do
jean-marc.desperrier> something about it :-)

I've certain plans in this area for OpenSSL.  I hope to have most of
it ready for 0.9.8.  As it is right now, it has rather crappy
verification routines, as well as the lookup of certificates (it's
in-memory, and lacks of certain needed features).  No policy checking
(as far as I've been able to see and test), and no support for trees
of certificate chains (i.e. it doesn't support the possibility for any
specific subject to have more than one valid certificate at a time...

-- 
Richard Levitte     | http://richard.levitte.org/ | Spannv. 38, I
Levitte Programming | http://www.lp.se/           | S-168 35 Bromma
T: [phone] |                             | SWEDEN
     "Price, performance, quality...  choose the two you like"



Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h0HIgwQ24987 for ietf-pkix-bks; Fri, 17 Jan 2003 10:42:58 -0800 (PST)
Received: from prv-mail20.provo.novell.com (prv-mail20.provo.novell.com [137.65.81.122]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h0HIguo24983 for <[e-mail]>; Fri, 17 Jan 2003 10:42:56 -0800 (PST)
Received: from INET-PRV-MTA by prv-mail20.provo.novell.com with Novell_GroupWise; Fri, 17 Jan 2003 11:41:39 -0700
Message-Id: <[e-mail]>
X-Mailer: Novell GroupWise Internet Agent 6.5.0 
Date: Fri, 17 Jan 2003 11:42:41 -0700
From: "Tammy Green" <[e-mail]>
To: <[e-mail]>, <[e-mail]>
Subject: Re: Q. Automatic certificate selection for signing
Mime-Version: 1.0
Content-Type: multipart/alternative; boundary="=_431C5873.12730EF5"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

This is a MIME message. If you are reading this text, you may want to 
consider changing to a mail reader or gateway that understands how to 
properly handle MIME multipart messages.

--=_431C5873.12730EF5
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit

:)  No....  It's just a bad habit I developed from talking to non-pki
folk where absolute precision gets in the way sometimes.  
 
Obviously, I meant that the private key would be used to sign the data.
 The user/software would use the certificate(s) to determine which
certificate-and-private-key set would be used to perform the signature. 
The signature would be created using the private key, but only after the
matching certificate had been checked for validity and to be sure that
it could be used for signatures.  The certificate associated with the
private key would probably be tacked on to the signed data such that the
relying party could validate the signature using the certificate.
 


>>> Vadim Fedukovich <[e-mail]> 1/17/03 2:05:03 AM >>>


Let me just say I'm impressed we are still talking about "using
certificates
for signing". To sign, the private key is used. At least for pkcs7.
Certificate is used while verification.

did I miss something?

On Thu, Jan 16, 2003 at 05:17:39PM -0700, Tammy Green wrote:
> In trying to design something like this a while back, I found that a
> blanket statement of "use this certificate for application x" was
not
> always sufficient.  Two areas where the concept broke down were:



--=_431C5873.12730EF5
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 8bit

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META http-equiv=Content-Type content="text/html; charset=unicode">
<META content="MSHTML 6.00.2719.2200" name=GENERATOR></HEAD>
<BODY style="MARGIN: 4px 4px 1px; FONT: 10pt Verdana">
<DIV>:)&nbsp; No....&nbsp; It's just a bad habit I developed&nbsp;from talking 
to non-pki folk where absolute&nbsp;precision gets in the&nbsp;way 
sometimes.&nbsp; </DIV>
<DIV>&nbsp;</DIV>
<DIV>Obviously, I meant that the private key would be used to sign the 
data.&nbsp;&nbsp;The user/software would&nbsp;use&nbsp;the certificate(s) to 
determine which certificate-and-private-key set would be used to perform the 
signature.&nbsp; The signature would be created using the private key, but only 
after the matching certificate had been checked for validity and to be sure that 
it could be used for signatures.&nbsp; The certificate associated with the 
private key would probably be tacked on to the signed data such that the relying 
party could validate the signature using the certificate.</DIV>
<DIV>&nbsp;</DIV>
<DIV><BR><BR>&gt;&gt;&gt; Vadim Fedukovich &lt;[e-mail]&gt; 1/17/03 2:05:03 
AM &gt;&gt;&gt;<BR></DIV>
<DIV><BR>Let me just say I'm impressed we are still talking about "using 
certificates<BR>for signing". To sign, the private key is used. At least for 
pkcs7.<BR>Certificate is used while verification.<BR><BR>did I miss 
something?<BR><BR>On Thu, Jan 16, 2003 at 05:17:39PM -0700, Tammy Green 
wrote:<BR>&gt; In trying to design something like this a while back, I found 
that a<BR>&gt; blanket statement of "use this certificate for application x" was 
not<BR>&gt; always sufficient.&nbsp; Two areas where the concept broke down 
were:<BR><BR></DIV></BODY></HTML>

--=_431C5873.12730EF5--


Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h0HF6jv15696 for ietf-pkix-bks; Fri, 17 Jan 2003 07:06:45 -0800 (PST)
Received: from mtiwmhc11.worldnet.att.net (mtiwmhc11.worldnet.att.net [204.127.131.115]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h0HF6io15692 for <[e-mail]>; Fri, 17 Jan 2003 07:06:44 -0800 (PST)
Received: from Chokhani ([12.91.133.86]) by mtiwmhc11.worldnet.att.net (InterMail vM.5.01.05.12 201-253-122-126-112-20020820) with ESMTP id <20030117150634.HIUM9286.mtiwmhc11.worldnet.att.net@Chokhani>; Fri, 17 Jan 2003 15:06:34 +0000
From: "Santosh Chokhani" <[e-mail]>
To: "'Peter Gutmann'" <[e-mail]>, <[e-mail]>
Subject: RE: Another certificate policy question
Date: Fri, 17 Jan 2003 10:06:54 -0500
Message-ID: <000001c2be3a$1a1bb800$56855b0c@Chokhani>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook, Build 10.0.4510
Importance: Normal
In-Reply-To: <[e-mail]>
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id h0HF6jo15693
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Peter:

I think a certificate could be valid for a variety of policies, but should
be issued under a single CPS.  Thus, there should be a single CPS pointer.

This assumes that the certificate does not have subject directory attribute
extension with different practices for validating and asserting multiple
roles and privileges.

I do not understand the CA having multiple CPS's for multiple policies.  CA
should have a single CPS for multiple policies.  But, may be the CA is using
different CPS for different policies.  Even in that case, the certificate
was generated using only one CPS.

In short, I think it should have a single CPS pointer.

-----Original Message-----
From: [e-mail] [mailto:[e-mail]] On
Behalf Of Peter Gutmann
Sent: Friday, January 17, 2003 12:22 AM
To: [e-mail]
Subject: Another certificate policy question



Actually it's not really a question, more a thinking-out-loud: I've just
been sent yet another odd cert which has a single policy OID but two
different CPSes associated with it as qualifiers.  This is valid according
to the RFC, but seems a bit odd.

Given that the policy extension has become a kitchen-sink extension into
which people are just shovelling everything they can think of, perhaps we
should change the name to kitchenSink (to match the SINK RR) and define a
new policy extension that can't contain anything more than policy OIDs.  I
shudder to think what would be required to meaningfully process some of the
kitchenSinks I've seen if the critical flag was set on them.

Peter.



Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h0HEwae15292 for ietf-pkix-bks; Fri, 17 Jan 2003 06:58:36 -0800 (PST)
Received: from maile.telia.com (maile.telia.com [194.22.190.16]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h0HEwZo15284 for <[e-mail]>; Fri, 17 Jan 2003 06:58:35 -0800 (PST)
Received: from arport (h119n2fls31o1122.telia.com [212.181.142.119]) by maile.telia.com (8.12.5/8.12.5) with SMTP id h0HEwYmZ022231; Fri, 17 Jan 2003 15:58:34 +0100 (CET)
X-Original-Recipient: [e-mail]
Message-ID: <001901c2be38$99928e80$0500a8c0@arport>
From: "Anders Rundgren" <[e-mail]>
To: "Jean-Marc Desperrier" <[e-mail]>
Cc: "Richard Levitte - VMS Whacker" <[e-mail]>, <[e-mail]>
References: <007501c2be00$bb24be20$0500a8c0@arport> <[e-mail]> <011001c2be23$22209a50$0500a8c0@arport> <[e-mail]>
Subject: Re: "Basic" path-validation question
Date: Fri, 17 Jan 2003 15:55:34 +0100
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.50.4133.2400
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Jean-Marc,

>What is broken is the application, if it *requires* to install both 
>RootCA and CA1 in order to trust EE_type1.

Ahh, you "solved" the problem by disconnecting the CAs.
But that is an entirely different scenario.

>It should be possible to install only CA1 as a trust anchor, there is no 
>requirement in the path-validation that the trust anchor be self-signed.

Although possible, this will make CA1 renewals require reinstallation
which it does not necessarily require if it is connected to a higher-level
root.  If this "automation" is outside of RFC3280 is though outside of my
knowledge.

>If the application is OpenSSL, you were talking with someone who is 
>supposed to be able to do something about it :-)

I'm more in thinking in terms of RFC-level handling.

Rickard: I can hardly see that policy-extensions would solve this
without moving the problem into "app-space".  E.g. "Class 3"
is one CAs way of expressing things,  "Premium grade" is
another likely form. 

Anders

----- Original Message ----- 
From: "Jean-Marc Desperrier" <[e-mail]>
To: "Anders Rundgren" <[e-mail]>
Cc: "Richard Levitte - VMS Whacker" <[e-mail]>; <[e-mail]>
Sent: Friday, January 17, 2003 14:38
Subject: Re: "Basic" path-validation question



Anders Rundgren a dit :

>>>Below we have a little scheme where an RP have
>>>"accepted" CA1 by "installing" the RootCA and CA1
>>>in the trust-store:
>>>
>>>     /CA1->EE_type1 (class 3 id)
>>>RootCA-CA2->EE_type2 (low assurance e-mail)
>>>     \CA3->EE_type3 (web-server-cert)
>>>      
>>>
 > [...]

>Nema problema.  Except for the fact that the RP probably only agreed
>to accept class 3 id's and now got fooled by the path-validation.
>
>Isn't this what we engineers call "broken" eh?
>  
>
What is broken is the application, if it *requires* to install both 
RootCA and CA1 in order to trust EE_type1.

It should be possible to install only CA1 as a trust anchor, there is no 
requirement in the path-validation that the trust anchor be self-signed.

If the application is OpenSSL, you were talking with someone who is 
supposed to be able to do something about it :-)






Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h0HETEQ13818 for ietf-pkix-bks; Fri, 17 Jan 2003 06:29:14 -0800 (PST)
Received: from mail.slb.com (nammta01.sugar-land.nam.slb.com [163.188.150.130]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h0HETDo13812 for <[e-mail]>; Fri, 17 Jan 2003 06:29:13 -0800 (PST)
Received: from conversion-daemon.nammta01.sugar-land.nam.slb.com by nammta01.sugar-land.nam.slb.com (iPlanet Messaging Server 5.2 HotFix 1.06 (built Nov 15 2002)) id <[e-mail]> for [e-mail]; Fri, 17 Jan 2003 14:23:51 +0000 (GMT)
Received: from namems01.sugar-land.oilfield.slb.com (namems01.sugar-land.oilfield.slb.com [163.188.150.131]) by nammta01.sugar-land.nam.slb.com (iPlanet Messaging Server 5.2 HotFix 1.06 (built Nov 15 2002)) with ESMTP id <[e-mail]> for [e-mail]; Fri, 17 Jan 2003 14:23:50 +0000 (GMT)
Received: from conversion-daemon.namems01.sugar-land.oilfield.slb.com by namems01.sugar-land.oilfield.slb.com (iPlanet Messaging Server 5.1 HotFix 1.7 (built Nov  1 2002)) id <[e-mail]> for [e-mail]; Fri, 17 Jan 2003 14:23:33 +0000 (GMT)
Received: from SCHLUMBE-OITRVU.parsippany.sns.slb.com (vpnpool582.houston.sinet.slb.com [163.188.126.70]) by namems01.sugar-land.oilfield.slb.com (iPlanet Messaging Server 5.1 HotFix 1.7 (built Nov  1 2002)) with ESMTP id <[e-mail]>; Fri, 17 Jan 2003 14:22:17 +0000 (GMT)
Content-return: prohibited
Date: Fri, 17 Jan 2003 09:22:13 -0500
From: "Joel S. Kazin" <[e-mail]>
Subject: Re: Another certificate policy question
In-reply-to: <[e-mail]>
X-Sender: jkazin@163.188.150.131
To: [e-mail] (Peter Gutmann), [e-mail]
Message-id: <5.1.1.1.2.20030117090314.00aa6050@163.188.150.131>
MIME-version: 1.0
X-Mailer: QUALCOMM Windows Eudora Version 5.1.1
Content-type: text/plain; charset=us-ascii; format=flowed
Content-transfer-encoding: 7BIT
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

At 06:21 PM 1/17/2003 +1300, Peter Gutmann wrote:

>Actually it's not really a question, more a thinking-out-loud: I've just been
>sent yet another odd cert which has a single policy OID but two different
>CPSes associated with it as qualifiers.  This is valid according to the RFC,
>but seems a bit odd.

Odd indeed!  There is a slight discrepancy between the text of RFC 3280 and 
the ASN.1 notation for the type.

"This specification defines two policy qualifier types for use by
    certificate policy writers and certificate issuers.  The qualifier
    types are the CPS Pointer and User Notice qualifiers.

    The CPS Pointer qualifier contains a pointer to a Certification
    Practice Statement (CPS) published by the CA.  The pointer is in the
    form of a URI.  Processing requirements for this qualifier are a
    local matter.  No action is mandated by this specification regardless
    of the criticality value asserted for the extension." (RFC 3280)

The RFC clearly is talking about a single CPS pointer.

A few lines down the RFC gives the following ASN.1:

PolicyInformation ::= SEQUENCE {
         policyIdentifier   CertPolicyId,
         policyQualifiers   SEQUENCE SIZE (1..MAX) OF
                                 PolicyQualifierInfo OPTIONAL }

    CertPolicyId ::= OBJECT IDENTIFIER

    PolicyQualifierInfo ::= SEQUENCE {
         policyQualifierId  PolicyQualifierId,
         qualifier          ANY DEFINED BY policyQualifierId }

    -- policyQualifierIds for Internet policy qualifiers

    id-qt          OBJECT IDENTIFIER ::=  { id-pkix 2 }
    id-qt-cps      OBJECT IDENTIFIER ::=  { id-qt 1 }
    id-qt-unotice  OBJECT IDENTIFIER ::=  { id-qt 2 }

    PolicyQualifierId ::=
         OBJECT IDENTIFIER ( id-qt-cps | id-qt-unotice )

Which could carry OIDs for more than one CPS.

Once in a while you have to read the text of the RFC!   I once stumbled 
into a similar ambiguity in RFC 2459 concerning UTC Time.

In any event such a certificate is an error. Perhaps they intended to list 
two CPs and made an error. Can you find both documents from the OID or URI? 
Are they both CPSs or is one a CP?


>Given that the policy extension has become a kitchen-sink extension into which
>people are just shovelling everything they can think of, perhaps we should
>change the name to kitchenSink (to match the SINK RR) and define a new policy
>extension that can't contain anything more than policy OIDs.  I shudder to
>think what would be required to meaningfully process some of the kitchenSinks
>I've seen if the critical flag was set on them.
>
>Peter.

Senior Consultant
Technical Consulting Practice, Northeast Region
Schlumberger Network Solutions

[e-mail]
www.slb.com/nws

35 Waterview Blvd.
Suite 210
Parsippany, NJ 07054-1200
USA

Phone  [phone]
Mobile  [phone]



Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h0HEKDd12265 for ietf-pkix-bks; Fri, 17 Jan 2003 06:20:13 -0800 (PST)
Received: from hubie.hubbardind.com (mail.hubbardsupply.com [65.245.100.65]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h0HEKCo12256 for <[e-mail]>; Fri, 17 Jan 2003 06:20:12 -0800 (PST)
Received: by HUBIE.hubbardsupply.com with Internet Mail Service (5.5.2653.19) id <Y0ST0X73>; Fri, 17 Jan 2003 09:20:12 -0500
Message-ID: <[e-mail]>
From: Roger Younglove <[e-mail]>
To: "'Eve Chow - Yahoo'" <[e-mail]>, IETF PKIX <[e-mail]>
Subject: RE: about CRLdp 
Date: Fri, 17 Jan 2003 09:20:10 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C2BE33.8ADFAF80"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

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

------_=_NextPart_001_01C2BE33.8ADFAF80
Content-Type: text/plain

Eve,
I would have the full CRL increment N to identify the full CRL that would
be:
Full CRL number N , CRLDP 1 = N1 ,CRLDP 2 = N2,CRLDP 3 = N3  and  Next full
CRL = N+1 with CRLDP 1 = (N+1) 1, CRLDP2 = (N=1)2, does this make sense?
 
Roger Younglove, CISSP
Principal Consultant
NetWorks Group
O. 810.225.4800 ex. 2245
M. 810.599.0879
E. [e-mail]
www.networksgroup.com
 
-----Original Message-----
From: Eve Chow - Yahoo [mailto:[e-mail]] 
Sent: Friday, January 17, 2003 3:44 AM
To: IETF PKIX
Subject: about CRLdp 
 
Dear all ,
 
I have a question about the CRLdp usage - suppose I setup m CRLdp , how will
the CRL number in CRL count up  ?
eg. m= 3 CRLDP  for CRL partition.
so the full CRL will have number N ,CRLDP 1 = N+1 ,CRLDP 2 = N+2,CRLDP 3 =
N+3  and  Next full CRL = N+ 4 ?
Regards,
Eve Chow , CISSP, CISA
Project Manager
Baltimore Technologies Limited
 
 

------_=_NextPart_001_01C2BE33.8ADFAF80
Content-Type: text/html
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<html xmlns:v=3D"urn:schemas-microsoft-com:vml" =
xmlns:o=3D"urn:schemas-microsoft-com:office:office" =
xmlns:w=3D"urn:schemas-microsoft-com:office:word" =
xmlns:st1=3D"urn:schemas-microsoft-com:office:smarttags" =
xmlns=3D"http://www.w3.org/TR/REC-html40">

<head>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Dus-ascii">


<meta name=3DProgId content=3DWord.Document>
<meta name=3DGenerator content=3D"Microsoft Word 10">
<meta name=3DOriginator content=3D"Microsoft Word 10">
<link rel=3DFile-List href=3D"cid:filelist.xml@01C2BE09.A79A8520">
<o:SmartTagType =
namespaceuri=3D"urn:schemas-microsoft-com:office:smarttags"
 name=3D"time"/>
<o:SmartTagType =
namespaceuri=3D"urn:schemas-microsoft-com:office:smarttags"
 name=3D"date"/>
<!--[if gte mso 9]><xml>
 <o:OfficeDocumentSettings>
  <o:DoNotRelyOnCSS/>
 </o:OfficeDocumentSettings>
</xml><![endif]--><!--[if gte mso 9]><xml>
 <w:WordDocument>
  <w:SpellingState>Clean</w:SpellingState>
  <w:GrammarState>Clean</w:GrammarState>
  <w:DocumentKind>DocumentEmail</w:DocumentKind>
  <w:EnvelopeVis/>
  <w:BrowserLevel>MicrosoftInternetExplorer4</w:BrowserLevel>
 </w:WordDocument>
</xml><![endif]--><!--[if !mso]>
<style>
st1\:*{behavior:url(#default#ieooui) }
</style>
<![endif]-->
<style>
<!--
 /* Font Definitions */
 @font-face
	{font-family:Tahoma;
	panose-1:2 11 6 4 3 5 4 4 2 4;
	mso-font-charset:0;
	mso-generic-font-family:swiss;
	mso-font-pitch:variable;
	mso-font-signature:553679495 -2147483648 8 0 66047 0;}
 /* Style Definitions */
 p.MsoNormal, li.MsoNormal, div.MsoNormal
	{mso-style-parent:"";
	margin:0in;
	margin-bottom:.0001pt;
	mso-pagination:widow-orphan;
	font-size:12.0pt;
	font-family:"Times New Roman";
	mso-fareast-font-family:"Times New Roman";}
a:link, span.MsoHyperlink
	{color:blue;
	text-decoration:underline;
	text-underline:single;}
a:visited, span.MsoHyperlinkFollowed
	{color:purple;
	text-decoration:underline;
	text-underline:single;}
p.MsoAutoSig, li.MsoAutoSig, div.MsoAutoSig
	{margin:0in;
	margin-bottom:.0001pt;
	mso-pagination:widow-orphan;
	font-size:12.0pt;
	font-family:"Times New Roman";
	mso-fareast-font-family:"Times New Roman";}
p
	{mso-margin-top-alt:auto;
	margin-right:0in;
	mso-margin-bottom-alt:auto;
	margin-left:0in;
	mso-pagination:widow-orphan;
	font-size:12.0pt;
	font-family:"Times New Roman";
	mso-fareast-font-family:"Times New Roman";}
span.EmailStyle18
	{mso-style-type:personal-reply;
	mso-style-noshow:yes;
	mso-ansi-font-size:10.0pt;
	mso-bidi-font-size:10.0pt;
	font-family:Arial;
	mso-ascii-font-family:Arial;
	mso-hansi-font-family:Arial;
	mso-bidi-font-family:Arial;
	color:navy;}
span.GramE
	{mso-style-name:"";
	mso-gram-e:yes;}
@page Section1
	{size:8.5in 11.0in;
	margin:1.0in 1.25in 1.0in 1.25in;
	mso-header-margin:.5in;
	mso-footer-margin:.5in;
	mso-paper-source:0;}
div.Section1
	{page:Section1;}
-->
</style>
<!--[if gte mso 10]>
<style>
 /* Style Definitions */=20
 table.MsoNormalTable
	{mso-style-name:"Table Normal";
	mso-tstyle-rowband-size:0;
	mso-tstyle-colband-size:0;
	mso-style-noshow:yes;
	mso-style-parent:"";
	mso-padding-alt:0in 5.4pt 0in 5.4pt;
	mso-para-margin:0in;
	mso-para-margin-bottom:.0001pt;
	mso-pagination:widow-orphan;
	font-size:10.0pt;
	font-family:"Times New Roman";}
</style>
<![endif]--><!--[if gte mso 9]><xml>
 <o:shapedefaults v:ext=3D"edit" spidmax=3D"1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
 <o:shapelayout v:ext=3D"edit">
  <o:idmap v:ext=3D"edit" data=3D"1" />
 </o:shapelayout></xml><![endif]-->
</head>

<body bgcolor=3Dwhite lang=3DEN-US link=3Dblue vlink=3Dpurple =
style=3D'tab-interval:.5in'>

<div class=3DSection1>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
mso-bidi-font-size:12.0pt;font-family:Arial'>Eve,<o:p></o:p></span></fon=
t></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
mso-bidi-font-size:12.0pt;font-family:Arial'>I would have the full CRL
increment N to identify the full CRL that would =
be:<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
mso-bidi-font-size:12.0pt;font-family:Arial'>Full =
CRL</span></font><font
size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;mso-bidi-font-size:12.0pt;
font-family:Arial;mso-bidi-font-family:"Times New Roman"'> number <span
class=3DGramE>N ,</span> CRLDP 1 =3D N1 ,CRLDP 2 =3D N2,CRLDP 3 =3D =
N3&nbsp; and&nbsp;
Next full CRL =3D N+1 with CRLDP 1 =3D (N+1) 1, CRLDP2 =3D (N=3D1)2, =
does this make
sense?</span></font><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
mso-bidi-font-size:12.0pt;font-family:Arial'><o:p></o:p></span></font></=
p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'><o:p>&nbsp;</o:p></span></font></p>

<div>

<p class=3DMsoAutoSig><font size=3D3 color=3Dnavy face=3D"Times New =
Roman"><span
style=3D'font-size:12.0pt;color:navy;mso-no-proof:yes'>Roger Younglove, =
CISSP<o:p></o:p></span></font></p>

<p class=3DMsoAutoSig><font size=3D3 color=3Dnavy face=3D"Times New =
Roman"><span
style=3D'font-size:12.0pt;color:navy;mso-no-proof:yes'>Principal =
Consultant<o:p></o:p></span></font></p>

<p class=3DMsoAutoSig><font size=3D3 color=3Dnavy face=3D"Times New =
Roman"><span
style=3D'font-size:12.0pt;color:navy;mso-no-proof:yes'>NetWorks =
Group<o:p></o:p></span></font></p>

<p class=3DMsoAutoSig><font size=3D3 color=3Dnavy face=3D"Times New =
Roman"><span
lang=3DFR =
style=3D'font-size:12.0pt;color:navy;mso-ansi-language:FR;mso-no-proof:
yes'>O. 810.225.4800 ex. 2245<o:p></o:p></span></font></p>

<p class=3DMsoAutoSig><font size=3D3 color=3Dnavy face=3D"Times New =
Roman"><span
lang=3DFR =
style=3D'font-size:12.0pt;color:navy;mso-ansi-language:FR;mso-no-proof:
yes'>M. 810.599.0879<o:p></o:p></span></font></p>

<p class=3DMsoAutoSig><font size=3D3 color=3Dnavy face=3D"Times New =
Roman"><span
lang=3DFR =
style=3D'font-size:12.0pt;color:navy;mso-ansi-language:FR;mso-no-proof:
yes'>E. [e-mail]<o:p></o:p></span></font></p>

<p class=3DMsoAutoSig><font size=3D3 color=3Dnavy face=3D"Times New =
Roman"><span
style=3D'font-size:12.0pt;color:navy;mso-no-proof:yes'>www.networksgroup=
.com<o:p></o:p></span></font></p>

</div>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:navy'><o:p>&nbsp;</o:p></span></font></p>=


<p class=3DMsoNormal style=3D'margin-left:.5in'><font size=3D2 =
face=3DTahoma><span
style=3D'font-size:10.0pt;font-family:Tahoma'>-----Original =
Message-----<br>
<b><span style=3D'font-weight:bold'>From:</span></b> Eve Chow - Yahoo
[mailto:[e-mail]] <br>
<b><span style=3D'font-weight:bold'>Sent:</span></b> =
</span></font><st1:date
Month=3D"1" Day=3D"17" Year=3D"2003"><font size=3D2 face=3DTahoma><span =
style=3D'font-size:
 10.0pt;font-family:Tahoma'>Friday, January 17, =
2003</span></font></st1:date><font
size=3D2 face=3DTahoma><span =
style=3D'font-size:10.0pt;font-family:Tahoma'> </span></font><st1:time
Hour=3D"3" Minute=3D"44"><font size=3D2 face=3DTahoma><span =
style=3D'font-size:10.0pt;
 font-family:Tahoma'>3:44 AM</span></font></st1:time><font size=3D2 =
face=3DTahoma><span
style=3D'font-size:10.0pt;font-family:Tahoma'><br>
<b><span style=3D'font-weight:bold'>To:</span></b> IETF PKIX<br>
<b><span style=3D'font-weight:bold'>Subject:</span></b> about CRLdp =
</span></font></p>

<p class=3DMsoNormal style=3D'margin-left:.5in'><font size=3D3 =
face=3D"Times New Roman"><span
style=3D'font-size:12.0pt'><o:p>&nbsp;</o:p></span></font></p>

<div>

<p class=3DMsoNormal style=3D'margin-left:.5in'><font size=3D2 =
face=3D"Times New Roman"><span
style=3D'font-size:10.0pt'>Dear all ,</span></font><o:p></o:p></p>

</div>

<div>

<p class=3DMsoNormal style=3D'margin-left:.5in'><font size=3D3 =
face=3D"Times New Roman"><span
style=3D'font-size:12.0pt'>&nbsp;<o:p></o:p></span></font></p>

</div>

<div>

<p class=3DMsoNormal style=3D'margin-left:.5in'><font size=3D2 =
face=3D"Times New Roman"><span
style=3D'font-size:10.0pt'>I have a question about the CRLdp usage - =
suppose I
setup m CRLdp , how will the CRL number in CRL&nbsp;count up =
&nbsp;?<o:p></o:p></span></font></p>

</div>

<div>

<p style=3D'margin-left:.5in'><font size=3D2 face=3D"Times New =
Roman"><span
style=3D'font-size:10.0pt'>eg. m=3D 3 CRLDP&nbsp; for CRL =
partition.<o:p></o:p></span></font></p>

<p style=3D'margin-left:.5in'><font size=3D2 face=3D"Times New =
Roman"><span
style=3D'font-size:10.0pt'>so the full CRL will have number N ,CRLDP 1 =
=3D N+1
,CRLDP 2 =3D N+2,CRLDP 3 =3D N+3&nbsp; and&nbsp; Next full CRL =3D =
N+&nbsp;4 ?<o:p></o:p></span></font></p>

<p style=3D'margin-left:.5in'><font size=3D2 face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial'>Regards,<o:p></o:p></span></font></p>

<p style=3D'margin-left:.5in'><font size=3D2 face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial'>Eve Chow , CISSP, =
CISA<o:p></o:p></span></font></p>

<p style=3D'margin-left:.5in'><font size=3D2 face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial'>Project Manager<o:p></o:p></span></font></p>

<p style=3D'margin-left:.5in'><font size=3D2 face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial'>Baltimore Technologies =
Limited<o:p></o:p></span></font></p>

<p style=3D'margin-left:.5in'><font size=3D2 face=3D"Times New =
Roman"><span
style=3D'font-size:10.0pt'>&nbsp;<o:p></o:p></span></font></p>

<p style=3D'margin-left:.5in'><font size=3D2 face=3D"Times New =
Roman"><span
style=3D'font-size:10.0pt'>&nbsp;<o:p></o:p></span></font></p>

</div>

</div>

</body>

</html>

------_=_NextPart_001_01C2BE33.8ADFAF80--


Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h0HDZId08676 for ietf-pkix-bks; Fri, 17 Jan 2003 05:35:18 -0800 (PST)
Received: from email.certplus.com ([195.101.88.80]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h0HDZHo08671 for <[e-mail]>; Fri, 17 Jan 2003 05:35:17 -0800 (PST)
Received: from carbone.certplus.com (facteur.certplus.com [172.16.1.81]) by email.certplus.com (8.12.2+Sun/8.12.2) with ESMTP id h0HDZ7ft011907; Fri, 17 Jan 2003 14:35:07 +0100 (CET)
Received: from certplus.com ([192.168.212.166]) by carbone.certplus.com with Microsoft SMTPSVC(5.0.2195.2966); Fri, 17 Jan 2003 14:35:08 +0100
Message-ID: <[e-mail]>
Date: Fri, 17 Jan 2003 14:38:46 +0100
From: Jean-Marc Desperrier <[e-mail]>
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.3b) Gecko/20030101
X-Accept-Language: fr, en, en-us, ja
MIME-Version: 1.0
To: Anders Rundgren <[e-mail]>
CC: Richard Levitte - VMS Whacker <[e-mail]>, [e-mail]
Subject: Re: "Basic" path-validation question
References: <007501c2be00$bb24be20$0500a8c0@arport> <[e-mail]> <011001c2be23$22209a50$0500a8c0@arport>
In-Reply-To: <011001c2be23$22209a50$0500a8c0@arport>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
X-OriginalArrivalTime: 17 Jan 2003 13:35:08.0328 (UTC) FILETIME=[4069DA80:01C2BE2D]
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Anders Rundgren a dit :

>>>Below we have a little scheme where an RP have
>>>"accepted" CA1 by "installing" the RootCA and CA1
>>>in the trust-store:
>>>
>>>     /CA1->EE_type1 (class 3 id)
>>>RootCA-CA2->EE_type2 (low assurance e-mail)
>>>     \CA3->EE_type3 (web-server-cert)
>>>      
>>>
 > [...]

>Nema problema.  Except for the fact that the RP probably only agreed
>to accept class 3 id's and now got fooled by the path-validation.
>
>Isn't this what we engineers call "broken" eh?
>  
>
What is broken is the application, if it *requires* to install both 
RootCA and CA1 in order to trust EE_type1.

It should be possible to install only CA1 as a trust anchor, there is no 
requirement in the path-validation that the trust anchor be self-signed.

If the application is OpenSSL, you were talking with someone who is 
supposed to be able to do something about it :-)





Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h0HCV7G07111 for ietf-pkix-bks; Fri, 17 Jan 2003 04:31:07 -0800 (PST)
Received: from nic.lp.se (nic.lp.se [212.247.5.91]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h0HCV5o07107 for <[e-mail]>; Fri, 17 Jan 2003 04:31:06 -0800 (PST)
Received: from localhost (217.215.93.181) by nic.lp.se (MX V5.3 VnHj) with ESMTP; Fri, 17 Jan 2003 13:29:12 +0100
Date: Fri, 17 Jan 2003 13:26:48 +0100 (CET)
Message-ID: <[e-mail]>
To: [e-mail]
CC: [e-mail]
Subject: Re: "Basic" path-validation question
From: Richard Levitte - VMS Whacker <[e-mail]>
In-Reply-To: <011001c2be23$22209a50$0500a8c0@arport>
References: <007501c2be00$bb24be20$0500a8c0@arport> <[e-mail]> <011001c2be23$22209a50$0500a8c0@arport>
X-URL: http://www.lp.se/
X-Waved: dead chicken, GNU emacs 21.2.2, Mew version 3.1
X-Mew: See http://www.mew.org/
X-Mailer: Mew version 3.1 on Emacs 21.2 / Mule 5.0 (SAKAKI)
MIME-Version: 1.0
Content-Type: Text/Plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

In message <011001c2be23$22209a50$0500a8c0@arport> on Fri, 17 Jan 2003 13:22:16 +0100, "Anders Rundgren" <[e-mail]> said:

anders.rundgren> >> Below we have a little scheme where an RP have
anders.rundgren> >> "accepted" CA1 by "installing" the RootCA and CA1
anders.rundgren> >> in the trust-store:
anders.rundgren> >> 
anders.rundgren> >>      /CA1->EE_type1 (class 3 id)
anders.rundgren> >> RootCA-CA2->EE_type2 (low assurance e-mail)
anders.rundgren> >>      \CA3->EE_type3 (web-server-cert)
anders.rundgren> >> 
anders.rundgren> >> Now, the RP receives a message containing a path
anders.rundgren> >> of CA3 + EE_type3.
anders.rundgren> >> 
anders.rundgren> >> What should a conforming path-validation say about this?
anders.rundgren> 
anders.rundgren> >Since the RP already has RootCA in it's store, and
anders.rundgren> >supposedly trusts it, and it verifies CA3 which in
anders.rundgren> >turn verifies EE_type3, the path is validated.  No
anders.rundgren> >problemo.  Or did I miss something?
anders.rundgren> 
anders.rundgren> Nema problema.  Except for the fact that the RP
anders.rundgren> probably only agreed to accept class 3 id's and now
anders.rundgren> got fooled by the path-validation.
anders.rundgren> 
anders.rundgren> Isn't this what we engineers call "broken" eh?

In that case, either the policy extensions in some certificate or the
path validation software is broken.  The only way to know if a
certificate is "class 3" is the policy extension and the knowledge of
what policy OIDs corresponds to "class 3".  The software should be
configurable with a set of acceptable policy OIDs, and should verify
that policy is properly maintained in the whole path.

If the RP only accepts class 3 id's, then it should invalidate that
path just by looking at the EE_type3 certificate.

Note: there's a lot of software out there that doesn't process the
policy checks, either at all or badly...

Have you looked at RFC3280?  It has a pretty good description of what
to check and how during validation.

-- 
Richard Levitte     | http://richard.levitte.org/ | Spannv. 38, I
Levitte Programming | http://www.lp.se/           | S-168 35 Bromma
T: [phone] |                             | SWEDEN
     "Price, performance, quality...  choose the two you like"


Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h0HCOvJ06945 for ietf-pkix-bks; Fri, 17 Jan 2003 04:24:57 -0800 (PST)
Received: from maile.telia.com (maile.telia.com [194.22.190.16]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h0HCOto06941 for <[e-mail]>; Fri, 17 Jan 2003 04:24:56 -0800 (PST)
Received: from arport (h119n2fls31o1122.telia.com [212.181.142.119]) by maile.telia.com (8.12.5/8.12.5) with SMTP id h0HCOtS6005071; Fri, 17 Jan 2003 13:24:55 +0100 (CET)
X-Original-Recipient: [e-mail]
Message-ID: <011001c2be23$22209a50$0500a8c0@arport>
From: "Anders Rundgren" <[e-mail]>
To: "Richard Levitte - VMS Whacker" <[e-mail]>, <[e-mail]>
References: <007501c2be00$bb24be20$0500a8c0@arport> <[e-mail]>
Subject: Re: "Basic" path-validation question
Date: Fri, 17 Jan 2003 13:22:16 +0100
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.50.4133.2400
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

>> Below we have a little scheme where an RP have
>> "accepted" CA1 by "installing" the RootCA and CA1
>> in the trust-store:
>> 
>>      /CA1->EE_type1 (class 3 id)
>> RootCA-CA2->EE_type2 (low assurance e-mail)
>>      \CA3->EE_type3 (web-server-cert)
>> 
>> Now, the RP receives a message containing a path
>> of CA3 + EE_type3.
>> 
>> What should a conforming path-validation say about this?

>Since the RP already has RootCA in it's store, and supposedly trusts
>it, and it verifies CA3 which in turn verifies EE_type3, the path is
>validated.  No problemo.  Or did I miss something?

Nema problema.  Except for the fact that the RP probably only agreed
to accept class 3 id's and now got fooled by the path-validation.

Isn't this what we engineers call "broken" eh?

<snip>

Anders



Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h0HBxlX04161 for ietf-pkix-bks; Fri, 17 Jan 2003 03:59:47 -0800 (PST)
Received: from nic.lp.se (nic.lp.se [212.247.5.91]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h0HBxjo04153 for <[e-mail]>; Fri, 17 Jan 2003 03:59:46 -0800 (PST)
Received: from localhost (217.215.93.181) by nic.lp.se (MX V5.3 VnHj) with ESMTP; Fri, 17 Jan 2003 12:57:58 +0100
Date: Fri, 17 Jan 2003 12:55:33 +0100 (CET)
Message-ID: <[e-mail]>
To: [e-mail]
CC: [e-mail]
Subject: Re: "Basic" path-validation question
From: Richard Levitte - VMS Whacker <[e-mail]>
In-Reply-To: <007501c2be00$bb24be20$0500a8c0@arport>
References: <007501c2be00$bb24be20$0500a8c0@arport>
X-URL: http://www.lp.se/
X-Waved: dead chicken, GNU emacs 21.2.2, Mew version 3.1
X-Mew: See http://www.mew.org/
X-Mailer: Mew version 3.1 on Emacs 21.2 / Mule 5.0 (SAKAKI)
MIME-Version: 1.0
Content-Type: Text/Plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

In message <007501c2be00$bb24be20$0500a8c0@arport> on Fri, 17 Jan 2003 09:16:23 +0100, "Anders Rundgren" <[e-mail]> said:

anders.rundgren> Below we have a little scheme where an RP have
anders.rundgren> "accepted" CA1 by "installing" the RootCA and CA1
anders.rundgren> in the trust-store:
anders.rundgren> 
anders.rundgren>      /CA1->EE_type1 (class 3 id)
anders.rundgren> RootCA-CA2->EE_type2 (low assurance e-mail)
anders.rundgren>      \CA3->EE_type3 (web-server-cert)
anders.rundgren> 
anders.rundgren> Now, the RP receives a message containing a path
anders.rundgren> of CA3 + EE_type3.
anders.rundgren> 
anders.rundgren> What should a conforming path-validation say about this?

Since the RP already has RootCA in it's store, and supposedly trusts
it, and it verifies CA3 which in turn verifies EE_type3, the path is
validated.  No problemo.  Or did I miss something?

This is under the assumption that it doesn't matter how the RP gets
the certificates it gets hold of in the process of messages, as long
as there's a chain that validates back to a trust point (in the case,
RootCA).

-- 
Richard Levitte     | http://richard.levitte.org/ | Spannv. 38, I
Levitte Programming | http://www.lp.se/           | S-168 35 Bromma
T: [phone] |                             | SWEDEN
     "Price, performance, quality...  choose the two you like"


Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h0HBodx02413 for ietf-pkix-bks; Fri, 17 Jan 2003 03:50:39 -0800 (PST)
Received: from nic.lp.se (nic.lp.se [212.247.5.91]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h0HBoYo02395 for <[e-mail]>; Fri, 17 Jan 2003 03:50:37 -0800 (PST)
Received: from localhost (217.215.93.181) by nic.lp.se (MX V5.3 VnHj) with ESMTP; Fri, 17 Jan 2003 12:48:39 +0100
Date: Fri, 17 Jan 2003 12:46:14 +0100 (CET)
Message-ID: <[e-mail]>
To: [e-mail]
CC: [e-mail]
Subject: Re: Another certificate policy question
From: Richard Levitte - VMS Whacker <[e-mail]>
In-Reply-To: <[e-mail]>
References: <[e-mail]>
X-URL: http://www.lp.se/
X-Waved: dead chicken, GNU emacs 21.2.2, Mew version 3.1
X-Mew: See http://www.mew.org/
X-Mailer: Mew version 3.1 on Emacs 21.2 / Mule 5.0 (SAKAKI)
MIME-Version: 1.0
Content-Type: Text/Plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

In message <[e-mail]> on Fri, 17 Jan 2003 18:21:41 +1300, [e-mail] (Peter Gutmann) said:

pgut001> Actually it's not really a question, more a
pgut001> thinking-out-loud: I've just been sent yet another odd cert
pgut001> which has a single policy OID but two different CPSes
pgut001> associated with it as qualifiers.  This is valid according to
pgut001> the RFC, but seems a bit odd.

That *is* odd...  Do they cover different things, or do they specify
roughly the same things but differently?

pgut001> Given that the policy extension has become a kitchen-sink
pgut001> extension into which people are just shovelling everything
pgut001> they can think of, perhaps we should change the name to
pgut001> kitchenSink (to match the SINK RR)

*laugh*

pgut001> and define a new policy extension that can't contain anything
pgut001> more than policy OIDs.

I violently disagree with the single policy suggestion.  However, I
could definitely see an extension that could contain a list of CP+CPS
pairs, where the CPS would be optional...  The reason is that a CA
cert should be possible to use under more than one policy (I'm dubious
about having EE certs running under more than one policy, but I guess
that's a question of policies...).

Now, about the reality of something like that ever turning up (what
with interoperability, or at least attempts in that direction)...

pgut001> I shudder to think what would be required to meaningfully
pgut001> process some of the kitchenSinks I've seen if the critical
pgut001> flag was set on them.

You can always invalidate the path...

-- 
Richard Levitte     | http://richard.levitte.org/ | Spannv. 38, I
Levitte Programming | http://www.lp.se/           | S-168 35 Bromma
T: [phone] |                             | SWEDEN
     "Price, performance, quality...  choose the two you like"



Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h0H938L16813 for ietf-pkix-bks; Fri, 17 Jan 2003 01:03:08 -0800 (PST)
Received: from localhost.intranet (cl0.unity.net [195.24.141.128]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h0H92eo16752 for <[e-mail]>; Fri, 17 Jan 2003 01:02:41 -0800 (PST)
Received: (from vf@localhost) by localhost.intranet (8.9.3/8.8.8/Debian/GNU) id LAA01028; Fri, 17 Jan 2003 11:05:03 +0200
Date: Fri, 17 Jan 2003 11:05:03 +0200
From: Vadim Fedukovich <[e-mail]>
To: Tammy Green <[e-mail]>, [e-mail]
Subject: Re: Q. Automatic certificate selection for signing
Message-ID: <[e-mail]>
References: <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Mailer: Mutt 1.0.1i
In-Reply-To: <[e-mail]>; from [e-mail] on Thu, Jan 16, 2003 at 05:17:39PM -0700
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Let me just say I'm impressed we are still talking about "using certificates
for signing". To sign, the private key is used. At least for pkcs7.
Certificate is used while verification.

did I miss something?

On Thu, Jan 16, 2003 at 05:17:39PM -0700, Tammy Green wrote:
> In trying to design something like this a while back, I found that a
> blanket statement of "use this certificate for application x" was not
> always sufficient.  Two areas where the concept broke down were:



Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h0H8kqe15275 for ietf-pkix-bks; Fri, 17 Jan 2003 00:46:52 -0800 (PST)
Received: from smtp014.mail.yahoo.com (smtp014.mail.yahoo.com [216.136.173.58]) by above.proper.com (8.11.6/8.11.3) with SMTP id h0H8kqo15268 for <[e-mail]>; Fri, 17 Jan 2003 00:46:52 -0800 (PST)
Received: from pc199.baltimore.com.hk (HELO evechow) (chow?eve@203.85.185.199 with login) by smtp.mail.vip.sc5.yahoo.com with SMTP; 17 Jan 2003 08:46:51 -0000
Message-ID: <002101c2be04$87887990$[e-mail]>
From: "Eve Chow - Yahoo" <[e-mail]>
To: "IETF PKIX" <[e-mail]>
Subject: about CRLdp 
Date: Fri, 17 Jan 2003 16:43:30 +0800
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_001E_01C2BE47.91101160"
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2800.1106
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

This is a multi-part message in MIME format.

------=_NextPart_000_001E_01C2BE47.91101160
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Dear all ,

I have a question about the CRLdp usage - suppose I setup m CRLdp , how =
will the CRL number in CRL count up  ?
eg. m=3D 3 CRLDP  for CRL partition.

so the full CRL will have number N ,CRLDP 1 =3D N+1 ,CRLDP 2 =3D =
N+2,CRLDP 3 =3D N+3  and  Next full CRL =3D N+ 4 ?

Regards,

Eve Chow , CISSP, CISA

Project Manager

Baltimore Technologies Limited





------=_NextPart_000_001E_01C2BE47.91101160
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 http-equiv=3DContent-Type content=3D"text/html; =
charset=3Diso-8859-1">
<META content=3D"MSHTML 6.00.2800.1106" name=3DGENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=3D#ffffff>
<DIV><FONT size=3D2>Dear all ,</FONT></DIV>
<DIV><FONT size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT size=3D2>I have a question about the CRLdp usage - suppose I =
setup m=20
CRLdp , how will the CRL number in CRL&nbsp;count up &nbsp;?</DIV>
<DIV>
<P>eg. m=3D 3 CRLDP&nbsp; for CRL partition.</P>
<P>so the full CRL will have number N ,CRLDP 1 =3D N+1 ,CRLDP 2 =3D =
N+2,CRLDP 3 =3D=20
N+3&nbsp; and&nbsp; Next full CRL =3D N+&nbsp;4 ?<FONT =
size=3D2></P></FONT><FONT=20
face=3DArial size=3D2>
<P>Regards,</P>
<P>Eve Chow , CISSP, CISA</P>
<P>Project Manager</P>
<P>Baltimore Technologies Limited</P></FONT>
<P>&nbsp;</P>
<P>&nbsp;</P></FONT></DIV></BODY></HTML>

------=_NextPart_000_001E_01C2BE47.91101160--



Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h0H8ImB08644 for ietf-pkix-bks; Fri, 17 Jan 2003 00:18:48 -0800 (PST)
Received: from maild.telia.com (maild.telia.com [194.22.190.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h0H8Iko08635 for <[e-mail]>; Fri, 17 Jan 2003 00:18:47 -0800 (PST)
Received: from arport (h119n2fls31o1122.telia.com [212.181.142.119]) by maild.telia.com (8.12.5/8.12.5) with SMTP id h0H8IdZq015072 for <[e-mail]>; Fri, 17 Jan 2003 09:18:39 +0100 (CET)
X-Original-Recipient: <[e-mail]>
Message-ID: <007501c2be00$bb24be20$0500a8c0@arport>
From: "Anders Rundgren" <[e-mail]>
To: <[e-mail]>
Subject: "Basic" path-validation question
Date: Fri, 17 Jan 2003 09:16:23 +0100
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.50.4133.2400
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Hi,
Below we have a little scheme where an RP have
"accepted" CA1 by "installing" the RootCA and CA1
in the trust-store:

     /CA1->EE_type1 (class 3 id)
RootCA-CA2->EE_type2 (low assurance e-mail)
     \CA3->EE_type3 (web-server-cert)

Now, the RP receives a message containing a path
of CA3 + EE_type3.

What should a conforming path-validation say about this?

Or is this (as I suspect) up to the implementation to have
an opinion about?

cheers,
Anders



Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h0H7Ulq01519 for ietf-pkix-bks; Thu, 16 Jan 2003 23:30:47 -0800 (PST)
Received: from hermes.cs.auckland.ac.nz (hermes.cs.auckland.ac.nz [130.216.35.151]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h0H7Ujo01515 for <[e-mail]>; Thu, 16 Jan 2003 23:30:45 -0800 (PST)
Received: from medusa01.cs.auckland.ac.nz (medusa01.cs.auckland.ac.nz [130.216.34.60]) by hermes.cs.auckland.ac.nz (8.12.4/8.12.4) with ESMTP id h0H7Udmv026097 for <[e-mail]>; Fri, 17 Jan 2003 20:30:39 +1300
Received: (from pgut001@localhost) by medusa01.cs.auckland.ac.nz (8.11.6/8.11.6) id h0H7Uea27298 for [e-mail]; Fri, 17 Jan 2003 20:30:40 +1300
Date: Fri, 17 Jan 2003 20:30:40 +1300
Message-Id: <[e-mail]>
From: [e-mail] (Peter Gutmann)
To: [e-mail]
Subject: Comment on RFC 3161/3161bis
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Appendix A contains some text on using timestamps with CMS ("a sensible way
of...").  Although this quacks like a CMS Countersignature, it is in fact
different, both in the format and in the way it's generated.  The overall
format can't easily be fixed without changing the whole TSA response format,
but the way of generating the not-quite-countersignature is just gratuitously
incompatible.  CMS says:

 3.  The input to the message-digesting process is the contents
     octets of the DER encoding of the signatureValue field of the
     SignerInfo value with which the attribute is associated.

In contrast TSP says:

   The value of messageImprint field within TimeStampToken shall be a
   hash of the value of signature field within SignerInfo for the
   signedData being time-stamped.

In order to fix this, I would suggest the following change to 3161bis, to
follow the existing "CHANGE N-x" list:

-- Snip --

CHANGE N-7:

In Appendix A, removed the unfounded claim that what this RFC requires is
sensible, and added a warning about incompatibilities with the standard CMS
way of doing things.

-- Snip --

Peter.


Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h0H5Lh521813 for ietf-pkix-bks; Thu, 16 Jan 2003 21:21:43 -0800 (PST)
Received: from hermes.cs.auckland.ac.nz (hermes.cs.auckland.ac.nz [130.216.35.151]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h0H5Lfo21809 for <[e-mail]>; Thu, 16 Jan 2003 21:21:41 -0800 (PST)
Received: from medusa01.cs.auckland.ac.nz (medusa01.cs.auckland.ac.nz [130.216.34.60]) by hermes.cs.auckland.ac.nz (8.12.4/8.12.4) with ESMTP id h0H5Lemv024895 for <[e-mail]>; Fri, 17 Jan 2003 18:21:40 +1300
Received: (from pgut001@localhost) by medusa01.cs.auckland.ac.nz (8.11.6/8.11.6) id h0H5LfK23293 for [e-mail]; Fri, 17 Jan 2003 18:21:41 +1300
Date: Fri, 17 Jan 2003 18:21:41 +1300
Message-Id: <[e-mail]>
From: [e-mail] (Peter Gutmann)
To: [e-mail]
Subject: Another certificate policy question
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Actually it's not really a question, more a thinking-out-loud: I've just been
sent yet another odd cert which has a single policy OID but two different
CPSes associated with it as qualifiers.  This is valid according to the RFC,
but seems a bit odd.

Given that the policy extension has become a kitchen-sink extension into which
people are just shovelling everything they can think of, perhaps we should
change the name to kitchenSink (to match the SINK RR) and define a new policy
extension that can't contain anything more than policy OIDs.  I shudder to
think what would be required to meaningfully process some of the kitchenSinks
I've seen if the critical flag was set on them.

Peter.


Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h0H5Dct21635 for ietf-pkix-bks; Thu, 16 Jan 2003 21:13:38 -0800 (PST)
Received: from hermes.cs.auckland.ac.nz (hermes.cs.auckland.ac.nz [130.216.35.151]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h0H5Dao21631 for <[e-mail]>; Thu, 16 Jan 2003 21:13:36 -0800 (PST)
Received: from medusa01.cs.auckland.ac.nz (medusa01.cs.auckland.ac.nz [130.216.34.60]) by hermes.cs.auckland.ac.nz (8.12.4/8.12.4) with ESMTP id h0H5DYmv024786 for <[e-mail]>; Fri, 17 Jan 2003 18:13:34 +1300
Received: (from pgut001@localhost) by medusa01.cs.auckland.ac.nz (8.11.6/8.11.6) id h0H5DZL23069 for [e-mail]; Fri, 17 Jan 2003 18:13:35 +1300
Date: Fri, 17 Jan 2003 18:13:35 +1300
Message-Id: <[e-mail]>
From: [e-mail] (Peter Gutmann)
To: [e-mail]
Subject: New draft: Real-time Certificate Status Facility for OCSP - (RTCS)
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

The following draft was recently posted: 

  http://www.ietf.org/internet-drafts/draft-gutmann-ocsp-rtcs-00.txt

The (rather lengthy :-) abstract describes it as follows:

When the OCSP protocol was defined, the design was based on full compatibility
with CRL-based mechanisms.  This requires the use of a complex means of
certificate identification that has resulted in interoperability problems
among implementations, a design unsuited for high-throughput, real-time
operation, the inability to provide an unambiguous certificate status response
(the only thing that a CRL can say with certainty is "revoked"), and an online
responder tied to an offline mechanism (some CAs issue CRLs only once or twice
a day, even though they have an online, real- time certificate store
available).  A more practical problem is that it makes it impossible to
implement an OCSP responder not based on CRLs, for example one that consults a
certificate database or in-memory hash table to determine the presence or
absence of a valid certificate.

Fortunately, the authors of the OCSP RFC foresaw this situation by allowing a
client to specify, and a responder to return, more than one type of response.
Just as the original OCSP responses were designed for completely CRL-
compatible operation, this document specifies a response type that is designed
for real-time status operation, providing a response not from a stored CRL
using CRL-only mechanisms but directly from a live certificate store or in-
memory hash table.  This allows the responder to provide extended information
not possible with CRLs, combined a high level of performance not possible with
the original OCSP design.

In abstract terms, the responder is providing an implementation of an
authenticated dictionary D that responds to membership queries from relying
parties.  A conventional OCSP responder answers the question "Is x excluded
from D?", while an OCSP responder with RTCS capability answers the question
"Is x present in D?".

When returning a response, the responder is merely indicating that the queried
certificate is currently present in its set of valid certificates.  It is
purely an authenticated dictionary service and does not verify the certificate
in any way.  Relying parties requiring external verification services should
use the PKIX standard mechanisms for this [RFC 3379] and not RTCS.
Specifically, RTCS does not provide, and should not be assumed to provide, any
of the functionality of DPD/DPV.  It is purely a mechanism for running a high-
performance OCSP responder directly from a CA certificate store/in-memory
table.

Peter.


Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h0H0I8w14984 for ietf-pkix-bks; Thu, 16 Jan 2003 16:18:08 -0800 (PST)
Received: from prv-mail20.provo.novell.com (prv-mail20.provo.novell.com [137.65.81.122]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h0H0I6o14978 for <[e-mail]>; Thu, 16 Jan 2003 16:18:06 -0800 (PST)
Received: from INET-PRV-MTA by prv-mail20.provo.novell.com with Novell_GroupWise; Thu, 16 Jan 2003 17:16:41 -0700
Message-Id: <[e-mail]>
X-Mailer: Novell GroupWise Internet Agent 6.5.0 
Date: Thu, 16 Jan 2003 17:17:39 -0700
From: "Tammy Green" <[e-mail]>
To: <[e-mail]>, <[e-mail]>
Subject: Re: Q. Automatic certificate selection for signing
Mime-Version: 1.0
Content-Type: multipart/alternative; boundary="=_431C5779.650478E6"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

This is a MIME message. If you are reading this text, you may want to 
consider changing to a mail reader or gateway that understands how to 
properly handle MIME multipart messages.

--=_431C5779.650478E6
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit

In trying to design something like this a while back, I found that a
blanket statement of "use this certificate for application x" was not
always sufficient.  Two areas where the concept broke down were:
 
1.  Nonrepudiation
Some signatures need to carry more legal weight than others, even
though they are being done through the same application and as the same
user.  In such cases, it is difficult to tell which certificate the user
wants to use without actual user input to the application.  The same
argument applies, by the way, if the user has multiple roles with a
certificate for each role -- you must determine which role the user is
acting as in order to select the correct certificate.
 
2.  Certificate Authority
If a user needs to use a single application to sign data, but sends the
data to different recipients, the certificate that must be used could
depend on which CA issued it.  For emailing family, perhaps I use a
public CA, but for work matters I am required to use a certificate
issued by my company's internally maintained CA.  

In the end, the linkage to an application can only be used to provide a
default certificate -- the user must always be able to chose something
else.
 
Putting such a linkage in the certificate, though, could be interesting
if the set of applications remained relatively static over the lifetime
of the certificate.  Otherwise, every time a new application was
deployed, new certificates would have to be created.  But, perhaps the
harder thing would be to standardize the set of application
names/identifiers that would be used in the certificates to prevent name
conflicts.  But, perhaps you get this for free with URIs?
 
 
 
Tammy Green
Senior Software Engineer
Novell, Inc., The Leading Provider of Net Business Solutions
[e-mail] 

 
Tammy Green
Senior Software Engineer
Novell, Inc., The Leading Provider of Net Business Solutions
[e-mail] 


>>> "Marc Poulaud" <[e-mail]> 1/14/03 2:35:11 PM >>>

A question for those involved with signing applications (or anybody
else with 2 cents)...
 
I'm interested to understand what might be some of the key
issues/options for a signing application that needs to select the right
certificate for signing a piece of data. I see two main options. One is
that there is a configuration option that allows a particular user to be
associated with a particular certificate (a la Outlook - I want to use
this certificate (and associated key) to sign my outgoing emails).
Another is that, during the signing operation, some how select the right
certificate based on a value coded in a certificate.
 
On the one hand I think the latter would be a smart move if it where
possible to use some standard (and therefore interoperable) way of doing
this (unlike my initial thought of having an 'application' specific
value in an OU field) or perhaps a more suitable field within a
certificate (perhaps a policy qualifier?).
 
Anybody have experience of such matters?
 
Marc.

--=_431C5779.650478E6
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 8bit

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META http-equiv=Content-Type content="text/html; charset=iso-8859-1">
<META content="MSHTML 6.00.2719.2200" name=GENERATOR></HEAD>
<BODY style="MARGIN: 4px 4px 1px; FONT: 10pt Verdana">
<DIV>In trying to design something like this a while back, I found that a 
blanket statement of "use this certificate for application x" was not always 
sufficient.&nbsp; Two areas where the concept broke down were:</DIV>
<DIV>&nbsp;</DIV>
<DIV>1.&nbsp; Nonrepudiation</DIV>
<DIV>Some signatures need to carry more legal weight than others, even though 
they are being done through the same application and as the same user.&nbsp; In 
such cases, it is difficult to tell which certificate the user wants to use 
without actual user input to the application.&nbsp; The same argument applies, 
by the way, if the user has multiple roles with a certificate for each role -- 
you must determine which role the user is acting as in order to select the 
correct certificate.</DIV>
<DIV>&nbsp;</DIV>
<DIV>2.&nbsp; Certificate Authority</DIV>
<DIV>If a user needs to use a single application to sign data, but&nbsp;sends 
the&nbsp;data to&nbsp;different recipients, the certificate&nbsp;that must be 
used&nbsp;could depend on which CA issued it.&nbsp; For&nbsp;emailing family, 
perhaps I use a public CA, but for work matters I am required to use a 
certificate issued by my company's internally maintained CA.&nbsp; <BR></DIV>
<DIV>In the end, the linkage to an application&nbsp;can only be used to provide 
a default certificate -- the user must always be able to chose something 
else.</DIV>
<DIV>&nbsp;</DIV>
<DIV>Putting such a linkage in the certificate, though, could be interesting if 
the set of applications remained relatively static over the lifetime of the 
certificate.&nbsp; Otherwise, every time a new application was deployed, new 
certificates would have to be created.&nbsp; But, perhaps the 
harder&nbsp;thing&nbsp;would be to standardize the set of application 
names/identifiers that would&nbsp;be used in the certificates to prevent name 
conflicts.&nbsp; But, perhaps you get this for free with URIs?</DIV>
<DIV>&nbsp;</DIV>
<DIV>&nbsp;</DIV>
<DIV>&nbsp;</DIV>
<DIV>Tammy Green<BR>Senior Software Engineer<BR>Novell, Inc., The Leading 
Provider of Net Business Solutions<BR><A 
href="mailto:[e-mail]">[e-mail]</A><BR></DIV>
<DIV>&nbsp;</DIV>
<DIV>Tammy Green<BR>Senior Software Engineer<BR>Novell, Inc., The Leading 
Provider of Net Business Solutions<BR><A 
href="mailto:[e-mail]">[e-mail]</A><BR></DIV>
<DIV><BR>&gt;&gt;&gt; "Marc Poulaud" &lt;[e-mail]&gt; 1/14/03 
2:35:11 PM &gt;&gt;&gt;<BR></DIV>
<DIV><FONT face=Arial size=2><SPAN class=346562121-14012003>A question for those 
involved with signing applications (or anybody else with 2 
cents)...</SPAN></FONT></DIV>
<DIV><FONT face=Arial size=2><SPAN 
class=346562121-14012003></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT face=Arial size=2><SPAN class=346562121-14012003>I'm interested to 
understand what might be some of the key issues/options for a signing 
application that needs to select the right certificate for signing a piece of 
data. I see two main options. One is that there is a configuration&nbsp;option 
that allows a particular user to be associated with a particular certificate (a 
la Outlook - I want to use this certificate (and associated key) to sign my 
outgoing emails). Another is that, during the signing operation, some how select 
the right certificate based on a value coded in</SPAN></FONT><FONT face=Arial 
size=2><SPAN class=346562121-14012003>&nbsp;a certificate.</SPAN></FONT></DIV>
<DIV><FONT face=Arial size=2><SPAN 
class=346562121-14012003></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT face=Arial size=2><SPAN class=346562121-14012003>On the one hand I 
think the latter would be a smart move if it where possible to use some standard 
(and therefore interoperable) way of doing this (unlike my initial thought of 
having&nbsp;an 'application' specific value in an OU field) or perhaps a more 
suitable field within a certificate (perhaps a policy 
qualifier?).</SPAN></FONT></DIV>
<DIV><FONT face=Arial size=2><SPAN 
class=346562121-14012003></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT face=Arial size=2><SPAN class=346562121-14012003>Anybody have 
experience of such matters?</SPAN></FONT></DIV>
<DIV><FONT face=Arial size=2><SPAN 
class=346562121-14012003></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT face=Arial size=2><SPAN 
class=346562121-14012003>Marc.</SPAN></FONT></DIV></BODY></HTML>

--=_431C5779.650478E6--


Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h0GE5Vf22960 for ietf-pkix-bks; Thu, 16 Jan 2003 06:05:31 -0800 (PST)
Received: from hubie.hubbardind.com (mail.hubbardsupply.com [65.245.100.65]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h0GE5Uo22956 for <[e-mail]>; Thu, 16 Jan 2003 06:05:30 -0800 (PST)
Received: by HUBIE.hubbardsupply.com with Internet Mail Service (5.5.2653.19) id <Y0ST0WHC>; Thu, 16 Jan 2003 09:05:30 -0500
Message-ID: <[e-mail]>
From: Roger Younglove <[e-mail]>
To: "'Anders Rundgren'" <[e-mail]>, [e-mail]
Subject: RE: CA Liability:Warranty/ draft-ietf-pkix-warranty-extn-01.txt
Date: Thu, 16 Jan 2003 09:05:30 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C2BD68.53D0DA80"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

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

------_=_NextPart_001_01C2BD68.53D0DA80
Content-Type: text/plain

Anders,
In the development of a large PKI we wrote a limited liability clause in the
CP and also in the RP agreement, legally this met the requirements of the CA
operator.

Roger Younglove, CISSP
Principal Consultant
NetWorks Group
O. 810.225.4800 ex. 2245
M. 810.599.0879
E. [e-mail]
www.networksgroup.com
 

-----Original Message-----
From: Anders Rundgren [mailto:[e-mail]] 
Sent: Thursday, January 16, 2003 2:07 AM
To: [e-mail]
Subject: CA Liability:Warranty/ draft-ietf-pkix-warranty-extn-01.txt


Hi PKI-lawyers,

I took the liberty to check how VeriSign handles this and
it was sort of enlightening (well...)

http://www.verisign.com/netsure ?

They talk about "limited liability warranty" (!!!) which sort of verifies
that what we call this is all over the map but the consequences
are the same as when your house is burning down:  If insured, you 
file a damage report and depending on the cause and nature of the
damage you may get something between zero to full compensation
up to a certain limit.

Q: A typical US SW agreement contains paragraphs that seems to
be intended to LIMIT liability as it states that you use it on your
own risk, and not for mission-critical stuff.  If this really works (it
does?) for software, why would it not work for CAs?

IF it *IS* possible (this ought to be investigated) to limit liability
by an agreement, this should be a part of the extension as there is
a demand for such measures.

Cheers,
Anders Rundgren
Senior Internet e-Commerce Architect


------_=_NextPart_001_01C2BD68.53D0DA80
Content-Type: text/html
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Dus-ascii">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
5.5.2653.12">
<TITLE>RE: CA Liability:Warranty/ =
draft-ietf-pkix-warranty-extn-01.txt</TITLE>
</HEAD>
<BODY>

<P><FONT SIZE=3D2>Anders,</FONT>
<BR><FONT SIZE=3D2>In the development of a large PKI we wrote a limited =
liability clause in the CP and also in the RP agreement, legally this =
met the requirements of the CA operator.</FONT></P>

<P><FONT SIZE=3D2>Roger Younglove, CISSP</FONT>
<BR><FONT SIZE=3D2>Principal Consultant</FONT>
<BR><FONT SIZE=3D2>NetWorks Group</FONT>
<BR><FONT SIZE=3D2>O. 810.225.4800 ex. 2245</FONT>
<BR><FONT SIZE=3D2>M. 810.599.0879</FONT>
<BR><FONT SIZE=3D2>E. [e-mail]</FONT>
<BR><FONT SIZE=3D2>www.networksgroup.com</FONT>
<BR><FONT SIZE=3D2>&nbsp;</FONT>
</P>

<P><FONT SIZE=3D2>-----Original Message-----</FONT>
<BR><FONT SIZE=3D2>From: Anders Rundgren [<A =
HREF=3D"mailto:[e-mail]">mailto:anders.rundgren@telia.c=
om</A>] </FONT>
<BR><FONT SIZE=3D2>Sent: Thursday, January 16, 2003 2:07 AM</FONT>
<BR><FONT SIZE=3D2>To: [e-mail]</FONT>
<BR><FONT SIZE=3D2>Subject: CA Liability:Warranty/ =
draft-ietf-pkix-warranty-extn-01.txt</FONT>
</P>
<BR>

<P><FONT SIZE=3D2>Hi PKI-lawyers,</FONT>
</P>

<P><FONT SIZE=3D2>I took the liberty to check how VeriSign handles this =
and</FONT>
<BR><FONT SIZE=3D2>it was sort of enlightening (well...)</FONT>
</P>

<P><FONT SIZE=3D2><A HREF=3D"http://www.verisign.com/netsure" =
TARGET=3D"_blank">http://www.verisign.com/netsure</A> ?</FONT>
</P>

<P><FONT SIZE=3D2>They talk about &quot;limited liability =
warranty&quot; (!!!) which sort of verifies</FONT>
<BR><FONT SIZE=3D2>that what we call this is all over the map but the =
consequences</FONT>
<BR><FONT SIZE=3D2>are the same as when your house is burning =
down:&nbsp; If insured, you </FONT>
<BR><FONT SIZE=3D2>file a damage report and depending on the cause and =
nature of the</FONT>
<BR><FONT SIZE=3D2>damage you may get something between zero to full =
compensation</FONT>
<BR><FONT SIZE=3D2>up to a certain limit.</FONT>
</P>

<P><FONT SIZE=3D2>Q: A typical US SW agreement contains paragraphs that =
seems to</FONT>
<BR><FONT SIZE=3D2>be intended to LIMIT liability as it states that you =
use it on your</FONT>
<BR><FONT SIZE=3D2>own risk, and not for mission-critical stuff.&nbsp; =
If this really works (it</FONT>
<BR><FONT SIZE=3D2>does?) for software, why would it not work for =
CAs?</FONT>
</P>

<P><FONT SIZE=3D2>IF it *IS* possible (this ought to be investigated) =
to limit liability</FONT>
<BR><FONT SIZE=3D2>by an agreement, this should be a part of the =
extension as there is</FONT>
<BR><FONT SIZE=3D2>a demand for such measures.</FONT>
</P>

<P><FONT SIZE=3D2>Cheers,</FONT>
<BR><FONT SIZE=3D2>Anders Rundgren</FONT>
<BR><FONT SIZE=3D2>Senior Internet e-Commerce Architect</FONT>
</P>

</BODY>
</HTML>
------_=_NextPart_001_01C2BD68.53D0DA80--


Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h0GBah813339 for ietf-pkix-bks; Thu, 16 Jan 2003 03:36:43 -0800 (PST)
Received: from mail3.consignia.com (mail3.consignia.com [144.87.143.83]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h0GBafo13331 for <[e-mail]>; Thu, 16 Jan 2003 03:36:42 -0800 (PST)
Received: from postoffice.co.uk (mta2.int.consignia.com [144.87.146.16]) by mail3.consignia.com (Postfix) with SMTP id 1AACF18F991; Thu, 16 Jan 2003 11:36:41 +0000 (GMT)
Received: by postoffice.co.uk(Lotus SMTP MTA v4.6.6  (890.1 7-16-1999))  id 00256CB0.003FCE0C ; Thu, 16 Jan 2003 11:36:55 +0000
X-Lotus-FromDomain: POSTOFFICE
From: [e-mail]
To: [e-mail]
Cc: Sharon Boeyen <[e-mail]>
Message-ID: <[e-mail]>
Date: Thu, 16 Jan 2003 11:36:24 +0000
Subject: RE: LDAP PKI Schema (was Re: No-op LDAP ;binary option)
Mime-Version: 1.0
Content-type: text/plain; charset=us-ascii
Content-Disposition: inline
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

> otherwise they'd be sending a lot of requests that
> wouldn't succeed

Unfortunately this is already the way of the world

> That model is limited to closed environments and
> creates isolated islands of interoperability.

Again, this is already the case.

> PKIX requires a mechanism that enables clients to
> be able to access the data they need to build
> and validate cert paths and separating servers into
> some that follow a compatible schema and others
> that don't would significantly hinder that ability.

I don't disagree but as you have implied this would
require a very heavy client that can cope with all
currently deployed strategies. I doubt that any vendor
would commit to creating a product that supported
someone else's technical strategy. I would much rather
see the killing off of one of the strategies and a
focus on and a commitment by everyone to the other.
I accept that this is not trivial but I do not believe
that genuine interoperability is achievable until we
bite the  bullet and simplify the mechanisms that
support proof of trust.

> It then becomes very difficult to determine a point
> in time at which you can turn off the old schema and
> rely solely on the new one.

Agreed. But just because something is difficult does
that mean that we shouldn't do it ?

Chris




Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h0G794711223 for ietf-pkix-bks; Wed, 15 Jan 2003 23:09:04 -0800 (PST)
Received: from mailf.telia.com (mailf.telia.com [194.22.194.25]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h0G793o11213 for <[e-mail]>; Wed, 15 Jan 2003 23:09:03 -0800 (PST)
Received: from arport (h119n2fls31o1122.telia.com [212.181.142.119]) by mailf.telia.com (8.12.5/8.12.5) with SMTP id h0G794Vp019508 for <[e-mail]>; Thu, 16 Jan 2003 08:09:04 +0100 (CET)
X-Original-Recipient: <[e-mail]>
Message-ID: <003e01c2bd2d$d8fef240$0500a8c0@arport>
From: "Anders Rundgren" <[e-mail]>
To: <[e-mail]>
Subject: CA Liability:Warranty/ draft-ietf-pkix-warranty-extn-01.txt
Date: Thu, 16 Jan 2003 08:06:52 +0100
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.50.4133.2400
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Hi PKI-lawyers,

I took the liberty to check how VeriSign handles this and
it was sort of enlightening (well...)

http://www.verisign.com/netsure ?

They talk about "limited liability warranty" (!!!) which sort of verifies
that what we call this is all over the map but the consequences
are the same as when your house is burning down:  If insured, you 
file a damage report and depending on the cause and nature of the
damage you may get something between zero to full compensation
up to a certain limit.

Q: A typical US SW agreement contains paragraphs that seems to
be intended to LIMIT liability as it states that you use it on your
own risk, and not for mission-critical stuff.  If this really works (it
does?) for software, why would it not work for CAs?

IF it *IS* possible (this ought to be investigated) to limit liability
by an agreement, this should be a part of the extension as there is
a demand for such measures.

Cheers,
Anders Rundgren
Senior Internet e-Commerce Architect




Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h0FEeQD11856 for ietf-pkix-bks; Wed, 15 Jan 2003 06:40:26 -0800 (PST)
Received: from woodstock.binhost.com (woodstock.binhost.com [207.228.252.5]) by above.proper.com (8.11.6/8.11.3) with SMTP id h0FEeOo11852 for <[e-mail]>; Wed, 15 Jan 2003 06:40:24 -0800 (PST)
Received: (qmail 24799 invoked from network); 15 Jan 2003 14:40:00 -0000
Received: from unknown (HELO Russ-Laptop.vigilsec.com) (65.199.255.70) by woodstock.binhost.com with SMTP; 15 Jan 2003 14:40:00 -0000
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9
Date: Wed, 15 Jan 2003 09:36:04 -0500
To: "Liaquat Khan" <[e-mail]>
From: Russ Housley <[e-mail]>
Subject: Re: SCVP validation policy
Cc: [e-mail]
In-Reply-To: <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Liaquat:

The server must identify the policy that was actually used.  The document 
recommends the development of several application-specific validation 
policies.  IPsec, TLS, and S/MIME seem like obvious applications to address.

Of course, the server is free to assign its own OID for its own validation 
policy.

Russ

At 08:15 AM 1/15/2003 +0000, Liaquat Khan wrote:
>Hi,
>
>I have a small confusion on the use of validation policy in SCVP. Imagine the
>following scenario:
>
>1) SCVP client does not identify any validation policy in the request
>message,
>2) SCVP sever therefore uses the default validation policy
>3) When providing the SCVP response which validation policy does the server
>identify in the valPolicy field?    As Section 4.7.6 of the current SCVP
>draft states: "The valPolicy value MUST NOT be id-svp-defaultValPolicy."
>
>The same section also states: "even if the query does not include a
>validation policy, the server MUST indicate the validation policy that was
>used."
>
>So if the server can't identify the default validation policy, which one 
>should
>it identify?
>
>Regards
>
>Liaquat Khan
>Ascertia
>
>----- Original Message -----
>From: "Russ Housley" <<mailto:[e-mail]>[e-mail]>
>To: <<mailto:[e-mail]>[e-mail]>
>Sent: Monday, December 23, 2002 8:40 PM
>Subject: SCVP Compliance Matrix
>
>
> > Dear PKIX Working Group:
> >
> > In preparation for the upcoming straw poll, I am providing the attached
> > compliance matrix for SCVP.  Please review it, and the SCVP specification
> > too.  The updated SCVP specification has been submitted for posting in the
> > Internet-Draft repository.  If should appear soon.
> >
> > Have a safe and joyous holiday season,
> >    Russ



Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h0FC1hW03317 for ietf-pkix-bks; Wed, 15 Jan 2003 04:01:43 -0800 (PST)
Received: from mail.unity.net (nirvana.unity.net [195.24.141.105]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h0FC1co03313 for <[e-mail]>; Wed, 15 Jan 2003 04:01:39 -0800 (PST)
Received: from localhost.intranet (cl0.unity.net [195.24.141.128]) by mail.unity.net (8.12.3/8.12.3) with ESMTP id h0FBuLXT022378; Wed, 15 Jan 2003 13:56:43 +0200
Received: (from vf@localhost) by localhost.intranet (8.9.3/8.8.8/Debian/GNU) id OAA00865; Wed, 15 Jan 2003 14:01:06 +0200
Date: Wed, 15 Jan 2003 14:01:06 +0200
From: Vadim Fedukovich <[e-mail]>
To: Marc Poulaud <[e-mail]>
Cc: [e-mail]
Subject: Re: Q. Automatic certificate selection for signing
Message-ID: <[e-mail]>
References: <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Mailer: Mutt 1.0.1i
In-Reply-To: <[e-mail]>; from [e-mail] on Tue, Jan 14, 2003 at 09:35:11PM -0000
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

On Tue, Jan 14, 2003 at 09:35:11PM -0000, Marc Poulaud wrote:
> A question for those involved with signing applications (or anybody else
> with 2 cents)...
> 
> I'm interested to understand what might be some of the key issues/options
> for a signing application that needs to select the right certificate for
> signing a piece of data. I see two main options. One is that there is a
> configuration option that allows a particular user to be associated with a
> particular certificate (a la Outlook - I want to use this certificate (and
> associated key) to sign my outgoing emails). Another is that, during the
> signing operation, some how select the right certificate based on a value
> coded in a certificate.

Maybe one can think signing with what key will be acceptable by
recipient or relaying party. Having access to too many keys might
undermine confidence in signatures made with that keys.
Yes, password- (or better) protected roles/profiles looks not bad.

> On the one hand I think the latter would be a smart move if it where
> possible to use some standard (and therefore interoperable) way of doing
> this (unlike my initial thought of having an 'application' specific value
> in an OU field) or perhaps a more suitable field within a certificate
> (perhaps a policy qualifier?).
> 
> Anybody have experience of such matters?

Mastercard wallet (SET protocol) allow to pickup a password-protected
user profile and then use card-specific keys to sign protocol messages.

regards,
Vadim
-- 
Naina library: http://www.unity.net/~vf/naina_r1.tgz


Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h0FASqo25257 for ietf-pkix-bks; Wed, 15 Jan 2003 02:28:52 -0800 (PST)
Received: from exafix.addtrust.com ([212.112.175.83]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h0FASlo25245 for <[e-mail]>; Wed, 15 Jan 2003 02:28:49 -0800 (PST)
Received: from Santesson ([192.168.101.117]) by exafix.addtrust.com with Microsoft SMTPSVC(5.0.2195.2966); Wed, 15 Jan 2003 11:28:54 +0100
From: "Stefan Santesson" <[e-mail]>
To: "Anders Rundgren" <[e-mail]>, <[e-mail]>
Subject: RE: RFC3039/X.500 naming question
Date: Wed, 15 Jan 2003 11:28:54 +0100
Message-ID: <[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.6604 (9.0.2911.0)
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106
Importance: Normal
In-Reply-To: <012901c2bbb6$11d292d0$0500a8c0@arport>
X-OriginalArrivalTime: 15 Jan 2003 10:28:54.0405 (UTC) FILETIME=[E7690350:01C2BC80]
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

> -----Original Message-----
> From: Anders Rundgren [mailto:[e-mail]]
> Sent: Tuesday, January 14, 2003 11:17 AM
> To: Stefan Santesson; [e-mail]
> Subject: Re: RFC3039/X.500 naming question
>
>
> Thanx Stefan,
> some minor "return-data".
>
> >> A colleague of mine claims that the DN
> >>
> >>    "CN=Marion Anderson, serialNumber=nnnnnnnnnnnn, C=SE"
> >>
> >> denotes a Swedish citizen according to ISO/ITU standards.
>
> >What ISO/ITU Standard would that be?
>
> The ones that are the foundation for X.500, that's all I know.

Where? To my knowledge there is no such thing. You need to dig that out and
show me.

>
> >My guess is that your colleague is wrong. There is at least
> nothing in RFC
> >3280 or RFC 3039 that support that statement.
>
> So I have understood it as well.  But he claims that you must FIRST
> read the ISO/ITU-stuff which is NORMATIVE and then see what's
> fits with the PKIX RFCs.  I find this both awkard and unrealistic.
>

But first he must show where ISO/ITU contradict RFC 3039. I think I dare to
promise that there is no such thing.
We where in liaison with the ITU folks when writing RFC 3039 and we even
managed to get a change in X.520 definition of SerialNumber in order for
X.509 to support the RFC 3039 use of the attribute.


> <snip>
>
> >> I claim that this is a "convention" (maybe even "good practice")
> >> but that this statement at least has no support in PKIX RFCs.
> >> RFC3039 which should be close to this issue is BTW absolutely
> >> mum about what "C" actually means.
>
> >Actually not.
>
> >RFC 3039 section 3.1.2 says:
>
> >   The countryName attribute value specifies a general context in which
> >   other attributes are to be understood.  The country attribute does
> >   not necessarily indicate the subject's country of citizenship or
> >   country of residence, nor does it have to indicate the country of
> >   issuance.
>
> Well, "mum" was an exaggeration of mine, but it is pretty clear that "C"
> do not carry huge semantic weight in RFC3039.  Which IMO is perfectly OK.
>

It is as it must be. If you want to define country of residence and
citizenship, there are ways in RFC 3039 to do so.
Look in subject directory attributes section.

/Stefan

> <snip>
>
> Anders
>
>



Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h0F98uI17407 for ietf-pkix-bks; Wed, 15 Jan 2003 01:08:56 -0800 (PST)
Received: from mailhost.netbenefit.co.uk (mailhost.netbenefit.co.uk [212.53.64.39]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h0F98so17397 for <[e-mail]>; Wed, 15 Jan 2003 01:08:55 -0800 (PST)
Received: from [202.179.149.202] (helo=ascertiacompaq)  by mailhost.netbenefit.co.uk with smtp (NetBenefit 1.5) id 18YjXW-0004of-00  for [e-mail]; Wed, 15 Jan 2003 09:08:51 +0000
From: "Liaquat Khan" <[e-mail]>
To: "Ietf-Pkix@Imc. Org" <[e-mail]>
Subject: FW: Automatic certificate selection for signing
Date: Wed, 15 Jan 2003 08:59:54 -0000
Message-ID: <[e-mail]>
MIME-Version: 1.0
Content-Type: multipart/related; boundary="----=_NextPart_000_0073_01C2BC74.78987200"
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0)
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000
Importance: Normal
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

This is a multi-part message in MIME format.

------=_NextPart_000_0073_01C2BC74.78987200
Content-Type: multipart/alternative;
	boundary="----=_NextPart_001_0074_01C2BC74.78987200"


------=_NextPart_001_0074_01C2BC74.78987200
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit



Hi Marc,

The client application could look at the KeyUsage extension, and from here
determine the correct certificate to be used for the task at hand (e.g.
signing or encrypting).  Alternatively the use of the Certificate Policies
extension is also not a bad idea, but you need to ensure your CA does
include this in the end-user's certificate.  Also you need to think about
what it will take for your client application to support new certificate
policy identifiers.  Note your certificate policy identifier may change
through a simple update of your certificate policy (e.g. change of address
or contact details), now how easy will it be to change all your client
applications to accept the new certificate policy identifier as well as the
old one?

Regards,
LK
  ----- Original Message -----
  From: Marc Poulaud
  To: Ietf-Pkix@Imc. Org
  Sent: Tuesday, January 14, 2003 9:35 PM
  Subject: Q. Automatic certificate selection for signing


  A question for those involved with signing applications (or anybody else
with 2 cents)...

  I'm interested to understand what might be some of the key issues/options
for a signing application that needs to select the right certificate for
signing a piece of data. I see two main options. One is that there is a
configuration option that allows a particular user to be associated with a
particular certificate (a la Outlook - I want to use this certificate (and
associated key) to sign my outgoing emails). Another is that, during the
signing operation, some how select the right certificate based on a value
coded in a certificate.

  On the one hand I think the latter would be a smart move if it where
possible to use some standard (and therefore interoperable) way of doing
this (unlike my initial thought of having an 'application' specific value in
an OU field) or perhaps a more suitable field within a certificate (perhaps
a policy qualifier?).

  Anybody have experience of such matters?

  Marc.
Liaquat Khan       Chief Consultancy Officer

     a leading provider of real-time Certificate Validation solutions

E-Mail: [e-mail]
Mobile: [phone]


Adding Trust to your PKI

www.ascertia.com

The opinions expressed are those of the individual and not the company.
Internet communications are not secure and therefore the company does not
accept legal responsibility for the contents of this message.  If the reader
of this message is not the intended recipient, or the employee responsible
for delivering this communication to the intended recipient, you are hereby
notified that any disclosure, distribution or copying of this communication
is strictly prohibited.



------=_NextPart_001_0074_01C2BC74.78987200
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 http-equiv=3DContent-Type content=3D"text/html; =
charset=3Diso-8859-1">
<META content=3D"MSHTML 6.00.2600.0" name=3DGENERATOR></HEAD>
<BODY>
<DIV><FONT face=3DTahoma size=3D2><BR></FONT>&nbsp;</DIV>
<DIV>
<DIV><FONT face=3DArial size=3D2><SPAN class=3D614121708-15012003>Hi=20
Marc,</SPAN></FONT></DIV>
<DIV><FONT face=3DArial size=3D2><SPAN=20
class=3D614121708-15012003></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2><SPAN class=3D614121708-15012003>The =
client=20
application&nbsp;could look at the KeyUsage extension, and from here =
determine=20
the correct certificate to be used for the task at hand (e.g. signing or =

encrypting).&nbsp; Alternatively the use of the Certificate Policies =
extension=20
is also not a bad idea, but you need to ensure your CA does include this =
in the=20
end-user's certificate.&nbsp; Also you need to think about what it will =
take for=20
your client application to support new certificate policy =
identifiers.&nbsp;=20
Note your certificate policy identifier may change through a simple =
update of=20
your certificate policy (e.g. change of address or contact details), now =
how=20
easy will it be to change all your client applications to accept the new =

certificate policy identifier as well as the old =
one?</SPAN></FONT></DIV>
<DIV><FONT face=3DArial size=3D2><SPAN=20
class=3D614121708-15012003></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2><SPAN=20
class=3D614121708-15012003>Regards,</SPAN></FONT></DIV>
<DIV><FONT face=3DArial size=3D2><SPAN=20
class=3D614121708-15012003>LK</SPAN></FONT></DIV>
<BLOCKQUOTE dir=3Dltr=20
style=3D"PADDING-RIGHT: 0px; PADDING-LEFT: 5px; MARGIN-LEFT: 5px; =
BORDER-LEFT: #000000 2px solid; MARGIN-RIGHT: 0px">
  <DIV style=3D"FONT: 10pt arial">----- Original Message ----- </DIV>
  <DIV=20
  style=3D"BACKGROUND: #e4e4e4; FONT: 10pt arial; font-color: =
black"><B>From:</B>=20
  <A title=[e-mail]=20
  href=3D"mailto:[e-mail]">Marc Poulaud</A> </DIV>
  <DIV style=3D"FONT: 10pt arial"><B>To:</B> <A =
title=[e-mail]=20
  href=3D"mailto:Ietf-Pkix@Imc. Org">Ietf-Pkix@Imc. Org</A> </DIV>
  <DIV style=3D"FONT: 10pt arial"><B>Sent:</B> Tuesday, January 14, 2003 =
9:35=20
  PM</DIV>
  <DIV style=3D"FONT: 10pt arial"><B>Subject:</B> Q. Automatic =
certificate=20
  selection for signing</DIV>
  <DIV><FONT face=3DArial><BR><FONT size=3D2></FONT></FONT></DIV>
  <DIV><FONT face=3DArial size=3D2><SPAN class=3D346562121-14012003>A =
question for=20
  those involved with signing applications (or anybody else with 2=20
  cents)...</SPAN></FONT></DIV>
  <DIV><FONT face=3DArial size=3D2><SPAN=20
  class=3D346562121-14012003></SPAN></FONT>&nbsp;</DIV>
  <DIV><FONT face=3DArial><FONT size=3D2><SPAN =
class=3D346562121-14012003>I'm=20
  interested to understand what might be some of the key issues/options =
for a=20
  signing application that needs to select the right certificate for =
signing a=20
  piece of data. I see two main options. One is that there is a=20
  configuration&nbsp;option that allows a particular user to be =
associated with=20
  a particular certificate (a la Outlook - I want to use this =
certificate (and=20
  associated key) to sign my outgoing emails). Another is that, during =
the=20
  signing operation, some how select the right certificate based on a =
value=20
  coded in</SPAN><SPAN class=3D346562121-14012003>&nbsp;a=20
  certificate.</SPAN></FONT></FONT></DIV>
  <DIV><FONT face=3DArial size=3D2><SPAN=20
  class=3D346562121-14012003></SPAN></FONT>&nbsp;</DIV>
  <DIV><FONT face=3DArial size=3D2><SPAN class=3D346562121-14012003>On =
the one hand I=20
  think the latter would be a smart move if it where possible to use =
some=20
  standard (and therefore interoperable) way of doing this (unlike my =
initial=20
  thought of having&nbsp;an 'application' specific value in an OU field) =
or=20
  perhaps a more suitable field within a certificate (perhaps a policy=20
  qualifier?).</SPAN></FONT></DIV>
  <DIV><FONT face=3DArial size=3D2><SPAN=20
  class=3D346562121-14012003></SPAN></FONT>&nbsp;</DIV>
  <DIV><FONT face=3DArial size=3D2><SPAN =
class=3D346562121-14012003>Anybody have=20
  experience of such matters?</SPAN></FONT></DIV>
  <DIV><FONT face=3DArial size=3D2><SPAN=20
  class=3D346562121-14012003></SPAN></FONT>&nbsp;</DIV>
  <DIV><FONT face=3DArial size=3D2><SPAN=20
  =
class=3D346562121-14012003>Marc.</SPAN></FONT></DIV></BLOCKQUOTE></DIV>
<P><FONT face=3DArial color=3D#008080 size=3D2><STRONG><EM>Liaquat=20
Khan&nbsp;&nbsp;</EM></STRONG><FONT color=3D#000000=20
size=3D1>&nbsp;&nbsp;&nbsp;&nbsp; </FONT></FONT><FONT face=3DArial =
size=3D1>Chief=20
Consultancy Officer</FONT></P>
<P><FONT face=3DArial size=3D1><IMG height=3D58 =
src=3D"cid:614121708@15012003-2092"=20
width=3D90 border=3D0>&nbsp;&nbsp;&nbsp;&nbsp; </FONT><FONT face=3DArial =
size=3D1>a=20
leading provider of real-time&nbsp;Certificate Validation =
solutions</FONT></P>
<P><STRONG><FONT face=3DArial size=3D1>E-Mail:</FONT></STRONG> <FONT =
face=3DArial=20
size=3D1><A=20
href=3D"mailto:[e-mail]">[e-mail]</A></FONT><FONT=
=20
face=3DArial size=3D1><BR></FONT><B><FONT face=3DArial =
size=3D1>Mobile:</FONT></B><FONT=20
face=3DArial size=3D1> [phone]</FONT><BR></P>
<P align=3Dcenter><FONT color=3D#008080 size=3D6>Adding <EM>Trust</EM> =
to your=20
PKI</FONT></P>
<P align=3Dcenter><A href=3D"http://www.ascertia.com/"><U></U><U><FONT =
face=3DArial=20
color=3D#0000ff size=3D2>www.ascertia.com</FONT></U></A></P>
<P align=3Dleft><FONT face=3DArial color=3D#808080 size=3D1>The opinions =
expressed are=20
those of the individual and not the company. Internet communications are =
not=20
secure and therefore the company does not accept legal responsibility =
for the=20
contents of this message.&nbsp; If the reader of this message is not the =

intended recipient, or the employee responsible for delivering this=20
communication to the intended recipient, you are hereby notified that =
any=20
disclosure, distribution or copying of this communication is strictly=20
prohibited.</FONT></P>
<DIV>&nbsp;</DIV></BODY></HTML>

------=_NextPart_001_0074_01C2BC74.78987200--

------=_NextPart_000_0073_01C2BC74.78987200
Content-Type: image/gif;
	name="Omar.h1.gif"
Content-Transfer-Encoding: base64
Content-ID: <614121708@15012003-2092>

R0lGODlhWgA6APcAAP///yQhIjmJyWhqbGS+a8jKzAWAxKDTnqiqrejp63el2MHiv6vD5dve5/Hy
897v3haY/Hf4CBMAYPoSAGj6EgAAAAAAePgSAAACAAAw+hIA24D7dxhE+Xf/////QPoSAFCa/Hdn
mvx3CgIAAID6EgAAAAAAAAATAAC4FQAAAAAAuPgSAIgGEwBs+RIA24D7d9CY+Hd4ARMAeAETAOyc
/HeoBxMACLgVAAAAAIgABAQAfPoSAAAEBAADAAAAAAAAAAAAAAAw+RIAXVnhd8BoVgABN/l3GAAA
AAAAAAAAAAAAWPkSACQAAADTQ/l3SA0TAAAAEwAkAAAA4FQTADD5EgAAAgAA6PoSANuA+3cYRPl3
//////j6EgAWmPx3SA0TAAAAAAAAAAAAqHNIAKD5EgAAAAAAmJj4dwAAEwBQbhcAAAAAAHz5EgCI
BhMAMPoSANuA+3fQmPh3/////0D6EgDsnPx32AcTAFhuFwBsbhcAWG4XAAEAAADQmPh3AwAAAAAA
AAAAAAgCDQAAALgAugBw1hMA33f4d5DR/HfEd/h32GATALhgEwBsbhcAAAAAAAAAAAA4+hIA24D7
d4h4+Hf/////SPoSAAAAEwAHAAAAAG4XAFhuFwABAAAAAWATABDQ/Hew+RIAgPoSAID6EgDbgPt3
iK74d/////+Q+hIAsI3odwAAEwAAAAAAAQAAAG1c4XcAAAAAAQAAAADg/X+wTBcAAAAAAFhuFwAA
AAAAKAEAAFT6EgAAAAAAsP8SAP0T6nfIjeh3/////4iu+HfcTUMAWG4XAAAAEwAAAAAAIAAAAKC8
cs/FIsIBAHgAbyQAAAAAPLZwq9nAAQAAAAAZAwAAAAATAA0AAABsb2dv4FQTACABAAAZuUAA3gII
AN4CCAA0+xIA24D7d3iu+Hf/////RPsSAH9J6XcAABMACAAUABgBAABtXOF3AAAAAAAAAAAAAAAA
AAAAAMTARAA5VRMAXMQVAD1VEwAFdEgA/////+BUEwAuwUQAOVUTACH5BAAAAAAALAAAAABaADoA
AAj+AAEIHEiwoMGDCBMqXMiwocOHECNKnEixosWLGDMuTNDAgcaPIAkyEGCgpAIGIVNeVFBSgMuS
KFXKfNiApMubLxXM3LmQJc6fBmLyHErwp1EDOokqdWC0qVKlDQw0xWngKdEEUqfetEpU60sBXId6
JSk0rEyvJROY3am1ZIO1M6NSLYnUI1yZPklKZfD27swCWff63dkgL9LBMhswYJmVpF3EH0fSpZr0
4IMFBxY8gOyQcdOglgmIHn1gM+eEeT+XFbhgtGvRC04fxIq2QEEHr3PLNphadcEDuV/H3j3QZtvK
AoO/PkC8+NjDA3ErJ91coPGp0AVKn06AeXUGjT/+9x0InLv35g5afkbOmjsB09/D34R50H11keq/
riZYfvn9goXRlZ0DBYw3UGuuDfefQQ0YCAACAQSA0AMPPLZgQxBK+BECA3Q4AAIIcRjAAA4KJOIA
thnkwAAjpqhihyAOVECEHboIQAEdqiVQAh5+iBCLEdJoUIZBMhhkhDYKBGSEMRLkQJADPEZkAAhI
GeF4DRwZoY4ELRlkklpSWZCXEY4ZJpcCHTkAQTMG2eSNET6WpZZrKsRindpt+WCZ0emZoYFIpjki
QRkeVKhBbVrIJp8J3UnQnGoduuOVewZgY6AACDmQpIQyumgAisroKaEejignpRziCcCTlt5YI0H+
TBaQoaqciqphQYnimuqoStJZkKYqBurAsL+GSSuvlR6Uq3ZT8kokkFHCemSSrCYpra+bIlurQMsK
OmKRZmroaKdHGlhtQjQioC4CNm4L562fPlYtgbwC2Wu0Too4aJ+tIoTpqgW56263CQS6rb0AjLtj
h73Cey6OJEobI7HkGooswQbXy+edj7VpG6fnZnipmAXva+LFKIM6UMkfayyuyQCU7BHIcVYKaL/A
JjtkyvJS2ubOVJ5oYboKC/ohkGimm+GbAvMs7dG8zqlmsUe+mXCYAWNdMaJOD0QmvDKSievUt6lp
7ZIoZg221yobxKKBDYh9kEfDhipQAwXYvSMcAiWuzG6oDiSAJq565z33sINfqPjijDfu+OMBAQA7

------=_NextPart_000_0073_01C2BC74.78987200--



Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h0F8Omm10879 for ietf-pkix-bks; Wed, 15 Jan 2003 00:24:48 -0800 (PST)
Received: from mailhost.netbenefit.co.uk (mailhost.netbenefit.co.uk [212.53.64.39]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h0F8Oko10864 for <[e-mail]>; Wed, 15 Jan 2003 00:24:46 -0800 (PST)
Received: from [202.179.149.202] (helo=ascertiacompaq)  by mailhost.netbenefit.co.uk with smtp (NetBenefit 1.5) id 18Yiqp-0000PT-00  for [e-mail]; Wed, 15 Jan 2003 08:24:44 +0000
From: "Liaquat Khan" <[e-mail]>
To: "Ietf-Pkix@Imc. Org" <[e-mail]>
Subject: SCVP validation policy
Date: Wed, 15 Jan 2003 08:15:48 -0000
Message-ID: <[e-mail]>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_0049_01C2BC6E.4F340970"
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0)
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000
Importance: Normal
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

This is a multi-part message in MIME format.

------=_NextPart_000_0049_01C2BC6E.4F340970
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit

Hi,

I have a small confusion on the use of validation policy in SCVP. Imagine
the
following scenario:

1) SCVP client does not identify any validation policy in the request
message,
2) SCVP sever therefore uses the default validation policy
3) When providing the SCVP response which validation policy does the server
identify in the valPolicy field?    As Section 4.7.6 of the current SCVP
draft states: "The valPolicy value MUST NOT be id-svp-defaultValPolicy."

The same section also states: "even if the query does not include a
validation policy, the server MUST indicate the validation policy that was
used."

So if the server can't identify the default validation policy, which one
should
it identify?

Regards

Liaquat Khan
Ascertia

----- Original Message -----
From: "Russ Housley" <[e-mail]>
To: <[e-mail]>
Sent: Monday, December 23, 2002 8:40 PM
Subject: SCVP Compliance Matrix


> Dear PKIX Working Group:
>
> In preparation for the upcoming straw poll, I am providing the attached
> compliance matrix for SCVP.  Please review it, and the SCVP specification
> too.  The updated SCVP specification has been submitted for posting in the
> Internet-Draft repository.  If should appear soon.
>
> Have a safe and joyous holiday season,
>    Russ


------=_NextPart_000_0049_01C2BC6E.4F340970
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 http-equiv=3DContent-Type content=3D"text/html; =
charset=3Diso-8859-1">
<META content=3D"MSHTML 6.00.2600.0" name=3DGENERATOR></HEAD>
<BODY>
<DIV><FONT face=3DArial size=3D2>Hi,<BR><BR>I have a&nbsp;<SPAN=20
class=3D808050808-15012003>small </SPAN>confusion on the use of =
validation policy=20
in SCVP. Imagine the<BR>following scenario:<BR><BR>1) SCVP client does =
not=20
identify any validation policy in the request<BR>message,<BR>2) SCVP =
sever=20
therefore uses the default validation policy<BR>3) When providing the =
SCVP=20
response which validation policy does the server<BR>identify in the =
valPolicy=20
field?&nbsp;&nbsp;&nbsp; As Section 4.7.6 of the current SCVP<BR>draft =
states:=20
"The valPolicy value MUST NOT be id-svp-defaultValPolicy."<BR><BR>The =
same=20
section also states: "even if the query does not include a<BR>validation =
policy,=20
the server MUST indicate the validation policy that =
was<BR>used."<BR><BR>So if=20
the server can't identify the default validation policy<SPAN=20
class=3D808050808-15012003>,</SPAN> which one&nbsp;<SPAN=20
class=3D808050808-15012003>should</SPAN><BR>it=20
identify?<BR><BR>Regards<BR><BR>L<SPAN class=3D808050808-15012003>iaquat =

</SPAN>K<SPAN class=3D808050808-15012003>han</SPAN></FONT></DIV>
<DIV><FONT><SPAN class=3D808050808-15012003></SPAN><SPAN=20
class=3D808050808-15012003></SPAN><FONT face=3DArial size=3D2>A<SPAN=20
class=3D808050808-15012003>scertia</SPAN></FONT></FONT></DIV>
<DIV><FONT><FONT face=3DArial size=3D2><SPAN=20
class=3D808050808-15012003></SPAN><BR>----- Original Message =
-----<BR>From: "Russ=20
Housley" &lt;</FONT></FONT><A href=3D"mailto:[e-mail]"><FONT =

face=3DArial size=3D2>[e-mail]</FONT></A><FONT face=3DArial=20
size=3D2>&gt;<BR>To: &lt;</FONT><A =
href=3D"mailto:[e-mail]"><FONT=20
face=3DArial size=3D2>[e-mail]</FONT></A><FONT face=3DArial=20
size=3D2>&gt;<BR>Sent: Monday, December 23, 2002 8:40 PM<BR>Subject: =
SCVP=20
Compliance Matrix<BR><BR><BR>&gt; Dear PKIX Working =
Group:<BR>&gt;<BR>&gt; In=20
preparation for the upcoming straw poll, I am providing the =
attached<BR>&gt;=20
compliance matrix for SCVP.&nbsp; Please review it, and the SCVP=20
specification<BR>&gt; too.&nbsp; The updated SCVP specification has been =

submitted for posting in the<BR>&gt; Internet-Draft repository.&nbsp; If =
should=20
appear soon.<BR>&gt;<BR>&gt; Have a safe and joyous holiday=20
season,<BR>&gt;&nbsp;&nbsp;&nbsp; Russ<BR></DIV></FONT></BODY></HTML>

------=_NextPart_000_0049_01C2BC6E.4F340970--



Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h0F7KKs28207 for ietf-pkix-bks; Tue, 14 Jan 2003 23:20:20 -0800 (PST)
Received: from maild.telia.com (maild.telia.com [194.22.190.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h0F7KIo28203 for <[e-mail]>; Tue, 14 Jan 2003 23:20:18 -0800 (PST)
Received: from arport (h119n2fls31o1122.telia.com [212.181.142.119]) by maild.telia.com (8.12.5/8.12.5) with SMTP id h0F7KDxU007381; Wed, 15 Jan 2003 08:20:13 +0100 (CET)
X-Original-Recipient: [e-mail]
Message-ID: <005101c2bc66$3e579b10$0500a8c0@arport>
From: "Anders Rundgren" <[e-mail]>
To: "Marc Poulaud" <[e-mail]>, "Ietf-Pkix@Imc. Org" <[e-mail]>
References: <[e-mail]>
Subject: Re: Q. Automatic certificate selection for signing
Date: Wed, 15 Jan 2003 08:18:03 +0100
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_004E_01C2BC6E.9FFF0530"
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.50.4133.2400
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

This is a multi-part message in MIME format.

------=_NextPart_000_004E_01C2BC6E.9FFF0530
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Marc,
The only techically working solution for Web-signing is schemes like the =
one used in HTTPS/SSL where the relying party indicates the issuer etc. =
of accepted certificates.   This is already a part of the =
next-generation mobile-phone system developed by PKIX's Magnus Nystr=F6m =
et al.

Anders
  ----- Original Message -----=20
  From: Marc Poulaud=20
  To: Ietf-Pkix@Imc. Org=20
  Sent: Tuesday, January 14, 2003 22:35
  Subject: Q. Automatic certificate selection for signing


  A question for those involved with signing applications (or anybody =
else with 2 cents)...
  =20
  I'm interested to understand what might be some of the key =
issues/options for a signing application that needs to select the right =
certificate for signing a piece of data. I see two main options. One is =
that there is a configuration option that allows a particular user to be =
associated with a particular certificate (a la Outlook - I want to use =
this certificate (and associated key) to sign my outgoing emails). =
Another is that, during the signing operation, some how select the right =
certificate based on a value coded in a certificate.
  =20
  On the one hand I think the latter would be a smart move if it where =
possible to use some standard (and therefore interoperable) way of doing =
this (unlike my initial thought of having an 'application' specific =
value in an OU field) or perhaps a more suitable field within a =
certificate (perhaps a policy qualifier?).
  =20
  Anybody have experience of such matters?
  =20
  Marc.

------=_NextPart_000_004E_01C2BC6E.9FFF0530
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.3103.1000" name=3DGENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=3D#ffffff>
<DIV><FONT face=3DArial size=3D2>Marc,</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>The only techically working solution =
for=20
Web-signing is schemes like the one used in HTTPS/SSL where the relying =
party=20
indicates the issuer etc. of accepted certificates.&nbsp;&nbsp; This is =
already=20
a part of the next-generation mobile-phone system developed by PKIX's =
Magnus=20
Nystr=F6m et al.</FONT></DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>Anders</FONT></DIV>
<BLOCKQUOTE=20
style=3D"BORDER-LEFT: #000000 2px solid; MARGIN-LEFT: 5px; MARGIN-RIGHT: =
0px; PADDING-LEFT: 5px; PADDING-RIGHT: 0px">
  <DIV style=3D"FONT: 10pt arial">----- Original Message ----- </DIV>
  <DIV=20
  style=3D"BACKGROUND: #e4e4e4; FONT: 10pt arial; font-color: =
black"><B>From:</B>=20
  <A href=3D"mailto:[e-mail]"=20
  title=[e-mail]>Marc Poulaud</A> </DIV>
  <DIV style=3D"FONT: 10pt arial"><B>To:</B> <A =
href=3D"mailto:Ietf-Pkix@Imc. Org"=20
  title=[e-mail]>Ietf-Pkix@Imc. Org</A> </DIV>
  <DIV style=3D"FONT: 10pt arial"><B>Sent:</B> Tuesday, January 14, 2003 =

  22:35</DIV>
  <DIV style=3D"FONT: 10pt arial"><B>Subject:</B> Q. Automatic =
certificate=20
  selection for signing</DIV>
  <DIV><BR></DIV>
  <DIV><FONT face=3DArial size=3D2><SPAN class=3D346562121-14012003>A =
question for=20
  those involved with signing applications (or anybody else with 2=20
  cents)...</SPAN></FONT></DIV>
  <DIV><FONT face=3DArial size=3D2><SPAN=20
  class=3D346562121-14012003></SPAN></FONT>&nbsp;</DIV>
  <DIV><FONT face=3DArial size=3D2><SPAN class=3D346562121-14012003>I'm =
interested to=20
  understand what might be some of the key issues/options for a signing=20
  application that needs to select the right certificate for signing a =
piece of=20
  data. I see two main options. One is that there is a =
configuration&nbsp;option=20
  that allows a particular user to be associated with a particular =
certificate=20
  (a la Outlook - I want to use this certificate (and associated key) to =
sign my=20
  outgoing emails). Another is that, during the signing operation, some =
how=20
  select the right certificate based on a value coded =
in</SPAN></FONT><FONT=20
  face=3DArial size=3D2><SPAN class=3D346562121-14012003>&nbsp;a=20
  certificate.</SPAN></FONT></DIV>
  <DIV><FONT face=3DArial size=3D2><SPAN=20
  class=3D346562121-14012003></SPAN></FONT>&nbsp;</DIV>
  <DIV><FONT face=3DArial size=3D2><SPAN class=3D346562121-14012003>On =
the one hand I=20
  think the latter would be a smart move if it where possible to use =
some=20
  standard (and therefore interoperable) way of doing this (unlike my =
initial=20
  thought of having&nbsp;an 'application' specific value in an OU field) =
or=20
  perhaps a more suitable field within a certificate (perhaps a policy=20
  qualifier?).</SPAN></FONT></DIV>
  <DIV><FONT face=3DArial size=3D2><SPAN=20
  class=3D346562121-14012003></SPAN></FONT>&nbsp;</DIV>
  <DIV><FONT face=3DArial size=3D2><SPAN =
class=3D346562121-14012003>Anybody have=20
  experience of such matters?</SPAN></FONT></DIV>
  <DIV><FONT face=3DArial size=3D2><SPAN=20
  class=3D346562121-14012003></SPAN></FONT>&nbsp;</DIV>
  <DIV><FONT face=3DArial size=3D2><SPAN=20
  =
class=3D346562121-14012003>Marc.</SPAN></FONT></DIV></BLOCKQUOTE></BODY><=
/HTML>

------=_NextPart_000_004E_01C2BC6E.9FFF0530--



Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h0EMRcE09769 for ietf-pkix-bks; Tue, 14 Jan 2003 14:27:38 -0800 (PST)
Received: from mail.coastside.net (mail.coastside.net [207.213.212.6]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h0EMRbo09765 for <[e-mail]>; Tue, 14 Jan 2003 14:27:37 -0800 (PST)
Received: from MMyersLapTop (ppp213-51.coastside.net [207.213.213.51]) by mail.coastside.net  with SMTP id h0EMRS81001686 for <[e-mail]>; Tue, 14 Jan 2003 14:27:29 -0800 (PST)
From: "Michael Myers" <[e-mail]>
To: <[e-mail]>
Subject: OCSP for DPV and DPD rqmts compliance
Date: Tue, 14 Jan 2003 15:22:44 -0800
Message-ID: <[e-mail]>
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="----=_NextPart_000_0000_01C2BBE0.C9A77AE0"
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0)
Importance: Normal
In-Reply-To: <[e-mail]>
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

This is a multi-part message in MIME format.

------=_NextPart_000_0000_01C2BBE0.C9A77AE0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit

All,

Apologies for being a bit late on this.  Compliance statements
per Tim's direction attached.

Mike


------=_NextPart_000_0000_01C2BBE0.C9A77AE0
Content-Type: text/plain;
	name="DpvDPDRqmtsComply.txt"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: attachment;
	filename="DpvDPDRqmtsComply.txt"

Topic 1: Basic Protocol

1. If the DPV server does not support the client requested  validation =
policy, then the=20
DPV server MUST return an error. (4.1. Basic Protocol)

Errors are returned via RFC2560 encapsulation. An error state for=20
unsuportedPolicy can be folded into the ongoing work for OCSPv2.=20

2. If the DPV request does not specify a validation policy, the  server =
response MUST=20
indicate the validation policy that was used.  (4.1. Basic Protocol)

"If a DPV request does not indicate a validation policy, DPV responders=20
SHALL include the DPV extended response OID and syntax in their=20
responses and SHALL identify in the policy field of that syntax the OID=20
identifying the policy in effect when the response was produced."

3. The protocol MUST allow the client to include these policy dependent =
parameters in=20
the DPV request; however, it is expected that most clients will simply =
reference a=20
validation policy for a given application or accept the DPV server's =
default validation =20
policy. (4.1. Basic Protocol)

[For the candidate protocol, state the provisions it includes for such =
parameters.]

As it relates to DPV requests, the ExtendedOCSPRequest enables=20
specification of initialPolicySet, trustPoints and a token field related =
to the=20
nature or reason for the query.

4. The DPV server MUST obtain revocation status information for the =
validation time in=20
the client request. (4.1. Basic Protocol)=20

[a. Indicate how a conformant server for the candidate protocol deals  =
with other than=20
"current time" validation requests.]

 [b. For the candidate protocol, indicate which revocation status =
methods a conformant=20
server is required to support. A DPV server must support some revocation =
status=20
methods, but the methods used by different CAs may differ, suggesting =
that a server=20
needs to be prepared to deal with several such methods. A server may =
need to be=20
configured to use specific methods for specific CAs. How does the =
candidate protocol=20
accommodate this need?]

Need to address this.

5. If the revocation status information for the requested validation =
time is unavailable,=20
then the DPV server MUST return a status indicating that the certificate =
is invalid.=20
Additional information about the reason for invalidity MAY also be =
provided. (4.1 Basic=20
Protocol)

The invalid state is addressed.  Reasons are enabled.

6. The certificate to be validated MUST either be directly provided in =
the request or=20
unambiguously referenced, such as the CA distinguished name, certificate =
serial number,=20
and the hash of the certificate, like ESSCertID as defined in [ESS] or=20
OtherSigningCertificate as defined in [ES-F]. (4.1 Basic Protocol)=20

 [For the candidate protocol, specify which formats for certificate =
references MUST be=20
supported by conformant clients and servers. The lists may differ for =
clients vs. servers,=20
e.g., servers may bear the burden of having to accept a larger range of =
reference types, to=20
ease the burden on clients.]=20

CertID syntax in [RFC2560] enables such a means.  Collateral WG efforts  =

on expanding this syntax will enable other mechanisms.

7. The DPV client MUST be able to provide to the validation server, =
associated with each=20
certificate to be validated, useful certificates, as well as useful =
revocation information.=20
(4.1 Basic Protocol)

[For the candidate protocol, indicate which forms of revocationstatus =
info a conformant=20
client is allowed to provide, and whatforms of revocation status data a =
conformant server=20
MUST beprepared to accept from a client.]

pathParams and revInfo are available in  DPVOptions.

3379 does not assert a requirement for normative specification of =
minimal=20
server-side requirements governing revocation data forms or formats. =20
Further WG consensus on this is point is anticipated.

8. The DPV server MUST have the certificate to be validated.  When the =
certificate is not=20
provided in the request, the server MUST obtain the certificate and then =
verify that the=20
certificate is indeed the one being unambiguous referenced by the =
client. (4.1 Basic=20
Protocol)

[For the candidate protocol, specify what mechanisms a conformantserver =
MUST=20
implement in support of this requirement, e.g., retrieval of a =
certificate via LDAP=20
queries.]

The cited text isinterpreted as an obvious fact.

3379 asserts no requirement for a normative specification of minimal=20
server-side certificate retrival mechanisms  Further WG consensus on =
this=20
is point is anticipated.
.

9. The DPV server MUST include either the certificate or an unambiguous =
reference to=20
the certificate (in case of a CA key compromise) in the DPV response. =
(4.1 Basic=20
Protocol)=20

Certificate reference is enabled via BasicOCSPResponse syntax of =
RFC2560.

10. The DPV response MUST indicate one of the following status =
alternatives:

   1.	the certificate is valid according to the validation policy.

   2.	the certificate is not valid according to the validation policy.

   3.	the validity of the certificate is unknown according to the  =
validation policy.

   4.	the validity could not be determined due to an error.

 (source for 10: 4.1 Basic Protocol)

The valid, invalid and unknown states are addressed.  RFC2560 governs=20
production of errors.

11. When the certificate is not valid according to the validation =
policy, then the reason=20
MUST also be indicated.  Invalidity reasons include:

   1.	the DPV server cannot determine the validity of the certificate =
because a=20
certification path cannot be constructed.

   2.	the DPV server successfully constructed a certification path,    =
but it was not valid=20
according to the validation algorithm in  [PKIX-1].

   3.	the certificate is not valid at this time.  If another request =
could be made later on,=20
the certificate could possibly be determined as valid.  This condition =
may occur before a=20
certificate validity period has begun or while a certificate is =
suspended.  (Source for 11:=20
4.1 Basic Protocol)=20

[For the candidate protocol, indicate what if any, other invalidity =
reasons are reportable=20
by a conformant server.]

The OCTET STRING Reasons associated with the invalid state enables=20
responders to indicate reasons to requestors.  On the basis of prior=20
experience, it is anticipated that: 1) the full spectrum of such reasons =
may=20
be broad, owing to mission-specific needs; and yet 2) there might be a=20
core set worthy of standardization but that dialog has yet to occur.

12. The protocol MUST prevent replay attacks, and the replay prevention =
mechanism=20
employed by the protocol MUST NOT rely on synchronized clocks. (4.1 =
Basic Protocol)

[For the candidate protocol, describe the means by which conformant =
clients and servers=20
detect and reject replay attacks.]

RFC2560 governs the use of replay detection via the use of nonces.

13. The DPV request MUST allow the client to request that the server =
include in its=20
response additional information which will allow relying parties not =
trusting the DPV=20
server to be confident that the certificate validation has correctly =
been performed.=20

[=85]When the certificate is valid according to the validation policy, =
the server MUST,=20
upon request, include that information in the response.  However, the =
server MAY omit=20
that information when the certificate is invalid or when it cannot =
determine the validity. =20
(4.1 Basic Protocol)

[For the candidate protocol, specify the additional information that a =
conformant server=20
MUST be able to provide and indicate how the set of information to be =
returned is=20
determined, e.g., if it may vary depending on the client or other =
parameters.]

Requestors can ask responders to return one or more of: certification=20
path; revocation information; a time stamp; or policy identifier

The DPV/DPD requirements RFC does not assert a requirement for=20
normative specification of minimal server-side suypport for additional=20
information  It was assumed this is a deployment-specific issue.

Return of validation policy OID is enabled.

14. The DPV server MUST be able, upon request, copy a text field  =
provided by the client=20
into the DPV response. (4.1 Basic Protocol)

The token field in Parameters syntax is defined for this purpose.

15. The DPV response MUST be bound to the DPV request so that the client =
can be sure=20
that all the parameters from the request have been taken into =
consideration by the DPV=20
server to build the response.  This can be accomplished by including a =
one-way hash of=20
the request in the  response.

[For the candidate protocol, describe how this binding is effected.]

"If a value for requestExtensions is present in the DPV request  (thus=20
indicating the presence of requestor-specified parameters),  responders=20
shall perform a hash across this value using the SHA-1 algorithm AND=20
include this resulting value in the paramHash field."

In some environments it may be necessary to present only a DPV response =
to another=20
relying party without the corresponding request. In this case the =
response MUST be self=20
contained.  This  can be accomplished by repeating only the important =
components  from=20
the request in the response. (4.1 Basic Protocol)=20

"If the returnReq bit is set, responders SHALL return in reqContents =
field=20
the contents of the received DPVOptions . . ."

16. For the client to be confident that the certificate validation was =
handled by the=20
expected DPV server, the DPV response MUST be authenticated, unless an =
error is=20
reported (such as a badly formatted request or unknown validation =
policy).

[For the candidate protocol, specify the response message authentication =
mechanisms that=20
a conformant server MUST support, and those that a conformant client =
MUST support.=20
Note that clients might be required to support fewer mechanisms, or =
might be required to=20
support only one mechanism from a set, while a server might be required =
to support all of=20
the mechanisms in the set, e.g., as a means of ensuring interoperation.]

For the client to be able prove to a third party that trusts the same =
DPV server that the=20
certificate validation was handled correctly, the DPV response MUST be =
digitally signed,=20
unless an error is reported. The DPV server's certificate MUST =
authenticate the DPV=20
server. (4.1 Basic Protocol)

"In instances where it is important to authenticate the identity of a=20
responder prior to acceptance of its response, lower layer security=20
protocols could be used to establish the identity of the intended =
responder. =20
Note that authoritative DPV responses are required to be digitally =
signed. =20
Thus, to the extent the identity contained in the certificate used to =
validate=20
a response is an acceptable form of response authentication, this method =

may suffice."

17. The DPV server MAY require client authentication, therefore, the DPV =
request=20
MUST be able to be authenticated. (4.1 Basic Protocol)

[For the candidate protocol, describe the request message authentication =
mechanisms that=20
a conformant server MUST support, and those that a conformant client =
MUST support, to=20
ensure a minimal level of interoperability. Note that clients might be =
required to support=20
fewer mechanisms, or might be required to support only one mechanism =
from a set, while=20
a server might be required to support all of the mechanisms in the set, =
e.g., as a means of=20
ensuring interoperation.]

See above.

18. When the DPV request is authenticated, the client SHOULD be able to =
include a=20
client identifier in the request for the DPV server to copy into the =
response.  Mechanisms=20
for matching this identifier with the authenticated identity depends on =
local DPV server=20
conditions and/or the validation policy.  The DPV server MAY choose to =
blindly copy=20
the identifier, omit the identifier, or return an error response. (4.1 =
Basic Protocol)=20

[For the candidate protocol, describe provisions for confidentiality, if =
any.]

"If requestorName is included TBSRequest element, responders SHALL=20
include this value in the reqID field of  ExtendedOCSPResponse.  Where=20
client authentication is important to the responder's policy (e.g.=20
authorization to access the service), lower-layer protocol  MAY be used =
to=20
establish this authentication.  If used, responders SHOULD copy the=20
client-auth identity into the reqID field."

Topic 2: Relay and Redirection

19. Protocols designed to satisfy these requirements MAY include =
optional fields and/or=20
extensions to support relaying, re-direction or multicasting.  [=85]  If =
the protocol supports=20
such features, the protocol MUST include provisions for DPV clients and =
DPV servers=20
that do not support such features, allowing them to conform to the basic =
set of=20
requirements. (4.2. Relaying, Re-direction and Multicasting)

[For the candidate protocol, describe any relay, referral, or =
multicasting facilities required=20
of conformant server.]

No specific mechanisms are defined.  Current OCSP deployment practice=20
has shown that relaying and referral needs can be addressed.

20. When a server supports a relay mechanism, a mechanism to detect =
loops or repetition=20
MUST be provided. (4.2. Relaying, Re-direction and Multicasting)

See above re: 19.

21. When a protocol provides the capability for a DPV server to redirect =
a request to=20
another DPV server (that is, the protocol chooses to provide a referral =
mechanism), a=20
mechanism to provide information to be used for the re-direction SHOULD =
be supported.=20
If such re-direction information is sent back to clients, then the =
protocol MUST allow=20
conforming clients to ignore it. (4.2. Relaying, Re-direction and =
Multicasting)

[For the candidate protocol, describe what strategy is employed to deal =
with redirection=20
by a conformant server and what redirectionfeatures are mandated for a =
conformant=20
client.]

See above re: 19.

22. Optional parameters in the protocol request and/or response MAY be =
provide support=20
for relaying, re-direction or multicasting.  DPV clients that ignore any =
such optional=20
parameters MUST be able to use the DPV service.  DPV servers that ignore =
any such=20
optional parameters MUST still be able to offer the DPV service, =
although they might not=20
be able to overcome the limitations imposed by the network topology.  In =
this way,=20
protocol implementers do not need to understand the syntax or semantics =
of any such=20
optional parameters. (4.2. Relaying, Re-direction and Multicasting)=20

See above re: 19.

Topic 3: DPD Requirements

23. Clients MUST be able to specify whether they want, in addition to =
the certification=20
path, the revocation information associated with the path, for the =
end-entity certificate,=20
for the CA certificates, or for both. (5. Delegated Path Discovery =
Protocol)=20

[For the candidate protocol, specify what revocation status data types =
MUST be=20
supported by a conformant server.]

Requestors are able specify via the Flags field of ExtendedOCSPRequest=20
whether they wish to receive EE and/or CA revocation Information.  The=20
ExtendedOCSPResponse syntax and its DPD usage specification further=20
enables clients to request CRLs and/or OCSP.

24. If the DPD server does not support the client requested path =
discovery policy, the=20
DPD server MUST return an error. (5. Delegated Path Discovery Protocol)

Errors are reported via the RFC2560 envelope.

25. The DPD request MUST allow more elaborated path discovery policies =
to be=20
referenced. (5. Delegated Path Discovery Protocol)=20

[For the candidate protocol, specify the parameters for path discovery =
that a conformant=20
server MUST support, i.e., the minimum path discovery policy supported, =
and specify=20
what optional path discovery parameters a server SHOULD/MAY support.]

The ExtendedOCSPRequest syntax and its DPD usage specification enables =
this.

26. If the trust anchor is a self-signed certificate, that self-signed =
certificate MUST NOT=20
be included.  In addition, if requested, the revocation information =
associated with each=20
certificate in the path MUST also be returned. (5. Delegated Path =
Discovery Protocol)=20

[For the candidate protocol, specify the types of revocation status data =
that a conformant=20
server MUST support.]

"[If] the trust anchor is a self-signed certificate . . . that =
certificate SHALL=20
NOT be included in the path."

27. By default, the DPD server MUST return a single certification path =
for each end-
entity certificate in the DPD request. (5. Delegated Path Discovery =
Protocol)

"Responders aware of multiple candidate paths that satisfy requestor-
specified parameters (if any) SHALL include in their responses the =
lesser=20
of the number of qualified paths or the number of paths specified by the =

requestor in numPaths.  If the requestor did not specify numPaths then, =
by=20
default, the responder MUST return a single certification path for each=20
end-entity certificate in the DPD request."

28. Therefore, the DPD client MUST have a means of obtaining more than =
one=20
certification path for each end-entity certificate in the DPD request.  =
At the same time,=20
the mechanism for obtaining additional certification paths MUST NOT =
impose protocol=20
state on the DPD server. (5. Delegated Path Discovery Protocol)

[For the candidate protocol, provide a state machine description of DPD =
operation, to=20
demonstrate that this requirement is met.]

See above re: 27.

29. Path discovery MUST be performed according to the path discovery =
policy.  The=20
DPD response MUST indicate one of the following status alternatives:

   1.	one or more certification paths was found according to the  path =
discovery policy,=20
with all of the requested revocation information present.

   2.	one or more certification paths was found according to the  path =
discovery policy,=20
with a subset of the requested revocation information present.

   3.	one or more certification paths was found according to the path =
discovery policy,=20
with none of the requested revocation  information present.

   4.	no certification path was found according to the path  discovery =
policy.

   5.	path construction could not be performed due to an error.

(Source for 29: 5. Delegated Path Discovery Protocol)=20

"Responders SHALL develop a path or paths correspondent to a=20
requestor-specified path discovery policy when such is indicated in the=20
request."

"Requestors can derive these states from a DPD response as follows. =20
Errors are reported as OCSPResponseStatus (see [RFC2560]) in which=20
case no path data is present in the response.  A value of successful in=20
OCSPResponseStatus indicates the presence of pathInfo in=20
ExtendedOCSPResponse.  This value may be NULL, indicating that no=20
paths were discovered.  Requestors that did not request revInfo will not =

receive revInfo. Else each certificate in each path returned via the=20
pathInfo structure may or may not have revInfo associated with it. =20
Absence of revInfo for a given certificate in the pathInfo structure =
enables=20
requestor determination of the first three states noted above."

30.   For the client to be confident that all of the elements from the =
response originate=20
from the expected DPD server, an authenticated response MAY be required. =
 For=20
example, the server might sign  the response or data authentication =
might also be=20
achieved using a lower-layer security protocol. (5. Delegated Path =
Discovery  Protocol)

[For the candidate protocol, specify whether conformant servers MUST be =
capable of=20
generating authenticated responses, what authentication mechanisms they =
MUST support,=20
and what authentication mechanisms conformant clients MUST support. Note =
that clients=20
might be required to support fewer mechanisms, or might be required to =
support only one=20
mechanism from a set, while a server might be required to support all of =
the mechanisms=20
in the set, e.g., as a means of ensuring interoperation.]

RFC2560 enables responder signatures.

31. The DPD server MAY require client authentication, allowing the DPD =
request MUST=20
to be authenticated. (5. Delegated Path Discovery Protocol)

[For the candidate protocol, specify whether conformant servers MUST be =
capable of=20
authenticating requests, what authentication mechanisms they MUST =
support, and what=20
authentication mechanisms conformant clients MUST support. Note that =
clients might be=20
required to support fewer mechanisms, or might be required to support =
only one=20
mechanism from a set, while a server might be required to support all of =
the mechanisms=20
in the set, e.g., as a means of ensuring interoperation..]

"Where client authentication is important to the responder's policy =
(e.g.=20
authorization to access the service), a lower-layer protocol may be used =
to=20
establish this authentication.  If used, responders SHOULD copy the=20
client-auth identity into the reqID field of ExtendedOCSPResponse."

32. Using a separate request/response pair, the DPV or DPD client MUST =
be able to=20
obtain references for the default policy or for all  of the policies =
supported by the server.=20
(6. DPV and DPD Policy Query)

Policy Discovery Protocol (PDP) is not addressed.

33. In order to succeed, one valid certification path (none of the =
certificates in the path=20
are expired or revoked) MUST be found between an end-entity certificate =
and a trust=20
anchor and all constraints that apply to the certification path MUST be =
verified. (7.=20
Validation Policy)

34. The validation policy MUST specify the source of revocation =
information:

   1.	full CRLs (or full Authority Revocation Lists) have to be =
collected.

   2.	OCSP responses, using [OCSP], have to be collected.

   3.	delta CRLs and the relevant associated full CRLs (or full  =
Authority Revocation=20
Lists) are to be collected.

   4.	any available revocation information has to be collected.

   5.	no revocation information need be collected.

(Source for 34: 7.3. Revocation Requirements)

Policy Discovery Protocol (PDP) is not addressed.

35. The validation policy MUST specify the source of revocation =
information:

   - full CRLs (or full Authority Revocation Lists) have to be =
collected.

   - OCSP responses, using [OCSP], have to be collected.

   - delta CRLs and the relevant associated full CRLs (or full Authority =
Revocation Lists)=20
are to be collected.

   - any available revocation information has to be collected.

   - no revocation information need be collected.=20

(source for 35: 7. Validation Policy)

[For the candidate protocol, describe the path validation and path =
discovery policy=20
parameters that a conformant server MUST or  SHOULD support, e.g., trust =
anchor=20
names, keys, name  constraints and policy constraints for trust anchors, =
path depth limits,=20
key usage constraints, extended key usage constraints,  required/allowed =
revocation status=20
data types, etc.]  =20

Policy Discovery Protocol (PDP) is not addressed.


------=_NextPart_000_0000_01C2BBE0.C9A77AE0--



Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h0ELZC508190 for ietf-pkix-bks; Tue, 14 Jan 2003 13:35:12 -0800 (PST)
Received: from mta05-svc.ntlworld.com (mta05-svc.ntlworld.com [62.253.162.45]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h0ELZAo08186 for <[e-mail]>; Tue, 14 Jan 2003 13:35:10 -0800 (PST)
Received: from f67j40j ([213.106.136.127]) by mta05-svc.ntlworld.com (InterMail vM.4.01.03.27 201-229-121-127-20010626) with SMTP id <20030114213512.TLGF900.mta05-svc.ntlworld.com@f67j40j> for <[e-mail]>; Tue, 14 Jan 2003 21:35:12 +0000
From: "Marc Poulaud" <[e-mail]>
To: "Ietf-Pkix@Imc. Org" <[e-mail]>
Subject: Q. Automatic certificate selection for signing
Date: Tue, 14 Jan 2003 21:35:11 -0000
MIME-Version: 1.0
Message-ID: <[e-mail]>
Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_000A_01C2BC14.CE565F50"
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0)
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

This is a multi-part message in MIME format.

------=_NextPart_000_000A_01C2BC14.CE565F50
Content-Type: multipart/alternative;
	boundary="----=_NextPart_001_000B_01C2BC14.CE596C90"


------=_NextPart_001_000B_01C2BC14.CE596C90
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit

A question for those involved with signing applications (or anybody else
with 2 cents)...

I'm interested to understand what might be some of the key issues/options
for a signing application that needs to select the right certificate for
signing a piece of data. I see two main options. One is that there is a
configuration option that allows a particular user to be associated with a
particular certificate (a la Outlook - I want to use this certificate (and
associated key) to sign my outgoing emails). Another is that, during the
signing operation, some how select the right certificate based on a value
coded in a certificate.

On the one hand I think the latter would be a smart move if it where
possible to use some standard (and therefore interoperable) way of doing
this (unlike my initial thought of having an 'application' specific value
in an OU field) or perhaps a more suitable field within a certificate
(perhaps a policy qualifier?).

Anybody have experience of such matters?

Marc.

------=_NextPart_001_000B_01C2BC14.CE596C90
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 http-equiv=3DContent-Type content=3D"text/html; =
charset=3Diso-8859-1">
<META content=3D"MSHTML 6.00.2800.1106" name=3DGENERATOR></HEAD>
<BODY>
<DIV><FONT face=3DArial size=3D2><SPAN class=3D346562121-14012003>A =
question for those=20
involved with signing applications (or anybody else with 2=20
cents)...</SPAN></FONT></DIV>
<DIV><FONT face=3DArial size=3D2><SPAN=20
class=3D346562121-14012003></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2><SPAN class=3D346562121-14012003>I'm =
interested to=20
understand what might be some of the key issues/options for a signing=20
application that needs to select the right certificate for signing a =
piece of=20
data. I see two main options. One is that there is a =
configuration&nbsp;option=20
that allows a particular user to be associated with a particular =
certificate (a=20
la Outlook - I want to use this certificate (and associated key) to sign =
my=20
outgoing emails). Another is that, during the signing operation, some =
how select=20
the right certificate based on a value coded in</SPAN></FONT><FONT =
face=3DArial=20
size=3D2><SPAN class=3D346562121-14012003>&nbsp;a =
certificate.</SPAN></FONT></DIV>
<DIV><FONT face=3DArial size=3D2><SPAN=20
class=3D346562121-14012003></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2><SPAN class=3D346562121-14012003>On the =
one hand I=20
think the latter would be a smart move if it where possible to use some =
standard=20
(and therefore interoperable) way of doing this (unlike my initial =
thought of=20
having&nbsp;an 'application' specific value in an OU field) or perhaps a =
more=20
suitable field within a certificate (perhaps a policy=20
qualifier?).</SPAN></FONT></DIV>
<DIV><FONT face=3DArial size=3D2><SPAN=20
class=3D346562121-14012003></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2><SPAN =
class=3D346562121-14012003>Anybody have=20
experience of such matters?</SPAN></FONT></DIV>
<DIV><FONT face=3DArial size=3D2><SPAN=20
class=3D346562121-14012003></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2><SPAN=20
class=3D346562121-14012003>Marc.</SPAN></FONT></DIV></BODY></HTML>

------=_NextPart_001_000B_01C2BC14.CE596C90--

------=_NextPart_000_000A_01C2BC14.CE565F50
Content-Type: application/x-pkcs7-signature;
	name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment;
	filename="smime.p7s"

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIKITCCAj0w
ggGmAhEAzbp/VvDf5LxU/iKss3KqVTANBgkqhkiG9w0BAQIFADBfMQswCQYDVQQGEwJVUzEXMBUG
A1UEChMOVmVyaVNpZ24sIEluYy4xNzA1BgNVBAsTLkNsYXNzIDEgUHVibGljIFByaW1hcnkgQ2Vy
dGlmaWNhdGlvbiBBdXRob3JpdHkwHhcNOTYwMTI5MDAwMDAwWhcNMjgwODAxMjM1OTU5WjBfMQsw
CQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xNzA1BgNVBAsTLkNsYXNzIDEgUHVi
bGljIFByaW1hcnkgQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkwgZ8wDQYJKoZIhvcNAQEBBQADgY0A
MIGJAoGBAOUZv22jVmEtmUhx9mfeuY3rt56GgAqRDvo4Ja9GiILlc6igmyRdDR/MZW4MsNBWhBiH
mgabEKFz37RYOWtuwfYV1aioP6oSBo0xrH+wNNePNGeICc0UEeJORVZpH3gCgNrcR5EpuzbJY1zF
4Ncth3uhtzKwezC6Ki8xqu6jZ9rbAgMBAAEwDQYJKoZIhvcNAQECBQADgYEATD+4i8Zo3+5DMw5d
6abLB4RNejP/khv0Nq3YlSI2aBFsfELM85wuxAc/FLAPT/+Qknb54rxK6Y/NoIAK98Up8YIiXbix
3YEjo3slFUYweRb46gVLlH8dwhzI47f0EEA8E8NfH1PoSOSGtHuhNbB7Jbq4046rPzidADQAmPPR
cZQwggNiMIICy6ADAgECAhAL2gsXwT+JjqsJdHq0zi4zMA0GCSqGSIb3DQEBAgUAMF8xCzAJBgNV
BAYTAlVTMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjE3MDUGA1UECxMuQ2xhc3MgMSBQdWJsaWMg
UHJpbWFyeSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTAeFw05ODA1MTIwMDAwMDBaFw0wODA1MTIy
MzU5NTlaMIHMMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1
c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNv
cnAuIEJ5IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xhc3MgMSBDQSBJ
bmRpdmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkMIGfMA0GCSqGSIb3DQEB
AQUAA4GNADCBiQKBgQC7WkSKBBa7Vf0DeootlE8VeDa4DUqyb5xUv7zodyqdufBou5XZMUFweoFL
uUgTVi3HCOGEQqvAopKrRFyqQvCCDgLpL/vCO7u+yScKXbawNkIztW5UiE+HSr8Z2vkV6A+Hthzj
zMaajn9qJJLj/OBluqexfu/J2zdqyErICQbkmQIDAQABo4GwMIGtMA8GA1UdEwQIMAYBAf8CAQAw
RwYDVR0gBEAwPjA8BgtghkgBhvhFAQcBATAtMCsGCCsGAQUFBwIBFh93d3cudmVyaXNpZ24uY29t
L3JlcG9zaXRvcnkvUlBBMDEGA1UdHwQqMCgwJqAkoCKGIGh0dHA6Ly9jcmwudmVyaXNpZ24uY29t
L3BjYTEuY3JsMAsGA1UdDwQEAwIBBjARBglghkgBhvhCAQEEBAMCAQYwDQYJKoZIhvcNAQECBQAD
gYEAAn2eb0VLOKC43ulTZCG85Ewrjx7+kkCs2Ao5aqEyISwHm6tZ/tJiGn1VOLA3c9z0B2ZjYr3h
U3BSh+eo2FLpWy2q4d7PrDFU1IsZyNgjqO8EKzJ9LBgcyHyJqC538kTRZQpNdLXu0xuSc3QuiTs1
E3LnQDGa07LEq+dWvovj+xUwggR2MIID36ADAgECAhB/l4yg+FrgmGLkay+Z3cRwMA0GCSqGSIb3
DQEBBAUAMIHMMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1
c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNv
cnAuIEJ5IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xhc3MgMSBDQSBJ
bmRpdmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkMB4XDTAyMTAwNzAwMDAw
MFoXDTAzMTAwNzIzNTk1OVowggEaMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMW
VmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0
b3J5L1JQQSBJbmNvcnAuIGJ5IFJlZi4sTElBQi5MVEQoYyk5ODEeMBwGA1UECxMVUGVyc29uYSBO
b3QgVmFsaWRhdGVkMTQwMgYDVQQLEytEaWdpdGFsIElEIENsYXNzIDEgLSBNaWNyb3NvZnQgRnVs
bCBTZXJ2aWNlMRUwEwYDVQQDFAxNYXJjIFBvdWxhdWQxKTAnBgkqhkiG9w0BCQEWGm1hcmMucG91
bGF1ZEBpLXNvbHZlLmNvLnVrMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDfd3CCaom3tU0P
mdCz0ggSdD8UNJMSVDPou1CJjsLvYpwUySsSQgUdYdFjvQmheBDL2z0T3dX1mvce5WJrDg5fcWQG
aUmQbubJ0qxdK5uT4IkNJx9s1PPDfOEj4PdJExyyG0Cbsvwo8Wyq+xnRlCcMzwm4D/XNnXqkrEZw
MifX+wIDAQABo4IBBjCCAQIwCQYDVR0TBAIwADCBrAYDVR0gBIGkMIGhMIGeBgtghkgBhvhFAQcB
ATCBjjAoBggrBgEFBQcCARYcaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL0NQUzBiBggrBgEFBQcC
AjBWMBUWDlZlcmlTaWduLCBJbmMuMAMCAQEaPVZlcmlTaWduJ3MgQ1BTIGluY29ycC4gYnkgcmVm
ZXJlbmNlIGxpYWIuIGx0ZC4gKGMpOTcgVmVyaVNpZ24wEQYJYIZIAYb4QgEBBAQDAgeAMDMGA1Ud
HwQsMCowKKAmoCSGImh0dHA6Ly9jcmwudmVyaXNpZ24uY29tL2NsYXNzMS5jcmwwDQYJKoZIhvcN
AQEEBQADgYEAh/j3ynKibKwqRZA4Y3KsDwboqp78AIi04ATWtK0MSq+qL2FIu7HORZrN9eJVwqkm
3lr4tNU/ld7bCqnd9zHO4FRyg17pDVwZ4/7Z3UR+wW6WLj2FXn+QPRPWuyeIpOz+LxPhn4HaBIS6
qaO6+glnQl0IX6axcAhLebO/J/hNIQAxggNWMIIDUgIBATCB4TCBzDEXMBUGA1UEChMOVmVyaVNp
Z24sIEluYy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0IE5ldHdvcmsxRjBEBgNVBAsTPXd3dy52
ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEgSW5jb3JwLiBCeSBSZWYuLExJQUIuTFREKGMpOTgx
SDBGBgNVBAMTP1ZlcmlTaWduIENsYXNzIDEgQ0EgSW5kaXZpZHVhbCBTdWJzY3JpYmVyLVBlcnNv
bmEgTm90IFZhbGlkYXRlZAIQf5eMoPha4Jhi5Gsvmd3EcDAJBgUrDgMCGgUAoIIByjAYBgkqhkiG
9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0wMzAxMTQyMTM1MDZaMCMGCSqGSIb3
DQEJBDEWBBQBHzMyZ6vuZL5vHvGYB0N7ivJ4TzB2BgkqhkiG9w0BCQ8xaTBnMAoGCCqGSIb3DQMH
MA4GCCqGSIb3DQMCAgIAgDAHBgUrDgMCBzAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDAHBgUrDgMC
GjAHBgUrDgMCGjAKBggqhkiG9w0CBTAKBggqhkiG9w0CBTCB8gYJKwYBBAGCNxAEMYHkMIHhMIHM
MRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29y
azFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIEJ5IFJl
Zi4sTElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xhc3MgMSBDQSBJbmRpdmlkdWFs
IFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkAhB/l4yg+FrgmGLkay+Z3cRwMA0GCSqG
SIb3DQEBAQUABIGA1+iycn2HFdjGjNiPiYAv2CdmcnLLI8tVleQAOgmZHDnYd3TujBypds6Rnyd/
YwMf4JLsBC7QLHrcajNZ7lyJFz95iwf7T3ESl9r5gHwNB+mzOxUVjQkj+SM3256H2kEWeWle10vJ
C4W38Iz0tF8OBHm35NNfL/Zxm6YdUq+C1tsAAAAAAAA=

------=_NextPart_000_000A_01C2BC14.CE565F50--



Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h0EKwhR07166 for ietf-pkix-bks; Tue, 14 Jan 2003 12:58:43 -0800 (PST)
Received: from woodstock.binhost.com (woodstock.binhost.com [207.228.252.5]) by above.proper.com (8.11.6/8.11.3) with SMTP id h0EKwgo07162 for <[e-mail]>; Tue, 14 Jan 2003 12:58:42 -0800 (PST)
Received: (qmail 809 invoked from network); 14 Jan 2003 20:58:06 -0000
Received: from unknown (HELO Russ-Laptop.vigilsec.com) (65.199.255.70) by woodstock.binhost.com with SMTP; 14 Jan 2003 20:58:06 -0000
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9
Date: Tue, 14 Jan 2003 15:37:34 -0500
To: Timothy Hahn <[e-mail]>, [e-mail]
From: Russ Housley <[e-mail]>
Subject: Re: LDAP PKI Schema (was Re: No-op LDAP ;binary option)
In-Reply-To: <OF72F48BC4.883E39EB-ON85256CAD.00466F4D-85256CAD.00476A03@ us.ibm.com>
References: <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Tim:

I do not agree.  These are two cases associated with the same goal.  The 
client wants to locate the appropriate certificate.  The subject may have 
one, two, or more certificates, but the client does not know this until it 
starts looking.

Russ


At 07:59 AM 1/13/2003 -0500, Timothy Hahn wrote:
>Russ,
>
>I agree with you in not wanting two standards for accomplishing the same 
>goal.
>
>But I still assert that the (currently) two proposed models do not have 
>exactly the same goals, hence a possibility that the different goals 
>require different solutions.
>
>Option 1: single entry, containing possibly multiple userCertificate 
>attribute values
>Goals: (primary) support existing deployments which assume this model, 
>(secondary) support attribute-within-certificate searching, (secondary) 
>support single userCertificate retrieval.
>
>Option 2: multiple entry, containing single userCertificate attribute 
>value per entry, entries related by sub-tree layout
>Goals: (primary) support attribute-within-certificate searching with 
>existing and widely available directory technologies, (primary) support 
>single userCertificate retrieval, (non-goal) support existing deployments 
>which assume a single entry model.
>
>I accept the desire to not have this situation, but I also believe it is 
>going to occur - so why wouldn't we try and infuse at least some order 
>into this situation?
>
>Regards,
>Tim Hahn
>
>Internet: [e-mail]
>Internal: Timothy Hahn/Durham/IBM@IBMUS
>phone: [phone]     tie-line: 8/687.1565
>fax: [phone]



Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h0EG1jd26034 for ietf-pkix-bks; Tue, 14 Jan 2003 08:01:45 -0800 (PST)
Received: from SOTTMXS01.entrust.com (mail.entrust.com [216.191.251.35]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h0EG1io26030 for <[e-mail]>; Tue, 14 Jan 2003 08:01:44 -0800 (PST)
Received: by sottmxs01.entrust.com with Internet Mail Service (5.5.2656.59) id <CZ533AVP>; Tue, 14 Jan 2003 11:01:39 -0500
Message-ID: <[e-mail]>
From: Sharon Boeyen <[e-mail]>
To: "'Russ Housley'" <[e-mail]>, Timothy Hahn <[e-mail]>
Cc: [e-mail]
Subject: RE: LDAP PKI Schema (was Re: No-op LDAP ;binary option)
Date: Tue, 14 Jan 2003 11:01:38 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2656.59)
Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C2BBE6.389E3600"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

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

------_=_NextPart_001_01C2BBE6.389E3600
Content-Type: text/plain

Russ I want to add my support to your comment about interoperability. In
particular
I think we need to be careful about anything that would require
changes/additions to 
clients. Existing deployed PKIX clients will be around for quite some time
and need 
to be accomodated in anticipated environments. The only way to do that with
this proposal 
would be to require that all servers follow the traditional userCertificate
schema and 
some could, in addition to that, add these child entries for enhanced
clients. Even that 
approach would require some way for the enhanced client to know which
servers support the 
enhancements. otherwise they'd be sending a lot of requests that wouldn't
succeed and they'd 
need to re-request the old way. Its also not fine for the PKI application to
say that clients 
and servers will figure out which ones they are compatible with and work
with those alone.  
That model is limited to closed environments and creates isolated islands of
interoperability. 
PKIX requires a mechanism that enables clients to be able to access the data
they need to build
and validate cert paths and separating servers into some that follow a
compatible schema and others 
that don't would significantly hinder that ability. 

A few years ago I remember participating in discussions about the
crossCertificatePairs attribute and 
how complex that one is. It would be wonderful to replace that single
overloaded attribute with at least
two separate attributes (one for certs issued "to" this CA and a separate
one for certs issued "by" this 
CA). While many of those in that discussion, myself included, agreed that
this would be a great thing to 
do we decided NOT to try to make that change for exactly this same reason.
Existing clients need to be 
accomodated and making such a change can only be done gracefully by
requiring that all CAs publish the old
way and some may also publish the new way. It then becomes very difficult to
determine a point in time 
at which you can turn off the old schema and rely solely on the new one. 

Sharon


-----Original Message-----
From: Russ Housley [mailto:[e-mail]]
Sent: Friday, January 10, 2003 2:31 PM
To: Timothy Hahn
Cc: [e-mail]
Subject: Re: LDAP PKI Schema (was Re: No-op LDAP ;binary option)



Tim:

In the PKIX WG, we have learned a hard lesson about letting two standard 
that accomplish the same goal progress.  The "let the market decide" has 
lead to camps that implement the alternatives, but do not interoperate with 
each other, even if they know why they do not interoperate.  I do not want 
to repeat this mistake.

Russ


At 08:40 AM 1/7/2003 -0500, Timothy Hahn wrote:



>Russ,
>
>Great question.  Simply - it gives the "client" the opportunity to
>establish whether or not it can or cannot support retrieval of the
>information from that data source (directory sub-tree).  Client and server
>implementations choose which protocols and data models they're going to
>"support" all the time.  As long as both support the same model(s), then
>they interoperate.  My proposal is that we define one way to identify which
>data model(s) is(are) employed, so that servers and clients can determine
>whether they are capable of supporting the formats.  If they are not
>capable, they can gracefully fail.
>
>The client can be made as "fat" or as "lean" as the implementer wants,
>because the implementer can decide which formats to support.  If the
>implementer decides to support one while another part of the industry tends
>to support another - well, then that particular implementation will get
>"fatter" because it will wind up supporting both.
>
>My premise is that there is not a single data model that "fits" for ALL
>applications/deployments.  And because of that, multiple data models can
>and will (in real-world scenarios) exist.  So why not accept this, define a
>(singular) way of identifying which model is used, and move on.  At least
>in this way, if a particular implementation/application has a need to store
>things in a different way, it can, and we can still hope for
>interoperability through IETF documents.
>
>Regards,
>Tim Hahn
>
>Internet: [e-mail]
>Internal: Timothy Hahn/Durham/IBM@IBMUS
>phone: [phone]     tie-line: 8/687.1565
>fax: [phone]
>
>|+-----------------------+------------------------------------------------|
>||   Russ Housley        |                                                |
>||   <[e-mail]|           To:        Timothy                   |
>||   m>                  |   Hahn/Durham/IBM@IBMUS                        |
>||                       |           cc:        [e-mail]         |
>||   01/06/2003 04:28 PM |           Subject:        Re: LDAP PKI Schema  |
>||                       |   (was Re: No-op LDAP ;binary option)          |
>||                       |                                                |
>||                       |                                                |
>|+-----------------------+------------------------------------------------|
>
>
>
>
>
>Tim:
>
>I do not understand how a client is better off with multiple ways to put
>the same information in the Directory.  Doesn't this approach just make the
>client fat?  It seem to me that the client would have to support all of the
>possible ways that the information could be stored.  It cannot know which
>method it will encounter until it starts looking at data in the Directory.
>
>Russ
>
>
>At 03:14 PM 1/6/2003 -0500, Timothy Hahn wrote:
> >Hello all,
> >
> >After listening to the different view-points on this topic, it seems to
me
> >that there are multiple valid approaches.  These approaches include, but
> >are not limited to:
> >   - leveraging the general solution of component-matching
> >   - new schema to support application-managed componentization of
> >information to make things searchable
> >as well as others (additional matching rules, for example).
> >
> >It occurs to me that perhaps we have a situation where "one size does not
> >fit all".  Why not accept this and define a way for applications to
> >determine which (of possibly multiple) format(s) has been used to place
>the
> >information into the directory?  We could define some small bit of schema
> >which indicates the way in which the certificate information is placed
>into
> >the directory, then different applications could query this and
determine:
> >   - whether they can use the data at all
> >   - if they can use the data, how they can best use it (if there are,
for
> >example, multiple mechanisms employed).
> >
> >Just a thought to get us through this discussion.
> >
> >Regards,
> >Tim Hahn
>
>

------_=_NextPart_001_01C2BBE6.389E3600
Content-Type: text/html
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3DUS-ASCII">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
5.5.2653.12">
<TITLE>RE: LDAP PKI Schema (was Re: No-op LDAP ;binary option)</TITLE>
</HEAD>
<BODY>

<P><FONT SIZE=3D2>Russ I want to add my support to your comment about =
interoperability. In particular</FONT>
<BR><FONT SIZE=3D2>I think we need to be careful about anything that =
would require changes/additions to </FONT>
<BR><FONT SIZE=3D2>clients. Existing deployed PKIX clients will be =
around for quite some time and need </FONT>
<BR><FONT SIZE=3D2>to be accomodated in anticipated environments. The =
only way to do that with this proposal </FONT>
<BR><FONT SIZE=3D2>would be to require that all servers follow the =
traditional userCertificate schema and </FONT>
<BR><FONT SIZE=3D2>some could, in addition to that, add these child =
entries for enhanced clients. Even that </FONT>
<BR><FONT SIZE=3D2>approach would require some way for the enhanced =
client to know which servers support the </FONT>
<BR><FONT SIZE=3D2>enhancements. otherwise they'd be sending a lot of =
requests that wouldn't succeed and they'd </FONT>
<BR><FONT SIZE=3D2>need to re-request the old way. Its also not fine =
for the PKI application to say that clients </FONT>
<BR><FONT SIZE=3D2>and servers will figure out which ones they are =
compatible with and work with those alone.&nbsp; </FONT>
<BR><FONT SIZE=3D2>That model is limited to closed environments and =
creates isolated islands of interoperability. </FONT>
<BR><FONT SIZE=3D2>PKIX requires a mechanism that enables clients to be =
able to access the data they need to build</FONT>
<BR><FONT SIZE=3D2>and validate cert paths and separating servers into =
some that follow a compatible schema and others </FONT>
<BR><FONT SIZE=3D2>that don't would significantly hinder that ability. =
</FONT>
</P>

<P><FONT SIZE=3D2>A few years ago I remember participating in =
discussions about the crossCertificatePairs attribute and </FONT>
<BR><FONT SIZE=3D2>how complex that one is. It would be wonderful to =
replace that single overloaded attribute with at least</FONT>
<BR><FONT SIZE=3D2>two separate attributes (one for certs issued =
&quot;to&quot; this CA and a separate one for certs issued =
&quot;by&quot; this </FONT>
<BR><FONT SIZE=3D2>CA). While many of those in that discussion, myself =
included, agreed that this would be a great thing to </FONT>
<BR><FONT SIZE=3D2>do we decided NOT to try to make that change for =
exactly this same reason. Existing clients need to be </FONT>
<BR><FONT SIZE=3D2>accomodated and making such a change can only be =
done gracefully by requiring that all CAs publish the old</FONT>
<BR><FONT SIZE=3D2>way and some may also publish the new way. It then =
becomes very difficult to determine a point in time </FONT>
<BR><FONT SIZE=3D2>at which you can turn off the old schema and rely =
solely on the new one. </FONT>
</P>

<P><FONT SIZE=3D2>Sharon</FONT>
</P>
<BR>

<P><FONT SIZE=3D2>-----Original Message-----</FONT>
<BR><FONT SIZE=3D2>From: Russ Housley [<A =
HREF=3D"mailto:[e-mail]">mailto:[e-mail]</A>]</F=
ONT>
<BR><FONT SIZE=3D2>Sent: Friday, January 10, 2003 2:31 PM</FONT>
<BR><FONT SIZE=3D2>To: Timothy Hahn</FONT>
<BR><FONT SIZE=3D2>Cc: [e-mail]</FONT>
<BR><FONT SIZE=3D2>Subject: Re: LDAP PKI Schema (was Re: No-op LDAP =
;binary option)</FONT>
</P>
<BR>
<BR>

<P><FONT SIZE=3D2>Tim:</FONT>
</P>

<P><FONT SIZE=3D2>In the PKIX WG, we have learned a hard lesson about =
letting two standard </FONT>
<BR><FONT SIZE=3D2>that accomplish the same goal progress.&nbsp; The =
&quot;let the market decide&quot; has </FONT>
<BR><FONT SIZE=3D2>lead to camps that implement the alternatives, but =
do not interoperate with </FONT>
<BR><FONT SIZE=3D2>each other, even if they know why they do not =
interoperate.&nbsp; I do not want </FONT>
<BR><FONT SIZE=3D2>to repeat this mistake.</FONT>
</P>

<P><FONT SIZE=3D2>Russ</FONT>
</P>
<BR>

<P><FONT SIZE=3D2>At 08:40 AM 1/7/2003 -0500, Timothy Hahn =
wrote:</FONT>
</P>
<BR>
<BR>

<P><FONT SIZE=3D2>&gt;Russ,</FONT>
<BR><FONT SIZE=3D2>&gt;</FONT>
<BR><FONT SIZE=3D2>&gt;Great question.&nbsp; Simply - it gives the =
&quot;client&quot; the opportunity to</FONT>
<BR><FONT SIZE=3D2>&gt;establish whether or not it can or cannot =
support retrieval of the</FONT>
<BR><FONT SIZE=3D2>&gt;information from that data source (directory =
sub-tree).&nbsp; Client and server</FONT>
<BR><FONT SIZE=3D2>&gt;implementations choose which protocols and data =
models they're going to</FONT>
<BR><FONT SIZE=3D2>&gt;&quot;support&quot; all the time.&nbsp; As long =
as both support the same model(s), then</FONT>
<BR><FONT SIZE=3D2>&gt;they interoperate.&nbsp; My proposal is that we =
define one way to identify which</FONT>
<BR><FONT SIZE=3D2>&gt;data model(s) is(are) employed, so that servers =
and clients can determine</FONT>
<BR><FONT SIZE=3D2>&gt;whether they are capable of supporting the =
formats.&nbsp; If they are not</FONT>
<BR><FONT SIZE=3D2>&gt;capable, they can gracefully fail.</FONT>
<BR><FONT SIZE=3D2>&gt;</FONT>
<BR><FONT SIZE=3D2>&gt;The client can be made as &quot;fat&quot; or as =
&quot;lean&quot; as the implementer wants,</FONT>
<BR><FONT SIZE=3D2>&gt;because the implementer can decide which formats =
to support.&nbsp; If the</FONT>
<BR><FONT SIZE=3D2>&gt;implementer decides to support one while another =
part of the industry tends</FONT>
<BR><FONT SIZE=3D2>&gt;to support another - well, then that particular =
implementation will get</FONT>
<BR><FONT SIZE=3D2>&gt;&quot;fatter&quot; because it will wind up =
supporting both.</FONT>
<BR><FONT SIZE=3D2>&gt;</FONT>
<BR><FONT SIZE=3D2>&gt;My premise is that there is not a single data =
model that &quot;fits&quot; for ALL</FONT>
<BR><FONT SIZE=3D2>&gt;applications/deployments.&nbsp; And because of =
that, multiple data models can</FONT>
<BR><FONT SIZE=3D2>&gt;and will (in real-world scenarios) exist.&nbsp; =
So why not accept this, define a</FONT>
<BR><FONT SIZE=3D2>&gt;(singular) way of identifying which model is =
used, and move on.&nbsp; At least</FONT>
<BR><FONT SIZE=3D2>&gt;in this way, if a particular =
implementation/application has a need to store</FONT>
<BR><FONT SIZE=3D2>&gt;things in a different way, it can, and we can =
still hope for</FONT>
<BR><FONT SIZE=3D2>&gt;interoperability through IETF documents.</FONT>
<BR><FONT SIZE=3D2>&gt;</FONT>
<BR><FONT SIZE=3D2>&gt;Regards,</FONT>
<BR><FONT SIZE=3D2>&gt;Tim Hahn</FONT>
<BR><FONT SIZE=3D2>&gt;</FONT>
<BR><FONT SIZE=3D2>&gt;Internet: [e-mail]</FONT>
<BR><FONT SIZE=3D2>&gt;Internal: Timothy Hahn/Durham/IBM@IBMUS</FONT>
<BR><FONT SIZE=3D2>&gt;phone: [phone]&nbsp;&nbsp;&nbsp;&nbsp; =
tie-line: 8/687.1565</FONT>
<BR><FONT SIZE=3D2>&gt;fax: [phone]</FONT>
<BR><FONT SIZE=3D2>&gt;</FONT>
<BR><FONT =
SIZE=3D2>&gt;|+-----------------------+---------------------------------=
---------------|</FONT>
<BR><FONT SIZE=3D2>&gt;||&nbsp;&nbsp; Russ =
Housley&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
|</FONT>
<BR><FONT SIZE=3D2>&gt;||&nbsp;&nbsp; =
&lt;[e-mail]|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
&nbsp;&nbsp; To:&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
Timothy&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; |</FONT>
<BR><FONT SIZE=3D2>&gt;||&nbsp;&nbsp; =
m&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&=
nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; |&nbsp;&nbsp; =
Hahn/Durham/IBM@IBMUS&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp; |</FONT>
<BR><FONT SIZE=3D2>&gt;||&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;&nbsp;&nbsp; =
|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
cc:&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
[e-mail]&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
|</FONT>
<BR><FONT SIZE=3D2>&gt;||&nbsp;&nbsp; 01/06/2003 04:28 PM =
|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
Subject:&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Re: LDAP PKI =
Schema&nbsp; |</FONT>
<BR><FONT =
SIZE=3D2>&gt;||&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp; |&nbsp;&nbsp; (was Re: No-op LDAP ;binary =
option)&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; |</FONT>
<BR><FONT =
SIZE=3D2>&gt;||&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp; =
|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
|</FONT>
<BR><FONT =
SIZE=3D2>&gt;||&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp; =
|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
|</FONT>
<BR><FONT =
SIZE=3D2>&gt;|+-----------------------+---------------------------------=
---------------|</FONT>
<BR><FONT SIZE=3D2>&gt;</FONT>
<BR><FONT SIZE=3D2>&gt;</FONT>
<BR><FONT SIZE=3D2>&gt;</FONT>
<BR><FONT SIZE=3D2>&gt;</FONT>
<BR><FONT SIZE=3D2>&gt;</FONT>
<BR><FONT SIZE=3D2>&gt;Tim:</FONT>
<BR><FONT SIZE=3D2>&gt;</FONT>
<BR><FONT SIZE=3D2>&gt;I do not understand how a client is better off =
with multiple ways to put</FONT>
<BR><FONT SIZE=3D2>&gt;the same information in the Directory.&nbsp; =
Doesn't this approach just make the</FONT>
<BR><FONT SIZE=3D2>&gt;client fat?&nbsp; It seem to me that the client =
would have to support all of the</FONT>
<BR><FONT SIZE=3D2>&gt;possible ways that the information could be =
stored.&nbsp; It cannot know which</FONT>
<BR><FONT SIZE=3D2>&gt;method it will encounter until it starts looking =
at data in the Directory.</FONT>
<BR><FONT SIZE=3D2>&gt;</FONT>
<BR><FONT SIZE=3D2>&gt;Russ</FONT>
<BR><FONT SIZE=3D2>&gt;</FONT>
<BR><FONT SIZE=3D2>&gt;</FONT>
<BR><FONT SIZE=3D2>&gt;At 03:14 PM 1/6/2003 -0500, Timothy Hahn =
wrote:</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;Hello all,</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;After listening to the different =
view-points on this topic, it seems to me</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;that there are multiple valid =
approaches.&nbsp; These approaches include, but</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;are not limited to:</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;&nbsp;&nbsp; - leveraging the general =
solution of component-matching</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;&nbsp;&nbsp; - new schema to support =
application-managed componentization of</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;information to make things =
searchable</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;as well as others (additional matching =
rules, for example).</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;It occurs to me that perhaps we have a =
situation where &quot;one size does not</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;fit all&quot;.&nbsp; Why not accept this =
and define a way for applications to</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;determine which (of possibly multiple) =
format(s) has been used to place</FONT>
<BR><FONT SIZE=3D2>&gt;the</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;information into the directory?&nbsp; We =
could define some small bit of schema</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;which indicates the way in which the =
certificate information is placed</FONT>
<BR><FONT SIZE=3D2>&gt;into</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;the directory, then different applications =
could query this and determine:</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;&nbsp;&nbsp; - whether they can use the =
data at all</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;&nbsp;&nbsp; - if they can use the data, =
how they can best use it (if there are, for</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;example, multiple mechanisms =
employed).</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;Just a thought to get us through this =
discussion.</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;Regards,</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;Tim Hahn</FONT>
<BR><FONT SIZE=3D2>&gt;</FONT>
<BR><FONT SIZE=3D2>&gt;</FONT>
</P>

</BODY>
</HTML>
------_=_NextPart_001_01C2BBE6.389E3600--


Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h0EFWJb24386 for ietf-pkix-bks; Tue, 14 Jan 2003 07:32:19 -0800 (PST)
Received: from nic.lp.se (nic.lp.se [212.247.5.91]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h0EFWGo24381 for <[e-mail]>; Tue, 14 Jan 2003 07:32:17 -0800 (PST)
Received: from localhost (217.215.93.181) by nic.lp.se (MX V5.3 VnHj) with ESMTP; Tue, 14 Jan 2003 16:30:10 +0100
Date: Tue, 14 Jan 2003 16:28:00 +0100 (CET)
Message-ID: <[e-mail]>
To: [e-mail]
CC: [e-mail], [e-mail]
Subject: Re: RFC3039/X.500 naming question
From: Richard Levitte - VMS Whacker <[e-mail]>
In-Reply-To: <012901c2bbb6$11d292d0$0500a8c0@arport>
References: <[e-mail]> <012901c2bbb6$11d292d0$0500a8c0@arport>
X-URL: http://www.lp.se/
X-Waved: dead chicken, GNU emacs 21.2.2, Mew version 3.1
X-Mew: See http://www.mew.org/
X-Mailer: Mew version 3.1 on Emacs 21.2 / Mule 5.0 (SAKAKI)
MIME-Version: 1.0
Content-Type: Text/Plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

In message <012901c2bbb6$11d292d0$0500a8c0@arport> on Tue, 14 Jan 2003 11:16:54 +0100, "Anders Rundgren" <[e-mail]> said:

anders.rundgren> >> A colleague of mine claims that the DN
anders.rundgren> >>
anders.rundgren> >>    "CN=Marion Anderson, serialNumber=nnnnnnnnnnnn, C=SE"
anders.rundgren> >>
anders.rundgren> >> denotes a Swedish citizen according to ISO/ITU standards.
anders.rundgren> 
anders.rundgren> >What ISO/ITU Standard would that be?
anders.rundgren> 
anders.rundgren> The ones that are the foundation for X.500, that's all I know.

I think your colleague should say exactly what he or she means, or we
can discuss endlessly and in loops...  You can't really throw
something like "the ISO/ITU Standards" and assume that everyone knows
what you're talking about.

I'm assuming that what's meant is X.520, which mentions a number of
attribute types.  All those used in the DN above exist according to
that document.

Note that the ISO/ITU standards (at least those I have a copy of) say
nothing about swedish citizen, so the fact that swedish citizen get a
DN like the above is outside the scope of ISO/ITU and has been
documented somewhere else.  So the question "What ISO/ITU Standard
would that be?" is pretty well founded.

anders.rundgren> >My guess is that your colleague is wrong. There is
anders.rundgren> >at least nothing in RFC 3280 or RFC 3039 that
anders.rundgren> >support that statement.
anders.rundgren> 
anders.rundgren> So I have understood it as well.  But he claims that
anders.rundgren> you must FIRST read the ISO/ITU-stuff which is
anders.rundgren> NORMATIVE and then see what's fits with the PKIX
anders.rundgren> RFCs.  I find this both awkard and unrealistic.

That actually depends entirely on your base of operation.  PKIX
document the use of certificates and PKI for the Internet, so if you
base your operation on the Internet, the PKIX documents would be
normative.  You would however have to find all the missing pieces in
the ISO/ITU documents :-/.

At least that's how I understand things.  Am I alone in this belief?

(from a personal point of view: when I started playing with PKI, I did
start with the ISO/ITU documents I could get hold of, and then went on
to the RFCs.  However, since my business is based on the Internet, I
base my work on the letter of the RFCs first)

-- 
Richard Levitte     | http://richard.levitte.org/ | Spannv. 38, I
Levitte Programming | http://www.lp.se/           | S-168 35 Bromma
T: [phone] |                             | SWEDEN
     "Price, performance, quality...  choose the two you like"


Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h0EAJ7706328 for ietf-pkix-bks; Tue, 14 Jan 2003 02:19:07 -0800 (PST)
Received: from mailc.telia.com (mailc.telia.com [194.22.190.4]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h0EAJ6o06322 for <[e-mail]>; Tue, 14 Jan 2003 02:19:06 -0800 (PST)
Received: from arport (h119n2fls31o1122.telia.com [212.181.142.119]) by mailc.telia.com (8.12.5/8.12.5) with SMTP id h0EAJ5pc010186; Tue, 14 Jan 2003 11:19:05 +0100 (CET)
X-Original-Recipient: [e-mail]
Message-ID: <012901c2bbb6$11d292d0$0500a8c0@arport>
From: "Anders Rundgren" <[e-mail]>
To: "Stefan Santesson" <[e-mail]>, <[e-mail]>
References: <[e-mail]>
Subject: Re: RFC3039/X.500 naming question
Date: Tue, 14 Jan 2003 11:16:54 +0100
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.50.4133.2400
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Thanx Stefan,
some minor "return-data".

>> A colleague of mine claims that the DN
>>
>>    "CN=Marion Anderson, serialNumber=nnnnnnnnnnnn, C=SE"
>>
>> denotes a Swedish citizen according to ISO/ITU standards.

>What ISO/ITU Standard would that be?

The ones that are the foundation for X.500, that's all I know.

>My guess is that your colleague is wrong. There is at least nothing in RFC
>3280 or RFC 3039 that support that statement.

So I have understood it as well.  But he claims that you must FIRST
read the ISO/ITU-stuff which is NORMATIVE and then see what's
fits with the PKIX RFCs.  I find this both awkard and unrealistic.

<snip>

>> I claim that this is a "convention" (maybe even "good practice")
>> but that this statement at least has no support in PKIX RFCs.
>> RFC3039 which should be close to this issue is BTW absolutely
>> mum about what "C" actually means.

>Actually not.

>RFC 3039 section 3.1.2 says:

>   The countryName attribute value specifies a general context in which
>   other attributes are to be understood.  The country attribute does
>   not necessarily indicate the subject's country of citizenship or
>   country of residence, nor does it have to indicate the country of
>   issuance.

Well, "mum" was an exaggeration of mine, but it is pretty clear that "C"
do not carry huge semantic weight in RFC3039.  Which IMO is perfectly OK.

<snip>

Anders



Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h0E9nV704806 for ietf-pkix-bks; Tue, 14 Jan 2003 01:49:31 -0800 (PST)
Received: from exafix.addtrust.com ([212.112.175.83]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h0E9nTo04801 for <[e-mail]>; Tue, 14 Jan 2003 01:49:29 -0800 (PST)
Received: from Santesson ([213.64.1.87]) by exafix.addtrust.com with Microsoft SMTPSVC(5.0.2195.2966); Tue, 14 Jan 2003 10:49:27 +0100
From: "Stefan Santesson" <[e-mail]>
To: "Anders Rundgren" <[e-mail]>, <[e-mail]>
Subject: RE: RFC3039/X.500 naming question
Date: Tue, 14 Jan 2003 10:49:26 +0100
Message-ID: <[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.6604 (9.0.2911.0)
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106
Importance: Normal
In-Reply-To: <008501c2bb99$a21f0ed0$0500a8c0@arport>
X-OriginalArrivalTime: 14 Jan 2003 09:49:28.0171 (UTC) FILETIME=[3A9C9BB0:01C2BBB2]
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Anders,

Comments in line;

> -----Original Message-----
> From: [e-mail]
> [mailto:[e-mail]]On Behalf Of Anders Rundgren
> Sent: Tuesday, January 14, 2003 7:53 AM
> To: [e-mail]
> Subject: RFC3039/X.500 naming question
>
>
>
> Hi,
>
> A colleague of mine claims that the DN
>
>    "CN=Marion Anderson, serialNumber=nnnnnnnnnnnn, C=SE"
>
> denotes a Swedish citizen according to ISO/ITU standards.

What ISO/ITU Standard would that be?
My guess is that your colleague is wrong. There is at least nothing in RFC
3280 or RFC 3039 that support that statement.

> This makes the DN string globally unique as as it would be a
> "violation" to use the same naming scheme for expressing
> lets say "members" of some kind of organization "associated" to Sweden.

Again that is not necessarily true. A RP can not assume globally uniqueness
just based on the information you supply here. RFC 3039 provide a mechanism
where you could define semantics fro these attributes so that the RP could
have this information and knowledge about the name uniqueness.

>
> I claim that this is a "convention" (maybe even "good practice")
> but that this statement at least has no support in PKIX RFCs.
> RFC3039 which should be close to this issue is BTW absolutely
> mum about what "C" actually means.

Actually not.

RFC 3039 section 3.1.2 says:

   The countryName attribute value specifies a general context in which
   other attributes are to be understood.  The country attribute does
   not necessarily indicate the subject's country of citizenship or
   country of residence, nor does it have to indicate the country of
   issuance.

   Note: Many X.500 implementations require the presence of countryName
   in the DIT.  In cases where the subject name, as specified in the
   subject field, specifies a public X.500 directory entry, the
   countryName attribute SHOULD always be present.

/Stefan

>
> Thoughts?
>
> cheers.
> Anders Rundgren
>
>
>
>
>



Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h0E6tW506211 for ietf-pkix-bks; Mon, 13 Jan 2003 22:55:32 -0800 (PST)
Received: from mailc.telia.com (mailc.telia.com [194.22.190.4]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h0E6tUo06207 for <[e-mail]>; Mon, 13 Jan 2003 22:55:30 -0800 (PST)
Received: from arport (h119n2fls31o1122.telia.com [212.181.142.119]) by mailc.telia.com (8.12.5/8.12.5) with SMTP id h0E6tWFI016016 for <[e-mail]>; Tue, 14 Jan 2003 07:55:32 +0100 (CET)
X-Original-Recipient: <[e-mail]>
Message-ID: <008501c2bb99$a21f0ed0$0500a8c0@arport>
From: "Anders Rundgren" <[e-mail]>
To: <[e-mail]>
Subject: RFC3039/X.500 naming question
Date: Tue, 14 Jan 2003 07:53:24 +0100
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.50.4133.2400
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Hi,

A colleague of mine claims that the DN 

   "CN=Marion Anderson, serialNumber=nnnnnnnnnnnn, C=SE"

denotes a Swedish citizen according to ISO/ITU standards.
This makes the DN string globally unique as as it would be a 
"violation" to use the same naming scheme for expressing
lets say "members" of some kind of organization "associated" to Sweden.

I claim that this is a "convention" (maybe even "good practice")
but that this statement at least has no support in PKIX RFCs.
RFC3039 which should be close to this issue is BTW absolutely
mum about what "C" actually means.

Thoughts?

cheers.
Anders Rundgren






Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h0DJ6Xw19250 for ietf-pkix-bks; Mon, 13 Jan 2003 11:06:33 -0800 (PST)
Received: from mail5.microsoft.com (mail5.microsoft.com [131.107.3.121]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h0DJ6Vo19246 for <[e-mail]>; Mon, 13 Jan 2003 11:06:31 -0800 (PST)
Received: from inet-vrs-05.redmond.corp.microsoft.com ([157.54.6.157]) by mail5.microsoft.com with Microsoft SMTPSVC(5.0.2195.5600); Mon, 13 Jan 2003 11:06:27 -0800
Received: from 157.54.6.197 by inet-vrs-05.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Mon, 13 Jan 2003 11:06:27 -0800
Received: from RED-IMC-01.redmond.corp.microsoft.com ([157.54.9.102]) by inet-hub-06.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.5600); Mon, 13 Jan 2003 11:06:27 -0800
Received: from WIN-IMC-02.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.84]) by RED-IMC-01.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.5600); Mon, 13 Jan 2003 11:06:27 -0800
Received: from WIN-MSG-01.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.52]) by WIN-IMC-02.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(6.0.3718.0); Mon, 13 Jan 2003 11:06:27 -0800
X-MimeOLE: Produced By Microsoft Exchange V6.5.6803.0
Content-class: urn:content-classes:message
Subject: RE: WG Last Call: Logotypes
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Date: Mon, 13 Jan 2003 11:06:26 -0800
Message-ID: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: WG Last Call: Logotypes
thread-index: AcK4vGYJ0TbmI5bnS+yPVgLest4BagCdpGCw
From: "Trevor Freeman" <[e-mail]>
To: "Denis Pinkas" <[e-mail]>
Cc: <[e-mail]>, <[e-mail]>, <[e-mail]>, "Tim Polk" <[e-mail]>
X-OriginalArrivalTime: 13 Jan 2003 19:06:27.0466 (UTC) FILETIME=[DFA696A0:01C2BB36]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id h0DJ6Vo19247
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Denis,
Let me clarify why the document today only places the requirement on the
CA for image sizes so you will understand that the asymmetry between CA
and client requirements was quite deliberate. A UI designer has to
balance the functions which need to be performed with the real-estate
available. For the general case, we have defined a format which should
reasonably support any logotype which the UI designer can reasonably
rely on being available. If they want they can of course allow the
display of larger images at their discretion and local policy. However,
since some logotypes can be displayed in a smaller size, we did not want
to exclude their use either which in situations where there in minimal
real-estate available could mean the deference between some or no
logotypes. Those restrictions could be universal such as on a small hand
held device so it could conceivably mean a device never displays a 60x45
image. I therefore don't agree that we should mandate any display
requirements on the client. At most we can recommend what they do, but
ultimately it's down to the implementer to make the best job given the
restrictions they are under.

Trevor

-----Original Message-----
From: Denis Pinkas [mailto:[e-mail]] 
Sent: Friday, January 10, 2003 7:24 AM
To: Russ Housley
Cc: [e-mail]; [e-mail]; [e-mail]; Trevor
Freeman; Tim Polk
Subject: Re: WG Last Call: Logotypes

Russ,

Thanks for your prompt answer.

> Denis:
> 
>>> This message initiates working group Last Call for the logotypes 
>>> document.  In light of holiday schedules, Last Call will run for 
>>> three weeks rather than two weeks.  That is, Last Call will not
close 
>>> before January 13.   The URL for this Internet-Draft is:
>>>      
>>> http://www.ietf.org/internet-drafts/draft-ietf-pkix-logotypes-09.txt
>>> The editors have informed us that "all of the items briefed at the 
>>> meeting in Atlanta as well as the request by the chairs have been 
>>> handled. In addition, a few comments from working group members that

>>> sent us email have been addressed."
>>
>>
>> I acknowledge the fact that many improvements have been done to the 
>> specification.
>>
>> However I have two remaining concerns:
>>
>> 1. In order to try to solve the minimum interoperability requirements

>> between an application and a certificate issuer, the characteristics 
>> of the size of the picture have been indicated in the following way:
>>
>>    At least one of the image files representing a logotype SHOULD
>>    contain an image within the size range of 60 pixels wide by 45
pixels
>>    high and 200 pixels wide by 150 pixels high.
>>
>> This does not say what whether a client is able or not to display 
>> logos, which was the basic question.
>>
>> I suggest to mandate clients to support at least images within the 
>> size range of 60 pixels wide by 45 pixels. This sentence does not 
>> exist in the document and should be added.
> 
> 
> I have no problem with this addition.

Fine.

>> 2. I have indicated that it would be nice to have an optional pointer

>> to a web site where more information could be obtained about the
logo. 
>> This is currently not possible with the current definition. From a 
>> non-technical point of view, it would be a very nice marketing tool.
>>
>> This can easily be accomplished by adding one OPTIONAL element in the

>> ASN.1 syntax.
> 
> 
> This addition opens a huge can of worms.  I would prefer to leave the 
> lid tightly sealed.

I would rather go fishing with that huge can of worms. :-)

> The certificate issuer would be including a reference in the
certificate 
> to information that is maintained by another party, and that other
party 
> could make unacceptable changes after certificate issuance.  The usual

> mechanism to handle this situation is to include a hash value of the 
> referenced object, preventing any changes.  However, in this context, 
> this does not seem like an appropriate thing to do.  The organization 
> that owns the logo will surely want to make changes to their web page.

> And, it is not easy to handle links form that web page.  Handling
links 
> would require the definition of complicated canonicalization rules.

The basic question is what the link contains. The intent is not to point
to 
a link where you have the exact meaning of the logo, but to the entry
point 
of a web site. Here is an example for such a URL:

http://www.cartes-bancaires.com/GB/Pages/Accueil2.htm

So we need to carefully state what the link contains.

Denis

> Russ
> 
> 




Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h0DEsxr09569 for ietf-pkix-bks; Mon, 13 Jan 2003 06:54:59 -0800 (PST)
Received: from kraid.nerim.net (smtp-101.nerim.net [62.4.16.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h0DEswo09565 for <[e-mail]>; Mon, 13 Jan 2003 06:54:58 -0800 (PST)
Received: from jupiter.cry.pto (cryptolog.net1.nerim.net [80.65.224.225]) by kraid.nerim.net (Postfix) with ESMTP id DDD3840E35 for <[e-mail]>; Mon, 13 Jan 2003 15:37:58 +0100 (CET)
Received: from localhost (localhost [127.0.0.1]) by jupiter.cry.pto (Postfix) with ESMTP id 9C60449F4 for <[e-mail]>; Mon, 13 Jan 2003 15:50:17 +0100 (CET)
Received: from callisto.cry.pto (callisto.cry.pto [10.0.1.4]) by jupiter.cry.pto (Postfix) with SMTP id 3FB0249F2 for <[e-mail]>; Mon, 13 Jan 2003 15:50:17 +0100 (CET)
Received: by callisto.cry.pto (sSMTP sendmail emulation); Mon, 13 Jan 2003 15:50:17 +0100
From: "Julien Stern" <[e-mail]>
Date: Mon, 13 Jan 2003 15:50:17 +0100
To: [e-mail]
Subject: SubjectAltName comparison question.
Message-ID: <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.4i
X-Virus-Scanned: by AMaViS new-20020517
X-Razor-id: e932746e49fd0a29e60537b1b8b6a261b931b661
X-Spam-Status: No, hits=-4.6 tests=SPAM_PHRASE_00_01,USER_AGENT,USER_AGENT_MUTT
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Hi all,

sorry if this is a multi-faq, I checked the archives but could not
find it.

In short the question is: are DN comparisons somewhat inconsistent with
comparisons on equivalent fields in SubjectAltName and IssuerAltName
in RFC3280 ?

More precisely, RFC3280 says in 4.1.2.4:

(b) attribute values in types other than PrintableString are case
sensitive (this permits matching of attribute values as binary objects);

So, because email addresses and domain components are represented as
Ia5Strings, I understand that they should be entirely matched in
a case sensitive manner.

Now, the same RFC in 4.2.1.7 defines matching rules for 
rfc822Name (fully case insensitive according to the RFC, and already
questionned on the list by Steve Hanna, if I remember correctly),
and for dNSName (fully case insensitive).

So, if one choose to put an email attribute or a domain components
attribute in a DN inside a GeneralName, the matching will not be the same
as if the email or the domain components are put in an rfc822Name
or a dNSName inside a GeneralName ?

Now, Pkcs9Email is a legacy attribute, so this might not be a big deal,
but domainComponent is not, and it is explicitely stated in 4.2.1.7 that

"a DNS name MAY be represented in the subject field using the
domainComponent attribute as described in section 4.1.2.4."

So, it seems to me that we have two legal representations for DNS names,
which are not equivalent, as they should be matched differently.

--
Julien Stern
Cryptolog International


Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h0DD0DI01977 for ietf-pkix-bks; Mon, 13 Jan 2003 05:00:13 -0800 (PST)
Received: from e5.ny.us.ibm.com (e5.ny.us.ibm.com [32.97.182.105]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h0DD08o01972 for <[e-mail]>; Mon, 13 Jan 2003 05:00:08 -0800 (PST)
Received: from northrelay04.pok.ibm.com (northrelay04.pok.ibm.com [9.56.224.206]) by e5.ny.us.ibm.com (8.12.2/8.12.2) with ESMTP id h0DD03md005384 for <[e-mail]>; Mon, 13 Jan 2003 08:00:03 -0500
Received: from d01mlc96.pok.ibm.com (d01av02.pok.ibm.com [9.56.224.216]) by northrelay04.pok.ibm.com (8.12.3/NCO/VER6.4) with ESMTP id h0DD00Gm082208 for <[e-mail]>; Mon, 13 Jan 2003 08:00:00 -0500
In-Reply-To: <[e-mail]>
To: [e-mail]
MIME-Version: 1.0
Subject: Re: LDAP PKI Schema (was Re: No-op LDAP ;binary option)
X-Mailer: Lotus Notes Release 6.0 September 26, 2002
From: Timothy Hahn <[e-mail]>
X-MIMETrack: S/MIME Sign by Notes Client on Timothy Hahn/Durham/IBM(Release 6.0|September 26, 2002) at 01/13/2003 07:57:28 AM, Serialize by Notes Client on Timothy Hahn/Durham/IBM(Release 6.0|September 26, 2002) at 01/13/2003 07:57:28 AM, Serialize complete at 01/13/2003 07:57:28 AM, Itemize by Notes Client on Timothy Hahn/Durham/IBM(Release 6.0|September 26, 2002) at 01/13/2003 07:57:28 AM, S/MIME Sign complete at 01/13/2003 07:57:28 AM, S/MIME Sign by Notes Client on Timothy Hahn/Durham/IBM(Release 6.0|September 26, 2002) at 01/13/2003 08:00:01 AM, S/MIME Sign complete at 01/13/2003 08:00:01 AM, Serialize by Router on D01MLC96/01/M/IBM(Build V601_12152002 SPR MIAS5GXKFV CBOD5GVRDB TDAS5GZPCG|January 7, 2003) at 01/13/2003 08:00:01, Serialize complete at 01/13/2003 08:00:01
Message-ID: <[e-mail]>
Date: Mon, 13 Jan 2003 07:59:59 -0500
Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary=-------z35712_boundary_sign
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

This is an S/MIME signed message.

---------z35712_boundary_sign
Content-Type: multipart/alternative; boundary="=_alternative 00472E1685256CAD_="

This is a multipart message in MIME format.
--=_alternative 00472E1685256CAD_=
Content-Type: text/plain; charset="US-ASCII"

Russ,

I agree with you in not wanting two standards for accomplishing the same 
goal.

But I still assert that the (currently) two proposed models do not have 
exactly the same goals, hence a possibility that the different goals 
require different solutions.

Option 1: single entry, containing possibly multiple userCertificate 
attribute values
Goals: (primary) support existing deployments which assume this model, 
(secondary) support attribute-within-certificate searching, (secondary) 
support single userCertificate retrieval.

Option 2: multiple entry, containing single userCertificate attribute 
value per entry, entries related by sub-tree layout
Goals: (primary) support attribute-within-certificate searching with 
existing and widely available directory technologies, (primary) support 
single userCertificate retrieval, (non-goal) support existing deployments 
which assume a single entry model.

I accept the desire to not have this situation, but I also believe it is 
going to occur - so why wouldn't we try and infuse at least some order 
into this situation?

Regards,
Tim Hahn

Internet: [e-mail]
Internal: Timothy Hahn/Durham/IBM@IBMUS
phone: [phone]     tie-line: 8/687.1565
fax: [phone]





Russ Housley <[e-mail]>
Sent by: [e-mail]
01/10/2003 02:31 PM
 
        To:     Timothy Hahn/Durham/IBM@IBMUS
        cc:     [e-mail]
        Subject:        Re: LDAP PKI Schema (was Re: No-op LDAP ;binary 
option)

 


Tim:

In the PKIX WG, we have learned a hard lesson about letting two standard 
that accomplish the same goal progress.  The "let the market decide" has 
lead to camps that implement the alternatives, but do not interoperate 
with 
each other, even if they know why they do not interoperate.  I do not want 

to repeat this mistake.

Russ


At 08:40 AM 1/7/2003 -0500, Timothy Hahn wrote:



>Russ,
>
>Great question.  Simply - it gives the "client" the opportunity to
>establish whether or not it can or cannot support retrieval of the
>information from that data source (directory sub-tree).  Client and 
server
>implementations choose which protocols and data models they're going to
>"support" all the time.  As long as both support the same model(s), then
>they interoperate.  My proposal is that we define one way to identify 
which
>data model(s) is(are) employed, so that servers and clients can determine
>whether they are capable of supporting the formats.  If they are not
>capable, they can gracefully fail.
>
>The client can be made as "fat" or as "lean" as the implementer wants,
>because the implementer can decide which formats to support.  If the
>implementer decides to support one while another part of the industry 
tends
>to support another - well, then that particular implementation will get
>"fatter" because it will wind up supporting both.
>
>My premise is that there is not a single data model that "fits" for ALL
>applications/deployments.  And because of that, multiple data models can
>and will (in real-world scenarios) exist.  So why not accept this, define 
a
>(singular) way of identifying which model is used, and move on.  At least
>in this way, if a particular implementation/application has a need to 
store
>things in a different way, it can, and we can still hope for
>interoperability through IETF documents.
>
>Regards,
>Tim Hahn
>
>Internet: [e-mail]
>Internal: Timothy Hahn/Durham/IBM@IBMUS
>phone: [phone]     tie-line: 8/687.1565
>fax: [phone]
>
>|+-----------------------+------------------------------------------------|
>||   Russ Housley        | |
>||   <[e-mail]|           To:        Timothy |
>||   m>                  |   Hahn/Durham/IBM@IBMUS |
>||                       |           cc:        [e-mail] |
>||   01/06/2003 04:28 PM |           Subject:        Re: LDAP PKI Schema 
|
>||                       |   (was Re: No-op LDAP ;binary option) |
>||                       | |
>||                       | |
>|+-----------------------+------------------------------------------------|
>
>
>
>
>
>Tim:
>
>I do not understand how a client is better off with multiple ways to put
>the same information in the Directory.  Doesn't this approach just make 
the
>client fat?  It seem to me that the client would have to support all of 
the
>possible ways that the information could be stored.  It cannot know which
>method it will encounter until it starts looking at data in the 
Directory.
>
>Russ
>
>
>At 03:14 PM 1/6/2003 -0500, Timothy Hahn wrote:
> >Hello all,
> >
> >After listening to the different view-points on this topic, it seems to 
me
> >that there are multiple valid approaches.  These approaches include, 
but
> >are not limited to:
> >   - leveraging the general solution of component-matching
> >   - new schema to support application-managed componentization of
> >information to make things searchable
> >as well as others (additional matching rules, for example).
> >
> >It occurs to me that perhaps we have a situation where "one size does 
not
> >fit all".  Why not accept this and define a way for applications to
> >determine which (of possibly multiple) format(s) has been used to place
>the
> >information into the directory?  We could define some small bit of 
schema
> >which indicates the way in which the certificate information is placed
>into
> >the directory, then different applications could query this and 
determine:
> >   - whether they can use the data at all
> >   - if they can use the data, how they can best use it (if there are, 
for
> >example, multiple mechanisms employed).
> >
> >Just a thought to get us through this discussion.
> >
> >Regards,
> >Tim Hahn
>
>



--=_alternative 00472E1685256CAD_=
Content-Type: text/html; charset="US-ASCII"


<br><font size=2 face="sans-serif">Russ,</font>
<br>
<br><font size=2 face="sans-serif">I agree with you in not wanting two
standards for accomplishing the same goal.</font>
<br>
<br><font size=2 face="sans-serif">But I still assert that the (currently)
two proposed models do not have exactly the same goals, hence a possibility
that the different goals require different solutions.</font>
<br>
<br><font size=2 face="sans-serif">Option 1: single entry, containing possibly
multiple userCertificate attribute values</font>
<br><font size=2 face="sans-serif">Goals: (primary) support existing deployments
which assume this model, (secondary) support attribute-within-certificate
searching, (secondary) support single userCertificate retrieval.</font>
<br>
<br><font size=2 face="sans-serif">Option 2: multiple entry, containing
single userCertificate attribute value per entry, entries related by sub-tree
layout</font>
<br><font size=2 face="sans-serif">Goals: (primary) support attribute-within-certificate
searching with existing and widely available directory technologies, (primary)
support single userCertificate retrieval, (non-goal) support existing deployments
which assume a single entry model.</font>
<br>
<br><font size=2 face="sans-serif">I accept the desire to not have this
situation, but I also believe it is going to occur - so why wouldn't we
try and infuse at least some order into this situation?</font>
<br>
<br><font size=2 face="sans-serif">Regards,<br>
Tim Hahn<br>
<br>
Internet: [e-mail]<br>
Internal: Timothy Hahn/Durham/IBM@IBMUS<br>
phone: [phone] &nbsp; &nbsp; tie-line: 8/687.1565<br>
fax: [phone]<br>
</font>
<br>
<br>
<br>
<table width=100%>
<tr valign=top>
<td>
<td><font size=1 face="sans-serif"><b>Russ Housley &lt;[e-mail]&gt;</b></font>
<br><font size=1 face="sans-serif">Sent by: [e-mail]</font>
<p><font size=1 face="sans-serif">01/10/2003 02:31 PM</font>
<td><font size=1 face="Arial">&nbsp; &nbsp; &nbsp; &nbsp; </font>
<br><font size=1 face="sans-serif">&nbsp; &nbsp; &nbsp; &nbsp; To:
&nbsp; &nbsp; &nbsp; &nbsp;Timothy Hahn/Durham/IBM@IBMUS</font>
<br><font size=1 face="sans-serif">&nbsp; &nbsp; &nbsp; &nbsp; cc:
&nbsp; &nbsp; &nbsp; &nbsp;[e-mail]</font>
<br><font size=1 face="sans-serif">&nbsp; &nbsp; &nbsp; &nbsp; Subject:
&nbsp; &nbsp; &nbsp; &nbsp;Re: LDAP PKI Schema (was Re: No-op LDAP
;binary option)</font>
<br>
<br><font size=1 face="Arial">&nbsp; &nbsp; &nbsp; &nbsp;</font></table>
<br>
<br><font size=2><tt><br>
Tim:<br>
<br>
In the PKIX WG, we have learned a hard lesson about letting two standard
<br>
that accomplish the same goal progress. &nbsp;The &quot;let the market
decide&quot; has <br>
lead to camps that implement the alternatives, but do not interoperate
with <br>
each other, even if they know why they do not interoperate. &nbsp;I do
not want <br>
to repeat this mistake.<br>
<br>
Russ<br>
<br>
<br>
At 08:40 AM 1/7/2003 -0500, Timothy Hahn wrote:<br>
<br>
<br>
<br>
&gt;Russ,<br>
&gt;<br>
&gt;Great question. &nbsp;Simply - it gives the &quot;client&quot; the
opportunity to<br>
&gt;establish whether or not it can or cannot support retrieval of the<br>
&gt;information from that data source (directory sub-tree). &nbsp;Client
and server<br>
&gt;implementations choose which protocols and data models they're going
to<br>
&gt;&quot;support&quot; all the time. &nbsp;As long as both support the
same model(s), then<br>
&gt;they interoperate. &nbsp;My proposal is that we define one way to identify
which<br>
&gt;data model(s) is(are) employed, so that servers and clients can determine<br>
&gt;whether they are capable of supporting the formats. &nbsp;If they are
not<br>
&gt;capable, they can gracefully fail.<br>
&gt;<br>
&gt;The client can be made as &quot;fat&quot; or as &quot;lean&quot; as
the implementer wants,<br>
&gt;because the implementer can decide which formats to support. &nbsp;If
the<br>
&gt;implementer decides to support one while another part of the industry
tends<br>
&gt;to support another - well, then that particular implementation will
get<br>
&gt;&quot;fatter&quot; because it will wind up supporting both.<br>
&gt;<br>
&gt;My premise is that there is not a single data model that &quot;fits&quot;
for ALL<br>
&gt;applications/deployments. &nbsp;And because of that, multiple data
models can<br>
&gt;and will (in real-world scenarios) exist. &nbsp;So why not accept this,
define a<br>
&gt;(singular) way of identifying which model is used, and move on. &nbsp;At
least<br>
&gt;in this way, if a particular implementation/application has a need
to store<br>
&gt;things in a different way, it can, and we can still hope for<br>
&gt;interoperability through IETF documents.<br>
&gt;<br>
&gt;Regards,<br>
&gt;Tim Hahn<br>
&gt;<br>
&gt;Internet: [e-mail]<br>
&gt;Internal: Timothy Hahn/Durham/IBM@IBMUS<br>
&gt;phone: [phone] &nbsp; &nbsp; tie-line: 8/687.1565<br>
&gt;fax: [phone]<br>
&gt;<br>
&gt;|+-----------------------+------------------------------------------------|<br>
&gt;|| &nbsp; Russ Housley &nbsp; &nbsp; &nbsp; &nbsp;| &nbsp; &nbsp; &nbsp;
&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;
&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;|<br>
&gt;|| &nbsp; &lt;[e-mail]| &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;
To: &nbsp; &nbsp; &nbsp; &nbsp;Timothy &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;
&nbsp; &nbsp; &nbsp; &nbsp; |<br>
&gt;|| &nbsp; m&gt; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;
&nbsp;| &nbsp; Hahn/Durham/IBM@IBMUS &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;
&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;|<br>
&gt;|| &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;
&nbsp; | &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; cc: &nbsp; &nbsp; &nbsp; &nbsp;[e-mail]
&nbsp; &nbsp; &nbsp; &nbsp; |<br>
&gt;|| &nbsp; 01/06/2003 04:28 PM | &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;
Subject: &nbsp; &nbsp; &nbsp; &nbsp;Re: LDAP PKI Schema &nbsp;|<br>
&gt;|| &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;
&nbsp; | &nbsp; (was Re: No-op LDAP ;binary option) &nbsp; &nbsp; &nbsp;
&nbsp; &nbsp;|<br>
&gt;|| &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;
&nbsp; | &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;
&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;
&nbsp; &nbsp; &nbsp; &nbsp;|<br>
&gt;|| &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;
&nbsp; | &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;
&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;
&nbsp; &nbsp; &nbsp; &nbsp;|<br>
&gt;|+-----------------------+------------------------------------------------|<br>
&gt;<br>
&gt;<br>
&gt;<br>
&gt;<br>
&gt;<br>
&gt;Tim:<br>
&gt;<br>
&gt;I do not understand how a client is better off with multiple ways to
put<br>
&gt;the same information in the Directory. &nbsp;Doesn't this approach
just make the<br>
&gt;client fat? &nbsp;It seem to me that the client would have to support
all of the<br>
&gt;possible ways that the information could be stored. &nbsp;It cannot
know which<br>
&gt;method it will encounter until it starts looking at data in the Directory.<br>
&gt;<br>
&gt;Russ<br>
&gt;<br>
&gt;<br>
&gt;At 03:14 PM 1/6/2003 -0500, Timothy Hahn wrote:<br>
&gt; &gt;Hello all,<br>
&gt; &gt;<br>
&gt; &gt;After listening to the different view-points on this topic, it
seems to me<br>
&gt; &gt;that there are multiple valid approaches. &nbsp;These approaches
include, but<br>
&gt; &gt;are not limited to:<br>
&gt; &gt; &nbsp; - leveraging the general solution of component-matching<br>
&gt; &gt; &nbsp; - new schema to support application-managed componentization
of<br>
&gt; &gt;information to make things searchable<br>
&gt; &gt;as well as others (additional matching rules, for example).<br>
&gt; &gt;<br>
&gt; &gt;It occurs to me that perhaps we have a situation where &quot;one
size does not<br>
&gt; &gt;fit all&quot;. &nbsp;Why not accept this and define a way for
applications to<br>
&gt; &gt;determine which (of possibly multiple) format(s) has been used
to place<br>
&gt;the<br>
&gt; &gt;information into the directory? &nbsp;We could define some small
bit of schema<br>
&gt; &gt;which indicates the way in which the certificate information is
placed<br>
&gt;into<br>
&gt; &gt;the directory, then different applications could query this and
determine:<br>
&gt; &gt; &nbsp; - whether they can use the data at all<br>
&gt; &gt; &nbsp; - if they can use the data, how they can best use it (if
there are, for<br>
&gt; &gt;example, multiple mechanisms employed).<br>
&gt; &gt;<br>
&gt; &gt;Just a thought to get us through this discussion.<br>
&gt; &gt;<br>
&gt; &gt;Regards,<br>
&gt; &gt;Tim Hahn<br>
&gt;<br>
&gt;<br>
<br>
</tt></font>
<br>
--=_alternative 00472E1685256CAD_=--

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

MIAGCSqGSIb3DQEHAqCAMIIULwIBATELMAkGBSsOAwIaBQAwCwYJKoZIhvcNAQcBoIISUDCCAtow
ggJDoAMCAQICAwMUtjANBgkqhkiG9w0BAQQFADBOMQswCQYDVQQGEwJVUzEQMA4GA1UEChMHRXF1
aWZheDEtMCsGA1UECxMkRXF1aWZheCBTZWN1cmUgQ2VydGlmaWNhdGUgQXV0aG9yaXR5MB4XDTAy
MDExNDIyMDcxMVoXDTExMTIzMTIyMDcxMVowaTELMAkGA1UEBhMCVVMxNDAyBgNVBAoTK0ludGVy
bmF0aW9uYWwgQnVzaW5lc3MgTWFjaGluZXMgQ29ycG9yYXRpb24xJDAiBgNVBAMTG0lCTSBDZXJ0
aWZpY2F0aW9uIEF1dGhvcml0eTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEA629xc49NpAPz
cAsuShTImLRYMkyepDEkC1UrPbsFRyAFZKsv3pw0MGfW/+7glzJKgPkPzlTZZfznznGbmAWVnNBQ
lyPasOtCjif603euRXReHcKfHMPLItKozibWIPHJuOnwNclOnnP2sKufuPzbTImQTTi5c8JZNZcM
J0YFzTcCAwEAAaOBqjCBpzARBglghkgBhvhCAQEEBAMCAIcwDgYDVR0PAQH/BAQDAgHGMB0GA1Ud
DgQWBBSuVA6S6qgzqSskLcfIbzDc3vNKQDAfBgNVHSMEGDAWgBRI5mj5K9KylddH2CMgEE8zmJCf
1DAPBgNVHRMBAf8EBTADAQH/MDEGA1UdJQQqMCgGCCsGAQUFBwMBBggrBgEFBQcDAgYIKwYBBQUH
AwMGCCsGAQUFBwMEMA0GCSqGSIb3DQEBBAUAA4GBADJye3NmC8q2PzypRZfu7JvDRDX1rRcanZvu
jQupk2oCScMd3FIHLE7hOfu8YffvxtLU3y8wNamQEORjTD175qAffryXypwtiVjBUKSDlBCQ14ke
McF9ViNdewEoBGiAycUq8R3Lrlf4TCDvW4GeguNTFFZnS0ygYATiJk7iDyvEMIIC2jCCAkOgAwIB
AgIDAxS2MA0GCSqGSIb3DQEBBAUAME4xCzAJBgNVBAYTAlVTMRAwDgYDVQQKEwdFcXVpZmF4MS0w
KwYDVQQLEyRFcXVpZmF4IFNlY3VyZSBDZXJ0aWZpY2F0ZSBBdXRob3JpdHkwHhcNMDIwMTE0MjIw
NzExWhcNMTExMjMxMjIwNzExWjBpMQswCQYDVQQGEwJVUzE0MDIGA1UEChMrSW50ZXJuYXRpb25h
bCBCdXNpbmVzcyBNYWNoaW5lcyBDb3Jwb3JhdGlvbjEkMCIGA1UEAxMbSUJNIENlcnRpZmljYXRp
b24gQXV0aG9yaXR5MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDrb3Fzj02kA/NwCy5KFMiY
tFgyTJ6kMSQLVSs9uwVHIAVkqy/enDQwZ9b/7uCXMkqA+Q/OVNll/OfOcZuYBZWc0FCXI9qw60KO
J/rTd65FdF4dwp8cw8si0qjOJtYg8cm46fA1yU6ec/awq5+4/NtMiZBNOLlzwlk1lwwnRgXNNwID
AQABo4GqMIGnMBEGCWCGSAGG+EIBAQQEAwIAhzAOBgNVHQ8BAf8EBAMCAcYwHQYDVR0OBBYEFK5U
DpLqqDOpKyQtx8hvMNze80pAMB8GA1UdIwQYMBaAFEjmaPkr0rKV10fYIyAQTzOYkJ/UMA8GA1Ud
EwEB/wQFMAMBAf8wMQYDVR0lBCowKAYIKwYBBQUHAwEGCCsGAQUFBwMCBggrBgEFBQcDAwYIKwYB
BQUHAwQwDQYJKoZIhvcNAQEEBQADgYEAMnJ7c2YLyrY/PKlFl+7sm8NENfWtFxqdm+6NC6mTagJJ
wx3cUgcsTuE5+7xh9+/G0tTfLzA1qZAQ5GNMPXvmoB9+vJfKnC2JWMFQpIOUEJDXiR4xwX1WI117
ASgEaIDJxSrxHcuuV/hMIO9bgZ6C41MUVmdLTKBgBOImTuIPK8QwggMgMIICiaADAgECAgQ13vTP
MA0GCSqGSIb3DQEBBQUAME4xCzAJBgNVBAYTAlVTMRAwDgYDVQQKEwdFcXVpZmF4MS0wKwYDVQQL
EyRFcXVpZmF4IFNlY3VyZSBDZXJ0aWZpY2F0ZSBBdXRob3JpdHkwHhcNOTgwODIyMTY0MTUxWhcN
MTgwODIyMTY0MTUxWjBOMQswCQYDVQQGEwJVUzEQMA4GA1UEChMHRXF1aWZheDEtMCsGA1UECxMk
RXF1aWZheCBTZWN1cmUgQ2VydGlmaWNhdGUgQXV0aG9yaXR5MIGfMA0GCSqGSIb3DQEBAQUAA4GN
ADCBiQKBgQDBXbFYZwhi7qCaLR8IbZEUaJgKHv7aBG8ThGIhw9F8zp8F4LgB8E407OKKlQRkrPFr
U18Fs8tngL9CAo7+3QEJ7OEAFE/8+/AM3UO6WyvhH4BwmRVXkxbxD5dqt8JoIxzMTVkwrFEeO68r
1u5jRXvF2V9Q0uNQDzqI578U/eDHuQIDAQABo4IBCTCCAQUwcAYDVR0fBGkwZzBloGOgYaRfMF0x
CzAJBgNVBAYTAlVTMRAwDgYDVQQKEwdFcXVpZmF4MS0wKwYDVQQLEyRFcXVpZmF4IFNlY3VyZSBD
ZXJ0aWZpY2F0ZSBBdXRob3JpdHkxDTALBgNVBAMTBENSTDEwGgYDVR0QBBMwEYEPMjAxODA4MjIx
NjQxNTFaMAsGA1UdDwQEAwIBBjAfBgNVHSMEGDAWgBRI5mj5K9KylddH2CMgEE8zmJCf1DAdBgNV
HQ4EFgQUSOZo+SvSspXXR9gjIBBPM5iQn9QwDAYDVR0TBAUwAwEB/zAaBgkqhkiG9n0HQQAEDTAL
GwVWMy4wYwMCBsAwDQYJKoZIhvcNAQEFBQADgYEAWM4p6vz33rXOArkXtYXRuePglcwlMQ0AppJu
f7aSY55QldGab+QR3mOFbpjuqP9ayNNVsmZxV97AIes9KqcjSQEEhkJ7/O5/ohZStWdn00DbOyZY
sih3Pa4Ud2HW+ipmJ6AN+qdzXOpw8ZQhZURf+vzvKWipood573nvT6wHdzgwggMgMIICiaADAgEC
AgQ13vTPMA0GCSqGSIb3DQEBBQUAME4xCzAJBgNVBAYTAlVTMRAwDgYDVQQKEwdFcXVpZmF4MS0w
KwYDVQQLEyRFcXVpZmF4IFNlY3VyZSBDZXJ0aWZpY2F0ZSBBdXRob3JpdHkwHhcNOTgwODIyMTY0
MTUxWhcNMTgwODIyMTY0MTUxWjBOMQswCQYDVQQGEwJVUzEQMA4GA1UEChMHRXF1aWZheDEtMCsG
A1UECxMkRXF1aWZheCBTZWN1cmUgQ2VydGlmaWNhdGUgQXV0aG9yaXR5MIGfMA0GCSqGSIb3DQEB
AQUAA4GNADCBiQKBgQDBXbFYZwhi7qCaLR8IbZEUaJgKHv7aBG8ThGIhw9F8zp8F4LgB8E407OKK
lQRkrPFrU18Fs8tngL9CAo7+3QEJ7OEAFE/8+/AM3UO6WyvhH4BwmRVXkxbxD5dqt8JoIxzMTVkw
rFEeO68r1u5jRXvF2V9Q0uNQDzqI578U/eDHuQIDAQABo4IBCTCCAQUwcAYDVR0fBGkwZzBloGOg
YaRfMF0xCzAJBgNVBAYTAlVTMRAwDgYDVQQKEwdFcXVpZmF4MS0wKwYDVQQLEyRFcXVpZmF4IFNl
Y3VyZSBDZXJ0aWZpY2F0ZSBBdXRob3JpdHkxDTALBgNVBAMTBENSTDEwGgYDVR0QBBMwEYEPMjAx
ODA4MjIxNjQxNTFaMAsGA1UdDwQEAwIBBjAfBgNVHSMEGDAWgBRI5mj5K9KylddH2CMgEE8zmJCf
1DAdBgNVHQ4EFgQUSOZo+SvSspXXR9gjIBBPM5iQn9QwDAYDVR0TBAUwAwEB/zAaBgkqhkiG9n0H
QQAEDTALGwVWMy4wYwMCBsAwDQYJKoZIhvcNAQEFBQADgYEAWM4p6vz33rXOArkXtYXRuePglcwl
MQ0AppJuf7aSY55QldGab+QR3mOFbpjuqP9ayNNVsmZxV97AIes9KqcjSQEEhkJ7/O5/ohZStWdn
00DbOyZYsih3Pa4Ud2HW+ipmJ6AN+qdzXOpw8ZQhZURf+vzvKWipood573nvT6wHdzgwggMiMIIC
i6ADAgECAgJONTANBgkqhkiG9w0BAQQFADBpMQswCQYDVQQGEwJVUzE0MDIGA1UEChMrSW50ZXJu
YXRpb25hbCBCdXNpbmVzcyBNYWNoaW5lcyBDb3Jwb3JhdGlvbjEkMCIGA1UEAxMbSUJNIENlcnRp
ZmljYXRpb24gQXV0aG9yaXR5MB4XDTAyMTEyMTEzMDY1M1oXDTAzMTIwNTEzMDY1M1owgYQxCzAJ
BgNVBAYTAlVTMQwwCgYDVQQKEwNJQk0xETAPBgNVBAsTCEVNUExPWUVFMRgwFgYDVQQDEw9UaW1v
dGh5IEouIEhhaG4xGTAXBgoJkiaJk/IsZAEBEwkxMjg4NTc4OTcxHzAdBgkqhkiG9w0BCQEWEGhh
aG50QHVzLmlibS5jb20wgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBAMZRHQYCNd56O2LkRqmV
bpvr70BMnmNf+UWqMbgJ0v8Y5Vb3hdrThAoyNs3XKbFl9oYir3AFiZHVPUpFM2anK8+Sb9IqzfIh
g/x6Tu9wVHPXkve+wBCGneHD2GgvIx7NEECdr7YuOd7SWevXcLloLu3yQ7Hb2aZ1MQ8o78M9S7K1
AgMBAAGjgbwwgbkwEQYJYIZIAYb4QgEBBAQDAgWgMA4GA1UdDwEB/wQEAwIF4DAdBgNVHQ4EFgQU
z9GrkTcJqnyWERTvptgBPQmzC/QwKwYDVR0RBCQwIqAgBgorBgEEAYI3FAIDoBIMEGhhaG50QHVz
LmlibS5jb20wHwYDVR0jBBgwFoAUrlQOkuqoM6krJC3HyG8w3N7zSkAwJwYDVR0lBCAwHgYIKwYB
BQUHAwIGCCsGAQUFBwMDBggrBgEFBQcDBDANBgkqhkiG9w0BAQQFAAOBgQCHcqGsmuSPRftlK36s
f5HfVXRhzCbH63xR5jLTpzFIfzoNo8u8yeC2yu81Ylj3rLzKmcwNtb9rkQT+wqWJH498ECe66dOQ
6tUDHk3VYGYZ3QrerjTBWBnKoekfUMcp+9xtjsHYVfMEopW/0FU6QsMwj3vouSy6Uv5nTGxKIi73
ZzCCAyIwggKLoAMCAQICAk41MA0GCSqGSIb3DQEBBAUAMGkxCzAJBgNVBAYTAlVTMTQwMgYDVQQK
EytJbnRlcm5hdGlvbmFsIEJ1c2luZXNzIE1hY2hpbmVzIENvcnBvcmF0aW9uMSQwIgYDVQQDExtJ
Qk0gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkwHhcNMDIxMTIxMTMwNjUzWhcNMDMxMjA1MTMwNjUz
WjCBhDELMAkGA1UEBhMCVVMxDDAKBgNVBAoTA0lCTTERMA8GA1UECxMIRU1QTE9ZRUUxGDAWBgNV
BAMTD1RpbW90aHkgSi4gSGFobjEZMBcGCgmSJomT8ixkAQETCTEyODg1Nzg5NzEfMB0GCSqGSIb3
DQEJARYQaGFobnRAdXMuaWJtLmNvbTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAxlEdBgI1
3no7YuRGqZVum+vvQEyeY1/5RaoxuAnS/xjlVveF2tOECjI2zdcpsWX2hiKvcAWJkdU9SkUzZqcr
z5Jv0irN8iGD/HpO73BUc9eS977AEIad4cPYaC8jHs0QQJ2vti453tJZ69dwuWgu7fJDsdvZpnUx
Dyjvwz1LsrUCAwEAAaOBvDCBuTARBglghkgBhvhCAQEEBAMCBaAwDgYDVR0PAQH/BAQDAgXgMB0G
A1UdDgQWBBTP0auRNwmqfJYRFO+m2AE9CbML9DArBgNVHREEJDAioCAGCisGAQQBgjcUAgOgEgwQ
aGFobnRAdXMuaWJtLmNvbTAfBgNVHSMEGDAWgBSuVA6S6qgzqSskLcfIbzDc3vNKQDAnBgNVHSUE
IDAeBggrBgEFBQcDAgYIKwYBBQUHAwMGCCsGAQUFBwMEMA0GCSqGSIb3DQEBBAUAA4GBAIdyoaya
5I9F+2Urfqx/kd9VdGHMJsfrfFHmMtOnMUh/Og2jy7zJ4LbK7zViWPesvMqZzA21v2uRBP7CpYkf
j3wQJ7rp05Dq1QMeTdVgZhndCt6uNMFYGcqh6R9Qxyn73G2OwdhV8wSilb/QVTpCwzCPe+i5LLpS
/mdMbEoiLvdnMYIBujCCAbYCAQEwbzBpMQswCQYDVQQGEwJVUzE0MDIGA1UEChMrSW50ZXJuYXRp
b25hbCBCdXNpbmVzcyBNYWNoaW5lcyBDb3Jwb3JhdGlvbjEkMCIGA1UEAxMbSUJNIENlcnRpZmlj
YXRpb24gQXV0aG9yaXR5AgJONTAJBgUrDgMCGgUAoIGiMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0B
BwEwHAYJKoZIhvcNAQkFMQ8XDTAzMDExMzEyNTcyOFowIwYJKoZIhvcNAQkEMRYEFOG38R/9EyqC
8HEJ4kuOlzKEKP95MEMGCSqGSIb3DQEJDzE2MDQwBwYFKw4DAh0wDgYIKoZIhvcNAwICAgCAMAoG
CCqGSIb3DQMHMA0GCCqGSIb3DQMCAgEoMA0GCSqGSIb3DQEBAQUABIGAGn7zLvGANF8zEbIlyC1H
7Ao8DxZgFh67p0uolSucYBU8L7BZtdcUrkwIkG6BISRSV8YctWodv0gXqXIQpLf0YDqgeX3M3uVQ
8upw4OIlqpV8fBhGV5QwMfwQmLAtXCGHwoViDRre+rZbB/fnjOO8f6IppbHdpDs08rT6JYh/Bh0A
AAAA

---------z35712_boundary_sign--


Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h0DAAiG19767 for ietf-pkix-bks; Mon, 13 Jan 2003 02:10:44 -0800 (PST)
Received: from mail3.consignia.com (mail3.consignia.com [144.87.143.83]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h0DAAho19763 for <[e-mail]>; Mon, 13 Jan 2003 02:10:43 -0800 (PST)
Received: from postoffice.co.uk (mta2.int.consignia.com [144.87.146.16]) by mail3.consignia.com (Postfix) with SMTP id 337C218F97D; Mon, 13 Jan 2003 10:10:42 +0000 (GMT)
Received: by postoffice.co.uk(Lotus SMTP MTA v4.6.6  (890.1 7-16-1999))  id 00256CAD.0037EEFE ; Mon, 13 Jan 2003 10:10:56 +0000
X-Lotus-FromDomain: POSTOFFICE
From: [e-mail]
To: [e-mail]
Cc: Russ Housley <[e-mail]>
Message-ID: <[e-mail]>
Date: Mon, 13 Jan 2003 10:10:33 +0000
Subject: Re: LDAP PKI Schema (was Re: No-op LDAP ;binary option)
Mime-Version: 1.0
Content-type: text/plain; charset=us-ascii
Content-Disposition: inline
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

> The "let the market decide" has
> lead to camps that implement the alternatives, but do not interoperate with
> each other, even if they know why they do not interoperate.  I do not want
> to repeat this mistake.

Amen.

Any chance of coming up with a procedure that de-engineers these
standards ? We are failing in the 'Review' stage of the project
life-cycle :-)

Chris




Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h0D7s2L02227 for ietf-pkix-bks; Sun, 12 Jan 2003 23:54:02 -0800 (PST)
Received: from mailg.telia.com (mailg.telia.com [194.22.194.26]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h0D7s0o02223 for <[e-mail]>; Sun, 12 Jan 2003 23:54:01 -0800 (PST)
Received: from arport (h119n2fls31o1122.telia.com [212.181.142.119]) by mailg.telia.com (8.12.5/8.12.5) with SMTP id h0D7rsLb022300 for <[e-mail]>; Mon, 13 Jan 2003 08:53:55 +0100 (CET)
X-Original-Recipient: <[e-mail]>
Message-ID: <006a01c2bad8$a0802490$0500a8c0@arport>
From: "Anders Rundgren" <[e-mail]>
To: <[e-mail]>
References: <[e-mail]> <009401c1b5a3$ea927cd0$0500a8c0@arport> <[e-mail]> <012201c1b633$93cd09c0$0500a8c0@arport> <[e-mail]>
Subject: Re: I-D ACTION:draft-ietf-pkix-pi-06.txt
Date: Mon, 13 Jan 2003 08:51:48 +0100
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.50.4133.2400
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

In the Nordic region TTP CAs are slowly but surely supporting
a total of 15 million citizens using "implicit" PI-schemes
as described on the next line:

Subject: CN=Maria Svensson, serialNumber=43566, C=SE

Now, how should they preferably convert to using the PKIX PI profile?
(it is of some value to know that these profiles are compatible
with RFC3039 which requires DNs to be unique)


Variant 1. Redundantly storing the citizen code in each EE-cert:
Subject: CN=Maria Svensson, serialNumber=43566, C=SE
PI Assigner Authority: http://government.se/citizens
PI Value: 43566



Variant 2. Adding a nonsense disambiguer code to the subject DN:
Subject: CN=Maria Svensson, serialNumber=6, C=SE
PI Assigner Authority: http://government.se/citizens
PI Value: 43566


It there a variant 3?


Cheers,
Anders



Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h0AJVGn18859 for ietf-pkix-bks; Fri, 10 Jan 2003 11:31:16 -0800 (PST)
Received: from woodstock.binhost.com (woodstock.binhost.com [207.228.252.5]) by above.proper.com (8.11.6/8.11.3) with SMTP id h0AJVFo18855 for <[e-mail]>; Fri, 10 Jan 2003 11:31:15 -0800 (PST)
Received: (qmail 11971 invoked from network); 10 Jan 2003 19:30:54 -0000
Received: from unknown (HELO Russ-Laptop.vigilsec.com) (141.156.178.141) by woodstock.binhost.com with SMTP; 10 Jan 2003 19:30:54 -0000
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9
Date: Fri, 10 Jan 2003 14:31:12 -0500
To: Timothy Hahn <[e-mail]>
From: Russ Housley <[e-mail]>
Subject: Re: LDAP PKI Schema (was Re: No-op LDAP ;binary option)
Cc: [e-mail]
In-Reply-To: <OF095C1351.5EB88FD3-ON85256CA7.0049AEBD-85256CA7.004B1849@ us.ibm.com>
References: <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Tim:

In the PKIX WG, we have learned a hard lesson about letting two standard 
that accomplish the same goal progress.  The "let the market decide" has 
lead to camps that implement the alternatives, but do not interoperate with 
each other, even if they know why they do not interoperate.  I do not want 
to repeat this mistake.

Russ


At 08:40 AM 1/7/2003 -0500, Timothy Hahn wrote:



>Russ,
>
>Great question.  Simply - it gives the "client" the opportunity to
>establish whether or not it can or cannot support retrieval of the
>information from that data source (directory sub-tree).  Client and server
>implementations choose which protocols and data models they're going to
>"support" all the time.  As long as both support the same model(s), then
>they interoperate.  My proposal is that we define one way to identify which
>data model(s) is(are) employed, so that servers and clients can determine
>whether they are capable of supporting the formats.  If they are not
>capable, they can gracefully fail.
>
>The client can be made as "fat" or as "lean" as the implementer wants,
>because the implementer can decide which formats to support.  If the
>implementer decides to support one while another part of the industry tends
>to support another - well, then that particular implementation will get
>"fatter" because it will wind up supporting both.
>
>My premise is that there is not a single data model that "fits" for ALL
>applications/deployments.  And because of that, multiple data models can
>and will (in real-world scenarios) exist.  So why not accept this, define a
>(singular) way of identifying which model is used, and move on.  At least
>in this way, if a particular implementation/application has a need to store
>things in a different way, it can, and we can still hope for
>interoperability through IETF documents.
>
>Regards,
>Tim Hahn
>
>Internet: [e-mail]
>Internal: Timothy Hahn/Durham/IBM@IBMUS
>phone: [phone]     tie-line: 8/687.1565
>fax: [phone]
>
>|+-----------------------+------------------------------------------------|
>||   Russ Housley        |                                                |
>||   <[e-mail]|           To:        Timothy                   |
>||   m>                  |   Hahn/Durham/IBM@IBMUS                        |
>||                       |           cc:        [e-mail]         |
>||   01/06/2003 04:28 PM |           Subject:        Re: LDAP PKI Schema  |
>||                       |   (was Re: No-op LDAP ;binary option)          |
>||                       |                                                |
>||                       |                                                |
>|+-----------------------+------------------------------------------------|
>
>
>
>
>
>Tim:
>
>I do not understand how a client is better off with multiple ways to put
>the same information in the Directory.  Doesn't this approach just make the
>client fat?  It seem to me that the client would have to support all of the
>possible ways that the information could be stored.  It cannot know which
>method it will encounter until it starts looking at data in the Directory.
>
>Russ
>
>
>At 03:14 PM 1/6/2003 -0500, Timothy Hahn wrote:
> >Hello all,
> >
> >After listening to the different view-points on this topic, it seems to me
> >that there are multiple valid approaches.  These approaches include, but
> >are not limited to:
> >   - leveraging the general solution of component-matching
> >   - new schema to support application-managed componentization of
> >information to make things searchable
> >as well as others (additional matching rules, for example).
> >
> >It occurs to me that perhaps we have a situation where "one size does not
> >fit all".  Why not accept this and define a way for applications to
> >determine which (of possibly multiple) format(s) has been used to place
>the
> >information into the directory?  We could define some small bit of schema
> >which indicates the way in which the certificate information is placed
>into
> >the directory, then different applications could query this and determine:
> >   - whether they can use the data at all
> >   - if they can use the data, how they can best use it (if there are, for
> >example, multiple mechanisms employed).
> >
> >Just a thought to get us through this discussion.
> >
> >Regards,
> >Tim Hahn
>
>



Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h0AHeNF15414 for ietf-pkix-bks; Fri, 10 Jan 2003 09:40:23 -0800 (PST)
Received: from ietf.org (odin.ietf.org [132.151.1.176]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h0AHeLo15406 for <[e-mail]>; Fri, 10 Jan 2003 09:40:21 -0800 (PST)
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA05599; Fri, 10 Jan 2003 12:37:05 -0500 (EST)
Message-Id: <[e-mail]>
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
Cc: [e-mail]
From: [e-mail]
Reply-to: [e-mail]
Subject: I-D ACTION:draft-ietf-pkix-ocsp-dpvdpd-00.txt
Date: Fri, 10 Jan 2003 12:37:04 -0500
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

--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		: DPV and DPD over OCSP
	Author(s)	: M. Myers
	Filename	: draft-ietf-pkix-ocsp-dpvdpd-00.txt
	Pages		: 8
	Date		: 2003-1-9
	
This specification standardizes means by which the extensibility mechanisms of OCSP are to be used for Delegated Path Validation (DPV) and Delegated Path Discovery (DPD). Familiarity with OCSP core syntax [RFC2560] is assumed.

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

To remove yourself from the IETF Announcement list, send a message to 
ietf-announce-request with the word unsubscribe in the body of the message.

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

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


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

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

--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"

--OtherAccess
Content-Type: Message/External-body;
	access-type="mail-server";
	server="[e-mail]"

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

ENCODING mime
FILE /internet-drafts/draft-ietf-pkix-ocsp-dpvdpd-00.txt

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

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

--OtherAccess--

--NextPart--




Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h0AGgD513336 for ietf-pkix-bks; Fri, 10 Jan 2003 08:42:13 -0800 (PST)
Received: from woodstock.binhost.com (woodstock.binhost.com [207.228.252.5]) by above.proper.com (8.11.6/8.11.3) with SMTP id h0AGg9o13316 for <[e-mail]>; Fri, 10 Jan 2003 08:42:10 -0800 (PST)
Received: (qmail 31448 invoked from network); 10 Jan 2003 16:41:41 -0000
Received: from unknown (HELO Russ-Laptop.vigilsec.com) (141.156.215.77) by woodstock.binhost.com with SMTP; 10 Jan 2003 16:41:41 -0000
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9
Date: Fri, 10 Jan 2003 11:14:49 -0500
To: Denis Pinkas <[e-mail]>
From: Russ Housley <[e-mail]>
Subject: Re: WG Last Call: Logotypes
Cc: [e-mail], [e-mail], [e-mail], [e-mail], Tim Polk <[e-mail]>
In-Reply-To: <[e-mail]>
References: <[e-mail]> <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Denis:

>>The certificate issuer would be including a reference in the certificate 
>>to information that is maintained by another party, and that other party 
>>could make unacceptable changes after certificate issuance.  The usual 
>>mechanism to handle this situation is to include a hash value of the 
>>referenced object, preventing any changes.  However, in this context, 
>>this does not seem like an appropriate thing to do.  The organization 
>>that owns the logo will surely want to make changes to their web page.
>>And, it is not easy to handle links form that web page.  Handling links 
>>would require the definition of complicated canonicalization rules.
>
>The basic question is what the link contains. The intent is not to point 
>to a link where you have the exact meaning of the logo, but to the entry 
>point of a web site. Here is an example for such a URL:
>
>http://www.cartes-bancaires.com/GB/Pages/Accueil2.htm
>
>So we need to carefully state what the link contains.

I understand the manner that you wish to use the URL.  It is not 
appropriate to prevent changes to such a web page by including a hash in 
the certificate.  So, it is possible for changes to be unacceptable to the 
certificate issuer.  The only recourse would be the revocation of the 
certificate, and this punishes the wrong party.  The subject would have to 
get a new certificate (without the embedded URL), yet the subject had no 
part in the activities that lead to revocation.

I remain opposed.

Russ



Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h0AFOvt09326 for ietf-pkix-bks; Fri, 10 Jan 2003 07:24:57 -0800 (PST)
Received: from odin2.bull.net (odin2.bull.net [192.90.70.84]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h0AFOso09315 for <[e-mail]>; Fri, 10 Jan 2003 07:24:54 -0800 (PST)
Received: from clbull.frcl.bull.fr (clbull.frcl.bull.fr [129.182.8.31]) by odin2.bull.net (8.9.3/8.9.3) with ESMTP id QAA35540; Fri, 10 Jan 2003 16:25:09 +0100
Received: from bull.net (frcls4013.frcl.bull.fr [129.182.108.120]) by clbull.frcl.bull.fr (8.9.2/8.9.1) with ESMTP id QAA19392; Fri, 10 Jan 2003 16:23:48 +0100
Message-ID: <[e-mail]>
Date: Fri, 10 Jan 2003 16:23:32 +0100
From: Denis Pinkas <[e-mail]>
Organization: Bull SA.
User-Agent: Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.0.1) Gecko/20020823 Netscape/7.0
X-Accept-Language: en-us, en, fr
MIME-Version: 1.0
To: Russ Housley <[e-mail]>
CC: [e-mail], [e-mail], [e-mail], [e-mail], Tim Polk <[e-mail]>
Subject: Re: WG Last Call: Logotypes
References: <[e-mail]> <[e-mail]>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Russ,

Thanks for your prompt answer.

> Denis:
> 
>>> This message initiates working group Last Call for the logotypes 
>>> document.  In light of holiday schedules, Last Call will run for 
>>> three weeks rather than two weeks.  That is, Last Call will not close 
>>> before January 13.   The URL for this Internet-Draft is:
>>>      
>>> http://www.ietf.org/internet-drafts/draft-ietf-pkix-logotypes-09.txt
>>> The editors have informed us that "all of the items briefed at the 
>>> meeting in Atlanta as well as the request by the chairs have been 
>>> handled. In addition, a few comments from working group members that 
>>> sent us email have been addressed."
>>
>>
>> I acknowledge the fact that many improvements have been done to the 
>> specification.
>>
>> However I have two remaining concerns:
>>
>> 1. In order to try to solve the minimum interoperability requirements 
>> between an application and a certificate issuer, the characteristics 
>> of the size of the picture have been indicated in the following way:
>>
>>    At least one of the image files representing a logotype SHOULD
>>    contain an image within the size range of 60 pixels wide by 45 pixels
>>    high and 200 pixels wide by 150 pixels high.
>>
>> This does not say what whether a client is able or not to display 
>> logos, which was the basic question.
>>
>> I suggest to mandate clients to support at least images within the 
>> size range of 60 pixels wide by 45 pixels. This sentence does not 
>> exist in the document and should be added.
> 
> 
> I have no problem with this addition.

Fine.

>> 2. I have indicated that it would be nice to have an optional pointer 
>> to a web site where more information could be obtained about the logo. 
>> This is currently not possible with the current definition. From a 
>> non-technical point of view, it would be a very nice marketing tool.
>>
>> This can easily be accomplished by adding one OPTIONAL element in the 
>> ASN.1 syntax.
> 
> 
> This addition opens a huge can of worms.  I would prefer to leave the 
> lid tightly sealed.

I would rather go fishing with that huge can of worms. :-)

> The certificate issuer would be including a reference in the certificate 
> to information that is maintained by another party, and that other party 
> could make unacceptable changes after certificate issuance.  The usual 
> mechanism to handle this situation is to include a hash value of the 
> referenced object, preventing any changes.  However, in this context, 
> this does not seem like an appropriate thing to do.  The organization 
> that owns the logo will surely want to make changes to their web page.  
> And, it is not easy to handle links form that web page.  Handling links 
> would require the definition of complicated canonicalization rules.

The basic question is what the link contains. The intent is not to point to 
a link where you have the exact meaning of the logo, but to the entry point 
of a web site. Here is an example for such a URL:

http://www.cartes-bancaires.com/GB/Pages/Accueil2.htm

So we need to carefully state what the link contains.

Denis

> Russ
> 
> 




Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h0AEBLd05603 for ietf-pkix-bks; Fri, 10 Jan 2003 06:11:21 -0800 (PST)
Received: from woodstock.binhost.com (woodstock.binhost.com [207.228.252.5]) by above.proper.com (8.11.6/8.11.3) with SMTP id h0AEBIo05598 for <[e-mail]>; Fri, 10 Jan 2003 06:11:18 -0800 (PST)
Received: (qmail 22762 invoked from network); 10 Jan 2003 14:10:46 -0000
Received: from unknown (HELO Russ-Laptop.vigilsec.com) (141.156.186.236) by woodstock.binhost.com with SMTP; 10 Jan 2003 14:10:46 -0000
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9
Date: Fri, 10 Jan 2003 09:04:04 -0500
To: Denis Pinkas <[e-mail]>
From: Russ Housley <[e-mail]>
Subject: Re: WG Last Call: Logotypes
Cc: [e-mail], [e-mail], [e-mail], [e-mail], Tim Polk <[e-mail]>
In-Reply-To: <[e-mail]>
References: <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Denis:

>>This message initiates working group Last Call for the logotypes 
>>document.  In light of holiday schedules, Last Call will run for three 
>>weeks rather than two weeks.  That is, Last Call will not close before 
>>January 13.   The URL for this Internet-Draft is:
>>      http://www.ietf.org/internet-drafts/draft-ietf-pkix-logotypes-09.txt
>>The editors have informed us that "all of the items briefed at the 
>>meeting in Atlanta as well as the request by the chairs have been 
>>handled. In addition, a few comments from working group members that sent 
>>us email have been addressed."
>
>I acknowledge the fact that many improvements have been done to the 
>specification.
>
>However I have two remaining concerns:
>
>1. In order to try to solve the minimum interoperability requirements 
>between an application and a certificate issuer, the characteristics of 
>the size of the picture have been indicated in the following way:
>
>    At least one of the image files representing a logotype SHOULD
>    contain an image within the size range of 60 pixels wide by 45 pixels
>    high and 200 pixels wide by 150 pixels high.
>
>This does not say what whether a client is able or not to display logos, 
>which was the basic question.
>
>I suggest to mandate clients to support at least images within the size 
>range of 60 pixels wide by 45 pixels. This sentence does not exist in the 
>document and should be added.

I have no problem with this addition.


>2. I have indicated that it would be nice to have an optional pointer to a 
>web site where more information could be obtained about the logo. This is 
>currently not possible with the current definition. From a non-technical 
>point of view, it would be a very nice marketing tool.
>
>This can easily be accomplished by adding one OPTIONAL element in the 
>ASN.1 syntax.

This addition opens a huge can of worms.  I would prefer to leave the lid 
tightly sealed.

The certificate issuer would be including a reference in the certificate to 
information that is maintained by another party, and that other party could 
make unacceptable changes after certificate issuance.  The usual mechanism 
to handle this situation is to include a hash value of the referenced 
object, preventing any changes.  However, in this context, this does not 
seem like an appropriate thing to do.  The organization that owns the logo 
will surely want to make changes to their web page.  And, it is not easy to 
handle links form that web page.  Handling links would require the 
definition of complicated canonicalization rules.

Russ



Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h0ADi5704774 for ietf-pkix-bks; Fri, 10 Jan 2003 05:44:05 -0800 (PST)
Received: from odin2.bull.net (odin2.bull.net [192.90.70.84]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h0ADi2o04770 for <[e-mail]>; Fri, 10 Jan 2003 05:44:03 -0800 (PST)
Received: from clbull.frcl.bull.fr (clbull.frcl.bull.fr [129.182.8.31]) by odin2.bull.net (8.9.3/8.9.3) with ESMTP id OAA26806; Fri, 10 Jan 2003 14:45:36 +0100
Received: from bull.net (frcls4013.frcl.bull.fr [129.182.108.120]) by clbull.frcl.bull.fr (8.9.2/8.9.1) with ESMTP id OAA25016; Fri, 10 Jan 2003 14:44:15 +0100
Message-ID: <[e-mail]>
Date: Fri, 10 Jan 2003 14:43:59 +0100
From: Denis Pinkas <[e-mail]>
Organization: Bull SA.
User-Agent: Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.0.1) Gecko/20020823 Netscape/7.0
X-Accept-Language: en-us, en, fr
MIME-Version: 1.0
To: carol <[e-mail]>
CC: "[e-mail]" <[e-mail]>
Subject: Re: [TSP] while introduce TSU in RFC3161bis-00?
References: <[e-mail]>
Content-Type: text/plain; charset=GB2312
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Carol,

Sorry for the delay to answer,

> Folks,
> 
>   I am wondering while RFC3161bis-00 introduces TSU.
>   Can I interpret as the following ?
>      1. One TSA may support multiple policy, just as one CA may have multiple policy.
>      2. Each policy or some policies of one TSA needs a TSU to support.

The basic argument is that one TSA (i.e. organization) may be in charge of
several TSUs (units). Each unit has its own key pair while the organization
does not need to have any key pair. Units can be revoked, while there is no
concept of revocation of the organization as a whole.

It is true as well that one TSA (i.e. organization) can support several
policies.

Regards,

Denis


> Thanks in advance,
> 
> carol
> [e-mail]
> 2002-12-24




Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h0ACkbn29884 for ietf-pkix-bks; Fri, 10 Jan 2003 04:46:37 -0800 (PST)
Received: from mail3.consignia.com (mail3.consignia.com [144.87.143.83]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h0ACkao29880 for <[e-mail]>; Fri, 10 Jan 2003 04:46:36 -0800 (PST)
Received: from postoffice.co.uk (mta2.int.consignia.com [144.87.146.16]) by mail3.consignia.com (Postfix) with SMTP id DCBD118F8D9; Fri, 10 Jan 2003 12:46:35 +0000 (GMT)
Received: by postoffice.co.uk(Lotus SMTP MTA v4.6.6  (890.1 7-16-1999))  id 00256CAA.00463106 ; Fri, 10 Jan 2003 12:46:40 +0000
X-Lotus-FromDomain: POSTOFFICE
From: [e-mail]
To: Richard Levitte - VMS Whacker <[e-mail]>
Cc: [e-mail]
Message-ID: <[e-mail]>
Date: Fri, 10 Jan 2003 11:59:01 +0000
Subject: Re: e-tendering enabler digital certificate
Mime-Version: 1.0
Content-type: text/plain; charset=us-ascii
Content-Disposition: inline
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

> attribute certificates come to mind.

I have no doubt that it could be done but it strikes
me as a rather specialised implementation. I am sure,
that any of the large cert vendors would gladly relieve
the parties involved in the process of their cash in
return for the privilege of constructing the certs and
the associated registration process :-)

Alternatively, if the issuer of the tender owns and
runs a CA then they could issue appropriate Attribute
Certificates to those people tendering.

Then again CA could even be owned by an organisation
that sells the facilitation of this sort of thing and
includes the cost of the certs and registration in the
package. The more generic the supporting infrastructure
becomes the lower the cost of implementation.

Chris




Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h0ACVYx29492 for ietf-pkix-bks; Fri, 10 Jan 2003 04:31:34 -0800 (PST)
Received: from odin2.bull.net (odin2.bull.net [192.90.70.84]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h0ACVVo29487 for <[e-mail]>; Fri, 10 Jan 2003 04:31:31 -0800 (PST)
Received: from clbull.frcl.bull.fr (clbull.frcl.bull.fr [129.182.8.31]) by odin2.bull.net (8.9.3/8.9.3) with ESMTP id NAA15536; Fri, 10 Jan 2003 13:32:32 +0100
Received: from bull.net (frcls4013.frcl.bull.fr [129.182.108.120]) by clbull.frcl.bull.fr (8.9.2/8.9.1) with ESMTP id NAA22528; Fri, 10 Jan 2003 13:31:11 +0100
Message-ID: <[e-mail]>
Date: Fri, 10 Jan 2003 13:30:54 +0100
From: Denis Pinkas <[e-mail]>
Organization: Bull SA.
User-Agent: Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.0.1) Gecko/20020823 Netscape/7.0
X-Accept-Language: en-us, en, fr
MIME-Version: 1.0
To: Tim Polk <[e-mail]>
CC: [e-mail], [e-mail], Russ Housley <[e-mail]>, [e-mail], [e-mail]
Subject: Re: WG Last Call: Logotypes
References: <[e-mail]>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

> This message initiates working group Last Call for the logotypes 
> document.  In light of holiday schedules, Last Call will run for three 
> weeks rather than two weeks.  That is, Last Call will not close before 
> January 13.   The URL for this Internet-Draft is:
> 
>      http://www.ietf.org/internet-drafts/draft-ietf-pkix-logotypes-09.txt
> 
> The editors have informed us that "all of the items briefed at the 
> meeting in Atlanta as well as the request by the chairs have been 
> handled. In addition, a few comments from working group members that 
> sent us email have been addressed."

I acknowledge the fact that many improvements have been done to the 
specification.

However I have two remaining concerns:

1. In order to try to solve the minimum interoperability requirements 
between an application and a certificate issuer, the characteristics of the 
size of the picture have been indicated in the following way:

    At least one of the image files representing a logotype SHOULD
    contain an image within the size range of 60 pixels wide by 45 pixels
    high and 200 pixels wide by 150 pixels high.

This does not say what whether a client is able or not to display logos, 
which was the basic question.

I suggest to mandate clients to support at least images within the size 
range of 60 pixels wide by 45 pixels. This sentence does not exist in the 
document and should be added.


2. I have indicated that it would be nice to have an optional pointer to a 
web site where more information could be obtained about the logo. This is 
currently not possible with the current definition. From a non-technical 
point of view, it would be a very nice marketing tool.

This can easily be accomplished by adding one OPTIONAL element in the ASN.1 
syntax.

Denis



Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h0AB7Wc24059 for ietf-pkix-bks; Fri, 10 Jan 2003 03:07:32 -0800 (PST)
Received: from nic.lp.se (nic.lp.se [212.247.5.91]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h0AB7To24045 for <[e-mail]>; Fri, 10 Jan 2003 03:07:30 -0800 (PST)
Received: from localhost (217.215.93.181) by nic.lp.se (MX V5.3 VnHj) with ESMTP; Fri, 10 Jan 2003 12:05:33 +0100
Date: Fri, 10 Jan 2003 12:03:36 +0100 (CET)
Message-ID: <[e-mail]>
To: [e-mail]
CC: [e-mail], [e-mail]
Subject: Re: e-tendering enabler digital certificate
From: Richard Levitte - VMS Whacker <[e-mail]>
In-Reply-To: <[e-mail]>
References: <[e-mail]>
X-URL: http://www.lp.se/
X-Waved: dead chicken, GNU emacs 21.2.2, Mew version 3.1
X-Mew: See http://www.mew.org/
X-Mailer: Mew version 3.1 on Emacs 21.2 / Mule 5.0 (SAKAKI)
MIME-Version: 1.0
Content-Type: Text/Plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

In message <[e-mail]> on Fri, 10 Jan 2003 08:41:45 +0000, [e-mail] said:

chris.gilbert> > My idea ... is to rely on digital certificate with particular
chris.gilbert> > attributes.
chris.gilbert> 
chris.gilbert> I am against building application information into Certificates.
chris.gilbert> They are merely a trust mechanism. Every time you add to the
chris.gilbert> content you make it harder to achieve interoperability. Push the
chris.gilbert> application specific logic back into the application.

Hmm, attribute certificates come to mind.  Is there any reason (apart
from lack of implementation, I'm want to hear theories, not that it
currently can't be achieved in practice) not to use them?

-- 
Richard Levitte     | http://richard.levitte.org/ | Spannv. 38, I
Levitte Programming | http://www.lp.se/           | S-168 35 Bromma
T: [phone] |                             | SWEDEN
     "Price, performance, quality...  choose the two you like"


Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h0A8gE508551 for ietf-pkix-bks; Fri, 10 Jan 2003 00:42:14 -0800 (PST)
Received: from mail4.consignia.com (mail4.consignia.com [144.87.143.84]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h0A8gCo08540 for <[e-mail]>; Fri, 10 Jan 2003 00:42:13 -0800 (PST)
Received: from postoffice.co.uk (mta2.int.consignia.com [144.87.146.16]) by mail4.consignia.com (Postfix) with SMTP id B4C7412237C; Fri, 10 Jan 2003 08:42:02 +0000 (GMT)
Received: by postoffice.co.uk(Lotus SMTP MTA v4.6.6  (890.1 7-16-1999))  id 00256CAA.002FD0A6 ; Fri, 10 Jan 2003 08:42:16 +0000
X-Lotus-FromDomain: POSTOFFICE
From: [e-mail]
To: [e-mail]
Cc: [e-mail]
Message-ID: <[e-mail]>
Date: Fri, 10 Jan 2003 08:41:45 +0000
Subject: Re: e-tendering enabler digital certificate
Mime-Version: 1.0
Content-type: text/plain; charset=us-ascii
Content-Disposition: inline
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

> My idea ... is to rely on digital certificate with particular
> attributes.

I am against building application information into Certificates.
They are merely a trust mechanism. Every time you add to the
content you make it harder to achieve interoperability. Push the
application specific logic back into the application.

Chris




Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h0A5epM18870 for ietf-pkix-bks; Thu, 9 Jan 2003 21:40:51 -0800 (PST)
Received: from ns.malpani.biz (adsl-63-194-89-166.dsl.snfc21.pacbell.net [63.194.89.166]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h0A5eoo18866 for <[e-mail]>; Thu, 9 Jan 2003 21:40:50 -0800 (PST)
Received: from nt1 (nt1.malpani.biz [192.168.25.13]) by ns.malpani.biz (8.12.5/8.12.5) with SMTP id h0A5eqZp008617; Thu, 9 Jan 2003 21:40:52 -0800
From: "Ambarish Malpani" <[e-mail]>
To: "Miguel Rodriguez" <[e-mail]>, <[e-mail]>
Subject: RE: OCSP signed requests
Date: Thu, 9 Jan 2003 21:41:19 -0800
Message-ID: <[e-mail]>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_0135_01C2B827.D8672970"
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0)
In-Reply-To: <001001c2b837$a4866b60$[e-mail]>
X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1106
Importance: Normal
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

This is a multi-part message in MIME format.

------=_NextPart_000_0135_01C2B827.D8672970
Content-Type: text/plain;
	charset="US-ASCII"
Content-Transfer-Encoding: 7bit

Hi Miguel,
    If a responder doesn't require signed requests, it is free to ignore the
signature
completely and not validate it at all.

Hope this helps,
Regards,
Ambarish

---------------------------------------------------------------------
Ambarish Malpani                                          650.759.9045
Malpani Consulting Services
[e-mail]



  -----Original Message-----
  From: [e-mail] [mailto:[e-mail]]On
Behalf Of Miguel Rodriguez
  Sent: Thursday, January 09, 2003 3:34 PM
  To: [e-mail]
  Subject: OCSP signed requests


  What is the prescribed (or most common) behavior of an OCSP responder when
receiving a signed request? Should the signature be ignored if it is not
required?



  Thanks,



  Miguel A. Rodriguez

  Software Engineer

  SeguriDATA



------=_NextPart_000_0135_01C2B827.D8672970
Content-Type: text/html;
	charset="US-ASCII"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML xmlns=3D"http://www.w3.org/TR/REC-html40" xmlns:o =3D=20
"urn:schemas-microsoft-com:office:office" xmlns:w =3D=20
"urn:schemas-microsoft-com:office:word"><HEAD>
<META http-equiv=3DContent-Type content=3D"text/html; =
charset=3Dus-ascii">
<META content=3DWord.Document name=3DProgId>
<META content=3D"MSHTML 6.00.2800.1126" name=3DGENERATOR>
<META content=3D"Microsoft Word 10" name=3DOriginator><LINK=20
href=3D"cid:filelist.xml@01C2B805.56704220" rel=3DFile-List><!--[if gte =
mso 9]><xml>
 <o:OfficeDocumentSettings>
  <o:DoNotRelyOnCSS/>
 </o:OfficeDocumentSettings>
</xml><![endif]--><!--[if gte mso 9]><xml>
 <w:WordDocument>
  <w:SpellingState>Clean</w:SpellingState>
  <w:GrammarState>Clean</w:GrammarState>
  <w:DocumentKind>DocumentEmail</w:DocumentKind>
  <w:EnvelopeVis/>
  <w:Compatibility>
   <w:BreakWrappedTables/>
   <w:SnapToGridInCell/>
   <w:WrapTextWithPunct/>
   <w:UseAsianBreakRules/>
  </w:Compatibility>
  <w:BrowserLevel>MicrosoftInternetExplorer4</w:BrowserLevel>
 </w:WordDocument>
</xml><![endif]-->
<STYLE>@font-face {
	font-family: Arial Narrow;
}
@page Section1 {size: 612.0pt 792.0pt; margin: 72.0pt 90.0pt 72.0pt =
90.0pt; mso-header-margin: 35.4pt; mso-footer-margin: 35.4pt; =
mso-paper-source: 0; }
P.MsoNormal {
	FONT-SIZE: 12pt; MARGIN: 0cm 0cm 0pt; FONT-FAMILY: "Times New Roman"; =
mso-style-parent: ""; mso-pagination: widow-orphan; =
mso-fareast-font-family: "Times New Roman"
}
LI.MsoNormal {
	FONT-SIZE: 12pt; MARGIN: 0cm 0cm 0pt; FONT-FAMILY: "Times New Roman"; =
mso-style-parent: ""; mso-pagination: widow-orphan; =
mso-fareast-font-family: "Times New Roman"
}
DIV.MsoNormal {
	FONT-SIZE: 12pt; MARGIN: 0cm 0cm 0pt; FONT-FAMILY: "Times New Roman"; =
mso-style-parent: ""; mso-pagination: widow-orphan; =
mso-fareast-font-family: "Times New Roman"
}
A:link {
	COLOR: blue; TEXT-DECORATION: underline; text-underline: single
}
SPAN.MsoHyperlink {
	COLOR: blue; TEXT-DECORATION: underline; text-underline: single
}
A:visited {
	COLOR: purple; TEXT-DECORATION: underline; text-underline: single
}
SPAN.MsoHyperlinkFollowed {
	COLOR: purple; TEXT-DECORATION: underline; text-underline: single
}
SPAN.EmailStyle17 {
	COLOR: windowtext; FONT-FAMILY: Arial; mso-style-type: =
personal-compose; mso-style-noshow: yes; mso-ansi-font-size: 10.0pt; =
mso-bidi-font-size: 10.0pt; mso-ascii-font-family: Arial; =
mso-hansi-font-family: Arial; mso-bidi-font-family: Arial
}
DIV.Section1 {
	page: Section1
}
</STYLE>
<!--[if gte mso 10]>
<style>
 /* Style Definitions */=20
 table.MsoNormalTable
	{mso-style-name:"Table Normal";
	mso-tstyle-rowband-size:0;
	mso-tstyle-colband-size:0;
	mso-style-noshow:yes;
	mso-style-parent:"";
	mso-padding-alt:0cm 5.4pt 0cm 5.4pt;
	mso-para-margin:0cm;
	mso-para-margin-bottom:.0001pt;
	mso-pagination:widow-orphan;
	font-size:10.0pt;
	font-family:"Times New Roman";}
</style>
<![endif]--></HEAD>
<BODY lang=3DEN-US style=3D"tab-interval: 36.0pt" vLink=3Dpurple =
link=3Dblue>
<DIV><SPAN class=3D912194005-10012003><FONT face=3DArial color=3D#0000ff =
size=3D2>Hi=20
Miguel,</FONT></SPAN></DIV>
<DIV><SPAN class=3D912194005-10012003><FONT face=3DArial color=3D#0000ff =

size=3D2>&nbsp;&nbsp;&nbsp; If a responder doesn't require signed =
requests, it is=20
free to ignore the signature</FONT></SPAN></DIV>
<DIV><SPAN class=3D912194005-10012003><FONT face=3DArial color=3D#0000ff =

size=3D2>completely and not validate it at all.</FONT></SPAN></DIV>
<DIV><SPAN class=3D912194005-10012003><FONT face=3DArial color=3D#0000ff =

size=3D2></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=3D912194005-10012003><FONT face=3DArial color=3D#0000ff =
size=3D2>Hope=20
this helps,</FONT></SPAN></DIV>
<DIV><SPAN class=3D912194005-10012003><FONT face=3DArial color=3D#0000ff =

size=3D2>Regards,</FONT></SPAN></DIV>
<DIV><SPAN class=3D912194005-10012003><FONT face=3DArial color=3D#0000ff =

size=3D2>Ambarish</FONT></SPAN></DIV>
<DIV>&nbsp;</DIV>
<P><FONT=20
size=3D2>----------------------------------------------------------------=
-----<BR>Ambarish=20
Malpani&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&=
nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
650.759.9045<BR>Malpani Consulting=20
Services&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
[e-mail]<BR><BR></FONT></P>
<BLOCKQUOTE dir=3Dltr=20
style=3D"PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: #0000ff 2px =
solid; MARGIN-RIGHT: 0px">
  <DIV class=3DOutlookMessageHeader dir=3Dltr align=3Dleft><FONT =
face=3DTahoma=20
  size=3D2>-----Original Message-----<BR><B>From:</B> =
[e-mail]=20
  [mailto:[e-mail]]<B>On Behalf Of </B>Miguel=20
  Rodriguez<BR><B>Sent:</B> Thursday, January 09, 2003 3:34 =
PM<BR><B>To:</B>=20
  [e-mail]<BR><B>Subject:</B> OCSP signed =
requests<BR><BR></FONT></DIV>
  <DIV class=3DSection1>
  <P class=3DMsoNormal><FONT face=3DArial size=3D2><SPAN=20
  style=3D"FONT-SIZE: 10pt; FONT-FAMILY: Arial">What is the prescribed =
(or most=20
  common) behavior of an OCSP responder when receiving a signed request? =
Should=20
  the signature be ignored if it is not required? =
<o:p></o:p></SPAN></FONT></P>
  <P class=3DMsoNormal><FONT face=3DArial size=3D2><SPAN=20
  style=3D"FONT-SIZE: 10pt; FONT-FAMILY: =
Arial"><o:p>&nbsp;</o:p></SPAN></FONT></P>
  <P class=3DMsoNormal><FONT face=3DArial size=3D2><SPAN=20
  style=3D"FONT-SIZE: 10pt; FONT-FAMILY: =
Arial">Thanks,<o:p></o:p></SPAN></FONT></P>
  <P class=3DMsoNormal><FONT face=3DArial size=3D2><SPAN=20
  style=3D"FONT-SIZE: 10pt; FONT-FAMILY: Arial"><SPAN=20
  style=3D"mso-spacerun: yes">&nbsp;</SPAN><o:p></o:p></SPAN></FONT></P>
  <P class=3DMsoNormal><FONT face=3D"Arial Narrow" color=3Dmaroon =
size=3D2><SPAN=20
  lang=3DES-MX=20
  style=3D"FONT-SIZE: 10pt; COLOR: maroon; FONT-FAMILY: 'Arial Narrow'; =
mso-ansi-language: ES-MX; mso-no-proof: yes">Miguel=20
  A. Rodriguez</SPAN></FONT><SPAN lang=3DES-MX=20
  style=3D"mso-ansi-language: ES-MX; mso-no-proof: =
yes"><o:p></o:p></SPAN></P>
  <P class=3DMsoNormal><FONT face=3D"Arial Narrow" color=3Dmaroon =
size=3D2><SPAN=20
  lang=3DES-MX=20
  style=3D"FONT-SIZE: 10pt; COLOR: maroon; FONT-FAMILY: 'Arial Narrow'; =
mso-ansi-language: ES-MX; mso-no-proof: yes">Software=20
  Engineer</SPAN></FONT><SPAN lang=3DES-MX=20
  style=3D"mso-ansi-language: ES-MX; mso-no-proof: =
yes"><o:p></o:p></SPAN></P>
  <P class=3DMsoNormal><FONT face=3D"Arial Narrow" color=3Dmaroon =
size=3D2><SPAN=20
  lang=3DES-MX=20
  style=3D"FONT-SIZE: 10pt; COLOR: maroon; FONT-FAMILY: 'Arial Narrow'; =
mso-ansi-language: ES-MX; mso-no-proof: =
yes">SeguriDATA</SPAN></FONT><SPAN=20
  lang=3DES-MX=20
  style=3D"mso-ansi-language: ES-MX; mso-no-proof: =
yes"><o:p></o:p></SPAN></P>
  <P class=3DMsoNormal><FONT face=3D"Times New Roman" size=3D3><SPAN =
lang=3DES-MX=20
  style=3D"FONT-SIZE: 12pt; mso-ansi-language: =
ES-MX"><o:p>&nbsp;</o:p></SPAN></FONT></P></DIV></BLOCKQUOTE></BODY></HTM=
L>

------=_NextPart_000_0135_01C2B827.D8672970--



Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h0A3Q7K15006 for ietf-pkix-bks; Thu, 9 Jan 2003 19:26:07 -0800 (PST)
Received: from mail.coastside.net (mail.coastside.net [207.213.212.6]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h0A3Q3o14978 for <[e-mail]>; Thu, 9 Jan 2003 19:26:04 -0800 (PST)
Received: from MMyersLapTop (ppp213-77.coastside.net [207.213.213.77]) by mail.coastside.net  with SMTP id h0A3Q581005849; Thu, 9 Jan 2003 19:26:06 -0800 (PST)
From: "Michael Myers" <[e-mail]>
To: "Miguel Rodriguez" <[e-mail]>, <[e-mail]>
Subject: RE: OCSP signed requests
Date: Thu, 9 Jan 2003 20:21:23 -0800
Message-ID: <[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0)
Importance: Normal
In-Reply-To: <001001c2b837$a4866b60$[e-mail]>
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Miguel,

Signed OCSP requests enable audit trails and authenticated
service access.  Implementors should produce this capability;
deployers decide on its use.

Mike

-----Original Message-----
From:    Miguel Rodriguez
Sent:    Thursday, January 09, 2003 3:34 PM
Subject: OCSP signed requests


What is the prescribed (or most common) behavior of an OCSP
responder when receiving a signed request? Should the signature
be ignored if it is not required?

Thanks,

Miguel A. Rodriguez
Software Engineer
SeguriDATA




Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h09NYB009523 for ietf-pkix-bks; Thu, 9 Jan 2003 15:34:11 -0800 (PST)
Received: from seguridata1.seguridata.com ([200.57.34.107]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h09NY9o09519 for <[e-mail]>; Thu, 9 Jan 2003 15:34:10 -0800 (PST)
Received: from MarsXP ([148.233.248.105]) by seguridata1.seguridata.com with Microsoft SMTPSVC(5.0.2195.2966); Thu, 9 Jan 2003 17:34:58 -0600
From: "Miguel Rodriguez" <[e-mail]>
To: <[e-mail]>
Subject: OCSP signed requests
Date: Thu, 9 Jan 2003 17:34:18 -0600
Message-ID: <001001c2b837$a4866b60$[e-mail]>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_0011_01C2B805.59EBFB60"
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook, Build 10.0.2627
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106
Importance: Normal
X-OriginalArrivalTime: 09 Jan 2003 23:34:58.0250 (UTC) FILETIME=[B8C622A0:01C2B837]
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

This is a multi-part message in MIME format.

------=_NextPart_000_0011_01C2B805.59EBFB60
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit

What is the prescribed (or most common) behavior of an OCSP responder
when receiving a signed request? Should the signature be ignored if it
is not required? 
 
Thanks,
 
Miguel A. Rodriguez
Software Engineer
SeguriDATA
 

------=_NextPart_000_0011_01C2B805.59EBFB60
Content-Type: text/html;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

<html xmlns:o=3D"urn:schemas-microsoft-com:office:office" =
xmlns:w=3D"urn:schemas-microsoft-com:office:word" =
xmlns=3D"http://www.w3.org/TR/REC-html40">

<head>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Dus-ascii">


<meta name=3DProgId content=3DWord.Document>
<meta name=3DGenerator content=3D"Microsoft Word 10">
<meta name=3DOriginator content=3D"Microsoft Word 10">
<link rel=3DFile-List href=3D"cid:filelist.xml@01C2B805.56704220">
<!--[if gte mso 9]><xml>
 <o:OfficeDocumentSettings>
  <o:DoNotRelyOnCSS/>
 </o:OfficeDocumentSettings>
</xml><![endif]--><!--[if gte mso 9]><xml>
 <w:WordDocument>
  <w:SpellingState>Clean</w:SpellingState>
  <w:GrammarState>Clean</w:GrammarState>
  <w:DocumentKind>DocumentEmail</w:DocumentKind>
  <w:EnvelopeVis/>
  <w:Compatibility>
   <w:BreakWrappedTables/>
   <w:SnapToGridInCell/>
   <w:WrapTextWithPunct/>
   <w:UseAsianBreakRules/>
  </w:Compatibility>
  <w:BrowserLevel>MicrosoftInternetExplorer4</w:BrowserLevel>
 </w:WordDocument>
</xml><![endif]-->
<style>
<!--
 /* Font Definitions */
 @font-face
	{font-family:"Arial Narrow";
	panose-1:2 11 5 6 2 2 2 3 2 4;
	mso-font-charset:0;
	mso-generic-font-family:swiss;
	mso-font-pitch:variable;
	mso-font-signature:647 0 0 0 159 0;}
 /* Style Definitions */
 p.MsoNormal, li.MsoNormal, div.MsoNormal
	{mso-style-parent:"";
	margin:0cm;
	margin-bottom:.0001pt;
	mso-pagination:widow-orphan;
	font-size:12.0pt;
	font-family:"Times New Roman";
	mso-fareast-font-family:"Times New Roman";}
a:link, span.MsoHyperlink
	{color:blue;
	text-decoration:underline;
	text-underline:single;}
a:visited, span.MsoHyperlinkFollowed
	{color:purple;
	text-decoration:underline;
	text-underline:single;}
span.EmailStyle17
	{mso-style-type:personal-compose;
	mso-style-noshow:yes;
	mso-ansi-font-size:10.0pt;
	mso-bidi-font-size:10.0pt;
	font-family:Arial;
	mso-ascii-font-family:Arial;
	mso-hansi-font-family:Arial;
	mso-bidi-font-family:Arial;
	color:windowtext;}
@page Section1
	{size:612.0pt 792.0pt;
	margin:72.0pt 90.0pt 72.0pt 90.0pt;
	mso-header-margin:35.4pt;
	mso-footer-margin:35.4pt;
	mso-paper-source:0;}
div.Section1
	{page:Section1;}
-->
</style>
<!--[if gte mso 10]>
<style>
 /* Style Definitions */=20
 table.MsoNormalTable
	{mso-style-name:"Table Normal";
	mso-tstyle-rowband-size:0;
	mso-tstyle-colband-size:0;
	mso-style-noshow:yes;
	mso-style-parent:"";
	mso-padding-alt:0cm 5.4pt 0cm 5.4pt;
	mso-para-margin:0cm;
	mso-para-margin-bottom:.0001pt;
	mso-pagination:widow-orphan;
	font-size:10.0pt;
	font-family:"Times New Roman";}
</style>
<![endif]-->
</head>

<body lang=3DEN-US link=3Dblue vlink=3Dpurple =
style=3D'tab-interval:36.0pt'>

<div class=3DSection1>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'>What is the prescribed (or most common) behavior of =
an OCSP
responder when receiving a signed request? Should the signature be =
ignored if
it is not required? <o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'>Thanks,<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'><span =
style=3D'mso-spacerun:yes'>&nbsp;</span><o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dmaroon face=3D"Arial =
Narrow"><span
lang=3DES-MX style=3D'font-size:10.0pt;font-family:"Arial =
Narrow";color:maroon;
mso-ansi-language:ES-MX;mso-no-proof:yes'>Miguel A. =
Rodriguez</span></font><span
lang=3DES-MX =
style=3D'mso-ansi-language:ES-MX;mso-no-proof:yes'><o:p></o:p></span></p>=


<p class=3DMsoNormal><font size=3D2 color=3Dmaroon face=3D"Arial =
Narrow"><span
lang=3DES-MX style=3D'font-size:10.0pt;font-family:"Arial =
Narrow";color:maroon;
mso-ansi-language:ES-MX;mso-no-proof:yes'>Software =
Engineer</span></font><span
lang=3DES-MX =
style=3D'mso-ansi-language:ES-MX;mso-no-proof:yes'><o:p></o:p></span></p>=


<p class=3DMsoNormal><font size=3D2 color=3Dmaroon face=3D"Arial =
Narrow"><span
lang=3DES-MX style=3D'font-size:10.0pt;font-family:"Arial =
Narrow";color:maroon;
mso-ansi-language:ES-MX;mso-no-proof:yes'>SeguriDATA</span></font><span
lang=3DES-MX =
style=3D'mso-ansi-language:ES-MX;mso-no-proof:yes'><o:p></o:p></span></p>=


<p class=3DMsoNormal><font size=3D3 face=3D"Times New Roman"><span =
lang=3DES-MX
style=3D'font-size:12.0pt;mso-ansi-language:ES-MX'><o:p>&nbsp;</o:p></spa=
n></font></p>

</div>

</body>

</html>

------=_NextPart_000_0011_01C2B805.59EBFB60--




Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h09GPUw26280 for ietf-pkix-bks; Thu, 9 Jan 2003 08:25:30 -0800 (PST)
Received: from mail1.belgacom.be (mail1.belgacom.be [195.13.15.36]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h09GPSo26276 for <[e-mail]>; Thu, 9 Jan 2003 08:25:29 -0800 (PST)
Received: from exhub01.bc (exchange.bc [45.34.4.231]) by mail1.belgacom.be  with SMTP id QAA22348 for <[e-mail]>; Thu, 9 Jan 2003 16:25:25 GMT
From: [e-mail]
Received: from 127.0.0.1 by exhub01.bc (InterScan E-Mail VirusWall NT); Thu, 09 Jan 2003 17:23:48 +0100
Received: by exhub01.bc with Internet Mail Service (5.5.2653.19) id <CMPHFLKR>; Thu, 9 Jan 2003 17:23:48 +0100
Message-ID: <[e-mail]>
To: [e-mail]
Subject: e-tendering enabler digital certificate
Date: Thu, 9 Jan 2003 17:23:46 +0100 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain; charset="ISO-8859-1"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Dear all,

When answering to call for tenders, sellers should not be judged solely on the price the buyer will be billed for. Usually, a seller provide lots of documents and arguments to provide their ability to win a tender.

I am aware about few initiatives to develop and implement an e-tendering service allowing particularly to automate the process of tender creation by the buyer and bid offer creation by suppliers. The approach of these initiative is to standardize the tender creation language and logic relying on XML and DTD schemas.

I am quite confident in e-tendering since it will particularly allow to promote PKI and and digital certificates but i see that the idea of automating the process of tender creation might be confusing for the buyer and sellers.

My idea to automate efficiently a fair tender winner determination (not relying only on the price proposed by the seller) is to rely on digital certificate with particular attributes. We can consider that terms of seller qualifications (a least few of them) can be standardized and the certification authority issue an "e-tendering enabler" certificate only for those sellers that meets the needed criterions.

I would like to have feedback about my proposal i mean 
- whether there exist actually a similar initiative some where?
- whether you find it is interest idea and subject?
- if there organizations of people currently working on similar idears?

thank you for your feedback,

best regards,

malek.
___________________________________________________________
Malek Bechlaghem
e-Security Product Development Manager
Strategy, Business Development and Product Management (SBP)
Internet Business Unit (IBU)
Belgacom SA/NV
Bd du Roi Albert II, 27, B-1030 Brussels

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

We bring security to the e-world : www.e-trust.be




**** DISCLAIMER **** 
"This e-mail and any attachments thereto may contain information 
which is confidential and/or protected by intellectual property 
rights and are intended for the sole use of the recipient(s) named above. 
Any use of the information contained herein (including, but not limited to, 
total or partial reproduction, communication or distribution in any form) 
by persons other than the designated recipient(s) is prohibited. 
If you have received this e-mail in error, please notify the sender either 
by telephone or by e-mail and delete the material from any computer. 
Thank you for your cooperation."



Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h09A6qS02360 for ietf-pkix-bks; Thu, 9 Jan 2003 02:06:52 -0800 (PST)
Received: from mailb.telia.com (mailb.telia.com [194.22.194.6]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h09A6po02356 for <[e-mail]>; Thu, 9 Jan 2003 02:06:51 -0800 (PST)
Received: from arport (h119n2fls31o1122.telia.com [212.181.142.119]) by mailb.telia.com (8.12.5/8.12.5) with SMTP id h09A6pht027919 for <[e-mail]>; Thu, 9 Jan 2003 11:06:51 +0100 (CET)
X-Original-Recipient: <[e-mail]>
Message-ID: <006901c2b7c6$8d33b920$0500a8c0@arport>
From: "Anders Rundgren" <[e-mail]>
To: <[e-mail]>
References: <[e-mail]>
Subject: Re: I-D ACTION:draft-ietf-pkix-warranty-extn-02.txt
Date: Thu, 9 Jan 2003 11:04:51 +0100
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.50.4133.2400
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

I would be happy to get some response from the "infrastructure
deployment experts" of the PKIX WG on how you look at the
software question. 
Ref: http://www.imc.org/ietf-pkix/mail-archive/msg05348.html
If this question is out of scope, please let me know.

>From the authors' I would be happy to get feedback on:
http://www.imc.org/ietf-pkix/mail-archive/msg05349.html
As VeriSign talks about "Limited liability warranty" it
seems that these terms are intimately associated in the
context of compensation for _indirect_ damages caused
by faulty products...

cheers,
Anders

----- Original Message ----- 
From: <[e-mail]>
To: <IETF-Announce:>
Cc: <[e-mail]>
Sent: Tuesday, January 07, 2003 14:30
Subject: I-D ACTION:draft-ietf-pkix-warranty-extn-02.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 : Warranty Certificate Extension
Author(s) : D. Linsenbardt, S. Pontius, A. Sturgeon
Filename : draft-ietf-pkix-warranty-extn-02.txt
Pages : 7
Date : 2003-1-6

This document describes a certificate extension to explicitly state
the warranty offered by a Certificate Authority (CA) for a the
certificate containing the extension.

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

To remove yourself from the IETF Announcement list, send a message to 
ietf-announce-request with the word unsubscribe in the body of the message.

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-warranty-extn-02.txt".

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


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

Send a message to:
[e-mail].
In the body type:
"FILE /internet-drafts/draft-ietf-pkix-warranty-extn-02.txt".

NOTE: The mail server at ietf.org can return the document in
MIME-encoded form by using the "mpack" utility.  To use this
feature, insert the command "ENCODING mime" before the "FILE"
command.  To decode the response(s), you will need "munpack" or
a MIME-compliant mail reader.  Different MIME-compliant mail readers
exhibit different behavior, especially when dealing with
"multipart" MIME messages (i.e. documents which have been split
up into multiple messages), so check your local documentation on
how to manipulate these messages.


Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.




Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h098jb322670 for ietf-pkix-bks; Thu, 9 Jan 2003 00:45:37 -0800 (PST)
Received: from host8.successfulhosting.com (host8.successfulhosting.com [209.239.36.32]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h098jao22659 for <[e-mail]>; Thu, 9 Jan 2003 00:45:36 -0800 (PST)
Received: from ascertiacompaq ([203.81.197.48]) by host8.successfulhosting.com (8.10.2/8.10.2) with SMTP id h098jaN26096 for <[e-mail]>; Thu, 9 Jan 2003 03:45:37 -0500
Message-ID: <003701c2b7ba$521a71a0$2400a8c0@ascertiacompaq>
From: "Liaquat Khan" <[e-mail]>
To: "Ietf-Pkix@Imc. Org" <[e-mail]>
Subject: question on OCSP
Date: Thu, 9 Jan 2003 08:36:10 -0000
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_0034_01C2B7BA.29480120"
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2600.0000
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

This is a multi-part message in MIME format.

------=_NextPart_000_0034_01C2B7BA.29480120
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Hi,

According to Item 3 of Section 3.2 of RFC2560, OCSP clients should =
confirm that "the identity of the signer matches the intended recipient =
of the request" before accepting a signed OCSP response.=20

Can I ask how this can be achieved by the client? It is not quite as =
simple as it seems, since the OCSP client may not know the identity of =
the OCSP responder in advance, but only have an address of where the =
OCSP responder is located (e.g. from the AIA extension of the =
certificate whose revocation status is being checked).=20

Thanks and my apologies if this has already been covered before.=20

Regards,

Liaquat Khan=20


------=_NextPart_000_0034_01C2B7BA.29480120
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 http-equiv=3DContent-Type content=3D"text/html; =
charset=3Diso-8859-1">
<META content=3D"MSHTML 6.00.2600.0" name=3DGENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=3D#ffffff>
<DIV><FONT face=3DArial size=3D2><FONT size=3D2>
<P>Hi,</P>
<P>According to Item 3 of Section 3.2 of RFC2560, OCSP clients should =
confirm=20
that "the identity of the signer matches the intended recipient of the =
request"=20
before accepting a signed OCSP response. </P>
<P>Can I ask how this can be achieved by the client? It is not quite as =
simple=20
as it seems, since the OCSP client may not know the identity of the OCSP =

responder in advance, but only have an address of where the OCSP =
responder is=20
located (e.g. from the AIA extension of the certificate whose revocation =
status=20
is being checked). </P>
<P>Thanks and my apologies if this has already been covered before. </P>
<P>Regards,</P>
<P>Liaquat Khan </P></FONT></FONT></DIV></BODY></HTML>

------=_NextPart_000_0034_01C2B7BA.29480120--



Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h08M9uA20063 for ietf-pkix-bks; Wed, 8 Jan 2003 14:09:56 -0800 (PST)
Received: from maynard.mail.mindspring.net (maynard.mail.mindspring.net [207.69.200.243]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h08M9so20059 for <[e-mail]>; Wed, 8 Jan 2003 14:09:55 -0800 (PST)
Received: from user-0c8h20e.cable.mindspring.com ([24.136.136.14] helo=asn-1.com) by maynard.mail.mindspring.net with esmtp (Exim 3.33 #1) id 18WONz-0000Ba-00; Wed, 08 Jan 2003 17:09:19 -0500
Message-ID: <[e-mail]>
Date: Wed, 08 Jan 2003 17:08:26 -0500
From: "Phillip H. Griffin" <[e-mail]>
Organization: http://asn-1.com
User-Agent: Mozilla/5.0 (Windows; U; Win 9x 4.90; en-US; rv:1.0.1) Gecko/20020823 Netscape/7.0
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Tony Bartoletti <[e-mail]>
CC: Peter Gutmann <[e-mail]>, [e-mail], [e-mail], [e-mail], [e-mail]
Subject: Re: OCSP and LDAP
References: <[e-mail]>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Well, you guys are all much smarter than I am.

I used to think I knew a lot about Directory, then I attended a
few meetings. I figured that since I was pretty clever in my
understanding of the abstract syntax and notation that I
probably had a major leg up. I figured that directory was
just another term for database.

I figured that by having implemented shttp and early ssl in C
and the first code ever (I think) to issue a v1 certificate at IBM,
that maybe I had a clue. Turns out that just about an hour in a
Directory meeting is enough to make your hat fit better.

Extremely smart people involved. And they're probably not
working on what most folks think they are.

Phil




Tony Bartoletti wrote:

>
> At 06:52 PM 1/8/2003 +1300, Peter Gutmann wrote:
>
>> Other person: "Why is X.500 so special?  Why is no-one else doing this?"
>>
>> Me: "Get your favourite book on database technology and look up
>>      'Hierarchical databases'".
>>
>> [Time passes]
>>
>> Other person: "I looked in several books.  Many didn't mention it at 
>> all,
>>                and one had a half-page historical note saying it's 
>> something
>>                that was obsoleted by better technology more than two 
>> decades
>>                ago".
>>
>> Me: "Exactly".
>
>
>
> Heh.  Actually, hierarchical databases can be superlative to most all 
> other technologies, when one has a static taxonomy to support.  Trying 
> to represent (no less manage) a dynamically changing global namespace 
> with scores of independent geopolitical naming authorities with a 
> hierarchical database is rather ... ridiculous. :)
>
> Cheers!  ____tony____
>
>




Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h08L1lc18580 for ietf-pkix-bks; Wed, 8 Jan 2003 13:01:47 -0800 (PST)
Received: from maild.telia.com (maild.telia.com [194.22.190.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h08L1ho18574 for <[e-mail]>; Wed, 8 Jan 2003 13:01:44 -0800 (PST)
Received: from arport (h119n2fls31o1122.telia.com [212.181.142.119]) by maild.telia.com (8.12.5/8.12.5) with SMTP id h08L14UU018997; Wed, 8 Jan 2003 22:01:05 +0100 (CET)
X-Original-Recipient: [e-mail]
Message-ID: <011e01c2b758$c94e9290$0500a8c0@arport>
From: "Anders Rundgren" <[e-mail]>
To: "Peter Gutmann" <[e-mail]>, <[e-mail]>, "Tony Bartoletti" <[e-mail]>
Cc: <[e-mail]>, <[e-mail]>
References: <[e-mail]>
Subject: Re: OCSP and LDAP
Date: Wed, 8 Jan 2003 21:58:56 +0100
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_011B_01C2B761.24499CF0"
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.50.4133.2400
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

This is a multi-part message in MIME format.

------=_NextPart_000_011B_01C2B761.24499CF0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

>Heh.  Actually, hierarchical databases can be superlative to most all =
other=20
>technologies, when one has a static taxonomy to support.  Trying to=20
>represent (no less manage) a dynamically changing global namespace with =

>scores of independent geopolitical naming authorities with a =
hierarchical=20
>database is rather ... ridiculous. :)

Tony,
You are right!  You may be pleased to know that a remedy is in =
preparation
in the form of an I-D where the following extract addresses the =
situation mentioned.
/Anders

              Plug-and-Play Certificates for Web Services

1. Introduction and rationale

   To combine PKI with "Web Services" on a global scale presents a
   challenge, as it requires Relying Parties (RPs) to process signed
   messages possibly emanating from many different PKIs, while
   preferably using a unified RP PKI software- and user-interface.
   In the web-browser environment, global interoperability is only
   achieved due to the fact that web-server certificates supporting
   HTTPS [6], are based on a static ("hard-coded") profile [7],
   which is a prerequisite by browsers to correctly interpret such
   certificates.  To further simplify usage, most commercial CAs'
   root-certificates are already pre-installed in leading browsers.

   However, "Web Services" can unlike web-browsers, not depend on
   static PKI-schemes and pre-installed root-certificates, as this
   would severely limit the kind of entity-types and certificate-
   profiles that would be possible for RPs to accept.

   This specification introduces a CA-certificate-based, non-critical
   X.509 v3 extension, from now on referred to as a "PnP-descriptor",
   that works like an additional "specification" for associated End
   Entity (EE)-certificates.  The following introductory sections
   describe how this extension can support a more dynamic PKI-based
   ecosystem, by removing some major hurdles to wide-scale PKI usage.

1.1 Globally unique subject DNs

   The aforementioned Web-server certificates, contain globally unique
   subject Distinguished Names (DNs) [8] due to the fact that they
   certify Domain Name System (DNS) [9] host-names.

   However, for non-DNS-based entities, few existing certificate-
   profiles as well as RFC3280 [10] and RFC3039 [11] require subject
   DNs to be globally unique.  This may lead to possible name-clashes
   when multiple non-coordinated PKIs are to be handled by RPs.  One
   way to cope with this is to associate each CA-certificate with a
   unique "virtual" name-space.  This complicates CA-certificate
   renewals with respect to RPs, as well as making it more difficult to
   efficiently explore common certificate-profiles and associated
   naming-domains shared by multiple CAs (exemplified by many national
   ID-schemes), as both these scenarios require manual and error-prone
   RP configuration to work.  Requiring CAs to deploy globally unique
   subject DNs by for example adding Domain Components (DCs) [8] is
   likely to be less popular, as well as breaking some existing RP
   software.

   The PnP-descriptor therefore supports an explicit naming-domain in
   the form of a Universal Resource Identifier (URI) [12]. Due to the
   two-level naming structure, the PnP-descriptor provides global
   uniqueness to any existing or future non-empty subject DN scheme.
   Below is a figure, illustrating the two-level naming system.
             ____
            /    \
           |  CA  |<--- PnP Naming domain:
            \____/      http://www.sampleregistry.org/members
            /    \
           /      \
          |       _\__
          |      /    \
          |     |  EE  | CN=3DJohn Doe, serialNumber=3D43155, C=3DUS
          |      \____/
          |
         _|__
        /    \
       |  EE  | CN=3DMarion Anderson, serialNumber=3D43566, C=3DUS
        \____/

   That is, Marion's fully canonicalized name could be expressed like

       "http://www.sampleregistry.org/members" :
       "CN=3DMarion Anderson, serialNumber=3D43566, C=3DUS"

   Note: Canonicalization syntax is outside of this specification as it
   is mostly a disadvantage to merge naming domain and subject DN in a
   real application.



------=_NextPart_000_011B_01C2B761.24499CF0
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.3103.1000" name=3DGENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY>
<DIV><FONT face=3DArial size=3D2>&gt;Heh.&nbsp; Actually, hierarchical =
databases can=20
be superlative to most all other <BR>&gt;technologies, when one has a =
static=20
taxonomy to support.&nbsp; Trying to <BR>&gt;represent (no less manage) =
a=20
dynamically changing global namespace with <BR>&gt;scores of independent =

geopolitical naming authorities with a hierarchical <BR>&gt;database is =
rather=20
... ridiculous. :)</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>Tony,</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>You are right!&nbsp; You may be pleased =
to know=20
that a remedy is in preparation</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>in the form of an I-D where the =
following extract=20
addresses the situation mentioned.</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>/Anders<BR></FONT><FONT face=3D"Courier =
New"=20
size=3D1><FONT face=3DArial size=3D2></FONT></FONT></DIV>
<DIV><FONT face=3D"Courier New" size=3D1><FONT face=3DArial=20
size=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp;=20
Plug-and-Play Certificates for Web Services</FONT></FONT></DIV>
<DIV><FONT face=3D"Courier New" size=3D1></FONT>&nbsp;</DIV>
<DIV><FONT face=3D"Courier New" size=3D1>1. Introduction and =
rationale</FONT></DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT face=3D"Courier New" size=3D1>&nbsp;&nbsp; To combine PKI =
with "Web=20
Services" on a global scale presents a<BR>&nbsp;&nbsp; challenge, as it =
requires=20
Relying Parties (RPs) to process signed<BR>&nbsp;&nbsp; messages =
possibly=20
emanating from many different PKIs, while<BR>&nbsp;&nbsp; preferably =
using a=20
unified RP PKI software- and user-interface.<BR>&nbsp;&nbsp; In the =
web-browser=20
environment, global interoperability is only<BR>&nbsp;&nbsp; achieved =
due to the=20
fact that web-server certificates supporting<BR>&nbsp;&nbsp; HTTPS [6], =
are=20
based on a static ("hard-coded") profile [7],<BR>&nbsp;&nbsp; which is a =

prerequisite by browsers to correctly interpret such<BR>&nbsp;&nbsp;=20
certificates.&nbsp; To further simplify usage, most commercial=20
CAs'<BR>&nbsp;&nbsp; root-certificates are already pre-installed in =
leading=20
browsers.</FONT></DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT face=3D"Courier New" size=3D1>&nbsp;&nbsp; However, "Web =
Services" can=20
unlike web-browsers, not depend on<BR>&nbsp;&nbsp; static PKI-schemes =
and=20
pre-installed root-certificates, as this<BR>&nbsp;&nbsp; would severely =
limit=20
the kind of entity-types and certificate-<BR>&nbsp;&nbsp; profiles that =
would be=20
possible for RPs to accept.</FONT></DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT face=3D"Courier New" size=3D1>&nbsp;&nbsp; This specification =
introduces=20
a CA-certificate-based, non-critical<BR>&nbsp;&nbsp; X.509 v3 extension, =
from=20
now on referred to as a "PnP-descriptor",<BR>&nbsp;&nbsp; that works =
like an=20
additional "specification" for associated End<BR>&nbsp;&nbsp; Entity=20
(EE)-certificates.&nbsp; The following introductory =
sections<BR>&nbsp;&nbsp;=20
describe how this extension can support a more dynamic =
PKI-based<BR>&nbsp;&nbsp;=20
ecosystem, by removing some major hurdles to wide-scale PKI =
usage.</FONT></DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT face=3D"Courier New" size=3D1>1.1 Globally unique subject=20
DNs</FONT></DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT face=3D"Courier New" size=3D1>&nbsp;&nbsp; The aforementioned =
Web-server=20
certificates, contain globally unique<BR>&nbsp;&nbsp; subject =
Distinguished=20
Names (DNs) [8] due to the fact that they<BR>&nbsp;&nbsp; certify Domain =
Name=20
System (DNS) [9] host-names.</FONT></DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT face=3D"Courier New" size=3D1>&nbsp;&nbsp; However, for =
non-DNS-based=20
entities, few existing certificate-<BR>&nbsp;&nbsp; profiles as well as =
RFC3280=20
[10] and RFC3039 [11] require subject<BR>&nbsp;&nbsp; DNs to be globally =

unique.&nbsp; This may lead to possible name-clashes<BR>&nbsp;&nbsp; =
when=20
multiple non-coordinated PKIs are to be handled by RPs.&nbsp;=20
One<BR>&nbsp;&nbsp; way to cope with this is to associate each =
CA-certificate=20
with a<BR>&nbsp;&nbsp; unique "virtual" name-space.&nbsp; This =
complicates=20
CA-certificate<BR>&nbsp;&nbsp; renewals with respect to RPs, as well as =
making=20
it more difficult to<BR>&nbsp;&nbsp; efficiently explore common=20
certificate-profiles and associated<BR>&nbsp;&nbsp; naming-domains =
shared by=20
multiple CAs (exemplified by many national<BR>&nbsp;&nbsp; ID-schemes), =
as both=20
these scenarios require manual and error-prone<BR>&nbsp;&nbsp; RP =
configuration=20
to work.&nbsp; Requiring CAs to deploy globally unique<BR>&nbsp;&nbsp; =
subject=20
DNs by for example adding Domain Components (DCs) [8] is<BR>&nbsp;&nbsp; =
likely=20
to be less popular, as well as breaking some existing RP<BR>&nbsp;&nbsp; =

software.</FONT></DIV>
<DIV><BR><FONT face=3D"Courier New" size=3D1>&nbsp;&nbsp; The =
PnP-descriptor=20
therefore supports an explicit naming-domain in<BR>&nbsp;&nbsp; the form =
of a=20
Universal Resource Identifier (URI) [12]. Due to the<BR>&nbsp;&nbsp; =
two-level=20
naming structure, the PnP-descriptor provides global<BR>&nbsp;&nbsp; =
uniqueness=20
to any existing or future non-empty subject DN scheme.<BR>&nbsp;&nbsp; =
Below is=20
a figure, illustrating the two-level naming=20
system.<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;=20
____<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;=20
/&nbsp;&nbsp;&nbsp;=20
\<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
|&nbsp;=20
CA&nbsp; |&lt;--- PnP Naming=20
domain:<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;=20
\____/&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; </FONT><A=20
href=3D"http://www.sampleregistry.org/members"><FONT face=3D"Courier =
New"=20
size=3D1>http://www.sampleregistry.org/members</FONT></A><BR><FONT=20
face=3D"Courier New"=20
size=3D1>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;=20
/&nbsp;&nbsp;&nbsp;=20
\<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
/&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
\<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
_\__<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; /&nbsp;&nbsp;&nbsp;=20
\<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
|&nbsp;&nbsp;&nbsp;&nbsp; |&nbsp; EE&nbsp; | CN=3DJohn Doe, =
serialNumber=3D43155,=20
C=3DUS<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
\____/<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
|<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
_|__<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; /&nbsp;&nbsp;&nbsp;=20
\<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; |&nbsp; EE&nbsp; | CN=3DMarion =
Anderson,=20
serialNumber=3D43566, =
C=3DUS<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
\____/</FONT></DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT face=3D"Courier New" size=3D1>&nbsp;&nbsp; That is, Marion's =
fully=20
canonicalized name could be expressed like</FONT></DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT face=3D"Courier New" =
size=3D1>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
"</FONT><A href=3D"http://www.sampleregistry.org/members"><FONT =
face=3D"Courier New"=20
size=3D1>http://www.sampleregistry.org/members</FONT></A><FONT =
face=3D"Courier New"=20
size=3D1>" :<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; "CN=3DMarion =
Anderson,=20
serialNumber=3D43566, C=3DUS"</FONT></DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT face=3D"Courier New" size=3D1>&nbsp;&nbsp; Note: =
Canonicalization syntax=20
is outside of this specification as it<BR>&nbsp;&nbsp; is mostly a =
disadvantage=20
to merge naming domain and subject DN in a<BR>&nbsp;&nbsp; real=20
application.</FONT></DIV>
<DIV>&nbsp;</DIV>
<DIV>&nbsp;</DIV></BODY></HTML>

------=_NextPart_000_011B_01C2B761.24499CF0--



Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h08K21G16855 for ietf-pkix-bks; Wed, 8 Jan 2003 12:02:01 -0800 (PST)
Received: from smtp-2.llnl.gov (smtp-2.llnl.gov [128.115.250.82]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h08K20o16851 for <[e-mail]>; Wed, 8 Jan 2003 12:02:00 -0800 (PST)
Received: from poptop.llnl.gov (localhost [127.0.0.1]) by smtp-2.llnl.gov (8.9.3/8.9.3/LLNL-gateway-1.0) with ESMTP id MAA03623; Wed, 8 Jan 2003 12:00:58 -0800 (PST)
Received: from [128.115.222.68] (HELO catalyst2b.llnl.gov) by poptop.llnl.gov (CommuniGate Pro SMTP 3.5.9) with ESMTP id 8842067; Wed, 08 Jan 2003 12:01:01 -0800
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Version 5.0
Date: Wed, 08 Jan 2003 12:01:44 -0800
To: [e-mail] (Peter Gutmann), [e-mail], [e-mail]
From: Tony Bartoletti <[e-mail]>
Subject: Re: OCSP and LDAP
Cc: [e-mail], [e-mail]
In-Reply-To: <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

At 06:52 PM 1/8/2003 +1300, Peter Gutmann wrote:

>Other person: "Why is X.500 so special?  Why is no-one else doing this?"
>
>Me: "Get your favourite book on database technology and look up
>      'Hierarchical databases'".
>
>[Time passes]
>
>Other person: "I looked in several books.  Many didn't mention it at all,
>                and one had a half-page historical note saying it's something
>                that was obsoleted by better technology more than two decades
>                ago".
>
>Me: "Exactly".


Heh.  Actually, hierarchical databases can be superlative to most all other 
technologies, when one has a static taxonomy to support.  Trying to 
represent (no less manage) a dynamically changing global namespace with 
scores of independent geopolitical naming authorities with a hierarchical 
database is rather ... ridiculous. :)

Cheers!  ____tony____



Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h08FwDb10161 for ietf-pkix-bks; Wed, 8 Jan 2003 07:58:13 -0800 (PST)
Received: from mail.inka.de ([e-mail] [193.197.184.2]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h08FwBo10156 for <[e-mail]>; Wed, 8 Jan 2003 07:58:12 -0800 (PST)
Received: from nb2.stroeder.com (puric.inka.de [193.197.184.17]) by mail.inka.de with esmtp  id 18WIal-0005cP-00; Wed, 08 Jan 2003 16:58:07 +0100
Received: from localhost (localhost [127.0.0.1]) by nb2.stroeder.com (Postfix) with ESMTP id B7CF039426; Wed,  8 Jan 2003 16:58:05 +0100 (CET)
Received: from stroeder.com (localhost [127.0.0.1]) by nb2.stroeder.com (Postfix) with ESMTP id 92DCF3480A; Wed,  8 Jan 2003 16:58:04 +0100 (CET)
Message-ID: <[e-mail]>
Date: Wed, 08 Jan 2003 16:58:04 +0100
From: =?ISO-8859-1?Q?Michael_Str=F6der?= <[e-mail]>
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.2.1) Gecko/20021130
X-Accept-Language: de-de, de, en-us, en
MIME-Version: 1.0
To: Peter Gutmann <[e-mail]>
Cc: [e-mail]
Subject: Re: I-D ACTION:draft-ietf-pkix-certstore-http-03.txt
References: <[e-mail]>
In-Reply-To: <[e-mail]>
X-Enigmail-Version: 0.71.0.0
X-Enigmail-Supports: pgp-inline, pgp-mime
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
X-Virus-Scanned: by AMaViS 0.3.12pre8
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Peter Gutmann wrote:
> 
> I've actually reworded it to use mostly a very generic "email address
> associated with the cert" (someone pointed out that there doesn't actually
> have to be an email address in the cert for it to be associated with one). The
> intent was never to provide an exhaustive enumeration of all possible places
> it could be hidden, just to say that it was whatever address(es) were
> associated with the cert.

Which is perfectly right since the draft specifies a simple query interface
and (hopefully) nothing else.

Ciao, Michael.



Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h08Cv0k00687 for ietf-pkix-bks; Wed, 8 Jan 2003 04:57:00 -0800 (PST)
Received: from nymelsmtp.internet.ny.fdms.firstdata.com (nymelsmtp01.firstdata.com [198.184.0.23]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h08Cuwo00683 for <[e-mail]>; Wed, 8 Jan 2003 04:56:59 -0800 (PST)
Subject: Re: OCSP and LDAP
To: [e-mail] (Peter Gutmann)
Cc: [e-mail], [e-mail], [e-mail]
X-Mailer: Lotus Notes Release 5.0.5  September 22, 2000
Message-ID: <[e-mail]>
From: [e-mail]
Date: Wed, 8 Jan 2003 05:51:10 -0700
X-MIMETrack: Serialize by Router on NYMELSMTP/NY/FDMS/FDC(Release 5.0.8 |June 18, 2001) at 01/08/2003 07:58:52 AM
MIME-Version: 1.0
Content-type: text/plain; charset=us-ascii
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

total trivia:
from the previous aadsm5 references to:
http://www.garlic.com/~lynn/95.html#13

two of the people in the conference room went on to the small client/server
startup involved in this thing called SSL & HTTPS ... one had been involved
in the tech. transfer from SJR to Endicott for SQL/DS and one had been
involved in the tech transfer from Endicott to STL for DB2.

Of all the people in the meeting .... I believe only one is still working
for the same employer they were then ... and that case isn't exactly
considered employee ... most recently there has been some stuff about him
getting ready to compete with some sailing team from "down under".

--
Internet trivia, 20th anv: http://www.garlic.com/~lynn/rfcietff.htm



Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h08CbhT29819 for ietf-pkix-bks; Wed, 8 Jan 2003 04:37:43 -0800 (PST)
Received: from nymelsmtp.internet.ny.fdms.firstdata.com (nymelsmtp01.firstdata.com [198.184.0.23]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h08Cbfo29815 for <[e-mail]>; Wed, 8 Jan 2003 04:37:41 -0800 (PST)
Subject: Re: OCSP and LDAP
To: [e-mail] (Peter Gutmann)
Cc: [e-mail], [e-mail], [e-mail]
X-Mailer: Lotus Notes Release 5.0.5  September 22, 2000
Message-ID: <[e-mail]>
From: [e-mail]
Date: Wed, 8 Jan 2003 05:37:17 -0700
X-MIMETrack: Serialize by Router on NYMELSMTP/NY/FDMS/FDC(Release 5.0.8 |June 18, 2001) at 01/08/2003 07:39:35 AM
MIME-Version: 1.0
Content-type: text/plain; charset=us-ascii
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

on the other hand ... there some book someplace that makes the claim that
relational set the state-of-the-art back 20 years.

I was somewhat involved having done some support infrastructure for
system/r and then involved in the technology transfer of system/r from sjr
to endicott for sql/ds (before the technology transfer back from endicott
to stl for db2 .... note that SJR/bld28 & STL/bld90 are like 10 miles apart
.... with both SRJ/STL on the west coast and endicott nearly on the east
coast).

slightly related:
http://www.garlic.com/~lynn/aadsm5.htm#asrn2
http://www.garlic.com/~lynn/aadsm5.htm#asrn3

some archeological tales:
http://www.garlic.com/~lynn/2000.html#18 Computer of the century
http://www.garlic.com/~lynn/2000b.html#29 20th March 2000
http://www.garlic.com/~lynn/2000b.html#55 Multics dual-page-size scheme
http://www.garlic.com/~lynn/2000e.html#49 How did Oracle get started?
http://www.garlic.com/~lynn/2001d.html#44 IBM was/is: Imitation...
http://www.garlic.com/~lynn/2001k.html#5 OT - Internet Explorer V6.0
http://www.garlic.com/~lynn/2002.html#10 index searching
http://www.garlic.com/~lynn/2002e.html#44 SQL wildcard origins?
http://www.garlic.com/~lynn/2002g.html#60 Amiga Rexx
http://www.garlic.com/~lynn/2002h.html#17 disk write caching (was: ibm
icecube -- return of
http://www.garlic.com/~lynn/2002i.html#69 Hercules and System/390 - do we
need it?
http://www.garlic.com/~lynn/2002k.html#8 Avoiding JCL Space Abends
http://www.garlic.com/~lynn/2002k.html#9 Avoiding JCL Space Abends
http://www.garlic.com/~lynn/2002l.html#71 Faster seeks (was Re: Do any
architectures use instruction
http://www.garlic.com/~lynn/2002n.html#36 VR vs. Portable Computing
http://www.garlic.com/~lynn/2002o.html#54 XML, AI, Cyc, psych, and
literature
http://www.garlic.com/~lynn/2002q.html#32 Collating on the S/360-2540 card
reader?
--
Internet trivia, 20th anv: http://www.garlic.com/~lynn/rfcietff.htm


[e-mail] on 1/7/2003 10:52 pm wrote:

I've used that explanation too :-).  The conversion went something like
this:

Other person: "Why is X.500 so special?  Why is no-one else doing this?"

Me: "Get your favourite book on database technology and look up
     'Hierarchical databases'".

[Time passes]

Other person: "I looked in several books.  Many didn't mention it at all,
               and one had a half-page historical note saying it's
something
               that was obsoleted by better technology more than two
decades
               ago".

Me: "Exactly".

Peter.





Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h08A8UZ17645 for ietf-pkix-bks; Wed, 8 Jan 2003 02:08:30 -0800 (PST)
Received: from mta03-svc.ntlworld.com (mta03-svc.ntlworld.com [62.253.162.43]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h08A8To17639 for <[e-mail]>; Wed, 8 Jan 2003 02:08:29 -0800 (PST)
Received: from f67j40j ([213.106.136.127]) by mta03-svc.ntlworld.com (InterMail vM.4.01.03.27 201-229-121-127-20010626) with SMTP id <20030108100826.NZCK4699.mta03-svc.ntlworld.com@f67j40j> for <[e-mail]>; Wed, 8 Jan 2003 10:08:26 +0000
From: "Marc Poulaud" <[e-mail]>
To: <[e-mail]>
Subject: RE: Onus on Registration
Date: Wed, 8 Jan 2003 10:08:12 -0000
MIME-Version: 1.0
Message-ID: <[e-mail]>
Content-Type: multipart/signed; micalg=SHA1; protocol="application/x-pkcs7-signature"; boundary="----=_NextPart_000_0029_01C2B6FD.D81F3460"
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0)
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106
Importance: Normal
In-Reply-To: <[e-mail]>
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

This is a multi-part message in MIME format.

------=_NextPart_000_0029_01C2B6FD.D81F3460
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit

Jim,

Can you give some more details as to what you mean exactly.

The scheme known as Identrus requires an RP to register (a customer
agreement and certificate requests) for what amounts to an
organi[sz]ational certificate. This is partly to do with participating in
a closed scheme but also to use the org certificate for signing validation
requests (of a subscribing customer's certificate) to its financial
institution.

Marc.
-----Original Message-----
From: [e-mail]
[mailto:[e-mail]]On Behalf Of jim
Sent: 08 January 2003 01:16
To: [e-mail]
Subject: Onus on Registration



Does anyone have any sample PK installation that they know of where the
onus for registration was placed on the relying party using
organizational certificates.  There is a chance that an organization
will undertake such a path and I have been asked to find out if anyone
else has done it.

Jim Heimberg, ABC, Ph.D.


------=_NextPart_000_0029_01C2B6FD.D81F3460
Content-Type: application/x-pkcs7-signature;
	name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment;
	filename="smime.p7s"

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIKITCCAj0w
ggGmAhEAzbp/VvDf5LxU/iKss3KqVTANBgkqhkiG9w0BAQIFADBfMQswCQYDVQQGEwJVUzEXMBUG
A1UEChMOVmVyaVNpZ24sIEluYy4xNzA1BgNVBAsTLkNsYXNzIDEgUHVibGljIFByaW1hcnkgQ2Vy
dGlmaWNhdGlvbiBBdXRob3JpdHkwHhcNOTYwMTI5MDAwMDAwWhcNMjgwODAxMjM1OTU5WjBfMQsw
CQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xNzA1BgNVBAsTLkNsYXNzIDEgUHVi
bGljIFByaW1hcnkgQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkwgZ8wDQYJKoZIhvcNAQEBBQADgY0A
MIGJAoGBAOUZv22jVmEtmUhx9mfeuY3rt56GgAqRDvo4Ja9GiILlc6igmyRdDR/MZW4MsNBWhBiH
mgabEKFz37RYOWtuwfYV1aioP6oSBo0xrH+wNNePNGeICc0UEeJORVZpH3gCgNrcR5EpuzbJY1zF
4Ncth3uhtzKwezC6Ki8xqu6jZ9rbAgMBAAEwDQYJKoZIhvcNAQECBQADgYEATD+4i8Zo3+5DMw5d
6abLB4RNejP/khv0Nq3YlSI2aBFsfELM85wuxAc/FLAPT/+Qknb54rxK6Y/NoIAK98Up8YIiXbix
3YEjo3slFUYweRb46gVLlH8dwhzI47f0EEA8E8NfH1PoSOSGtHuhNbB7Jbq4046rPzidADQAmPPR
cZQwggNiMIICy6ADAgECAhAL2gsXwT+JjqsJdHq0zi4zMA0GCSqGSIb3DQEBAgUAMF8xCzAJBgNV
BAYTAlVTMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjE3MDUGA1UECxMuQ2xhc3MgMSBQdWJsaWMg
UHJpbWFyeSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTAeFw05ODA1MTIwMDAwMDBaFw0wODA1MTIy
MzU5NTlaMIHMMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1
c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNv
cnAuIEJ5IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xhc3MgMSBDQSBJ
bmRpdmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkMIGfMA0GCSqGSIb3DQEB
AQUAA4GNADCBiQKBgQC7WkSKBBa7Vf0DeootlE8VeDa4DUqyb5xUv7zodyqdufBou5XZMUFweoFL
uUgTVi3HCOGEQqvAopKrRFyqQvCCDgLpL/vCO7u+yScKXbawNkIztW5UiE+HSr8Z2vkV6A+Hthzj
zMaajn9qJJLj/OBluqexfu/J2zdqyErICQbkmQIDAQABo4GwMIGtMA8GA1UdEwQIMAYBAf8CAQAw
RwYDVR0gBEAwPjA8BgtghkgBhvhFAQcBATAtMCsGCCsGAQUFBwIBFh93d3cudmVyaXNpZ24uY29t
L3JlcG9zaXRvcnkvUlBBMDEGA1UdHwQqMCgwJqAkoCKGIGh0dHA6Ly9jcmwudmVyaXNpZ24uY29t
L3BjYTEuY3JsMAsGA1UdDwQEAwIBBjARBglghkgBhvhCAQEEBAMCAQYwDQYJKoZIhvcNAQECBQAD
gYEAAn2eb0VLOKC43ulTZCG85Ewrjx7+kkCs2Ao5aqEyISwHm6tZ/tJiGn1VOLA3c9z0B2ZjYr3h
U3BSh+eo2FLpWy2q4d7PrDFU1IsZyNgjqO8EKzJ9LBgcyHyJqC538kTRZQpNdLXu0xuSc3QuiTs1
E3LnQDGa07LEq+dWvovj+xUwggR2MIID36ADAgECAhB/l4yg+FrgmGLkay+Z3cRwMA0GCSqGSIb3
DQEBBAUAMIHMMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1
c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNv
cnAuIEJ5IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xhc3MgMSBDQSBJ
bmRpdmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkMB4XDTAyMTAwNzAwMDAw
MFoXDTAzMTAwNzIzNTk1OVowggEaMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMW
VmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0
b3J5L1JQQSBJbmNvcnAuIGJ5IFJlZi4sTElBQi5MVEQoYyk5ODEeMBwGA1UECxMVUGVyc29uYSBO
b3QgVmFsaWRhdGVkMTQwMgYDVQQLEytEaWdpdGFsIElEIENsYXNzIDEgLSBNaWNyb3NvZnQgRnVs
bCBTZXJ2aWNlMRUwEwYDVQQDFAxNYXJjIFBvdWxhdWQxKTAnBgkqhkiG9w0BCQEWGm1hcmMucG91
bGF1ZEBpLXNvbHZlLmNvLnVrMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDfd3CCaom3tU0P
mdCz0ggSdD8UNJMSVDPou1CJjsLvYpwUySsSQgUdYdFjvQmheBDL2z0T3dX1mvce5WJrDg5fcWQG
aUmQbubJ0qxdK5uT4IkNJx9s1PPDfOEj4PdJExyyG0Cbsvwo8Wyq+xnRlCcMzwm4D/XNnXqkrEZw
MifX+wIDAQABo4IBBjCCAQIwCQYDVR0TBAIwADCBrAYDVR0gBIGkMIGhMIGeBgtghkgBhvhFAQcB
ATCBjjAoBggrBgEFBQcCARYcaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL0NQUzBiBggrBgEFBQcC
AjBWMBUWDlZlcmlTaWduLCBJbmMuMAMCAQEaPVZlcmlTaWduJ3MgQ1BTIGluY29ycC4gYnkgcmVm
ZXJlbmNlIGxpYWIuIGx0ZC4gKGMpOTcgVmVyaVNpZ24wEQYJYIZIAYb4QgEBBAQDAgeAMDMGA1Ud
HwQsMCowKKAmoCSGImh0dHA6Ly9jcmwudmVyaXNpZ24uY29tL2NsYXNzMS5jcmwwDQYJKoZIhvcN
AQEEBQADgYEAh/j3ynKibKwqRZA4Y3KsDwboqp78AIi04ATWtK0MSq+qL2FIu7HORZrN9eJVwqkm
3lr4tNU/ld7bCqnd9zHO4FRyg17pDVwZ4/7Z3UR+wW6WLj2FXn+QPRPWuyeIpOz+LxPhn4HaBIS6
qaO6+glnQl0IX6axcAhLebO/J/hNIQAxggNWMIIDUgIBATCB4TCBzDEXMBUGA1UEChMOVmVyaVNp
Z24sIEluYy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0IE5ldHdvcmsxRjBEBgNVBAsTPXd3dy52
ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEgSW5jb3JwLiBCeSBSZWYuLExJQUIuTFREKGMpOTgx
SDBGBgNVBAMTP1ZlcmlTaWduIENsYXNzIDEgQ0EgSW5kaXZpZHVhbCBTdWJzY3JpYmVyLVBlcnNv
bmEgTm90IFZhbGlkYXRlZAIQf5eMoPha4Jhi5Gsvmd3EcDAJBgUrDgMCGgUAoIIByjAYBgkqhkiG
9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0wMzAxMDgxMDA4MDhaMCMGCSqGSIb3
DQEJBDEWBBSyQfhoGTxzsg3+W6xJZmPb9gvvhjB2BgkqhkiG9w0BCQ8xaTBnMAoGCCqGSIb3DQMH
MA4GCCqGSIb3DQMCAgIAgDAHBgUrDgMCBzAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDAHBgUrDgMC
GjAHBgUrDgMCGjAKBggqhkiG9w0CBTAKBggqhkiG9w0CBTCB8gYJKwYBBAGCNxAEMYHkMIHhMIHM
MRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29y
azFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIEJ5IFJl
Zi4sTElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xhc3MgMSBDQSBJbmRpdmlkdWFs
IFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkAhB/l4yg+FrgmGLkay+Z3cRwMA0GCSqG
SIb3DQEBAQUABIGAoVNTTFRCWyq/UOsrspfjA4Fc0uU657crtzogg3eJ9E2DfTWApXYVSWV27H7F
SVma59tTEyJpgxJEsNKFhVlFP/Iu8EUkjiSz1RiwHhuuOD58GncJpBV3wEyfc88mglVYIwoEmMAW
4zdUKLUeoYxP6/nZQ53hy49ZP0DQ3rgBsYMAAAAAAAA=

------=_NextPart_000_0029_01C2B6FD.D81F3460--



Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h085rIi16554 for ietf-pkix-bks; Tue, 7 Jan 2003 21:53:18 -0800 (PST)
Received: from hermes.cs.auckland.ac.nz (hermes.cs.auckland.ac.nz [130.216.35.151]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h085rFo16550 for <[e-mail]>; Tue, 7 Jan 2003 21:53:16 -0800 (PST)
Received: from medusa01.cs.auckland.ac.nz (medusa01.cs.auckland.ac.nz [130.216.34.60]) by hermes.cs.auckland.ac.nz (8.12.4/8.12.4) with ESMTP id h085qfvv007227; Wed, 8 Jan 2003 18:52:41 +1300
Received: (from pgut001@localhost) by medusa01.cs.auckland.ac.nz (8.11.6/8.11.6) id h085qeA28408; Wed, 8 Jan 2003 18:52:40 +1300
Date: Wed, 8 Jan 2003 18:52:40 +1300
Message-Id: <[e-mail]>
From: [e-mail] (Peter Gutmann)
To: [e-mail], [e-mail]
Subject: Re: OCSP and LDAP
Cc: [e-mail], [e-mail]
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

[e-mail] writes:

>some ten plus years ago i was at a acm sigmod conference and asked somebody
>what this x.500 stuff was ... and was told it is a bunch of networking types
>trying to re-invent 1960s database technology.

I've used that explanation too :-).  The conversion went something like this:

Other person: "Why is X.500 so special?  Why is no-one else doing this?"

Me: "Get your favourite book on database technology and look up 
     'Hierarchical databases'".

[Time passes]

Other person: "I looked in several books.  Many didn't mention it at all,
               and one had a half-page historical note saying it's something
               that was obsoleted by better technology more than two decades 
               ago".

Me: "Exactly".

Peter.


Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h081Fio09619 for ietf-pkix-bks; Tue, 7 Jan 2003 17:15:44 -0800 (PST)
Received: from smtp2.mivlmd.cablespeed.com (smtp2.mivlmd.cablespeed.com [24.35.0.19] (may be forged)) by above.proper.com (8.11.6/8.11.3) with SMTP id h081Fho09615 for <[e-mail]>; Tue, 7 Jan 2003 17:15:43 -0800 (PST)
Received: (qmail 14938 invoked by uid 0); 8 Jan 2003 01:15:10 -0000
Received: from unknown (HELO cablespeed.com) (216.45.82.31) by 0 with SMTP; 8 Jan 2003 01:15:10 -0000
Message-ID: <[e-mail]>
Date: Tue, 07 Jan 2003 20:15:34 -0500
From: jim <[e-mail]>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.1) Gecko/20020823 Netscape/7.0 (nscd2)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: [e-mail]
Subject: Onus on Registration
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Does anyone have any sample PK installation that they know of where the 
onus for registration was placed on the relying party using 
organizational certificates.  There is a chance that an organization 
will undertake such a path and I have been asked to find out if anyone 
else has done it.

Jim Heimberg, ABC, Ph.D.




Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h07Hovj13571 for ietf-pkix-bks; Tue, 7 Jan 2003 09:50:57 -0800 (PST)
Received: from nwkea-mail-2.sun.com (nwkea-mail-2.sun.com [192.18.42.14]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h07Hoto13564 for <[e-mail]>; Tue, 7 Jan 2003 09:50:55 -0800 (PST)
Received: from sydney.East.Sun.COM ([129.148.9.16]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA26556; Tue, 7 Jan 2003 09:50:52 -0800 (PST)
Received: from sun.com (dhcp-ubur02-75-167 [129.148.75.167]) by sydney.East.Sun.COM (8.11.6+Sun/8.11.6/ENSMAIL,v2.2) with ESMTP id h07HopQ28086; Tue, 7 Jan 2003 12:50:51 -0500 (EST)
Message-ID: <[e-mail]>
Date: Tue, 07 Jan 2003 12:49:36 -0500
From: Steve Hanna <[e-mail]>
X-Mailer: Mozilla 4.79 [en] (WinNT; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Santosh Chokhani <[e-mail]>
CC: PKIX List <[e-mail]>
Subject: Re: Offline Root CA with valid CRL hierachie
References: <000e01c2b366$bbed4380$5b845b0c@Chokhani>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

I don't think we disagree substantially. We discussed a few
different ways to provide timely revocation with an offline CA,
pointing out some of the pros and cons of each technique.
We may not agree on which technique is best, but ultimately
that's up to the CA operator.

-Steve

Santosh Chokhani wrote:
> 
> Steve:
> 
> The question is not of Root revocation, but of establishing trust in and
> checking the revocation status (if the trust is certificate based) of the
> OCSP Responder itself.
> 
> In the other comments, I do not see an area where you disagree with me.  If
> you do, please point that out to me.
> 
> -----Original Message-----
> From: Steve Hanna [mailto:[e-mail]]
> Sent: Friday, January 03, 2003 2:43 PM
> To: Santosh Chokhani
> Cc: [e-mail]
> Subject: Re: Offline Root CA with valid CRL hierachie
> 
> Santosh Chokhani wrote:
> > I am thoroughly confused.  First, what I am proposing will work if the
> > RP is using indirect CRL.  I am making a modest assumption that an RP
> > that can process indirect CRL can also process full and complete CRL.
> 
> Right. The primary benefit of pre-issued CRLs over indirect CRLs or OCSP is
> that pre-issued CRLs work with any RP that can process CRLs (any RFC 3280
> compliant RP) whereas the others require support for features not required
> by RFC 3280.
> 
> > In terms of OCSP, if your solution is OCSP only, I still think the
> > approach I suggest will be a good way to supply the revocation
> > information to the OCSP responders, specially if there are many of
> > them or if you want to the convenience of distributing the revocation
> > information over untrusted networks.
> 
> I don't know much about how people generally supply
> revocation information to OCSP responders. Certainly,
> I expect that your system would work fine. But I expect
> that many OCSP responders would support indirect CRLs,
> so that might also be a solution. And some people might
> just use SSH. I don't know.
> 
> > How the OCSP Responder for off-line root revocation should be
> > architected is a separate topic with its own nuances.
> 
> I didn't think we were discussing how to revoke a root.
> As you say, that's a separate topic. Let's leave it aside
> for now, unless there's some pressing need to address it.
> 
> -Steve


Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h07FDJD02970 for ietf-pkix-bks; Tue, 7 Jan 2003 07:13:19 -0800 (PST)
Received: from e4.ny.us.ibm.com (e4.ny.us.ibm.com [32.97.182.104]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h07FDGo02965 for <[e-mail]>; Tue, 7 Jan 2003 07:13:16 -0800 (PST)
Received: from northrelay02.pok.ibm.com (northrelay02.pok.ibm.com [9.56.224.150]) by e4.ny.us.ibm.com (8.12.2/8.12.2) with ESMTP id h07FDCOd008966 for <[e-mail]>; Tue, 7 Jan 2003 10:13:12 -0500
Received: from d01hub03.pok.ibm.com (d01av02.pok.ibm.com [9.56.224.216]) by northrelay02.pok.ibm.com (8.12.3/NCO/VER6.4) with ESMTP id h07FCxLN131872 for <[e-mail]>; Tue, 7 Jan 2003 10:13:10 -0500
In-Reply-To: <[e-mail]>
To: [e-mail]
MIME-Version: 1.0
Subject: Re: LDAP PKI Schema (was Re: No-op LDAP ;binary option)
X-Mailer: Lotus Notes Release 6.0 September 26, 2002
From: Timothy Hahn <[e-mail]>
X-MIMETrack: S/MIME Sign by Notes Client on Timothy Hahn/Durham/IBM(Release 6.0|September 26, 2002) at 01/07/2003 08:34:32 AM, Serialize by Notes Client on Timothy Hahn/Durham/IBM(Release 6.0|September 26, 2002) at 01/07/2003 08:34:32 AM, Serialize complete at 01/07/2003 08:34:33 AM, Itemize by Notes Client on Timothy Hahn/Durham/IBM(Release 6.0|September 26, 2002) at 01/07/2003 08:34:33 AM, S/MIME Sign complete at 01/07/2003 08:34:33 AM, S/MIME Sign by Notes Client on Timothy Hahn/Durham/IBM(Release 6.0|September 26, 2002) at 01/07/2003 08:40:14 AM, S/MIME Sign complete at 01/07/2003 08:40:14 AM, MIME-CD by Router on D01MLC96/01/M/IBM(Build V601_12152002 SPR MIAS5GXKFV CBOD5GVRDB|December 20, 2002) at 01/07/2003 10:13:00, MIME-CD complete at 01/07/2003 10:13:00, Serialize by Router on D01HUB03/01/H/IBM(Release 6.0 [IBM]|December 22, 2002) at 01/07/2003 10:13:10
Message-ID: <[e-mail]>
Date: Tue, 7 Jan 2003 08:40:13 -0500
Content-type: multipart/mixed;  Boundary="0__=0ABBE634DFDA282D8f9e8a93df938690918c0ABBE634DFDA282D"
Content-Disposition: inline
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

--0__=0ABBE634DFDA282D8f9e8a93df938690918c0ABBE634DFDA282D
Content-type: text/plain; charset=ISO-8859-1
Content-transfer-encoding: quoted-printable




Russ,

Great question. =A0Simply - it gives the "client" the opportunity to
establish whether or not it can or cannot support retrieval of the
information from that data source (directory sub-tree). =A0Client and s=
erver
implementations choose which protocols and data models they're going to=

"support" all the time. =A0As long as both support the same model(s), t=
hen
they interoperate. =A0My proposal is that we define one way to identify=
 which
data model(s) is(are) employed, so that servers and clients can determi=
ne
whether they are capable of supporting the formats. =A0If they are not
capable, they can gracefully fail.

The client can be made as "fat" or as "lean" as the implementer wants,
because the implementer can decide which formats to support. =A0If the
implementer decides to support one while another part of the industry t=
ends
to support another - well, then that particular implementation will get=

"fatter" because it will wind up supporting both.

My premise is that there is not a single data model that "fits" for ALL=

applications/deployments. =A0And because of that, multiple data models =
can
and will (in real-world scenarios) exist. =A0So why not accept this, de=
fine a
(singular) way of identifying which model is used, and move on. =A0At l=
east
in this way, if a particular implementation/application has a need to s=
tore
things in a different way, it can, and we can still hope for
interoperability through IETF documents.

Regards,
Tim Hahn

Internet: [e-mail]
Internal: Timothy Hahn/Durham/IBM@IBMUS
phone: [phone] =A0 =A0 tie-line: 8/687.1565
fax: [phone]

|+-----------------------+---------------------------------------------=
---|
||   Russ Housley        |                                             =
   |
||   <[e-mail]|   =A0 =A0 =A0 =A0 To: =A0 =A0 =A0 =A0Timothy=
                   |
||   m>                  |   Hahn/Durham/IBM@IBMUS                     =
   |
||                       |   =A0 =A0 =A0 =A0 cc: =A0 =A0 =A0 =A0ietf-pk=
[e-mail]         |
||   01/06/2003 04:28 PM |   =A0 =A0 =A0 =A0 Subject: =A0 =A0 =A0 =A0Re=
: LDAP PKI Schema  |
||                       |   (was Re: No-op LDAP ;binary option)       =
   |
||                       |                                             =
   |
||                       |                                             =
   |
|+-----------------------+---------------------------------------------=
---|





Tim:

I do not understand how a client is better off with multiple ways to pu=
t
the same information in the Directory. =A0Doesn't this approach just ma=
ke the
client fat? =A0It seem to me that the client would have to support all =
of the
possible ways that the information could be stored. =A0It cannot know w=
hich
method it will encounter until it starts looking at data in the Directo=
ry.

Russ


At 03:14 PM 1/6/2003 -0500, Timothy Hahn wrote:
>Hello all,
>
>After listening to the different view-points on this topic, it seems t=
o me
>that there are multiple valid approaches. =A0These approaches include,=
 but
>are not limited to:
> =A0 - leveraging the general solution of component-matching
> =A0 - new schema to support application-managed componentization of
>information to make things searchable
>as well as others (additional matching rules, for example).
>
>It occurs to me that perhaps we have a situation where "one size does =
not
>fit all". =A0Why not accept this and define a way for applications to
>determine which (of possibly multiple) format(s) has been used to plac=
e
the
>information into the directory? =A0We could define some small bit of s=
chema
>which indicates the way in which the certificate information is placed=

into
>the directory, then different applications could query this and determ=
ine:
> =A0 - whether they can use the data at all
> =A0 - if they can use the data, how they can best use it (if there ar=
e, for
>example, multiple mechanisms employed).
>
>Just a thought to get us through this discussion.
>
>Regards,
>Tim Hahn


=

--0__=0ABBE634DFDA282D8f9e8a93df938690918c0ABBE634DFDA282D
Content-type: application/octet-stream; 
	name="=?ISO-8859-1?Q?smime=2Ep7s?="
Content-Disposition: attachment; filename="=?ISO-8859-1?Q?smime=2Ep7s?="
Content-transfer-encoding: base64

MIAGCSqGSIb3DQEHAqCAMIIULwIBATELMAkGBSsOAwIaBQAwCwYJKoZIhvcNAQcBoIISUDCCAtow
ggJDoAMCAQICAwMUtjANBgkqhkiG9w0BAQQFADBOMQswCQYDVQQGEwJVUzEQMA4GA1UEChMHRXF1
aWZheDEtMCsGA1UECxMkRXF1aWZheCBTZWN1cmUgQ2VydGlmaWNhdGUgQXV0aG9yaXR5MB4XDTAy
MDExNDIyMDcxMVoXDTExMTIzMTIyMDcxMVowaTELMAkGA1UEBhMCVVMxNDAyBgNVBAoTK0ludGVy
bmF0aW9uYWwgQnVzaW5lc3MgTWFjaGluZXMgQ29ycG9yYXRpb24xJDAiBgNVBAMTG0lCTSBDZXJ0
aWZpY2F0aW9uIEF1dGhvcml0eTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEA629xc49NpAPz
cAsuShTImLRYMkyepDEkC1UrPbsFRyAFZKsv3pw0MGfW/+7glzJKgPkPzlTZZfznznGbmAWVnNBQ
lyPasOtCjif603euRXReHcKfHMPLItKozibWIPHJuOnwNclOnnP2sKufuPzbTImQTTi5c8JZNZcM
J0YFzTcCAwEAAaOBqjCBpzARBglghkgBhvhCAQEEBAMCAIcwDgYDVR0PAQH/BAQDAgHGMB0GA1Ud
DgQWBBSuVA6S6qgzqSskLcfIbzDc3vNKQDAfBgNVHSMEGDAWgBRI5mj5K9KylddH2CMgEE8zmJCf
1DAPBgNVHRMBAf8EBTADAQH/MDEGA1UdJQQqMCgGCCsGAQUFBwMBBggrBgEFBQcDAgYIKwYBBQUH
AwMGCCsGAQUFBwMEMA0GCSqGSIb3DQEBBAUAA4GBADJye3NmC8q2PzypRZfu7JvDRDX1rRcanZvu
jQupk2oCScMd3FIHLE7hOfu8YffvxtLU3y8wNamQEORjTD175qAffryXypwtiVjBUKSDlBCQ14ke
McF9ViNdewEoBGiAycUq8R3Lrlf4TCDvW4GeguNTFFZnS0ygYATiJk7iDyvEMIIC2jCCAkOgAwIB
AgIDAxS2MA0GCSqGSIb3DQEBBAUAME4xCzAJBgNVBAYTAlVTMRAwDgYDVQQKEwdFcXVpZmF4MS0w
KwYDVQQLEyRFcXVpZmF4IFNlY3VyZSBDZXJ0aWZpY2F0ZSBBdXRob3JpdHkwHhcNMDIwMTE0MjIw
NzExWhcNMTExMjMxMjIwNzExWjBpMQswCQYDVQQGEwJVUzE0MDIGA1UEChMrSW50ZXJuYXRpb25h
bCBCdXNpbmVzcyBNYWNoaW5lcyBDb3Jwb3JhdGlvbjEkMCIGA1UEAxMbSUJNIENlcnRpZmljYXRp
b24gQXV0aG9yaXR5MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDrb3Fzj02kA/NwCy5KFMiY
tFgyTJ6kMSQLVSs9uwVHIAVkqy/enDQwZ9b/7uCXMkqA+Q/OVNll/OfOcZuYBZWc0FCXI9qw60KO
J/rTd65FdF4dwp8cw8si0qjOJtYg8cm46fA1yU6ec/awq5+4/NtMiZBNOLlzwlk1lwwnRgXNNwID
AQABo4GqMIGnMBEGCWCGSAGG+EIBAQQEAwIAhzAOBgNVHQ8BAf8EBAMCAcYwHQYDVR0OBBYEFK5U
DpLqqDOpKyQtx8hvMNze80pAMB8GA1UdIwQYMBaAFEjmaPkr0rKV10fYIyAQTzOYkJ/UMA8GA1Ud
EwEB/wQFMAMBAf8wMQYDVR0lBCowKAYIKwYBBQUHAwEGCCsGAQUFBwMCBggrBgEFBQcDAwYIKwYB
BQUHAwQwDQYJKoZIhvcNAQEEBQADgYEAMnJ7c2YLyrY/PKlFl+7sm8NENfWtFxqdm+6NC6mTagJJ
wx3cUgcsTuE5+7xh9+/G0tTfLzA1qZAQ5GNMPXvmoB9+vJfKnC2JWMFQpIOUEJDXiR4xwX1WI117
ASgEaIDJxSrxHcuuV/hMIO9bgZ6C41MUVmdLTKBgBOImTuIPK8QwggMgMIICiaADAgECAgQ13vTP
MA0GCSqGSIb3DQEBBQUAME4xCzAJBgNVBAYTAlVTMRAwDgYDVQQKEwdFcXVpZmF4MS0wKwYDVQQL
EyRFcXVpZmF4IFNlY3VyZSBDZXJ0aWZpY2F0ZSBBdXRob3JpdHkwHhcNOTgwODIyMTY0MTUxWhcN
MTgwODIyMTY0MTUxWjBOMQswCQYDVQQGEwJVUzEQMA4GA1UEChMHRXF1aWZheDEtMCsGA1UECxMk
RXF1aWZheCBTZWN1cmUgQ2VydGlmaWNhdGUgQXV0aG9yaXR5MIGfMA0GCSqGSIb3DQEBAQUAA4GN
ADCBiQKBgQDBXbFYZwhi7qCaLR8IbZEUaJgKHv7aBG8ThGIhw9F8zp8F4LgB8E407OKKlQRkrPFr
U18Fs8tngL9CAo7+3QEJ7OEAFE/8+/AM3UO6WyvhH4BwmRVXkxbxD5dqt8JoIxzMTVkwrFEeO68r
1u5jRXvF2V9Q0uNQDzqI578U/eDHuQIDAQABo4IBCTCCAQUwcAYDVR0fBGkwZzBloGOgYaRfMF0x
CzAJBgNVBAYTAlVTMRAwDgYDVQQKEwdFcXVpZmF4MS0wKwYDVQQLEyRFcXVpZmF4IFNlY3VyZSBD
ZXJ0aWZpY2F0ZSBBdXRob3JpdHkxDTALBgNVBAMTBENSTDEwGgYDVR0QBBMwEYEPMjAxODA4MjIx
NjQxNTFaMAsGA1UdDwQEAwIBBjAfBgNVHSMEGDAWgBRI5mj5K9KylddH2CMgEE8zmJCf1DAdBgNV
HQ4EFgQUSOZo+SvSspXXR9gjIBBPM5iQn9QwDAYDVR0TBAUwAwEB/zAaBgkqhkiG9n0HQQAEDTAL
GwVWMy4wYwMCBsAwDQYJKoZIhvcNAQEFBQADgYEAWM4p6vz33rXOArkXtYXRuePglcwlMQ0AppJu
f7aSY55QldGab+QR3mOFbpjuqP9ayNNVsmZxV97AIes9KqcjSQEEhkJ7/O5/ohZStWdn00DbOyZY
sih3Pa4Ud2HW+ipmJ6AN+qdzXOpw8ZQhZURf+vzvKWipood573nvT6wHdzgwggMgMIICiaADAgEC
AgQ13vTPMA0GCSqGSIb3DQEBBQUAME4xCzAJBgNVBAYTAlVTMRAwDgYDVQQKEwdFcXVpZmF4MS0w
KwYDVQQLEyRFcXVpZmF4IFNlY3VyZSBDZXJ0aWZpY2F0ZSBBdXRob3JpdHkwHhcNOTgwODIyMTY0
MTUxWhcNMTgwODIyMTY0MTUxWjBOMQswCQYDVQQGEwJVUzEQMA4GA1UEChMHRXF1aWZheDEtMCsG
A1UECxMkRXF1aWZheCBTZWN1cmUgQ2VydGlmaWNhdGUgQXV0aG9yaXR5MIGfMA0GCSqGSIb3DQEB
AQUAA4GNADCBiQKBgQDBXbFYZwhi7qCaLR8IbZEUaJgKHv7aBG8ThGIhw9F8zp8F4LgB8E407OKK
lQRkrPFrU18Fs8tngL9CAo7+3QEJ7OEAFE/8+/AM3UO6WyvhH4BwmRVXkxbxD5dqt8JoIxzMTVkw
rFEeO68r1u5jRXvF2V9Q0uNQDzqI578U/eDHuQIDAQABo4IBCTCCAQUwcAYDVR0fBGkwZzBloGOg
YaRfMF0xCzAJBgNVBAYTAlVTMRAwDgYDVQQKEwdFcXVpZmF4MS0wKwYDVQQLEyRFcXVpZmF4IFNl
Y3VyZSBDZXJ0aWZpY2F0ZSBBdXRob3JpdHkxDTALBgNVBAMTBENSTDEwGgYDVR0QBBMwEYEPMjAx
ODA4MjIxNjQxNTFaMAsGA1UdDwQEAwIBBjAfBgNVHSMEGDAWgBRI5mj5K9KylddH2CMgEE8zmJCf
1DAdBgNVHQ4EFgQUSOZo+SvSspXXR9gjIBBPM5iQn9QwDAYDVR0TBAUwAwEB/zAaBgkqhkiG9n0H
QQAEDTALGwVWMy4wYwMCBsAwDQYJKoZIhvcNAQEFBQADgYEAWM4p6vz33rXOArkXtYXRuePglcwl
MQ0AppJuf7aSY55QldGab+QR3mOFbpjuqP9ayNNVsmZxV97AIes9KqcjSQEEhkJ7/O5/ohZStWdn
00DbOyZYsih3Pa4Ud2HW+ipmJ6AN+qdzXOpw8ZQhZURf+vzvKWipood573nvT6wHdzgwggMiMIIC
i6ADAgECAgJONTANBgkqhkiG9w0BAQQFADBpMQswCQYDVQQGEwJVUzE0MDIGA1UEChMrSW50ZXJu
YXRpb25hbCBCdXNpbmVzcyBNYWNoaW5lcyBDb3Jwb3JhdGlvbjEkMCIGA1UEAxMbSUJNIENlcnRp
ZmljYXRpb24gQXV0aG9yaXR5MB4XDTAyMTEyMTEzMDY1M1oXDTAzMTIwNTEzMDY1M1owgYQxCzAJ
BgNVBAYTAlVTMQwwCgYDVQQKEwNJQk0xETAPBgNVBAsTCEVNUExPWUVFMRgwFgYDVQQDEw9UaW1v
dGh5IEouIEhhaG4xGTAXBgoJkiaJk/IsZAEBEwkxMjg4NTc4OTcxHzAdBgkqhkiG9w0BCQEWEGhh
aG50QHVzLmlibS5jb20wgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBAMZRHQYCNd56O2LkRqmV
bpvr70BMnmNf+UWqMbgJ0v8Y5Vb3hdrThAoyNs3XKbFl9oYir3AFiZHVPUpFM2anK8+Sb9IqzfIh
g/x6Tu9wVHPXkve+wBCGneHD2GgvIx7NEECdr7YuOd7SWevXcLloLu3yQ7Hb2aZ1MQ8o78M9S7K1
AgMBAAGjgbwwgbkwEQYJYIZIAYb4QgEBBAQDAgWgMA4GA1UdDwEB/wQEAwIF4DAdBgNVHQ4EFgQU
z9GrkTcJqnyWERTvptgBPQmzC/QwKwYDVR0RBCQwIqAgBgorBgEEAYI3FAIDoBIMEGhhaG50QHVz
LmlibS5jb20wHwYDVR0jBBgwFoAUrlQOkuqoM6krJC3HyG8w3N7zSkAwJwYDVR0lBCAwHgYIKwYB
BQUHAwIGCCsGAQUFBwMDBggrBgEFBQcDBDANBgkqhkiG9w0BAQQFAAOBgQCHcqGsmuSPRftlK36s
f5HfVXRhzCbH63xR5jLTpzFIfzoNo8u8yeC2yu81Ylj3rLzKmcwNtb9rkQT+wqWJH498ECe66dOQ
6tUDHk3VYGYZ3QrerjTBWBnKoekfUMcp+9xtjsHYVfMEopW/0FU6QsMwj3vouSy6Uv5nTGxKIi73
ZzCCAyIwggKLoAMCAQICAk41MA0GCSqGSIb3DQEBBAUAMGkxCzAJBgNVBAYTAlVTMTQwMgYDVQQK
EytJbnRlcm5hdGlvbmFsIEJ1c2luZXNzIE1hY2hpbmVzIENvcnBvcmF0aW9uMSQwIgYDVQQDExtJ
Qk0gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkwHhcNMDIxMTIxMTMwNjUzWhcNMDMxMjA1MTMwNjUz
WjCBhDELMAkGA1UEBhMCVVMxDDAKBgNVBAoTA0lCTTERMA8GA1UECxMIRU1QTE9ZRUUxGDAWBgNV
BAMTD1RpbW90aHkgSi4gSGFobjEZMBcGCgmSJomT8ixkAQETCTEyODg1Nzg5NzEfMB0GCSqGSIb3
DQEJARYQaGFobnRAdXMuaWJtLmNvbTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAxlEdBgI1
3no7YuRGqZVum+vvQEyeY1/5RaoxuAnS/xjlVveF2tOECjI2zdcpsWX2hiKvcAWJkdU9SkUzZqcr
z5Jv0irN8iGD/HpO73BUc9eS977AEIad4cPYaC8jHs0QQJ2vti453tJZ69dwuWgu7fJDsdvZpnUx
Dyjvwz1LsrUCAwEAAaOBvDCBuTARBglghkgBhvhCAQEEBAMCBaAwDgYDVR0PAQH/BAQDAgXgMB0G
A1UdDgQWBBTP0auRNwmqfJYRFO+m2AE9CbML9DArBgNVHREEJDAioCAGCisGAQQBgjcUAgOgEgwQ
aGFobnRAdXMuaWJtLmNvbTAfBgNVHSMEGDAWgBSuVA6S6qgzqSskLcfIbzDc3vNKQDAnBgNVHSUE
IDAeBggrBgEFBQcDAgYIKwYBBQUHAwMGCCsGAQUFBwMEMA0GCSqGSIb3DQEBBAUAA4GBAIdyoaya
5I9F+2Urfqx/kd9VdGHMJsfrfFHmMtOnMUh/Og2jy7zJ4LbK7zViWPesvMqZzA21v2uRBP7CpYkf
j3wQJ7rp05Dq1QMeTdVgZhndCt6uNMFYGcqh6R9Qxyn73G2OwdhV8wSilb/QVTpCwzCPe+i5LLpS
/mdMbEoiLvdnMYIBujCCAbYCAQEwbzBpMQswCQYDVQQGEwJVUzE0MDIGA1UEChMrSW50ZXJuYXRp
b25hbCBCdXNpbmVzcyBNYWNoaW5lcyBDb3Jwb3JhdGlvbjEkMCIGA1UEAxMbSUJNIENlcnRpZmlj
YXRpb24gQXV0aG9yaXR5AgJONTAJBgUrDgMCGgUAoIGiMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0B
BwEwHAYJKoZIhvcNAQkFMQ8XDTAzMDEwNzEzMzQzM1owIwYJKoZIhvcNAQkEMRYEFJp9BPP8kHRW
uPbyKiAViU9+VAEfMEMGCSqGSIb3DQEJDzE2MDQwBwYFKw4DAh0wDgYIKoZIhvcNAwICAgCAMAoG
CCqGSIb3DQMHMA0GCCqGSIb3DQMCAgEoMA0GCSqGSIb3DQEBAQUABIGACvwBO2mZ9klb4VTwcMK4
AorPvtztACgs80jrAKSwy8ULcOH9XxhhRmKOYvO8RxrPORVdWOkU/of3DxjXslsgD1JtuGWuSacb
KFF4YNecGqD9dEQgmeqxI6yi4cXIgD439SB/Oti+KBLrgpyHgH5usZOUpvORb5KjOu5UX1ff0McA
AAAA

--0__=0ABBE634DFDA282D8f9e8a93df938690918c0ABBE634DFDA282D--



Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h07Dgq123637 for ietf-pkix-bks; Tue, 7 Jan 2003 05:42:52 -0800 (PST)
Received: from nymelsmtp.internet.ny.fdms.firstdata.com (nymelsmtp01.firstdata.com [198.184.0.23]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h07Dgpo23631 for <[e-mail]>; Tue, 7 Jan 2003 05:42:51 -0800 (PST)
Subject: Re: OCSP and LDAP
To: "Anders Rundgren" <[e-mail]>
Cc: "Ambarish Malpani" <[e-mail]>, "IETF PKIX" <[e-mail]>
X-Mailer: Lotus Notes Release 5.0.5  September 22, 2000
Message-ID: <[e-mail]>
From: [e-mail]
Date: Tue, 7 Jan 2003 06:42:20 -0700
X-MIMETrack: Serialize by Router on NYMELSMTP/NY/FDMS/FDC(Release 5.0.8 |June 18, 2001) at 01/07/2003 08:44:46 AM
MIME-Version: 1.0
Content-type: text/plain; charset=us-ascii
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

as been mentioned before ... it is relatively simple to see the information
in certificates as form of distributed read/only cache entries ... with
lots of similarities to cpu caches, database caches, filesystem caches,
distributed/network databases, distributed/network filesystems, etc.

the data in the certificates is stale by defintion ... if it wasn't ... it
wouldn't be necessary to have an OCSP that basically is asking if it is too
stale.

some ten plus years ago i was at a acm sigmod conference and asked somebody
what this x.500 stuff was ... and was told it is a bunch of networking
types trying to re-invent 1960s database technology.

random past refs:
http://www.garlic.com/~lynn/aadsmore.htm#time Certifiedtime.com
http://www.garlic.com/~lynn/aadsm5.htm#faith faith-based security and kinds
of trust
http://www.garlic.com/~lynn/aadsm8.htm#softpki19 DNSSEC (RE: Software for
PKI)
http://www.garlic.com/~lynn/aadsm12.htm#52 First Data Unit Says It's
Untangling Authentication
http://www.garlic.com/~lynn/aepay4.htm#visaset2 Visa Delicately Gives Hook
to SET Standard
http://www.garlic.com/~lynn/aepay6.htm#crlwork do CRL's actually work?
http://www.garlic.com/~lynn/aepay10.htm#77 Invisible Ink, E-signatures slow
to broadly catch on (addenda)
http://www.garlic.com/~lynn/2001d.html#7 Invalid certificate on 'security'
site.
http://www.garlic.com/~lynn/2001e.html#43 Can I create my own SSL key?

--
Internet trivia, 20th anv: http://www.garlic.com/~lynn/rfcietff.htm



Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h07DXSr22544 for ietf-pkix-bks; Tue, 7 Jan 2003 05:33:28 -0800 (PST)
Received: from ietf.org (odin.ietf.org [132.151.1.176]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h07DXRo22540 for <[e-mail]>; Tue, 7 Jan 2003 05:33:27 -0800 (PST)
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA12313; Tue, 7 Jan 2003 08:30:11 -0500 (EST)
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-warranty-extn-02.txt
Date: Tue, 07 Jan 2003 08:30:11 -0500
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

--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		: Warranty Certificate Extension
	Author(s)	: D. Linsenbardt, S. Pontius, A. Sturgeon
	Filename	: draft-ietf-pkix-warranty-extn-02.txt
	Pages		: 7
	Date		: 2003-1-6
	
This document describes a certificate extension to explicitly state
the warranty offered by a Certificate Authority (CA) for a the
certificate containing the extension.

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

To remove yourself from the IETF Announcement list, send a message to 
ietf-announce-request with the word unsubscribe in the body of the message.

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-warranty-extn-02.txt".

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


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

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

--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"

--OtherAccess
Content-Type: Message/External-body;
	access-type="mail-server";
	server="[e-mail]"

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

ENCODING mime
FILE /internet-drafts/draft-ietf-pkix-warranty-extn-02.txt

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

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

--OtherAccess--

--NextPart--




Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h07DXME22527 for ietf-pkix-bks; Tue, 7 Jan 2003 05:33:22 -0800 (PST)
Received: from ietf.org (odin.ietf.org [132.151.1.176]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h07DXLo22520 for <[e-mail]>; Tue, 7 Jan 2003 05:33:21 -0800 (PST)
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA12281; Tue, 7 Jan 2003 08:30:05 -0500 (EST)
Message-Id: <[e-mail]>
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
Cc: [e-mail]
From: [e-mail]
Reply-to: [e-mail]
Subject: I-D ACTION:draft-ietf-pkix-scvp-11.txt
Date: Tue, 07 Jan 2003 08:30:05 -0500
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

--NextPart

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

	Title		: Simple Certificate Validation Protocol (SCVP)
	Author(s)	: A. Malpani, R. Housley, T. Freeman
	Filename	: draft-ietf-pkix-scvp-11.txt
	Pages		: 47
	Date		: 2003-1-6
	
SCVP allows a client to offload certificate handling to a server. The
server can provide the client with a variety of valuable information
about the certificate, such as whether the certificate is valid, a
certification path to a trust anchor, and revocation status. SCVP has
many purposes, including simplifying client implementations and
allowing companies to centralize trust and policy management.

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

To remove yourself from the IETF Announcement list, send a message to 
ietf-announce-request with the word unsubscribe in the body of the message.

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

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


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

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

--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"

--OtherAccess
Content-Type: Message/External-body;
	access-type="mail-server";
	server="[e-mail]"

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

ENCODING mime
FILE /internet-drafts/draft-ietf-pkix-scvp-11.txt

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

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

--OtherAccess--

--NextPart--




Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h07DXHQ22510 for ietf-pkix-bks; Tue, 7 Jan 2003 05:33:17 -0800 (PST)
Received: from ietf.org (odin.ietf.org [132.151.1.176]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h07DXGo22502 for <[e-mail]>; Tue, 7 Jan 2003 05:33:16 -0800 (PST)
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA12262; Tue, 7 Jan 2003 08:29:59 -0500 (EST)
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-ecc-nist-recommended-curves-00.txt
Date: Tue, 07 Jan 2003 08:29:59 -0500
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

--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		: NIST Recommended EC Domain Parameters For PKIX
	Author(s)	: D. Brown
	Filename	: draft-ietf-pkix-ecc-nist-recommended-curves-00.txt
	Pages		: 5
	Date		: 2003-1-6
	
This document gives the object identifiers for the elliptic curve
domain pararmeters that the National Institute of Standards and
Techology recommends in its publication 'Digital Signature
Standard

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-pkix-ecc-nist-recommended-curves-00.txt

To remove yourself from the IETF Announcement list, send a message to 
ietf-announce-request with the word unsubscribe in the body of the message.

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-ecc-nist-recommended-curves-00.txt".

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


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

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

--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"

--OtherAccess
Content-Type: Message/External-body;
	access-type="mail-server";
	server="[e-mail]"

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

ENCODING mime
FILE /internet-drafts/draft-ietf-pkix-ecc-nist-recommended-curves-00.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-pkix-ecc-nist-recommended-curves-00.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

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

--OtherAccess--

--NextPart--




Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h07DXBg22495 for ietf-pkix-bks; Tue, 7 Jan 2003 05:33:11 -0800 (PST)
Received: from ietf.org (odin.ietf.org [132.151.1.176]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h07DXAo22491 for <[e-mail]>; Tue, 7 Jan 2003 05:33:10 -0800 (PST)
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA12242; Tue, 7 Jan 2003 08:29:53 -0500 (EST)
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-rsa-pkalgs-00.txt
Date: Tue, 07 Jan 2003 08:29:53 -0500
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

--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		: Additional Algorithms and Identifiers for RSA 
                          Cryptography for use in the Internet X.509 Public Key 
                          Infrastructure Certificate and Certificate Revocation 
                          List (CRL) Profile
	Author(s)	: R. Housley, B. Kaliski
	Filename	: draft-ietf-pkix-rsa-pkalgs-00.txt
	Pages		: 22
	Date		: 2003-1-6
	
This document supplements RFC 3279.  It describes the conventions for
using the RSASSA-PSS signature algorithm, the RSAES-OAEP key
transport algorithm, and additional one-way hash functions with the
PKCS #1 version 1.5 signature algorithm in the Internet X.509 Public
Key Infrastructure (PKI).  Encoding formats, algorithm identifiers,
and parameter formats are specified.

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

To remove yourself from the IETF Announcement list, send a message to 
ietf-announce-request with the word unsubscribe in the body of the message.

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-rsa-pkalgs-00.txt".

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


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

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

--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"

--OtherAccess
Content-Type: Message/External-body;
	access-type="mail-server";
	server="[e-mail]"

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

ENCODING mime
FILE /internet-drafts/draft-ietf-pkix-rsa-pkalgs-00.txt

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

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

--OtherAccess--

--NextPart--




Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h07BD9L06090 for ietf-pkix-bks; Tue, 7 Jan 2003 03:13:09 -0800 (PST)
Received: from nalle.datum.nu (as6-6-8.s.bonet.se [217.215.37.231]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h07BD5o06079 for <[e-mail]>; Tue, 7 Jan 2003 03:13:05 -0800 (PST)
Received: from stl (as3-3-6.apv.s.bonet.se [217.215.35.57]) by nalle.datum.nu (Postfix) with ESMTP id CC8E810F544; Tue,  7 Jan 2003 12:12:54 +0100 (CET)
From: "Simon Tardell" <[e-mail]>
To: "'Massimiliano Pala'" <[e-mail]>, <[e-mail]>
Subject: RE: OCSP and LDAP
Date: Tue, 7 Jan 2003 12:12:53 +0100
Message-ID: <00f901c2b63d$b961f460$0a01a8c0@stl>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook, Build 10.0.3416
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000
In-Reply-To: <[e-mail]>
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

 
> Simon Tardell wrote:
> [...]r this reason I need some more information rather than 
> the only CRL.
> > 
> > 
> > No, if you want to remove the latency in the system that is 
> related to 
> > the issuance interval of your CRL, then you should issue CRLs 
> > immediately as the revocation occurs.
> 
> But this, in some environment it is not possible. Let's say 
> the CA is in a timed controlled access, unavailable from 8pm 
> to 8am (for different reasons, i.e. security, lack of 
> personnel, etc.. ) and a user asks for revocation at 9pm, 
> should we let the certificate being reported as valid till 8am ?

Not necessarily. Just because the staff is in bed, it doesn't mean that
the CA can't issue deltas with onHold in the meanwhile. It achieves the
same thing, except two things:

1/ You don't introduce an extra directory which --
   --would have to be sufficiently understood in order not to compromise
the security of the system as a whole
   --would not be interoperable with anyone elses CA (private schema)
2/ You don't introduce another source of authority beside the CA.
Although it is the business idea of a wellknown company, many believe
the the final word on what certificate is valid and what is not lies
with the CA...

> For this reason I need some additional information, my 
> question was about the presence of a standard describing 
> where to store them onto LDAP and if, to you, it could be 
> better storing them on a per certificate basis or in a single 
> entry in the main organization entry.

The latter describes a CRL...
 
> [ unknown ]
> > No. There is an unclear wording in RFC2560 that might lead the 
> > thoughts in that direction. "unknown" means that the OCSP 
> is unable or 
> > unwilling to answer the revocation query (because it 
> doesn't know the 
> > CA, or because it doesn't have up to date revocation information or 
> > whatever). A logical reaction to an "unknown" response is to go to 
> > some other OCSP responder that might be better connected for the 
> > moment. If you confuse the meaning of "unknown" to be an assertion 
> > (that the certificate was indeed never issued) then that 
> availability 
> > feature breaks down (at least if you have the wrong kind of 
> client). 
> > The OCSPv2 draft has a better wording.
> 
> Quoting the RFC2560 << The "unknown" state indicates that the 
> responder doesn't know about the certificate being requested. 
> >>. I was not saying that the "unknown" means that the 
> certificate has never being issued, anyway how could the 
> responder know which certificates have been issued ? In this 
> case the responder can';t be sure about the validity of a 
> certificate and it should, to me at least, therefore return 
> an "unknown" status.

This was not the intention, and the text has been refrased for the draft
of OCSPv2:
"
   This specification defines the following definitive response
   indicators for use in the certificate status value:

   -- good
   -- revoked
   -- unknown

   The "good" state indicates that the certificate has not been
   revoked. It does not indicate that the certificate was ever issued,
   or is in its validity interval.

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

   The "unknown" state indicates that the responder does not know, or
   is unwilling to tell, the requestor the status of the certificate. A
   client may be able to get a definitive response later, or at another
   responder.

   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, expiry, etc.
"

>From this is it is quite clear that the base query is about revocation,
and that the answer to the question "has this neverissued certificate
been revoked?" is "no".

The interpretation you are suggesting has been discussed before at great
length in this group, and I hesitate to regurgitate it. 

However, it is possible to put a question (and corresponding answer)
about issuance into an extension. The question is possibly, why? What
risk is it you are trying to cover for? And, is there perhaps already
another, less magic, mechanism to handle it?
 
> Because of these considerations I think the OCSP reponder 
> needs additional data besides the only CRL(s), although I 
> know that this is a fast way of having it working but this 
> works only when the CRLs are immediately (in the same second) 
> issued after certificate revocation and this does not work in 
> environment when some human interaction (for example verification).
> 
> It seems, to me, just translating the CRLs in another format 
> without adding a real improvement to the validating 
> process... I think the OCSP to be more useful than this.

Adding is ok, but altering is a no-no. If different implementors have
different interpretations of the base query, then clients and servers
from different vendors will not interoperate.

Simon

Simon Tardell, cell [phone], [e-mail]





Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h06LTPa18206 for ietf-pkix-bks; Mon, 6 Jan 2003 13:29:25 -0800 (PST)
Received: from woodstock.binhost.com (woodstock.binhost.com [207.228.252.5]) by above.proper.com (8.11.6/8.11.3) with SMTP id h06LTNo18202 for <[e-mail]>; Mon, 6 Jan 2003 13:29:24 -0800 (PST)
Received: (qmail 28156 invoked from network); 6 Jan 2003 21:28:54 -0000
Received: from unknown (HELO Russ-Laptop.vigilsec.com) (141.156.219.29) by woodstock.binhost.com with SMTP; 6 Jan 2003 21:28:54 -0000
Message-Id: <[e-mail]>
X-Sender: [e-mail] (Unverified)
X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9
Date: Mon, 06 Jan 2003 16:28:47 -0500
To: Timothy Hahn <[e-mail]>
From: Russ Housley <[e-mail]>
Subject: Re: LDAP PKI Schema (was Re: No-op LDAP ;binary option)
Cc: [e-mail]
In-Reply-To: <OF7746540B.FD6FD177-ON85256CA6.006E6D27-85256CA6.006F3704@ us.ibm.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Tim:

I do not understand how a client is better off with multiple ways to put 
the same information in the Directory.  Doesn't this approach just make the 
client fat?  It seem to me that the client would have to support all of the 
possible ways that the information could be stored.  It cannot know which 
method it will encounter until it starts looking at data in the Directory.

Russ


At 03:14 PM 1/6/2003 -0500, Timothy Hahn wrote:
>Hello all,
>
>After listening to the different view-points on this topic, it seems to me
>that there are multiple valid approaches.  These approaches include, but
>are not limited to:
>   - leveraging the general solution of component-matching
>   - new schema to support application-managed componentization of
>information to make things searchable
>as well as others (additional matching rules, for example).
>
>It occurs to me that perhaps we have a situation where "one size does not
>fit all".  Why not accept this and define a way for applications to
>determine which (of possibly multiple) format(s) has been used to place the
>information into the directory?  We could define some small bit of schema
>which indicates the way in which the certificate information is placed into
>the directory, then different applications could query this and determine:
>   - whether they can use the data at all
>   - if they can use the data, how they can best use it (if there are, for
>example, multiple mechanisms employed).
>
>Just a thought to get us through this discussion.
>
>Regards,
>Tim Hahn



Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h06KEtn13768 for ietf-pkix-bks; Mon, 6 Jan 2003 12:14:55 -0800 (PST)
Received: from e5.ny.us.ibm.com (e5.ny.us.ibm.com [32.97.182.105]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h06KEpo13750 for <[e-mail]>; Mon, 6 Jan 2003 12:14:51 -0800 (PST)
Received: from northrelay04.pok.ibm.com (northrelay04.pok.ibm.com [9.56.224.206]) by e5.ny.us.ibm.com (8.12.2/8.12.2) with ESMTP id h06KEmmd134428 for <[e-mail]>; Mon, 6 Jan 2003 15:14:48 -0500
Received: from d01hub03.pok.ibm.com (d01av02.pok.ibm.com [9.56.224.216]) by northrelay04.pok.ibm.com (8.12.3/NCO/VER6.4) with ESMTP id h06KEjfI056846 for <[e-mail]>; Mon, 6 Jan 2003 15:14:46 -0500
To: [e-mail]
MIME-Version: 1.0
Subject: Re: LDAP PKI Schema (was Re: No-op LDAP ;binary option)
X-Mailer: Lotus Notes Release 6.0 September 26, 2002
From: Timothy Hahn <[e-mail]>
X-MIMETrack: S/MIME Sign by Notes Client on Timothy Hahn/Durham/IBM(Release 6.0|September 26, 2002) at 01/06/2003 03:14:07 PM, Serialize by Notes Client on Timothy Hahn/Durham/IBM(Release 6.0|September 26, 2002) at 01/06/2003 03:14:07 PM, Serialize complete at 01/06/2003 03:14:07 PM, Itemize by Notes Client on Timothy Hahn/Durham/IBM(Release 6.0|September 26, 2002) at 01/06/2003 03:14:07 PM, S/MIME Sign complete at 01/06/2003 03:14:07 PM, S/MIME Sign by Notes Client on Timothy Hahn/Durham/IBM(Release 6.0|September 26, 2002) at 01/06/2003 03:14:45 PM, S/MIME Sign complete at 01/06/2003 03:14:45 PM, MIME-CD by Router on D01MLC96/01/M/IBM(Build V601_12152002 SPR MIAS5GXKFV CBOD5GVRDB|December 20, 2002) at 01/06/2003 15:14:46, MIME-CD complete at 01/06/2003 15:14:46, Serialize by Router on D01HUB03/01/H/IBM(Release 6.0 [IBM]|December 22, 2002) at 01/06/2003 15:14:45
Message-ID: <[e-mail]>
Date: Mon, 6 Jan 2003 15:14:45 -0500
Content-type: multipart/mixed;  Boundary="0__=0ABBE635DFFDEBB78f9e8a93df938690918c0ABBE635DFFDEBB7"
Content-Disposition: inline
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

--0__=0ABBE635DFFDEBB78f9e8a93df938690918c0ABBE635DFFDEBB7
Content-type: text/plain; charset=ISO-8859-1
Content-transfer-encoding: quoted-printable




Hello all,

After listening to the different view-points on this topic, it seems to=
 me
that there are multiple valid approaches. =A0These approaches include, =
but
are not limited to:
=A0 - leveraging the general solution of component-matching
=A0 - new schema to support application-managed componentization of
information to make things searchable
as well as others (additional matching rules, for example).

It occurs to me that perhaps we have a situation where "one size does n=
ot
fit all". =A0Why not accept this and define a way for applications to
determine which (of possibly multiple) format(s) has been used to place=
 the
information into the directory? =A0We could define some small bit of sc=
hema
which indicates the way in which the certificate information is placed =
into
the directory, then different applications could query this and determi=
ne:
=A0 - whether they can use the data at all
=A0 - if they can use the data, how they can best use it (if there are,=
 for
example, multiple mechanisms employed).

Just a thought to get us through this discussion.

Regards,
Tim Hahn

Internet: [e-mail]
Internal: Timothy Hahn/Durham/IBM@IBMUS
phone: [phone] =A0 =A0 tie-line: 8/687.1565
fax: [phone]
=

--0__=0ABBE635DFFDEBB78f9e8a93df938690918c0ABBE635DFFDEBB7
Content-type: application/octet-stream; 
	name="=?ISO-8859-1?Q?smime=2Ep7s?="
Content-Disposition: attachment; filename="=?ISO-8859-1?Q?smime=2Ep7s?="
Content-transfer-encoding: base64

MIAGCSqGSIb3DQEHAqCAMIIULwIBATELMAkGBSsOAwIaBQAwCwYJKoZIhvcNAQcBoIISUDCCAtow
ggJDoAMCAQICAwMUtjANBgkqhkiG9w0BAQQFADBOMQswCQYDVQQGEwJVUzEQMA4GA1UEChMHRXF1
aWZheDEtMCsGA1UECxMkRXF1aWZheCBTZWN1cmUgQ2VydGlmaWNhdGUgQXV0aG9yaXR5MB4XDTAy
MDExNDIyMDcxMVoXDTExMTIzMTIyMDcxMVowaTELMAkGA1UEBhMCVVMxNDAyBgNVBAoTK0ludGVy
bmF0aW9uYWwgQnVzaW5lc3MgTWFjaGluZXMgQ29ycG9yYXRpb24xJDAiBgNVBAMTG0lCTSBDZXJ0
aWZpY2F0aW9uIEF1dGhvcml0eTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEA629xc49NpAPz
cAsuShTImLRYMkyepDEkC1UrPbsFRyAFZKsv3pw0MGfW/+7glzJKgPkPzlTZZfznznGbmAWVnNBQ
lyPasOtCjif603euRXReHcKfHMPLItKozibWIPHJuOnwNclOnnP2sKufuPzbTImQTTi5c8JZNZcM
J0YFzTcCAwEAAaOBqjCBpzARBglghkgBhvhCAQEEBAMCAIcwDgYDVR0PAQH/BAQDAgHGMB0GA1Ud
DgQWBBSuVA6S6qgzqSskLcfIbzDc3vNKQDAfBgNVHSMEGDAWgBRI5mj5K9KylddH2CMgEE8zmJCf
1DAPBgNVHRMBAf8EBTADAQH/MDEGA1UdJQQqMCgGCCsGAQUFBwMBBggrBgEFBQcDAgYIKwYBBQUH
AwMGCCsGAQUFBwMEMA0GCSqGSIb3DQEBBAUAA4GBADJye3NmC8q2PzypRZfu7JvDRDX1rRcanZvu
jQupk2oCScMd3FIHLE7hOfu8YffvxtLU3y8wNamQEORjTD175qAffryXypwtiVjBUKSDlBCQ14ke
McF9ViNdewEoBGiAycUq8R3Lrlf4TCDvW4GeguNTFFZnS0ygYATiJk7iDyvEMIIC2jCCAkOgAwIB
AgIDAxS2MA0GCSqGSIb3DQEBBAUAME4xCzAJBgNVBAYTAlVTMRAwDgYDVQQKEwdFcXVpZmF4MS0w
KwYDVQQLEyRFcXVpZmF4IFNlY3VyZSBDZXJ0aWZpY2F0ZSBBdXRob3JpdHkwHhcNMDIwMTE0MjIw
NzExWhcNMTExMjMxMjIwNzExWjBpMQswCQYDVQQGEwJVUzE0MDIGA1UEChMrSW50ZXJuYXRpb25h
bCBCdXNpbmVzcyBNYWNoaW5lcyBDb3Jwb3JhdGlvbjEkMCIGA1UEAxMbSUJNIENlcnRpZmljYXRp
b24gQXV0aG9yaXR5MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDrb3Fzj02kA/NwCy5KFMiY
tFgyTJ6kMSQLVSs9uwVHIAVkqy/enDQwZ9b/7uCXMkqA+Q/OVNll/OfOcZuYBZWc0FCXI9qw60KO
J/rTd65FdF4dwp8cw8si0qjOJtYg8cm46fA1yU6ec/awq5+4/NtMiZBNOLlzwlk1lwwnRgXNNwID
AQABo4GqMIGnMBEGCWCGSAGG+EIBAQQEAwIAhzAOBgNVHQ8BAf8EBAMCAcYwHQYDVR0OBBYEFK5U
DpLqqDOpKyQtx8hvMNze80pAMB8GA1UdIwQYMBaAFEjmaPkr0rKV10fYIyAQTzOYkJ/UMA8GA1Ud
EwEB/wQFMAMBAf8wMQYDVR0lBCowKAYIKwYBBQUHAwEGCCsGAQUFBwMCBggrBgEFBQcDAwYIKwYB
BQUHAwQwDQYJKoZIhvcNAQEEBQADgYEAMnJ7c2YLyrY/PKlFl+7sm8NENfWtFxqdm+6NC6mTagJJ
wx3cUgcsTuE5+7xh9+/G0tTfLzA1qZAQ5GNMPXvmoB9+vJfKnC2JWMFQpIOUEJDXiR4xwX1WI117
ASgEaIDJxSrxHcuuV/hMIO9bgZ6C41MUVmdLTKBgBOImTuIPK8QwggMgMIICiaADAgECAgQ13vTP
MA0GCSqGSIb3DQEBBQUAME4xCzAJBgNVBAYTAlVTMRAwDgYDVQQKEwdFcXVpZmF4MS0wKwYDVQQL
EyRFcXVpZmF4IFNlY3VyZSBDZXJ0aWZpY2F0ZSBBdXRob3JpdHkwHhcNOTgwODIyMTY0MTUxWhcN
MTgwODIyMTY0MTUxWjBOMQswCQYDVQQGEwJVUzEQMA4GA1UEChMHRXF1aWZheDEtMCsGA1UECxMk
RXF1aWZheCBTZWN1cmUgQ2VydGlmaWNhdGUgQXV0aG9yaXR5MIGfMA0GCSqGSIb3DQEBAQUAA4GN
ADCBiQKBgQDBXbFYZwhi7qCaLR8IbZEUaJgKHv7aBG8ThGIhw9F8zp8F4LgB8E407OKKlQRkrPFr
U18Fs8tngL9CAo7+3QEJ7OEAFE/8+/AM3UO6WyvhH4BwmRVXkxbxD5dqt8JoIxzMTVkwrFEeO68r
1u5jRXvF2V9Q0uNQDzqI578U/eDHuQIDAQABo4IBCTCCAQUwcAYDVR0fBGkwZzBloGOgYaRfMF0x
CzAJBgNVBAYTAlVTMRAwDgYDVQQKEwdFcXVpZmF4MS0wKwYDVQQLEyRFcXVpZmF4IFNlY3VyZSBD
ZXJ0aWZpY2F0ZSBBdXRob3JpdHkxDTALBgNVBAMTBENSTDEwGgYDVR0QBBMwEYEPMjAxODA4MjIx
NjQxNTFaMAsGA1UdDwQEAwIBBjAfBgNVHSMEGDAWgBRI5mj5K9KylddH2CMgEE8zmJCf1DAdBgNV
HQ4EFgQUSOZo+SvSspXXR9gjIBBPM5iQn9QwDAYDVR0TBAUwAwEB/zAaBgkqhkiG9n0HQQAEDTAL
GwVWMy4wYwMCBsAwDQYJKoZIhvcNAQEFBQADgYEAWM4p6vz33rXOArkXtYXRuePglcwlMQ0AppJu
f7aSY55QldGab+QR3mOFbpjuqP9ayNNVsmZxV97AIes9KqcjSQEEhkJ7/O5/ohZStWdn00DbOyZY
sih3Pa4Ud2HW+ipmJ6AN+qdzXOpw8ZQhZURf+vzvKWipood573nvT6wHdzgwggMgMIICiaADAgEC
AgQ13vTPMA0GCSqGSIb3DQEBBQUAME4xCzAJBgNVBAYTAlVTMRAwDgYDVQQKEwdFcXVpZmF4MS0w
KwYDVQQLEyRFcXVpZmF4IFNlY3VyZSBDZXJ0aWZpY2F0ZSBBdXRob3JpdHkwHhcNOTgwODIyMTY0
MTUxWhcNMTgwODIyMTY0MTUxWjBOMQswCQYDVQQGEwJVUzEQMA4GA1UEChMHRXF1aWZheDEtMCsG
A1UECxMkRXF1aWZheCBTZWN1cmUgQ2VydGlmaWNhdGUgQXV0aG9yaXR5MIGfMA0GCSqGSIb3DQEB
AQUAA4GNADCBiQKBgQDBXbFYZwhi7qCaLR8IbZEUaJgKHv7aBG8ThGIhw9F8zp8F4LgB8E407OKK
lQRkrPFrU18Fs8tngL9CAo7+3QEJ7OEAFE/8+/AM3UO6WyvhH4BwmRVXkxbxD5dqt8JoIxzMTVkw
rFEeO68r1u5jRXvF2V9Q0uNQDzqI578U/eDHuQIDAQABo4IBCTCCAQUwcAYDVR0fBGkwZzBloGOg
YaRfMF0xCzAJBgNVBAYTAlVTMRAwDgYDVQQKEwdFcXVpZmF4MS0wKwYDVQQLEyRFcXVpZmF4IFNl
Y3VyZSBDZXJ0aWZpY2F0ZSBBdXRob3JpdHkxDTALBgNVBAMTBENSTDEwGgYDVR0QBBMwEYEPMjAx
ODA4MjIxNjQxNTFaMAsGA1UdDwQEAwIBBjAfBgNVHSMEGDAWgBRI5mj5K9KylddH2CMgEE8zmJCf
1DAdBgNVHQ4EFgQUSOZo+SvSspXXR9gjIBBPM5iQn9QwDAYDVR0TBAUwAwEB/zAaBgkqhkiG9n0H
QQAEDTALGwVWMy4wYwMCBsAwDQYJKoZIhvcNAQEFBQADgYEAWM4p6vz33rXOArkXtYXRuePglcwl
MQ0AppJuf7aSY55QldGab+QR3mOFbpjuqP9ayNNVsmZxV97AIes9KqcjSQEEhkJ7/O5/ohZStWdn
00DbOyZYsih3Pa4Ud2HW+ipmJ6AN+qdzXOpw8ZQhZURf+vzvKWipood573nvT6wHdzgwggMiMIIC
i6ADAgECAgJONTANBgkqhkiG9w0BAQQFADBpMQswCQYDVQQGEwJVUzE0MDIGA1UEChMrSW50ZXJu
YXRpb25hbCBCdXNpbmVzcyBNYWNoaW5lcyBDb3Jwb3JhdGlvbjEkMCIGA1UEAxMbSUJNIENlcnRp
ZmljYXRpb24gQXV0aG9yaXR5MB4XDTAyMTEyMTEzMDY1M1oXDTAzMTIwNTEzMDY1M1owgYQxCzAJ
BgNVBAYTAlVTMQwwCgYDVQQKEwNJQk0xETAPBgNVBAsTCEVNUExPWUVFMRgwFgYDVQQDEw9UaW1v
dGh5IEouIEhhaG4xGTAXBgoJkiaJk/IsZAEBEwkxMjg4NTc4OTcxHzAdBgkqhkiG9w0BCQEWEGhh
aG50QHVzLmlibS5jb20wgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBAMZRHQYCNd56O2LkRqmV
bpvr70BMnmNf+UWqMbgJ0v8Y5Vb3hdrThAoyNs3XKbFl9oYir3AFiZHVPUpFM2anK8+Sb9IqzfIh
g/x6Tu9wVHPXkve+wBCGneHD2GgvIx7NEECdr7YuOd7SWevXcLloLu3yQ7Hb2aZ1MQ8o78M9S7K1
AgMBAAGjgbwwgbkwEQYJYIZIAYb4QgEBBAQDAgWgMA4GA1UdDwEB/wQEAwIF4DAdBgNVHQ4EFgQU
z9GrkTcJqnyWERTvptgBPQmzC/QwKwYDVR0RBCQwIqAgBgorBgEEAYI3FAIDoBIMEGhhaG50QHVz
LmlibS5jb20wHwYDVR0jBBgwFoAUrlQOkuqoM6krJC3HyG8w3N7zSkAwJwYDVR0lBCAwHgYIKwYB
BQUHAwIGCCsGAQUFBwMDBggrBgEFBQcDBDANBgkqhkiG9w0BAQQFAAOBgQCHcqGsmuSPRftlK36s
f5HfVXRhzCbH63xR5jLTpzFIfzoNo8u8yeC2yu81Ylj3rLzKmcwNtb9rkQT+wqWJH498ECe66dOQ
6tUDHk3VYGYZ3QrerjTBWBnKoekfUMcp+9xtjsHYVfMEopW/0FU6QsMwj3vouSy6Uv5nTGxKIi73
ZzCCAyIwggKLoAMCAQICAk41MA0GCSqGSIb3DQEBBAUAMGkxCzAJBgNVBAYTAlVTMTQwMgYDVQQK
EytJbnRlcm5hdGlvbmFsIEJ1c2luZXNzIE1hY2hpbmVzIENvcnBvcmF0aW9uMSQwIgYDVQQDExtJ
Qk0gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkwHhcNMDIxMTIxMTMwNjUzWhcNMDMxMjA1MTMwNjUz
WjCBhDELMAkGA1UEBhMCVVMxDDAKBgNVBAoTA0lCTTERMA8GA1UECxMIRU1QTE9ZRUUxGDAWBgNV
BAMTD1RpbW90aHkgSi4gSGFobjEZMBcGCgmSJomT8ixkAQETCTEyODg1Nzg5NzEfMB0GCSqGSIb3
DQEJARYQaGFobnRAdXMuaWJtLmNvbTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAxlEdBgI1
3no7YuRGqZVum+vvQEyeY1/5RaoxuAnS/xjlVveF2tOECjI2zdcpsWX2hiKvcAWJkdU9SkUzZqcr
z5Jv0irN8iGD/HpO73BUc9eS977AEIad4cPYaC8jHs0QQJ2vti453tJZ69dwuWgu7fJDsdvZpnUx
Dyjvwz1LsrUCAwEAAaOBvDCBuTARBglghkgBhvhCAQEEBAMCBaAwDgYDVR0PAQH/BAQDAgXgMB0G
A1UdDgQWBBTP0auRNwmqfJYRFO+m2AE9CbML9DArBgNVHREEJDAioCAGCisGAQQBgjcUAgOgEgwQ
aGFobnRAdXMuaWJtLmNvbTAfBgNVHSMEGDAWgBSuVA6S6qgzqSskLcfIbzDc3vNKQDAnBgNVHSUE
IDAeBggrBgEFBQcDAgYIKwYBBQUHAwMGCCsGAQUFBwMEMA0GCSqGSIb3DQEBBAUAA4GBAIdyoaya
5I9F+2Urfqx/kd9VdGHMJsfrfFHmMtOnMUh/Og2jy7zJ4LbK7zViWPesvMqZzA21v2uRBP7CpYkf
j3wQJ7rp05Dq1QMeTdVgZhndCt6uNMFYGcqh6R9Qxyn73G2OwdhV8wSilb/QVTpCwzCPe+i5LLpS
/mdMbEoiLvdnMYIBujCCAbYCAQEwbzBpMQswCQYDVQQGEwJVUzE0MDIGA1UEChMrSW50ZXJuYXRp
b25hbCBCdXNpbmVzcyBNYWNoaW5lcyBDb3Jwb3JhdGlvbjEkMCIGA1UEAxMbSUJNIENlcnRpZmlj
YXRpb24gQXV0aG9yaXR5AgJONTAJBgUrDgMCGgUAoIGiMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0B
BwEwHAYJKoZIhvcNAQkFMQ8XDTAzMDEwNjIwMTQwN1owIwYJKoZIhvcNAQkEMRYEFEw949jhi8Vo
OowQG+xHD56xHhe/MEMGCSqGSIb3DQEJDzE2MDQwBwYFKw4DAh0wDgYIKoZIhvcNAwICAgCAMAoG
CCqGSIb3DQMHMA0GCCqGSIb3DQMCAgEoMA0GCSqGSIb3DQEBAQUABIGAlIETn5YN6CdoxL44n0qT
iWUBhF+2QL/DZKxWGMx3wtCMIELh3HoHDG0kAXXgSl81HlNXIhyFpNQAOTRe9VEqZ/J1oEzup8jZ
QAltLAdwjY+qDzVV6CiF9x/T1Fzo566nSdt04GoymbupsXlZN62Du0r2G3Zhof5GJTn1iAiGlQgA
AAAA

--0__=0ABBE635DFFDEBB78f9e8a93df938690918c0ABBE635DFFDEBB7--



Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h06EZwL24857 for ietf-pkix-bks; Mon, 6 Jan 2003 06:35:58 -0800 (PST)
Received: from mail.hackmasters.net (ppp-217-133-8-148.dialup.tiscali.it [217.133.8.148]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h06EZro24841 for <[e-mail]>; Mon, 6 Jan 2003 06:35:54 -0800 (PST)
Received: from localhost (localhost.localdomain [127.0.0.1]) by mail.hackmasters.net (Postfix) with ESMTP id 7C8F2F356 for <[e-mail]>; Mon,  6 Jan 2003 15:34:45 +0100 (CET)
Received: by mail.hackmasters.net (Postfix, from userid 509) id 04AA8F35C; Mon,  6 Jan 2003 15:34:39 +0100 (CET)
Received: from hackmasters.net (galadriel.mpnet.hackmasters.net [10.5.122.180]) by mail.hackmasters.net (Postfix) with ESMTP id E7200F356 for <[e-mail]>; Mon,  6 Jan 2003 15:34:36 +0100 (CET)
Message-ID: <[e-mail]>
Date: Mon, 06 Jan 2003 15:36:51 +0100
From: Massimiliano Pala <[e-mail]>
Organization: OpenCA
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.2.1) Gecko/20021130
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: [e-mail]
Subject: Re: OCSP and LDAP
References: <[e-mail]>
In-Reply-To: <[e-mail]>
Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms030100040009040907050700"
X-Virus-Scanned: by AMaViS perl-11
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

This is a cryptographically signed message in MIME format.

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

[e-mail] wrote:


> Then the certificate policy under which the EE cert was issued
> is inappropriate for the use to which the certificate itself is
> being put. If the EE requires up-to-the-minute revocation
> information to be available to it's correspondents then it
> should make sure it is using a CA that can fulfil these
> requirements. Legality first, technology second.

I understand your point and I do agree with you that the policy is at the
first place when setting up a CA.

Anyway I do not agree with you when you state that this is the only way,
at least now that there is the OCSP. As I stated in my last email my
question was about the best method of doing things was, but still I
think the OCSP can behave better than the old CRL mechanisms, otherwise
why implementing OCSP when the client could check the CRL by itself ?

Anyway thank to you all for sharing your point of view on the subject,
although I assume I am the only one supporting this approach to the
OCSP (right?) :-(

-- 

C'you,

	Massimiliano Pala

--o-------------------------------------------------------------------------
Massimiliano Pala [OpenCA Project Manager]                [e-mail]
                                                  Tel.:   [phone]
http://www.openca.org                            Fax:    +39   178  221 8225
http://openca.sourceforge.net                    Mobile: [phone]

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

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIOZjCC
By8wggYXoAMCAQICASwwDQYJKoZIhvcNAQEEBQAwgYoxIjAgBgkqhkiG9w0BCQEWE3BraS5j
aWNhaWFAdW5pbW8uaXQxJzAlBgNVBAMTHlVuaW1vcmUgRW50ZSBkaSBDZXJ0aWZpY2F6aW9u
ZTEuMCwGA1UEChMlVW5pdmVyc2l0YScgZGkgTW9kZW5hIGUgUmVnZ2lvIEVtaWxpYTELMAkG
A1UEBhMCSVQwHhcNMDIwNzI0MTUyNjI2WhcNMDMxMjMxMjM1OTU5WjCBqTEaMBgGA1UEAxMR
TWFzc2ltaWxpYW5vIFBhbGExNTAzBgNVBAsTLERpcGFydGltZW50byBkaSBJbmdlZ25lcmlh
IGRlbGwnSW5mb3JtYXppb25lMRcwFQYDVQQLEw5TZWRlIGRpIE1vZGVuYTEuMCwGA1UEChMl
VW5pdmVyc2l0YScgZGkgTW9kZW5hIGUgUmVnZ2lvIEVtaWxpYTELMAkGA1UEBhMCSVQwgZ8w
DQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBANSesg80BGzryvQlplD0MJ2YWlSEUAZpiFmywpOm
l//lWMnhONmC/q0TrO7j9Bb195dNzCMuXFgvV49Sy1iyHAjDhpysFvm/xZbAS3j8prXNN23K
S3Oa7Zz2GrQpCHgupCPQL2cy+ARVwwFod2GOSCVoUACkndit964K/bfsGvyLAgMBAAGjggQB
MIID/TAMBgNVHRMBAf8EAjAAMBEGCWCGSAGG+EIBAQQEAwIFoDAOBgNVHQ8BAf8EBAMCA/gw
HQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMB0GA1UdDgQWBBT6aSO5yTMPTf9OdcWo
14pKLqEHMDCBtwYDVR0jBIGvMIGsgBRFHaYA4ZfoyU2aaUnZYMiYf4lFA6GBkKSBjTCBijEi
MCAGCSqGSIb3DQEJARYTcGtpLmNpY2FpYUB1bmltby5pdDEnMCUGA1UEAxMeVW5pbW9yZSBF
bnRlIGRpIENlcnRpZmljYXppb25lMS4wLAYDVQQKEyVVbml2ZXJzaXRhJyBkaSBNb2RlbmEg
ZSBSZWdnaW8gRW1pbGlhMQswCQYDVQQGEwJJVIIBADBqBglghkgBhvhCAQ0EXRZbUHJvZ2V0
dG8gUG9zdGEgRWxldHRyb25pY2EgU2ljdXJhIA0KVW5pdmVyc2l0YScgZGkgTW9kZW5hIGUg
UmVnZ2lvIEVtaWxpYSANCkMuSS5DLkEuSS5BLiANCjAiBgNVHREEGzAZgRdtYWR3b2xmQGhh
Y2ttYXN0ZXJzLm5ldDA0BgNVHRIELTArgRNwa2kuY2ljYWlhQHVuaW1vLml0hhRodHRwOi8v
cGtpLnVuaW1vLml0LzA/BggrBgEFBQcBAQQzMDEwLwYIKwYBBQUHMAKGI2h0dHA6Ly9wa2ku
dW5pbW8uaXQvY2EvaXNzdWVycy5odG1sMDIGA1UdHwQrMCkwJ6AloCOGIWh0dHA6Ly9wa2ku
dW5pbW8uaXQvY3JsL2NhY3JsLmNybDAwBglghkgBhvhCAQQEIxYhaHR0cDovL3BraS51bmlt
by5pdC9jcmwvY2FjcmwuY3JsMDAGCWCGSAGG+EIBAwQjFiFodHRwOi8vcGtpLnVuaW1vLml0
L2NybC9jYWNybC5jcmwwKgYJYIZIAYb4QgEHBB0WG2h0dHA6Ly9wa2kudW5pbW8uaXQvcmVu
ZXdhbDArBglghkgBhvhCAQgEHhYcaHR0cDovL3BraS51bmltby5pdC9jcHMvMS4xLzCB2QYD
VR0gBIHRMIHOMEMGCisGAQQBqQcBAQEwNTAzBggrBgEFBQcCARYnaHR0cDovL3d3dy5ldXJv
cGtpLm9yZy9jYS9yb290L2Nwcy8xLjEvMEEGCisGAQQBqQcCAQEwMzAxBggrBgEFBQcCARYl
aHR0cDovL3d3dy5ldXJvcGtpLm9yZy9jYS9pdC9jcHMvMS4xLzBEBgorBgEEAegTAQEBMDYw
NAYIKwYBBQUHAgEWKGh0dHA6Ly9tYWlsLnVuaW1vLml0L2Zpcm1hL2Nwc21vZGVuYS5odG0w
DQYJKoZIhvcNAQEEBQADggEBABn8ViNg4MPNRzEFFF4BsmRMP1YbUHbS+NmFvvys0D3xueex
Ie6HU+tkv9hz8++0MbLPnRY2qKpZXfWTbIOkrHLGVVHUkiZXFzfxsDMgcB4MWmSmhRVLfPqr
RZKAjIevO0JKIksq2xutAUqX5jkqZoGHpPv9JCiSI+cDRqOOW2Fh3JBGkcULKybrdwrSN6+S
NoTyTXR+ryeTBUXxu9rIbjrJdH3rKS7rz3ZkP2PKuFOb+Vbp829ALph1SJOLQrUnmJouLOSL
oVHW4zJK4zcAiNyMHua3HveLRkVINT9eDBeYBRPdn1k+LqdXqkXiEUPA+EIKeA23F5nQkqxI
mVVpaaYwggcvMIIGF6ADAgECAgEsMA0GCSqGSIb3DQEBBAUAMIGKMSIwIAYJKoZIhvcNAQkB
FhNwa2kuY2ljYWlhQHVuaW1vLml0MScwJQYDVQQDEx5Vbmltb3JlIEVudGUgZGkgQ2VydGlm
aWNhemlvbmUxLjAsBgNVBAoTJVVuaXZlcnNpdGEnIGRpIE1vZGVuYSBlIFJlZ2dpbyBFbWls
aWExCzAJBgNVBAYTAklUMB4XDTAyMDcyNDE1MjYyNloXDTAzMTIzMTIzNTk1OVowgakxGjAY
BgNVBAMTEU1hc3NpbWlsaWFubyBQYWxhMTUwMwYDVQQLEyxEaXBhcnRpbWVudG8gZGkgSW5n
ZWduZXJpYSBkZWxsJ0luZm9ybWF6aW9uZTEXMBUGA1UECxMOU2VkZSBkaSBNb2RlbmExLjAs
BgNVBAoTJVVuaXZlcnNpdGEnIGRpIE1vZGVuYSBlIFJlZ2dpbyBFbWlsaWExCzAJBgNVBAYT
AklUMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDUnrIPNARs68r0JaZQ9DCdmFpUhFAG
aYhZssKTppf/5VjJ4TjZgv6tE6zu4/QW9feXTcwjLlxYL1ePUstYshwIw4acrBb5v8WWwEt4
/Ka1zTdtyktzmu2c9hq0KQh4LqQj0C9nMvgEVcMBaHdhjkglaFAApJ3YrfeuCv237Br8iwID
AQABo4IEATCCA/0wDAYDVR0TAQH/BAIwADARBglghkgBhvhCAQEEBAMCBaAwDgYDVR0PAQH/
BAQDAgP4MB0GA1UdJQQWMBQGCCsGAQUFBwMCBggrBgEFBQcDBDAdBgNVHQ4EFgQU+mkjuckz
D03/TnXFqNeKSi6hBzAwgbcGA1UdIwSBrzCBrIAURR2mAOGX6MlNmmlJ2WDImH+JRQOhgZCk
gY0wgYoxIjAgBgkqhkiG9w0BCQEWE3BraS5jaWNhaWFAdW5pbW8uaXQxJzAlBgNVBAMTHlVu
aW1vcmUgRW50ZSBkaSBDZXJ0aWZpY2F6aW9uZTEuMCwGA1UEChMlVW5pdmVyc2l0YScgZGkg
TW9kZW5hIGUgUmVnZ2lvIEVtaWxpYTELMAkGA1UEBhMCSVSCAQAwagYJYIZIAYb4QgENBF0W
W1Byb2dldHRvIFBvc3RhIEVsZXR0cm9uaWNhIFNpY3VyYSANClVuaXZlcnNpdGEnIGRpIE1v
ZGVuYSBlIFJlZ2dpbyBFbWlsaWEgDQpDLkkuQy5BLkkuQS4gDQowIgYDVR0RBBswGYEXbWFk
d29sZkBoYWNrbWFzdGVycy5uZXQwNAYDVR0SBC0wK4ETcGtpLmNpY2FpYUB1bmltby5pdIYU
aHR0cDovL3BraS51bmltby5pdC8wPwYIKwYBBQUHAQEEMzAxMC8GCCsGAQUFBzAChiNodHRw
Oi8vcGtpLnVuaW1vLml0L2NhL2lzc3VlcnMuaHRtbDAyBgNVHR8EKzApMCegJaAjhiFodHRw
Oi8vcGtpLnVuaW1vLml0L2NybC9jYWNybC5jcmwwMAYJYIZIAYb4QgEEBCMWIWh0dHA6Ly9w
a2kudW5pbW8uaXQvY3JsL2NhY3JsLmNybDAwBglghkgBhvhCAQMEIxYhaHR0cDovL3BraS51
bmltby5pdC9jcmwvY2FjcmwuY3JsMCoGCWCGSAGG+EIBBwQdFhtodHRwOi8vcGtpLnVuaW1v
Lml0L3JlbmV3YWwwKwYJYIZIAYb4QgEIBB4WHGh0dHA6Ly9wa2kudW5pbW8uaXQvY3BzLzEu
MS8wgdkGA1UdIASB0TCBzjBDBgorBgEEAakHAQEBMDUwMwYIKwYBBQUHAgEWJ2h0dHA6Ly93
d3cuZXVyb3BraS5vcmcvY2Evcm9vdC9jcHMvMS4xLzBBBgorBgEEAakHAgEBMDMwMQYIKwYB
BQUHAgEWJWh0dHA6Ly93d3cuZXVyb3BraS5vcmcvY2EvaXQvY3BzLzEuMS8wRAYKKwYBBAHo
EwEBATA2MDQGCCsGAQUFBwIBFihodHRwOi8vbWFpbC51bmltby5pdC9maXJtYS9jcHNtb2Rl
bmEuaHRtMA0GCSqGSIb3DQEBBAUAA4IBAQAZ/FYjYODDzUcxBRReAbJkTD9WG1B20vjZhb78
rNA98bnnsSHuh1PrZL/Yc/PvtDGyz50WNqiqWV31k2yDpKxyxlVR1JImVxc38bAzIHAeDFpk
poUVS3z6q0WSgIyHrztCSiJLKtsbrQFKl+Y5KmaBh6T7/SQokiPnA0ajjlthYdyQRpHFCysm
63cK0jevkjaE8k10fq8nkwVF8bvayG46yXR96yku6892ZD9jyrhTm/lW6fNvQC6YdUiTi0K1
J5iaLizki6FR1uMySuM3AIjcjB7mtx73i0ZFSDU/XgwXmAUT3Z9ZPi6nV6pF4hFDwPhCCngN
txeZ0JKsSJlVaWmmMYIDNjCCAzICAQEwgZAwgYoxIjAgBgkqhkiG9w0BCQEWE3BraS5jaWNh
aWFAdW5pbW8uaXQxJzAlBgNVBAMTHlVuaW1vcmUgRW50ZSBkaSBDZXJ0aWZpY2F6aW9uZTEu
MCwGA1UEChMlVW5pdmVyc2l0YScgZGkgTW9kZW5hIGUgUmVnZ2lvIEVtaWxpYTELMAkGA1UE
BhMCSVQCASwwCQYFKw4DAhoFAKCCAfswGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkq
hkiG9w0BCQUxDxcNMDMwMTA2MTQzNjUxWjAjBgkqhkiG9w0BCQQxFgQUkYsVhagk+f8LBQ2M
dLu8b5QHAQMwUgYJKoZIhvcNAQkPMUUwQzAKBggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAw
DQYIKoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZIhvcNAwICASgwgaEGCSsGAQQBgjcQBDGB
kzCBkDCBijEiMCAGCSqGSIb3DQEJARYTcGtpLmNpY2FpYUB1bmltby5pdDEnMCUGA1UEAxMe
VW5pbW9yZSBFbnRlIGRpIENlcnRpZmljYXppb25lMS4wLAYDVQQKEyVVbml2ZXJzaXRhJyBk
aSBNb2RlbmEgZSBSZWdnaW8gRW1pbGlhMQswCQYDVQQGEwJJVAIBLDCBowYLKoZIhvcNAQkQ
AgsxgZOggZAwgYoxIjAgBgkqhkiG9w0BCQEWE3BraS5jaWNhaWFAdW5pbW8uaXQxJzAlBgNV
BAMTHlVuaW1vcmUgRW50ZSBkaSBDZXJ0aWZpY2F6aW9uZTEuMCwGA1UEChMlVW5pdmVyc2l0
YScgZGkgTW9kZW5hIGUgUmVnZ2lvIEVtaWxpYTELMAkGA1UEBhMCSVQCASwwDQYJKoZIhvcN
AQEBBQAEgYAbcUhmtGmJVVJghN3PZcn3i3z+MZupI/l42QHdhtFfOdYhqVAsB9mcDVL6ZLxY
5oeuUy0rhK7N5eBMNmaporbhzSlbs0aETn8to/7r1BoikLdG75zVWl7wf517TzzvtaN1+cV4
p7Ts6KNeu8LHaLIAusOb+l8PZNbtKOfbsU6SWgAAAAAAAA==
--------------ms030100040009040907050700--



Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h06EG3R22744 for ietf-pkix-bks; Mon, 6 Jan 2003 06:16:03 -0800 (PST)
Received: from mail4.consignia.com (mail4.consignia.com [144.87.143.84]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h06EG1o22738 for <[e-mail]>; Mon, 6 Jan 2003 06:16:01 -0800 (PST)
Received: from postoffice.co.uk (mta1.int.consignia.com [144.87.146.14]) by mail4.consignia.com (Postfix) with SMTP id DE7E4122131; Mon,  6 Jan 2003 14:15:58 +0000 (GMT)
Received: by postoffice.co.uk(Lotus SMTP MTA v4.6.6  (890.1 7-16-1999))  id 00256CA6.004E0431 ; Mon, 6 Jan 2003 14:12:08 +0000
X-Lotus-FromDomain: POSTOFFICE
From: [e-mail]
To: Massimiliano Pala <[e-mail]>
Cc: [e-mail]
Message-ID: <[e-mail]>
Date: Mon, 6 Jan 2003 14:15:46 +0000
Subject: Re: OCSP and LDAP
Mime-Version: 1.0
Content-type: text/plain; charset=us-ascii
Content-Disposition: inline
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

> But this, in some environment it is not possible. Let's say the
> CA is in a timed controlled access, unavailable from 8pm to 8am
> (for different reasons, i.e. security, lack of personnel, etc.. )
> and a user asks for revocation at 9pm, should we let the certificate
> being reported as valid till 8am ?

Then the certificate policy under which the EE cert was issued
is inappropriate for the use to which the certificate itself is
being put. If the EE requires up-to-the-minute revocation
information to be available to it's correspondents then it
should make sure it is using a CA that can fulfil these
requirements. Legality first, technology second.

Chris



This  email  and  any  attachments  are confidential and intended for the addressee
only.   If  you are not the named recipient, you must not use, disclose, reproduce,
copy  or  distribute the contents of this communication.  If you have received this
in error, please contact the sender and then delete this email from your system.




Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h06C6x910738 for ietf-pkix-bks; Mon, 6 Jan 2003 04:06:59 -0800 (PST)
Received: from mail.hackmasters.net (ppp-217-133-8-148.dialup.tiscali.it [217.133.8.148]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h06C6uo10731 for <[e-mail]>; Mon, 6 Jan 2003 04:06:56 -0800 (PST)
Received: from localhost (localhost.localdomain [127.0.0.1]) by mail.hackmasters.net (Postfix) with ESMTP id 91FE5F356 for <[e-mail]>; Mon,  6 Jan 2003 13:05:39 +0100 (CET)
Received: by mail.hackmasters.net (Postfix, from userid 509) id D7873F35C; Mon,  6 Jan 2003 13:05:32 +0100 (CET)
Received: from hackmasters.net (galadriel.mpnet.hackmasters.net [10.5.122.180]) by mail.hackmasters.net (Postfix) with ESMTP id 988A5F356 for <[e-mail]>; Mon,  6 Jan 2003 13:05:30 +0100 (CET)
Message-ID: <[e-mail]>
Date: Mon, 06 Jan 2003 13:07:44 +0100
From: Massimiliano Pala <[e-mail]>
Organization: OpenCA
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.2.1) Gecko/20021130
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: [e-mail]
Subject: Re: OCSP and LDAP
References: <006001c2b572$d31f53a0$0a01a8c0@stl>
In-Reply-To: <006001c2b572$d31f53a0$0a01a8c0@stl>
Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms080001070800010006050107"
X-Virus-Scanned: by AMaViS perl-11
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

This is a cryptographically signed message in MIME format.

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

Simon Tardell wrote:
[...]r this reason I need some more information rather than the only CRL.
> 
> 
> No, if you want to remove the latency in the system that is related to
> the issuance interval of your CRL, then you should issue CRLs
> immediately as the revocation occurs.

But this, in some environment it is not possible. Let's say the
CA is in a timed controlled access, unavailable from 8pm to 8am
(for different reasons, i.e. security, lack of personnel, etc.. )
and a user asks for revocation at 9pm, should we let the certificate
being reported as valid till 8am ?

For this reason I need some additional information, my question was
about the presence of a standard describing where to store them
onto LDAP and if, to you, it could be better storing them on a
per certificate basis or in a single entry in the main organization
entry.

[ unknown ]
> No. There is an unclear wording in RFC2560 that might lead the thoughts
> in that direction. "unknown" means that the OCSP is unable or unwilling
> to answer the revocation query (because it doesn't know the CA, or
> because it doesn't have up to date revocation information or whatever).
> A logical reaction to an "unknown" response is to go to some other OCSP
> responder that might be better connected for the moment. If you confuse
> the meaning of "unknown" to be an assertion (that the certificate was
> indeed never issued) then that availability feature breaks down (at
> least if you have the wrong kind of client). The OCSPv2 draft has a
> better wording.

Quoting the RFC2560 << The "unknown" state indicates that the responder
doesn't know about the certificate being requested. >>. I was not saying
that the "unknown" means that the certificate has never being issued,
anyway how could the responder know which certificates have been issued ?
In this case the responder can';t be sure about the validity of a certificate
and it should, to me at least, therefore return an "unknown" status.

Because of these considerations I think the OCSP reponder needs additional
data besides the only CRL(s), although I know that this is a fast way of
having it working but this works only when the CRLs are immediately (in the
same second) issued after certificate revocation and this does not work in
environment when some human interaction (for example verification).

It seems, to me, just translating the CRLs in another format without adding
a real improvement to the validating process... I think the OCSP to be more
useful than this.

-- 

C'you,

	Massimiliano Pala

--o-------------------------------------------------------------------------
Massimiliano Pala [OpenCA Project Manager]                [e-mail]
                                                   Tel.:   [phone]
http://www.openca.org                            Fax:    +39   178  221 8225
http://openca.sourceforge.net                    Mobile: [phone]

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

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIOZjCC
By8wggYXoAMCAQICASwwDQYJKoZIhvcNAQEEBQAwgYoxIjAgBgkqhkiG9w0BCQEWE3BraS5j
aWNhaWFAdW5pbW8uaXQxJzAlBgNVBAMTHlVuaW1vcmUgRW50ZSBkaSBDZXJ0aWZpY2F6aW9u
ZTEuMCwGA1UEChMlVW5pdmVyc2l0YScgZGkgTW9kZW5hIGUgUmVnZ2lvIEVtaWxpYTELMAkG
A1UEBhMCSVQwHhcNMDIwNzI0MTUyNjI2WhcNMDMxMjMxMjM1OTU5WjCBqTEaMBgGA1UEAxMR
TWFzc2ltaWxpYW5vIFBhbGExNTAzBgNVBAsTLERpcGFydGltZW50byBkaSBJbmdlZ25lcmlh
IGRlbGwnSW5mb3JtYXppb25lMRcwFQYDVQQLEw5TZWRlIGRpIE1vZGVuYTEuMCwGA1UEChMl
VW5pdmVyc2l0YScgZGkgTW9kZW5hIGUgUmVnZ2lvIEVtaWxpYTELMAkGA1UEBhMCSVQwgZ8w
DQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBANSesg80BGzryvQlplD0MJ2YWlSEUAZpiFmywpOm
l//lWMnhONmC/q0TrO7j9Bb195dNzCMuXFgvV49Sy1iyHAjDhpysFvm/xZbAS3j8prXNN23K
S3Oa7Zz2GrQpCHgupCPQL2cy+ARVwwFod2GOSCVoUACkndit964K/bfsGvyLAgMBAAGjggQB
MIID/TAMBgNVHRMBAf8EAjAAMBEGCWCGSAGG+EIBAQQEAwIFoDAOBgNVHQ8BAf8EBAMCA/gw
HQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMB0GA1UdDgQWBBT6aSO5yTMPTf9OdcWo
14pKLqEHMDCBtwYDVR0jBIGvMIGsgBRFHaYA4ZfoyU2aaUnZYMiYf4lFA6GBkKSBjTCBijEi
MCAGCSqGSIb3DQEJARYTcGtpLmNpY2FpYUB1bmltby5pdDEnMCUGA1UEAxMeVW5pbW9yZSBF
bnRlIGRpIENlcnRpZmljYXppb25lMS4wLAYDVQQKEyVVbml2ZXJzaXRhJyBkaSBNb2RlbmEg
ZSBSZWdnaW8gRW1pbGlhMQswCQYDVQQGEwJJVIIBADBqBglghkgBhvhCAQ0EXRZbUHJvZ2V0
dG8gUG9zdGEgRWxldHRyb25pY2EgU2ljdXJhIA0KVW5pdmVyc2l0YScgZGkgTW9kZW5hIGUg
UmVnZ2lvIEVtaWxpYSANCkMuSS5DLkEuSS5BLiANCjAiBgNVHREEGzAZgRdtYWR3b2xmQGhh
Y2ttYXN0ZXJzLm5ldDA0BgNVHRIELTArgRNwa2kuY2ljYWlhQHVuaW1vLml0hhRodHRwOi8v
cGtpLnVuaW1vLml0LzA/BggrBgEFBQcBAQQzMDEwLwYIKwYBBQUHMAKGI2h0dHA6Ly9wa2ku
dW5pbW8uaXQvY2EvaXNzdWVycy5odG1sMDIGA1UdHwQrMCkwJ6AloCOGIWh0dHA6Ly9wa2ku
dW5pbW8uaXQvY3JsL2NhY3JsLmNybDAwBglghkgBhvhCAQQEIxYhaHR0cDovL3BraS51bmlt
by5pdC9jcmwvY2FjcmwuY3JsMDAGCWCGSAGG+EIBAwQjFiFodHRwOi8vcGtpLnVuaW1vLml0
L2NybC9jYWNybC5jcmwwKgYJYIZIAYb4QgEHBB0WG2h0dHA6Ly9wa2kudW5pbW8uaXQvcmVu
ZXdhbDArBglghkgBhvhCAQgEHhYcaHR0cDovL3BraS51bmltby5pdC9jcHMvMS4xLzCB2QYD
VR0gBIHRMIHOMEMGCisGAQQBqQcBAQEwNTAzBggrBgEFBQcCARYnaHR0cDovL3d3dy5ldXJv
cGtpLm9yZy9jYS9yb290L2Nwcy8xLjEvMEEGCisGAQQBqQcCAQEwMzAxBggrBgEFBQcCARYl
aHR0cDovL3d3dy5ldXJvcGtpLm9yZy9jYS9pdC9jcHMvMS4xLzBEBgorBgEEAegTAQEBMDYw
NAYIKwYBBQUHAgEWKGh0dHA6Ly9tYWlsLnVuaW1vLml0L2Zpcm1hL2Nwc21vZGVuYS5odG0w
DQYJKoZIhvcNAQEEBQADggEBABn8ViNg4MPNRzEFFF4BsmRMP1YbUHbS+NmFvvys0D3xueex
Ie6HU+tkv9hz8++0MbLPnRY2qKpZXfWTbIOkrHLGVVHUkiZXFzfxsDMgcB4MWmSmhRVLfPqr
RZKAjIevO0JKIksq2xutAUqX5jkqZoGHpPv9JCiSI+cDRqOOW2Fh3JBGkcULKybrdwrSN6+S
NoTyTXR+ryeTBUXxu9rIbjrJdH3rKS7rz3ZkP2PKuFOb+Vbp829ALph1SJOLQrUnmJouLOSL
oVHW4zJK4zcAiNyMHua3HveLRkVINT9eDBeYBRPdn1k+LqdXqkXiEUPA+EIKeA23F5nQkqxI
mVVpaaYwggcvMIIGF6ADAgECAgEsMA0GCSqGSIb3DQEBBAUAMIGKMSIwIAYJKoZIhvcNAQkB
FhNwa2kuY2ljYWlhQHVuaW1vLml0MScwJQYDVQQDEx5Vbmltb3JlIEVudGUgZGkgQ2VydGlm
aWNhemlvbmUxLjAsBgNVBAoTJVVuaXZlcnNpdGEnIGRpIE1vZGVuYSBlIFJlZ2dpbyBFbWls
aWExCzAJBgNVBAYTAklUMB4XDTAyMDcyNDE1MjYyNloXDTAzMTIzMTIzNTk1OVowgakxGjAY
BgNVBAMTEU1hc3NpbWlsaWFubyBQYWxhMTUwMwYDVQQLEyxEaXBhcnRpbWVudG8gZGkgSW5n
ZWduZXJpYSBkZWxsJ0luZm9ybWF6aW9uZTEXMBUGA1UECxMOU2VkZSBkaSBNb2RlbmExLjAs
BgNVBAoTJVVuaXZlcnNpdGEnIGRpIE1vZGVuYSBlIFJlZ2dpbyBFbWlsaWExCzAJBgNVBAYT
AklUMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDUnrIPNARs68r0JaZQ9DCdmFpUhFAG
aYhZssKTppf/5VjJ4TjZgv6tE6zu4/QW9feXTcwjLlxYL1ePUstYshwIw4acrBb5v8WWwEt4
/Ka1zTdtyktzmu2c9hq0KQh4LqQj0C9nMvgEVcMBaHdhjkglaFAApJ3YrfeuCv237Br8iwID
AQABo4IEATCCA/0wDAYDVR0TAQH/BAIwADARBglghkgBhvhCAQEEBAMCBaAwDgYDVR0PAQH/
BAQDAgP4MB0GA1UdJQQWMBQGCCsGAQUFBwMCBggrBgEFBQcDBDAdBgNVHQ4EFgQU+mkjuckz
D03/TnXFqNeKSi6hBzAwgbcGA1UdIwSBrzCBrIAURR2mAOGX6MlNmmlJ2WDImH+JRQOhgZCk
gY0wgYoxIjAgBgkqhkiG9w0BCQEWE3BraS5jaWNhaWFAdW5pbW8uaXQxJzAlBgNVBAMTHlVu
aW1vcmUgRW50ZSBkaSBDZXJ0aWZpY2F6aW9uZTEuMCwGA1UEChMlVW5pdmVyc2l0YScgZGkg
TW9kZW5hIGUgUmVnZ2lvIEVtaWxpYTELMAkGA1UEBhMCSVSCAQAwagYJYIZIAYb4QgENBF0W
W1Byb2dldHRvIFBvc3RhIEVsZXR0cm9uaWNhIFNpY3VyYSANClVuaXZlcnNpdGEnIGRpIE1v
ZGVuYSBlIFJlZ2dpbyBFbWlsaWEgDQpDLkkuQy5BLkkuQS4gDQowIgYDVR0RBBswGYEXbWFk
d29sZkBoYWNrbWFzdGVycy5uZXQwNAYDVR0SBC0wK4ETcGtpLmNpY2FpYUB1bmltby5pdIYU
aHR0cDovL3BraS51bmltby5pdC8wPwYIKwYBBQUHAQEEMzAxMC8GCCsGAQUFBzAChiNodHRw
Oi8vcGtpLnVuaW1vLml0L2NhL2lzc3VlcnMuaHRtbDAyBgNVHR8EKzApMCegJaAjhiFodHRw
Oi8vcGtpLnVuaW1vLml0L2NybC9jYWNybC5jcmwwMAYJYIZIAYb4QgEEBCMWIWh0dHA6Ly9w
a2kudW5pbW8uaXQvY3JsL2NhY3JsLmNybDAwBglghkgBhvhCAQMEIxYhaHR0cDovL3BraS51
bmltby5pdC9jcmwvY2FjcmwuY3JsMCoGCWCGSAGG+EIBBwQdFhtodHRwOi8vcGtpLnVuaW1v
Lml0L3JlbmV3YWwwKwYJYIZIAYb4QgEIBB4WHGh0dHA6Ly9wa2kudW5pbW8uaXQvY3BzLzEu
MS8wgdkGA1UdIASB0TCBzjBDBgorBgEEAakHAQEBMDUwMwYIKwYBBQUHAgEWJ2h0dHA6Ly93
d3cuZXVyb3BraS5vcmcvY2Evcm9vdC9jcHMvMS4xLzBBBgorBgEEAakHAgEBMDMwMQYIKwYB
BQUHAgEWJWh0dHA6Ly93d3cuZXVyb3BraS5vcmcvY2EvaXQvY3BzLzEuMS8wRAYKKwYBBAHo
EwEBATA2MDQGCCsGAQUFBwIBFihodHRwOi8vbWFpbC51bmltby5pdC9maXJtYS9jcHNtb2Rl
bmEuaHRtMA0GCSqGSIb3DQEBBAUAA4IBAQAZ/FYjYODDzUcxBRReAbJkTD9WG1B20vjZhb78
rNA98bnnsSHuh1PrZL/Yc/PvtDGyz50WNqiqWV31k2yDpKxyxlVR1JImVxc38bAzIHAeDFpk
poUVS3z6q0WSgIyHrztCSiJLKtsbrQFKl+Y5KmaBh6T7/SQokiPnA0ajjlthYdyQRpHFCysm
63cK0jevkjaE8k10fq8nkwVF8bvayG46yXR96yku6892ZD9jyrhTm/lW6fNvQC6YdUiTi0K1
J5iaLizki6FR1uMySuM3AIjcjB7mtx73i0ZFSDU/XgwXmAUT3Z9ZPi6nV6pF4hFDwPhCCngN
txeZ0JKsSJlVaWmmMYIDNjCCAzICAQEwgZAwgYoxIjAgBgkqhkiG9w0BCQEWE3BraS5jaWNh
aWFAdW5pbW8uaXQxJzAlBgNVBAMTHlVuaW1vcmUgRW50ZSBkaSBDZXJ0aWZpY2F6aW9uZTEu
MCwGA1UEChMlVW5pdmVyc2l0YScgZGkgTW9kZW5hIGUgUmVnZ2lvIEVtaWxpYTELMAkGA1UE
BhMCSVQCASwwCQYFKw4DAhoFAKCCAfswGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkq
hkiG9w0BCQUxDxcNMDMwMTA2MTIwNzQ0WjAjBgkqhkiG9w0BCQQxFgQUM4rDilnRIbsRrVyv
VV3fowSySN8wUgYJKoZIhvcNAQkPMUUwQzAKBggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAw
DQYIKoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZIhvcNAwICASgwgaEGCSsGAQQBgjcQBDGB
kzCBkDCBijEiMCAGCSqGSIb3DQEJARYTcGtpLmNpY2FpYUB1bmltby5pdDEnMCUGA1UEAxMe
VW5pbW9yZSBFbnRlIGRpIENlcnRpZmljYXppb25lMS4wLAYDVQQKEyVVbml2ZXJzaXRhJyBk
aSBNb2RlbmEgZSBSZWdnaW8gRW1pbGlhMQswCQYDVQQGEwJJVAIBLDCBowYLKoZIhvcNAQkQ
AgsxgZOggZAwgYoxIjAgBgkqhkiG9w0BCQEWE3BraS5jaWNhaWFAdW5pbW8uaXQxJzAlBgNV
BAMTHlVuaW1vcmUgRW50ZSBkaSBDZXJ0aWZpY2F6aW9uZTEuMCwGA1UEChMlVW5pdmVyc2l0
YScgZGkgTW9kZW5hIGUgUmVnZ2lvIEVtaWxpYTELMAkGA1UEBhMCSVQCASwwDQYJKoZIhvcN
AQEBBQAEgYCuMUWKwY4qbHSboVFdLSHhHBxMtnCcyurIHl1xXI21GtHC94XHIPwT79RX3Bmt
ZfmcwrWq/WKbssB3IuxA2TIYSMrLlMpYXXUVqDSoJ3pJwKEGYVMjz+Oam9y8BpX+k30fDQH0
AULx6K3dBIxeVkvusk9sy1BO2ZqPfdcNZfZobgAAAAAAAA==
--------------ms080001070800010006050107--



Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h06B0bP03391 for ietf-pkix-bks; Mon, 6 Jan 2003 03:00:37 -0800 (PST)
Received: from nalle.datum.nu (as6-6-8.s.bonet.se [217.215.37.231]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h06B0Zo03386 for <[e-mail]>; Mon, 6 Jan 2003 03:00:35 -0800 (PST)
Received: from stl (as3-3-6.apv.s.bonet.se [217.215.35.57]) by nalle.datum.nu (Postfix) with ESMTP id 1823A10F544; Mon,  6 Jan 2003 12:00:30 +0100 (CET)
From: "Simon Tardell" <[e-mail]>
To: "'Massimiliano Pala'" <[e-mail]>, <[e-mail]>
Subject: RE: OCSP and LDAP
Date: Mon, 6 Jan 2003 12:00:28 +0100
Message-ID: <006001c2b572$d31f53a0$0a01a8c0@stl>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook, Build 10.0.3416
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000
In-Reply-To: <[e-mail]>
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

> Ambarish Malpani wrote:
> > Hi Massimiliano,
> >     You should seriously consider having your responder work off a 
> > CA's CRL, rather than trying to access its database directly.
> 
> Well, our approach is towards the usage of an off-line CA so 
> my problem is that usually the CRL could be not up to date to 
> the latest status of the certificate (let's say a user 
> request its certificate to be revoked, from this time to the 
> time the CRL will be issued there could be a time gap during 
> which I want the certificate to be reported as invalid -- 
> let's say with the onHold reason).
> 
> For this reason I need some more information rather than the only CRL.

No, if you want to remove the latency in the system that is related to
the issuance interval of your CRL, then you should issue CRLs
immediately as the revocation occurs.
 
> There is another question about this approach: if the client 
> request the status of one certificate with a serial that is 
> not within the CRL, should not the responder check for it 
> (i.e. its existance?) and if it does not have informations 
> about it return an "unknown" answer ?

No. There is an unclear wording in RFC2560 that might lead the thoughts
in that direction. "unknown" means that the OCSP is unable or unwilling
to answer the revocation query (because it doesn't know the CA, or
because it doesn't have up to date revocation information or whatever).
A logical reaction to an "unknown" response is to go to some other OCSP
responder that might be better connected for the moment. If you confuse
the meaning of "unknown" to be an assertion (that the certificate was
indeed never issued) then that availability feature breaks down (at
least if you have the wrong kind of client). The OCSPv2 draft has a
better wording.
 
Simon

Simon Tardell, cell [phone], [e-mail]





Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h06AkZ402591 for ietf-pkix-bks; Mon, 6 Jan 2003 02:46:35 -0800 (PST)
Received: from nalle.datum.nu (as6-6-8.s.bonet.se [217.215.37.231]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h06AkXo02587 for <[e-mail]>; Mon, 6 Jan 2003 02:46:33 -0800 (PST)
Received: from stl (as3-3-6.apv.s.bonet.se [217.215.35.57]) by nalle.datum.nu (Postfix) with ESMTP id 6ABA610F544; Mon,  6 Jan 2003 11:46:24 +0100 (CET)
From: "Simon Tardell" <[e-mail]>
To: "'Peter Gutmann'" <[e-mail]>, <[e-mail]>, <[e-mail]>, <[e-mail]>
Subject: RE: OCSP and LDAP
Date: Mon, 6 Jan 2003 11:46:23 +0100
Message-ID: <003f01c2b570$db572040$0a01a8c0@stl>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook, Build 10.0.3416
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000
In-Reply-To: <[e-mail]>
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Peter,

> Most of the CAs I know of issues CRLs a few times a day, some 
> as infrequently as once a day.  If I'm doing processing with 
> any kind of value attached to the transaction, I want to know 
> whether the cert is valid right now, not whether it was OK 
> last night when the CRL was issued (substitute "credit card" 
> for "cert" to see why this is important).  I have never seen 
> a situation where an offline CRL gives better performance 
> than a real-time check of a live database, unless you happen 
> to catch it just as the CRL is being issued, which (for a 
> 24-hour CRL time) only works about once in 86,400 times.

This argument is backwards: The CAs are doing the minimum that they can
while still conforming to the model, because noone is (as you correctly
note) really asking for CRLs (or revocation checking in any other way)
more than as a checkbox item. It doesn't mean that they can't. When need
arises, they can switch to issuing one delta per revocation and push
that their OCSP responders. 

It is just as up to date as coupling an OCSP responder directly to the
CA database, and it keeps the CA offline. The only thing missing, from a
standards perspective, is to specify the push protocol. 

Simon

Simon Tardell, cell [phone], [e-mail]



Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h069RXd22593 for ietf-pkix-bks; Mon, 6 Jan 2003 01:27:33 -0800 (PST)
Received: from mx1.fujixerox.co.jp ([e-mail] [202.32.191.28]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h069RVo22585 for <[e-mail]>; Mon, 6 Jan 2003 01:27:31 -0800 (PST)
Received: by mx1.fujixerox.co.jp; id SAA13195; Mon, 6 Jan 2003 18:27:30 +0900 (JST)
Received: from unknown(129.249.118.132) by mx1.fujixerox.co.jp via smap (3.2) id xma012970; Mon, 6 Jan 03 18:26:51 +0900
Received: from ns1.fujixerox.co.jp (localhost [127.0.0.1]) by isvw2.fujixerox.co.jp (8.11.1/3.7W) with ESMTP id h069Qp321738 for <[e-mail]>; Mon, 6 Jan 2003 18:26:51 +0900 (JST)
Received: from mail.next.ksp.fujixerox.co.jp (mail.next.ksp.fujixerox.co.jp [129.249.209.162]) by ns1.fujixerox.co.jp (8.11.6/3.7W) with SMTP id h069Qn111489 for <[e-mail]>; Mon, 6 Jan 2003 18:26:49 +0900 (JST)
Received: (qmail 43644 invoked by uid 0); 6 Jan 2003 09:26:46 -0000
Received: from fxmxgw.fujixerox.co.jp (HELO carry-on5) (129.249.118.106) by mail.next.ksp.fujixerox.co.jp with SMTP; 6 Jan 2003 09:26:46 -0000
To: [e-mail], [e-mail]
Cc: [e-mail], [e-mail], [e-mail], [e-mail]
Subject: HTML version of Challenge PKI 2001 is ready.
From: Ryu Inada <[e-mail]>
References: <[e-mail]> <[e-mail]>
In-Reply-To: <[e-mail]>
Message-Id: <[e-mail]>
X-Mailer: Winbiff [Version 2.42 beta2]
X-Accept-Language: ja,en
Date: Mon, 6 Jan 2003 18:26:49 +0900
Mime-Version: 1.0
Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; Boundary="---------1041844953-704823272"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

This is a multi-part message in MIME format.

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

Dear PKIX members.

Happy new year !

As we announced pdf version of Challenge PKI 2001 report in 30 
Dec 2003, this document has some Japanese character, and most of
 people could not open nor print out it.

We stragled to solve the problem, but we could not success yet.

So, we make a HTML verion of Challnge PKI 2001 report on 
following URL.
http://www.ipa.go.jp/security/fy13/report/pki_interop/
chalange2001.html

Our activity about PKI interoperability:
http://www.jnsa.org/english/e_active2_10.html

If you have a any comments, please post it multi-domain-PKI@jnsa.
org.

Sorry for out lack of experience about PDF.

Thank you.

Ryu Inada/JNSA

-----------1041844953-704823272
Content-Type: application/x-pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"

MIIGJAYJKoZIhvcNAQcCoIIGFTCCBhECAQExCzAJBgUrDgMCGgUAMAsGCSqGSIb3DQEHAaCC
BIQwggIlMIIBjqADAgECAgEBMA0GCSqGSIb3DQEBBAUAMEkxCzAJBgNVBAYTAkpQMR0wGwYD
VQQKExRGdWppIFhlcm94IENvLiwgTHRkLjEbMBkGA1UEAxMSRnVqaSBYZXJveCBYbmV0IENB
MB4XDTAwMDcyMDE1MDAwMFoXDTEwMTIzMTE0NTk1OVowSTELMAkGA1UEBhMCSlAxHTAbBgNV
BAoTFEZ1amkgWGVyb3ggQ28uLCBMdGQuMRswGQYDVQQDExJGdWppIFhlcm94IFhuZXQgQ0Ew
gZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBAL9YJsiaA54WeIrWV5GqU1ty155OM8Jh3XgK
5o/QPcvFShuRuMvX162wVPJLFP+0k1g2E3qEtnCMRbRI8eiGpN7NkzqfsD8M6SdMVRxW77MM
/riYVeEf5dMznul0VUQ82RQ5OEjf4DE+DSVw7dJCN4/rGG97PtDuWjdfsg1//q/fAgMBAAGj
HTAbMAsGA1UdDwQEAwIBBjAMBgNVHRMEBTADAQEBMA0GCSqGSIb3DQEBBAUAA4GBAAmqWsKF
HEDU+33KTLjz5aJzAp1u3nn2Cr5F3D1fr44uqmrIDwykcRRCQJmYMDxItKWNzBfemn+mjBzC
Nk7gG38aUpxrD4tLl4miIAVYqu2svOzX0NvfHsy3ECQWXhU0vVMSVOFAfljHMFimLHFnhnsQ
2bQ3ijVKo8/V5Lmtc5CpMIICVzCCAcCgAwIBAgICLOEwDQYJKoZIhvcNAQEEBQAwSTELMAkG
A1UEBhMCSlAxHTAbBgNVBAoTFEZ1amkgWGVyb3ggQ28uLCBMdGQuMRswGQYDVQQDExJGdWpp
IFhlcm94IFhuZXQgQ0EwHhcNMDIwNDA5MTUwMDAwWhcNMDQwNDA5MTQ1OTU5WjBGMQswCQYD
VQQGEwJKUDEdMBsGA1UEChMURnVqaSBYZXJveCBDby4sIEx0ZC4xGDAWBgNVBAMTDzE3NTc4
IFJ5dSBJbmFkYTBcMA0GCSqGSIb3DQEBAQUAA0sAMEgCQQC5EZaT1mRJy4g1vM37ti+oKkVU
phqtyvd5ZjA+woaL6T2PcMtU/QNUoJCT9x9kqHvDDHpBQN2qpe4u6PLsRffXAgMBAAGjgZQw
gZEwDAYDVR0TBAUwAwEBADALBgNVHQ8EBAMCAaAwJAYDVR0RBB0wG4EZUnl1LkluYWRhQGZ1
aml4ZXJveC5jby5qcDARBglghkgBhvhCAQEEBAMCAKAwOwYDVR0fBDQwMjAwoC6gLIYqaHR0
cDovL3huZXQuZnVqaXhlcm94LmNvLmpwL0NSTC94bmV0Y2EuY3JsMA0GCSqGSIb3DQEBBAUA
A4GBAJShNhdMVhVffoJkVnq1Q2MCztGWy1hwm36nSXCGDig+1jEyf1wtqoFU5bI7lX/c5Wto
knmMFlj2AjpjIcJIx1gECECQnSX+ibtZkGiPcqzvApw0LxG7Jo77YW+N3DyMFzQYVt43k62/
onPINbf7hBwqAjJpXe0MQ+vU2jaekP23MYIBaDCCAWQCAQEwTzBJMQswCQYDVQQGEwJKUDEd
MBsGA1UEChMURnVqaSBYZXJveCBDby4sIEx0ZC4xGzAZBgNVBAMTEkZ1amkgWGVyb3ggWG5l
dCBDQQICLOEwCQYFKw4DAhoFAKCBsTAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqG
SIb3DQEJBTEPFw0wMzAxMDYwOTIyMDBaMCMGCSqGSIb3DQEJBDEWBBSdUJFHOZFjubZVZoLh
TDEd6VSOWDBSBgkqhkiG9w0BCQ8xRTBDMAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIAgDAH
BgUrDgMCBzANBggqhkiG9w0DAgIBQDANBggqhkiG9w0DAgIBKDANBgkqhkiG9w0BAQEFAARA
UCira9K8AFC39hZb/m6Z8TuCnpHyVemVf6uAAgIa+Qnzvgiwd/D1FZKHaXj9M0NSSHu8BkVa
xkWsrvckybplng==

-----------1041844953-704823272--




Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h060Dh315690 for ietf-pkix-bks; Sun, 5 Jan 2003 16:13:43 -0800 (PST)
Received: from nymelsmtp.internet.ny.fdms.firstdata.com (nymelsmtp01.firstdata.com [198.184.0.23]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h060Dgo15684 for <[e-mail]>; Sun, 5 Jan 2003 16:13:42 -0800 (PST)
Subject: Re: OCSP and LDAP
To: "Anders Rundgren" <[e-mail]>
Cc: "Ambarish Malpani" <[e-mail]>, "IETF PKIX" <[e-mail]>
X-Mailer: Lotus Notes Release 5.0.5  September 22, 2000
Message-ID: <[e-mail]>
From: [e-mail]
Date: Sun, 5 Jan 2003 17:15:37 -0700
X-MIMETrack: Serialize by Router on NYMELSMTP/NY/FDMS/FDC(Release 5.0.8 |June 18, 2001) at 01/05/2003 07:15:40 PM
MIME-Version: 1.0
Content-type: text/plain; charset=us-ascii
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

... aka ... i never said you can't have a certificate with r/o stale,
static subset copy of the real information ....
i just said that in an online environment whre you have the real-time,
fresh, dynamic, &/or aggregate of the
real information ... then the r/o stale, static, subset copy is redundant
and superfluous.

for a particular business/value operation, if the r/o stale, static, subset
copy is redundant and superfluous ... then it seems to follow that an OCSP
transaction giving an opinion about the staleness of tedundant and
superfluous information is also superfluous.

--
Internet trivia, 20th anv: http://www.garlic.com/~lynn/rfcietff.htm



Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h0602Y214162 for ietf-pkix-bks; Sun, 5 Jan 2003 16:02:34 -0800 (PST)
Received: from nymelsmtp.internet.ny.fdms.firstdata.com (nymelsmtp01.firstdata.com [198.184.0.23]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h0602Wo14155 for <[e-mail]>; Sun, 5 Jan 2003 16:02:32 -0800 (PST)
Subject: Re: OCSP and LDAP
To: "Anders Rundgren" <[e-mail]>
Cc: "Ambarish Malpani" <[e-mail]>, "IETF PKIX" <[e-mail]>
X-Mailer: Lotus Notes Release 5.0.5  September 22, 2000
Message-ID: <[e-mail]>
From: [e-mail]
Date: Sun, 5 Jan 2003 17:04:22 -0700
X-MIMETrack: Serialize by Router on NYMELSMTP/NY/FDMS/FDC(Release 5.0.8 |June 18, 2001) at 01/05/2003 07:04:30 PM
MIME-Version: 1.0
Content-type: text/plain; charset=us-ascii
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

the driver's license in your hand isn't the real driver's license .... it
is a r/o, stale, static copy made at some time in the past. the real
driver's license is in some agency's database record. the issue about
whether the real license is valid or not is stored there also. all the
dynamic, fresh, aggregated, and/or realtime data is stored there ... or is
pointed to by that record (if you want all the online, realtime, fresh,
dynamic and/or aggregated information ... you have to read the real
"license" record).

for low value &/or low risk operations ... the static, stale copy that you
hold will be sufficient. for situations that justify the cost of an online
transaction ... to get the real-time, fresh, dynamic, and aggregated real
information ... they go online to get the real information.

somebody types in a driver's license number to the online system ... it
could just spit back just a simple yes/no regarding the staleness of the
static, r/o copy in the person's possesion. however, if somebody is going
to the trouble of going online .... they type in the driver's license
number to the online system .... and they get back the real license, with
all the real-time, fresh, dynamic, and/or aggregated information. any
information claims by the r/o, static, stale copy in the person's position
.... at that point are redundant and superfluous.

--
Internet trivia, 20th anv: http://www.garlic.com/~lynn/rfcietff.htm



Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h05NmFt11793 for ietf-pkix-bks; Sun, 5 Jan 2003 15:48:15 -0800 (PST)
Received: from nymelsmtp.internet.ny.fdms.firstdata.com (nymelsmtp01.firstdata.com [198.184.0.23]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h05NmEo11786 for <[e-mail]>; Sun, 5 Jan 2003 15:48:14 -0800 (PST)
Subject: Re: OCSP and LDAP
To: "Anders Rundgren" <[e-mail]>
Cc: "Ambarish Malpani" <[e-mail]>, "IETF PKIX" <[e-mail]>
X-Mailer: Lotus Notes Release 5.0.5  September 22, 2000
Message-ID: <[e-mail]>
From: [e-mail]
Date: Sun, 5 Jan 2003 16:50:05 -0700
X-MIMETrack: Serialize by Router on NYMELSMTP/NY/FDMS/FDC(Release 5.0.8 |June 18, 2001) at 01/05/2003 06:50:12 PM
MIME-Version: 1.0
Content-type: text/plain; charset=us-ascii
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

but the whole point of an offline credential containing certified
information is i can reference it offline. if i'm online .... i don't need
a certificate.

in the non-certificate model .... i assert that i have account number #xxx
and sign the assertion with hardware token.

that is sent off to the online infrastructure and it pulls up #xxx and
verifies the signature with the public key in the online record.

the state of the account and all related information is pulled from the
account. there is no offlne certificate containing any certified stale,
static information.

in the payment transaction ... i make two assertions that I have account
number #xxx and that i'll pay xyx .... I sign that assertion .... it is
sent off .... the account #xxx is pulled up .... it checks the signature
with the public key in the account record .... it checks the status of the
account and decides about the payment and returns yes/no as to the payment
(and whatever other information). No offline certificate with certified
stale, static information is needed.

for the license ... I make an assertion that i have license #abc and sign
the assertions with a hardware token. the police sends off the assertions
.... which verifies the public key and pulls up the record .... either
direclty containing all the real-time, fresh, dynamic, and/or aggregating
information .... or contains enuf information to aggregate all the
information. still no offline certificate with certified stale, static
information is needed  The police is using the online, realtime, fresh,
dynamic, and/or aggregated information. The police doesn't have to resort
to a offline credential containing a stale, static subset of the online,
realtime, fresh, dynamic and/or aggregated information. It is purely an
artificial contrivence to claim that a offline certificate with stale
static information provides any added value at the point when all of the
online realtime, fresh, dynamic and/or aggregated information is available.

i only need a certificate with stale, static information for offline
operations where i don't have access to online, real-time, fresh, dynamic,
and/or aggregated information. If I have a superset of the stale, static
information in a certificate .... then the certificate is redundant and
superfluous for that operation. If the certifcate is redundant and
superfluous .... then an OCSP operation that gives an opinion about the
staleness of the redundantant & superfluous stale, static information is
also redundant and superfluous.

If the value proposition is such that I always resort to the online,
real-time, fresh, dynamic and/or aggregated information .... then for those
value propositions an offline certificate with stale, static information is
always redundant and superfluous. If the offline certificate with stale,
static information is always redundant and superfluous ... then it would
follow that an OCSP for a redundant and superfluous certificate is also
redundant and superfluous.

so there is slight vulnerability issue here. not only is the certificate in
somebody's position subject to being stale static information ... but it is
also potentially subject to counterfeiting (picture, name, address, birth
date, etc). for low value operations with little risk .... the risk of
counterfeited license is low. For high value operations with potentially
more risk .... the "real" information is stored under strong security at
the appropriate agency. The thing that is in somebody's hand is purely a
stale, static offline copy of the real information stored online someplace.
The law enforcement are bringing up the "real" information when they go
onlne .... the stuff in your hand is basically a r/o stale, static copy
purely for low value, low risk, offline operations.

the claim that in an online environment .... that it is sufficient to have
an authentication mechanism .... it isn't necessary in a real online
environment to have any r/o, stale, static copy of the real information
carried around on your person in a certificate for use in offline
operations. If there are no offline operations .... then r/o, stale, static
copies designed for use in offline operations are redundant and
superfluous. For online operations, r/o, stale, static copies designed for
offline use are redundant and superfluous when the real, online, fresh,
realtime, dynamic and aggregated information is available.

--
Internet trivia, 20th anv: http://www.garlic.com/~lynn/rfcietff.htm


                                                                                    
                    "Anders Rundgren"                                               
                    <anders.rundgren@     To:      "Ambarish Malpani"               
                           telia.com>        <[e-mail]>,                
                                             <[e-mail]>           
                     01/05/2003 04:08     cc:      "IETF PKIX" <[e-mail]>  
                                   PM     Subject:      Re: OCSP and LDAP           
                                                                                    
                                                                                    




<snip>

>Lets take another example ... driver's license. If you get stopped ....
the
>typical real-time, online response isn't about whether the license is
>revoked or not (that is trivial subset) .... it is how many traffic
>citations/warrents are outstanding .... number of parking tickets, and
>potentially some number of other pieces of real-time, dynamic information.

No problems.
The licensee authenticates to the "traffic police server" which uses
OCSP to verify that the TTP-issued license is not revoked.
Assuming the license was OK the server then invokes other
"authorities" for any additional information needed using the
identity as given in the license (certificate).  The result is returned
as a nicely formatted screen on the officer's PDA.  Except for
the fact that the screen is static [:-)], I don't see any particular
staleness here.  Unless for the *possible* reliance on CRLs
you have a problem with.  But CRLs are just an option.

But you do have a point.  To put a lot of potentially stale information
in a certificate is a bad idea.  "Employee certificates" is an example
of a broken scheme as they vouch for not less than three things:
An individual, an organization, and an unspecified [= totally useless]
association between these two entities.  Here I really believe that your
on-line, real-time paradigm will become the norm.

<snip>

Anders







Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h05NB2Y06572 for ietf-pkix-bks; Sun, 5 Jan 2003 15:11:02 -0800 (PST)
Received: from mailf.telia.com (mailf.telia.com [194.22.194.25]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h05NB1o06564 for <[e-mail]>; Sun, 5 Jan 2003 15:11:01 -0800 (PST)
Received: from arport (h119n2fls31o1122.telia.com [212.181.142.119]) by mailf.telia.com (8.12.5/8.12.5) with SMTP id h05NAhTk002233; Mon, 6 Jan 2003 00:10:43 +0100 (CET)
X-Original-Recipient: [e-mail]
Message-ID: <005701c2b50f$682d4790$0500a8c0@arport>
From: "Anders Rundgren" <[e-mail]>
To: "Ambarish Malpani" <[e-mail]>, <[e-mail]>
Cc: "IETF PKIX" <[e-mail]>
References: <[e-mail]>
Subject: Re: OCSP and LDAP
Date: Mon, 6 Jan 2003 00:08:49 +0100
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.50.4133.2400
X-MIMEOLE: Produced By Microsoft MimeOLE V5.50.4133.2400
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

<snip>

>Lets take another example ... driver's license. If you get stopped .... the
>typical real-time, online response isn't about whether the license is
>revoked or not (that is trivial subset) .... it is how many traffic
>citations/warrents are outstanding .... number of parking tickets, and
>potentially some number of other pieces of real-time, dynamic information.

No problems.
The licensee authenticates to the "traffic police server" which uses
OCSP to verify that the TTP-issued license is not revoked. 
Assuming the license was OK the server then invokes other
"authorities" for any additional information needed using the 
identity as given in the license (certificate).  The result is returned
as a nicely formatted screen on the officer's PDA.  Except for
the fact that the screen is static [:-)], I don't see any particular
staleness here.  Unless for the *possible* reliance on CRLs
you have a problem with.  But CRLs are just an option.

But you do have a point.  To put a lot of potentially stale information 
in a certificate is a bad idea.  "Employee certificates" is an example
of a broken scheme as they vouch for not less than three things: 
An individual, an organization, and an unspecified [= totally useless]
association between these two entities.  Here I really believe that your
on-line, real-time paradigm will become the norm.

<snip>

Anders



Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h05LhLf02240 for ietf-pkix-bks; Sun, 5 Jan 2003 13:43:21 -0800 (PST)
Received: from nymelsmtp.internet.ny.fdms.firstdata.com (nymelsmtp01.firstdata.com [198.184.0.23]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h05LhKo02234 for <[e-mail]>; Sun, 5 Jan 2003 13:43:20 -0800 (PST)
Subject: RE: OCSP and LDAP
To: "Ambarish Malpani" <[e-mail]>
Cc: "IETF PKIX" <[e-mail]>
X-Mailer: Lotus Notes Release 5.0.5  September 22, 2000
Message-ID: <[e-mail]>
From: [e-mail]
Date: Sun, 5 Jan 2003 14:45:14 -0700
X-MIMETrack: Serialize by Router on NYMELSMTP/NY/FDMS/FDC(Release 5.0.8 |June 18, 2001) at 01/05/2003 04:45:17 PM
MIME-Version: 1.0
Content-type: text/plain; charset=us-ascii
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

the thesis was that OCSP could provide a status indication as to the
staleness of the static information in a certificate designed for offline
operation.

an online service can provide almost any level of real-time, fresh,
dynamic, and/or aggregated information.
For a value business operation using online, real-time, fresh, dynamic,
and/or aggregated information (that is a superset of the stale, static
information in a certicate designed for offline operation) ... then both
the certificate becomes redundant and superfluous and therefor an OCSP
transaction as to the degree of staleness of the stale, static information
becomes superfluous.

furthermore ... it has been trivial to show that for an operation involving
transfer of money .... that the actual transaction for the transfer of
money can be piggy-backed with the online, real-time, fresh, dynamic and/or
aggregated information operation ... at effectively no additional cost ....
and that then both a certificate and any OCSP are redundant and superluous.

I can have online, real-time, fresh, dynamic, and/or aggregated information
operation. Such information is a superset of offline, static, stale
certificate-based information. If i'm using the online, real-time, fresh,
dynamic, and/or aggregated information .... then the offline, static, stale
certificate-based information is redundant and superfluous.

--
Internet trivia, 20th anv: http://www.garlic.com/~lynn/rfcietff.htm


                                                                                     
                    "Ambarish Malpani"                                               
                    <ambarish@malpani.     To:      <[e-mail]>,    
                                  biz>        "IETF PKIX" <[e-mail]>        
                              Sent by:     cc:                                       
                    owner-ietf-pkix@ma     Subject:      RE: OCSP and LDAP           
                            il.imc.org                                               
                                                                                     
                                                                                     
                      01/05/2003 12:15                                               
                                    PM                                               
                                                                                     
                                                                                     






Hi Lynn,
    Not sure why you associate OCSP with stale information. The
responder can have as current information as you choose to provide
it.

Once again, I believe it makes sense to have the interaction
between the CA and the VA be CRLs. If there is more
current information you have (than is present in the CRL), it
makes sense to have that information at the VA for use until a
new CRL is produced.

Ambarish

P.S. We have also had people use their OCSP responder to provide
more than just certificate revocation information (eg. payment
authorization) using extensions to OCSP.


---------------------------------------------------------------------
Ambarish Malpani                                         650.759.9045
Malpani Consulting Services                      [e-mail]
http://www.malpani.biz



> -----Original Message-----
> From: [e-mail]
> [mailto:[e-mail]]On Behalf Of
> [e-mail]
> Sent: Sunday, January 05, 2003 6:53 AM
> To: Anders Rundgren
> Cc: [e-mail]; [e-mail]; [e-mail];
> [e-mail]; Peter Gutmann
> Subject: Re: OCSP and LDAP
>
>
>
>
> but as been discussed in other venues ... it is not only the cost ... but
> also who pays (how does the money flow). does a consumer pay for
> checking a
> merchant's certificate as part of access the merchant's website ....
which
> might otherwise be free access? A merchant (as the relying party)
> might pay
> when checking the status of a consumer's certificate .... but does a
> consumer (as the relying party) pay when checking the status of a
> merchant's certificate..  Also ... as in other merchant/consumer
> e-commerce
> discussions .... a merchant's interest in the status (real-time or not)
of
> a consumer's certificate is only incidental to whether the bank says that
> the merchant gets paid.
>
> now the other business flow as a certificate, offline, stale paradigm is
> pushed towards an online, real-time model .... there is a question of
what
> point does the paradigm switch. In the original offline credit-card
> paradigm .... the transition to online, real-time .... bypassed the
> real-time checking on whether the offline, stale credential was still
good
> ... and/or whether the stale assertions in the offline credential
> was still
> good .... but whether the real-time assertions were valid.
>
> The model in the certificate ... is that there are some
> assertions that are
> inserted into a stale, static certificate at some time in the
> past .... and
> for OCSP ... you do real-time checks to see if the stale, static past
> assertions still hold. The model that credit-cards went to .... was doing
> real-time checks on real-time assertions ... not real-time checks on
> real-time stale, static assertions.
>
> The distinction is that the payment card paradigm in moving to online ...
> bypassed the intermediate paradigm of real-time checks on past, stale,
> historic, static assertions (contined in the certificate) .... and went
> directly to real-time checks on current, real-time assertions, aka the
> credit-card industry in transitioning to online .... could have continued
> to preserve the offline paradigm with real time checks (like OCSP does
for
> certificates) .... which is equivalent to a real-time check to see if the
> consumer still has a valid account.  However, the payment card industry
in
> transitioning to online discovered that they could significantly leverage
> the utility of having real-time, online checking .... that instead of
> having real-time, online checking of stale, static information ....
> significantly increase the utility of having real-time checking of
> real-time information.
>
> So the credit-card industry skipped the OCSP-analogous step of having a
> real-time infrastructure for checking of stale, static data (aka does an
> account still exist), and significantly improved the utility of having an
> online, real-time infrastructure ... and performing real-time checking of
> what the merchant is really interested in .... will they get
> paid. An issue
> is whether the value of having a real-time online infrastructure is
> significantly depreciated if it is just being applied to checking
> status of
> static, stale information .... when for effectively the same
> infrastructure
> costs .... it can be used for real-time, online checking of real-time
> dynamic information (under the assumption that real-time checking of
> real-time dynamic information tends to have more value than real-time
> checking of static, stale information).
>
> ... i believe that the charge/chost at supermarket check-out for
> debit card
> transaction doing real-time checking for sufficient funds for the
> transaction (rather than just checking if the account still exists)
> as well as scheduling the transaction .... the charge/cost for
> both/combined ... is on the order of your projected lookup costs.
>
> If the online, real-time validation of real-time dynamic assertion
(rather
> the real-time validation of static, stale assertion) can be bundled with
> the actual execution of real transaction .... and be bundled for
> essentially the same cost of doing just online, real-time lookup
> of static,
> stale data .... then it would imply that static, stale data paradigm
would
> be somewhat redundant and superfulous in an online, real-time
environment.
>
> --
> Internet trivia, 20th anv: http://www.garlic.com/~lynn/rfcietff.htm
>
>
> [e-mail] on 1/5/2002 2:44 am wrote:
>
> I agree with Peter.
>
> I don't think OCSP in a not so distant future have to be more technically
> costly than accessing a web-page.  Including a signed answer.
>
> Some banks in Sweden believe 20 cents/lookup is a reasonable fee as it is
> "comparable to putting a stamp on a letter".
>
> Personally I don't think the VA-business model has much future as it
> complicates they way parties interact.  It essentially requires two or
> three global VA-networks in the world to function and that seems very
> unlikely to happen.  It feels like the VA business model is crafted
> according to the lines of credit-card authorizations, but that is a
rather
> different type of business IMHO.
>
> Pardon the slightly orthogonal input, but business & technology do have
> rather interesting connections...
>
> Anders
>
>
>







Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h05LVVw01420 for ietf-pkix-bks; Sun, 5 Jan 2003 13:31:31 -0800 (PST)
Received: from nymelsmtp.internet.ny.fdms.firstdata.com (nymelsmtp01.firstdata.com [198.184.0.23]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h05LVTo01409 for <[e-mail]>; Sun, 5 Jan 2003 13:31:30 -0800 (PST)
Subject: OCSP value proposition
To: "Anders Rundgren" <[e-mail]>
Cc: [e-mail], [e-mail], [e-mail], [e-mail], "Peter Gutmann" <[e-mail]>
X-Mailer: Lotus Notes Release 5.0.5  September 22, 2000
Message-ID: <[e-mail]>
From: [e-mail]
Date: Sun, 5 Jan 2003 14:33:18 -0700
X-MIMETrack: Serialize by Router on NYMELSMTP/NY/FDMS/FDC(Release 5.0.8 |June 18, 2001) at 01/05/2003 04:33:27 PM
MIME-Version: 1.0
Content-type: text/plain; charset=us-ascii
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

ok, i'm a RP sitting here with a credential that contains some certified
static, stale information .... that was designed to support an offline
paradigm.

The RP believes there is some business/value operation involved which has
some risk issues with the staleness of the information in the certificate.

A OCSP transaction provides the RP with some feeling as to the degree of
staleness .... in theory to better mitigate risks associated with the value
operation.

My assertions are

1) a online transaction can provide real-time, fresh, dynamic, and
aggregated information (which is a superset of the stale static information
contained in the certificate) for approximately the same cost as a
transaction about the staleness of the static certificate information.
furthermore nearly every business/value operation in existence has some
form of real-time, fresh, dynamic and aggregated information (for those
mired in certificate paradigm ... view the online, real-time response
containing this information as a one-time, immediately expiring
certificate).

2) the superset of the stale, static information with real-time, fresh,
dynamic, and aggregated information provides better quality risk management
than an opinion as to the staleness of the certificate static information
(at effectively the same cost).

3) given the same cost .... and greater value information for better risk
management .... the cost/benefit analysis would nearly always benefit the
real-time, fresh, dynamic aggregated response of an opinion about the
degree of static information staleness.

4) the real-time, fresh, dynamic and aggregated information potentially
provides the ability to piggy-back an actual business transaction as part
of the underlying online operation (for little or not additional cost) ....
this is the payment scenario.

5) for cost/benefit of risk management associated with real-time, fresh,
aggregated, and/or dynamic may represent such a compelling business
justification that all operations become online. For environment with all
online operations, using real-time, fresh, aggregated, and dynamic
information, then an offline certificate with static, stale information
(that is a subset of real-time, fresh, aggregated and dynamic information)
become totally redundant and superfluous. Certificates are at least
redundant and superfluous for those transactions involving real-time,
fresh, aggregated, and/or dynamic operations (if RP is getting the
real-time superset information ... then the stale, static, subset
information isn't needed).

So the question I believe was a value proposition for OCSP that

1)  involves value that justifies having online, real-time infrastructure

2) doesn't involve payments or money (as per somebody else's earlier
posting since it has already been shown that money infrastructure does a
piggy-back transaction based on real-time, fresh, dynamic, and aggregated
information).

3) only requires an opinion as to the staleness of static information
(yes/no)

4) has no incremental business justification for real-time, fresh, dynamic
and/or aggregated information.

--
Internet trivia, 20th anv: http://www.garlic.com/~lynn/rfcietff.htm



Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h05LVUd01417 for ietf-pkix-bks; Sun, 5 Jan 2003 13:31:30 -0800 (PST)
Received: from nymelsmtp.internet.ny.fdms.firstdata.com (nymelsmtp01.firstdata.com [198.184.0.23]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h05LVTo01406 for <[e-mail]>; Sun, 5 Jan 2003 13:31:29 -0800 (PST)
Subject: RE: OCSP and LDAP
To: "Ambarish Malpani" <[e-mail]>
Cc: "IETF PKIX" <[e-mail]>
X-Mailer: Lotus Notes Release 5.0.5  September 22, 2000
Message-ID: <[e-mail]>
From: [e-mail]
Date: Sun, 5 Jan 2003 14:01:25 -0700
X-MIMETrack: Serialize by Router on NYMELSMTP/NY/FDMS/FDC(Release 5.0.8 |June 18, 2001) at 01/05/2003 04:33:26 PM
MIME-Version: 1.0
Content-type: text/plain; charset=us-ascii
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

the certificate typically contains some assertions (age, address, name,
address, affiliation, etc) .... OCSP & CRLs are about the degree of
possible staleness of the assertions/information contianed in the
certificate .... not actual information itself

because the information is certified in the certificate ... at some time in
the past .... by definition ... you aren't going to see dynamic information
.... information in a certificate is about static information as of the
time the certificate is created. OCSP & CRLs doesn't represent actual
information .... it represents information about possibly how stale the
static information is ... not the static information itself.

so a characteristic of the certificate offline paradigm is static
information as of some point in the past. Online, real-time OCSP ...
doesn't provide current &/or dynamic information .... it just provides some
indication of how stale the static information in the certificate is.

An online, real-time infrastructure has the opportunity to transition to
providing online, real-time, current, & dynamic information .... not
limiting itself as to an opinion as to the degree of staleness contained in
the static certificate.

The business issue .... is that going to the trouble & expensive of having
an online, real-time infrastructure .... can be leveraged to provide
real-time, online (& dynamic) information.

So as in some other scenario (non payment card) .... was the issue of gov.
granting business licenses of various kinds.  The brain-dead translation is
to give them a gov. signed certificate representing that offline, paper
license. Now people that want timely information in the non-electronic
world .... go to online, real-time ... by calling and/or visiting the
various agencies (better business bureau, local gov. office, etc) and check
on the status of the license. Actually what most people do when doing
real-time checks on a business .... isn't just that the business license is
still valid ... but how many complaints, what kind of complaints, what kind
of recommendations, disposition of complaints, any fines, etc.  If they are
going to all the trouble of having a real-time check .... they aren't after
the OCSP version .... if they are going to all the trouble of a real-time
check ... they want the real-time, dynamic data version of the informattion
(not the old fashion, offline, static & possibly stale version of the
data).

My assertions has not been that certificates (offline, static, stale
information) are useless .... my assertions have been that if you are going
to the trouble of having a real-time, online infrastructure .... that the
value of that real-time online infrastructure is significantly enhanced by
offering higher value information .... like real-time dynamic information.
It isn't limited to the payment industry (lets say all electronic commerce)
or licensing (all gov. sanction activities) .... I claim that for nearly
all certification scenarios involving online, real-time ... the
infrastructure goes to the trouble of having real-time dynamic data.

Lets take another example ... driver's license. If you get stopped .... the
typical real-time, online response isn't about whether the license is
revoked or not (that is trivial subset) .... it is how many traffic
citations/warrents are outstanding .... number of parking tickets, and
potentially some number of other pieces of real-time, dynamic information.

The issue isn't whether offline, static, stale certified infomration is
useless. The issue is that in going to the trouble of having online,
real-time facilities .... there is the ability and the value proposition to
support online, teal-time dynamic information ... rather than offline,
static stale information.

All instances that I can think of where somebody is going to the trouble of
some real-time, online checking .... they are getting real-time dynamic
information ... not just a simple opinion about the possible degree of
staleness of static, offline information.

--
Internet trivia, 20th anv: http://www.garlic.com/~lynn/rfcietff.htm


                                                                                  
                          "Ambarish                                               
                           Malpani"     To:      <[e-mail]>,    
                    <ambarish@malpa        "IETF PKIX" <[e-mail]>        
                            ni.biz>     cc:                                       
                                        Subject:      RE: OCSP and LDAP           
                         01/05/2003                                               
                           12:15 PM                                               
                                                                                  
                                                                                  





Hi Lynn,
    Not sure why you associate OCSP with stale information. The
responder can have as current information as you choose to provide
it.

Once again, I believe it makes sense to have the interaction
between the CA and the VA be CRLs. If there is more
current information you have (than is present in the CRL), it
makes sense to have that information at the VA for use until a
new CRL is produced.

Ambarish

P.S. We have also had people use their OCSP responder to provide
more than just certificate revocation information (eg. payment
authorization) using extensions to OCSP.


---------------------------------------------------------------------
Ambarish Malpani                                         650.759.9045
Malpani Consulting Services                      [e-mail]
http://www.malpani.biz



> -----Original Message-----
> From: [e-mail]
> [mailto:[e-mail]]On Behalf Of
> [e-mail]
> Sent: Sunday, January 05, 2003 6:53 AM
> To: Anders Rundgren
> Cc: [e-mail]; [e-mail]; [e-mail];
> [e-mail]; Peter Gutmann
> Subject: Re: OCSP and LDAP
>
>
>
>
> but as been discussed in other venues ... it is not only the cost ... but
> also who pays (how does the money flow). does a consumer pay for
> checking a
> merchant's certificate as part of access the merchant's website ....
which
> might otherwise be free access? A merchant (as the relying party)
> might pay
> when checking the status of a consumer's certificate .... but does a
> consumer (as the relying party) pay when checking the status of a
> merchant's certificate..  Also ... as in other merchant/consumer
> e-commerce
> discussions .... a merchant's interest in the status (real-time or not)
of
> a consumer's certificate is only incidental to whether the bank says that
> the merchant gets paid.
>
> now the other business flow as a certificate, offline, stale paradigm is
> pushed towards an online, real-time model .... there is a question of
what
> point does the paradigm switch. In the original offline credit-card
> paradigm .... the transition to online, real-time .... bypassed the
> real-time checking on whether the offline, stale credential was still
good
> ... and/or whether the stale assertions in the offline credential
> was still
> good .... but whether the real-time assertions were valid.
>
> The model in the certificate ... is that there are some
> assertions that are
> inserted into a stale, static certificate at some time in the
> past .... and
> for OCSP ... you do real-time checks to see if the stale, static past
> assertions still hold. The model that credit-cards went to .... was doing
> real-time checks on real-time assertions ... not real-time checks on
> real-time stale, static assertions.
>
> The distinction is that the payment card paradigm in moving to online ...
> bypassed the intermediate paradigm of real-time checks on past, stale,
> historic, static assertions (contined in the certificate) .... and went
> directly to real-time checks on current, real-time assertions, aka the
> credit-card industry in transitioning to online .... could have continued
> to preserve the offline paradigm with real time checks (like OCSP does
for
> certificates) .... which is equivalent to a real-time check to see if the
> consumer still has a valid account.  However, the payment card industry
in
> transitioning to online discovered that they could significantly leverage
> the utility of having real-time, online checking .... that instead of
> having real-time, online checking of stale, static information ....
> significantly increase the utility of having real-time checking of
> real-time information.
>
> So the credit-card industry skipped the OCSP-analogous step of having a
> real-time infrastructure for checking of stale, static data (aka does an
> account still exist), and significantly improved the utility of having an
> online, real-time infrastructure ... and performing real-time checking of
> what the merchant is really interested in .... will they get
> paid. An issue
> is whether the value of having a real-time online infrastructure is
> significantly depreciated if it is just being applied to checking
> status of
> static, stale information .... when for effectively the same
> infrastructure
> costs .... it can be used for real-time, online checking of real-time
> dynamic information (under the assumption that real-time checking of
> real-time dynamic information tends to have more value than real-time
> checking of static, stale information).
>
> ... i believe that the charge/chost at supermarket check-out for
> debit card
> transaction doing real-time checking for sufficient funds for the
> transaction (rather than just checking if the account still exists)
> as well as scheduling the transaction .... the charge/cost for
> both/combined ... is on the order of your projected lookup costs.
>
> If the online, real-time validation of real-time dynamic assertion
(rather
> the real-time validation of static, stale assertion) can be bundled with
> the actual execution of real transaction .... and be bundled for
> essentially the same cost of doing just online, real-time lookup
> of static,
> stale data .... then it would imply that static, stale data paradigm
would
> be somewhat redundant and superfulous in an online, real-time
environment.
>
> --
> Internet trivia, 20th anv: http://www.garlic.com/~lynn/rfcietff.htm
>
>
> [e-mail] on 1/5/2002 2:44 am wrote:
>
> I agree with Peter.
>
> I don't think OCSP in a not so distant future have to be more technically
> costly than accessing a web-page.  Including a signed answer.
>
> Some banks in Sweden believe 20 cents/lookup is a reasonable fee as it is
> "comparable to putting a stamp on a letter".
>
> Personally I don't think the VA-business model has much future as it
> complicates they way parties interact.  It essentially requires two or
> three global VA-networks in the world to function and that seems very
> unlikely to happen.  It feels like the VA business model is crafted
> according to the lines of credit-card authorizations, but that is a
rather
> different type of business IMHO.
>
> Pardon the slightly orthogonal input, but business & technology do have
> rather interesting connections...
>
> Anders
>
>
>







Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h05JFlc17287 for ietf-pkix-bks; Sun, 5 Jan 2003 11:15:47 -0800 (PST)
Received: from ns.malpani.biz (adsl-63-194-89-166.dsl.snfc21.pacbell.net [63.194.89.166]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h05JFjo17278 for <[e-mail]>; Sun, 5 Jan 2003 11:15:45 -0800 (PST)
Received: from nt1 (nt1.malpani.biz [192.168.25.13]) by ns.malpani.biz (8.12.5/8.12.5) with SMTP id h05JFZZp005527; Sun, 5 Jan 2003 11:15:35 -0800
From: "Ambarish Malpani" <[e-mail]>
To: <[e-mail]>, "IETF PKIX" <[e-mail]>
Subject: RE: OCSP and LDAP
Date: Sun, 5 Jan 2003 11:15:49 -0800
Message-ID: <[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0)
In-Reply-To: <[e-mail]>
X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1106
Importance: Normal
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Hi Lynn,
    Not sure why you associate OCSP with stale information. The
responder can have as current information as you choose to provide
it.

Once again, I believe it makes sense to have the interaction
between the CA and the VA be CRLs. If there is more
current information you have (than is present in the CRL), it
makes sense to have that information at the VA for use until a
new CRL is produced.

Ambarish

P.S. We have also had people use their OCSP responder to provide
more than just certificate revocation information (eg. payment
authorization) using extensions to OCSP.


---------------------------------------------------------------------
Ambarish Malpani                                         650.759.9045
Malpani Consulting Services                      [e-mail]
http://www.malpani.biz



> -----Original Message-----
> From: [e-mail]
> [mailto:[e-mail]]On Behalf Of
> [e-mail]
> Sent: Sunday, January 05, 2003 6:53 AM
> To: Anders Rundgren
> Cc: [e-mail]; [e-mail]; [e-mail];
> [e-mail]; Peter Gutmann
> Subject: Re: OCSP and LDAP
>
>
>
>
> but as been discussed in other venues ... it is not only the cost ... but
> also who pays (how does the money flow). does a consumer pay for
> checking a
> merchant's certificate as part of access the merchant's website .... which
> might otherwise be free access? A merchant (as the relying party)
> might pay
> when checking the status of a consumer's certificate .... but does a
> consumer (as the relying party) pay when checking the status of a
> merchant's certificate..  Also ... as in other merchant/consumer
> e-commerce
> discussions .... a merchant's interest in the status (real-time or not) of
> a consumer's certificate is only incidental to whether the bank says that
> the merchant gets paid.
>
> now the other business flow as a certificate, offline, stale paradigm is
> pushed towards an online, real-time model .... there is a question of what
> point does the paradigm switch. In the original offline credit-card
> paradigm .... the transition to online, real-time .... bypassed the
> real-time checking on whether the offline, stale credential was still good
> ... and/or whether the stale assertions in the offline credential
> was still
> good .... but whether the real-time assertions were valid.
>
> The model in the certificate ... is that there are some
> assertions that are
> inserted into a stale, static certificate at some time in the
> past .... and
> for OCSP ... you do real-time checks to see if the stale, static past
> assertions still hold. The model that credit-cards went to .... was doing
> real-time checks on real-time assertions ... not real-time checks on
> real-time stale, static assertions.
>
> The distinction is that the payment card paradigm in moving to online ...
> bypassed the intermediate paradigm of real-time checks on past, stale,
> historic, static assertions (contined in the certificate) .... and went
> directly to real-time checks on current, real-time assertions, aka the
> credit-card industry in transitioning to online .... could have continued
> to preserve the offline paradigm with real time checks (like OCSP does for
> certificates) .... which is equivalent to a real-time check to see if the
> consumer still has a valid account.  However, the payment card industry in
> transitioning to online discovered that they could significantly leverage
> the utility of having real-time, online checking .... that instead of
> having real-time, online checking of stale, static information ....
> significantly increase the utility of having real-time checking of
> real-time information.
>
> So the credit-card industry skipped the OCSP-analogous step of having a
> real-time infrastructure for checking of stale, static data (aka does an
> account still exist), and significantly improved the utility of having an
> online, real-time infrastructure ... and performing real-time checking of
> what the merchant is really interested in .... will they get
> paid. An issue
> is whether the value of having a real-time online infrastructure is
> significantly depreciated if it is just being applied to checking
> status of
> static, stale information .... when for effectively the same
> infrastructure
> costs .... it can be used for real-time, online checking of real-time
> dynamic information (under the assumption that real-time checking of
> real-time dynamic information tends to have more value than real-time
> checking of static, stale information).
>
> ... i believe that the charge/chost at supermarket check-out for
> debit card
> transaction doing real-time checking for sufficient funds for the
> transaction (rather than just checking if the account still exists)
> as well as scheduling the transaction .... the charge/cost for
> both/combined ... is on the order of your projected lookup costs.
>
> If the online, real-time validation of real-time dynamic assertion (rather
> the real-time validation of static, stale assertion) can be bundled with
> the actual execution of real transaction .... and be bundled for
> essentially the same cost of doing just online, real-time lookup
> of static,
> stale data .... then it would imply that static, stale data paradigm would
> be somewhat redundant and superfulous in an online, real-time environment.
>
> --
> Internet trivia, 20th anv: http://www.garlic.com/~lynn/rfcietff.htm
>
>
> [e-mail] on 1/5/2002 2:44 am wrote:
>
> I agree with Peter.
>
> I don't think OCSP in a not so distant future have to be more technically
> costly than accessing a web-page.  Including a signed answer.
>
> Some banks in Sweden believe 20 cents/lookup is a reasonable fee as it is
> "comparable to putting a stamp on a letter".
>
> Personally I don't think the VA-business model has much future as it
> complicates they way parties interact.  It essentially requires two or
> three global VA-networks in the world to function and that seems very
> unlikely to happen.  It feels like the VA business model is crafted
> according to the lines of credit-card authorizations, but that is a rather
> different type of business IMHO.
>
> Pardon the slightly orthogonal input, but business & technology do have
> rather interesting connections...
>
> Anders
>
>
>



Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h05HrUl09365 for ietf-pkix-bks; Sun, 5 Jan 2003 09:53:30 -0800 (PST)
Received: from ns.malpani.biz (adsl-63-194-89-166.dsl.snfc21.pacbell.net [63.194.89.166]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h05HrTo09361 for <[e-mail]>; Sun, 5 Jan 2003 09:53:29 -0800 (PST)
Received: from nt1 (nt1.malpani.biz [192.168.25.13]) by ns.malpani.biz (8.12.5/8.12.5) with SMTP id h05HrDZp005498; Sun, 5 Jan 2003 09:53:14 -0800
From: "Ambarish Malpani" <[e-mail]>
To: "Peter Gutmann" <[e-mail]>, <[e-mail]>, <[e-mail]>
Subject: RE: OCSP and LDAP
Date: Sun, 5 Jan 2003 09:53:27 -0800
Message-ID: <[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0)
In-Reply-To: <[e-mail]>
X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1106
Importance: Normal
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Hi Peter,
     I agree completely with the statements that people don't
really use CRLs and that getting up to date information to all
clients via CRLs is hard.

    I, too, wish people would just use OCSP and move on with things.
That was the whole idea behind doing Valicert.

As I explained before - using CRLs as a mechanism for getting
snapshots from the CA, ability to accept emergency CRLs and the
ability to revoke/suspend at the VA give people all the benefits
of OCSP without needing to change their CA or have their VA tied
into the CA/need access to the CAs database.

Regards,
Ambarish

---------------------------------------------------------------------
Ambarish Malpani                                         650.759.9045
Malpani Consulting Services                      [e-mail]
http://www.malpani.biz



> -----Original Message-----
> From: [e-mail]
> [mailto:[e-mail]]On Behalf Of Peter Gutmann
> Sent: Sunday, January 05, 2003 12:20 AM
> To: [e-mail]; [e-mail]; [e-mail];
> [e-mail]
> Subject: RE: OCSP and LDAP
>
>
>
> "Ambarish Malpani" <[e-mail]> writes:
>
> >I have still to see a place where using CRLs as the mechanism
> for letting a
> >VA know of changes in the revocation data has led to poorer
> performance than
> >having the VA access the CA's database directly.
>
> Most of the CAs I know of issues CRLs a few times a day, some as
> infrequently
> as once a day.  If I'm doing processing with any kind of value
> attached to the
> transaction, I want to know whether the cert is valid right now,
> not whether
> it was OK last night when the CRL was issued (substitute "credit card" for
> "cert" to see why this is important).  I have never seen a
> situation where an
> offline CRL gives better performance than a real-time check of a live
> database, unless you happen to catch it just as the CRL is being
> issued, which
> (for a 24-hour CRL time) only works about once in 86,400 times.
>
> I think one of the reasons why there aren't more complaints about CRLs is
> because so many apps only pay lip service to revocation checking, so it
> doesn't really matter if it doesn't work proprely ("We go through
> the motions
> because the CA policy requires it"/"It's turned off by default, but we can
> claim it's there"/"We realise the CRL is almost always out of
> date, but our
> accounting processes should catch any problems"/etc are all excuses I've
> heard).  If you build a system where you can tell users that
> there's a simple
> online check which guarantees that at the time the check was done
> the cert was
> valid (rather than being valid a couple of hours ago) following the credit
> card model that businesses are used to, perhaps people would lend
> more weight
> to the value of checking.  Actually, as mentioned in my previous message,
> implementors are already doing this, and have been doing it for some time,
> because people care about real-time cert status information, it's just not
> standardised in any spec (yet :-) so you get a pile of proprietary ways of
> doing it.
>
> Peter.
>



Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h05GV4V04047 for ietf-pkix-bks; Sun, 5 Jan 2003 08:31:04 -0800 (PST)
Received: from mailf.telia.com (mailf.telia.com [194.22.194.25]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h05GUxo04023; Sun, 5 Jan 2003 08:31:00 -0800 (PST)
Received: from arport (h119n2fls31o1122.telia.com [212.181.142.119]) by mailf.telia.com (8.12.5/8.12.5) with SMTP id h05GUcTk009808; Sun, 5 Jan 2003 17:30:38 +0100 (CET)
X-Original-Recipient: [e-mail]
Message-ID: <001401c2b4d7$846e1390$0500a8c0@arport>
From: "Anders Rundgren" <[e-mail]>
To: <[e-mail]>
Cc: <[e-mail]>, <[e-mail]>, <[e-mail]>, <[e-mail]>, "Peter Gutmann" <[e-mail]>
References: <[e-mail]>
Subject: Re: OCSP and LDAP
Date: Sun, 5 Jan 2003 17:28:43 +0100
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.50.4133.2400
X-MIMEOLE: Produced By Microsoft MimeOLE V5.50.4133.2400
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Ok Lynn,
I believe we have heard this one a couple times before or so :-)

But, there *is* (believe it or not) a world *outside* of payment-
transactions.

Like e-governments having citizens typically using TTP-issued
certificates _authenticating_ to various services.

In case you want to respond to this, make a _SHORT_ note why
OCSP would _NOT_ fit (=be redundant in) the scenario above.

Now I must go back to my rost, it is time to party :-)

Anders


----- Original Message -----
From: <[e-mail]>
To: "Anders Rundgren" <[e-mail]>
Cc: <[e-mail]>; <[e-mail]>; <[e-mail]>; <[e-mail]>; "Peter Gutmann"
<[e-mail]>
Sent: Sunday, January 05, 2003 15:52
Subject: Re: OCSP and LDAP



but as been discussed in other venues ... it is not only the cost ... but
also who pays (how does the money flow). does a consumer pay for checking a
merchant's certificate as part of access the merchant's website .... which
might otherwise be free access? A merchant (as the relying party) might pay
when checking the status of a consumer's certificate .... but does a
consumer (as the relying party) pay when checking the status of a
merchant's certificate..  Also ... as in other merchant/consumer e-commerce
discussions .... a merchant's interest in the status (real-time or not) of
a consumer's certificate is only incidental to whether the bank says that
the merchant gets paid.

now the other business flow as a certificate, offline, stale paradigm is
pushed towards an online, real-time model .... there is a question of what
point does the paradigm switch. In the original offline credit-card
paradigm .... the transition to online, real-time .... bypassed the
real-time checking on whether the offline, stale credential was still good
... and/or whether the stale assertions in the offline credential was still
good .... but whether the real-time assertions were valid.

The model in the certificate ... is that there are some assertions that are
inserted into a stale, static certificate at some time in the past .... and
for OCSP ... you do real-time checks to see if the stale, static past
assertions still hold. The model that credit-cards went to .... was doing
real-time checks on real-time assertions ... not real-time checks on
real-time stale, static assertions.

The distinction is that the payment card paradigm in moving to online ...
bypassed the intermediate paradigm of real-time checks on past, stale,
historic, static assertions (contined in the certificate) .... and went
directly to real-time checks on current, real-time assertions, aka the
credit-card industry in transitioning to online .... could have continued
to preserve the offline paradigm with real time checks (like OCSP does for
certificates) .... which is equivalent to a real-time check to see if the
consumer still has a valid account.  However, the payment card industry in
transitioning to online discovered that they could significantly leverage
the utility of having real-time, online checking .... that instead of
having real-time, online checking of stale, static information ....
significantly increase the utility of having real-time checking of
real-time information.

So the credit-card industry skipped the OCSP-analogous step of having a
real-time infrastructure for checking of stale, static data (aka does an
account still exist), and significantly improved the utility of having an
online, real-time infrastructure ... and performing real-time checking of
what the merchant is really interested in .... will they get paid. An issue
is whether the value of having a real-time online infrastructure is
significantly depreciated if it is just being applied to checking status of
static, stale information .... when for effectively the same infrastructure
costs .... it can be used for real-time, online checking of real-time
dynamic information (under the assumption that real-time checking of
real-time dynamic information tends to have more value than real-time
checking of static, stale information).

... i believe that the charge/chost at supermarket check-out for debit card
transaction doing real-time checking for sufficient funds for the
transaction (rather than just checking if the account still exists)
as well as scheduling the transaction .... the charge/cost for
both/combined ... is on the order of your projected lookup costs.

If the online, real-time validation of real-time dynamic assertion (rather
the real-time validation of static, stale assertion) can be bundled with
the actual execution of real transaction .... and be bundled for
essentially the same cost of doing just online, real-time lookup of static,
stale data .... then it would imply that static, stale data paradigm would
be somewhat redundant and superfulous in an online, real-time environment.

--
Internet trivia, 20th anv: http://www.garlic.com/~lynn/rfcietff.htm


[e-mail] on 1/5/2002 2:44 am wrote:

I agree with Peter.

I don't think OCSP in a not so distant future have to be more technically
costly than accessing a web-page.  Including a signed answer.

Some banks in Sweden believe 20 cents/lookup is a reasonable fee as it is
"comparable to putting a stamp on a letter".

Personally I don't think the VA-business model has much future as it
complicates they way parties interact.  It essentially requires two or
three global VA-networks in the world to function and that seems very
unlikely to happen.  It feels like the VA business model is crafted
according to the lines of credit-card authorizations, but that is a rather
different type of business IMHO.

Pardon the slightly orthogonal input, but business & technology do have
rather interesting connections...

Anders






Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h05GSog03815 for ietf-pkix-bks; Sun, 5 Jan 2003 08:28:50 -0800 (PST)
Received: from ns.malpani.biz (adsl-63-194-89-166.dsl.snfc21.pacbell.net [63.194.89.166]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h05GSno03811 for <[e-mail]>; Sun, 5 Jan 2003 08:28:49 -0800 (PST)
Received: from nt1 (nt1.malpani.biz [192.168.25.13]) by ns.malpani.biz (8.12.5/8.12.5) with SMTP id h05GSWZp005467; Sun, 5 Jan 2003 08:28:32 -0800
From: "Ambarish Malpani" <[e-mail]>
To: "Peter Gutmann" <[e-mail]>, <[e-mail]>, <[e-mail]>
Subject: RE: OCSP and LDAP
Date: Sun, 5 Jan 2003 08:28:46 -0800
Message-ID: <[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0)
In-Reply-To: <[e-mail]>
X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1106
Importance: Normal
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Hi Peter,
    One of the things that I didn't mention in my original mail,
but that I think I had said on this list before, is that we do
allow our VA to use its own data to indicate that a certificate
is revoked/suspended if the VA knows that a certificate has
been revoked/suspended, but the CA has not had a chance to indicate
that.

3 other issues:
    a. When people try to keep their CAs offline, they not only
want keep the CAs signing key offline, but also its database. Having
the responder access the CAs database means that some of the CAs
data now needs to be online.

    b. If you want to locate VAs at multiple remote locations and
you have the VA access the CAs database, it needs to access that
database from remote locations.

    c. Most CA operators are prefectly happy to combine the
capablity above (of temporary suspension at the VA) and the fact
that a VA can accept a CRL issued at any time, to deal with the
issue of needing to revoke/suspend a cert while a CA is offline.

Hope this helps,
Regards,
Ambarish

---------------------------------------------------------------------
Ambarish Malpani                                         650.759.9045
Malpani Consulting Services                      [e-mail]
http://www.malpani.biz



> -----Original Message-----
> From: [e-mail]
> [mailto:[e-mail]]On Behalf Of Peter Gutmann
> Sent: Sunday, January 05, 2003 12:20 AM
> To: [e-mail]; [e-mail]; [e-mail];
> [e-mail]
> Subject: RE: OCSP and LDAP
>
>
>
> "Ambarish Malpani" <[e-mail]> writes:
>
> >I have still to see a place where using CRLs as the mechanism
> for letting a
> >VA know of changes in the revocation data has led to poorer
> performance than
> >having the VA access the CA's database directly.
>
> Most of the CAs I know of issues CRLs a few times a day, some as
> infrequently
> as once a day.  If I'm doing processing with any kind of value
> attached to the
> transaction, I want to know whether the cert is valid right now,
> not whether
> it was OK last night when the CRL was issued (substitute "credit card" for
> "cert" to see why this is important).  I have never seen a
> situation where an
> offline CRL gives better performance than a real-time check of a live
> database, unless you happen to catch it just as the CRL is being
> issued, which
> (for a 24-hour CRL time) only works about once in 86,400 times.
>
> I think one of the reasons why there aren't more complaints about CRLs is
> because so many apps only pay lip service to revocation checking, so it
> doesn't really matter if it doesn't work proprely ("We go through
> the motions
> because the CA policy requires it"/"It's turned off by default, but we can
> claim it's there"/"We realise the CRL is almost always out of
> date, but our
> accounting processes should catch any problems"/etc are all excuses I've
> heard).  If you build a system where you can tell users that
> there's a simple
> online check which guarantees that at the time the check was done
> the cert was
> valid (rather than being valid a couple of hours ago) following the credit
> card model that businesses are used to, perhaps people would lend
> more weight
> to the value of checking.  Actually, as mentioned in my previous message,
> implementors are already doing this, and have been doing it for some time,
> because people care about real-time cert status information, it's just not
> standardised in any spec (yet :-) so you get a pile of proprietary ways of
> doing it.
>
> Peter.
>



Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h05Eopm25886 for ietf-pkix-bks; Sun, 5 Jan 2003 06:50:51 -0800 (PST)
Received: from nymelsmtp.internet.ny.fdms.firstdata.com (nymelsmtp01.firstdata.com [198.184.0.23]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h05Eono25874 for <[e-mail]>; Sun, 5 Jan 2003 06:50:49 -0800 (PST)
Subject: Re: OCSP and LDAP
To: "Anders Rundgren" <[e-mail]>
Cc: [e-mail], [e-mail], [e-mail], [e-mail], "Peter Gutmann" <[e-mail]>
X-Mailer: Lotus Notes Release 5.0.5  September 22, 2000
Message-ID: <[e-mail]>
From: [e-mail]
Date: Sun, 5 Jan 2003 07:52:32 -0700
X-MIMETrack: Serialize by Router on NYMELSMTP/NY/FDMS/FDC(Release 5.0.8 |June 18, 2001) at 01/05/2003 09:52:45 AM
MIME-Version: 1.0
Content-type: text/plain; charset=us-ascii
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

but as been discussed in other venues ... it is not only the cost ... but
also who pays (how does the money flow). does a consumer pay for checking a
merchant's certificate as part of access the merchant's website .... which
might otherwise be free access? A merchant (as the relying party) might pay
when checking the status of a consumer's certificate .... but does a
consumer (as the relying party) pay when checking the status of a
merchant's certificate..  Also ... as in other merchant/consumer e-commerce
discussions .... a merchant's interest in the status (real-time or not) of
a consumer's certificate is only incidental to whether the bank says that
the merchant gets paid.

now the other business flow as a certificate, offline, stale paradigm is
pushed towards an online, real-time model .... there is a question of what
point does the paradigm switch. In the original offline credit-card
paradigm .... the transition to online, real-time .... bypassed the
real-time checking on whether the offline, stale credential was still good
... and/or whether the stale assertions in the offline credential was still
good .... but whether the real-time assertions were valid.

The model in the certificate ... is that there are some assertions that are
inserted into a stale, static certificate at some time in the past .... and
for OCSP ... you do real-time checks to see if the stale, static past
assertions still hold. The model that credit-cards went to .... was doing
real-time checks on real-time assertions ... not real-time checks on
real-time stale, static assertions.

The distinction is that the payment card paradigm in moving to online ...
bypassed the intermediate paradigm of real-time checks on past, stale,
historic, static assertions (contined in the certificate) .... and went
directly to real-time checks on current, real-time assertions, aka the
credit-card industry in transitioning to online .... could have continued
to preserve the offline paradigm with real time checks (like OCSP does for
certificates) .... which is equivalent to a real-time check to see if the
consumer still has a valid account.  However, the payment card industry in
transitioning to online discovered that they could significantly leverage
the utility of having real-time, online checking .... that instead of
having real-time, online checking of stale, static information ....
significantly increase the utility of having real-time checking of
real-time information.

So the credit-card industry skipped the OCSP-analogous step of having a
real-time infrastructure for checking of stale, static data (aka does an
account still exist), and significantly improved the utility of having an
online, real-time infrastructure ... and performing real-time checking of
what the merchant is really interested in .... will they get paid. An issue
is whether the value of having a real-time online infrastructure is
significantly depreciated if it is just being applied to checking status of
static, stale information .... when for effectively the same infrastructure
costs .... it can be used for real-time, online checking of real-time
dynamic information (under the assumption that real-time checking of
real-time dynamic information tends to have more value than real-time
checking of static, stale information).

... i believe that the charge/chost at supermarket check-out for debit card
transaction doing real-time checking for sufficient funds for the
transaction (rather than just checking if the account still exists)
as well as scheduling the transaction .... the charge/cost for
both/combined ... is on the order of your projected lookup costs.

If the online, real-time validation of real-time dynamic assertion (rather
the real-time validation of static, stale assertion) can be bundled with
the actual execution of real transaction .... and be bundled for
essentially the same cost of doing just online, real-time lookup of static,
stale data .... then it would imply that static, stale data paradigm would
be somewhat redundant and superfulous in an online, real-time environment.

--
Internet trivia, 20th anv: http://www.garlic.com/~lynn/rfcietff.htm


[e-mail] on 1/5/2002 2:44 am wrote:

I agree with Peter.

I don't think OCSP in a not so distant future have to be more technically
costly than accessing a web-page.  Including a signed answer.

Some banks in Sweden believe 20 cents/lookup is a reasonable fee as it is
"comparable to putting a stamp on a letter".

Personally I don't think the VA-business model has much future as it
complicates they way parties interact.  It essentially requires two or
three global VA-networks in the world to function and that seems very
unlikely to happen.  It feels like the VA business model is crafted
according to the lines of credit-card authorizations, but that is a rather
different type of business IMHO.

Pardon the slightly orthogonal input, but business & technology do have
rather interesting connections...

Anders





Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h05APgp25849 for ietf-pkix-bks; Sun, 5 Jan 2003 02:25:42 -0800 (PST)
Received: from mail.hackmasters.net (ppp-217-133-8-148.dialup.tiscali.it [217.133.8.148]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h05APdo25841 for <[e-mail]>; Sun, 5 Jan 2003 02:25:39 -0800 (PST)
Received: from localhost (localhost.localdomain [127.0.0.1]) by mail.hackmasters.net (Postfix) with ESMTP id 2FF3AF356 for <[e-mail]>; Sun,  5 Jan 2003 11:24:32 +0100 (CET)
Received: by mail.hackmasters.net (Postfix, from userid 509) id 4819CF35C; Sun,  5 Jan 2003 11:24:25 +0100 (CET)
Received: from hackmasters.net (galadriel.mpnet.hackmasters.net [10.5.122.180]) by mail.hackmasters.net (Postfix) with ESMTP id 110D9F356 for <[e-mail]>; Sun,  5 Jan 2003 11:24:23 +0100 (CET)
Message-ID: <[e-mail]>
Date: Sun, 05 Jan 2003 11:26:34 +0100
From: Massimiliano Pala <[e-mail]>
Organization: OpenCA
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.2.1) Gecko/20021130
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: [e-mail]
Subject: Re: OCSP and LDAP
References: <[e-mail]>
In-Reply-To: <[e-mail]>
Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms070109030600000701050208"
X-Virus-Scanned: by AMaViS perl-11
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

This is a cryptographically signed message in MIME format.

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

Hi all,

I am quoting one answer for all as it seems them all share the same
vision.


Ambarish Malpani wrote:
> Hi Massimiliano,
>     You should seriously consider having your responder work off a
> CA's CRL, rather than trying to access its database directly.

Well, our approach is towards the usage of an off-line CA so my
problem is that usually the CRL could be not up to date to the latest
status of the certificate (let's say a user request its certificate
to be revoked, from this time to the time the CRL will be issued
there could be a time gap during which I want the certificate
to be reported as invalid -- let's say with the onHold reason).

For this reason I need some more information rather than the only
CRL.

There is another question about this approach: if the client request
the status of one certificate with a serial that is not within the CRL,
should not the responder check for it (i.e. its existance?) and
if it does not have informations about it return an "unknown"
answer ?

> There are a set of reasons why this is a good idea. Here are are
> few (in no particular order):
> 
> - CA independence (might not be important for you)

This is one of the most important reason that drives my questions.

> - Helps auditability of the VA
> - Allows better control over replication (where you don't need
> 	to rely on LDAP replication - most CAs won't want to
> 	replicate the rest of their LDAP data)
> - Better performance - can keep the revocation data in memory and
> 	respond from memory - won't need to also have a LDAP lookup

I know, indeed we actually use a single file generated from the
certificates' db that is read by the responder and kept in memory,
but as the number of certificates grows and in case of a spawning
process approach used memory grows and performance drop.

IMHO I guess I need the latest CRL and the latest CSL (list of
"suspended" certificates -- i.e. certificates that for any reason
"could" be revoked but them are not, yet).

 From your answers I guess there is no reference on how to store
this information onto LDAP.

Do you think the best method could be storing a single pkcs7 file
with all the information into the main ca entry onto LDAP (and
when the CA updates the information, the OCSP will update its
internal data) or it is best having a field in the user's entry ?

Thanks to all of you for your answers.

-- 

C'you,

	Massimiliano Pala

--o-------------------------------------------------------------------------
Massimiliano Pala [OpenCA Project Manager]                [e-mail]
                                                  Tel.:   [phone]
http://www.openca.org                            Fax:    +39   178  221 8225
http://openca.sourceforge.net                    Mobile: [phone]

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

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIOZjCC
By8wggYXoAMCAQICASwwDQYJKoZIhvcNAQEEBQAwgYoxIjAgBgkqhkiG9w0BCQEWE3BraS5j
aWNhaWFAdW5pbW8uaXQxJzAlBgNVBAMTHlVuaW1vcmUgRW50ZSBkaSBDZXJ0aWZpY2F6aW9u
ZTEuMCwGA1UEChMlVW5pdmVyc2l0YScgZGkgTW9kZW5hIGUgUmVnZ2lvIEVtaWxpYTELMAkG
A1UEBhMCSVQwHhcNMDIwNzI0MTUyNjI2WhcNMDMxMjMxMjM1OTU5WjCBqTEaMBgGA1UEAxMR
TWFzc2ltaWxpYW5vIFBhbGExNTAzBgNVBAsTLERpcGFydGltZW50byBkaSBJbmdlZ25lcmlh
IGRlbGwnSW5mb3JtYXppb25lMRcwFQYDVQQLEw5TZWRlIGRpIE1vZGVuYTEuMCwGA1UEChMl
VW5pdmVyc2l0YScgZGkgTW9kZW5hIGUgUmVnZ2lvIEVtaWxpYTELMAkGA1UEBhMCSVQwgZ8w
DQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBANSesg80BGzryvQlplD0MJ2YWlSEUAZpiFmywpOm
l//lWMnhONmC/q0TrO7j9Bb195dNzCMuXFgvV49Sy1iyHAjDhpysFvm/xZbAS3j8prXNN23K
S3Oa7Zz2GrQpCHgupCPQL2cy+ARVwwFod2GOSCVoUACkndit964K/bfsGvyLAgMBAAGjggQB
MIID/TAMBgNVHRMBAf8EAjAAMBEGCWCGSAGG+EIBAQQEAwIFoDAOBgNVHQ8BAf8EBAMCA/gw
HQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMB0GA1UdDgQWBBT6aSO5yTMPTf9OdcWo
14pKLqEHMDCBtwYDVR0jBIGvMIGsgBRFHaYA4ZfoyU2aaUnZYMiYf4lFA6GBkKSBjTCBijEi
MCAGCSqGSIb3DQEJARYTcGtpLmNpY2FpYUB1bmltby5pdDEnMCUGA1UEAxMeVW5pbW9yZSBF
bnRlIGRpIENlcnRpZmljYXppb25lMS4wLAYDVQQKEyVVbml2ZXJzaXRhJyBkaSBNb2RlbmEg
ZSBSZWdnaW8gRW1pbGlhMQswCQYDVQQGEwJJVIIBADBqBglghkgBhvhCAQ0EXRZbUHJvZ2V0
dG8gUG9zdGEgRWxldHRyb25pY2EgU2ljdXJhIA0KVW5pdmVyc2l0YScgZGkgTW9kZW5hIGUg
UmVnZ2lvIEVtaWxpYSANCkMuSS5DLkEuSS5BLiANCjAiBgNVHREEGzAZgRdtYWR3b2xmQGhh
Y2ttYXN0ZXJzLm5ldDA0BgNVHRIELTArgRNwa2kuY2ljYWlhQHVuaW1vLml0hhRodHRwOi8v
cGtpLnVuaW1vLml0LzA/BggrBgEFBQcBAQQzMDEwLwYIKwYBBQUHMAKGI2h0dHA6Ly9wa2ku
dW5pbW8uaXQvY2EvaXNzdWVycy5odG1sMDIGA1UdHwQrMCkwJ6AloCOGIWh0dHA6Ly9wa2ku
dW5pbW8uaXQvY3JsL2NhY3JsLmNybDAwBglghkgBhvhCAQQEIxYhaHR0cDovL3BraS51bmlt
by5pdC9jcmwvY2FjcmwuY3JsMDAGCWCGSAGG+EIBAwQjFiFodHRwOi8vcGtpLnVuaW1vLml0
L2NybC9jYWNybC5jcmwwKgYJYIZIAYb4QgEHBB0WG2h0dHA6Ly9wa2kudW5pbW8uaXQvcmVu
ZXdhbDArBglghkgBhvhCAQgEHhYcaHR0cDovL3BraS51bmltby5pdC9jcHMvMS4xLzCB2QYD
VR0gBIHRMIHOMEMGCisGAQQBqQcBAQEwNTAzBggrBgEFBQcCARYnaHR0cDovL3d3dy5ldXJv
cGtpLm9yZy9jYS9yb290L2Nwcy8xLjEvMEEGCisGAQQBqQcCAQEwMzAxBggrBgEFBQcCARYl
aHR0cDovL3d3dy5ldXJvcGtpLm9yZy9jYS9pdC9jcHMvMS4xLzBEBgorBgEEAegTAQEBMDYw
NAYIKwYBBQUHAgEWKGh0dHA6Ly9tYWlsLnVuaW1vLml0L2Zpcm1hL2Nwc21vZGVuYS5odG0w
DQYJKoZIhvcNAQEEBQADggEBABn8ViNg4MPNRzEFFF4BsmRMP1YbUHbS+NmFvvys0D3xueex
Ie6HU+tkv9hz8++0MbLPnRY2qKpZXfWTbIOkrHLGVVHUkiZXFzfxsDMgcB4MWmSmhRVLfPqr
RZKAjIevO0JKIksq2xutAUqX5jkqZoGHpPv9JCiSI+cDRqOOW2Fh3JBGkcULKybrdwrSN6+S
NoTyTXR+ryeTBUXxu9rIbjrJdH3rKS7rz3ZkP2PKuFOb+Vbp829ALph1SJOLQrUnmJouLOSL
oVHW4zJK4zcAiNyMHua3HveLRkVINT9eDBeYBRPdn1k+LqdXqkXiEUPA+EIKeA23F5nQkqxI
mVVpaaYwggcvMIIGF6ADAgECAgEsMA0GCSqGSIb3DQEBBAUAMIGKMSIwIAYJKoZIhvcNAQkB
FhNwa2kuY2ljYWlhQHVuaW1vLml0MScwJQYDVQQDEx5Vbmltb3JlIEVudGUgZGkgQ2VydGlm
aWNhemlvbmUxLjAsBgNVBAoTJVVuaXZlcnNpdGEnIGRpIE1vZGVuYSBlIFJlZ2dpbyBFbWls
aWExCzAJBgNVBAYTAklUMB4XDTAyMDcyNDE1MjYyNloXDTAzMTIzMTIzNTk1OVowgakxGjAY
BgNVBAMTEU1hc3NpbWlsaWFubyBQYWxhMTUwMwYDVQQLEyxEaXBhcnRpbWVudG8gZGkgSW5n
ZWduZXJpYSBkZWxsJ0luZm9ybWF6aW9uZTEXMBUGA1UECxMOU2VkZSBkaSBNb2RlbmExLjAs
BgNVBAoTJVVuaXZlcnNpdGEnIGRpIE1vZGVuYSBlIFJlZ2dpbyBFbWlsaWExCzAJBgNVBAYT
AklUMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDUnrIPNARs68r0JaZQ9DCdmFpUhFAG
aYhZssKTppf/5VjJ4TjZgv6tE6zu4/QW9feXTcwjLlxYL1ePUstYshwIw4acrBb5v8WWwEt4
/Ka1zTdtyktzmu2c9hq0KQh4LqQj0C9nMvgEVcMBaHdhjkglaFAApJ3YrfeuCv237Br8iwID
AQABo4IEATCCA/0wDAYDVR0TAQH/BAIwADARBglghkgBhvhCAQEEBAMCBaAwDgYDVR0PAQH/
BAQDAgP4MB0GA1UdJQQWMBQGCCsGAQUFBwMCBggrBgEFBQcDBDAdBgNVHQ4EFgQU+mkjuckz
D03/TnXFqNeKSi6hBzAwgbcGA1UdIwSBrzCBrIAURR2mAOGX6MlNmmlJ2WDImH+JRQOhgZCk
gY0wgYoxIjAgBgkqhkiG9w0BCQEWE3BraS5jaWNhaWFAdW5pbW8uaXQxJzAlBgNVBAMTHlVu
aW1vcmUgRW50ZSBkaSBDZXJ0aWZpY2F6aW9uZTEuMCwGA1UEChMlVW5pdmVyc2l0YScgZGkg
TW9kZW5hIGUgUmVnZ2lvIEVtaWxpYTELMAkGA1UEBhMCSVSCAQAwagYJYIZIAYb4QgENBF0W
W1Byb2dldHRvIFBvc3RhIEVsZXR0cm9uaWNhIFNpY3VyYSANClVuaXZlcnNpdGEnIGRpIE1v
ZGVuYSBlIFJlZ2dpbyBFbWlsaWEgDQpDLkkuQy5BLkkuQS4gDQowIgYDVR0RBBswGYEXbWFk
d29sZkBoYWNrbWFzdGVycy5uZXQwNAYDVR0SBC0wK4ETcGtpLmNpY2FpYUB1bmltby5pdIYU
aHR0cDovL3BraS51bmltby5pdC8wPwYIKwYBBQUHAQEEMzAxMC8GCCsGAQUFBzAChiNodHRw
Oi8vcGtpLnVuaW1vLml0L2NhL2lzc3VlcnMuaHRtbDAyBgNVHR8EKzApMCegJaAjhiFodHRw
Oi8vcGtpLnVuaW1vLml0L2NybC9jYWNybC5jcmwwMAYJYIZIAYb4QgEEBCMWIWh0dHA6Ly9w
a2kudW5pbW8uaXQvY3JsL2NhY3JsLmNybDAwBglghkgBhvhCAQMEIxYhaHR0cDovL3BraS51
bmltby5pdC9jcmwvY2FjcmwuY3JsMCoGCWCGSAGG+EIBBwQdFhtodHRwOi8vcGtpLnVuaW1v
Lml0L3JlbmV3YWwwKwYJYIZIAYb4QgEIBB4WHGh0dHA6Ly9wa2kudW5pbW8uaXQvY3BzLzEu
MS8wgdkGA1UdIASB0TCBzjBDBgorBgEEAakHAQEBMDUwMwYIKwYBBQUHAgEWJ2h0dHA6Ly93
d3cuZXVyb3BraS5vcmcvY2Evcm9vdC9jcHMvMS4xLzBBBgorBgEEAakHAgEBMDMwMQYIKwYB
BQUHAgEWJWh0dHA6Ly93d3cuZXVyb3BraS5vcmcvY2EvaXQvY3BzLzEuMS8wRAYKKwYBBAHo
EwEBATA2MDQGCCsGAQUFBwIBFihodHRwOi8vbWFpbC51bmltby5pdC9maXJtYS9jcHNtb2Rl
bmEuaHRtMA0GCSqGSIb3DQEBBAUAA4IBAQAZ/FYjYODDzUcxBRReAbJkTD9WG1B20vjZhb78
rNA98bnnsSHuh1PrZL/Yc/PvtDGyz50WNqiqWV31k2yDpKxyxlVR1JImVxc38bAzIHAeDFpk
poUVS3z6q0WSgIyHrztCSiJLKtsbrQFKl+Y5KmaBh6T7/SQokiPnA0ajjlthYdyQRpHFCysm
63cK0jevkjaE8k10fq8nkwVF8bvayG46yXR96yku6892ZD9jyrhTm/lW6fNvQC6YdUiTi0K1
J5iaLizki6FR1uMySuM3AIjcjB7mtx73i0ZFSDU/XgwXmAUT3Z9ZPi6nV6pF4hFDwPhCCngN
txeZ0JKsSJlVaWmmMYIDNjCCAzICAQEwgZAwgYoxIjAgBgkqhkiG9w0BCQEWE3BraS5jaWNh
aWFAdW5pbW8uaXQxJzAlBgNVBAMTHlVuaW1vcmUgRW50ZSBkaSBDZXJ0aWZpY2F6aW9uZTEu
MCwGA1UEChMlVW5pdmVyc2l0YScgZGkgTW9kZW5hIGUgUmVnZ2lvIEVtaWxpYTELMAkGA1UE
BhMCSVQCASwwCQYFKw4DAhoFAKCCAfswGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkq
hkiG9w0BCQUxDxcNMDMwMTA1MTAyNjM0WjAjBgkqhkiG9w0BCQQxFgQUgWIROJlgSgOwC4pM
u/KuTcDHE70wUgYJKoZIhvcNAQkPMUUwQzAKBggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAw
DQYIKoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZIhvcNAwICASgwgaEGCSsGAQQBgjcQBDGB
kzCBkDCBijEiMCAGCSqGSIb3DQEJARYTcGtpLmNpY2FpYUB1bmltby5pdDEnMCUGA1UEAxMe
VW5pbW9yZSBFbnRlIGRpIENlcnRpZmljYXppb25lMS4wLAYDVQQKEyVVbml2ZXJzaXRhJyBk
aSBNb2RlbmEgZSBSZWdnaW8gRW1pbGlhMQswCQYDVQQGEwJJVAIBLDCBowYLKoZIhvcNAQkQ
AgsxgZOggZAwgYoxIjAgBgkqhkiG9w0BCQEWE3BraS5jaWNhaWFAdW5pbW8uaXQxJzAlBgNV
BAMTHlVuaW1vcmUgRW50ZSBkaSBDZXJ0aWZpY2F6aW9uZTEuMCwGA1UEChMlVW5pdmVyc2l0
YScgZGkgTW9kZW5hIGUgUmVnZ2lvIEVtaWxpYTELMAkGA1UEBhMCSVQCASwwDQYJKoZIhvcN
AQEBBQAEgYBLXrS93IFJAtuOfwRU6UvoxdGxtTldSWaxTYMNtAecQFMIiNfjs86vfoE1RkOp
B5EyrnOAGGIDTmPRax4f0egHlJ0/7NheF0RWk47xVFpoX5+PPH1KVtgYYBgy5gXghr1gCuIP
S+VWViOXSmYrOGvPL64r21ZFsGYreCzS1dhgXgAAAAAAAA==
--------------ms070109030600000701050208--



Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h059kNd19089 for ietf-pkix-bks; Sun, 5 Jan 2003 01:46:23 -0800 (PST)
Received: from maila.telia.com (maila.telia.com [194.22.194.231]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h059kJo19081 for <[e-mail]>; Sun, 5 Jan 2003 01:46:20 -0800 (PST)
Received: from arport (h119n2fls31o1122.telia.com [212.181.142.119]) by maila.telia.com (8.12.5/8.12.5) with SMTP id h059kC3Y014331; Sun, 5 Jan 2003 10:46:13 +0100 (CET)
X-Original-Recipient: [e-mail]
Message-ID: <003c01c2b49f$04c2f300$0500a8c0@arport>
From: "Anders Rundgren" <[e-mail]>
To: "Peter Gutmann" <[e-mail]>, <[e-mail]>, <[e-mail]>, <[e-mail]>
References: <[e-mail]>
Subject: Re: OCSP and LDAP
Date: Sun, 5 Jan 2003 10:44:18 +0100
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.50.4133.2400
X-MIMEOLE: Produced By Microsoft MimeOLE V5.50.4133.2400
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

I agree with Peter.

I don't think OCSP in a not so distant future have to be more
technically costly than accessing a web-page.  Including a signed
answer.

Some banks in Sweden believe 20 cents/lookup is a reasonable
fee as it is "comparable to putting a stamp on a letter".

Personally I don't think the VA-business model has much future
as it complicates they way parties interact.  It essentially
requires two or three global VA-networks in the world to function
and that seems very unlikely to happen.  It feels like the VA business
model is crafted according to the lines of credit-card authorizations,
but that is a rather different type of business IMHO.

Pardon the slightly orthogonal input, but business & technology do
have rather interesting connections...

Anders

----- Original Message ----- 
From: "Peter Gutmann" <[e-mail]>
To: <[e-mail]>; <[e-mail]>; <[e-mail]>; <[e-mail]>
Sent: Sunday, January 05, 2003 09:20
Subject: RE: OCSP and LDAP



"Ambarish Malpani" <[e-mail]> writes:

>I have still to see a place where using CRLs as the mechanism for letting a
>VA know of changes in the revocation data has led to poorer performance than
>having the VA access the CA's database directly.

Most of the CAs I know of issues CRLs a few times a day, some as infrequently
as once a day.  If I'm doing processing with any kind of value attached to the
transaction, I want to know whether the cert is valid right now, not whether
it was OK last night when the CRL was issued (substitute "credit card" for
"cert" to see why this is important).  I have never seen a situation where an
offline CRL gives better performance than a real-time check of a live
database, unless you happen to catch it just as the CRL is being issued, which
(for a 24-hour CRL time) only works about once in 86,400 times.

I think one of the reasons why there aren't more complaints about CRLs is
because so many apps only pay lip service to revocation checking, so it
doesn't really matter if it doesn't work proprely ("We go through the motions
because the CA policy requires it"/"It's turned off by default, but we can
claim it's there"/"We realise the CRL is almost always out of date, but our
accounting processes should catch any problems"/etc are all excuses I've
heard).  If you build a system where you can tell users that there's a simple
online check which guarantees that at the time the check was done the cert was
valid (rather than being valid a couple of hours ago) following the credit
card model that businesses are used to, perhaps people would lend more weight
to the value of checking.  Actually, as mentioned in my previous message,
implementors are already doing this, and have been doing it for some time,
because people care about real-time cert status information, it's just not
standardised in any spec (yet :-) so you get a pile of proprietary ways of
doing it.

Peter.



Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h0594Zi15036 for ietf-pkix-bks; Sun, 5 Jan 2003 01:04:35 -0800 (PST)
Received: from hermes.cs.auckland.ac.nz (hermes.cs.auckland.ac.nz [130.216.35.151]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h0594Xo15030 for <[e-mail]>; Sun, 5 Jan 2003 01:04:33 -0800 (PST)
Received: from medusa01.cs.auckland.ac.nz (medusa01.cs.auckland.ac.nz [130.216.34.60]) by hermes.cs.auckland.ac.nz (8.12.4/8.12.4) with ESMTP id h0594PbT014026; Sun, 5 Jan 2003 22:04:25 +1300
Received: (from pgut001@localhost) by medusa01.cs.auckland.ac.nz (8.11.6/8.11.6) id h0594Pq00841; Sun, 5 Jan 2003 22:04:25 +1300
Date: Sun, 5 Jan 2003 22:04:25 +1300
Message-Id: <[e-mail]>
From: [e-mail] (Peter Gutmann)
To: [e-mail], [e-mail], [e-mail]
Subject: RE: OCSP and LDAP
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

I wrote:

>I think one of the reasons why there aren't more complaints about CRLs is
>because so many apps only pay lip service to revocation checking, so it
>doesn't really matter if it doesn't work proprely ("We go through the motions
>because the CA policy requires it"/"It's turned off by default, but we can
<claim it's there"/"We realise the CRL is almost always out of date, but our
>accounting processes should catch any problems"/etc are all excuses I've
>heard).

Before someone leaps in here with the obvious "Well, DoD PKI users (or
something similar) do check CRLs, so they must be OK", what I was referring to
was the civilian masses who are expected to adopt PKI at some point.
Government users are a special case in that they have infinite resources to
throw at a project, can be ordered to use CRLs (or to charge a machine-gun),
and various other things that don't apply to the masses.

I realise that you can always dig up some user somewhere to illustrate some
point ("DoD users use X.400 email, so it must be OK"), but that's not a good
example of what the masses are doing.  I'm not going to be able to sell X.400
to commercial users on this basis, and a semi-functional validity checking
mechanism supplying out-of-date information is also rather a hard sell.  When
I hear users who do actually care about checking certs (for example ones using
them for medical EDI) say things like "We rely for the most part on the
hospitals to control access, and in any case it's no worse than the existing
paper-based system", I have to worry about how long they'll continue listening
to PKI advocates telling them how wonderful it's all going to be...

Peter.


Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h058wSS14208 for ietf-pkix-bks; Sun, 5 Jan 2003 00:58:28 -0800 (PST)
Received: from hermes.cs.auckland.ac.nz (hermes.cs.auckland.ac.nz [130.216.35.151]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h058wQo14200 for <[e-mail]>; Sun, 5 Jan 2003 00:58:26 -0800 (PST)
Received: from medusa01.cs.auckland.ac.nz (medusa01.cs.auckland.ac.nz [130.216.34.60]) by hermes.cs.auckland.ac.nz (8.12.4/8.12.4) with ESMTP id h058wAbT013977; Sun, 5 Jan 2003 21:58:10 +1300
Received: (from pgut001@localhost) by medusa01.cs.auckland.ac.nz (8.11.6/8.11.6) id h058w7c00730; Sun, 5 Jan 2003 21:58:07 +1300
Date: Sun, 5 Jan 2003 21:58:07 +1300
Message-Id: <[e-mail]>
From: [e-mail] (Peter Gutmann)
To: [e-mail], [e-mail], [e-mail]
Subject: RE: OCSP and LDAP
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

I wrote:

>I think one of the reasons why there aren't more complaints about CRLs is
>because so many apps only pay lip service to revocation checking, so it
>doesn't really matter if it doesn't work proprely ("We go through the motions
>because the CA policy requires it"/"It's turned off by default, but we can
<claim it's there"/"We realise the CRL is almost always out of date, but our
>accounting processes should catch any problems"/etc are all excuses I've
>heard).

Before someone leaps in here with the obvious "Well, DoD PKI users (or
something similar) do check CRLs, so they must be OK", what I was referring to
was the civilian masses who are expected to adopt PKI at some point.
Government users are a special case in that they have infinite resources to
throw at a project, can be ordered to use CRLs (or to charge a machine-gun),
and various other things that don't apply to the masses.

I realise that you can always dig up some user somewhere to illustrate some
point ("DoD users use X.400 email, so it must be OK"), but that's not a good
example of what the masses are doing.  I'm not going to be able to sell X.400
to commercial users on this basis, and a semi-functional validity checking
mechanism supplying out-of-date information is also rather a hard sell to
people.  When I hear users who do actually care about checking certs (for
example ones using them for medical EDI) say things like "We rely for the most
part on the hospitals to control access, and in any case it's no worse than
the existing paper-based system", I can see why PKI is a hard-sell.

Peter.


Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h058NxK11319 for ietf-pkix-bks; Sun, 5 Jan 2003 00:23:59 -0800 (PST)
Received: from hermes.cs.auckland.ac.nz (hermes.cs.auckland.ac.nz [130.216.35.151]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h058Nvo11310 for <[e-mail]>; Sun, 5 Jan 2003 00:23:57 -0800 (PST)
Received: from medusa01.cs.auckland.ac.nz (medusa01.cs.auckland.ac.nz [130.216.34.60]) by hermes.cs.auckland.ac.nz (8.12.4/8.12.4) with ESMTP id h058KGbT013676; Sun, 5 Jan 2003 21:20:16 +1300
Received: (from pgut001@localhost) by medusa01.cs.auckland.ac.nz (8.11.6/8.11.6) id h058KHj00419; Sun, 5 Jan 2003 21:20:17 +1300
Date: Sun, 5 Jan 2003 21:20:17 +1300
Message-Id: <[e-mail]>
From: [e-mail] (Peter Gutmann)
To: [e-mail], [e-mail], [e-mail], [e-mail]
Subject: RE: OCSP and LDAP
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

"Ambarish Malpani" <[e-mail]> writes:

>I have still to see a place where using CRLs as the mechanism for letting a
>VA know of changes in the revocation data has led to poorer performance than
>having the VA access the CA's database directly.

Most of the CAs I know of issues CRLs a few times a day, some as infrequently
as once a day.  If I'm doing processing with any kind of value attached to the
transaction, I want to know whether the cert is valid right now, not whether
it was OK last night when the CRL was issued (substitute "credit card" for
"cert" to see why this is important).  I have never seen a situation where an
offline CRL gives better performance than a real-time check of a live
database, unless you happen to catch it just as the CRL is being issued, which
(for a 24-hour CRL time) only works about once in 86,400 times.

I think one of the reasons why there aren't more complaints about CRLs is
because so many apps only pay lip service to revocation checking, so it
doesn't really matter if it doesn't work proprely ("We go through the motions
because the CA policy requires it"/"It's turned off by default, but we can
claim it's there"/"We realise the CRL is almost always out of date, but our
accounting processes should catch any problems"/etc are all excuses I've
heard).  If you build a system where you can tell users that there's a simple
online check which guarantees that at the time the check was done the cert was
valid (rather than being valid a couple of hours ago) following the credit
card model that businesses are used to, perhaps people would lend more weight
to the value of checking.  Actually, as mentioned in my previous message,
implementors are already doing this, and have been doing it for some time,
because people care about real-time cert status information, it's just not
standardised in any spec (yet :-) so you get a pile of proprietary ways of
doing it.

Peter.


Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h057rp207171 for ietf-pkix-bks; Sat, 4 Jan 2003 23:53:51 -0800 (PST)
Received: from ns.malpani.biz (adsl-63-194-89-166.dsl.snfc21.pacbell.net [63.194.89.166]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h057roo07164 for <[e-mail]>; Sat, 4 Jan 2003 23:53:50 -0800 (PST)
Received: from nt1 (nt1.malpani.biz [192.168.25.13]) by ns.malpani.biz (8.12.5/8.12.5) with SMTP id h057rbZp029126; Sat, 4 Jan 2003 23:53:38 -0800
From: "Ambarish Malpani" <[e-mail]>
To: "Peter Gutmann" <[e-mail]>, <[e-mail]>, <[e-mail]>
Subject: RE: OCSP and LDAP
Date: Sat, 4 Jan 2003 23:53:50 -0800
Message-ID: <[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0)
In-Reply-To: <[e-mail]>
X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1106
Importance: Normal
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Hi Peter,
    I have still to see a place where using CRLs as the
mechanism for letting a VA know of changes in the revocation
data has led to poorer performance than having the VA access
the CA's database directly.

It also allows larger PKIs to deploy responders in multiple
remote locations (where they might not want to replicate their CAs
databases).

Regards,
Ambarish

---------------------------------------------------------------------
Ambarish Malpani                                         650.759.9045
Malpani Consulting Services                      [e-mail]
http://www.malpani.biz



> -----Original Message-----
> From: [e-mail]
> [mailto:[e-mail]]On Behalf Of Peter Gutmann
> Sent: Saturday, January 04, 2003 9:31 PM
> To: [e-mail]; [e-mail]; [e-mail]
> Subject: RE: OCSP and LDAP
>
>
>
> "Ambarish Malpani" <[e-mail]> writes:
>
> >You should seriously consider having your responder work off a CA's CRL,
> >rather than trying to access its database directly. There are a set of
> >reasons why this is a good idea. Here are are few (in no
> particular order):
>
> You should seriously consider having your responder work off a
> CA's database
> rather than trying to use CRLs. There are a set of reasons why
> this is a good
> idea. Here are are few (in no particular order):
>
> - Real-time cert status rather than inserting an artificial delay for
>   compatibility with OSI ideology (someone once said that the only reason
>   you'd want to drive an online status protocol from an offline mechanism
>   is if you wanted to emphasise how broken it was [0]).
>
> - Much better performance (I have an RFC draft in the works which looks at
>   this which should be out RSN, I hope).  You can't build a
> faster system than
>   the one described in the RFC.
>
>   (Actually in the process of working on the RFC draft, I've
> discovered that
>   there are already a surprising number of implementations which
> work directly
>   from a CA database, some dating back to before OCSP was even an RFC.
>   Standardising this operation, rather than having everyone do their own
>   proprietary version, was one of the motivations for writing the draft).
>
> [0] I've lost the source of this quote, if it's yours please let
> me know so I
>     can attribute it.
>
> Hope this helps,
> Regards,
> Peter.
>



Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h055Vd721859 for ietf-pkix-bks; Sat, 4 Jan 2003 21:31:39 -0800 (PST)
Received: from hermes.cs.auckland.ac.nz (hermes.cs.auckland.ac.nz [130.216.35.151]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h055Vbo21854 for <[e-mail]>; Sat, 4 Jan 2003 21:31:37 -0800 (PST)
Received: from medusa01.cs.auckland.ac.nz (medusa01.cs.auckland.ac.nz [130.216.34.60]) by hermes.cs.auckland.ac.nz (8.12.4/8.12.4) with ESMTP id h055VKbT012209; Sun, 5 Jan 2003 18:31:20 +1300
Received: (from pgut001@localhost) by medusa01.cs.auckland.ac.nz (8.11.6/8.11.6) id h055VIh31601; Sun, 5 Jan 2003 18:31:18 +1300
Date: Sun, 5 Jan 2003 18:31:18 +1300
Message-Id: <[e-mail]>
From: [e-mail] (Peter Gutmann)
To: [e-mail], [e-mail], [e-mail]
Subject: RE: OCSP and LDAP
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

"Ambarish Malpani" <[e-mail]> writes:

>You should seriously consider having your responder work off a CA's CRL,
>rather than trying to access its database directly. There are a set of
>reasons why this is a good idea. Here are are few (in no particular order):

You should seriously consider having your responder work off a CA's database
rather than trying to use CRLs. There are a set of reasons why this is a good
idea. Here are are few (in no particular order):

- Real-time cert status rather than inserting an artificial delay for
  compatibility with OSI ideology (someone once said that the only reason
  you'd want to drive an online status protocol from an offline mechanism
  is if you wanted to emphasise how broken it was [0]).

- Much better performance (I have an RFC draft in the works which looks at
  this which should be out RSN, I hope).  You can't build a faster system than
  the one described in the RFC.

  (Actually in the process of working on the RFC draft, I've discovered that
  there are already a surprising number of implementations which work directly
  from a CA database, some dating back to before OCSP was even an RFC.
  Standardising this operation, rather than having everyone do their own
  proprietary version, was one of the motivations for writing the draft).

[0] I've lost the source of this quote, if it's yours please let me know so I
    can attribute it.

Hope this helps,
Regards,
Peter.


Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h04Mspk17273 for ietf-pkix-bks; Sat, 4 Jan 2003 14:54:51 -0800 (PST)
Received: from ns.malpani.biz (adsl-63-194-89-166.dsl.snfc21.pacbell.net [63.194.89.166]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h04Msoo17269 for <[e-mail]>; Sat, 4 Jan 2003 14:54:50 -0800 (PST)
Received: from nt1 (nt1.malpani.biz [192.168.25.13]) by ns.malpani.biz (8.12.5/8.12.5) with SMTP id h04MseZp028974; Sat, 4 Jan 2003 14:54:41 -0800
From: "Ambarish Malpani" <[e-mail]>
To: "Massimiliano Pala" <[e-mail]>, <[e-mail]>
Subject: RE: OCSP and LDAP
Date: Sat, 4 Jan 2003 14:54:52 -0800
Message-ID: <[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0)
In-Reply-To: <[e-mail]>
X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1106
Importance: Normal
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Hi Massimiliano,
    You should seriously consider having your responder work off a
CA's CRL, rather than trying to access its database directly.
There are a set of reasons why this is a good idea. Here are are
few (in no particular order):

- CA independence (might not be important for you)
- Helps auditability of the VA
- Allows better control over replication (where you don't need
	to rely on LDAP replication - most CAs won't want to
	replicate the rest of their LDAP data)
- Better performance - can keep the revocation data in memory and
	respond from memory - won't need to also have a LDAP lookup


Hope this helps,
Regards,
Ambarish

---------------------------------------------------------------------
Ambarish Malpani                                         650.759.9045
Malpani Consulting Services                      [e-mail]
http://www.malpani.biz



> -----Original Message-----
> From: [e-mail]
> [mailto:[e-mail]]On Behalf Of Massimiliano Pala
> Sent: Saturday, January 04, 2003 9:24 AM
> To: [e-mail]
> Subject: OCSP and LDAP
> 
> 
> Hi all,
> 
> it might be an old question but If you can not answer me I really 
> don't know
> where to look... Here it is.
> 
> We are trying to rebuild our OCSPd backend and one of the 
> possibilities was
> to use the LDAP server to store (besides the issued certificates) 
> informations
> needed to the OCSPd to build the responses (i.e. at least the 
> status of the
> certificates).
> 
> Are there RFCs/raccomandations that will help us in using a good schema
> for storing this kind of informations and in not making big mistakes ?
> 
> Thank to you all for all the work you are doing.
> 
> -- 
> 
> C'you on the bit stream,
> 
> 	Massimiliano Pala
> 
> --o---------------------------------------------------------------
> ----------
> Massimiliano Pala [OpenCA Project Manager]                
> [e-mail]
>                                                   Tel.:   +39 
> (0)59  270  094
> http://www.openca.org                            Fax:    +39   
> 178  221 8225
> http://openca.sourceforge.net                    Mobile: +39 
> (0)347 7222 365
> 


Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h04KjmH04625 for ietf-pkix-bks; Sat, 4 Jan 2003 12:45:48 -0800 (PST)
Received: from gil.axelero.hu (mail01.axelero.hu [195.228.240.76]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h04Kjko04618 for <[e-mail]>; Sat, 4 Jan 2003 12:45:47 -0800 (PST)
Received: from houston (adsl-169-75.adsl-pool.axelero.hu [62.201.75.169]) by mail01.axelero.hu (iPlanet Messaging Server 5.1 HotFix 1.9 (built Dec  3 2002)) with SMTP id <[e-mail]> for [e-mail]; Sat, 04 Jan 2003 21:45:43 +0100 (MET)
Date: Sat, 04 Jan 2003 21:45:43 +0100
From: Adam Tresch <[e-mail]>
Subject: RE: OCSP and LDAP
In-reply-to: <[e-mail]>
To: Massimiliano Pala <[e-mail]>, PKIX Working Group <[e-mail]>
Reply-to: [e-mail]
Message-id: <[e-mail]>
MIME-version: 1.0
X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1106
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0)
Content-type: multipart/signed; boundary="----=_NextPart_000_0013_01C2B43A.9E8A6CD0"; micalg=SHA1; protocol="application/x-pkcs7-signature"
Importance: Normal
X-Priority: 3 (Normal)
X-MSMail-priority: Normal
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

This is a multi-part message in MIME format.

------=_NextPart_000_0013_01C2B43A.9E8A6CD0
Content-Type: text/plain;
	charset="US-ASCII"
Content-Transfer-Encoding: 7bit

Massimiliano,

if am i right, then the easyest way to retreive the cert status form the
actual CRL.
You dont need to extand the schema, use only the valid CRL as the source
of the info.
But, in this case, the CA must issue a new crl after each revocation
immediately.


Adam

-----Original Message-----
From: [e-mail] [mailto:[e-mail]]On
Behalf Of Massimiliano Pala
Sent: Saturday, January 04, 2003 6:24 PM
To: [e-mail]
Subject: OCSP and LDAP


Hi all,

it might be an old question but If you can not answer me I really don't
know
where to look... Here it is.

We are trying to rebuild our OCSPd backend and one of the possibilities
was
to use the LDAP server to store (besides the issued certificates)
informations
needed to the OCSPd to build the responses (i.e. at least the status of
the
certificates).

Are there RFCs/raccomandations that will help us in using a good schema
for storing this kind of informations and in not making big mistakes ?

Thank to you all for all the work you are doing.

--

C'you on the bit stream,

	Massimiliano Pala

--o-----------------------------------------------------------------------
--
Massimiliano Pala [OpenCA Project Manager]
[e-mail]
                                                  Tel.:   [phone]
094
http://www.openca.org                            Fax:    +39   178  221
8225
http://openca.sourceforge.net                    Mobile: [phone]
365

------=_NextPart_000_0013_01C2B43A.9E8A6CD0
Content-Type: application/x-pkcs7-signature;
	name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment;
	filename="smime.p7s"

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIHJTCCA44w
ggJ2oAMCAQICBQC6vvrPMA0GCSqGSIb3DQEBBQUAME8xCzAJBgNVBAYTAkhVMRQwEgYDVQQKEwtR
dWF0dHJvc29mdDERMA8GA1UECxMIU2VjdXJpdHkxFzAVBgNVBAMTDlF1YXR0cm9zb2Z0IENBMB4X
DTAyMTIxNjIzMzMwN1oXDTAzMTIxNjIzMzMwN1owgZAxCzAJBgNVBAYTAkhVMRQwEgYDVQQKEwtR
dWF0dHJvc29mdDERMA8GA1UECxMIRW1wbG95ZWUxFzAVBgoJkiaJk/IsZAEBEwdhdHJlc2NoMRQw
EgYDVQQDEwtBZGFtIFRyZXNjaDEpMCcGCSqGSIb3DQEJARYaYWRhbS50cmVzY2hAcXVhdHRyb3Nv
ZnQuaHUwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBAJaUVwTsvg1sYmPSGZThAqaLRuLCEBq1
30tOrdBhYhetEwUvn/48HeTvBm6D7yrvzQ9Xa0ITkUJ57JDOliZj8GLtrXFWG2fuyNZ3c+UOW6CY
1hCNaECue8QBQvO7ZltMTXyqVK1rc57fveyr1mDTKX3pUJkfX2hC2TzcuV2e0aJrAgMBAAGjgbIw
ga8wDgYDVR0PAQH/BAQDAgUgMBEGCWCGSAGG+EIBAQQEAwIFoDAfBgNVHSMEGDAWgBR3LnB+p+Gk
jVMa4mVPrrAVrGpzlzAlBgNVHREEHjAcgRphZGFtLnRyZXNjaEBxdWF0dHJvc29mdC5odTBCBggr
BgEFBQcBAQQ2MDQwMgYIKwYBBQUHMAGGJmh0dHA6Ly90aW1idWt0dS5jZW50YXVydXMuaHU6ODAw
MC9vY3NwMA0GCSqGSIb3DQEBBQUAA4IBAQB2LKh/tyX3rXyYU58FILr/3r4vPDZI4dqEV8xgfp5w
Kg2rcQhAHjBL6FmDuJtTBbGgjGqEua6DF5/l1pYXabwQ80WinY73M/Cde0e8Qr411/VX44q4wb1M
RNgeWtMDKiKs5rQCE70WB1M7TjgV4Rxr3kOF2hlbtwMYAhYOao/k9vfrIiwy8t2FoMgJ7hBqJlPv
WuxkZQnCH3uBECzECpyFBlrQv3Mf5f+vkLJHK26rey2xapMSrBynG4qXLBMz4T92geV9++hWiPoq
ptuOTxVp39BdcRI96csOf157cTjOI/cStwlOy9cuxI+lSTFU7hvKob1FTGeAU02c0rzc1GgdMIID
jzCCAnegAwIBAgIFALq++tAwDQYJKoZIhvcNAQEFBQAwTzELMAkGA1UEBhMCSFUxFDASBgNVBAoT
C1F1YXR0cm9zb2Z0MREwDwYDVQQLEwhTZWN1cml0eTEXMBUGA1UEAxMOUXVhdHRyb3NvZnQgQ0Ew
HhcNMDIxMjE2MjMzMzA3WhcNMDMxMjE2MjMzMzA3WjCBkDELMAkGA1UEBhMCSFUxFDASBgNVBAoT
C1F1YXR0cm9zb2Z0MREwDwYDVQQLEwhFbXBsb3llZTEXMBUGCgmSJomT8ixkAQETB2F0cmVzY2gx
FDASBgNVBAMTC0FkYW0gVHJlc2NoMSkwJwYJKoZIhvcNAQkBFhphZGFtLnRyZXNjaEBxdWF0dHJv
c29mdC5odTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAtdEvNmRSSpLBMMHv/FoeJ9GZ6LU9
Mz59dENo/fO6m5WLRA15jKApj5wG1fQKL93u+R+H9YIZ4cNM44XJjgSIxQ8O495iiHl+XrniJLld
0bwWnx77XtGAOGjZi3Re8bC27igvFnDK+mXhQruO7Z9CIuqtu+r6txBd5MRiwRSLnl8CAwEAAaOB
szCBsDAPBgNVHQ8BAf8EBQMDB4AAMBEGCWCGSAGG+EIBAQQEAwIFoDAfBgNVHSMEGDAWgBR3LnB+
p+GkjVMa4mVPrrAVrGpzlzAlBgNVHREEHjAcgRphZGFtLnRyZXNjaEBxdWF0dHJvc29mdC5odTBC
BggrBgEFBQcBAQQ2MDQwMgYIKwYBBQUHMAGGJmh0dHA6Ly90aW1idWt0dS5jZW50YXVydXMuaHU6
ODAwMC9vY3NwMA0GCSqGSIb3DQEBBQUAA4IBAQAU8wHSSupdfso5O7Lz0PpzDSnti29bzMoCx8nC
DgzXGCyQIgP51J7/Ahl/L7qH2Zb5jWnGKWPH7D+tJUpCzDMDTsdYfadolvnNgR9XmW5fhBfgP7bJ
yv5VT46GSfSYwjCCIm6F+f2UJhzXt0FRWZmEu1Pu9GFj8znCrhpeVXFKM0iDYOqSPBZUyPgzc4hy
autzLGd3gpP6z05gitgH5KhtBPJ5HJ8Ila1Oo00jrShTwnkiY+Eo8DtXAeWC2m0n5P08xgUFGkYe
md8O0Xrs6RcIUX+BuLXb7Vm92ArI8jPwAGg2MhcCufXLILD4JgA9UNOdDfwN8ok++bRG3B1FWT8O
MYICIjCCAh4CAQEwWDBPMQswCQYDVQQGEwJIVTEUMBIGA1UEChMLUXVhdHRyb3NvZnQxETAPBgNV
BAsTCFNlY3VyaXR5MRcwFQYDVQQDEw5RdWF0dHJvc29mdCBDQQIFALq++tAwCQYFKw4DAhoFAKCC
ASAwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMDMwMTA0MjA0NTM4
WjAjBgkqhkiG9w0BCQQxFgQU3vYYbykV5cfODbtdtcLs3+IbY3UwWAYJKoZIhvcNAQkPMUswSTAK
BggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwBwYFKw4DAgcwDQYIKoZIhvcNAwICASgwBwYFKw4D
AhowCgYIKoZIhvcNAgUwZwYJKwYBBAGCNxAEMVowWDBPMQswCQYDVQQGEwJIVTEUMBIGA1UEChML
UXVhdHRyb3NvZnQxETAPBgNVBAsTCFNlY3VyaXR5MRcwFQYDVQQDEw5RdWF0dHJvc29mdCBDQQIF
ALq++s8wDQYJKoZIhvcNAQEBBQAEgYB2c1HNT/zejVSETmEOL1Ux9XfjlX2SozqFnP7QHfw57R20
sXCvpeRmrWK7IiRfKVYXcZWWZydGvKobKFS1IECF+oqeOieBc88Ivo+nBZwIqXyzd6vpGm05GdcD
Q+ViaDFRBBx/zQdwt1h6EcAvuhQ1YeFz1AEYpf9FCfUx+3KuogAAAAAAAA==

------=_NextPart_000_0013_01C2B43A.9E8A6CD0--



Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h04JhQu26864 for ietf-pkix-bks; Sat, 4 Jan 2003 11:43:26 -0800 (PST)
Received: from woodstock.binhost.com (woodstock.binhost.com [207.228.252.5]) by above.proper.com (8.11.6/8.11.3) with SMTP id h04JhPo26860 for <[e-mail]>; Sat, 4 Jan 2003 11:43:25 -0800 (PST)
Received: (qmail 28843 invoked from network); 4 Jan 2003 19:43:05 -0000
Received: from unknown (HELO Russ-Laptop.vigilsec.com) (141.156.33.28) by woodstock.binhost.com with SMTP; 4 Jan 2003 19:43:05 -0000
Message-Id: <[e-mail]>
X-Sender: [e-mail] (Unverified)
X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9
Date: Sat, 04 Jan 2003 14:42:25 -0500
To: "Kurt D. Zeilenga" <[e-mail]>
From: Russ Housley <[e-mail]>
Subject: Re: LDAP PKI Schema (was Re: No-op LDAP ;binary option)
Cc: [e-mail], [e-mail]
In-Reply-To: <5.2.0.9.0.20030103171102.024f3360@127.0.0.1>
References: <[e-mail]> <5.2.0.9.0.20021230223309.01dc1a40@127.0.0.1> <[e-mail]> <000901c29759$9f4d1df0$[e-mail]> <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Kurt:

I can support this position, as it sicks one solution for use in the PKIX 
schema.  It picks the certificate matching approach, which is fine with me.

It does mean that deployment will require servers and clients to be 
upgraded.  This is also fine with me.  The alternative requires client to 
be upgraded, but not servers.

Russ

At 05:59 PM 1/3/2003 -0800, Kurt D. Zeilenga wrote:
>Here are my recommendations to the PKIX WG:
>
>    The PKIX WG should not take on engineering of a PKI-specific
>    solution to the certificate matching / returning problems
>    which draft-klasen-ldap-x509certificate-schema.  General
>    solutions suitable for standardization exist to resolve these
>    problems.
>
>    The PKIX WG should, as part of its PKI LDAPv3 applicability
>    statement work, detail requirements of PKI implementations
>    to support:
>         a) existing LDAP PKI schema (as revised by PKIX WG)
>         b) component matching rule extension
>         c) matched values control extension
>
>    The PKIX WG should revise the LDAPv3 PKI Schema in a manner
>    which preserves existing interoperability (e.g., add
>    missing matching rules to userCertificate and friends,
>    fix up reference to X.509, etc.).
>
>At 02:18 PM 1/3/2003, Russ Housley wrote:
> >I must voice my disagreement with this approach, again.
>
>Let me rephrase the part I think you object to:
>
>   I have no objection to the proponents of
>   draft-klasen-ldap-x509certificate-schema continuing
>   to pursuing their work on an individual basis.  In
>   its current form, I would oppose publication as a
>   non-Experimental RFC.  As an Experimental RFC, I would
>   ask that an IESG Note be added to the document clarifying
>   that the document details an alternative to existing
>   and future IETF standards which implementors should favor.
>
>Kurt



Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h04HNpC18893 for ietf-pkix-bks; Sat, 4 Jan 2003 09:23:51 -0800 (PST)
Received: from mail.hackmasters.net (ppp-217-133-8-148.dialup.tiscali.it [217.133.8.148]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h04HNlo18887 for <[e-mail]>; Sat, 4 Jan 2003 09:23:48 -0800 (PST)
Received: from localhost (localhost.localdomain [127.0.0.1]) by mail.hackmasters.net (Postfix) with ESMTP id 641FFF35C for <[e-mail]>; Sat,  4 Jan 2003 18:22:27 +0100 (CET)
Received: by mail.hackmasters.net (Postfix, from userid 509) id B8E9CF368; Sat,  4 Jan 2003 18:22:20 +0100 (CET)
Received: from hackmasters.net (galadriel.mpnet.hackmasters.net [10.5.122.180]) by mail.hackmasters.net (Postfix) with ESMTP id B82FCF35C for <[e-mail]>; Sat,  4 Jan 2003 18:22:18 +0100 (CET)
Message-ID: <[e-mail]>
Date: Sat, 04 Jan 2003 18:24:23 +0100
From: Massimiliano Pala <[e-mail]>
Organization: OpenCA
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.2.1) Gecko/20021130
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: [e-mail]
Subject: OCSP and LDAP
Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms020405030008000600070108"
X-Virus-Scanned: by AMaViS perl-11
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

This is a cryptographically signed message in MIME format.

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

Hi all,

it might be an old question but If you can not answer me I really don't know
where to look... Here it is.

We are trying to rebuild our OCSPd backend and one of the possibilities was
to use the LDAP server to store (besides the issued certificates) informations
needed to the OCSPd to build the responses (i.e. at least the status of the
certificates).

Are there RFCs/raccomandations that will help us in using a good schema
for storing this kind of informations and in not making big mistakes ?

Thank to you all for all the work you are doing.

-- 

C'you on the bit stream,

	Massimiliano Pala

--o-------------------------------------------------------------------------
Massimiliano Pala [OpenCA Project Manager]                [e-mail]
                                                  Tel.:   [phone]
http://www.openca.org                            Fax:    +39   178  221 8225
http://openca.sourceforge.net                    Mobile: [phone]

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

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIOZjCC
By8wggYXoAMCAQICASwwDQYJKoZIhvcNAQEEBQAwgYoxIjAgBgkqhkiG9w0BCQEWE3BraS5j
aWNhaWFAdW5pbW8uaXQxJzAlBgNVBAMTHlVuaW1vcmUgRW50ZSBkaSBDZXJ0aWZpY2F6aW9u
ZTEuMCwGA1UEChMlVW5pdmVyc2l0YScgZGkgTW9kZW5hIGUgUmVnZ2lvIEVtaWxpYTELMAkG
A1UEBhMCSVQwHhcNMDIwNzI0MTUyNjI2WhcNMDMxMjMxMjM1OTU5WjCBqTEaMBgGA1UEAxMR
TWFzc2ltaWxpYW5vIFBhbGExNTAzBgNVBAsTLERpcGFydGltZW50byBkaSBJbmdlZ25lcmlh
IGRlbGwnSW5mb3JtYXppb25lMRcwFQYDVQQLEw5TZWRlIGRpIE1vZGVuYTEuMCwGA1UEChMl
VW5pdmVyc2l0YScgZGkgTW9kZW5hIGUgUmVnZ2lvIEVtaWxpYTELMAkGA1UEBhMCSVQwgZ8w
DQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBANSesg80BGzryvQlplD0MJ2YWlSEUAZpiFmywpOm
l//lWMnhONmC/q0TrO7j9Bb195dNzCMuXFgvV49Sy1iyHAjDhpysFvm/xZbAS3j8prXNN23K
S3Oa7Zz2GrQpCHgupCPQL2cy+ARVwwFod2GOSCVoUACkndit964K/bfsGvyLAgMBAAGjggQB
MIID/TAMBgNVHRMBAf8EAjAAMBEGCWCGSAGG+EIBAQQEAwIFoDAOBgNVHQ8BAf8EBAMCA/gw
HQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMB0GA1UdDgQWBBT6aSO5yTMPTf9OdcWo
14pKLqEHMDCBtwYDVR0jBIGvMIGsgBRFHaYA4ZfoyU2aaUnZYMiYf4lFA6GBkKSBjTCBijEi
MCAGCSqGSIb3DQEJARYTcGtpLmNpY2FpYUB1bmltby5pdDEnMCUGA1UEAxMeVW5pbW9yZSBF
bnRlIGRpIENlcnRpZmljYXppb25lMS4wLAYDVQQKEyVVbml2ZXJzaXRhJyBkaSBNb2RlbmEg
ZSBSZWdnaW8gRW1pbGlhMQswCQYDVQQGEwJJVIIBADBqBglghkgBhvhCAQ0EXRZbUHJvZ2V0
dG8gUG9zdGEgRWxldHRyb25pY2EgU2ljdXJhIA0KVW5pdmVyc2l0YScgZGkgTW9kZW5hIGUg
UmVnZ2lvIEVtaWxpYSANCkMuSS5DLkEuSS5BLiANCjAiBgNVHREEGzAZgRdtYWR3b2xmQGhh
Y2ttYXN0ZXJzLm5ldDA0BgNVHRIELTArgRNwa2kuY2ljYWlhQHVuaW1vLml0hhRodHRwOi8v
cGtpLnVuaW1vLml0LzA/BggrBgEFBQcBAQQzMDEwLwYIKwYBBQUHMAKGI2h0dHA6Ly9wa2ku
dW5pbW8uaXQvY2EvaXNzdWVycy5odG1sMDIGA1UdHwQrMCkwJ6AloCOGIWh0dHA6Ly9wa2ku
dW5pbW8uaXQvY3JsL2NhY3JsLmNybDAwBglghkgBhvhCAQQEIxYhaHR0cDovL3BraS51bmlt
by5pdC9jcmwvY2FjcmwuY3JsMDAGCWCGSAGG+EIBAwQjFiFodHRwOi8vcGtpLnVuaW1vLml0
L2NybC9jYWNybC5jcmwwKgYJYIZIAYb4QgEHBB0WG2h0dHA6Ly9wa2kudW5pbW8uaXQvcmVu
ZXdhbDArBglghkgBhvhCAQgEHhYcaHR0cDovL3BraS51bmltby5pdC9jcHMvMS4xLzCB2QYD
VR0gBIHRMIHOMEMGCisGAQQBqQcBAQEwNTAzBggrBgEFBQcCARYnaHR0cDovL3d3dy5ldXJv
cGtpLm9yZy9jYS9yb290L2Nwcy8xLjEvMEEGCisGAQQBqQcCAQEwMzAxBggrBgEFBQcCARYl
aHR0cDovL3d3dy5ldXJvcGtpLm9yZy9jYS9pdC9jcHMvMS4xLzBEBgorBgEEAegTAQEBMDYw
NAYIKwYBBQUHAgEWKGh0dHA6Ly9tYWlsLnVuaW1vLml0L2Zpcm1hL2Nwc21vZGVuYS5odG0w
DQYJKoZIhvcNAQEEBQADggEBABn8ViNg4MPNRzEFFF4BsmRMP1YbUHbS+NmFvvys0D3xueex
Ie6HU+tkv9hz8++0MbLPnRY2qKpZXfWTbIOkrHLGVVHUkiZXFzfxsDMgcB4MWmSmhRVLfPqr
RZKAjIevO0JKIksq2xutAUqX5jkqZoGHpPv9JCiSI+cDRqOOW2Fh3JBGkcULKybrdwrSN6+S
NoTyTXR+ryeTBUXxu9rIbjrJdH3rKS7rz3ZkP2PKuFOb+Vbp829ALph1SJOLQrUnmJouLOSL
oVHW4zJK4zcAiNyMHua3HveLRkVINT9eDBeYBRPdn1k+LqdXqkXiEUPA+EIKeA23F5nQkqxI
mVVpaaYwggcvMIIGF6ADAgECAgEsMA0GCSqGSIb3DQEBBAUAMIGKMSIwIAYJKoZIhvcNAQkB
FhNwa2kuY2ljYWlhQHVuaW1vLml0MScwJQYDVQQDEx5Vbmltb3JlIEVudGUgZGkgQ2VydGlm
aWNhemlvbmUxLjAsBgNVBAoTJVVuaXZlcnNpdGEnIGRpIE1vZGVuYSBlIFJlZ2dpbyBFbWls
aWExCzAJBgNVBAYTAklUMB4XDTAyMDcyNDE1MjYyNloXDTAzMTIzMTIzNTk1OVowgakxGjAY
BgNVBAMTEU1hc3NpbWlsaWFubyBQYWxhMTUwMwYDVQQLEyxEaXBhcnRpbWVudG8gZGkgSW5n
ZWduZXJpYSBkZWxsJ0luZm9ybWF6aW9uZTEXMBUGA1UECxMOU2VkZSBkaSBNb2RlbmExLjAs
BgNVBAoTJVVuaXZlcnNpdGEnIGRpIE1vZGVuYSBlIFJlZ2dpbyBFbWlsaWExCzAJBgNVBAYT
AklUMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDUnrIPNARs68r0JaZQ9DCdmFpUhFAG
aYhZssKTppf/5VjJ4TjZgv6tE6zu4/QW9feXTcwjLlxYL1ePUstYshwIw4acrBb5v8WWwEt4
/Ka1zTdtyktzmu2c9hq0KQh4LqQj0C9nMvgEVcMBaHdhjkglaFAApJ3YrfeuCv237Br8iwID
AQABo4IEATCCA/0wDAYDVR0TAQH/BAIwADARBglghkgBhvhCAQEEBAMCBaAwDgYDVR0PAQH/
BAQDAgP4MB0GA1UdJQQWMBQGCCsGAQUFBwMCBggrBgEFBQcDBDAdBgNVHQ4EFgQU+mkjuckz
D03/TnXFqNeKSi6hBzAwgbcGA1UdIwSBrzCBrIAURR2mAOGX6MlNmmlJ2WDImH+JRQOhgZCk
gY0wgYoxIjAgBgkqhkiG9w0BCQEWE3BraS5jaWNhaWFAdW5pbW8uaXQxJzAlBgNVBAMTHlVu
aW1vcmUgRW50ZSBkaSBDZXJ0aWZpY2F6aW9uZTEuMCwGA1UEChMlVW5pdmVyc2l0YScgZGkg
TW9kZW5hIGUgUmVnZ2lvIEVtaWxpYTELMAkGA1UEBhMCSVSCAQAwagYJYIZIAYb4QgENBF0W
W1Byb2dldHRvIFBvc3RhIEVsZXR0cm9uaWNhIFNpY3VyYSANClVuaXZlcnNpdGEnIGRpIE1v
ZGVuYSBlIFJlZ2dpbyBFbWlsaWEgDQpDLkkuQy5BLkkuQS4gDQowIgYDVR0RBBswGYEXbWFk
d29sZkBoYWNrbWFzdGVycy5uZXQwNAYDVR0SBC0wK4ETcGtpLmNpY2FpYUB1bmltby5pdIYU
aHR0cDovL3BraS51bmltby5pdC8wPwYIKwYBBQUHAQEEMzAxMC8GCCsGAQUFBzAChiNodHRw
Oi8vcGtpLnVuaW1vLml0L2NhL2lzc3VlcnMuaHRtbDAyBgNVHR8EKzApMCegJaAjhiFodHRw
Oi8vcGtpLnVuaW1vLml0L2NybC9jYWNybC5jcmwwMAYJYIZIAYb4QgEEBCMWIWh0dHA6Ly9w
a2kudW5pbW8uaXQvY3JsL2NhY3JsLmNybDAwBglghkgBhvhCAQMEIxYhaHR0cDovL3BraS51
bmltby5pdC9jcmwvY2FjcmwuY3JsMCoGCWCGSAGG+EIBBwQdFhtodHRwOi8vcGtpLnVuaW1v
Lml0L3JlbmV3YWwwKwYJYIZIAYb4QgEIBB4WHGh0dHA6Ly9wa2kudW5pbW8uaXQvY3BzLzEu
MS8wgdkGA1UdIASB0TCBzjBDBgorBgEEAakHAQEBMDUwMwYIKwYBBQUHAgEWJ2h0dHA6Ly93
d3cuZXVyb3BraS5vcmcvY2Evcm9vdC9jcHMvMS4xLzBBBgorBgEEAakHAgEBMDMwMQYIKwYB
BQUHAgEWJWh0dHA6Ly93d3cuZXVyb3BraS5vcmcvY2EvaXQvY3BzLzEuMS8wRAYKKwYBBAHo
EwEBATA2MDQGCCsGAQUFBwIBFihodHRwOi8vbWFpbC51bmltby5pdC9maXJtYS9jcHNtb2Rl
bmEuaHRtMA0GCSqGSIb3DQEBBAUAA4IBAQAZ/FYjYODDzUcxBRReAbJkTD9WG1B20vjZhb78
rNA98bnnsSHuh1PrZL/Yc/PvtDGyz50WNqiqWV31k2yDpKxyxlVR1JImVxc38bAzIHAeDFpk
poUVS3z6q0WSgIyHrztCSiJLKtsbrQFKl+Y5KmaBh6T7/SQokiPnA0ajjlthYdyQRpHFCysm
63cK0jevkjaE8k10fq8nkwVF8bvayG46yXR96yku6892ZD9jyrhTm/lW6fNvQC6YdUiTi0K1
J5iaLizki6FR1uMySuM3AIjcjB7mtx73i0ZFSDU/XgwXmAUT3Z9ZPi6nV6pF4hFDwPhCCngN
txeZ0JKsSJlVaWmmMYIDNjCCAzICAQEwgZAwgYoxIjAgBgkqhkiG9w0BCQEWE3BraS5jaWNh
aWFAdW5pbW8uaXQxJzAlBgNVBAMTHlVuaW1vcmUgRW50ZSBkaSBDZXJ0aWZpY2F6aW9uZTEu
MCwGA1UEChMlVW5pdmVyc2l0YScgZGkgTW9kZW5hIGUgUmVnZ2lvIEVtaWxpYTELMAkGA1UE
BhMCSVQCASwwCQYFKw4DAhoFAKCCAfswGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkq
hkiG9w0BCQUxDxcNMDMwMTA0MTcyNDIzWjAjBgkqhkiG9w0BCQQxFgQUSdMzFqDHDSReEHAT
A0OUTo+Z3hMwUgYJKoZIhvcNAQkPMUUwQzAKBggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAw
DQYIKoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZIhvcNAwICASgwgaEGCSsGAQQBgjcQBDGB
kzCBkDCBijEiMCAGCSqGSIb3DQEJARYTcGtpLmNpY2FpYUB1bmltby5pdDEnMCUGA1UEAxMe
VW5pbW9yZSBFbnRlIGRpIENlcnRpZmljYXppb25lMS4wLAYDVQQKEyVVbml2ZXJzaXRhJyBk
aSBNb2RlbmEgZSBSZWdnaW8gRW1pbGlhMQswCQYDVQQGEwJJVAIBLDCBowYLKoZIhvcNAQkQ
AgsxgZOggZAwgYoxIjAgBgkqhkiG9w0BCQEWE3BraS5jaWNhaWFAdW5pbW8uaXQxJzAlBgNV
BAMTHlVuaW1vcmUgRW50ZSBkaSBDZXJ0aWZpY2F6aW9uZTEuMCwGA1UEChMlVW5pdmVyc2l0
YScgZGkgTW9kZW5hIGUgUmVnZ2lvIEVtaWxpYTELMAkGA1UEBhMCSVQCASwwDQYJKoZIhvcN
AQEBBQAEgYCLW9J3c7zL5LZO0o7PzCQVHerB8bdoM31v0DDCLUFSKaTeHc7vVZYeRhLvoc+K
M9O1V/2lFV8ZQ5zzXe1mDLcg/PaqrhjDIXHDYEs0pedgQE8LVA1g/3rfLiAGz9RTqTRcVJB5
UzZHjR7VFqb+wnGt3WEWzJQ9aAJTVpVwlbmCXAAAAAAAAA==
--------------ms020405030008000600070108--



Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h04HBp218597 for ietf-pkix-bks; Sat, 4 Jan 2003 09:11:51 -0800 (PST)
Received: from maila.telia.com (maila.telia.com [194.22.194.231]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h04HBoo18592 for <[e-mail]>; Sat, 4 Jan 2003 09:11:50 -0800 (PST)
Received: from arport (h119n2fls31o1122.telia.com [212.181.142.119]) by maila.telia.com (8.12.5/8.12.5) with SMTP id h04HBo3Y008530; Sat, 4 Jan 2003 18:11:50 +0100 (CET)
X-Original-Recipient: [e-mail]
Message-ID: <016701c2b414$1bee1a90$0500a8c0@arport>
From: "Anders Rundgren" <[e-mail]>
To: <[e-mail]>, <[e-mail]>
References: <[e-mail]>
Subject: Re: "Web Services" PKI RFC
Date: Sat, 4 Jan 2003 18:09:57 +0100
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.50.4133.2400
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Thanx Alice,
You are the third person indicating interest in this!

Maybe Web Services is really as "red hot" as I always claim it is :-)

BTW, there are some outstanding warranty-issues to cater
for as well...

More to read : http://www.verisign.com/netsure
"Limited Liability Warranty" (!)

Best
Anders

----- Original Message ----- 
From: "Alice Sturgeon" <[e-mail]>
To: "Anders Rundgren" <[e-mail]>; <[e-mail]>
Sent: Saturday, January 04, 2003 17:47
Subject: RE: "Web Services" PKI RFC


Anders,
FYI, ISO/IEC JTC 1 is initiating a 'study period' to consider whether JTC 1
and its sub-committees should work on standardization in the area of Web
services.  This is at the point of soliciting interest from the national
bodies that participate in JTC 1.  We should know probably by the end of
January whether there is sufficient interest to go ahead with this.  If we
do, then there would clearly be synergy on this issue between JTC 1 and any
work by IETF.  I volunteered to participate because it is of interest to me.
Concerning your call for interest, I would say 'yes' to the last two points
(genuine interest in PKI-enabling business systems and consider user/market
acceptance as the number one issue), but not the first (except for the X.509
part).
I will let you know the outcome of the JTC 1 initiative.

Alice


Alice Sturgeon
Chair
Canadian Advisory Committee - Information Technology Security
ISO/IEC JTC1 SC 27
and
System Policy Architect
SPYRUS
Phone:     [phone]
Cell:         613-291-0331



-----Original Message-----
From: [e-mail] [mailto:[e-mail]]On
Behalf Of Anders Rundgren
Sent: January 3, 2003 5:13 PM
To: [e-mail]
Subject: "Web Services" PKI RFC


Dear all,

I am interested in creating an RFC (or similar) for a certificate-
profile matching the needs of the emerging "Web Services" technology.

The major reason for creating a specific profile is that Web Services
are plug-and-play while plain-vanilla X.509 is not.

Some initial work has already been carried out but I would like to
get in contact with other people who:

- Know SQL, XML, Java, X.509, and to some extent ASN.1
- Are genuinely interested in PKI-enabling business systems
- See user- and market-acceptance as the #1 issue

Exactly where the possible result will land is still open, it could be
in OASIS as well as this seems to be the "Home of Web Services".

Anders Rundgren
Senior Internet e-Commerce Architect
+46 70 - 627 74 37 (CET 9.00-21.00)




Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h04Ghvh18149 for ietf-pkix-bks; Sat, 4 Jan 2003 08:43:57 -0800 (PST)
Received: from mx1.magmacom.com (mx1.magmacom.com [206.191.0.217]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h04Ghuo18144 for <[e-mail]>; Sat, 4 Jan 2003 08:43:57 -0800 (PST)
Received: from mail3.magma.ca (mail3.magma.ca [206.191.0.221]) by mx1.magmacom.com (Magma's Mail Server) with ESMTP id h04Ghv1t017490; Sat, 4 Jan 2003 11:43:57 -0500 (EST)
Received: from asturgeonpc (ssm-on50-158.netcom.ca [142.154.169.30]) by mail3.magma.ca (Magma's Mail Server) with SMTP id h04Ghuh9013381; Sat, 4 Jan 2003 11:43:56 -0500 (EST)
Reply-To: <[e-mail]>
From: "Alice Sturgeon" <[e-mail]>
To: "Anders Rundgren" <[e-mail]>, <[e-mail]>
Subject: RE: "Web Services" PKI RFC
Date: Sat, 4 Jan 2003 11:47:49 -0500
Message-ID: <[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0)
X-MIMEOLE: Produced By Microsoft MimeOLE V5.50.4133.2400
Importance: Normal
In-Reply-To: <00be01c2b375$5764e210$0500a8c0@arport>
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Anders,
FYI, ISO/IEC JTC 1 is initiating a 'study period' to consider whether JTC 1
and its sub-committees should work on standardization in the area of Web
services.  This is at the point of soliciting interest from the national
bodies that participate in JTC 1.  We should know probably by the end of
January whether there is sufficient interest to go ahead with this.  If we
do, then there would clearly be synergy on this issue between JTC 1 and any
work by IETF.  I volunteered to participate because it is of interest to me.
Concerning your call for interest, I would say 'yes' to the last two points
(genuine interest in PKI-enabling business systems and consider user/market
acceptance as the number one issue), but not the first (except for the X.509
part).
I will let you know the outcome of the JTC 1 initiative.

Alice


Alice Sturgeon
Chair
Canadian Advisory Committee - Information Technology Security
ISO/IEC JTC1 SC 27
and
System Policy Architect
SPYRUS
Phone:     [phone]
Cell:         613-291-0331



-----Original Message-----
From: [e-mail] [mailto:[e-mail]]On
Behalf Of Anders Rundgren
Sent: January 3, 2003 5:13 PM
To: [e-mail]
Subject: "Web Services" PKI RFC


Dear all,

I am interested in creating an RFC (or similar) for a certificate-
profile matching the needs of the emerging "Web Services" technology.

The major reason for creating a specific profile is that Web Services
are plug-and-play while plain-vanilla X.509 is not.

Some initial work has already been carried out but I would like to
get in contact with other people who:

- Know SQL, XML, Java, X.509, and to some extent ASN.1
- Are genuinely interested in PKI-enabling business systems
- See user- and market-acceptance as the #1 issue

Exactly where the possible result will land is still open, it could be
in OASIS as well as this seems to be the "Home of Web Services".

Anders Rundgren
Senior Internet e-Commerce Architect
+46 70 - 627 74 37 (CET 9.00-21.00)



Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h04208g03462 for ietf-pkix-bks; Fri, 3 Jan 2003 18:00:08 -0800 (PST)
Received: from pretender.boolean.net ([e-mail] [198.144.206.49]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h04207o03458 for <[e-mail]>; Fri, 3 Jan 2003 18:00:07 -0800 (PST)
Received: from nomad.OpenLDAP.org (root@localhost [127.0.0.1]) by pretender.boolean.net (8.12.6/8.12.5) with ESMTP id h042040a009710; Sat, 4 Jan 2003 02:00:05 GMT (envelope-from [e-mail])
Message-Id: <5.2.0.9.0.20030103171102.024f3360@127.0.0.1>
X-Sender: kurt@127.0.0.1
X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9
Date: Fri, 03 Jan 2003 17:59:51 -0800
To: Russ Housley <[e-mail]>
From: "Kurt D. Zeilenga" <[e-mail]>
Subject: Re: LDAP PKI Schema (was Re: No-op LDAP ;binary option)
Cc: [e-mail], [e-mail]
In-Reply-To: <[e-mail]>
References: <5.2.0.9.0.20021230223309.01dc1a40@127.0.0.1> <[e-mail]> <000901c29759$9f4d1df0$[e-mail]> <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Here are my recommendations to the PKIX WG:

   The PKIX WG should not take on engineering of a PKI-specific
   solution to the certificate matching / returning problems
   which draft-klasen-ldap-x509certificate-schema.  General
   solutions suitable for standardization exist to resolve these
   problems.

   The PKIX WG should, as part of its PKI LDAPv3 applicability
   statement work, detail requirements of PKI implementations
   to support:
        a) existing LDAP PKI schema (as revised by PKIX WG)
        b) component matching rule extension
        c) matched values control extension

   The PKIX WG should revise the LDAPv3 PKI Schema in a manner
   which preserves existing interoperability (e.g., add
   missing matching rules to userCertificate and friends,
   fix up reference to X.509, etc.).

At 02:18 PM 1/3/2003, Russ Housley wrote:
>I must voice my disagreement with this approach, again.

Let me rephrase the part I think you object to:

  I have no objection to the proponents of
  draft-klasen-ldap-x509certificate-schema continuing
  to pursuing their work on an individual basis.  In
  its current form, I would oppose publication as a
  non-Experimental RFC.  As an Experimental RFC, I would
  ask that an IESG Note be added to the document clarifying
  that the document details an alternative to existing
  and future IETF standards which implementors should favor.

Kurt 



Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h041W8a02255 for ietf-pkix-bks; Fri, 3 Jan 2003 17:32:08 -0800 (PST)
Received: from hermes.cs.auckland.ac.nz (hermes.cs.auckland.ac.nz [130.216.35.151]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h041W6o02251 for <[e-mail]>; Fri, 3 Jan 2003 17:32:06 -0800 (PST)
Received: from medusa01.cs.auckland.ac.nz (medusa01.cs.auckland.ac.nz [130.216.34.60]) by hermes.cs.auckland.ac.nz (8.12.4/8.12.4) with ESMTP id h041W3bT024728; Sat, 4 Jan 2003 14:32:03 +1300
Received: (from pgut001@localhost) by medusa01.cs.auckland.ac.nz (8.11.6/8.11.6) id h041W2719281; Sat, 4 Jan 2003 14:32:02 +1300
Date: Sat, 4 Jan 2003 14:32:02 +1300
Message-Id: <[e-mail]>
From: [e-mail] (Peter Gutmann)
To: [e-mail], [e-mail]
Subject: Re: I-D ACTION:draft-ietf-pkix-certstore-http-03.txt
Cc: [e-mail], [e-mail], [e-mail]
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

"Tom Gindin" <[e-mail]> writes:

>Of course I have no objection to mentioning a preference for subjectAltName
>over subject for e-mail addresses.  I just thought that anybody actually
>implementing something which extracts e-mail addresses from certificates
>would be helped by knowing all the places which are used in large numbers of
>certificates, not just the approved ones.  In the earlier wording ("an
>rfc822Name attribute") I wasn't sure whether implementors would interpret
>this as the rfc822mailbox directory attribute or the rfc822Name component of
>GeneralName, anyway.

I've actually reworded it to use mostly a very generic "email address
associated with the cert" (someone pointed out that there doesn't actually
have to be an email address in the cert for it to be associated with one). The
intent was never to provide an exhaustive enumeration of all possible places
it could be hidden, just to say that it was whatever address(es) were
associated with the cert.

Peter.


Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h03MJM918105 for ietf-pkix-bks; Fri, 3 Jan 2003 14:19:22 -0800 (PST)
Received: from woodstock.binhost.com (woodstock.binhost.com [207.228.252.5]) by above.proper.com (8.11.6/8.11.3) with SMTP id h03MJLo18101 for <[e-mail]>; Fri, 3 Jan 2003 14:19:21 -0800 (PST)
Received: (qmail 4298 invoked from network); 3 Jan 2003 22:19:03 -0000
Received: from unknown (HELO Russ-Laptop.vigilsec.com) (141.156.161.121) by woodstock.binhost.com with SMTP; 3 Jan 2003 22:19:03 -0000
Message-Id: <[e-mail]>
X-Sender: [e-mail] (Unverified)
X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9
Date: Fri, 03 Jan 2003 17:18:54 -0500
To: [e-mail]
From: Russ Housley <[e-mail]>
Subject: Re: LDAP PKI Schema (was Re: No-op LDAP ;binary option)
Cc: [e-mail], [e-mail]
In-Reply-To: <5.2.0.9.0.20021230223309.01dc1a40@127.0.0.1>
References: <[e-mail]> <000901c29759$9f4d1df0$[e-mail]> <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Kurt:

I must voice my disagreement with this approach, again.

This approach adds complexity to the PKI client.  In the long run, a PKI 
client must look in two places to locate a certificate.  The client cannot 
know if the PKI "child entry" approach or the component matching approach 
was used by the administrator posting the information.  As a result, the 
PKI client must first look in the userCertificate attribute of the subject 
entry.  If the PKI client does not find the expected certificate, then it 
must search for child entries.

I want to pick one or the other, not live with checking both for the 
foreseeable future.  If we pick the PKI "child entry" approach, then this 
should be the only way that certificates are stored.  This means a 
standards track document, not an informational or experimental one.  If we 
pick the component matching approach, then we can write the standards track 
document now, but we will have to wait for development and deployment of 
updated software.

WE MUST PICK ONE APPROACH, NOT TWO!

Russ

At 11:37 PM 12/30/2002 -0800, Kurt D. Zeilenga wrote:
>My recommendation is that the PKI "child entry" approach be
>pursued individually as an Experimental (or possibly Informational)
>solution to the PKI component matching problem with a note that
>a more general solution, component matching, is being standardized.



Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h03MFKc18051 for ietf-pkix-bks; Fri, 3 Jan 2003 14:15:20 -0800 (PST)
Received: from mailb.telia.com (mailb.telia.com [194.22.194.6]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h03MFJo18047 for <[e-mail]>; Fri, 3 Jan 2003 14:15:19 -0800 (PST)
Received: from arport (h119n2fls31o1122.telia.com [212.181.142.119]) by mailb.telia.com (8.12.5/8.12.5) with SMTP id h03MFIGS005997 for <[e-mail]>; Fri, 3 Jan 2003 23:15:18 +0100 (CET)
X-Original-Recipient: <[e-mail]>
Message-ID: <00be01c2b375$5764e210$0500a8c0@arport>
From: "Anders Rundgren" <[e-mail]>
To: <[e-mail]>
Subject: "Web Services" PKI RFC
Date: Fri, 3 Jan 2003 23:13:27 +0100
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.50.4133.2400
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Dear all,

I am interested in creating an RFC (or similar) for a certificate-
profile matching the needs of the emerging "Web Services" technology.

The major reason for creating a specific profile is that Web Services
are plug-and-play while plain-vanilla X.509 is not.

Some initial work has already been carried out but I would like to
get in contact with other people who:

- Know SQL, XML, Java, X.509, and to some extent ASN.1
- Are genuinely interested in PKI-enabling business systems
- See user- and market-acceptance as the #1 issue

Exactly where the possible result will land is still open, it could be
in OASIS as well as this seems to be the "Home of Web Services".

Anders Rundgren
Senior Internet e-Commerce Architect
+46 70 - 627 74 37 (CET 9.00-21.00)



Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h03LKmg11877 for ietf-pkix-bks; Fri, 3 Jan 2003 13:20:48 -0800 (PST)
Received: from ns.malpani.biz (adsl-63-194-89-166.dsl.snfc21.pacbell.net [63.194.89.166]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h03LKlo11873 for <[e-mail]>; Fri, 3 Jan 2003 13:20:47 -0800 (PST)
Received: from nt1 (nt1.malpani.biz [192.168.25.13]) by ns.malpani.biz (8.12.5/8.12.5) with SMTP id h03LKeZp028130; Fri, 3 Jan 2003 13:20:43 -0800
From: "Ambarish Malpani" <[e-mail]>
To: "Mitchell Arnone" <[e-mail]>, "Al Arsenault" <[e-mail]>, "Santosh Chokhani" <[e-mail]>, <[e-mail]>
Subject: RE: Offline Root CA with valid CRL hierachie
Date: Fri, 3 Jan 2003 13:20:49 -0800
Message-ID: <[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0)
In-Reply-To: <[e-mail]>
X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1106
Importance: Normal
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Hi Mitch,
    With OCSP, you can get around most of the CRL publishing issues.
One of the features I added to the Valicert OCSP responder (VA), was
to allow it (under operator control), to accept expired CRLs for a
fixed amount of time.

If the CA is operating the VA, it can issue a single CRL
and have the VA trust it for as long as he wishes to - for example
issue the CRL for a day, but have the responder trust it for 30. If
a new revocation needs to happen, you publish the new CRL to the VA,
which now starts trusting the new CRL (and no longer depends on the
old one).

It is also perfectly possible to have the VA run on its own data and
not rely on the CA software for revocation data at all - I know at
least one CA that chose to operate in that way (even though they
were operating both the CA and the VA themselves).

Regards,
Ambarish


---------------------------------------------------------------------
Ambarish Malpani                                         650.759.9045
Malpani Consulting Services                      [e-mail]
http://www.malpani.biz



> -----Original Message-----
> From: [e-mail]
> [mailto:[e-mail]]On Behalf Of Mitchell Arnone
> Sent: Friday, January 03, 2003 11:11 AM
> To: Al Arsenault; Santosh Chokhani; [e-mail]
> Subject: Re: Offline Root CA with valid CRL hierachie
>
>
>
> All points raised on this issue have been well stated.  I do believe that
> Dave's approach could work but my concern is that I too do not
> see any real
> advantage to it.  The 30 day CRL might be OK if the directories
> are secured
> and scaled properly and the 30 1day CRLs might be OK if the stack of
> pre-generated CRLs are secured and published properly.  I just
> think there
> is a better solution the likes of which others on this list have already
> commented.  Personally I like the OCSP approach but even that does not
> mitigate the need for an effective CRL publishing strategy.
>
> Thanks
>
> Mitch
>
> At 01:11 PM 1/3/2003, Al Arsenault wrote:
> >I'm not saying Dave's approach couldn't work; it certainly could.  And it
> >wouldn't significantly reduce security if the pre-generated CRLs were
> >properly controlled through physical/procedural means.  I'm just
> saying that
> >I don't see any real big advantage to it.
>
> ***********************************************************
> Mitchell Arnone
> Managing Consultant
> SchlumbergerSema
> Technical Consulting Practice, Northeast Region
> Network & Infrastructure Solutions
>
> [e-mail]
> www.slb.com/nws
>
> 35 Waterview Blvd.
> Suite 210
> Parsippany, NJ 07054-1200
> USA
>
> Phone  [phone]
> Mobile  [phone]
>
>



Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h03KSQ907881 for ietf-pkix-bks; Fri, 3 Jan 2003 12:28:26 -0800 (PST)
Received: from mtiwmhc11.worldnet.att.net (mtiwmhc11.worldnet.att.net [204.127.131.115]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h03KSPo07875 for <[e-mail]>; Fri, 3 Jan 2003 12:28:25 -0800 (PST)
Received: from Chokhani ([12.91.132.91]) by mtiwmhc11.worldnet.att.net (InterMail vM.5.01.05.12 201-253-122-126-112-20020820) with ESMTP id <20030103202821.PEDC9286.mtiwmhc11.worldnet.att.net@Chokhani> for <[e-mail]>; Fri, 3 Jan 2003 20:28:21 +0000
From: "Santosh Chokhani" <[e-mail]>
To: <[e-mail]>
Subject: RE: Offline Root CA with valid CRL hierachie
Date: Fri, 3 Jan 2003 15:28:53 -0500
Message-ID: <000e01c2b366$bbed4380$5b845b0c@Chokhani>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook, Build 10.0.4510
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106
In-Reply-To: <[e-mail]>
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Steve:

The question is not of Root revocation, but of establishing trust in and
checking the revocation status (if the trust is certificate based) of the
OCSP Responder itself.

In the other comments, I do not see an area where you disagree with me.  If
you do, please point that out to me.

-----Original Message-----
From: Steve Hanna [mailto:[e-mail]] 
Sent: Friday, January 03, 2003 2:43 PM
To: Santosh Chokhani
Cc: [e-mail]
Subject: Re: Offline Root CA with valid CRL hierachie


Santosh Chokhani wrote:
> I am thoroughly confused.  First, what I am proposing will work if the 
> RP is using indirect CRL.  I am making a modest assumption that an RP 
> that can process indirect CRL can also process full and complete CRL.

Right. The primary benefit of pre-issued CRLs over indirect CRLs or OCSP is
that pre-issued CRLs work with any RP that can process CRLs (any RFC 3280
compliant RP) whereas the others require support for features not required
by RFC 3280.

> In terms of OCSP, if your solution is OCSP only, I still think the 
> approach I suggest will be a good way to supply the revocation 
> information to the OCSP responders, specially if there are many of 
> them or if you want to the convenience of distributing the revocation 
> information over untrusted networks.

I don't know much about how people generally supply
revocation information to OCSP responders. Certainly,
I expect that your system would work fine. But I expect
that many OCSP responders would support indirect CRLs,
so that might also be a solution. And some people might
just use SSH. I don't know.

> How the OCSP Responder for off-line root revocation should be 
> architected is a separate topic with its own nuances.

I didn't think we were discussing how to revoke a root.
As you say, that's a separate topic. Let's leave it aside
for now, unless there's some pressing need to address it.

-Steve



Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h03JhrA05983 for ietf-pkix-bks; Fri, 3 Jan 2003 11:43:53 -0800 (PST)
Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h03Jhqo05979 for <[e-mail]>; Fri, 3 Jan 2003 11:43:52 -0800 (PST)
Received: from sydney.East.Sun.COM ([129.148.9.16]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id MAA00914; Fri, 3 Jan 2003 12:43:53 -0700 (MST)
Received: from sun.com (dhcp-ubur02-75-167 [129.148.75.167]) by sydney.East.Sun.COM (8.11.6+Sun/8.11.6/ENSMAIL,v2.2) with ESMTP id h03JhrQ06574; Fri, 3 Jan 2003 14:43:53 -0500 (EST)
Message-ID: <[e-mail]>
Date: Fri, 03 Jan 2003 14:42:41 -0500
From: Steve Hanna <[e-mail]>
X-Mailer: Mozilla 4.79 [en] (WinNT; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Santosh Chokhani <[e-mail]>
CC: [e-mail]
Subject: Re: Offline Root CA with valid CRL hierachie
References: <007501c2b35b$c685ab80$a200a8c0@Chokhani>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Santosh Chokhani wrote:
> I am thoroughly confused.  First, what I am proposing will work
> if the RP is using indirect CRL.  I am making a modest assumption
> that an RP that can process indirect CRL can also process full and
> complete CRL.

Right. The primary benefit of pre-issued CRLs over indirect
CRLs or OCSP is that pre-issued CRLs work with any RP that
can process CRLs (any RFC 3280 compliant RP) whereas the
others require support for features not required by RFC 3280.

> In terms of OCSP, if your solution is OCSP only, I still
> think the approach I suggest will be a good way to supply the
> revocation information to the OCSP responders, specially if
> there are many of them or if you want to the convenience of
> distributing the revocation information over untrusted networks.

I don't know much about how people generally supply
revocation information to OCSP responders. Certainly,
I expect that your system would work fine. But I expect
that many OCSP responders would support indirect CRLs,
so that might also be a solution. And some people might
just use SSH. I don't know.

> How the OCSP Responder for off-line root revocation should be
> architected is a separate topic with its own nuances.

I didn't think we were discussing how to revoke a root.
As you say, that's a separate topic. Let's leave it aside
for now, unless there's some pressing need to address it.

-Steve


Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h03JZ8r05283 for ietf-pkix-bks; Fri, 3 Jan 2003 11:35:08 -0800 (PST)
Received: from e31.co.us.ibm.com (e31.co.us.ibm.com [32.97.110.129]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h03JZ5o05272 for <[e-mail]>; Fri, 3 Jan 2003 11:35:05 -0800 (PST)
Received: from westrelay04.boulder.ibm.com (westrelay04.boulder.ibm.com [9.17.193.32]) by e31.co.us.ibm.com (8.12.2/8.12.2) with ESMTP id h03JZ6Zx030116; Fri, 3 Jan 2003 14:35:06 -0500
Received: from d01ml062.pok.ibm.com (d01av02.pok.ibm.com [9.56.224.216]) by westrelay04.boulder.ibm.com (8.12.3/NCO/VER6.4) with ESMTP id h03Jcmv3026706; Fri, 3 Jan 2003 12:38:48 -0700
Importance: Normal
Sensitivity: 
Subject: Re: I-D ACTION:draft-ietf-pkix-certstore-http-03.txt
To: Russ Housley <[e-mail]>
Cc: [e-mail], [e-mail], [e-mail]
X-Mailer: Lotus Notes Release 5.0.7  March 21, 2001
Message-ID: <[e-mail]>
From: "Tom Gindin" <[e-mail]>
Date: Fri, 3 Jan 2003 14:34:38 -0500
X-MIMETrack: Serialize by Router on D01ML062/01/M/IBM(Release 5.0.11 +SPRs MIAS5EXFG4, MIAS5AUFPV and DHAG4Y6R7W, MATTEST |November 8th, 2002) at 01/03/2003 02:35:05 PM
MIME-Version: 1.0
Content-type: text/plain; charset=us-ascii
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

      Russ:

      Of course I have no objection to mentioning a preference for
subjectAltName over subject for e-mail addresses.  I just thought that
anybody actually implementing something which extracts e-mail addresses
from certificates would be helped by knowing all the places which are used
in large numbers of certificates, not just the approved ones.  In the
earlier wording ("an rfc822Name attribute") I wasn't sure whether
implementors would interpret this as the rfc822mailbox directory attribute
or the rfc822Name component of GeneralName, anyway.

            Tom Gindin

Russ Housley <[e-mail]> on 01/02/2003 02:27:28 PM

To:    Tom Gindin/Watson/IBM@IBMUS
cc:    [e-mail], [e-mail],
       [e-mail]
Subject:    Re: I-D ACTION:draft-ietf-pkix-certstore-http-03.txt


Tom:

RFC 3280 says that subjectAltName extension using the rfc822Name is the way

that an email address SHOULD be included in a certificate.  I would like to

see the text reinforces this, but says that there are certificates that use

other placements.

Russ

At 07:06 PM 12/23/2002 -0500, Tom Gindin wrote:


>       How about mentioning the other two normal ways of storing the email
>address: "This is typically stored in the certificate either within the
>subject DN as a value of one of the attributes rfc822mailbox or
>emailAddress, or in the subjectAltName extension using the rfc822Name
>choice of GeneralName".   I've personally never seen anyone use any other
>way than those three.
>
>             Tom Gindin
>
>
>[e-mail] (Peter Gutmann)@mail.imc.org on 12/20/2002
>09:10:32 PM
>
>Sent by:    [e-mail]
>
>
>To:    [e-mail], [e-mail]
>cc:
>Subject:    Re: I-D ACTION:draft-ietf-pkix-certstore-http-03.txt
>
>
>
>Jeff Jacoby <[e-mail]> writes:
>
> >Is it necessary to require an exact match for all attributes,
particularly
> >for such attributes as the email and name attributes?
>
>In a word, yes.
>
> >For example, I'm looking for the cert for Bill Williams, but I don't
know
>if
> >the common name is "Bill Williams" or "Will Williams" or "B. Williams",
>etc,
> >so I might like to try a search on just "Williams"
>
>How would you specify this?  You'd need some sort of general-purpose
>pattern-
>matching mechanism and then a means of mapping it to every possible
backend
>that might be used to implement the lookup.  The draft specifies a
>universal
>interface to (conceptually) a basic key-and-value lookup engine, which
>doesn't
>extend to general pattern-matching.  If you need anything more than this
>(for
>example searching on compound attributes and similar things) you should
>really
>use LDAP.
>
> >Secondly, the entry for email attribute indicates the value as:
> >
> >  "Subject email address contained in the certificate, typically as an
> >   rfc882Name attribute
> >
> >Is it necessary the email attribute be from the certificate.  Is it a
> >reasonable or likely situation that a certificate store might use the
>email
> >address as an database index even though it's not actually in the
> >certificate?
>
>I'd never thought of it being done like that, but I can easily change the
>text
>to accomodate it.  How about:
>
>   Subject email address associated with the certificate.  This is
typically
>   stored in the certificate as an rfc882Name attribute.
>
>Peter.








Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h03JFHM02654 for ietf-pkix-bks; Fri, 3 Jan 2003 11:15:17 -0800 (PST)
Received: from mtiwmhc11.worldnet.att.net (mtiwmhc11.worldnet.att.net [204.127.131.115]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h03JFGo02647 for <[e-mail]>; Fri, 3 Jan 2003 11:15:17 -0800 (PST)
Received: from Chokhani ([12.91.132.21]) by mtiwmhc11.worldnet.att.net (InterMail vM.5.01.05.12 201-253-122-126-112-20020820) with ESMTP id <20030103191512.NGJY9286.mtiwmhc11.worldnet.att.net@Chokhani> for <[e-mail]>; Fri, 3 Jan 2003 19:15:12 +0000
From: "Santosh Chokhani" <[e-mail]>
To: <[e-mail]>
Subject: RE: Offline Root CA with valid CRL hierachie
Date: Fri, 3 Jan 2003 14:15:44 -0500
Message-ID: <007601c2b35c$8414e440$a200a8c0@Chokhani>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook, Build 10.0.4510
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106
Importance: Normal
In-Reply-To: <[e-mail]>
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id h03JFHo02649
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Mitch:

OCSP for Root raises its own issue in terms of Responder trust and responder
revocation (if a certificate based approach is used (vice trust anchor))
checking.

-----Original Message-----
From: Mitchell Arnone [mailto:[e-mail]] 
Sent: Friday, January 03, 2003 2:11 PM
To: Al Arsenault; Santosh Chokhani; [e-mail]
Subject: Re: Offline Root CA with valid CRL hierachie


All points raised on this issue have been well stated.  I do believe that 
Dave's approach could work but my concern is that I too do not see any real 
advantage to it.  The 30 day CRL might be OK if the directories are secured 
and scaled properly and the 30 1day CRLs might be OK if the stack of 
pre-generated CRLs are secured and published properly.  I just think there 
is a better solution the likes of which others on this list have already 
commented.  Personally I like the OCSP approach but even that does not 
mitigate the need for an effective CRL publishing strategy.

Thanks

Mitch

At 01:11 PM 1/3/2003, Al Arsenault wrote:
>I'm not saying Dave's approach couldn't work; it certainly could.  And 
>it wouldn't significantly reduce security if the pre-generated CRLs 
>were properly controlled through physical/procedural means.  I'm just 
>saying that I don't see any real big advantage to it.

***********************************************************
Mitchell Arnone
Managing Consultant
SchlumbergerSema
Technical Consulting Practice, Northeast Region
Network & Infrastructure Solutions

[e-mail]
www.slb.com/nws

35 Waterview Blvd.
Suite 210
Parsippany, NJ 07054-1200
USA

Phone  [phone]
Mobile  [phone]




Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h03JAqg02411 for ietf-pkix-bks; Fri, 3 Jan 2003 11:10:52 -0800 (PST)
Received: from mail.slb.com (nammta01.sugar-land.nam.slb.com [163.188.150.130]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h03JAno02403 for <[e-mail]>; Fri, 3 Jan 2003 11:10:49 -0800 (PST)
Received: from conversion-daemon.nammta01.sugar-land.nam.slb.com by nammta01.sugar-land.nam.slb.com (iPlanet Messaging Server 5.2 HotFix 1.06 (built Nov 15 2002)) id <[e-mail]> for [e-mail]; Fri, 03 Jan 2003 19:10:52 +0000 (GMT)
Received: from namems01.sugar-land.oilfield.slb.com (namems01.sugar-land.oilfield.slb.com [163.188.150.131]) by nammta01.sugar-land.nam.slb.com (iPlanet Messaging Server 5.2 HotFix 1.06 (built Nov 15 2002)) with ESMTP id <[e-mail]> for [e-mail]; Fri, 03 Jan 2003 19:10:44 +0000 (GMT)
Received: from conversion-daemon.namems01.sugar-land.oilfield.slb.com by namems01.sugar-land.oilfield.slb.com (iPlanet Messaging Server 5.1 HotFix 1.7 (built Nov  1 2002)) id <[e-mail]> for [e-mail]; Fri, 03 Jan 2003 19:10:43 +0000 (GMT)
Received: from SCHLUMBE-HJ7VF7.HOUSTON-OMH (vpnpool851.houston.sinet.slb.com [163.188.127.83]) by namems01.sugar-land.oilfield.slb.com (iPlanet Messaging Server 5.1 HotFix 1.7 (built Nov  1 2002)) with ESMTP id <[e-mail]>; Fri, 03 Jan 2003 19:09:56 +0000 (GMT)
Date: Fri, 03 Jan 2003 14:10:51 -0500
From: Mitchell Arnone <[e-mail]>
Subject: Re: Offline Root CA with valid CRL hierachie
In-reply-to: <007b01c2b353$7e342800$6801a8c0@SJOSEPH>
X-Sender: [e-mail]
To: Al Arsenault <[e-mail]>, Santosh Chokhani <[e-mail]>, [e-mail]
Message-id: <[e-mail]>
MIME-version: 1.0
X-Mailer: QUALCOMM Windows Eudora Version 5.1.1
Content-type: text/plain; charset=us-ascii; format=flowed
Content-transfer-encoding: 7BIT
References: <[e-mail]> <[e-mail]>
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

All points raised on this issue have been well stated.  I do believe that 
Dave's approach could work but my concern is that I too do not see any real 
advantage to it.  The 30 day CRL might be OK if the directories are secured 
and scaled properly and the 30 1day CRLs might be OK if the stack of 
pre-generated CRLs are secured and published properly.  I just think there 
is a better solution the likes of which others on this list have already 
commented.  Personally I like the OCSP approach but even that does not 
mitigate the need for an effective CRL publishing strategy.

Thanks

Mitch

At 01:11 PM 1/3/2003, Al Arsenault wrote:
>I'm not saying Dave's approach couldn't work; it certainly could.  And it
>wouldn't significantly reduce security if the pre-generated CRLs were
>properly controlled through physical/procedural means.  I'm just saying that
>I don't see any real big advantage to it.

***********************************************************
Mitchell Arnone
Managing Consultant
SchlumbergerSema
Technical Consulting Practice, Northeast Region
Network & Infrastructure Solutions

[e-mail]
www.slb.com/nws

35 Waterview Blvd.
Suite 210
Parsippany, NJ 07054-1200
USA

Phone  [phone]
Mobile  [phone]




Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h03J9xF02366 for ietf-pkix-bks; Fri, 3 Jan 2003 11:09:59 -0800 (PST)
Received: from mtiwmhc12.worldnet.att.net (mtiwmhc12.worldnet.att.net [204.127.131.116]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h03J9xo02362 for <[e-mail]>; Fri, 3 Jan 2003 11:09:59 -0800 (PST)
Received: from Chokhani ([12.91.132.21]) by mtiwmhc12.worldnet.att.net (InterMail vM.5.01.05.12 201-253-122-126-112-20020820) with ESMTP id <20030103190955.IVFW12483.mtiwmhc12.worldnet.att.net@Chokhani> for <[e-mail]>; Fri, 3 Jan 2003 19:09:55 +0000
From: "Santosh Chokhani" <[e-mail]>
To: <[e-mail]>
Subject: RE: Offline Root CA with valid CRL hierachie
Date: Fri, 3 Jan 2003 14:10:26 -0500
Message-ID: <007501c2b35b$c685ab80$a200a8c0@Chokhani>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook, Build 10.0.4510
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106
Importance: Normal
In-Reply-To: <[e-mail]>
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id h03J9xo02363
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Steve:

I am thoroughly confused.  First, what I am proposing will work if the RP is
using indirect CRL.  I am making a modest assumption that an RP that can
process indirect CRL can also process full and complete CRL.

In terms of OCSP, if your solution is OCSP only, I still think the approach
I suggest will be a good way to supply the revocation information to the
OCSP responders, specially if there are many of them or if you want to the
convenience of distributing the revocation information over untrusted
networks.

Again I am making a modest assumption that the OCSP Responders should get
their revocation information from the issuer.  This being off-line Root, it
is not going to be the OCSP Responder for itself.  

How the OCSP Responder for off-line root revocation should be architected is
a separate topic with its own nuances.    

-----Original Message-----
From: Steve Hanna [mailto:[e-mail]] 
Sent: Friday, January 03, 2003 1:27 PM
To: Santosh Chokhani
Cc: [e-mail]
Subject: Re: Offline Root CA with valid CRL hierachie


I agree that there are many products (CAs and RPs) that
don't support indirect CRLs yet. That is also true of
policy constraints, name constraints, and many other
features of RFC 3280. In fact, most RPs don't support revocation checking at
all! I hope these deficiencies will be remedied soon as customers start to
require RFC 3280 compliant path validation in RFPs.

So one of the main advantages of the system you propose
is that it can work with RPs that support revocation
checking by CRL, but not indirect CRLs or OCSP. I wonder
how common that will be. I'm sure there will be some
such RPs.

-Steve

P.S. I see that RFC 3280 RECOMMENDS that RPs support
indirect CRLs, but it doesn't REQUIRE them to do so.
I hope that support for indirect CRLs will be common.
Indirect CRLs have benefits beyond the ability to
issue regular CRLs without having to put the CA online
or pre-issue CRLs. They also allow several CAs to share
a single CRL, which is especially useful for CAs that
rarely revoke certificates. Of course, they do require
more work for the relying party, since they must validate
the CRL issuer's cert.

Santosh Chokhani wrote:
> 
> Steve:
> 
> While CRL issuer may be well supported by the Standards, many 
> commercial products do not handle indirect CRL well.
> 
> Separately, some RP (client side software) require the CRL to be 
> signed by the same key as the certificate with no regard for re-key or 
> separate keys for certificate and CRL signing.
> 
> -----Original Message-----
> From: Steve Hanna [mailto:[e-mail]]
> Sent: Friday, January 03, 2003 11:45 AM
> To: Mitchell Arnone
> Cc: Santosh Chokhani; [e-mail]
> Subject: Re: Offline Root CA with valid CRL hierachie
> 
> Mitchell Arnone wrote:
> > I am struggling to see how publishing 30 one-day CRLs and storing 
> > them on some off-line media is more secure than publishing a single 
> > 30 day CRL.
> 
> The difference arises if an attacker can interfere with
> the distribution of new CRLs (replacing the new ones with
> old ones, etc.). It's generally much easier to compromise
> an online web or directory server than it is to compromise
> an offline CA, so this is a very real concern.
> 
> In this case, publishing a 30 day CRL allows revoked certs
> to continue to work for up to 30 days. Publishing 30 one-day CRLs (one 
> at a time, ensuring that later ones are not published
> prematurely) means that the worst an attacker can do is block all CRLs 
> (Denial Of Service). They can't make a revoked cert work for more than 
> 1 day.
> 
> As you say, pre-issuing CRLs adds some complexity and is
> not supported by most CA software. I suggest two alternative
> solutions:
> 
> 1) Have the offline CA use a separate CRL issuer that can be
>    easily activated. The CRL issuer can issue CRLs every day.
> 
> 2) Use OCSP. Update the OCSP responder promptly when a cert
>    is revoked.
> 
> Both of these solutions are well supported by the standards and don't 
> require any special mechanisms.
> 
> Steve Hanna



Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h03ISbe01072 for ietf-pkix-bks; Fri, 3 Jan 2003 10:28:37 -0800 (PST)
Received: from nwkea-mail-1.sun.com (nwkea-mail-1.sun.com [192.18.42.13]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h03ISVo01062 for <[e-mail]>; Fri, 3 Jan 2003 10:28:31 -0800 (PST)
Received: from sydney.East.Sun.COM ([129.148.9.16]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA09187; Fri, 3 Jan 2003 10:28:27 -0800 (PST)
Received: from sun.com (dhcp-ubur02-75-167 [129.148.75.167]) by sydney.East.Sun.COM (8.11.6+Sun/8.11.6/ENSMAIL,v2.2) with ESMTP id h03ISMQ29750; Fri, 3 Jan 2003 13:28:23 -0500 (EST)
Message-ID: <[e-mail]>
Date: Fri, 03 Jan 2003 13:27:10 -0500
From: Steve Hanna <[e-mail]>
X-Mailer: Mozilla 4.79 [en] (WinNT; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Santosh Chokhani <[e-mail]>
CC: [e-mail]
Subject: Re: Offline Root CA with valid CRL hierachie
References: <005a01c2b349$6ca19af0$a200a8c0@Chokhani>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

I agree that there are many products (CAs and RPs) that
don't support indirect CRLs yet. That is also true of
policy constraints, name constraints, and many other
features of RFC 3280. In fact, most RPs don't support
revocation checking at all! I hope these deficiencies
will be remedied soon as customers start to require
RFC 3280 compliant path validation in RFPs.

So one of the main advantages of the system you propose
is that it can work with RPs that support revocation
checking by CRL, but not indirect CRLs or OCSP. I wonder
how common that will be. I'm sure there will be some
such RPs.

-Steve

P.S. I see that RFC 3280 RECOMMENDS that RPs support
indirect CRLs, but it doesn't REQUIRE them to do so.
I hope that support for indirect CRLs will be common.
Indirect CRLs have benefits beyond the ability to
issue regular CRLs without having to put the CA online
or pre-issue CRLs. They also allow several CAs to share
a single CRL, which is especially useful for CAs that
rarely revoke certificates. Of course, they do require
more work for the relying party, since they must validate
the CRL issuer's cert.

Santosh Chokhani wrote:
> 
> Steve:
> 
> While CRL issuer may be well supported by the Standards, many commercial
> products do not handle indirect CRL well.
> 
> Separately, some RP (client side software) require the CRL to be signed by
> the same key as the certificate with no regard for re-key or separate keys
> for certificate and CRL signing.
> 
> -----Original Message-----
> From: Steve Hanna [mailto:[e-mail]]
> Sent: Friday, January 03, 2003 11:45 AM
> To: Mitchell Arnone
> Cc: Santosh Chokhani; [e-mail]
> Subject: Re: Offline Root CA with valid CRL hierachie
> 
> Mitchell Arnone wrote:
> > I am struggling to see how publishing 30 one-day CRLs and storing them
> > on some off-line media is more secure than publishing a single 30 day
> > CRL.
> 
> The difference arises if an attacker can interfere with
> the distribution of new CRLs (replacing the new ones with
> old ones, etc.). It's generally much easier to compromise
> an online web or directory server than it is to compromise
> an offline CA, so this is a very real concern.
> 
> In this case, publishing a 30 day CRL allows revoked certs
> to continue to work for up to 30 days. Publishing 30 one-day CRLs (one at a
> time, ensuring that later ones are not published
> prematurely) means that the worst an attacker can do is block all CRLs
> (Denial Of Service). They can't make a revoked cert work for more than 1
> day.
> 
> As you say, pre-issuing CRLs adds some complexity and is
> not supported by most CA software. I suggest two alternative
> solutions:
> 
> 1) Have the offline CA use a separate CRL issuer that can be
>    easily activated. The CRL issuer can issue CRLs every day.
> 
> 2) Use OCSP. Update the OCSP responder promptly when a cert
>    is revoked.
> 
> Both of these solutions are well supported by the standards
> and don't require any special mechanisms.
> 
> Steve Hanna


Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h03IBv300597 for ietf-pkix-bks; Fri, 3 Jan 2003 10:11:57 -0800 (PST)
Received: from smtp.comcast.net (smtp.comcast.net [24.153.64.2]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h03IBpo00593 for <[e-mail]>; Fri, 3 Jan 2003 10:11:51 -0800 (PST)
Received: from SJOSEPH (pcp237593pcs.elictc01.md.comcast.net [68.55.160.224]) by mtaout01.icomcast.net (iPlanet Messaging Server 5.2 HotFix 1.07 (built Nov 25 2002)) with SMTP id <[e-mail]> for [e-mail]; Fri, 03 Jan 2003 13:11:48 -0500 (EST)
Date: Fri, 03 Jan 2003 13:11:09 -0500
From: Al Arsenault <[e-mail]>
Subject: Re: Offline Root CA with valid CRL hierachie
To: Mitchell Arnone <[e-mail]>, Santosh Chokhani <[e-mail]>, [e-mail]
Message-id: <007b01c2b353$7e342800$6801a8c0@SJOSEPH>
MIME-version: 1.0
X-MIMEOLE: Produced By Microsoft MimeOLE V5.50.4133.2400
X-Mailer: Microsoft Outlook Express 5.50.4133.2400
Content-type: text/plain; charset=iso-8859-1
Content-transfer-encoding: 7BIT
X-Priority: 3
X-MSMail-priority: Normal
References: <[e-mail]> <[e-mail]>
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Mitch,

     While I'm not a big fan of the scheme Dave Kemp suggested, there are a
couple of things useful about it.  Comments in-line, prefaced by my
initials, "AWA".


----- Original Message -----
From: "Mitchell Arnone" <[e-mail]>
To: "Santosh Chokhani" <[e-mail]>; <[e-mail]>
Sent: Friday, January 03, 2003 10:57 AM
Subject: RE: Offline Root CA with valid CRL hierachie


>
> Santosh,
>
> In todays world, CRL publication is very straight forward.  The idea
> presented by Dave would require additional functionality built into the CA
to:
>
> 1-publish not only the current CRL but many others in advance then
> 2-procedures must be developed on who, how, when and where those CRLs will
> be stored and managed and then
> 3-some other process/procedure must put into place to replace expired CRLs
> with the "current" one and
> 4-there must be even more procedures describing what to do if there is a
CA
> revocation... like destroying all existing CRLs and generating a list of
> new ones.
>
> The complexity comes in adding numerous new procedures which simply may
not
> be necessary.  These procedures, as described below, are manual and if we
> are to support a secure and reliable infrastructure, the human element
must
> be reduced if not eliminated and to do so, major revisions to CA system
> could be required.

AWA: (I firmly believe, based on about 15 years of working with PKIs, that)
The human element can *never* be eliminated from a secure and reliable
infrastructure.  Yes, the human element can be reduced to lower certain
types of security risks, and it can certainly be reduced in many places to
lower operational costs, but designing a system where an event such as
revocation of an intermediate CA can be done with no level of human review
at any point is sheer folly.  It leads to some really sweet denial of
service and other attacks (well, they're sweet from the attacker's view).



>
> I am struggling to see how publishing 30 one-day CRLs and storing them on
> some off-line media is more secure than publishing a single 30 day
> CRL.  The reaction to a CA revocation will be the same in both scenarios
> because the ROOT CA will have to be brought on-line to execute the
> revocation process and produce new updated CRLs before going back
off-line.
>

AWA:  The difference is the expiration date.  With one 30-day CRL, when you
have to revoke an intermediate CA on day 10, there is nothing to indicate to
any RP that it can't continue to rely on the original CRL, which says that
the intermediate CA is good.  So for 20 days, you've got RPs believing that
a certificate path is good based on checking a "current" CRL, when the cert
path is invalid.

With 30 one-day CRLs, the CRL expires at the end of each day.  When you have
to revoke an intermediate CA on day 10, you destroy all the pre-generated
CRLs (saying that the intermediate CA is good), and generate new one-day
CRLs saying that the intermediate CA is bad. Thus, there's no-way a
well-behaved RP could find and use a CRL that says the intermediate CA is
good after the date of revocation.  Your window of vulnerability is reduced
to the rest of that day.

Now, that being said, I'm still not a big fan of Dave's proposal.  First, I
don't know of an auditor anywhere in the world who would allow the root CA's
clock to be advanced to pre-generate one-day CRLs for the future, so that
approach is pretty much out - you'd have to have all the "thisUpdate" dates
being the same.  But since revocation of an intermediate CA is (I hope :-)
an extremely rare  event, it seems to me to be much more efficient to put
out a notice using OCSP or some other mechanism when the revocation occurs.

I'm not saying Dave's approach couldn't work; it certainly could.  And it
wouldn't significantly reduce security if the pre-generated CRLs were
properly controlled through physical/procedural means.  I'm just saying that
I don't see any real big advantage to it.

> Mitch
>

        Al Arsenault
        Chief Security Architect
        Diversinet Corp.





Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h03GwbR25136 for ietf-pkix-bks; Fri, 3 Jan 2003 08:58:37 -0800 (PST)
Received: from mtiwmhc12.worldnet.att.net (mtiwmhc12.worldnet.att.net [204.127.131.116]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h03Gwao25132 for <[e-mail]>; Fri, 3 Jan 2003 08:58:36 -0800 (PST)
Received: from Chokhani ([12.91.131.215]) by mtiwmhc12.worldnet.att.net (InterMail vM.5.01.05.12 201-253-122-126-112-20020820) with ESMTP id <20030103165832.FKHH12483.mtiwmhc12.worldnet.att.net@Chokhani> for <[e-mail]>; Fri, 3 Jan 2003 16:58:32 +0000
From: "Santosh Chokhani" <[e-mail]>
To: <[e-mail]>
Subject: RE: Offline Root CA with valid CRL hierachie
Date: Fri, 3 Jan 2003 11:59:04 -0500
Message-ID: <005a01c2b349$6ca19af0$a200a8c0@Chokhani>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook, Build 10.0.4510
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106
Importance: Normal
In-Reply-To: <[e-mail]>
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Steve:

While CRL issuer may be well supported by the Standards, many commercial
products do not handle indirect CRL well.

Separately, some RP (client side software) require the CRL to be signed by
the same key as the certificate with no regard for re-key or separate keys
for certificate and CRL signing.

-----Original Message-----
From: Steve Hanna [mailto:[e-mail]] 
Sent: Friday, January 03, 2003 11:45 AM
To: Mitchell Arnone
Cc: Santosh Chokhani; [e-mail]
Subject: Re: Offline Root CA with valid CRL hierachie


Mitchell Arnone wrote:
> I am struggling to see how publishing 30 one-day CRLs and storing them 
> on some off-line media is more secure than publishing a single 30 day 
> CRL.

The difference arises if an attacker can interfere with
the distribution of new CRLs (replacing the new ones with
old ones, etc.). It's generally much easier to compromise
an online web or directory server than it is to compromise
an offline CA, so this is a very real concern.

In this case, publishing a 30 day CRL allows revoked certs
to continue to work for up to 30 days. Publishing 30 one-day CRLs (one at a
time, ensuring that later ones are not published
prematurely) means that the worst an attacker can do is block all CRLs
(Denial Of Service). They can't make a revoked cert work for more than 1
day.

As you say, pre-issuing CRLs adds some complexity and is
not supported by most CA software. I suggest two alternative
solutions:

1) Have the offline CA use a separate CRL issuer that can be
   easily activated. The CRL issuer can issue CRLs every day.

2) Use OCSP. Update the OCSP responder promptly when a cert
   is revoked.

Both of these solutions are well supported by the standards
and don't require any special mechanisms.

Steve Hanna



Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h03GnMu24834 for ietf-pkix-bks; Fri, 3 Jan 2003 08:49:22 -0800 (PST)
Received: from mtiwmhc13.worldnet.att.net (mtiwmhc13.worldnet.att.net [204.127.131.117]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h03GnLo24830 for <[e-mail]>; Fri, 3 Jan 2003 08:49:21 -0800 (PST)
Received: from Chokhani ([12.91.131.215]) by mtiwmhc13.worldnet.att.net (InterMail vM.5.01.05.12 201-253-122-126-112-20020820) with ESMTP id <20030103164910.ZUHL20003.mtiwmhc13.worldnet.att.net@Chokhani> for <[e-mail]>; Fri, 3 Jan 2003 16:49:10 +0000
From: "Santosh Chokhani" <[e-mail]>
To: <[e-mail]>
Subject: RE: Offline Root CA with valid CRL hierachie
Date: Fri, 3 Jan 2003 11:49:42 -0500
Message-ID: <005101c2b348$1d7e2a20$a200a8c0@Chokhani>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook, Build 10.0.4510
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106
Importance: Normal
In-Reply-To: <[e-mail]>
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id h03GnMo24831
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Mitch:

Please see responses in-line in [].

-----Original Message-----
From: Mitchell Arnone [mailto:[e-mail]] 
Sent: Friday, January 03, 2003 10:57 AM
To: Santosh Chokhani; [e-mail]
Subject: RE: Offline Root CA with valid CRL hierachie


Santosh,

In todays world, CRL publication is very straight forward.  The idea 
presented by Dave would require additional functionality built into the CA
to:

1-publish not only the current CRL but many others in advance
[My scheme calls for publishing CRLs one at a time, not many others]

 then 2-procedures must be developed on who, how, when and where those CRLs
will 
be stored and managed
[My proposal was for those who control the private key and/or cryptographic
module and associated private key activation data will do this]

 and then
3-some other process/procedure must put into place to replace expired CRLs 
with the "current" one
[If the CA is truly off-line, you will need to carry the CRL to network
connected directory any way.  You just take the CRL in the same medium as
you would otherwise]

 and
4-there must be even more procedures describing what to do if there is a CA 
revocation... like destroying all existing CRLs and generating a list of 
new ones.
[This simple to do.  What you get in return is security and operational
convenience]

The complexity comes in adding numerous new procedures which simply may not 
be necessary.  These procedures, as described below, are manual and if we 
are to support a secure and reliable infrastructure, the human element must 
be reduced if not eliminated and to do so, major revisions to CA system 
could be required.

I am struggling to see how publishing 30 one-day CRLs and storing them on 
some off-line media is more secure than publishing a single 30 day 
CRL.  The reaction to a CA revocation will be the same in both scenarios 
because the ROOT CA will have to be brought on-line to execute the 
revocation process and produce new updated CRLs before going back off-line.
[The reason it is more secure is that if you issue a CRL whose nextUpdate is
thirty days later, then if anything happens during those thirty days, you
are vulnerable to old CRL replay attack.  The only way to mitigate that risk
is to trust both the directory and the communication pipe you as RP build to
it.  With the approach I suggest, the window of vulnerability is one day
since the CRL gets to the directory daily.  If any day, a CA needs to be
revoked, you create new CRLS.  Since no one had those pregenerated CRLs, you
are not vulnerable to their use]


Mitch

At 10:57 AM 12/31/2002, Santosh Chokhani wrote:

>Mitch:
>
>What I interpreted from Dave's e-mail is as follows:
>
>1.  For operational security and operational workload reasons, we may 
>not want to bring the off-line Root on-line to generate the CRL too 
>often.
>
>2.  For security reasons, we also want the Root CRL to have a 
>relatively current nextUpdate (vice one month or one year from now).
>
>3.  To meet these two, the root CA generates a bunch of CRLs in advance 
>with thisUpdate not of the current time, but desired times in the 
>future and nextUpdate also of various desired times in the future.
>
>4.  One can put these CRLs on portable media and control them under the 
>same physical and procedural controls that Root CA and associated 
>private key activation is controlled.
>
>5.  Most of the time, a CA will not be revoked and hence the proper 
>portable medium can be carried to the repository and CRL published.
>
>6.  If a CA is revoked, root CA will be booted up, all  the portable 
>media will be erased and root CA will generate a bunch of new CRLs 
>using step 3.
>
>This does not sound technically complex to me.  It does require some 
>procedural controls for additional items, namely portable media for the 
>future CRLs.
>
>-----Original Message-----
>From: [e-mail] 
>[mailto:[e-mail]] On Behalf Of Mitchell Arnone
>Sent: Monday, December 30, 2002 8:13 PM
>To: David P. Kemp; [e-mail]
>Subject: Re: Offline Root CA with valid CRL hierachie
>
>
>
>Dave,
>
>This sounds like a very complex technical solution that circumvents 
>proper procedures designed to maintain a significantly high level of 
>assurance.  The Root CA is the root of trust and therefore must live up 
>to the highest level of assurance attested to by a particular PKI.
>
>CRLs must be generated on the date and at the time they become 
>effective.  Predicting contents of a CRL and generating them in advance 
>leaves much room and opportunity to render a PKI untrustworthy.
>
>A CRL can be generated by an off-line Root CA where the next update can 
>be one day, one month or even one year from the date contained in 
>"thisUpdate".  Depending on this setting, and assuming that no 
>subordinate CA certificates have been revoked prior to the normally 
>scheduled update period, the off-line Root CA can be brought on-line 
>allowing it to generate and publish a fresh CRL.  In the event that a 
>subordinate CA certificate is revoked, obviously the Root CA must 
>brought on-line to do so and immediately following the revocation, the 
>Root CA can generate and publish an updated CRL.  This is the proper 
>way to handle an Off-line Root CA.
>
>The burden of obtaining a current CRL is on the Relying Party where it 
>must periodically refresh its CRL regardless of whether the 
>"nextUpdate" has been reached or not.  A Relying Party can flush its 
>cache at prescribed intervals and then retrieve a new (updated) CRL as 
>required.
>
>Mitch
>
>At 11:01 AM 12/30/2002, David P. Kemp wrote:
>
> >Because revocation of a signing CA should be very rare event, the 
> >offline root can take advantage of a "long pipeline" to minimize the 
> >human effort required to transport disks of CRLs to an online 
> >repository.  The root could pre-generate, say, one week's worth of 
> >empty daily CRLs (where nextUpdate = thisUpdate + 1 day) and put the 
> >7 CRLs on media.  The repository would then be responsible for doling 
> >out the correct CRL each day and not publishing any CRL for which 
> >thisUpdate is in the future.
> >
> >In the event of a CA compromise, the pipeline would need to be 
> >flushed
> >- future CRLs in the repository would be destroyed and the root CA
> >would generate a new batch of CRLs on media.
> >
> >This assumes that compromise of the online repository (allowing 
> >access to CRLs up to 7 days in the future) is a much less serious 
> >event than compromise of the offline root CA.  I believe that 
> >assumption is valid and supportable.
> >
> >Dave
> >
> >
> >
> >
> >Al Arsenault wrote:
> > >
> > > Okay, I'm a little confused here.  This problem isn't really all 
> > > that hard to solve. My comments/questions are in-line, prefaced by 
> > > my initials,
> > "AWA".
> > >
> > > ----- Original Message -----
> > > From: "Haaino Beljaars" <[e-mail]>
> > > To: "Mark Scherling" <[e-mail]>
> > > Cc: <[e-mail]>
> > > Sent: Monday, December 23, 2002 6:36 AM
> > > Subject: Re: Offline Root CA with valid CRL hierachie
> > >
> > > >
> > > > > You can still publish a CRL for an off-line CA.  You will need 
> > > > > to
> > > > establish
> > > > > a fairly long expiry time for the CRL if you do not plan to 
> > > > > bring
> > the CA
> > > > > on-line often.  In many cases the Root CA is off-line and only 
> > > > > used to
> > > > issue
> > > > > new intermediary CAs or revoke intermediary CAs.  You will 
> > > > > need to
> > > > establish
> > > > > a very good procedure for startup and shutdown of the root CA 
> > > > > (two
> > > person
> > > > > control, locked in a safe, two person combination on the safe,
> > > documenting
> > > > > each time the CA is removed, etc. )  The reason for 
> > > > > documenting the
> > > > process
> > > > > is for audit purposes.
> > > > >
> > > > > You will also need to document in your CP that the CA is 
> > > > > off-line and
> > > that
> > > > > the onus is on the relying party to verify that an 
> > > > > intermediary CA is
> > > > still
> > > > > valid.
> > > >
> > >
> > > AWA:  Let's first clarify terms.  What, exactly, do you mean by 
> > > "off-line CA"?  To me, that term means that the CA is not 
> > > connected to a larger network (specifically, it's not connected to 
> > > the Internet or larger telecom network through which it can be 
> > > accessed).  It's still running, locked in its secure facility 
> > > somewhere.  That is, start-up/shut-down is not an
> > issue;
> > > it's already running.  Is that what you mean, or is there 
> > > something else?
> > >
> > > > I agree that you still publish a valid CRL for an offline Root 
> > > > CA. The problem is the following,
> > > > example: I issue an CRL with the Root CA with a validity of for 
> > > > example a month, and after issuing the CRL I take it offline. 
> > > > During that month, for example after
> > > two
> > > > weeks, one of the
> > > > intermediate CA's is compromised and I have to revoke that CA. 
> > > > According to the specs I can only issue a CRL which has a 
> > > > validity time
> > > that
> > > > starts after
> > > > current one.
> > >
> > > AWA:  I'm not sure you're interpreting RFC 3280 correctly. 
> > > Paragraph 5.1.2.5 starts:
> > >
> > >   5.1.2.5  Next Update
> > >
> > >    This field indicates the date by which the next CRL will be issued.
> > >    The next CRL could be issued before the indicated date, but it will
> > >    not be issued any later than the indicated date.  CRL issuers
SHOULD
> > >    issue CRLs with a nextUpdate time equal to or later than all
previous
> > >    CRLs.  nextUpdate may be encoded as UTCTime or GeneralizedTime.
> > >
> > > That is, you can only issue a CRL whose "thisUpdate" time is later 
> > > than the previous one, and whose nextUpdate time is equal to or 
> > > later than those on previous CRLs (although that latter part is 
> > > not required).  There's no reason why you have to wait until the 
> > > current CRL expires to issue the new one.
> > >
> > > >This means in practise that I have a valid intermediate CA for 
> > > >over two weeks,  but in reality that intermediate CA is revoked. 
> > > >How can I let everybody
> > > know
> > > > during that
> > > > two week period that the intermediate CA is compromised, taking 
> > > > in account:"Conforming applications are NOT REQUIRED to support 
> > > > processing of delta CRLs,
> > > indirect
> > > > CRLs, or CRLs
> > > > with a scope other than all certificates issued by one CA"?
> > > >
> > >
> > > AWA:  Okay, here's how I've solved this problem in the past.  The 
> > > root CA, while off-line, is running in its secure facility.  When 
> > > it is necessary to revoke an intermediate CA, the root CA is 
> > > accessed to create a new CRL. This CRL is dumped to some medium, 
> > > either burned onto a CD or put onto a floppy.  This medium is then 
> > > hand-carried (the term we used to use was
> > "sent
> > > via sneaker-net") to a server that is on the network.  It can be 
> > > either
> > made
> > > available as a CRL from, e.g., an LDAP repository; or it can be 
> > > provided to an OCSP responder.
> > >
> > > The rest is up to your revocation policy.  If you rely only on 
> > > CRLs,
> > and you
> > > allow users to cache CRLs until the end of their validity period 
> > > (e.g., until their "nextUpdate" time), then yes, you have in your 
> > > scenario a two-week window of vulnerability where users think an 
> > > intermediate CA is good but it's really not.  That's a risk you 
> > > take by relying only on static CRLs with that long a validity 
> > > period. (Of course, one would hope that revocation of an 
> > > intermediate CA would be an extremely rare event, so the overall 
> > > system risk/cost tradeoff may be acceptable, but...)
> > >
> > > On the other hand, you can use an OCSP-based system, where users 
> > > query the responder and will discover that the intermediate CA has 
> > > been revoked the first time they query its status.  OR you can use 
> > > CRLs with a shorter life cycle.  Depending on what you're willing 
> > > to pay in "human capital" costs, there's no reason you can't have 
> > > the off-line CA issue a new CRL -
> > generally
> > > identical to the previous one - as often as you want; e.g., every 
> > > day,
> > every
> > > 4 hours, whatever.  It just costs you to have the human move the 
> > > medium - floppy, CD - from the off-line CA to the 
> > > network-connected
> > repository.  It's
> > > not that hard.
> > >
> > > > Best regards,
> > > > Haaino
> > > >
> > >
> > > Hope this helps.
> > >
> > >                     Al Arsenault
> > >                     Chief Security Architect
> > >                     Diversinet Corp.
>
>***********************************************************
>Mitchell Arnone
>Managing Consultant
>SchlumbergerSema
>Technical Consulting Practice, Northeast Region
>Network & Infrastructure Solutions
>
>[e-mail]
>www.slb.com/nws
>
>35 Waterview Blvd.
>Suite 210
>Parsippany, NJ 07054-1200
>USA
>
>Phone  [phone]
>Mobile  [phone]

***********************************************************
Mitchell Arnone
Managing Consultant
SchlumbergerSema
Technical Consulting Practice, Northeast Region
Network & Infrastructure Solutions

[e-mail]
www.slb.com/nws

35 Waterview Blvd.
Suite 210
Parsippany, NJ 07054-1200
USA

Phone  [phone]
Mobile  [phone]




Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h03GjqE24636 for ietf-pkix-bks; Fri, 3 Jan 2003 08:45:52 -0800 (PST)
Received: from pheriche.sun.com (pheriche.sun.com [192.18.98.34]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h03Gjoo24632 for <[e-mail]>; Fri, 3 Jan 2003 08:45:50 -0800 (PST)
Received: from sydney.East.Sun.COM ([129.148.9.16]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA22415; Fri, 3 Jan 2003 09:45:51 -0700 (MST)
Received: from sun.com (dhcp-ubur02-75-167 [129.148.75.167]) by sydney.East.Sun.COM (8.11.6+Sun/8.11.6/ENSMAIL,v2.2) with ESMTP id h03GjpQ20606; Fri, 3 Jan 2003 11:45:51 -0500 (EST)
Message-ID: <[e-mail]>
Date: Fri, 03 Jan 2003 11:44:39 -0500
From: Steve Hanna <[e-mail]>
X-Mailer: Mozilla 4.79 [en] (WinNT; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Mitchell Arnone <[e-mail]>
CC: Santosh Chokhani <[e-mail]>, [e-mail]
Subject: Re: Offline Root CA with valid CRL hierachie
References: <[e-mail]> <[e-mail]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Mitchell Arnone wrote:
> I am struggling to see how publishing 30 one-day CRLs and
> storing them on some off-line media is more secure than
> publishing a single 30 day CRL.

The difference arises if an attacker can interfere with
the distribution of new CRLs (replacing the new ones with
old ones, etc.). It's generally much easier to compromise
an online web or directory server than it is to compromise
an offline CA, so this is a very real concern.

In this case, publishing a 30 day CRL allows revoked certs
to continue to work for up to 30 days. Publishing 30 one-day
CRLs (one at a time, ensuring that later ones are not published
prematurely) means that the worst an attacker can do is block
all CRLs (Denial Of Service). They can't make a revoked cert
work for more than 1 day.

As you say, pre-issuing CRLs adds some complexity and is
not supported by most CA software. I suggest two alternative
solutions:

1) Have the offline CA use a separate CRL issuer that can be
   easily activated. The CRL issuer can issue CRLs every day.

2) Use OCSP. Update the OCSP responder promptly when a cert
   is revoked.

Both of these solutions are well supported by the standards
and don't require any special mechanisms.

Steve Hanna


Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h03FvPW23035 for ietf-pkix-bks; Fri, 3 Jan 2003 07:57:25 -0800 (PST)
Received: from mail.slb.com (nammta01.sugar-land.nam.slb.com [163.188.150.130]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h03FvMo23030 for <[e-mail]>; Fri, 3 Jan 2003 07:57:24 -0800 (PST)
Received: from conversion-daemon.nammta01.sugar-land.nam.slb.com by nammta01.sugar-land.nam.slb.com (iPlanet Messaging Server 5.2 HotFix 1.06 (built Nov 15 2002)) id <[e-mail]> for [e-mail]; Fri, 03 Jan 2003 15:57:19 +0000 (GMT)
Received: from namems01.sugar-land.oilfield.slb.com (namems01.sugar-land.oilfield.slb.com [163.188.150.131]) by nammta01.sugar-land.nam.slb.com (iPlanet Messaging Server 5.2 HotFix 1.06 (built Nov 15 2002)) with ESMTP id <[e-mail]> for [e-mail]; Fri, 03 Jan 2003 15:57:19 +0000 (GMT)
Received: from conversion-daemon.namems01.sugar-land.oilfield.slb.com by namems01.sugar-land.oilfield.slb.com (iPlanet Messaging Server 5.1 HotFix 1.7 (built Nov  1 2002)) id <[e-mail]> for [e-mail]; Fri, 03 Jan 2003 15:57:19 +0000 (GMT)
Received: from SCHLUMBE-HJ7VF7.HOUSTON-OMH (vpnpool851.houston.sinet.slb.com [163.188.127.83]) by namems01.sugar-land.oilfield.slb.com (iPlanet Messaging Server 5.1 HotFix 1.7 (built Nov  1 2002)) with ESMTP id <[e-mail]>; Fri, 03 Jan 2003 15:56:36 +0000 (GMT)
Date: Fri, 03 Jan 2003 10:57:28 -0500
From: Mitchell Arnone <[e-mail]>
Subject: RE: Offline Root CA with valid CRL hierachie
In-reply-to: <001c01c2b0e5$42b60660$a200a8c0@Chokhani>
X-Sender: [e-mail]
To: Santosh Chokhani <[e-mail]>, [e-mail]
Message-id: <[e-mail]>
MIME-version: 1.0
X-Mailer: QUALCOMM Windows Eudora Version 5.1.1
Content-type: text/plain; charset=us-ascii; format=flowed
Content-transfer-encoding: 7BIT
References: <[e-mail]>
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Santosh,

In todays world, CRL publication is very straight forward.  The idea 
presented by Dave would require additional functionality built into the CA to:

1-publish not only the current CRL but many others in advance then
2-procedures must be developed on who, how, when and where those CRLs will 
be stored and managed and then
3-some other process/procedure must put into place to replace expired CRLs 
with the "current" one and
4-there must be even more procedures describing what to do if there is a CA 
revocation... like destroying all existing CRLs and generating a list of 
new ones.

The complexity comes in adding numerous new procedures which simply may not 
be necessary.  These procedures, as described below, are manual and if we 
are to support a secure and reliable infrastructure, the human element must 
be reduced if not eliminated and to do so, major revisions to CA system 
could be required.

I am struggling to see how publishing 30 one-day CRLs and storing them on 
some off-line media is more secure than publishing a single 30 day 
CRL.  The reaction to a CA revocation will be the same in both scenarios 
because the ROOT CA will have to be brought on-line to execute the 
revocation process and produce new updated CRLs before going back off-line.

Mitch

At 10:57 AM 12/31/2002, Santosh Chokhani wrote:

>Mitch:
>
>What I interpreted from Dave's e-mail is as follows:
>
>1.  For operational security and operational workload reasons, we may not
>want to bring the off-line Root on-line to generate the CRL too often.
>
>2.  For security reasons, we also want the Root CRL to have a relatively
>current nextUpdate (vice one month or one year from now).
>
>3.  To meet these two, the root CA generates a bunch of CRLs in advance with
>thisUpdate not of the current time, but desired times in the future and
>nextUpdate also of various desired times in the future.
>
>4.  One can put these CRLs on portable media and control them under the same
>physical and procedural controls that Root CA and associated private key
>activation is controlled.
>
>5.  Most of the time, a CA will not be revoked and hence the proper portable
>medium can be carried to the repository and CRL published.
>
>6.  If a CA is revoked, root CA will be booted up, all  the portable media
>will be erased and root CA will generate a bunch of new CRLs using step 3.
>
>This does not sound technically complex to me.  It does require some
>procedural controls for additional items, namely portable media for the
>future CRLs.
>
>-----Original Message-----
>From: [e-mail] [mailto:[e-mail]] On
>Behalf Of Mitchell Arnone
>Sent: Monday, December 30, 2002 8:13 PM
>To: David P. Kemp; [e-mail]
>Subject: Re: Offline Root CA with valid CRL hierachie
>
>
>
>Dave,
>
>This sounds like a very complex technical solution that circumvents proper
>procedures designed to maintain a significantly high level of
>assurance.  The Root CA is the root of trust and therefore must live up to
>the highest level of assurance attested to by a particular PKI.
>
>CRLs must be generated on the date and at the time they become
>effective.  Predicting contents of a CRL and generating them in advance
>leaves much room and opportunity to render a PKI untrustworthy.
>
>A CRL can be generated by an off-line Root CA where the next update can be
>one day, one month or even one year from the date contained in
>"thisUpdate".  Depending on this setting, and assuming that no subordinate
>CA certificates have been revoked prior to the normally scheduled update
>period, the off-line Root CA can be brought on-line allowing it to generate
>and publish a fresh CRL.  In the event that a subordinate CA certificate is
>revoked, obviously the Root CA must brought on-line to do so and
>immediately following the revocation, the Root CA can generate and publish
>an updated CRL.  This is the proper way to handle an Off-line Root CA.
>
>The burden of obtaining a current CRL is on the Relying Party where it must
>periodically refresh its CRL regardless of whether the "nextUpdate" has
>been reached or not.  A Relying Party can flush its cache at prescribed
>intervals and then retrieve a new (updated) CRL as required.
>
>Mitch
>
>At 11:01 AM 12/30/2002, David P. Kemp wrote:
>
> >Because revocation of a signing CA should be very rare event, the
> >offline root can take advantage of a "long pipeline" to minimize the
> >human effort required to transport disks of CRLs to an online
> >repository.  The root could pre-generate, say, one week's worth of
> >empty daily CRLs (where nextUpdate = thisUpdate + 1 day) and put the 7
> >CRLs on media.  The repository would then be responsible for doling out
> >the correct CRL each day and not publishing any CRL for which
> >thisUpdate is in the future.
> >
> >In the event of a CA compromise, the pipeline would need to be flushed
> >- future CRLs in the repository would be destroyed and the root CA
> >would generate a new batch of CRLs on media.
> >
> >This assumes that compromise of the online repository (allowing access
> >to CRLs up to 7 days in the future) is a much less serious event than
> >compromise of the offline root CA.  I believe that assumption is valid
> >and supportable.
> >
> >Dave
> >
> >
> >
> >
> >Al Arsenault wrote:
> > >
> > > Okay, I'm a little confused here.  This problem isn't really all
> > > that hard to solve. My comments/questions are in-line, prefaced by
> > > my initials,
> > "AWA".
> > >
> > > ----- Original Message -----
> > > From: "Haaino Beljaars" <[e-mail]>
> > > To: "Mark Scherling" <[e-mail]>
> > > Cc: <[e-mail]>
> > > Sent: Monday, December 23, 2002 6:36 AM
> > > Subject: Re: Offline Root CA with valid CRL hierachie
> > >
> > > >
> > > > > You can still publish a CRL for an off-line CA.  You will need
> > > > > to
> > > > establish
> > > > > a fairly long expiry time for the CRL if you do not plan to
> > > > > bring
> > the CA
> > > > > on-line often.  In many cases the Root CA is off-line and only
> > > > > used to
> > > > issue
> > > > > new intermediary CAs or revoke intermediary CAs.  You will need
> > > > > to
> > > > establish
> > > > > a very good procedure for startup and shutdown of the root CA
> > > > > (two
> > > person
> > > > > control, locked in a safe, two person combination on the safe,
> > > documenting
> > > > > each time the CA is removed, etc. )  The reason for documenting
> > > > > the
> > > > process
> > > > > is for audit purposes.
> > > > >
> > > > > You will also need to document in your CP that the CA is
> > > > > off-line and
> > > that
> > > > > the onus is on the relying party to verify that an intermediary
> > > > > CA is
> > > > still
> > > > > valid.
> > > >
> > >
> > > AWA:  Let's first clarify terms.  What, exactly, do you mean by
> > > "off-line CA"?  To me, that term means that the CA is not connected
> > > to a larger network (specifically, it's not connected to the
> > > Internet or larger telecom network through which it can be
> > > accessed).  It's still running, locked in its secure facility
> > > somewhere.  That is, start-up/shut-down is not an
> > issue;
> > > it's already running.  Is that what you mean, or is there something
> > > else?
> > >
> > > > I agree that you still publish a valid CRL for an offline Root CA.
> > > > The problem is the following,
> > > > example: I issue an CRL with the Root CA with a validity of for
> > > > example a month, and after issuing the CRL I take it offline.
> > > > During that month, for example after
> > > two
> > > > weeks, one of the
> > > > intermediate CA's is compromised and I have to revoke that CA.
> > > > According to the specs I can only issue a CRL which has a validity
> > > > time
> > > that
> > > > starts after
> > > > current one.
> > >
> > > AWA:  I'm not sure you're interpreting RFC 3280 correctly.
> > > Paragraph 5.1.2.5 starts:
> > >
> > >   5.1.2.5  Next Update
> > >
> > >    This field indicates the date by which the next CRL will be issued.
> > >    The next CRL could be issued before the indicated date, but it will
> > >    not be issued any later than the indicated date.  CRL issuers SHOULD
> > >    issue CRLs with a nextUpdate time equal to or later than all previous
> > >    CRLs.  nextUpdate may be encoded as UTCTime or GeneralizedTime.
> > >
> > > That is, you can only issue a CRL whose "thisUpdate" time is later
> > > than the previous one, and whose nextUpdate time is equal to or
> > > later than those on previous CRLs (although that latter part is not
> > > required).  There's no reason why you have to wait until the current
> > > CRL expires to issue the new one.
> > >
> > > >This means in practise that I have a valid intermediate CA for
> > > >over two weeks,  but in reality that intermediate CA is revoked.
> > > >How can I let everybody
> > > know
> > > > during that
> > > > two week period that the intermediate CA is compromised, taking in
> > > > account:"Conforming applications are NOT REQUIRED to support
> > > > processing of delta CRLs,
> > > indirect
> > > > CRLs, or CRLs
> > > > with a scope other than all certificates issued by one CA"?
> > > >
> > >
> > > AWA:  Okay, here's how I've solved this problem in the past.  The
> > > root CA, while off-line, is running in its secure facility.  When it
> > > is necessary to revoke an intermediate CA, the root CA is accessed
> > > to create a new CRL. This CRL is dumped to some medium, either
> > > burned onto a CD or put onto a floppy.  This medium is then
> > > hand-carried (the term we used to use was
> > "sent
> > > via sneaker-net") to a server that is on the network.  It can be
> > > either
> > made
> > > available as a CRL from, e.g., an LDAP repository; or it can be
> > > provided to an OCSP responder.
> > >
> > > The rest is up to your revocation policy.  If you rely only on CRLs,
> > and you
> > > allow users to cache CRLs until the end of their validity period
> > > (e.g., until their "nextUpdate" time), then yes, you have in your
> > > scenario a two-week window of vulnerability where users think an
> > > intermediate CA is good but it's really not.  That's a risk you take
> > > by relying only on static CRLs with that long a validity period. (Of
> > > course, one would hope that revocation of an intermediate CA would
> > > be an extremely rare event, so the overall system risk/cost tradeoff
> > > may be acceptable, but...)
> > >
> > > On the other hand, you can use an OCSP-based system, where users
> > > query the responder and will discover that the intermediate CA has
> > > been revoked the first time they query its status.  OR you can use
> > > CRLs with a shorter life cycle.  Depending on what you're willing to
> > > pay in "human capital" costs, there's no reason you can't have the
> > > off-line CA issue a new CRL -
> > generally
> > > identical to the previous one - as often as you want; e.g., every
> > > day,
> > every
> > > 4 hours, whatever.  It just costs you to have the human move the
> > > medium - floppy, CD - from the off-line CA to the network-connected
> > repository.  It's
> > > not that hard.
> > >
> > > > Best regards,
> > > > Haaino
> > > >
> > >
> > > Hope this helps.
> > >
> > >                     Al Arsenault
> > >                     Chief Security Architect
> > >                     Diversinet Corp.
>
>***********************************************************
>Mitchell Arnone
>Managing Consultant
>SchlumbergerSema
>Technical Consulting Practice, Northeast Region
>Network & Infrastructure Solutions
>
>[e-mail]
>www.slb.com/nws
>
>35 Waterview Blvd.
>Suite 210
>Parsippany, NJ 07054-1200
>USA
>
>Phone  [phone]
>Mobile  [phone]

***********************************************************
Mitchell Arnone
Managing Consultant
SchlumbergerSema
Technical Consulting Practice, Northeast Region
Network & Infrastructure Solutions

[e-mail]
www.slb.com/nws

35 Waterview Blvd.
Suite 210
Parsippany, NJ 07054-1200
USA

Phone  [phone]
Mobile  [phone]




Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h03FbDY21365 for ietf-pkix-bks; Fri, 3 Jan 2003 07:37:13 -0800 (PST)
Received: from mail.slb.com (nammta01.sugar-land.nam.slb.com [163.188.150.130]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h03Fb9o21294 for <[e-mail]>; Fri, 3 Jan 2003 07:37:09 -0800 (PST)
Received: from conversion-daemon.nammta01.sugar-land.nam.slb.com by nammta01.sugar-land.nam.slb.com (iPlanet Messaging Server 5.2 HotFix 1.06 (built Nov 15 2002)) id <[e-mail]> for [e-mail]; Fri, 03 Jan 2003 15:37:04 +0000 (GMT)
Received: from namems01.sugar-land.oilfield.slb.com (namems01.sugar-land.oilfield.slb.com [163.188.150.131]) by nammta01.sugar-land.nam.slb.com (iPlanet Messaging Server 5.2 HotFix 1.06 (built Nov 15 2002)) with ESMTP id <[e-mail]> for [e-mail]; Fri, 03 Jan 2003 15:36:49 +0000 (GMT)
Received: from conversion-daemon.namems01.sugar-land.oilfield.slb.com by namems01.sugar-land.oilfield.slb.com (iPlanet Messaging Server 5.1 HotFix 1.7 (built Nov  1 2002)) id <[e-mail]> for [e-mail]; Fri, 03 Jan 2003 15:36:48 +0000 (GMT)
Received: from SCHLUMBE-HJ7VF7.HOUSTON-OMH (vpnpool851.houston.sinet.slb.com [163.188.127.83]) by namems01.sugar-land.oilfield.slb.com (iPlanet Messaging Server 5.1 HotFix 1.7 (built Nov  1 2002)) with ESMTP id <[e-mail]>; Fri, 03 Jan 2003 15:33:57 +0000 (GMT)
Date: Fri, 03 Jan 2003 10:34:52 -0500
From: Mitchell Arnone <[e-mail]>
Subject: RE: Offline Root CA with valid CRL hierachie
In-reply-to: <[e-mail]>
X-Sender: [e-mail]
To: Ambarish Malpani <[e-mail]>, "David P. Kemp" <[e-mail]>, [e-mail]
Message-id: <[e-mail]>
MIME-version: 1.0
X-Mailer: QUALCOMM Windows Eudora Version 5.1.1
Content-type: text/plain; charset=us-ascii; format=flowed
Content-transfer-encoding: 7BIT
References: <[e-mail]>
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Ambarish,

I completely agree with you.  This is an ongoing issue when designing and 
building secure and reliable PKI implementations.

How often a client or service provider (both as relying parties) retrieves 
an updated CRL is dependant on the intended use of the PKI.  It all comes 
down to risk mitigation and associated costs.  If you are protecting highly 
sensitive information then maybe you need to support frequent checking of 
CRLs and if this is the case then maybe you need to deploy a LDAP farm 
fronted by some sort of HA device or maybe you deploy a smaller scale LDAP 
deployment and push certificate status checking to an OCSP responder which 
too may be integrated into an HA solution.  However, this can become very 
costly and if the cost outweighs the value of the information being 
protected, then there needs to be a balancing act between cost and risk.

Relying parties, especially service providers, need to be configurable 
allowing an administrator to determine the frequency in which an updated 
CRL is fetched.  There may be a situation where different relying parties 
have different intervals, based on risk.  In addition, administrators must 
be able to issue a command to the service front end (that is responsible 
for CRL checking) telling it to go out and fetch a new CRL 
immediately.  This is important for these cases when there is an emergency 
revocation early in the validity period of a CRL.

In most CP/CPS documents, reference is made to emergency certificate 
revocation and notification of relying parties in such cases.  However, if 
the relying party either cannot or does not effect an immediate retrieval 
of an update CRL, then emergency revocation procedures are useless.

Mitch

At 04:52 PM 12/31/2002, Ambarish Malpani wrote:

>Hi Mitchell,
>     As a CA, you can tell the RP (relying party) that it is
>responsible for fetching the latest CRL. If you then give it
>no way of knowing when to get a new CRL, any serious security
>client would keep checking for a new CRL *every* time it needed
>to validate a certificate/certification path.
>
>As a root CA, it is very unlikely that your directory could handle
>the load you would get from every client trying to get your latest
>CRL for every certificate that chains up to you (*distribution* is
>the real scalability problem with CRLs - as opposed to OCSP - not
>generation).
>
>Regards,
>Ambarish
>
>---------------------------------------------------------------------
>Ambarish Malpani                                         650.759.9045
>Malpani Consulting Services                      [e-mail]
>http://www.malpani.biz
>
>
>
> > -----Original Message-----
> > From: [e-mail]
> > [mailto:[e-mail]]On Behalf Of Mitchell Arnone
> > Sent: Monday, December 30, 2002 5:13 PM
> > To: David P. Kemp; [e-mail]
> > Subject: Re: Offline Root CA with valid CRL hierachie
> >
> >
> >
> > Dave,
> >
> > This sounds like a very complex technical solution that
> > circumvents proper
> > procedures designed to maintain a significantly high level of
> > assurance.  The Root CA is the root of trust and therefore must
> > live up to
> > the highest level of assurance attested to by a particular PKI.
> >
> > CRLs must be generated on the date and at the time they become
> > effective.  Predicting contents of a CRL and generating them in advance
> > leaves much room and opportunity to render a PKI untrustworthy.
> >
> > A CRL can be generated by an off-line Root CA where the next
> > update can be
> > one day, one month or even one year from the date contained in
> > "thisUpdate".  Depending on this setting, and assuming that no
> > subordinate
> > CA certificates have been revoked prior to the normally scheduled update
> > period, the off-line Root CA can be brought on-line allowing it
> > to generate
> > and publish a fresh CRL.  In the event that a subordinate CA
> > certificate is
> > revoked, obviously the Root CA must brought on-line to do so and
> > immediately following the revocation, the Root CA can generate
> > and publish
> > an updated CRL.  This is the proper way to handle an Off-line Root CA.
> >
> > The burden of obtaining a current CRL is on the Relying Party
> > where it must
> > periodically refresh its CRL regardless of whether the "nextUpdate" has
> > been reached or not.  A Relying Party can flush its cache at prescribed
> > intervals and then retrieve a new (updated) CRL as required.
> >
> > Mitch
> >
> > At 11:01 AM 12/30/2002, David P. Kemp wrote:
> >
> > >Because revocation of a signing CA should be very rare event, the
> > >offline root can take advantage of a "long pipeline" to minimize
> > >the human effort required to transport disks of CRLs to an online
> > >repository.  The root could pre-generate, say, one week's worth of
> > >empty daily CRLs (where nextUpdate = thisUpdate + 1 day) and put
> > >the 7 CRLs on media.  The repository would then be responsible
> > >for doling out the correct CRL each day and not publishing any
> > >CRL for which thisUpdate is in the future.
> > >
> > >In the event of a CA compromise, the pipeline would need to be
> > >flushed - future CRLs in the repository would be destroyed and
> > >the root CA would generate a new batch of CRLs on media.
> > >
> > >This assumes that compromise of the online repository (allowing
> > >access to CRLs up to 7 days in the future) is a much less serious
> > >event than compromise of the offline root CA.  I believe that
> > >assumption is valid and supportable.
> > >
> > >Dave
> > >
> > >
> > >
> > >
> > >Al Arsenault wrote:
> > > >
> > > > Okay, I'm a little confused here.  This problem isn't really
> > all that hard
> > > > to solve. My comments/questions are in-line, prefaced by my initials,
> > > "AWA".
> > > >
> > > > ----- Original Message -----
> > > > From: "Haaino Beljaars" <[e-mail]>
> > > > To: "Mark Scherling" <[e-mail]>
> > > > Cc: <[e-mail]>
> > > > Sent: Monday, December 23, 2002 6:36 AM
> > > > Subject: Re: Offline Root CA with valid CRL hierachie
> > > >
> > > > >
> > > > > > You can still publish a CRL for an off-line CA.  You will need to
> > > > > establish
> > > > > > a fairly long expiry time for the CRL if you do not plan to bring
> > > the CA
> > > > > > on-line often.  In many cases the Root CA is off-line and
> > only used to
> > > > > issue
> > > > > > new intermediary CAs or revoke intermediary CAs.  You will need to
> > > > > establish
> > > > > > a very good procedure for startup and shutdown of the root CA (two
> > > > person
> > > > > > control, locked in a safe, two person combination on the safe,
> > > > documenting
> > > > > > each time the CA is removed, etc. )  The reason for
> > documenting the
> > > > > process
> > > > > > is for audit purposes.
> > > > > >
> > > > > > You will also need to document in your CP that the CA is
> > off-line and
> > > > that
> > > > > > the onus is on the relying party to verify that an
> > intermediary CA is
> > > > > still
> > > > > > valid.
> > > > >
> > > >
> > > > AWA:  Let's first clarify terms.  What, exactly, do you mean
> > by "off-line
> > > > CA"?  To me, that term means that the CA is not connected to a larger
> > > > network (specifically, it's not connected to the Internet or
> > larger telecom
> > > > network through which it can be accessed).  It's still
> > running, locked in
> > > > its secure facility somewhere.  That is, start-up/shut-down is not an
> > > issue;
> > > > it's already running.  Is that what you mean, or is there
> > something else?
> > > >
> > > > > I agree that you still publish a valid CRL for an offline
> > Root CA. The
> > > > > problem is the following,
> > > > > example: I issue an CRL with the Root CA with a validity of
> > for example a
> > > > > month, and after
> > > > > issuing the CRL I take it offline. During that month, for
> > example after
> > > > two
> > > > > weeks, one of the
> > > > > intermediate CA's is compromised and I have to revoke that CA.
> > > > > According to the specs I can only issue a CRL which has a
> > validity time
> > > > that
> > > > > starts after
> > > > > current one.
> > > >
> > > > AWA:  I'm not sure you're interpreting RFC 3280 correctly.  Paragraph
> > > > 5.1.2.5 starts:
> > > >
> > > >   5.1.2.5  Next Update
> > > >
> > > >    This field indicates the date by which the next CRL will be issued.
> > > >    The next CRL could be issued before the indicated date, but it will
> > > >    not be issued any later than the indicated date.  CRL
> > issuers SHOULD
> > > >    issue CRLs with a nextUpdate time equal to or later than
> > all previous
> > > >    CRLs.  nextUpdate may be encoded as UTCTime or GeneralizedTime.
> > > >
> > > > That is, you can only issue a CRL whose "thisUpdate" time is
> > later than the
> > > > previous one, and whose nextUpdate time is equal to or later
> > than those on
> > > > previous CRLs (although that latter part is not required).  There's no
> > > > reason why you have to wait until the current CRL expires to
> > issue the new
> > > > one.
> > > >
> > > > >This means in practise that I have a valid intermediate CA for
> > > > > over two weeks,
> > > > > but in reality that intermediate CA is revoked. How can I
> > let everybody
> > > > know
> > > > > during that
> > > > > two week period that the intermediate CA is compromised, taking in
> > > > > account:"Conforming
> > > > > applications are NOT REQUIRED to support processing of delta CRLs,
> > > > indirect
> > > > > CRLs, or CRLs
> > > > > with a scope other than all certificates issued by one CA"?
> > > > >
> > > >
> > > > AWA:  Okay, here's how I've solved this problem in the past.
> > The root CA,
> > > > while off-line, is running in its secure facility.  When it
> > is necessary to
> > > > revoke an intermediate CA, the root CA is accessed to create
> > a new CRL.
> > > > This CRL is dumped to some medium, either burned onto a CD or
> > put onto a
> > > > floppy.  This medium is then hand-carried (the term we used
> > to use was
> > > "sent
> > > > via sneaker-net") to a server that is on the network.  It can
> > be either
> > > made
> > > > available as a CRL from, e.g., an LDAP repository; or it can
> > be provided to
> > > > an OCSP responder.
> > > >
> > > > The rest is up to your revocation policy.  If you rely only on CRLs,
> > > and you
> > > > allow users to cache CRLs until the end of their validity
> > period (e.g.,
> > > > until their "nextUpdate" time), then yes, you have in your scenario a
> > > > two-week window of vulnerability where users think an
> > intermediate CA is
> > > > good but it's really not.  That's a risk you take by relying
> > only on static
> > > > CRLs with that long a validity period. (Of course, one would hope that
> > > > revocation of an intermediate CA would be an extremely rare
> > event, so the
> > > > overall system risk/cost tradeoff may be acceptable, but...)
> > > >
> > > > On the other hand, you can use an OCSP-based system, where
> > users query the
> > > > responder and will discover that the intermediate CA has been
> > revoked the
> > > > first time they query its status.  OR you can use CRLs with a
> > shorter life
> > > > cycle.  Depending on what you're willing to pay in "human
> > capital" costs,
> > > > there's no reason you can't have the off-line CA issue a new CRL -
> > > generally
> > > > identical to the previous one - as often as you want; e.g.,
> > every day,
> > > every
> > > > 4 hours, whatever.  It just costs you to have the human move
> > the medium -
> > > > floppy, CD - from the off-line CA to the network-connected
> > > repository.  It's
> > > > not that hard.
> > > >
> > > > > Best regards,
> > > > > Haaino
> > > > >
> > > >
> > > > Hope this helps.
> > > >
> > > >                     Al Arsenault
> > > >                     Chief Security Architect
> > > >                     Diversinet Corp.
> >
> > ***********************************************************
> > Mitchell Arnone
> > Managing Consultant
> > SchlumbergerSema
> > Technical Consulting Practice, Northeast Region
> > Network & Infrastructure Solutions
> >
> > [e-mail]
> > www.slb.com/nws
> >
> > 35 Waterview Blvd.
> > Suite 210
> > Parsippany, NJ 07054-1200
> > USA
> >
> > Phone  [phone]
> > Mobile  [phone]
> >
> >

***********************************************************
Mitchell Arnone
Managing Consultant
SchlumbergerSema
Technical Consulting Practice, Northeast Region
Network & Infrastructure Solutions

[e-mail]
www.slb.com/nws

35 Waterview Blvd.
Suite 210
Parsippany, NJ 07054-1200
USA

Phone  [phone]
Mobile  [phone]




Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h03FJkI18407 for ietf-pkix-bks; Fri, 3 Jan 2003 07:19:46 -0800 (PST)
Received: from maile.telia.com (maile.telia.com [194.22.190.16]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h03FJjo18402 for <[e-mail]>; Fri, 3 Jan 2003 07:19:45 -0800 (PST)
Received: from arport (h119n2fls31o1122.telia.com [212.181.142.119]) by maile.telia.com (8.12.5/8.12.5) with SMTP id h03FJjCO005226; Fri, 3 Jan 2003 16:19:45 +0100 (CET)
X-Original-Recipient: [e-mail]
Message-ID: <00fa01c2b33b$4a16dd50$0500a8c0@arport>
From: "Anders Rundgren" <[e-mail]>
To: <[e-mail]>, <[e-mail]>
References: <[e-mail]>
Subject: CA Liability vs. Warranty in practice / draft-ietf-pkix-warranty-extn-01.txt
Date: Fri, 3 Jan 2003 16:17:54 +0100
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.50.4133.2400
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Alice,

Assume that an RP has suffered from a CA certification error.
Assume the RP has trusted a faulty purchase order which costed
them  (approximately) $10000 to cancel.

1. What would loosely be the practical difference for the RP
between a CA warranty of $25000 and a CA liability of $25000?

2. And if these were ZERO?

3. And if the certification error was due to an imposter?

Without nailing such basics firmly, I can't really see the 
"thin line" that seems to be dividing us.

I believe I'm not alone having problems with warranties
for indirect damages rather than for the product itself.

Cheers,
Anders Rundgren
Senior Internet e-Commerce Architect



Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h03DW4M08446 for ietf-pkix-bks; Fri, 3 Jan 2003 05:32:04 -0800 (PST)
Received: from maile.telia.com (maile.telia.com [194.22.190.16]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h03DVxo08435 for <[e-mail]>; Fri, 3 Jan 2003 05:32:00 -0800 (PST)
Received: from arport (h119n2fls31o1122.telia.com [212.181.142.119]) by maile.telia.com (8.12.5/8.12.5) with SMTP id h03DVnFg009260; Fri, 3 Jan 2003 14:31:52 +0100 (CET)
X-Original-Recipient: [e-mail]
Message-ID: <009101c2b32c$384082c0$0500a8c0@arport>
From: "Anders Rundgren" <[e-mail]>
To: <[e-mail]>, "Alice Sturgeon" <[e-mail]>
Cc: "Denis Pinkas" <[e-mail]>, <[e-mail]>, <[e-mail]>
Subject: RFC and then...? draft-ietf-pkix-warranty-extn-01.txt
Date: Fri, 3 Jan 2003 14:29:57 +0100
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_008E_01C2B334.9753D480"
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.50.4133.2400
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

This is a multi-part message in MIME format.

------=_NextPart_000_008E_01C2B334.9753D480
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Alice et al.

To create a standard in the IT-sector it is actually rather easy, and =
I'm sure that you without too much troubles can get the warranty =
extension through the IETF processes.

But, the real problem is [always] to get any major use of a standard.

In this particular case the "critical mass" problem is very hard as it =
requires both CAs, core software makers, and application makers to think =
this is a great idea.  Unless VeriSign, and similar market-leaders have =
expressed some support for this extension, I think it will from a =
usage-point of view fail, because why would anybody implement a =
non-technical ("soft") option that only a minor percentage of CAs are =
likely to support?

Another problem is that this option is anything but trivial to implement =
in a useful way.  If this is going to be transparently supported by =
interactive client/browser-side signatures, featuring pop-up dialogs =
etc, this probably even creeps into the core signature API and =
processes.

Added to that we have the principal difficulties mentioned by me and =
Denis.

A CA liability extension OTOH is an unilateral CA-decision to deploy, =
that since it should just be like an in-line agreement, does not require =
any application-level RP-software support.  When I think of it, the only =
reasonable place for a liability extension is in a CA certificate, as it =
is during the "trust installation/CA acceptance" phase, you should be =
made aware of CA conditions.  To have different liabilities in =
EE-certificates would be counterproductive, as it would then require the =
same kind of extensive and also slightly "yucky" software support, as =
imposed by the warranty-extension.

Best
Anders Rundgren
Senior Internet e-Commerce Architect=20

------=_NextPart_000_008E_01C2B334.9753D480
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML xmlns=3D"http://www.w3.org/TR/REC-html40" xmlns:v =3D=20
"urn:schemas-microsoft-com:vml" xmlns:o =3D=20
"urn:schemas-microsoft-com:office:office" xmlns:w =3D=20
"urn:schemas-microsoft-com:office:word"><HEAD>
<META content=3D"text/html; charset=3Diso-8859-1" =
http-equiv=3DContent-Type>
<META content=3DWord.Document name=3DProgId>
<META content=3D"MSHTML 5.00.3103.1000" name=3DGENERATOR>
<META content=3D"Microsoft Word 9" name=3DOriginator><LINK=20
href=3D"cid:[e-mail]340" rel=3DFile-List><!--[if gte =
mso 9]><xml>
 <o:OfficeDocumentSettings>
  <o:DoNotRelyOnCSS/>
 </o:OfficeDocumentSettings>
</xml><![endif]--><!--[if gte mso 9]><xml>
 <w:WordDocument>
  <w:Zoom>0</w:Zoom>
  <w:DocumentKind>DocumentEmail</w:DocumentKind>
  <w:EnvelopeVis/>
 </w:WordDocument>
</xml><![endif]-->
<STYLE>@font-face {
	font-family: Tahoma;
}
</STYLE>
<!--[if gte mso 9]><xml>
 <o:shapedefaults v:ext=3D"edit" spidmax=3D"1027"/>
</xml><![endif]--><!--[if gte mso 9]><xml>
 <o:shapelayout v:ext=3D"edit">
  <o:idmap v:ext=3D"edit" data=3D"1"/>
 </o:shapelayout></xml><![endif]--></HEAD>
<BODY background=3D"" bgColor=3D#ffffff lang=3DEN-US link=3Dblue =
vLink=3Dblue><![if !supportEmptyParas]><![endif]><![if =
!supportEmptyParas]><![endif]><![if !supportEmptyParas]><![endif]><![if =
!supportEmptyParas]><![endif]><![if !supportEmptyParas]><![endif]><![if =
!supportEmptyParas]><![endif]><!--[if supportFields]><span =
class=3DEmailStyle22><font=20
size=3D2 color=3Dnavy><span =
style=3D'font-size:11.0pt;mso-bidi-font-size:12.0pt'><span=20
style=3D'mso-element:field-begin'></span><span style=3D"mso-spacerun:=20
yes">&nbsp;</span>AUTOTEXTLIST \s &quot;E-mail Signature&quot; <span=20
style=3D'mso-element:field-separator'></span></span></font></span><![endi=
f]--><![if !supportLineBreakNewLine]><![endif]><!--[if =
supportFields]><span class=3DEmailStyle22><font=20
size=3D2 color=3Dnavy><span =
style=3D'font-size:11.0pt;mso-bidi-font-size:12.0pt'><span=20
style=3D'mso-element:field-end'></span></span></font></span><![endif]--><=
![if !supportEmptyParas]><![endif]><![if =
!supportEmptyParas]><![endif]><![if !supportEmptyParas]><![endif]>
<DIV><FONT face=3DArial size=3D2>Alice et al.</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>To create a standard in the IT-sector =
it is=20
actually rather easy, and </FONT><FONT face=3DArial size=3D2>I'm sure =
that you=20
without too much troubles can get the warranty extension through the =
IETF=20
processes.</FONT></DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>But, the real problem is [always] to =
get any major=20
<EM>use </EM>of a standard.</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>In this particular case the "critical =
mass" problem=20
is <EM>very </EM>hard as it requires both CAs, core software makers, and =

application makers to think this is a great idea.&nbsp; Unless VeriSign, =
and=20
similar market-leaders have expressed some support for this extension, I =
think=20
it will from a usage-point of view<EM> </EM>fail, because why would =
anybody=20
implement a <EM>non-technical ("soft") option </EM>that only a minor =
percentage=20
of CAs are likely to support?</DIV></FONT>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>Another problem is that <EM>this option =
is anything=20
but trivial to implement</EM> in a useful way.&nbsp; If this is going to =
be=20
transparently supported by interactive client/browser-side signatures, =
featuring=20
pop-up dialogs etc, this probably even creeps into the core signature =
API and=20
processes.</DIV></FONT>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>Added to that we have the principal =
difficulties=20
mentioned by me and Denis.</FONT></DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>A CA liability extension OTOH is an =
unilateral=20
CA-decision to deploy, that since it should just be like an in-line =
agreement,=20
does not require any application-level RP-software support.&nbsp; When I =
think=20
of it, <EM>the only reasonable place for a liability extension is in a =
CA=20
certificate</EM>, as it is during the "trust installation/CA acceptance" =
phase,=20
you should be made aware of CA conditions.&nbsp; To have different =
liabilities=20
in EE-certificates would be counterproductive, as it would then require =
the same=20
kind of extensive and also slightly "yucky" software support,&nbsp;as =
imposed by=20
the warranty-extension.</FONT></DIV>
<DIV><FONT face=3DArial size=3D2><BR></FONT><FONT face=3DArial =
size=3D2>Best<BR>Anders=20
Rundgren<BR>Senior Internet e-Commerce Architect</FONT> =
</DIV></BODY></HTML>

------=_NextPart_000_008E_01C2B334.9753D480--



Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h030hed06984 for ietf-pkix-bks; Thu, 2 Jan 2003 16:43:40 -0800 (PST)
Received: from pretender.boolean.net ([e-mail] [198.144.206.49]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h030hco06977 for <[e-mail]>; Thu, 2 Jan 2003 16:43:38 -0800 (PST)
Received: from nomad.OpenLDAP.org (root@localhost [127.0.0.1]) by pretender.boolean.net (8.12.6/8.12.5) with ESMTP id h030hX0a099764; Fri, 3 Jan 2003 00:43:34 GMT (envelope-from [e-mail])
Message-Id: <5.2.0.9.0.20030102154220.030316b0@127.0.0.1>
X-Sender: kurt@127.0.0.1
X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9
Date: Thu, 02 Jan 2003 16:43:22 -0800
To: "Ramsay, Ron" <[e-mail]>
From: "Kurt D. Zeilenga" <[e-mail]>
Subject: RE: LDAP PKI Schema (was Re: No-op LDAP ;binary option)
Cc: "Peter Gietz" <[e-mail]>, <[e-mail]>
In-Reply-To: <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

At 03:33 PM 1/2/2003, Ramsay, Ron wrote:
>I know, but is it widely implemented?

Given that it is still a work in progress, I hope not!
But there are early implementations which have provided
the operational experience that the approach is general
useful and otherwise suitable for standardization.  Same
is true for component matching.   I hope the IESG will
approve both soon.

Kurt

>-----Original Message-----
>From: Kurt D. Zeilenga [mailto:[e-mail]]
>Sent: Friday, 3 January 2003 04:01
>To: Ramsay, Ron
>Cc: Peter Gietz; [e-mail]
>Subject: RE: LDAP PKI Schema (was Re: No-op LDAP ;binary option)
>
>
>At 11:11 PM 1/1/2003, Ramsay, Ron wrote:
>>Component matching, however, does not address the problem of returning multiple certificates.
>
>We have a general solution to that general problem in the LDAP
>matched values control extension [draft-ietf-ldapext-matchedval]. 
>
>Kurt
>
>
>>Ron.
>>
>>-----Original Message-----
>>From: Kurt D. Zeilenga [mailto:[e-mail]]
>>Sent: Tuesday, 31 December 2002 18:38
>>To: Peter Gietz
>>Cc: [e-mail]
>>Subject: Re: LDAP PKI Schema (was Re: No-op LDAP ;binary option)
>>
>>
>>
>>
>>>Nevertheless two different solutions to one problem might be preferable here.
>>
>>My primary objection to standardizing the child entry approach
>>for PKI is that it is a PKI-specific solution to a general problem,
>>component matching of complex attribute values.   We should be
>>looking for general solutions to our general problems.  Steven's
>>component matching I-D details a general solution which I believe
>>is suitable for standardization.
>>
>>My recommendation is that the PKI "child entry" approach be
>>pursued individually as an Experimental (or possibly Informational)
>>solution to the PKI component matching problem with a note that
>>a more general solution, component matching, is being standardized.
>>
>>Kurt 



Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h030S1l05163 for ietf-pkix-bks; Thu, 2 Jan 2003 16:28:01 -0800 (PST)
Received: from ausyms50.ca.com ([155.35.248.106]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h030S0o05158 for <[e-mail]>; Thu, 2 Jan 2003 16:28:00 -0800 (PST)
content-class: urn:content-classes:message
Subject: RE: LDAP PKI Schema (was Re: No-op LDAP ;binary option)
Date: Fri, 3 Jan 2003 11:28:52 +1100
Message-ID: <[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: LDAP PKI Schema (was Re: No-op LDAP ;binary option)
X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0
Thread-Index: AcKygKFJiin3OL53QQykr8vpd1d6lwANnz3AAAHTxNA=
From: "Ramsay, Ron" <[e-mail]>
To: "Kurt D. Zeilenga" <[e-mail]>
Cc: "Peter Gietz" <[e-mail]>, <[e-mail]>
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id h030S0o05159
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Actually, it may not matter whether it is widely implemented. Because we wish to use component matching in matched-values, it will probably require any servers implementing matched-values to be rewritten to allow component-match in matched-values.

-----Original Message-----
From: Ramsay, Ron 
Sent: Friday, 3 January 2003 10:33
To: Kurt D. Zeilenga
Cc: Peter Gietz; [e-mail]
Subject: RE: LDAP PKI Schema (was Re: No-op LDAP ;binary option)



I know, but is it widely implemented?

-----Original Message-----
From: Kurt D. Zeilenga [mailto:[e-mail]]
Sent: Friday, 3 January 2003 04:01
To: Ramsay, Ron
Cc: Peter Gietz; [e-mail]
Subject: RE: LDAP PKI Schema (was Re: No-op LDAP ;binary option)


At 11:11 PM 1/1/2003, Ramsay, Ron wrote:
>Component matching, however, does not address the problem of returning multiple certificates.

We have a general solution to that general problem in the LDAP
matched values control extension [draft-ietf-ldapext-matchedval]. 

Kurt


>Ron.
>
>-----Original Message-----
>From: Kurt D. Zeilenga [mailto:[e-mail]]
>Sent: Tuesday, 31 December 2002 18:38
>To: Peter Gietz
>Cc: [e-mail]
>Subject: Re: LDAP PKI Schema (was Re: No-op LDAP ;binary option)
>
>
>
>
>>Nevertheless two different solutions to one problem might be preferable here.
>
>My primary objection to standardizing the child entry approach
>for PKI is that it is a PKI-specific solution to a general problem,
>component matching of complex attribute values.   We should be
>looking for general solutions to our general problems.  Steven's
>component matching I-D details a general solution which I believe
>is suitable for standardization.
>
>My recommendation is that the PKI "child entry" approach be
>pursued individually as an Experimental (or possibly Informational)
>solution to the PKI component matching problem with a note that
>a more general solution, component matching, is being standardized.
>
>Kurt 



Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h02NWJs29895 for ietf-pkix-bks; Thu, 2 Jan 2003 15:32:19 -0800 (PST)
Received: from ausyms50.ca.com ([155.35.248.106]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h02NWIo29891 for <[e-mail]>; Thu, 2 Jan 2003 15:32:18 -0800 (PST)
content-class: urn:content-classes:message
Subject: RE: LDAP PKI Schema (was Re: No-op LDAP ;binary option)
Date: Fri, 3 Jan 2003 10:33:09 +1100
Message-ID: <[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: LDAP PKI Schema (was Re: No-op LDAP ;binary option)
X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0
Thread-Index: AcKygKFJiin3OL53QQykr8vpd1d6lwANnz3A
From: "Ramsay, Ron" <[e-mail]>
To: "Kurt D. Zeilenga" <[e-mail]>
Cc: "Peter Gietz" <[e-mail]>, <[e-mail]>
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id h02NWIo29892
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

I know, but is it widely implemented?

-----Original Message-----
From: Kurt D. Zeilenga [mailto:[e-mail]]
Sent: Friday, 3 January 2003 04:01
To: Ramsay, Ron
Cc: Peter Gietz; [e-mail]
Subject: RE: LDAP PKI Schema (was Re: No-op LDAP ;binary option)


At 11:11 PM 1/1/2003, Ramsay, Ron wrote:
>Component matching, however, does not address the problem of returning multiple certificates.

We have a general solution to that general problem in the LDAP
matched values control extension [draft-ietf-ldapext-matchedval]. 

Kurt


>Ron.
>
>-----Original Message-----
>From: Kurt D. Zeilenga [mailto:[e-mail]]
>Sent: Tuesday, 31 December 2002 18:38
>To: Peter Gietz
>Cc: [e-mail]
>Subject: Re: LDAP PKI Schema (was Re: No-op LDAP ;binary option)
>
>
>
>
>>Nevertheless two different solutions to one problem might be preferable here.
>
>My primary objection to standardizing the child entry approach
>for PKI is that it is a PKI-specific solution to a general problem,
>component matching of complex attribute values.   We should be
>looking for general solutions to our general problems.  Steven's
>component matching I-D details a general solution which I believe
>is suitable for standardization.
>
>My recommendation is that the PKI "child entry" approach be
>pursued individually as an Experimental (or possibly Informational)
>solution to the PKI component matching problem with a note that
>a more general solution, component matching, is being standardized.
>
>Kurt 



Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h02JRbZ14433 for ietf-pkix-bks; Thu, 2 Jan 2003 11:27:37 -0800 (PST)
Received: from woodstock.binhost.com (woodstock.binhost.com [207.228.252.5]) by above.proper.com (8.11.6/8.11.3) with SMTP id h02JRao14426 for <[e-mail]>; Thu, 2 Jan 2003 11:27:36 -0800 (PST)
Received: (qmail 18814 invoked from network); 2 Jan 2003 19:27:16 -0000
Received: from unknown (HELO Russ-Laptop.vigilsec.com) (141.156.179.117) by woodstock.binhost.com with SMTP; 2 Jan 2003 19:27:16 -0000
Message-Id: <[e-mail]>
X-Sender: [e-mail] (Unverified)
X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9
Date: Thu, 02 Jan 2003 14:27:28 -0500
To: [e-mail]
From: Russ Housley <[e-mail]>
Subject: Re: I-D ACTION:draft-ietf-pkix-certstore-http-03.txt
Cc: [e-mail], [e-mail], [e-mail]
In-Reply-To: <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Tom:

RFC 3280 says that subjectAltName extension using the rfc822Name is the way 
that an email address SHOULD be included in a certificate.  I would like to 
see the text reinforces this, but says that there are certificates that use 
other placements.

Russ

At 07:06 PM 12/23/2002 -0500, Tom Gindin wrote:


>       How about mentioning the other two normal ways of storing the email
>address: "This is typically stored in the certificate either within the
>subject DN as a value of one of the attributes rfc822mailbox or
>emailAddress, or in the subjectAltName extension using the rfc822Name
>choice of GeneralName".   I've personally never seen anyone use any other
>way than those three.
>
>             Tom Gindin
>
>
>[e-mail] (Peter Gutmann)@mail.imc.org on 12/20/2002
>09:10:32 PM
>
>Sent by:    [e-mail]
>
>
>To:    [e-mail], [e-mail]
>cc:
>Subject:    Re: I-D ACTION:draft-ietf-pkix-certstore-http-03.txt
>
>
>
>Jeff Jacoby <[e-mail]> writes:
>
> >Is it necessary to require an exact match for all attributes, particularly
> >for such attributes as the email and name attributes?
>
>In a word, yes.
>
> >For example, I'm looking for the cert for Bill Williams, but I don't know
>if
> >the common name is "Bill Williams" or "Will Williams" or "B. Williams",
>etc,
> >so I might like to try a search on just "Williams"
>
>How would you specify this?  You'd need some sort of general-purpose
>pattern-
>matching mechanism and then a means of mapping it to every possible backend
>that might be used to implement the lookup.  The draft specifies a
>universal
>interface to (conceptually) a basic key-and-value lookup engine, which
>doesn't
>extend to general pattern-matching.  If you need anything more than this
>(for
>example searching on compound attributes and similar things) you should
>really
>use LDAP.
>
> >Secondly, the entry for email attribute indicates the value as:
> >
> >  "Subject email address contained in the certificate, typically as an
> >   rfc882Name attribute
> >
> >Is it necessary the email attribute be from the certificate.  Is it a
> >reasonable or likely situation that a certificate store might use the
>email
> >address as an database index even though it's not actually in the
> >certificate?
>
>I'd never thought of it being done like that, but I can easily change the
>text
>to accomodate it.  How about:
>
>   Subject email address associated with the certificate.  This is typically
>   stored in the certificate as an rfc882Name attribute.
>
>Peter.



Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h02H1mg03392 for ietf-pkix-bks; Thu, 2 Jan 2003 09:01:48 -0800 (PST)
Received: from pretender.boolean.net ([e-mail] [198.144.206.49]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h02H1ko03388 for <[e-mail]>; Thu, 2 Jan 2003 09:01:46 -0800 (PST)
Received: from nomad.OpenLDAP.org (root@localhost [127.0.0.1]) by pretender.boolean.net (8.12.6/8.12.5) with ESMTP id h02H1a0a097934; Thu, 2 Jan 2003 17:01:40 GMT (envelope-from [e-mail])
Message-Id: <5.2.0.9.0.20030102085547.01d3e8d8@127.0.0.1>
X-Sender: kurt@127.0.0.1
X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9
Date: Thu, 02 Jan 2003 09:01:25 -0800
To: "Ramsay, Ron" <[e-mail]>
From: "Kurt D. Zeilenga" <[e-mail]>
Subject: RE: LDAP PKI Schema (was Re: No-op LDAP ;binary option)
Cc: "Peter Gietz" <[e-mail]>, <[e-mail]>
In-Reply-To: <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

At 11:11 PM 1/1/2003, Ramsay, Ron wrote:
>Component matching, however, does not address the problem of returning multiple certificates.

We have a general solution to that general problem in the LDAP
matched values control extension [draft-ietf-ldapext-matchedval]. 

Kurt


>Ron.
>
>-----Original Message-----
>From: Kurt D. Zeilenga [mailto:[e-mail]]
>Sent: Tuesday, 31 December 2002 18:38
>To: Peter Gietz
>Cc: [e-mail]
>Subject: Re: LDAP PKI Schema (was Re: No-op LDAP ;binary option)
>
>
>
>
>>Nevertheless two different solutions to one problem might be preferable here.
>
>My primary objection to standardizing the child entry approach
>for PKI is that it is a PKI-specific solution to a general problem,
>component matching of complex attribute values.   We should be
>looking for general solutions to our general problems.  Steven's
>component matching I-D details a general solution which I believe
>is suitable for standardization.
>
>My recommendation is that the PKI "child entry" approach be
>pursued individually as an Experimental (or possibly Informational)
>solution to the PKI component matching problem with a note that
>a more general solution, component matching, is being standardized.
>
>Kurt 



Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h027AWa11824 for ietf-pkix-bks; Wed, 1 Jan 2003 23:10:32 -0800 (PST)
Received: from ausyms50.ca.com ([155.35.248.106]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h027ASo11797 for <[e-mail]>; Wed, 1 Jan 2003 23:10:29 -0800 (PST)
content-class: urn:content-classes:message
Subject: RE: LDAP PKI Schema (was Re: No-op LDAP ;binary option)
Date: Thu, 2 Jan 2003 18:11:20 +1100
Message-ID: <[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: LDAP PKI Schema (was Re: No-op LDAP ;binary option)
X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0
Thread-Index: AcKwpVnBx4b2bnqaSlOvmQN8ZmEDqABiGzzg
From: "Ramsay, Ron" <[e-mail]>
To: "Kurt D. Zeilenga" <[e-mail]>, "Peter Gietz" <[e-mail]>
Cc: <[e-mail]>
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id h027ATo11803
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Component matching, however, does not address the problem of returning multiple certificates.

That is, if component matching were to be used, and if the entry contains a matching certificate, then all certificates in the entry would be returned. Using subordinate entries ensures only one certificate is returned.

Ron.

-----Original Message-----
From: Kurt D. Zeilenga [mailto:[e-mail]]
Sent: Tuesday, 31 December 2002 18:38
To: Peter Gietz
Cc: [e-mail]
Subject: Re: LDAP PKI Schema (was Re: No-op LDAP ;binary option)




>Nevertheless two different solutions to one problem might be preferable here.

My primary objection to standardizing the child entry approach
for PKI is that it is a PKI-specific solution to a general problem,
component matching of complex attribute values.   We should be
looking for general solutions to our general problems.  Steven's
component matching I-D details a general solution which I believe
is suitable for standardization.

My recommendation is that the PKI "child entry" approach be
pursued individually as an Experimental (or possibly Informational)
solution to the PKI component matching problem with a note that
a more general solution, component matching, is being standardized.

Kurt