Re: RFC4210 and CMPtrans

[[e-mail] (Peter Gutmann)]

Teemu Alakoski <[e-mail]> writes:

>CMP RFC (4210) refers to [CMPtrans] which is an expired I-D, latest version
>being "draft-ietf-pkix-cmp-transport-protocols-05". CMPtrans is supposed to
>define the transport methods for CMP as they were separated from the CMP RFC.
>
>As RFC4210 is a quite fresh RFC, I would assume there is an intent to push
>also CMPtrans to RFC status. Is anyone working on it?

This is another one of these things that should be an FAQ, since it looks like
the RFC will never be fixed... CMPtrans was an embarassing kludge added to CMP
when it was found that the protocol as specified didn't actually work (rather
than fix it, an external wrapper was added as a hack to get around some of the
problems, although this created more problems because while CMP messages are
protected the wrapper messages aren't, so you can attack the protocol by
attacking the unprotected wrapper).  It's still present as a vestigial
remnant, but the real transport protocol for CMP is HTTP.  Unfortunately the
CMP RFC can't admit that, so people keep asking this same question here or on
other lists... the answer is to ignore CMPtrans and use HTTP.  QED.

Peter.





Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id jBR9pTZ8006460; Tue, 27 Dec 2005 01:51:29 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id jBR9pTwN006459; Tue, 27 Dec 2005 01:51:29 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from harpo.itss.auckland.ac.nz (harpo.itss.auckland.ac.nz [130.216.190.13]) by above.proper.com (8.12.11/8.12.9) with ESMTP id jBR9pSNK006446 for <[e-mail]>; Tue, 27 Dec 2005 01:51:28 -0800 (PST) (envelope-from [e-mail])
Received: from localhost (localhost.localdomain [127.0.0.1]) by harpo.itss.auckland.ac.nz (Postfix) with ESMTP id 81D2635450; Tue, 27 Dec 2005 22:50:55 +1300 (NZDT)
Received: from harpo.itss.auckland.ac.nz ([127.0.0.1]) by localhost (smtpc.itss.auckland.ac.nz [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 12975-28; Tue, 27 Dec 2005 22:50:55 +1300 (NZDT)
Received: from iris.cs.auckland.ac.nz (iris.cs.auckland.ac.nz [130.216.33.152]) by harpo.itss.auckland.ac.nz (Postfix) with ESMTP id 143AD340D6; Tue, 27 Dec 2005 22:50:54 +1300 (NZDT)
Received: from medusa01.cs.auckland.ac.nz (medusa01.cs.auckland.ac.nz [130.216.34.33]) by iris.cs.auckland.ac.nz (Postfix) with ESMTP id E407B37745; Tue, 27 Dec 2005 22:50:54 +1300 (NZDT)
Received: from pgut001 by medusa01.cs.auckland.ac.nz with local (Exim 3.36 #1 (Debian)) id 1ErBTy-0005E3-00; Tue, 27 Dec 2005 22:51:02 +1300
From: [e-mail] (Peter Gutmann)
To: [e-mail], [e-mail]
Subject: Re: RFC4210 and CMPtrans
In-Reply-To: <[e-mail]>
Message-Id: <[e-mail]>
Date: Tue, 27 Dec 2005 22:51:02 +1300
X-Virus-Scanned: by amavisd-new at mailhost.auckland.ac.nz
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Teemu Alakoski <[e-mail]> writes:

>CMP RFC (4210) refers to [CMPtrans] which is an expired I-D, latest version
>being "draft-ietf-pkix-cmp-transport-protocols-05". CMPtrans is supposed to
>define the transport methods for CMP as they were separated from the CMP RFC.
>
>As RFC4210 is a quite fresh RFC, I would assume there is an intent to push
>also CMPtrans to RFC status. Is anyone working on it?

This is another one of these things that should be an FAQ, since it looks like
the RFC will never be fixed... CMPtrans was an embarassing kludge added to CMP
when it was found that the protocol as specified didn't actually work (rather
than fix it, an external wrapper was added as a hack to get around some of the
problems, although this created more problems because while CMP messages are
protected the wrapper messages aren't, so you can attack the protocol by
attacking the unprotected wrapper).  It's still present as a vestigial
remnant, but the real transport protocol for CMP is HTTP.  Unfortunately the
CMP RFC can't admit that, so people keep asking this same question here or on
other lists... the answer is to ignore CMPtrans and use HTTP.  QED.

Peter.



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id jBR9CVMa002975; Tue, 27 Dec 2005 01:12:31 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id jBR9CVxY002974; Tue, 27 Dec 2005 01:12:31 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from mail.insta.fi (mail.insta.fi [212.246.151.130] (may be forged)) by above.proper.com (8.12.11/8.12.9) with ESMTP id jBR9CTt2002961 for <[e-mail]>; Tue, 27 Dec 2005 01:12:30 -0800 (PST) (envelope-from [e-mail])
Received: from [192.168.25.155] ([192.168.25.155]) by mail.insta.fi with Microsoft SMTPSVC(5.0.2195.6713); Tue, 27 Dec 2005 11:12:23 +0200
Message-ID: <[e-mail]>
Date: Tue, 27 Dec 2005 11:10:30 +0200
From: Teemu Alakoski <[e-mail]>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.7) Gecko/20050414
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: [e-mail]
Subject: RFC4210 and CMPtrans
X-Enigmail-Version: 0.91.0.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
X-OriginalArrivalTime: 27 Dec 2005 09:12:23.0372 (UTC) FILETIME=[A5D5B8C0:01C60AC5]
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Hello,

CMP RFC (4210) refers to [CMPtrans] which is an expired I-D, latest
version being "draft-ietf-pkix-cmp-transport-protocols-05". CMPtrans
is supposed to define the transport methods for CMP as they were
separated from the CMP RFC.

As RFC4210 is a quite fresh RFC, I would assume there is an intent
to push also CMPtrans to RFC status. Is anyone working on it?

-Teemu

--
Teemu Alakoski

INSTRUMENTOINTI OY
Instasec Oy

P.O. Box 174 (Finlaysoninkuja 21 A)
FI-33101 TAMPERE, FINLAND
Tel. 	[phone]
Gsm	[phone]
Fax	[phone]
[e-mail]
www.insta.fi





Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id jBMKjiBa050193; Thu, 22 Dec 2005 12:45:44 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id jBMKji1K050192; Thu, 22 Dec 2005 12:45:44 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from mail1.quimbik.com (mail1.quimbik.com [198.87.27.232]) by above.proper.com (8.12.11/8.12.9) with ESMTP id jBMKjhOG050184 for <[e-mail]>; Thu, 22 Dec 2005 12:45:43 -0800 (PST) (envelope-from [e-mail])
Received: from [172.16.1.52] (adsl-63-204-17-85.dsl.snfc21.pacbell.net [63.204.17.85]) by mail1.quimbik.com (Postfix) with ESMTP id 212C633C158 for <[e-mail]>; Thu, 22 Dec 2005 12:45:43 -0800 (PST)
Message-ID: <[e-mail]>
Date: Thu, 22 Dec 2005 12:45:42 -0800
From: Ed Gerck <[e-mail]>
User-Agent: Thunderbird 1.4 (Macintosh/20050908)
MIME-Version: 1.0
To: [e-mail]
Subject: Re: Certificate Validity Problem
References: <003401c6063b$4df1d7d0$[e-mail]>
In-Reply-To: <003401c6063b$4df1d7d0$[e-mail]>
Content-Type: text/plain; charset=ISO-8859-1; 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>

santosh chokhani wrote:
...
> 
> Also, there would be a need to change in 3280 so that base CRLs (vice delta)
> can have "remove from hold" reason code.  Once you have these, you can use
> revocation date in CRL entries to determine the revocation status at various
> time.

Some practices are suggested in my ID, "Certificate Revocation Revisited"
<http://www.faqs.org/ftp/pub/internet-drafts/draft-gerck-pkix-revocation-00.txt>
currently expired, allowing a relying party to determine the revocation status
of a certificate with higher reliability in less time -- notwithstanding the
discussed problems, including:

"Some mechanisms may not include direct evidence of the issuer CA's
assertion of a certificate's revocation status or conditions, at a
particular time. "

The ID also includes the considerations that apply to determinations of status
"change" processes, including certificateHold and removefromCRL.

Comments on the ID are welcome, as I am preparing an updated version (now
that some reference RFCs have been updated by the WG).

Cheers,
Ed Gerck



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id jBLKo30W005035; Wed, 21 Dec 2005 12:50:03 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id jBLKo3dj005034; Wed, 21 Dec 2005 12:50:03 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from newodin.ietf.org ([132.151.6.50]) by above.proper.com (8.12.11/8.12.9) with ESMTP id jBLKo2Qe005019 for <[e-mail]>; Wed, 21 Dec 2005 12:50:02 -0800 (PST) (envelope-from [e-mail])
Received: from mlee by newodin.ietf.org with local (Exim 4.43) id 1EpAuQ-0005XB-1B; Wed, 21 Dec 2005 15:50:02 -0500
Content-Type: Multipart/Mixed; Boundary="NextPart"
Mime-Version: 1.0
To: [e-mail]
Cc: [e-mail]
From: [e-mail]
Subject: I-D ACTION:draft-ietf-pkix-gost-cppk-04.txt 
Message-Id: <[e-mail]>
Date: Wed, 21 Dec 2005 15:50:02 -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		: Using the GOST R 34.10-94, GOST R 34.10-2001
                          and GOST R 34.11-94 algorithms with the 
                          Internet X.509 Public Key Infrastructure 
                          Certificate and CRL Profile.
	Author(s)	: S. Leontiev, et al.
	Filename	: draft-ietf-pkix-gost-cppk-04.txt
	Pages		: 18
	Date		: 2005-12-21
	
This document supplements RFC 3279. It describes encoding formats,
   identifiers and parameter formats for the algorithms GOST R 34.10-94,
   GOST R 34.10-2001 and GOST R 34.11-94 for use in Internet X.509
   Public Key Infrastructure (PKI).

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

To remove yourself from the I-D Announcement list, send a message to 
[e-mail] with the word unsubscribe in the body of the message.  
You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce 
to change your subscription settings.


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-gost-cppk-04.txt".

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


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

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

--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"

--OtherAccess
Content-Type: Message/External-body;
	access-type="mail-server";
	server="[e-mail]"

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

ENCODING mime
FILE /internet-drafts/draft-ietf-pkix-gost-cppk-04.txt

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

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

--OtherAccess--

--NextPart--



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id jBLKW9oD003638; Wed, 21 Dec 2005 12:32:09 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id jBLKW9RH003637; Wed, 21 Dec 2005 12:32:09 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from pne-smtpout1-sn1.fre.skanova.net (pne-smtpout1-sn1.fre.skanova.net [81.228.11.98]) by above.proper.com (8.12.11/8.12.9) with ESMTP id jBLKW76g003613 for <[e-mail]>; Wed, 21 Dec 2005 12:32:07 -0800 (PST) (envelope-from [e-mail])
Received: from arport2v (81.232.45.196) by pne-smtpout1-sn1.fre.skanova.net (7.2.069.1) id 43A9761F00016A13; Wed, 21 Dec 2005 21:31:54 +0100
Message-ID: <002401c6066e$383bcc10$8217a8c0@arport2v>
From: "Anders Rundgren" <[e-mail]>
To: "sravan" <[e-mail]>, <[e-mail]>
Cc: "Ersin Gulacti" <[e-mail]>
References: <[e-mail]> <[e-mail]>
Subject: Re: Certificate Validity Problem
Date: Wed, 21 Dec 2005 21:36:28 +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 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>

Dear Sravan & Ersin,

<snip>
>The problem here is that during certificate validation, latest* 
>*revocation information is being used instead of that available at the 
>time of signing.

I would rather say that the problem is to determine the actual signing
time unless you are going to trust the client's (software) opinion on that.

But there is fortunately a simple workaround:

In 21st century information systems, on-line signatures should be used,
making signing time=validation time.  Then OCSP works similar to how
most credit-card processing systems do since the 80ties.  In Scandinavia
governments have abandoned e-mail signatures for on-line signatures,
as on-line not only allows  you to validate a task (not only its signature),
the instant it is actually submitted, but also offers an interactive mode
as well as supporting structured data with full indata and form control
(Excel files or PDF forms sent by signed e-mail is simply stone age revisited).

================================================
   The remaining and non-trivial issue is then how to best address the
   case when a CA (usually via the certificate holder), finds out that a
   certificate may have been used by a fraudster
================================================

In my opinion, historical validation is a problematic approach because it
does not address the fundamental question: WHEN is the "right time" for
a relying party application to call such a service?  If you already know
how to specify this for your user community, please let us, somewhat
less enlightened, share this knowledge :-)

Authentication >> Signatures
Although signatures indeed are "cool",  authentication errors (and due to that
information-theft), is probably in the real world, a considerably bigger issue
as there is no way you can "rollback" such an error.   How do you intend
to deal with this using historical validation?  

To actually be *informed* that you may have had a break-in, or that
you are possibly keeping invalid documents in your systems, seems to be
worth some thinking, maybe even a new protocol!

regards
Anders Rundgren
Principal Engineer
RSA Security



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id jBLGaaCS078134; Wed, 21 Dec 2005 08:36:36 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id jBLGaaEq078133; Wed, 21 Dec 2005 08:36:36 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from srv1.int.stroeder.com (196-30-124-83.dsl.3u.net [83.124.30.196]) by above.proper.com (8.12.11/8.12.9) with ESMTP id jBLGaZAq078124 for <[e-mail]>; Wed, 21 Dec 2005 08:36:35 -0800 (PST) (envelope-from [e-mail])
Received: from localhost (localhost [127.0.0.1]) by srv1.int.stroeder.com (Postfix) with ESMTP id 4CD073371 for <[e-mail]>; Wed, 21 Dec 2005 17:36:28 +0100 (CET)
Received: from srv1.int.stroeder.com ([127.0.0.1]) by localhost (srv1 [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 18772-01 for <[e-mail]>; Wed, 21 Dec 2005 17:36:09 +0100 (CET)
Received: from [10.1.1.5] (unknown [10.1.1.5]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "Michael Stroeder", Issuer "Thawte Personal Freemail Issuing CA" (not verified)) by srv1.int.stroeder.com (Postfix) with ESMTP id 674A83356 for <[e-mail]>; Wed, 21 Dec 2005 17:36:09 +0100 (CET)
Message-ID: <[e-mail]>
Date: Wed, 21 Dec 2005 16:30:28 +0100
From: =?ISO-8859-1?Q?Michael_Str=F6der?= <[e-mail]>
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.12) Gecko/20050920
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: [e-mail]
Subject: Re: Certificate Validity Problem
References: <[e-mail]> <p06230900bfcdc7aae330@[128.89.89.106]>
In-Reply-To: <p06230900bfcdc7aae330@[128.89.89.106]>
X-Enigmail-Version: 0.93.0.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
X-Virus-Scanned: amavisd-new at int.stroeder.com
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Stephen Kent wrote:
> 
> The use of the "certificate on hold" reason code seems to be the one
> case that causes the greatest potential problem for an RP who fails to
> collect timely revocation status data. I view this as another example of
> why this feature ought to be deprecated :-).

Yes. It really opens a can of worms.

Ciao, Michael.



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id jBLEW1FI061861; Wed, 21 Dec 2005 06:32:01 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id jBLEW1Io061860; Wed, 21 Dec 2005 06:32:01 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from host15.websitesource.com (host15.websitesource.com [209.239.32.38]) by above.proper.com (8.12.11/8.12.9) with ESMTP id jBLEW0sp061849 for <[e-mail]>; Wed, 21 Dec 2005 06:32:00 -0800 (PST) (envelope-from [e-mail])
Received: from wchokhani (PPP-219.65.47.161.mum2.dialup.vsnl.net.in [219.65.47.161] (may be forged)) by host15.websitesource.com (8.12.10/8.12.10) with ESMTP id jBLEVoEG019273 for <[e-mail]>; Wed, 21 Dec 2005 09:31:56 -0500
From: "santosh chokhani" <[e-mail]>
To: <[e-mail]>
Subject: RE: Certificate Validity Problem
Date: Wed, 21 Dec 2005 09:31:47 -0500
Message-ID: <003401c6063b$4df1d7d0$[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Office Outlook 11
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2670
In-Reply-To: <p06230900bfcdc7aae330@[128.89.89.106]>
Thread-Index: AcYFgifnUyXEl5RrRcK9b7Qrd5pvsAAuJ+Rg
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

If the cryptanalysis or compromise of expired keys is not a concern, one
could do cumulative CRL using an X.509 extension (3280 does not have this)
stating that the CRL contains expired certificates.

Also, there would be a need to change in 3280 so that base CRLs (vice delta)
can have "remove from hold" reason code.  Once you have these, you can use
revocation date in CRL entries to determine the revocation status at various
time.

(Good luck in terms of non-repudiation).

-----Original Message-----
From: [e-mail] [mailto:[e-mail]] On
Behalf Of Stephen Kent
Sent: Tuesday, December 20, 2005 10:05 AM
To: Tom Gindin
Cc: Ersin Gulacti; [e-mail]
Subject: Re: Certificate Validity Problem


At 8:54 AM -0500 12/20/05, Tom Gindin wrote:
>         Steve:
>
>         I don't see why a critical OCSP SingleRequestExtension could not
>be defined to do this.  It could be called "StatusEffectiveTime", with
>syntax GeneralizedTime.  Why would another protocol be needed when a
>single extension might do the trick?
>         I realize that RFC 2560 section 4.1.2 deprecates the use of
>critical extensions, but this is a clear case for one.  Using a
>non-critical extension would not work, since the requestor is not
>interested in the current status.  Support for this extension in a
>responder would be OPTIONAL.
>         A standard current OCSP responder would be unlikely, as a
>functional matter, to be able to resolve these queries from its database.
>
>Tom Gindin

Tom,

The change to the message format might be simple, as you suggest. 
However, the change at the server might be very extensive, and there 
is the question of whether the description of the requested 
functionality has really been posed properly.

We have seen a move toward fast-response OCSP servers that use 
pre-signed responses, which is incompatible with this sort of change 
in functionality. So, for some class of OCSP servers, this extension 
would not be supportable. I think we agree on that, given your 
closing sentence above.

Also, based on some of the message exchanged on this topic, it seems 
that some folks are trying to use OCSP as a cert status protocol, vs. 
a revocation status protocol. PKIX has declined to expand the scope 
of OCSP for this purpose. Some messages talk in terms of querying a 
CA for status data. That's worrisome, since the PKI model under which 
we operate makes the role of directories and OCSP servers distinct 
from CAs.  A CA may choose to operate a directory server or an OCSP 
server, but the CA is not the server, per se. This sort of confusion 
causes me to question the generality of suggestions like this.

To determine if a cert was valid, for a specific purpose, at a prior 
point in time, an RP needs to construct a cert path and verify the 
revocation status of each cert in the path, all relative to a given 
validation policy, as per SCVP. For expired EE certs, there is the 
possibility that one of more of the CA certs also have expired. So, 
what do we assume the RP has and has not saved from the transaction 
in question? If the RP saved the certs for the path, why did he not 
also save the CRLs or OCSP responses too? If he saved nothing but the 
EE cert, then what mechanism do we envision for him to acquire the 
expired CA certs in the path?

The use of the "certificate on hold" reason code seems to be the one 
case that causes the greatest potential problem for an RP who fails 
to collect timely revocation status data. I view this as another 
example of why this feature ought to be deprecated :-).

Steve



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id jBKKo6QJ049266; Tue, 20 Dec 2005 12:50:06 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id jBKKo6iI049265; Tue, 20 Dec 2005 12:50:06 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from newodin.ietf.org ([132.151.6.50]) by above.proper.com (8.12.11/8.12.9) with ESMTP id jBKKo5BM049231 for <[e-mail]>; Tue, 20 Dec 2005 12:50:05 -0800 (PST) (envelope-from [e-mail])
Received: from mlee by newodin.ietf.org with local (Exim 4.43) id 1EooQr-0008SR-V4; Tue, 20 Dec 2005 15:50:01 -0500
Content-Type: Multipart/Mixed; Boundary="NextPart"
Mime-Version: 1.0
To: [e-mail]
Cc: [e-mail]
From: [e-mail]
Subject: I-D ACTION:draft-ietf-pkix-acpolicies-extn-07.txt 
Message-Id: <[e-mail]>
Date: Tue, 20 Dec 2005 15:50:01 -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		: Attribute Certificate Policies extension
	Author(s)	: C. Francis, D. Pinkas
	Filename	: draft-ietf-pkix-acpolicies-extn-07.txt
	Pages		: 10
	Date		: 2005-12-20
	
This document describes one certificate extension to explicitly
   state the Attribute Certificate Policies (ACPs) that apply to a 
   given Attribute Certificate (AC).  The goal of this document is to 
   allow relying parties to perform an additional test when validating 
   an AC, i.e. to assess whether a given AC carrying some attributes 
   can be accepted on the basis of references to one or more specific 
   ACPs.

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

To remove yourself from the I-D Announcement list, send a message to 
[e-mail] with the word unsubscribe in the body of the message.  
You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce 
to change your subscription settings.


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-acpolicies-extn-07.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-acpolicies-extn-07.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-acpolicies-extn-07.txt

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

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

--OtherAccess--

--NextPart--



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id jBKF5vDW009567; Tue, 20 Dec 2005 07:05:57 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id jBKF5vES009565; Tue, 20 Dec 2005 07:05:57 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from aragorn.bbn.com (aragorn.bbn.com [128.33.0.62]) by above.proper.com (8.12.11/8.12.9) with ESMTP id jBKF5uCx009528 for <[e-mail]>; Tue, 20 Dec 2005 07:05:56 -0800 (PST) (envelope-from [e-mail])
Received: from [128.33.244.163] (col-dhcp33-244-163.bbn.com [128.33.244.163]) by aragorn.bbn.com (8.12.7/8.12.7) with ESMTP id jBKF5kIC022898; Tue, 20 Dec 2005 10:05:50 -0500 (EST)
Mime-Version: 1.0
Message-Id: <p06230900bfcdc7aae330@[128.89.89.106]>
In-Reply-To:  <[e-mail]>
References:  <[e-mail]>
Date: Tue, 20 Dec 2005 10:05:20 -0500
To: Tom Gindin <[e-mail]>
From: Stephen Kent <[e-mail]>
Subject: Re: Certificate Validity Problem
Cc: "Ersin Gulacti" <[e-mail]>, [e-mail]
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
X-Virus-Scanned: ClamAV version 0.83, clamav-milter version 0.83 on 128.33.1.41
X-Virus-Status: Clean
Sender: [e-mail]
Precedence: 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 8:54 AM -0500 12/20/05, Tom Gindin wrote:
>         Steve:
>
>         I don't see why a critical OCSP SingleRequestExtension could not
>be defined to do this.  It could be called "StatusEffectiveTime", with
>syntax GeneralizedTime.  Why would another protocol be needed when a
>single extension might do the trick?
>         I realize that RFC 2560 section 4.1.2 deprecates the use of
>critical extensions, but this is a clear case for one.  Using a
>non-critical extension would not work, since the requestor is not
>interested in the current status.  Support for this extension in a
>responder would be OPTIONAL.
>         A standard current OCSP responder would be unlikely, as a
>functional matter, to be able to resolve these queries from its database.
>
>Tom Gindin

Tom,

The change to the message format might be simple, as you suggest. 
However, the change at the server might be very extensive, and there 
is the question of whether the description of the requested 
functionality has really been posed properly.

We have seen a move toward fast-response OCSP servers that use 
pre-signed responses, which is incompatible with this sort of change 
in functionality. So, for some class of OCSP servers, this extension 
would not be supportable. I think we agree on that, given your 
closing sentence above.

Also, based on some of the message exchanged on this topic, it seems 
that some folks are trying to use OCSP as a cert status protocol, vs. 
a revocation status protocol. PKIX has declined to expand the scope 
of OCSP for this purpose. Some messages talk in terms of querying a 
CA for status data. That's worrisome, since the PKI model under which 
we operate makes the role of directories and OCSP servers distinct 
from CAs.  A CA may choose to operate a directory server or an OCSP 
server, but the CA is not the server, per se. This sort of confusion 
causes me to question the generality of suggestions like this.

To determine if a cert was valid, for a specific purpose, at a prior 
point in time, an RP needs to construct a cert path and verify the 
revocation status of each cert in the path, all relative to a given 
validation policy, as per SCVP. For expired EE certs, there is the 
possibility that one of more of the CA certs also have expired. So, 
what do we assume the RP has and has not saved from the transaction 
in question? If the RP saved the certs for the path, why did he not 
also save the CRLs or OCSP responses too? If he saved nothing but the 
EE cert, then what mechanism do we envision for him to acquire the 
expired CA certs in the path?

The use of the "certificate on hold" reason code seems to be the one 
case that causes the greatest potential problem for an RP who fails 
to collect timely revocation status data. I view this as another 
example of why this feature ought to be deprecated :-).

Steve



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id jBKDsU6r099888; Tue, 20 Dec 2005 05:54:30 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id jBKDsUGF099887; Tue, 20 Dec 2005 05:54:30 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from e3.ny.us.ibm.com (e3.ny.us.ibm.com [32.97.182.143]) by above.proper.com (8.12.11/8.12.9) with ESMTP id jBKDsS4B099870 for <[e-mail]>; Tue, 20 Dec 2005 05:54:28 -0800 (PST) (envelope-from [e-mail])
Received: from d01relay02.pok.ibm.com (d01relay02.pok.ibm.com [9.56.227.234]) by e3.ny.us.ibm.com (8.12.11/8.12.11) with ESMTP id jBKDsJ7Z019497 for <[e-mail]>; Tue, 20 Dec 2005 08:54:19 -0500
Received: from d01av01.pok.ibm.com (d01av01.pok.ibm.com [9.56.224.215]) by d01relay02.pok.ibm.com (8.12.10/NCO/VERS6.8) with ESMTP id jBKDsJu4094264 for <[e-mail]>; Tue, 20 Dec 2005 08:54:19 -0500
Received: from d01av01.pok.ibm.com (loopback [127.0.0.1]) by d01av01.pok.ibm.com (8.12.11/8.13.3) with ESMTP id jBKDsJwc022346 for <[e-mail]>; Tue, 20 Dec 2005 08:54:19 -0500
Received: from d01ml062.pok.ibm.com (d01ml062.pok.ibm.com [9.56.228.115]) by d01av01.pok.ibm.com (8.12.11/8.12.11) with ESMTP id jBKDsJfP022343; Tue, 20 Dec 2005 08:54:19 -0500
In-Reply-To: <p06230902bfcc78a3d917@[128.89.89.106]>
To: Stephen Kent <[e-mail]>
Cc: "Ersin Gulacti" <[e-mail]>, [e-mail]
MIME-Version: 1.0
Subject: Re: Certificate Validity Problem
X-Mailer: Lotus Notes Release 6.0.2CF1 June 9, 2003
From: Tom Gindin <[e-mail]>
Message-ID: <[e-mail]>
Date: Tue, 20 Dec 2005 08:54:17 -0500
X-MIMETrack: Serialize by Router on D01ML062/01/M/IBM(Release 6.5.4FP2 HF2|November 9, 2005) at 12/20/2005 08:54:18, Serialize complete at 12/20/2005 08:54:18
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>

        Steve:

        I don't see why a critical OCSP SingleRequestExtension could not 
be defined to do this.  It could be called "StatusEffectiveTime", with 
syntax GeneralizedTime.  Why would another protocol be needed when a 
single extension might do the trick?
        I realize that RFC 2560 section 4.1.2 deprecates the use of 
critical extensions, but this is a clear case for one.  Using a 
non-critical extension would not work, since the requestor is not 
interested in the current status.  Support for this extension in a 
responder would be OPTIONAL.
        A standard current OCSP responder would be unlikely, as a 
functional matter, to be able to resolve these queries from its database.

Tom Gindin





Stephen Kent <[e-mail]>
Sent by: [e-mail]
12/19/2005 09:57 AM
 
        To:     "Ersin Gulacti" <[e-mail]>
        cc:     [e-mail]
        Subject:        Re: Certificate Validity Problem



At 11:39 AM +0200 12/18/05, Ersin Gulacti wrote:
>Thanks to everybody who sent comments about my question. I have read the
>answers and related RFC's and it seems that SCVP is the only solution to
>learn the status of a certificate at a certain time in the past. However 
I
>find SCVP very complicated and we need only a limited part of the SCVP
>functionality.
>
>We would like to implement a new and simpler protocol to solve our
>problem. This protocol may be called "Certificate History Retrieval
>Protocol". What is the procedure to propose this as a new RFC?
>
>Thanks.
>
>Ersin

The PKIX WG is not likely to accept a new work item of the sort 
described above.  We are trying to wind down the WG, as per the 
direction of the IESG. You could choose to submit such a protocol to 
another WG, maybe LTANS, or make it an individual submission.

Your suggested protocol does not propose new functionality; it offers 
less functionality, and hence, would be nominally simpler. This is an 
understandable motivation, but it needs to be weighed against the 
costs of creating yet another standard, a standard that would offer a 
subset of the functionality of a protocol already developed by an 
extant IETF WG.

Generally, the IETF tries to avoid duplication in standards, which 
argues against this approach, whether pussued in another WG or via an 
individual submission.

Steve





Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id jBJHZsC8060155; Mon, 19 Dec 2005 09:35:54 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id jBJHZscn060154; Mon, 19 Dec 2005 09:35:54 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from boole.openldap.org ([e-mail] [204.152.186.50]) by above.proper.com (8.12.11/8.12.9) with ESMTP id jBJHZrmA060147 for <[e-mail]>; Mon, 19 Dec 2005 09:35:53 -0800 (PST) (envelope-from [e-mail])
Received: from gyspy.OpenLDAP.org (24-205-218-53.dhcp.crcy.nv.charter.com [24.205.218.53] (may be forged)) (authenticated bits=0) by boole.openldap.org (8.13.3/8.13.3) with ESMTP id jBJHZrHW005650 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 19 Dec 2005 17:35:54 GMT (envelope-from [e-mail])
Message-Id: <[e-mail]>
X-Mailer: QUALCOMM Windows Eudora Version 6.2.1.2
Date: Mon, 19 Dec 2005 09:35:20 -0800
To: "Ersin Gulacti" <[e-mail]>
From: "Kurt D. Zeilenga" <[e-mail]>
Subject: RE: Certificate Validity Problem
Cc: [e-mail]
In-Reply-To: <[e-mail]>
References: <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

At 01:12 PM 12/18/2005, Ersin Gulacti wrote:
>You can't use a directory service because you can't use a certificate
>serial number as a filter for an LDAP search.

Actually, one can do this using LDAP Component Matching (RFC 3687].
This standards-track LDAP extension is implemented in at least two
currently shipping LDAP server products.

And, if you also know the issuer, one can use the
certficateExactMatch matching rule [draft-zeilenga-ldap-x509].
This standards-track RFC-to-be is implemented in at least two
currently shipping LDAP server products.  It's to be published
with the revised LDAP TS produced by the LDAPBIS WG.  (Of course,
the X.500 directory service has supported this matching rule for
ages.)

Kurt 



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id jBJGBdMs052275; Mon, 19 Dec 2005 08:11:39 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id jBJGBd42052274; Mon, 19 Dec 2005 08:11:39 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from aragorn.bbn.com (aragorn.bbn.com [128.33.0.62]) by above.proper.com (8.12.11/8.12.9) with ESMTP id jBJGBclt052257 for <[e-mail]>; Mon, 19 Dec 2005 08:11:39 -0800 (PST) (envelope-from [e-mail])
Received: from [128.89.89.106] (dhcp89-089-106.bbn.com [128.89.89.106]) by aragorn.bbn.com (8.12.7/8.12.7) with ESMTP id jBJGBVIE002081; Mon, 19 Dec 2005 11:11:33 -0500 (EST)
Mime-Version: 1.0
Message-Id: <p06230902bfcc78a3d917@[128.89.89.106]>
In-Reply-To: <[e-mail]>
References:     <[e-mail]> <[e-mail]>
Date: Mon, 19 Dec 2005 09:57:43 -0500
To: "Ersin Gulacti" <[e-mail]>
From: Stephen Kent <[e-mail]>
Subject: Re: Certificate Validity Problem
Cc: [e-mail]
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
X-Virus-Scanned: ClamAV version 0.83, clamav-milter version 0.83 on 128.33.1.41
X-Virus-Status: Clean
Sender: [e-mail]
Precedence: 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:39 AM +0200 12/18/05, Ersin Gulacti wrote:
>Thanks to everybody who sent comments about my question. I have read the
>answers and related RFC's and it seems that SCVP is the only solution to
>learn the status of a certificate at a certain time in the past. However I
>find SCVP very complicated and we need only a limited part of the SCVP
>functionality.
>
>We would like to implement a new and simpler protocol to solve our
>problem. This protocol may be called "Certificate History Retrieval
>Protocol". What is the procedure to propose this as a new RFC?
>
>Thanks.
>
>Ersin

The PKIX WG is not likely to accept a new work item of the sort 
described above.  We are trying to wind down the WG, as per the 
direction of the IESG. You could choose to submit such a protocol to 
another WG, maybe LTANS, or make it an individual submission.

Your suggested protocol does not propose new functionality; it offers 
less functionality, and hence, would be nominally simpler. This is an 
understandable motivation, but it needs to be weighed against the 
costs of creating yet another standard, a standard that would offer a 
subset of the functionality of a protocol already developed by an 
extant IETF WG.

Generally, the IETF tries to avoid duplication in standards, which 
argues against this approach, whether pussued in another WG or via an 
individual submission.

Steve



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id jBJBKve8017456; Mon, 19 Dec 2005 03:20:57 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id jBJBKvWs017455; Mon, 19 Dec 2005 03:20:57 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from odin2.bull.net (odin2.bull.net [192.90.70.84]) by above.proper.com (8.12.11/8.12.9) with ESMTP id jBJBKufE017443 for <[e-mail]>; Mon, 19 Dec 2005 03:20:56 -0800 (PST) (envelope-from [e-mail])
Received: from cln-m001.frcl.bull.fr (cln-m001.frcl.bull.fr [129.182.91.40]) by odin2.bull.net (8.9.3/8.9.3) with ESMTP id MAA44028; Mon, 19 Dec 2005 12:38:52 +0100
Importance: Normal
X-Priority: 3 (Normal)
Subject: Re: Certificate Validity Problem
MIME-Version: 1.0
From: [e-mail]
To: Dino Esposito <[e-mail]>
Cc: [e-mail], [e-mail]
Date: Mon, 19 Dec 2005 12:21:48 +0100
Message-ID: <[e-mail]>
X-MIMETrack: Serialize by Router on CLN-M001/FR/BULL(Release 5.0.11  |July 24, 2002) at 12/19/2005 12:21:49 PM
MIME-Version: 1.0
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: base64
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

PEZPTlQgZmFjZT0iRGVmYXVsdCBTYW5zIFNlcmlmLCBWZXJkYW5hLCBBcmlhbCwgSGVsdmV0aWNh
LCBzYW5zLXNlcmlmIiBzaXplPTI+PERJVj4odGV4dCBkZWxldGVkKTwvRElWPjxQPlBhcnRpYWxs
eSB0cnVlOyB3aGVuIGEgZGVlZCBpcyBmaWxlZCB0byBhbiBlR292ZXJubWVudCBzZXJ2aWNlIChq
dXN0IGFuIDxCUj5leGFtcGxlKSBpdCBpcyBwb3NzaWJsZSB0aGF0IHRoZSB2ZXJpZmljYXRpb24g
aGFwcGVucyB3ZWVrcyBvciBtb250aHMgPEJSPmFmdGVyIHRoZSBmaWxpbmcgKHRoaW5rIG9mIGEg
anVkaWNpYXJ5IGxpdGlnYXRpb24pLiA8L1A+PFA+PEZPTlQgY29sb3I9IzAwMDBjYz5bRGVuaXNd
LiBOb3QgcmVhbGx5LiBJdCB3b3VsZCBtZWFuIHJlY2VpdmluZyB0aGUgZG9jdW1lbnQgYW5kIG5v
dCB2ZXJpZnlpbmcgYW55dGhpbmcgPEJSPmFib3V0IHRoZSBzaWduYXR1cmUuPC9GT05UPjwvUD48
UD48Rk9OVCBjb2xvcj0jMDAwMGNjPlNpZ25lZCBkb2N1bWVudHMgTVVTVCBiZSB2ZXJpZmllZCZu
YnNwOyJzaG9ydGx5IiBhZnRlciB0aGV5IGFyZSByZWNlaXZlZC48QlI+PC9GT05UPjxGT05UIGNv
bG9yPSMwMDAwY2M+VGhlbiBhIGRpc3B1dGUgbWF5IGhhcHBlbiB0d28gbW9udGhzIG9yIHR3byB5
ZWFycyBsYXRlciwgYnV0IHRoZSBwcm9vZnMgPEJSPmhhdmUgYmVlbiBjYXB0dXJlZCAob3IgdGhl
IGRvY3VtZW50IGhhcyBhbHJlYWR5IGJlZW4mbmJzcDtyZWplY3RlZCBiZWNhdXNlIGl0IHdhcyBp
bnZhbGlkKS48L0ZPTlQ+PC9QPjxQPjxGT05UIGNvbG9yPSMwMDAwY2M+Jm5ic3A7W0RlbmlzL108
L0ZPTlQ+PC9QPjxQPiAgICAgICAgSW4gdGhpcyBjYXNlIHRoZSA8QlI+dGltZSBvZiB2ZXJpZmlj
YXRpb24gaXMgbWVhbmluZ2xlc3MsIGJ1dCBpdCdzIGltcG9ydGFudCB0aGUgc2lnbmF0dXJlIDxC
Uj50aW1lIGFuZCB0aGUgY2VydGlmaWNhdGlvbiBzdGF0dXMgYXQgdGhhdCB0aW1lLiBTaW5jZSB0
aGUgcHJvdG9jb2xzIDxCUj5kZWZpbmVkIGluIHNvbWUgb3RoZXIgc3RhbmRhcmQgKGkuZS4gRVRT
SSAxMDE3MzMsIHdpdGggYSBzZWxmIHZhbGlkYXRlZCA8QlI+ZW52ZWxvcGUgb3IgU0NWUCkgYXJl
IG5vdCB3aWRlbHkgc3ByZWFkLCB0aGUgcHJvYmxlbSB3aWxsIGJlIGhlcmUuIE1heWJlIDxCUj5h
IG5ldyBwcm90b2NvbCBpcyBvdmVyLWVuZ2luZWVyaW5nLCBidXQgYSBjb21tb24gZ3JvdW5kIHdv
dWxkIGJlIHF1aXRlIDxCUj51c2VmdWw8QlI+PEJSPkFsZnJlZG8gRXNwb3NpdG88QlI+SW5mb0Nh
bWVyZSBTLkMucC5BLjxCUj5JdGFseTxCUj48QlI+Jmd0OyBUaGVyZSBpcyBubyBuZWVkIGZvciBv
dmVyLWVuZ2luZWVyaW5nIGJ5IGRlZmluaW5nIGEgbmV3IHByb3RvY29sLjxCUj4mZ3Q7PEJSPiZn
dDsgRGVuaXM8QlI+Jmd0OzxCUj4mZ3Q7IFdlIHdvdWxkIGxpa2UgdG8gaW1wbGVtZW50IGEgbmV3
IGFuZCBzaW1wbGVyIHByb3RvY29sIHRvIHNvbHZlIG91cjxCUj4mZ3Q7IHByb2JsZW0uIFRoaXMg
cHJvdG9jb2wgbWF5IGJlIGNhbGxlZCAiQ2VydGlmaWNhdGUgSGlzdG9yeSBSZXRyaWV2YWw8QlI+
Jmd0OyBQcm90b2NvbCIuIFdoYXQgaXMgdGhlIHByb2NlZHVyZSB0byBwcm9wb3NlIHRoaXMgYXMg
YSBuZXcgUkZDPzxCUj4mZ3Q7PEJSPiZndDsgVGhhbmtzLjxCUj4mZ3Q7PEJSPiZndDsgRXJzaW48
QlI+Jmd0OzxCUj4mZ3Q7ICZndDs8QlI+Jmd0OyAmZ3Q7IEhlbGxvLDxCUj4mZ3Q7ICZndDs8QlI+
Jmd0OyAmZ3Q7IFdlIGFyZSBvcGVyYXRpbmcgYSBDZXJ0aWZpY2F0ZSBBdXRob3JpdHkgKHdoaWNo
IHVzZXMgb3VyIG93biBDQSA8QlI+Jmd0OyBzb2Z0d2FyZSk8QlI+Jmd0OyAmZ3Q7IGFuZCB3ZSBo
YXZlIGEgcHJvY2VzcyB0byBzZXQgY2VydGlmaWNhdGUgc3RhdHVzIHRvIG9uLWhvbGQuIE93bmVy
cyBvZjxCUj4mZ3Q7ICZndDsgY2VydGlmaWNhdGVzIGNhbiBwdXQgdGhlaXIgY2VydGlmaWNhdGVz
IG9uLWhvbGQgYW5kIHRoZXkgY2FuIHJldHVybiB0aGVtPEJSPiZndDsgJmd0OyB0byB0aGUgdmFs
aWQgc3RhdHVzLjxCUj4mZ3Q7ICZndDs8QlI+Jmd0OyAmZ3Q7IFdoZW4gc29tZWJvZHkgdHJpZXMg
dG8gdmVyaWZ5IHRoZSB2YWxpZGl0eSBvZiBzaWduYXR1cmUgaGUgY2FuIG9ubHkgPEJSPiZndDsg
Y2hlY2s8QlI+Jmd0OyAmZ3Q7IHRoZSBtb3N0IHJlY2VudCBzdGF0dXMgb2YgdGhlIGNlcnRpZmlj
YXRlLiBIZSBjYW4gdXNlIHRoZSBtb3N0IGZyZXNoIENSTDxCUj4mZ3Q7ICZndDsgb3IgZXhlY3V0
ZSBhbiBPQ1NQIHF1ZXJ5LiBCb3RoIG9mIHRoZXNlIHRlY2huaXF1ZXMgbGFjayBhbiBpbXBvcnRh
bnQ8QlI+Jmd0OyAmZ3Q7IGZ1bmN0aW9uYWxpdHksIHlvdSBjYW5ub3QgcXVlcnkgdGhlIHN0YXR1
cyBvZiBhIGNlcnRpZmljYXRlIGF0IGEgY2VydGFpbjxCUj4mZ3Q7ICZndDsgdGltZSBpbiB0aGUg
cGFzdC4gTWF5YmUgYXQgdGhlIHRpbWUgb2Ygc2lnbmluZyB0aGUgY2VydGlmaWNhdGUgdXNlZCB3
YXM8QlI+Jmd0OyAmZ3Q7IG9uLWhvbGQuPEJSPiZndDsgJmd0OzxCUj4mZ3Q7ICZndDsgSXMgdGhl
cmUgYSBtZXRob2Qgb3IgYW5vdGhlciB0ZWNobmlxdWUgdG8gc29sdmUgdGhpcyBwcm9ibGVtPzxC
Uj4mZ3Q7ICZndDs8QlI+Jmd0OyAmZ3Q7IFRoYW5rcy48QlI+Jmd0OyAmZ3Q7PEJSPiZndDs8QlI+
Jmd0OzxCUj4mZ3Q7PEJSPjxCUj48L1A+PC9GT05UPg==



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id jBJBDw0g016655; Mon, 19 Dec 2005 03:13:58 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id jBJBDvRb016654; Mon, 19 Dec 2005 03:13:58 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from odin2.bull.net (odin2.bull.net [192.90.70.84]) by above.proper.com (8.12.11/8.12.9) with ESMTP id jBJBDueS016624 for <[e-mail]>; Mon, 19 Dec 2005 03:13:57 -0800 (PST)
Received: from cln-m001.frcl.bull.fr (cln-m001.frcl.bull.fr [129.182.91.40]) by odin2.bull.net (8.9.3/8.9.3) with ESMTP id MAA60004 for <[e-mail]>; Mon, 19 Dec 2005 12:32:00 +0100
Received: from cln-m001.frcl.bull.fr (cln-m001.frcl.bull.fr [129.182.91.40])	by odin2.bull.net (8.9.3/8.9.3) with ESMTP id LAA31738;	Mon, 19 Dec 2005 11:38:39 +0100
Importance: Normal
X-Priority: 3 (Normal)
Subject: Re: Certificate Validity Problem
MIME-Version: 1.0
From: [e-mail]
MIME-Version: 1.0
X-MIMETrack: Serialize by Router on CLN-M001/FR/BULL(Release 5.0.11  |July 24, 2002) at 12/19/2005 11:21:36 AM, Itemize by SMTP Server on FRN-001/EVIDIAN(Release 5.0.8 |June 18, 2001) at 19/12/2005 11:21:43, Serialize by Router on FRN-001/EVIDIAN(Release 5.0.8 |June 18, 2001) at 19/12/2005 11:21:45, Serialize complete at 19/12/2005 11:21:45, Itemize by SMTP Server on MAIL-HUB/FR/BULL(Release 5.0.8 |June 18, 2001) at 19/12/2005 11:21:45, Serialize by Router on CLN-M001/FR/BULL(Release 5.0.11  |July 24, 2002) at 12/19/2005 12:14:57 PM, Serialize complete at 12/19/2005 12:14:57 PM
To: sravan <[e-mail]>
Cc: [e-mail]
Date: Mon, 19 Dec 2005 12:14:57 +0100
Message-ID: <[e-mail]>
Content-Transfer-Encoding: base64
Content-Type: text/html; 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>

PEZPTlQgZmFjZT0iRGVmYXVsdCBTYW5zIFNlcmlmLCBWZXJkYW5hLCBBcmlhbCwgSGVsdmV0aWNh
LCBzYW5zLXNlcmlmIiBzaXplPTI+PFA+Jmd0OyBQbGVhc2Ugbm90IHRoYXQga25vd2luZyB0aGUg
c3RhdHVzIG9mIGEgY2VydGlmaWNhdGUgaW4gdGhlIHBhc3QgaW4gbm90IDxCUj4mZ3Q7IG5lY2Vz
c2FyeSBpbiBnZW5lcmFsLDxCUj4mZ3Q7IGV4Y2VwdCB3aGVuIHRoZSBzaWduZXJzJ3MgY2VydGlm
aWNhdGUgaXMgY2xvc2UgdG8gaXRzIGV4cGlyYXRpb24gdGltZSwgPEJSPiZndDsgbW9yZSBwcmVj
aXNlbHk8QlI+Jmd0OyBpZiB0aGUgdmVyaWZpY2F0aW9uIGlzIGRvbmUgb25jZSB0aGUgY2VydGlm
aWNhdGUgaGFzIGV4cGlyZWQuIEhvd2V2ZXIsIDxCUj4mZ3Q7IHRoaXMgbGFzdCBjYXNlIHNob3Vs
ZCBub3Qgb2NjdXI8QlI+Jmd0OyBpZiB0aGUgc2lnbmVyIHJlY2VpdmVzIGl0cyBuZXcgY2VydGlm
aWNhdGUgKGUuZy4gb25lIG1vbnRoIGluIGFkdmFuY2UpIDxCUj4mZ3Q7IGFuZCB1c2UgaXQgb25j
ZSByZWNlaXZlZC48QlI+Jmd0OzxCUj4mZ3Q7IFNvbWUgbW9yZSBleHBsYW5hdGlvbnMgYWJvdXQg
dGhlIGdlbmVyYWwgY2FzZTo8QlI+Jmd0OzxCUj4mZ3Q7IDEpIGlmIHRoZSBjZXJ0aWZpY2F0ZSB3
YXMgcmV2b2tlZCBhdCB0aGUgdGltZSBvZiBzaWduYXR1cmUsIGl0IHdpbGwgYmUgPEJSPiZndDsg
YWxzbyByZXZva2VkIGF0IHRoZSB0aW1lIG9mIHRoZSB2ZXJpZmljYXRpb24uPEJSPiZndDsgMikg
aWYgdGhlIGNlcnRpZmljYXRlIHdhcyBzdXNwZW5kZWQsIHRoZW4gaXQgbWF5IHN0aWxsIGJlIHN1
c3BlbmRlZCwgPEJSPiZndDsgb3IgcmV2b2tlZCBvciBub3QgcmV2b2tkZWQgYXQgdGhlIHRpbWUg
b2YgdmVyaWZpaWNhdGlvbi48QlI+Jmd0OyAgICBUaGUgc3RhdHVzIGF0IHRoZSB0aW1lIG9mIHZl
cmlmaWNhdGlvbiBpcyB0aHVzIGJldHRlciBpbiB0aGUgPEJSPiZndDsgZ2VuZXJhbCBjYXNlLjxC
Uj4mZ3Q7PEJSPiZndDsgVGhlcmUgaXMgbm8gbmVlZCBmb3Igb3Zlci1lbmdpbmVlcmluZyBieSBk
ZWZpbmluZyBhIG5ldyBwcm90b2NvbC48QlI+Jmd0OzxCUj4mZ3Q7IERlbmlzPEJSPiZndDs8QlI+
RGVhciBBbGwsPEJSPkkgZmVlbCB0aGF0IGRldGVybWluaW5nIHRoZSBzdGF0dXMgb2YgYSBjZXJ0
aWZpY2F0ZSBhdCBhIGdpdmUgaW5zdGFuY2UgPEJSPmlzIHJlcXVpcmVkIGFuZCB3ZSBuZWVkIHRv
IGhhdmUgYSBzaW1wbGVyIHByb3RvY29sIGZvciBkZXRlcm1pbmluZyBpdC48QlI+SGVyZSBhcmUg
c29tZSBwb2ludHMgc3VwcG9ydGluZyBteSBvcGluaW9uOjxCUj48QlI+VGhpcyhrbm93aW5nIHRo
ZSBzdGF0dXMgb2YgYSBjZXJ0aWZpY2F0ZSBhdCBhIGdpdmUgaW5zdGFuY2UpIGlzIDxCUj5uZWNl
c3NhcnkgaW4gY2FzZXMgd2hlcmUgaW4sIHdlIG5lZWQgdG8gcHJvdmUgdGhlIHZhbGlkaXR5IG9m
IGEgZGlnaXRhbCA8QlI+c2lnbmF0dXJlIGxvbmcgYWZ0ZXIgdGhlIGV4cGlyeSBvZiB0aGUgc2ln
bmVyJ3MgY2VydGlmaWNhdGUuIDwvUD48UD48Rk9OVCBjb2xvcj0jMDAwMGNjPltEZW5pc10gTm8u
IEl0IGlzIG5vdC4gSXQgc3VmZmljaWVudCB0byBjYXB0dXJlIHRoZSBDUkwgb3IgdGhlIE9DU1Ag
cmVzcG9uc2UgPEJSPmF0IHRoZSB0aW1lIG9mIHZlcmlmaWNhdGlvbiBvciBjbG9zZSB0byB0aGUg
dGltZSBvZiB2ZXJpZmljYXRpb24uPC9GT05UPjwvUD48UD48Rk9OVCBjb2xvcj0jMDAwMGNjPkRl
bmlzPC9GT05UPjwvUD48UD4gICAgICAgICBTYXkgYW4gPEJSPmVtcGxveWVlIGFwcHJvdmVzICZh
bXA7IHNpZ25zIGEgZG9jdW1lbnQgYW5kIGFmdGVyIHNvbWUgdGltZSBoZSB0ZXJtaW5hdGVzIDxC
Uj5mcm9tIHRoZSBvcmdhbml6YXRpb247IGJ1dCB3ZSBuZWVkIHRvIHByb3ZlIHRoYXQgdGhlIGRv
Y3VtZW50IHdhcyBpbmZhY3QgPEJSPmFwcHJvdmVkIGFuZCBzaWduZWQgYnkgdGhhdCBwYXJ0aWN1
bGFyIGVtcGxveWVlIGV2ZW4gYWZ0ZXIgYSBsb25nIHRpbWUuIDxCUj5JbiB0aGlzIGNhc2UsIHRo
ZXJlIHdpbGwgbm90IGJlIGFueXRoaW5nIGxpa2UgdGhlIHNpZ25lciBnZXR0aW5nIGhpcyBuZXcg
PEJSPmNlcnRpZmljYXRlIGFzIERlbmlzIGhhcyBtZW50aW9uZWQuPEJSPjxCUj5BbHNvLCBjb25z
aWRlciBhIHNjZW5hcmlvIChhcyBEZW5pcyBoYXMgbWVudGlvbmVkIGluIGNhc2UgMikgd2hlcmUg
aW4sIGEgPEJSPmNlcnRpZmljYXRlIGlzIHN1c3BlbmRlZCBhbmQgYWZ0ZXIgc29tZSB0aW1lIGl0
IGlzIGFjdGl2YXRlZCBhZ2Fpbi48QlI+SW4gdGhpcyBzY2VuYXJpbywgaWYgYSBkaWdpdGFsIHNp
Z25hdHVyZSBpcyBjcmVhdGVkIHdoZW4gdGhlIGNlcnRpZmljYXRlIDxCUj5pcyBzdXNwZW5kZWQg
YW5kIHZlcmlmaWNhdGlvbiBpcyBkb25lIGFmdGVyIHNvbWV0aW1lKHdoZW4gdGhlIDxCUj5jZXJ0
aWZpY2F0ZSBpcyBhY3RpdmF0ZWQpLCB0aGUgZGlnaXRhbCBzaWduYXR1cmUgaXMgYWNjZXB0ZWQg
YWx0aG91Z2ggaXQgPEJSPnNob3VsZG4ndCBiZSB0aGUgY2FzZS48QlI+PEJSPlRoZSBwcm9ibGVt
IGhlcmUgaXMgdGhhdCBkdXJpbmcgY2VydGlmaWNhdGUgdmFsaWRhdGlvbiwgbGF0ZXN0KiA8QlI+
KnJldm9jYXRpb24gaW5mb3JtYXRpb24gaXMgYmVpbmcgdXNlZCBpbnN0ZWFkIG9mIHRoYXQgYXZh
aWxhYmxlIGF0IHRoZSA8QlI+dGltZSBvZiBzaWduaW5nLjxCUj48QlI+U28sIEkgZmVlbCB0aGF0
IHdlIG5lZWQgdG8gaGF2ZSBhIHNpbXBsZSBwcm90b2NvbChzaW1pbGFyIHRvIE9DU1ApLCA8QlI+
d2hpY2ggZ2l2ZXMgdGhlIHN0YXR1cyBvZiBhIGRpZ2l0YWwgY2VydGlmaWNhdGUgYXQgYSBnaXZl
biBpbnN0YW5jZS4gSSA8QlI+ZG9uJ3QgbmVlZCBhbnkgY2VydGlmaWNhdGUgdmFsaWRhdGlvbihh
cyBpcyBkb25lIGluIFNDVlApIHBlciBzZS4gQWxsIEkgPEJSPm5lZWQgaXMsPEJSPnNheSBJIGdp
dmUgdGhlc2UgZmllbGRzIGlkZW50aWZ5aW5nIGEgY2VydGlmaWNhdGUgYW5kIHRoZSB0aW1lIGF0
IHdoaWNoIDxCUj50aGF0IGNlcnRpZmljYXRlJ3Mgc3RhdHVzIGlzIHJlcXVpcmVkOjxCUj4gICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICZsdDtJc3N1ZXJETiwgSXNzdWVyUHVibGljS2V5
LCA8QlI+Q2VydGlmaWNhdGVTZXJpYWxOdW1iZXIsIFRpbWUmZ3Q7PEJSPmkgbmVlZCBhIHJlc3Bv
bnNlIHRlbGxpbmcgdGhlIHN0YXR1cyBvZiB0aGUgaWRlbnRpZmllZCBjZXJ0aWZpY2F0ZSBhdCA8
QlI+dGhlIGdpdmVuIFRpbWUuPEJSPjxCUj4tIFNyYXZhbjxCUj48QlI+UFM6IEluIGFsbCB0aGUg
YWJvdmUgY2FzZXMsIEkgYW0gYXNzdW1pbmcgdGhhdCBzaWduYXR1cmUgdGltZS1zdGFtcCBpcyA8
QlI+ZG9uZSBzbyB0aGF0IG9uZSBjYW4gZGV0ZXJtaW5lIHRoZSBzaWduaW5nIHRpbWUgaW4gYSB0
cnVzdGVkIHdheS48QlI+PEJSPjxCUj48L1A+PC9GT05UPg==



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id jBJ9og69007078; Mon, 19 Dec 2005 01:50:42 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id jBJ9ogIc007077; Mon, 19 Dec 2005 01:50:42 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from lxme02.infocamere.it (lxme02.infocamere.it [80.82.0.240]) by above.proper.com (8.12.11/8.12.9) with ESMTP id jBJ9oelC007067 for <[e-mail]>; Mon, 19 Dec 2005 01:50:41 -0800 (PST) (envelope-from [e-mail])
Received: from lxm07.intra.infocamere.it (lxm07.intra.infocamere.it [1.5.72.7]) by lxme02.infocamere.it (8.13.4/8.13.4) with ESMTP id jBJ9o0Ns015971; Mon, 19 Dec 2005 10:50:02 +0100
Received: from lxm07.intra.infocamere.it (IDENT:U2FsdGVkX1/[e-mail] [127.0.0.1]) by lxm07.intra.infocamere.it (8.12.11/8.12.11) with ESMTP id jBJ9o0cn021571; Mon, 19 Dec 2005 10:50:00 +0100
Received: from [1.71.4.82] (IC2300323.ic.intra.infocamere.it [1.71.4.82]) (authenticated bits=0) by lxm07.intra.infocamere.it (8.12.11/8.12.11) with ESMTP id jBJ9o0SJ021566; Mon, 19 Dec 2005 10:50:00 +0100
Message-ID: <[e-mail]>
Date: Mon, 19 Dec 2005 10:49:59 +0100
From: Dino Esposito <[e-mail]>
User-Agent: Mozilla Thunderbird 1.0.7 (Windows/20050923)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: [e-mail]
CC: Ersin Gulacti <[e-mail]>, [e-mail]
Subject: Re: Certificate Validity Problem
References: <[e-mail]>
In-Reply-To: <[e-mail]>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Virus-Scanned: ClamAV version 0.87.1, clamav-milter version 0.87 on localhost
X-Virus-Status: Clean
X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-2.0 (lxme02.infocamere.it [80.82.0.240]); Mon, 19 Dec 2005 10:50:03 +0100 (CET)
Sender: [e-mail]
Precedence: 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] wrote:

> Thanks to everybody who sent comments about my question. I have read the
> answers and related RFC's and it seems that SCVP is the only solution to
> learn the status of a certificate at a certain time in the past. However I
> find SCVP very complicated and we need only a limited part of the SCVP
> functionality.
>
> Please not that knowing the status of a certificate in the past in not 
> necessary in general,
> except when the signers's certificate is close to its expiration time, 
> more precisely
> if the verification is done once the certificate has expired. However, 
> this last case should not occur
> if the signer receives its new certificate (e.g. one month in advance) 
> and use it once received.
>
> Some more explanations about the general case:
>
> 1) if the certificate was revoked at the time of signature, it will be 
> also revoked at the time of the verification.
> 2) if the certificate was suspended, then it may still be suspended, 
> or revoked or not revokded at the time of verifiication.
>    The status at the time of verification is thus better in the 
> general case.
>
Partially true; when a deed is filed to an eGovernment service (just an 
example) it is possible that the verification happens weeks or months 
after the filing (think of a judiciary litigation). In this case the 
time of verification is meaningless, but it's important the signature 
time and the certification status at that time. Since the protocols 
defined in some other standard (i.e. ETSI 101733, with a self validated 
envelope or SCVP) are not widely spread, the problem will be here. Maybe 
a new protocol is over-engineering, but a common ground would be quite 
useful

Alfredo Esposito
InfoCamere S.C.p.A.
Italy

> There is no need for over-engineering by defining a new protocol.
>
> Denis
>
> We would like to implement a new and simpler protocol to solve our
> problem. This protocol may be called "Certificate History Retrieval
> Protocol". What is the procedure to propose this as a new RFC?
>
> Thanks.
>
> Ersin
>
> >
> > Hello,
> >
> > We are operating a Certificate Authority (which uses our own CA 
> software)
> > and we have a process to set certificate status to on-hold. Owners of
> > certificates can put their certificates on-hold and they can return them
> > to the valid status.
> >
> > When somebody tries to verify the validity of signature he can only 
> check
> > the most recent status of the certificate. He can use the most fresh CRL
> > or execute an OCSP query. Both of these techniques lack an important
> > functionality, you cannot query the status of a certificate at a certain
> > time in the past. Maybe at the time of signing the certificate used was
> > on-hold.
> >
> > Is there a method or another technique to solve this problem?
> >
> > Thanks.
> >
>
>
>



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id jBJ9Plkw004006; Mon, 19 Dec 2005 01:25:47 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id jBJ9PlJ4004005; Mon, 19 Dec 2005 01:25:47 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from atcmail.atc.tcs.co.in (atcmail.atc.tcs.co.in [203.200.212.145]) by above.proper.com (8.12.11/8.12.9) with ESMTP id jBJ9Pets003969 for <[e-mail]>; Mon, 19 Dec 2005 01:25:42 -0800 (PST) (envelope-from [e-mail])
Received: from [127.0.0.1] (sravan.atc.tcs.co.in [172.19.58.128]) by atcmail.atc.tcs.co.in (8.12.11/8.12.11) with ESMTP id jBJ9PXia020641; Mon, 19 Dec 2005 14:55:33 +0530
Message-ID: <[e-mail]>
Date: Mon, 19 Dec 2005 14:55:32 +0530
From: sravan <[e-mail]>
User-Agent: Mozilla Thunderbird 0.7 (Windows/20040616)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: [e-mail]
CC: [e-mail]
Subject: Re: Certificate Validity Problem
References: <[e-mail]>
In-Reply-To: <[e-mail]>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Virus-Scanned: ClamAV version 0.87, clamav-milter version 0.87 on atcmail.atc.tcs.co.in
X-Virus-Status: Clean
Sender: [e-mail]
Precedence: 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] wrote:

> Please not that knowing the status of a certificate in the past in not 
> necessary in general,
> except when the signers's certificate is close to its expiration time, 
> more precisely
> if the verification is done once the certificate has expired. However, 
> this last case should not occur
> if the signer receives its new certificate (e.g. one month in advance) 
> and use it once received.
>
> Some more explanations about the general case:
>
> 1) if the certificate was revoked at the time of signature, it will be 
> also revoked at the time of the verification.
> 2) if the certificate was suspended, then it may still be suspended, 
> or revoked or not revokded at the time of verifiication.
>    The status at the time of verification is thus better in the 
> general case.
>
> There is no need for over-engineering by defining a new protocol.
>
> Denis
>
Dear All,
I feel that determining the status of a certificate at a give instance 
is required and we need to have a simpler protocol for determining it.
Here are some points supporting my opinion:

This(knowing the status of a certificate at a give instance) is 
necessary in cases where in, we need to prove the validity of a digital 
signature long after the expiry of the signer's certificate. Say an 
employee approves & signs a document and after some time he terminates 
from the organization; but we need to prove that the document was infact 
approved and signed by that particular employee even after a long time. 
In this case, there will not be anything like the signer getting his new 
certificate as Denis has mentioned.

Also, consider a scenario (as Denis has mentioned in case 2) where in, a 
certificate is suspended and after some time it is activated again.
In this scenario, if a digital signature is created when the certificate 
is suspended and verification is done after sometime(when the 
certificate is activated), the digital signature is accepted although it 
shouldn't be the case.

The problem here is that during certificate validation, latest* 
*revocation information is being used instead of that available at the 
time of signing.

So, I feel that we need to have a simple protocol(similar to OCSP), 
which gives the status of a digital certificate at a given instance. I 
don't need any certificate validation(as is done in SCVP) per se. All I 
need is,
say I give these fields identifying a certificate and the time at which 
that certificate's status is required:
                                <IssuerDN, IssuerPublicKey, 
CertificateSerialNumber, Time>
i need a response telling the status of the identified certificate at 
the given Time.

- Sravan

PS: In all the above cases, I am assuming that signature time-stamp is 
done so that one can determine the signing time in a trusted way.




Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id jBJ8ZxhX099056; Mon, 19 Dec 2005 00:35:59 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id jBJ8Zwk7099055; Mon, 19 Dec 2005 00:35:59 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from odin2.bull.net (odin2.bull.net [192.90.70.84]) by above.proper.com (8.12.11/8.12.9) with ESMTP id jBJ8Zv9Z099044 for <[e-mail]>; Mon, 19 Dec 2005 00:35:58 -0800 (PST) (envelope-from [e-mail])
Received: from cln-m001.frcl.bull.fr (cln-m001.frcl.bull.fr [129.182.91.40]) by odin2.bull.net (8.9.3/8.9.3) with ESMTP id JAA33154; Mon, 19 Dec 2005 09:53:56 +0100
Importance: Normal
X-Priority: 3 (Normal)
Subject: Re: Certificate Validity Problem
MIME-Version: 1.0
From: [e-mail]
To: "Ersin Gulacti" <[e-mail]>
Cc: [e-mail]
Date: Mon, 19 Dec 2005 09:36:52 +0100
Message-ID: <[e-mail]>
X-MIMETrack: Serialize by Router on CLN-M001/FR/BULL(Release 5.0.11  |July 24, 2002) at 12/19/2005 09:36:54 AM
MIME-Version: 1.0
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: base64
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

PEZPTlQgZmFjZT0iRGVmYXVsdCBTYW5zIFNlcmlmLCBWZXJkYW5hLCBBcmlhbCwgSGVsdmV0aWNh
LCBzYW5zLXNlcmlmIiBzaXplPTI+PFA+VGhhbmtzIHRvIGV2ZXJ5Ym9keSB3aG8gc2VudCBjb21t
ZW50cyBhYm91dCBteSBxdWVzdGlvbi4gSSBoYXZlIHJlYWQgdGhlPEJSPmFuc3dlcnMgYW5kIHJl
bGF0ZWQgUkZDJ3MgYW5kIGl0IHNlZW1zIHRoYXQgU0NWUCBpcyB0aGUgb25seSBzb2x1dGlvbiB0
bzxCUj5sZWFybiB0aGUgc3RhdHVzIG9mIGEgY2VydGlmaWNhdGUgYXQgYSBjZXJ0YWluIHRpbWUg
aW4gdGhlIHBhc3QuIEhvd2V2ZXIgSTxCUj5maW5kIFNDVlAgdmVyeSBjb21wbGljYXRlZCBhbmQg
d2UgbmVlZCBvbmx5IGEgbGltaXRlZCBwYXJ0IG9mIHRoZSBTQ1ZQPEJSPmZ1bmN0aW9uYWxpdHku
PC9QPjxQPjxGT05UIGNvbG9yPSMwMDAwY2M+UGxlYXNlIG5vdCB0aGF0IGtub3dpbmcgdGhlIHN0
YXR1cyBvZiBhIGNlcnRpZmljYXRlIGluIHRoZSBwYXN0IGluIG5vdCBuZWNlc3NhcnkgaW4gZ2Vu
ZXJhbCw8QlI+ZXhjZXB0IHdoZW4mbmJzcDt0aGUgc2lnbmVycydzIGNlcnRpZmljYXRlIGlzIGNs
b3NlIHRvIGl0cyZuYnNwO2V4cGlyYXRpb24gdGltZSwgbW9yZSBwcmVjaXNlbHk8QlI+PC9GT05U
PjxGT05UIGNvbG9yPSMwMDAwY2M+aWYgdGhlIHZlcmlmaWNhdGlvbiBpcyBkb25lIG9uY2UmbmJz
cDt0aGUgY2VydGlmaWNhdGUgaGFzIGV4cGlyZWQuIEhvd2V2ZXIsIHRoaXMgbGFzdCBjYXNlIHNo
b3VsZCBub3Qgb2NjdXI8QlI+aWYgdGhlIHNpZ25lciByZWNlaXZlcyBpdHMgbmV3IGNlcnRpZmlj
YXRlIDwvRk9OVD48Rk9OVCBjb2xvcj0jMDAwMGNjPihlLmcuIG9uZSBtb250aCBpbiBhZHZhbmNl
KSBhbmQgdXNlIGl0IG9uY2UgcmVjZWl2ZWQuPC9GT05UPjwvUD48UD48Rk9OVCBjb2xvcj0jMDAw
MGNjPlNvbWUgbW9yZSBleHBsYW5hdGlvbnMgYWJvdXQgdGhlIGdlbmVyYWwgY2FzZTo8L0ZPTlQ+
PC9QPjxQPjxGT05UIGNvbG9yPSMwMDAwY2M+MSkgaWYgdGhlIGNlcnRpZmljYXRlIHdhcyByZXZv
a2VkIGF0IHRoZSB0aW1lIG9mIHNpZ25hdHVyZSwgaXQgd2lsbCBiZSBhbHNvIHJldm9rZWQgYXQg
dGhlIHRpbWUgb2YgdGhlIHZlcmlmaWNhdGlvbi48QlI+PC9GT05UPjxGT05UIGNvbG9yPSMwMDAw
Y2M+MikgaWYgdGhlIGNlcnRpZmljYXRlIHdhcyBzdXNwZW5kZWQsIHRoZW4gaXQgbWF5IHN0aWxs
IGJlIHN1c3BlbmRlZCwgb3IgcmV2b2tlZCBvciBub3QgcmV2b2tkZWQgYXQgdGhlIHRpbWUgb2Yg
dmVyaWZpaWNhdGlvbi4gPEJSPiZuYnNwOyZuYnNwOyBUaGUmbmJzcDtzdGF0dXMgYXQgdGhlIHRp
bWUgb2YgdmVyaWZpY2F0aW9uIGlzIHRodXMgYmV0dGVyIGluIHRoZSBnZW5lcmFsIGNhc2UuPC9G
T05UPjwvUD48UD48Rk9OVCBjb2xvcj0jMDAwMGNjPlRoZXJlIGlzIG5vIG5lZWQgZm9yIG92ZXIt
ZW5naW5lZXJpbmcgYnkgZGVmaW5pbmcmbmJzcDthIG5ldyBwcm90b2NvbC48L0ZPTlQ+PC9QPjxQ
PjxGT05UIGNvbG9yPSMwMDAwY2M+RGVuaXM8L0ZPTlQ+PC9QPjxQPldlIHdvdWxkIGxpa2UgdG8g
aW1wbGVtZW50IGEgbmV3IGFuZCBzaW1wbGVyIHByb3RvY29sIHRvIHNvbHZlIG91cjxCUj5wcm9i
bGVtLiBUaGlzIHByb3RvY29sIG1heSBiZSBjYWxsZWQgIkNlcnRpZmljYXRlIEhpc3RvcnkgUmV0
cmlldmFsPEJSPlByb3RvY29sIi4gV2hhdCBpcyB0aGUgcHJvY2VkdXJlIHRvIHByb3Bvc2UgdGhp
cyBhcyBhIG5ldyBSRkM/PEJSPjxCUj5UaGFua3MuPEJSPjxCUj5FcnNpbjxCUj48QlI+Jmd0OzxC
Uj4mZ3Q7IEhlbGxvLDxCUj4mZ3Q7PEJSPiZndDsgV2UgYXJlIG9wZXJhdGluZyBhIENlcnRpZmlj
YXRlIEF1dGhvcml0eSAod2hpY2ggdXNlcyBvdXIgb3duIENBIHNvZnR3YXJlKTxCUj4mZ3Q7IGFu
ZCB3ZSBoYXZlIGEgcHJvY2VzcyB0byBzZXQgY2VydGlmaWNhdGUgc3RhdHVzIHRvIG9uLWhvbGQu
IE93bmVycyBvZjxCUj4mZ3Q7IGNlcnRpZmljYXRlcyBjYW4gcHV0IHRoZWlyIGNlcnRpZmljYXRl
cyBvbi1ob2xkIGFuZCB0aGV5IGNhbiByZXR1cm4gdGhlbTxCUj4mZ3Q7IHRvIHRoZSB2YWxpZCBz
dGF0dXMuPEJSPiZndDs8QlI+Jmd0OyBXaGVuIHNvbWVib2R5IHRyaWVzIHRvIHZlcmlmeSB0aGUg
dmFsaWRpdHkgb2Ygc2lnbmF0dXJlIGhlIGNhbiBvbmx5IGNoZWNrPEJSPiZndDsgdGhlIG1vc3Qg
cmVjZW50IHN0YXR1cyBvZiB0aGUgY2VydGlmaWNhdGUuIEhlIGNhbiB1c2UgdGhlIG1vc3QgZnJl
c2ggQ1JMPEJSPiZndDsgb3IgZXhlY3V0ZSBhbiBPQ1NQIHF1ZXJ5LiBCb3RoIG9mIHRoZXNlIHRl
Y2huaXF1ZXMgbGFjayBhbiBpbXBvcnRhbnQ8QlI+Jmd0OyBmdW5jdGlvbmFsaXR5LCB5b3UgY2Fu
bm90IHF1ZXJ5IHRoZSBzdGF0dXMgb2YgYSBjZXJ0aWZpY2F0ZSBhdCBhIGNlcnRhaW48QlI+Jmd0
OyB0aW1lIGluIHRoZSBwYXN0LiBNYXliZSBhdCB0aGUgdGltZSBvZiBzaWduaW5nIHRoZSBjZXJ0
aWZpY2F0ZSB1c2VkIHdhczxCUj4mZ3Q7IG9uLWhvbGQuPEJSPiZndDs8QlI+Jmd0OyBJcyB0aGVy
ZSBhIG1ldGhvZCBvciBhbm90aGVyIHRlY2huaXF1ZSB0byBzb2x2ZSB0aGlzIHByb2JsZW0/PEJS
PiZndDs8QlI+Jmd0OyBUaGFua3MuPEJSPiZndDs8QlI+PEJSPjxCUj48QlI+PC9QPjwvRk9OVD4=



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id jBILFxuB028680; Sun, 18 Dec 2005 13:15:59 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id jBILFxAJ028679; Sun, 18 Dec 2005 13:15:59 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from uekae.uekae.gov.tr ([193.140.74.2]) by above.proper.com (8.12.11/8.12.9) with ESMTP id jBILFqk5028656 for <[e-mail]>; Sun, 18 Dec 2005 13:15:57 -0800 (PST) (envelope-from [e-mail])
Received: from www.uekae.tubitak.gov.tr (hitit.uekae.tubitak.gov.tr [192.168.5.6]) by uekae.uekae.gov.tr (UEKAE_MAIL_SERVER_V4) with ESMTP id 4A6E6490165 for <[e-mail]>; Sun, 18 Dec 2005 23:08:27 +0200 (EET)
Received: from 85.102.77.163 (SquirrelMail authenticated user egulacti) by www.uekae.tubitak.gov.tr with HTTP; Sun, 18 Dec 2005 23:12:47 +0200 (EET)
Date: Sun, 18 Dec 2005 23:12:47 +0200 (EET)
Subject: RE: Certificate Validity Problem
From: "Ersin Gulacti" <[e-mail]>
To: [e-mail]
MIME-Version: 1.0
Content-Type: text/plain;charset=iso-8859-9
X-Priority: 3 (Normal)
Importance: Normal
Message-Id: <[e-mail]>
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id jBILFxk5028673
Sender: [e-mail]
Precedence: 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 reply to my recent post Anders Rundgren proposed the following

> If you really want to create something new in this area, why
> not create this "Monitor This Certificate" protocol?  Such
> a protocol would send an alert to all "subscribers"
> the_moment_it_has_been_found_out  that a key was on the loose.
> This seems to be a more "proactive" approach than SCVP (which
> requires constant polling in order to achieve something similar).

I couldn't reply him in private so I am writing in public (email bounces
back). The proactive approach might help users who are aware of the
situation but users who are not aware of the revoked or suspended
(on-hold) certificate problems will not subscribe to such a service and
will not receive notifications. On the other hand think of a very large
PKI implementation with more than 100K users. In such a system you will be
distracted by the email notifications sent by the CA notification service.
After sometime you will start ignoring and deleting such notifications.

In my opinion "Certificate History Retrieval Protocol" could be very
useful in two areas. One area is to retrieve a certificate from the CA by
using the certificates' serial number. This is very helpful if you want to
track the list of users who are capable of deciphering an enciphered file.
You can't use a directory service because you can't use a certificate
serial number as a filter for an LDAP search. (Actually we have
implemented this functionality as a service in our CA software.)

The other area is to track the full history of the certificate. You can
query the "Certificate History Retrieval Service" with a specific
certificate serial number and the service will return you a full list of
history records for that certificate. The response from the service should
be signed by the CA. This trusted information can be used by many
participants of the PKI: end users who do the full certificate validation,
SCVP services etc.

I would like to learn the procedure of writing this as an RFC proposal.
Would it be enough to convince the members of this mail-list ? :)






Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id jBIEiueB098539; Sun, 18 Dec 2005 06:44:56 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id jBIEiuxn098538; Sun, 18 Dec 2005 06:44:56 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from EXVS01.ex.dslextreme.net (netblock-66.51.199.51.dslextreme.com [66.51.199.51] (may be forged)) by above.proper.com (8.12.11/8.12.9) with ESMTP id jBIEiomd098526 for <[e-mail]>; Sun, 18 Dec 2005 06:44:50 -0800 (PST) (envelope-from [e-mail])
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Subject: RE: Certificate Validity Problem
Date: Sun, 18 Dec 2005 06:49:55 -0800
Message-ID: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: Certificate Validity Problem
Thread-Index: AcYDwf4VNC4WgRoGTqeYfXNJfuW8tgAH1/TQ
From: "Carl Wallace" <[e-mail]>
To: "Ersin Gulacti" <[e-mail]>, <[e-mail]>
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id jBIEiomd098529
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

An upcoming LTANS I-D will define a few directory attributes used to
store historical certificates and/or historical certificates with
corresponding EvidenceRecord structures. 

> -----Original Message-----
> From: [e-mail] 
> [mailto:[e-mail]] On Behalf Of Ersin Gulacti
> Sent: Sunday, December 18, 2005 4:40 AM
> To: [e-mail]
> Subject: Re: Certificate Validity Problem
> 
> 
> Thanks to everybody who sent comments about my question. I 
> have read the answers and related RFC's and it seems that 
> SCVP is the only solution to learn the status of a 
> certificate at a certain time in the past. However I find 
> SCVP very complicated and we need only a limited part of the 
> SCVP functionality.
> 
> We would like to implement a new and simpler protocol to 
> solve our problem. This protocol may be called "Certificate 
> History Retrieval Protocol". What is the procedure to propose 
> this as a new RFC?
> 
> Thanks.
> 
> Ersin
> 
> >
> > Hello,
> >
> > We are operating a Certificate Authority (which uses our own CA 
> > software) and we have a process to set certificate status 
> to on-hold. 
> > Owners of certificates can put their certificates on-hold 
> and they can 
> > return them to the valid status.
> >
> > When somebody tries to verify the validity of signature he can only 
> > check the most recent status of the certificate. He can use 
> the most 
> > fresh CRL or execute an OCSP query. Both of these 
> techniques lack an 
> > important functionality, you cannot query the status of a 
> certificate 
> > at a certain time in the past. Maybe at the time of signing the 
> > certificate used was on-hold.
> >
> > Is there a method or another technique to solve this problem?
> >
> > Thanks.
> >
> 
> 
> 
> 



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id jBI9h6cF073987; Sun, 18 Dec 2005 01:43:06 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id jBI9h66r073986; Sun, 18 Dec 2005 01:43:06 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from uekae.uekae.gov.tr (uekaegateway.mam.gov.tr [193.140.74.2]) by above.proper.com (8.12.11/8.12.9) with ESMTP id jBI9h2gx073968 for <[e-mail]>; Sun, 18 Dec 2005 01:43:05 -0800 (PST) (envelope-from [e-mail])
Received: from www.uekae.tubitak.gov.tr (hitit.uekae.tubitak.gov.tr [192.168.5.6]) by uekae.uekae.gov.tr (UEKAE_MAIL_SERVER_V4) with ESMTP id D7AB9490165 for <[e-mail]>; Sun, 18 Dec 2005 11:35:37 +0200 (EET)
Received: from 81.212.105.151 (SquirrelMail authenticated user egulacti) by www.uekae.tubitak.gov.tr with HTTP; Sun, 18 Dec 2005 11:39:57 +0200 (EET)
In-Reply-To:  <[e-mail]>
References:  <[e-mail]>
Date: Sun, 18 Dec 2005 11:39:57 +0200 (EET)
Subject: Re: Certificate Validity Problem
From: "Ersin Gulacti" <[e-mail]>
To: [e-mail]
MIME-Version: 1.0
Content-Type: text/plain;charset=iso-8859-9
X-Priority: 3 (Normal)
Importance: Normal
Message-Id: <[e-mail]>
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id jBI9h5gx073981
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Thanks to everybody who sent comments about my question. I have read the
answers and related RFC's and it seems that SCVP is the only solution to
learn the status of a certificate at a certain time in the past. However I
find SCVP very complicated and we need only a limited part of the SCVP
functionality.

We would like to implement a new and simpler protocol to solve our
problem. This protocol may be called "Certificate History Retrieval
Protocol". What is the procedure to propose this as a new RFC?

Thanks.

Ersin

>
> Hello,
>
> We are operating a Certificate Authority (which uses our own CA software)
> and we have a process to set certificate status to on-hold. Owners of
> certificates can put their certificates on-hold and they can return them
> to the valid status.
>
> When somebody tries to verify the validity of signature he can only check
> the most recent status of the certificate. He can use the most fresh CRL
> or execute an OCSP query. Both of these techniques lack an important
> functionality, you cannot query the status of a certificate at a certain
> time in the past. Maybe at the time of signing the certificate used was
> on-hold.
>
> Is there a method or another technique to solve this problem?
>
> Thanks.
>





Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id jBGNcVZ7099095; Fri, 16 Dec 2005 15:38:31 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id jBGNcVbu099094; Fri, 16 Dec 2005 15:38:31 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from aragorn.bbn.com (aragorn.bbn.com [128.33.0.62]) by above.proper.com (8.12.11/8.12.9) with ESMTP id jBGNcUnK099063 for <[e-mail]>; Fri, 16 Dec 2005 15:38:30 -0800 (PST) (envelope-from [e-mail])
Received: from [128.89.89.106] (dhcp89-089-106.bbn.com [128.89.89.106]) by aragorn.bbn.com (8.12.7/8.12.7) with ESMTP id jBGNcMII010834 for <[e-mail]>; Fri, 16 Dec 2005 18:38:25 -0500 (EST)
Mime-Version: 1.0
Message-Id: <p06230912bfc8efa82962@[128.89.89.106]>
Date: Fri, 16 Dec 2005 17:31:56 -0500
To: [e-mail]
From: Stephen Kent <[e-mail]>
Subject: last call closed
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
X-Virus-Scanned: ClamAV version 0.83, clamav-milter version 0.83 on 128.33.1.41
X-Virus-Status: Clean
Sender: [e-mail]
Precedence: 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,

I saw no last call comments on the I-D: 
draft-ietf-pkix-gost-cppk-03.txt. As a result we will pass this to 
the IESG as a PKIX-approved document.

Affer further discussion with several parties, I have suggested to 
the authors that this be a Standards Track (vs. Informational) RFC. 
The algorithms are Russian de jure standards and, as such, warrant 
this status, in my opinion. This is consistent with the standards 
track status for the use of these algorithms in S/MIME, where an 
analogous document has just been approved.

If anyone objects to this proposed change to the I-D's status, let me 
know before the end of next week.

Thanks,

Steve



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id jBG1gSki043837; Thu, 15 Dec 2005 17:42:28 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id jBG1gS2Z043836; Thu, 15 Dec 2005 17:42:28 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) by above.proper.com (8.12.11/8.12.9) with ESMTP id jBG1gRi3043827 for <[e-mail]>; Thu, 15 Dec 2005 17:42:27 -0800 (PST) (envelope-from [e-mail])
Received: from ISI.EDU (adma.isi.edu [128.9.160.239]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id jBG1fBe01378; Thu, 15 Dec 2005 17:41:11 -0800 (PST)
Message-Id: <[e-mail]>
To: [e-mail]
Subject: RFC 4325 on Internet X.509 Public Key Infrastructure Authority Information Access Certificate Revocation List (CRL) Extension
Cc: [e-mail], [e-mail]
From: [e-mail]
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary=NextPart
Date: Thu, 15 Dec 2005 17:41:11 -0800
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: [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>

--NextPart


A new Request for Comments is now available in online RFC libraries.


        RFC 4325

        Title:      Internet X.509 Public Key Infrastructure Authority
                    Information Access Certificate Revocation List
                    (CRL) Extension
        Author(s):  S. Santesson, R. Housley
        Status:     Standards Track
        Date:       December 2005
        Mailbox:    [e-mail], [e-mail]
        Pages:      7
        Characters: 14449
        Updates:    3280

        I-D Tag:    draft-ietf-pkix-crlaia-03.txt

        URL:        ftp://ftp.rfc-editor.org/in-notes/rfc4325.txt


This document updates RFC 3280 by defining the Authority Information
Access Certificate Revocation List (CRL) extension.  RFC 3280 defines
the Authority Information Access certificate extension using the same
syntax.  The CRL extension provides a means of discovering and
retrieving CRL issuer certificates.

This document is a product of the Public-Key Infrastructure (X.509)
Working Group of the IETF.

This is now a Proposed Standard Protocol.

This document specifies an Internet standards track protocol for
the Internet community, and requests discussion and suggestions
for improvements.  Please refer to the current edition of the
"Internet Official Protocol Standards" (STD 1) for the
standardization state and status of this protocol.  Distribution
of this memo is unlimited.

This announcement is sent to the IETF list and the RFC-DIST list.
Requests to be added to or deleted from the IETF distribution list
should be sent to [e-mail].  Requests to be
added to or deleted from the RFC-DIST distribution list should
be sent to [e-mail].

Details on obtaining RFCs via FTP or EMAIL may be obtained by sending
an EMAIL message to [e-mail] with the message body 
help: ways_to_get_rfcs.  For example:

        To: [e-mail]
        Subject: getting rfcs

        help: ways_to_get_rfcs

Requests for special distribution should be addressed to either the
author of the RFC in question, or to [e-mail].  Unless
specifically noted otherwise on the RFC itself, all RFCs are for
unlimited distribution.

Submissions for Requests for Comments should be sent to
[e-mail].  Please consult RFC 2223, Instructions to RFC
Authors, for further information.


Joyce K. Reynolds and Sandy Ginoza
USC/Information Sciences Institute

...

Below is the data which will enable a MIME compliant Mail Reader 
implementation to automatically retrieve the ASCII version
of the RFCs.

--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"

--OtherAccess
Content-Type:  Message/External-body;
        access-type="mail-server";
        server="[e-mail]"

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

RETRIEVE: rfc
DOC-ID: rfc4325

--OtherAccess
Content-Type:   Message/External-body;
        name="rfc4325.txt";
        site="ftp.isi.edu";
        access-type="anon-ftp";
        directory="in-notes"

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

--OtherAccess--
--NextPart--



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id jBCCcl0b033853; Mon, 12 Dec 2005 04:38:47 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id jBCCclXc033852; Mon, 12 Dec 2005 04:38:47 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from emx2.cybertrust.com (emx2.cybertrust.com [64.209.238.45]) by above.proper.com (8.12.11/8.12.9) with ESMTP id jBCCckDl033842 for <[e-mail]>; Mon, 12 Dec 2005 04:38:46 -0800 (PST) (envelope-from [e-mail])
Received: by emx2.cybertrust.com (ESMTP, from userid 414) id 5CA32F6; Mon, 12 Dec 2005 07:38:40 -0500 (EST)
X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0
Content-class: urn:content-classes:message
MIME-Version: 1.0
Subject: RE: again: pmiUser ...
Date: Mon, 12 Dec 2005 07:38:39 -0500
Content-Type: multipart/signed; micalg=SHA1; protocol="application/x-pkcs7-signature"; boundary="----=_NextPart_000_0000_01C5FEDE.4D557C50"
Message-ID: <[e-mail]>
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator: 
Thread-Topic: again: pmiUser ...
Thread-Index: AcX+m9nmZsEPaHFxQnGuXnsU3kr2YQAfPupA
From: "Weiser, Russ" <[e-mail]>
To: "Keutel, Jochen" <[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>

This is a multi-part message in MIME format.

------=_NextPart_000_0000_01C5FEDE.4D557C50
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit

I would think userCertificate Its multivalued but the application will need
to determine which certificate is which. 

Russel F Weiser 
PKI SME 
Cybertrust Inc 
8708 S Diamond Dove Drive 
West Jordan, UT 84088 
[e-mail]
801-255-8078 Home Office
801-631-1685 Cell 
443-367-7011 Office Columbia MD
 
-----Original Message-----
From: [e-mail] [mailto:[e-mail]] On
Behalf Of Keutel, Jochen
Sent: Sunday, December 11, 2005 2:17 PM
To: [e-mail]
Subject: again: pmiUser ...


Hello,
   I didn't get any answer on the question I asked some days ago
(see below). So, let me ask this as follows:

Do you store attribute certificates in LDAP directories? If so:
Which object class are you using?

Bye, Jochen.

---

Hello,
   X.509 defines the LDAP object class pmiUser and the
attribute attributeCertificateAttribute.

I can't find these definitions in LDAP RFCs oder non-expired drafts ...
I found

http://tools.ietf.org/wg/pkix/draft-ietf-pkix-ldap-pmi-schema/draft-ietf-pki
x-ldap-pmi-schema-00.txt

- but it's from June, 2002 ...

Did I miss an I-D and/or RFC?

Regards,  Jochen.


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

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIGvTCCA1kw
ggLCoAMCAQICDjSgAAEAAjb19xqzoj4nMA0GCSqGSIb3DQEBBAUAMIG8MQswCQYDVQQGEwJERTEQ
MA4GA1UECBMHSGFtYnVyZzEQMA4GA1UEBxMHSGFtYnVyZzE6MDgGA1UEChMxVEMgVHJ1c3RDZW50
ZXIgZm9yIFNlY3VyaXR5IGluIERhdGEgTmV0d29ya3MgR21iSDEiMCAGA1UECxMZVEMgVHJ1c3RD
ZW50ZXIgQ2xhc3MgMSBDQTEpMCcGCSqGSIb3DQEJARYaY2VydGlmaWNhdGVAdHJ1c3RjZW50ZXIu
ZGUwHhcNMDUwNTE3MjAwOTU4WhcNMDYwNTE3MjAwOTU4WjBQMQswCQYDVQQGEwJVUzEWMBQGA1UE
AxMNUnVzc2VsIFdlaXNlcjEpMCcGCSqGSIb3DQEJARYacnVzcy53ZWlzZXJAY3liZXJ0cnVzdC5j
b20wgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBALQAr/P4rCOf4LIqGPdisgrgCzlV1+8ii5Rs
HhaP445tXWWQ576mj6t1xHGZO2z4WY1zreRdU3AAKhE/6ZDV2lSbFJN3EpyJmhaJ+3joaVPZDpFv
Ob9j4PwgYZS/Bx9irOdh76eb5QYcSflUgQDIz4qiUTGVc9OMtwm2fpIlGgUtAgMBAAGjgcgwgcUw
DAYDVR0TAQH/BAIwADAOBgNVHQ8BAf8EBAMCBeAwMwYJYIZIAYb4QgEIBCYWJGh0dHA6Ly93d3cu
dHJ1c3RjZW50ZXIuZGUvZ3VpZGVsaW5lczARBglghkgBhvhCAQEEBAMCBaAwXQYJYIZIAYb4QgED
BFAWTmh0dHBzOi8vd3d3LnRydXN0Y2VudGVyLmRlL2NnaS1iaW4vY2hlY2stcmV2LmNnaS8zNEEw
MDAwMTAwMDIzNkY1RjcxQUIzQTIzRTI3PzANBgkqhkiG9w0BAQQFAAOBgQAs9TMlE2KxxylRBeLw
vbk1n5ZPoShDiaOFsx0GzF/1LMD86HUn8cgde8/wxqHawNZK1aNTwq3TfXuQYVFz410YeCrFyEYo
gi6wbmx+gGWCOud4xqUPG5C8p4q5Lst9thod3OUGsbs9IfVAD+VUHtl6VWrbqUyvuIEUxXwx0cfp
QjCCA1wwggLFoAMCAQICAgPpMA0GCSqGSIb3DQEBBAUAMIG8MQswCQYDVQQGEwJERTEQMA4GA1UE
CBMHSGFtYnVyZzEQMA4GA1UEBxMHSGFtYnVyZzE6MDgGA1UEChMxVEMgVHJ1c3RDZW50ZXIgZm9y
IFNlY3VyaXR5IGluIERhdGEgTmV0d29ya3MgR21iSDEiMCAGA1UECxMZVEMgVHJ1c3RDZW50ZXIg
Q2xhc3MgMSBDQTEpMCcGCSqGSIb3DQEJARYaY2VydGlmaWNhdGVAdHJ1c3RjZW50ZXIuZGUwHhcN
OTgwMzA5MTE1OTU5WhcNMTEwMTAxMTE1OTU5WjCBvDELMAkGA1UEBhMCREUxEDAOBgNVBAgTB0hh
bWJ1cmcxEDAOBgNVBAcTB0hhbWJ1cmcxOjA4BgNVBAoTMVRDIFRydXN0Q2VudGVyIGZvciBTZWN1
cml0eSBpbiBEYXRhIE5ldHdvcmtzIEdtYkgxIjAgBgNVBAsTGVRDIFRydXN0Q2VudGVyIENsYXNz
IDEgQ0ExKTAnBgkqhkiG9w0BCQEWGmNlcnRpZmljYXRlQHRydXN0Y2VudGVyLmRlMIGfMA0GCSqG
SIb3DQEBAQUAA4GNADCBiQKBgQCwKeu0drOu17ZbtF7nveOxnEkEV1uhq9l/Exv9umGr2Odx3y0A
lF1RSH0j73VihJA8Ch9ZEXQvjoCl/TACPSlSzXIaSSGcvMtSjkihY5bIEIUwaVd0RcBahsbVPeBo
V30xaiSNRZc+MX5oZjJuJG3sMjbJQcrwMUTIo2HKG6A2HwIDAQABo2swaTAPBgNVHRMBAf8EBTAD
AQH/MA4GA1UdDwEB/wQEAwIBhjAzBglghkgBhvhCAQgEJhYkaHR0cDovL3d3dy50cnVzdGNlbnRl
ci5kZS9ndWlkZWxpbmVzMBEGCWCGSAGG+EIBAQQEAwIABzANBgkqhkiG9w0BAQQFAAOBgQBPmVmF
yGRWgsVvPdhGCS88UcGncFiBkhLq9NQWAJZecijn1jZfGpyvH8KDGrQFVZmmWFw3KPJXHutdv7HT
RQ9yHAPSAMcsVdr+X4l2i+LUd/VNCRevxLqrMCtPuB3q2f9Z8FB0Rrpe6jaw65J7D1jaMuFSvSM3
D/XzAEqusF7ebjGCBAgwggQEAgEBMIHPMIG8MQswCQYDVQQGEwJERTEQMA4GA1UECBMHSGFtYnVy
ZzEQMA4GA1UEBxMHSGFtYnVyZzE6MDgGA1UEChMxVEMgVHJ1c3RDZW50ZXIgZm9yIFNlY3VyaXR5
IGluIERhdGEgTmV0d29ya3MgR21iSDEiMCAGA1UECxMZVEMgVHJ1c3RDZW50ZXIgQ2xhc3MgMSBD
QTEpMCcGCSqGSIb3DQEJARYaY2VydGlmaWNhdGVAdHJ1c3RjZW50ZXIuZGUCDjSgAAEAAjb19xqz
oj4nMAkGBSsOAwIaBQCgggKOMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkF
MQ8XDTA1MTIxMjEyMzgzOFowIwYJKoZIhvcNAQkEMRYEFCgaoI+5s8Z58iraX9wXZNyTHLNDMGcG
CSqGSIb3DQEJDzFaMFgwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFA
MAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMAcGBSsOAwIaMAoGCCqGSIb3DQIFMIHgBgkrBgEEAYI3
EAQxgdIwgc8wgbwxCzAJBgNVBAYTAkRFMRAwDgYDVQQIEwdIYW1idXJnMRAwDgYDVQQHEwdIYW1i
dXJnMTowOAYDVQQKEzFUQyBUcnVzdENlbnRlciBmb3IgU2VjdXJpdHkgaW4gRGF0YSBOZXR3b3Jr
cyBHbWJIMSIwIAYDVQQLExlUQyBUcnVzdENlbnRlciBDbGFzcyAxIENBMSkwJwYJKoZIhvcNAQkB
FhpjZXJ0aWZpY2F0ZUB0cnVzdGNlbnRlci5kZQIONKAAAQACNvX3GrOiPicwgeIGCyqGSIb3DQEJ
EAILMYHSoIHPMIG8MQswCQYDVQQGEwJERTEQMA4GA1UECBMHSGFtYnVyZzEQMA4GA1UEBxMHSGFt
YnVyZzE6MDgGA1UEChMxVEMgVHJ1c3RDZW50ZXIgZm9yIFNlY3VyaXR5IGluIERhdGEgTmV0d29y
a3MgR21iSDEiMCAGA1UECxMZVEMgVHJ1c3RDZW50ZXIgQ2xhc3MgMSBDQTEpMCcGCSqGSIb3DQEJ
ARYaY2VydGlmaWNhdGVAdHJ1c3RjZW50ZXIuZGUCDjSgAAEAAjb19xqzoj4nMA0GCSqGSIb3DQEB
AQUABIGAUmBJMS+EP8qmfcTWzexQvYmYIL4NWLaZwaVIZCuqiVU75b8eFrePigk8uDS2uCb1QF6M
Mo0d/tFxMnZWfOkWi2isiyX1yOCThJMMdtDhg3Av8l9RgCmi320hP35wX+4B7PKxA2HZYruVRhRJ
Q548oJESXDqXvmg1U8bXJ5J47ocAAAAAAAA=

------=_NextPart_000_0000_01C5FEDE.4D557C50--



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id jBBLHY4q016438; Sun, 11 Dec 2005 13:17:34 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id jBBLHYcO016437; Sun, 11 Dec 2005 13:17:34 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from moutng.kundenserver.de (moutng.kundenserver.de [212.227.126.187]) by above.proper.com (8.12.11/8.12.9) with ESMTP id jBBLHX3I016396 for <[e-mail]>; Sun, 11 Dec 2005 13:17:33 -0800 (PST) (envelope-from [e-mail])
Received: from [84.189.9.214] (helo=[127.0.0.1]) by mrelayeu.kundenserver.de (node=mrelayeu8) with ESMTP (Nemesis), id 0ML2ov-1ElYZV0OHk-00027k; Sun, 11 Dec 2005 22:17:29 +0100
Message-ID: <[e-mail]>
Date: Sun, 11 Dec 2005 22:17:23 +0100
From: "Keutel, Jochen" <[e-mail]>
User-Agent: Mozilla Thunderbird 1.0.6 (Windows/20050716)
X-Accept-Language: de-DE, de, en-us, en
MIME-Version: 1.0
To: [e-mail]
Subject: again: pmiUser ...
Content-Type: text/plain; charset=ISO-8859-15; format=flowed
Content-Transfer-Encoding: 7bit
X-Provags-ID: kundenserver.de [e-mail] login:bd0f615417fb2508e1b23f8a312bf6cb
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Hello,
   I didn't get any answer on the question I asked some days ago
(see below). So, let me ask this as follows:

Do you store attribute certificates in LDAP directories? If so:
Which object class are you using?

Bye, Jochen.

---

Hello,
   X.509 defines the LDAP object class pmiUser and the
attribute attributeCertificateAttribute.

I can't find these definitions in LDAP RFCs oder non-expired drafts ...
I found

http://tools.ietf.org/wg/pkix/draft-ietf-pkix-ldap-pmi-schema/draft-ietf-pkix-ldap-pmi-schema-00.txt

- but it's from June, 2002 ...

Did I miss an I-D and/or RFC?

Regards,  Jochen.



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id jBA9IBqI052489; Sat, 10 Dec 2005 01:18:11 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id jBA9IB7c052488; Sat, 10 Dec 2005 01:18:11 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from pne-smtpout2-sn2.hy.skanova.net (pne-smtpout2-sn2.hy.skanova.net [81.228.8.164]) by above.proper.com (8.12.11/8.12.9) with ESMTP id jBA9I61Q052481 for <[e-mail]>; Sat, 10 Dec 2005 01:18:07 -0800 (PST) (envelope-from [e-mail])
Received: from arport2v (81.232.45.196) by pne-smtpout2-sn2.hy.skanova.net (7.2.060.1) id 43960D0D0010D823; Sat, 10 Dec 2005 10:17:56 +0100
Message-ID: <013701c5fd6b$1fce50f0$8217a8c0@arport2v>
From: "Anders Rundgren" <[e-mail]>
To: "Ersin Gulacti" <[e-mail]>, <[e-mail]>
References: <[e-mail]>
Subject: Re: Certificate Validity Problem
Date: Sat, 10 Dec 2005 10:21:38 +0100
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-9"
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>

Ersin,

You may as some people proposed, rely on a service to provide this information.

A more general approach that works with existing services offered
by CAs is to actually validate (and optionally record results,
timestamp etc.) certificates during receival of a signed message.

By also using on-line signing[*], the difference between the actual
signing time and receival time becomes insignificant.

This scheme has AFAIK been adopted by most governments in the EU.

The major advantage of this approach is that it is independent of if the
CA is still alive the day the signature is to be relied upon.  This is
indeed a real-world issue both for commercial CAs or in-house CAs.

A further problem with "historic" validation services, is that unless you
actually use on-line signing and associated storage, it seems to be
rather hard to securely determine the signing time.

Note that none of the suggested methods though properly supports the
case when it is later found out that the private key was out of control during
the signing.  That is, it does not seem to help much if you ten years after
the signature was performed (when you suddenly need to rely on it),
find out that it was actually made by the wrong person.  For that
scenario you would rather need an alert from the CA in order to deal
with the situation immediately when it occurred.  Although I don't
propose any new protocol, this would probably need something like
a "Monitor this certificate" request.

Anders Rundgren
Principal Engineer
RSA Security

Disclaimer:
This message expresses the author's own opinions and not necessarily those
of RSA Security

*] Although on-line signatures are in a poor shape standards-wise, the
advantages of of combining signature validation,  input data validatation,
interactivity, and SSL encryption in one chunk, has anyway made this way
of signing more important in the EU than signed e-mail.

----- Original Message ----- 
From: "Ersin Gulacti" <[e-mail]>
To: <[e-mail]>
Sent: Wednesday, December 07, 2005 17:23
Subject: Certificate Validity Problem




Hello,

We are operating a Certificate Authority (which uses our own CA software)
and we have a process to set certificate status to on-hold. Owners of
certificates can put their certificates on-hold and they can return them
to the valid status.

When somebody tries to verify the validity of signature he can only check
the most recent status of the certificate. He can use the most fresh CRL
or execute an OCSP query. Both of these techniques lack an important
functionality, you cannot query the status of a certificate at a certain
time in the past. Maybe at the time of signing the certificate used was
on-hold.

Is there a method or another technique to solve this problem?

Thanks.




Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id jB9HrV6A056800; Fri, 9 Dec 2005 09:53:31 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id jB9HrVLv056797; Fri, 9 Dec 2005 09:53:31 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from host15.websitesource.com (host15.websitesource.com [209.239.32.38]) by above.proper.com (8.12.11/8.12.9) with ESMTP id jB9HrUVx056785; Fri, 9 Dec 2005 09:53:31 -0800 (PST) (envelope-from [e-mail])
Received: from wchokhani (static-70-21-114-242.res.east.verizon.net [70.21.114.242]) by host15.websitesource.com (8.12.10/8.12.10) with ESMTP id jB9HrUC7017857; Fri, 9 Dec 2005 12:53:30 -0500
From: "Santosh Chokhani" <[e-mail]>
To: <[e-mail]>
Cc: <[e-mail]>
Subject: RE: Certificate Validity Problem
Date: Fri, 9 Dec 2005 12:53:24 -0500
Message-ID: <00cc01c5fce9$76d7c980$[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Office Outlook 11
Thread-Index: AcX86J3NCoy8rQjcTTe6bG+FSIf9kwAAE3Ig
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2670
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>

The work being done in the IETF LTANS will also help.

Also, there is an I-D that is relevant to this effort.  The following is the
I-D URL.

http://www.ietf.org/internet-drafts/draft-ietf-ltans-ers-scvp-00.txt

-----Original Message-----
From: [e-mail] [mailto:[e-mail]] On
Behalf Of Russ Housley
Sent: Friday, December 09, 2005 11:04 AM
To: Stephen Kent; Ersin Gulacti
Cc: [e-mail]
Subject: Re: Certificate Validity Problem


The protocol accommodates the query, but the server need to keep the 
historical data to respond property.  As I see it, this historical 
data retention is optional.

Russ

At 11:59 AM 12/8/2005, Stephen Kent wrote:

>>Hello,
>>
>>We are operating a Certificate Authority (which uses our own CA software)
>>and we have a process to set certificate status to on-hold. Owners of
>>certificates can put their certificates on-hold and they can return them
>>to the valid status.
>>
>>When somebody tries to verify the validity of signature he can only check
>>the most recent status of the certificate. He can use the most fresh CRL
>>or execute an OCSP query. Both of these techniques lack an important
>>functionality, you cannot query the status of a certificate at a certain
>>time in the past. Maybe at the time of signing the certificate used was
>>on-hold.
>>
>>Is there a method or another technique to solve this problem?
>>
>>Thanks.
>
>SCVP should be able to accommodate queries about the status of a 
>cert at a previous point in time.
>
>Steve
>



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id jB9Gt3qB050250; Fri, 9 Dec 2005 08:55:03 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id jB9Gt3MI050249; Fri, 9 Dec 2005 08:55:03 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from aragorn.bbn.com (aragorn.bbn.com [128.33.0.62]) by above.proper.com (8.12.11/8.12.9) with ESMTP id jB9Gt2Db050237 for <[e-mail]>; Fri, 9 Dec 2005 08:55:02 -0800 (PST) (envelope-from [e-mail])
Received: from [192.168.0.102] (dommiel.bbn.com [192.1.122.15]) by aragorn.bbn.com (8.12.7/8.12.7) with ESMTP id jB9GspIE012640; Fri, 9 Dec 2005 11:54:56 -0500 (EST)
Mime-Version: 1.0
Message-Id: <p0623090bbfbf66c9c1f1@[192.168.0.102]>
In-Reply-To: <[e-mail]>
References: <[e-mail]> <p0623090abfbe1550773b@[128.89.89.106]> <[e-mail]>
Date: Fri, 9 Dec 2005 11:52:35 -0500
To: Russ Housley <[e-mail]>
From: Stephen Kent <[e-mail]>
Subject: Re: Certificate Validity Problem
Cc: "Ersin Gulacti" <[e-mail]>, [e-mail]
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
X-Virus-Scanned: ClamAV version 0.83, clamav-milter version 0.83 on 128.33.1.41
X-Virus-Status: Clean
Sender: [e-mail]
Precedence: 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:03 AM -0500 12/9/05, Russ Housley wrote:
>The protocol accommodates the query, but the server need to keep the 
>historical data to respond property.  As I see it, this historical 
>data retention is optional.
>
>Russ
>

Agreed.

Steve



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id jB9GUDX0047809; Fri, 9 Dec 2005 08:30:13 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id jB9GUDG6047808; Fri, 9 Dec 2005 08:30:13 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from woodstock.binhost.com (woodstock.binhost.com [144.202.243.4]) by above.proper.com (8.12.11/8.12.9) with SMTP id jB9GUChI047800 for <[e-mail]>; Fri, 9 Dec 2005 08:30:12 -0800 (PST) (envelope-from [e-mail])
Received: (qmail 22890 invoked by uid 0); 9 Dec 2005 16:30:08 -0000
Received: from unknown (HELO Russ-Laptop.vigilsec.com) (141.156.162.215) by woodstock.binhost.com with SMTP; 9 Dec 2005 16:30:08 -0000
Message-Id: <[e-mail]>
X-Mailer: QUALCOMM Windows Eudora Version 7.0.0.10 (Beta)
Date: Fri, 09 Dec 2005 11:03:35 -0500
To: Stephen Kent <[e-mail]>, "Ersin Gulacti" <[e-mail]>
From: Russ Housley <[e-mail]>
Subject: Re: Certificate Validity Problem
Cc: [e-mail]
In-Reply-To: <p0623090abfbe1550773b@[128.89.89.106]>
References: <[e-mail]> <p0623090abfbe1550773b@[128.89.89.106]>
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 protocol accommodates the query, but the server need to keep the 
historical data to respond property.  As I see it, this historical 
data retention is optional.

Russ

At 11:59 AM 12/8/2005, Stephen Kent wrote:

>>Hello,
>>
>>We are operating a Certificate Authority (which uses our own CA software)
>>and we have a process to set certificate status to on-hold. Owners of
>>certificates can put their certificates on-hold and they can return them
>>to the valid status.
>>
>>When somebody tries to verify the validity of signature he can only check
>>the most recent status of the certificate. He can use the most fresh CRL
>>or execute an OCSP query. Both of these techniques lack an important
>>functionality, you cannot query the status of a certificate at a certain
>>time in the past. Maybe at the time of signing the certificate used was
>>on-hold.
>>
>>Is there a method or another technique to solve this problem?
>>
>>Thanks.
>
>SCVP should be able to accommodate queries about the status of a 
>cert at a previous point in time.
>
>Steve
>



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id jB8GxEls012803; Thu, 8 Dec 2005 08:59:14 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id jB8GxE71012802; Thu, 8 Dec 2005 08:59:14 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from aragorn.bbn.com (aragorn.bbn.com [128.33.0.62]) by above.proper.com (8.12.11/8.12.9) with ESMTP id jB8GxCh0012789 for <[e-mail]>; Thu, 8 Dec 2005 08:59:12 -0800 (PST) (envelope-from [e-mail])
Received: from [128.89.89.106] (dhcp89-089-106.bbn.com [128.89.89.106]) by aragorn.bbn.com (8.12.7/8.12.7) with ESMTP id jB8Gx4IC017548; Thu, 8 Dec 2005 11:59:06 -0500 (EST)
Mime-Version: 1.0
Message-Id: <p0623090abfbe1550773b@[128.89.89.106]>
In-Reply-To: <[e-mail]>
References: <[e-mail]>
Date: Thu, 8 Dec 2005 11:59:02 -0500
To: "Ersin Gulacti" <[e-mail]>
From: Stephen Kent <[e-mail]>
Subject: Re: Certificate Validity Problem
Cc: [e-mail]
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
X-Virus-Scanned: ClamAV version 0.83, clamav-milter version 0.83 on 128.33.1.41
X-Virus-Status: Clean
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

>Hello,
>
>We are operating a Certificate Authority (which uses our own CA software)
>and we have a process to set certificate status to on-hold. Owners of
>certificates can put their certificates on-hold and they can return them
>to the valid status.
>
>When somebody tries to verify the validity of signature he can only check
>the most recent status of the certificate. He can use the most fresh CRL
>or execute an OCSP query. Both of these techniques lack an important
>functionality, you cannot query the status of a certificate at a certain
>time in the past. Maybe at the time of signing the certificate used was
>on-hold.
>
>Is there a method or another technique to solve this problem?
>
>Thanks.

SCVP should be able to accommodate queries about the status of a cert 
at a previous point in time.

Steve



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id jB7GQ9A8054921; Wed, 7 Dec 2005 08:26:09 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id jB7GQ9LG054920; Wed, 7 Dec 2005 08:26:09 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from uekae.uekae.gov.tr ([193.140.74.2]) by above.proper.com (8.12.11/8.12.9) with ESMTP id jB7GQ7Qw054912 for <[e-mail]>; Wed, 7 Dec 2005 08:26:08 -0800 (PST) (envelope-from [e-mail])
Received: from www.uekae.tubitak.gov.tr (hitit.uekae.tubitak.gov.tr [192.168.5.6]) by uekae.uekae.gov.tr (UEKAE_MAIL_SERVER_V4) with ESMTP id 6805749001D for <[e-mail]>; Wed,  7 Dec 2005 18:19:24 +0200 (EET)
Received: from 81.207.19.69 (SquirrelMail authenticated user egulacti) by www.uekae.tubitak.gov.tr with HTTP; Wed, 7 Dec 2005 18:23:34 +0200 (EET)
Date: Wed, 7 Dec 2005 18:23:34 +0200 (EET)
Subject: Certificate Validity Problem
From: "Ersin Gulacti" <[e-mail]>
To: [e-mail]
MIME-Version: 1.0
Content-Type: text/plain;charset=iso-8859-9
X-Priority: 3 (Normal)
Importance: Normal
Message-Id: <[e-mail]>
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id jB7GQ9Qw054915
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Hello,

We are operating a Certificate Authority (which uses our own CA software)
and we have a process to set certificate status to on-hold. Owners of
certificates can put their certificates on-hold and they can return them
to the valid status.

When somebody tries to verify the validity of signature he can only check
the most recent status of the certificate. He can use the most fresh CRL
or execute an OCSP query. Both of these techniques lack an important
functionality, you cannot query the status of a certificate at a certain
time in the past. Maybe at the time of signing the certificate used was
on-hold.

Is there a method or another technique to solve this problem?

Thanks.




Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id jB76vNqF041868; Tue, 6 Dec 2005 22:57:23 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id jB76vN2k041867; Tue, 6 Dec 2005 22:57:23 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from mail1.quimbik.com (mail1.quimbik.com [198.87.27.232]) by above.proper.com (8.12.11/8.12.9) with ESMTP id jB76vNHb041861 for <[e-mail]>; Tue, 6 Dec 2005 22:57:23 -0800 (PST) (envelope-from [e-mail])
Received: from [172.16.1.52] (adsl-63-204-17-85.dsl.snfc21.pacbell.net [63.204.17.85]) by mail1.quimbik.com (Postfix) with ESMTP id BC61533C154 for <[e-mail]>; Tue,  6 Dec 2005 22:57:22 -0800 (PST)
Message-ID: <[e-mail]>
Date: Tue, 06 Dec 2005 22:57:07 -0800
From: Ed Gerck <[e-mail]>
User-Agent: Thunderbird 1.4 (Macintosh/20050908)
MIME-Version: 1.0
To: [e-mail]
Subject: feedback on X.509 / PKI secure email support
References: <p06110403bfbc0327f801@[192.168.1.35]> <[e-mail]>
In-Reply-To: <[e-mail]>
Content-Type: text/plain; charset=ISO-8859-1; 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>

http://email-security.net/papers/pki-pgp-ibe.htm

Greetings.

I would like feedback (by private email) on a list of desirable
secure email features as well as a list of attacks or problems, with
a corresponding score card for the secure email technologies X.509 /
PKI, PGP and IBE. The paper is at
http://email-security.net/papers/pki-pgp-ibe.htm

One of the motivations for this approach is to help develop a common
yardstick. Comparing these systems has been like comparing apples with
speedboats and wingbats. A speedboat is a bad apple, and so on.

The list of desirable secure email features and the list of attacks /
problems might also be useful for this WG, in terms of certificate
capabilities to support secure email.

Cheers,
Ed Gerck



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id jB5Ltd23012556; Mon, 5 Dec 2005 13:55:39 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id jB5LtdWL012555; Mon, 5 Dec 2005 13:55:39 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from woodstock.binhost.com (woodstock.binhost.com [144.202.243.4]) by above.proper.com (8.12.11/8.12.9) with SMTP id jB5LtcbE012539 for <[e-mail]>; Mon, 5 Dec 2005 13:55:38 -0800 (PST) (envelope-from [e-mail])
Received: (qmail 6786 invoked by uid 0); 5 Dec 2005 21:55:30 -0000
Received: from unknown (HELO Russ-Laptop.vigilsec.com) (138.88.40.79) by woodstock.binhost.com with SMTP; 5 Dec 2005 21:55:30 -0000
Message-Id: <[e-mail]>
X-Mailer: QUALCOMM Windows Eudora Version 7.0.0.10 (Beta)
Date: Mon, 05 Dec 2005 09:57:24 -0500
To: [e-mail]
From: Russ Housley <[e-mail]>
Subject: Does anyone use RFC 2875?
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>

I am trying to understand which IETF documents might need to be 
updated to include a key derivation function  (KDF) that is compliant 
with NIST SP 800-56.  RFC 2875 includes a KDF that is not supported 
by NIST SP 800-56, but I am not sure that anyone is actually using it.

Russ



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id jB468fMN069427; Sat, 3 Dec 2005 22:08:41 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id jB468eAh069426; Sat, 3 Dec 2005 22:08:40 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from [10.20.30.249] (dsl2-63-249-109-231.cruzio.com [63.249.109.231]) (authenticated bits=0) by above.proper.com (8.12.11/8.12.9) with ESMTP id jB468cRG069418 for <[e-mail]>; Sat, 3 Dec 2005 22:08:40 -0800 (PST) (envelope-from [e-mail])
Mime-Version: 1.0
Message-Id: <p06230940bfb8366354b6@[10.20.30.249]>
Date: Sat, 3 Dec 2005 22:08:34 -0800
To: [e-mail]
From: Paul Hoffman <[e-mail]>
Subject: Preventing identity attacks in PKIX
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>

Greetings again. I just posted a long thought-piece at 
<http://LookIt.proper.com/archives/000370.html> on the choices the 
PKIX community may need to make in order to prevent attacks against 
identities in certificates, should the Wang-style attacks improve. 
The WG probably should take up this topic at some point in the 
not-distant future.

If I have made omissions or errors in the article, please let me know 
so I can fix it.

--Paul Hoffman, Director
--VPN Consortium



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id jB2FWVSX020276; Fri, 2 Dec 2005 07:32:31 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id jB2FWVmr020275; Fri, 2 Dec 2005 07:32:31 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from aragorn.bbn.com (aragorn.bbn.com [128.33.0.62]) by above.proper.com (8.12.11/8.12.9) with ESMTP id jB2FWPtA020259 for <[e-mail]>; Fri, 2 Dec 2005 07:32:30 -0800 (PST) (envelope-from [e-mail])
Received: from [128.89.89.106] (dhcp89-089-106.bbn.com [128.89.89.106]) by aragorn.bbn.com (8.12.7/8.12.7) with ESMTP id jB2FWBIO001350 for <[e-mail]>; Fri, 2 Dec 2005 10:32:20 -0500 (EST)
Mime-Version: 1.0
Message-Id: <p06230907bfb6103c188f@[128.89.89.106]>
Date: Fri, 2 Dec 2005 10:22:33 -0500
To: [e-mail]
From: Stephen Kent <[e-mail]>
Subject: minutes
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
X-Virus-Scanned: ClamAV version 0.83, clamav-milter version 0.83 on 128.33.1.41
X-Virus-Status: Clean
Sender: [e-mail]
Precedence: 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,

I received a few comments on the minutes and have made the requested 
changes. The final minutes are now posted at the IETF web site:

	http://www3.ietf.org/proceedings/05nov/minutes/pkix.htm

I'm not sure why we have question marks inserted for apostrophes and 
bullets, but ...


Steve



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id jB1HDSlf085978; Thu, 1 Dec 2005 09:13:28 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id jB1HDSQ4085977; Thu, 1 Dec 2005 09:13:28 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from moutng.kundenserver.de (moutng.kundenserver.de [212.227.126.188]) by above.proper.com (8.12.11/8.12.9) with ESMTP id jB1HDRgU085971 for <[e-mail]>; Thu, 1 Dec 2005 09:13:28 -0800 (PST) (envelope-from [e-mail])
Received: from [84.189.54.178] (helo=[127.0.0.1]) by mrelayeu.kundenserver.de (node=mrelayeu5) with ESMTP (Nemesis), id 0ML25U-1Ehrzo46lz-0008Gh; Thu, 01 Dec 2005 18:13:25 +0100
Message-ID: <[e-mail]>
Date: Thu, 01 Dec 2005 18:13:19 +0100
From: Jochen Keutel <[e-mail]>
User-Agent: Mozilla Thunderbird 1.0.6 (Windows/20050716)
X-Accept-Language: de-DE, de, en-us, en
MIME-Version: 1.0
To: ietf-pkix <[e-mail]>
Subject: pmiUser ?
Content-Type: text/plain; charset=ISO-8859-15; format=flowed
Content-Transfer-Encoding: 7bit
X-Provags-ID: kundenserver.de [e-mail] login:bd0f615417fb2508e1b23f8a312bf6cb
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Hello,
   X.509 defines the LDAP object class pmiUser and the
attribute attributeCertificateAttribute.

I can't find these definitions in LDAP RFCs oder non-expired drafts ...
I found

http://tools.ietf.org/wg/pkix/draft-ietf-pkix-ldap-pmi-schema/draft-ietf-pkix-ldap-pmi-schema-00.txt

- but it's from June, 2002 ...

Did I miss an I-D and/or RFC?

Regards,  Jochen.