Subject: RFC4210 and CMPtrans

From: Teemu Alakoski <[email-masked]>
Date: Tue, 27 Dec 2005 11:10:30 +0200

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. 	+358 10 44 211
Gsm	+358 40 772 2951
Fax	+358 10 442 1300
[email-masked]
www.insta.fi

---

From: [email-masked] (Peter Gutmann)
Date: Tue, 27 Dec 2005 22:51:02 +1300

Teemu Alakoski <[email-masked]> 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.

From: [email-masked] (Peter Gutmann)
To: [email-masked], [email-masked]
Subject: Re: RFC4210 and CMPtrans
Date: Tue, 27 Dec 2005 22:51:02 +1300
Sender: [email-masked]

Teemu Alakoski <[email-masked]> 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.

Date: Tue, 27 Dec 2005 11:10:30 +0200
From: Teemu Alakoski <[email-masked]>
To: [email-masked]
Subject: RFC4210 and CMPtrans
Sender: [email-masked]

Hello,

-Teemu

--
Teemu Alakoski

INSTRUMENTOINTI OY
Instasec Oy

Date: Thu, 22 Dec 2005 12:45:42 -0800
From: Ed Gerck <[email-masked]>
To: [email-masked]
Subject: Re: Certificate Validity Problem
Sender: [email-masked]

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

To: [email-masked]
Cc: [email-masked]
From: [email-masked]
Subject: I-D ACTION:draft-ietf-pkix-gost-cppk-04.txt 
Date: Wed, 21 Dec 2005 15:50:02 -0500
Sender: [email-masked]

--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 
[email-masked] 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:
	[email-masked].
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="[email-masked]"

Content-Type: text/plain
Content-ID:	<[email-masked]>

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:	<[email-masked]>

--OtherAccess--

--NextPart--

From: "Anders Rundgren" <[email-masked]>
To: "sravan" <[email-masked]>, <[email-masked]>
Cc: "Ersin Gulacti" <[email-masked]>
Subject: Re: Certificate Validity Problem
Date: Wed, 21 Dec 2005 21:36:28 +0100
Sender: [email-masked]

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

Date: Wed, 21 Dec 2005 16:30:28 +0100
From: =?ISO-8859-1?Q?Michael_Str=F6der?= <[email-masked]>
To: [email-masked]
Subject: Re: Certificate Validity Problem
Sender: [email-masked]

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.

From: "santosh chokhani" <[email-masked]>
To: <[email-masked]>
Subject: RE: Certificate Validity Problem
Date: Wed, 21 Dec 2005 09:31:47 -0500
Sender: [email-masked]

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: [email-masked] [mailto:[email-masked]] On
Behalf Of Stephen Kent
Sent: Tuesday, December 20, 2005 10:05 AM
To: Tom Gindin
Cc: Ersin Gulacti; [email-masked]
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

To: [email-masked]
Cc: [email-masked]
From: [email-masked]
Subject: I-D ACTION:draft-ietf-pkix-acpolicies-extn-07.txt 
Date: Tue, 20 Dec 2005 15:50:01 -0500
Sender: [email-masked]

--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 
[email-masked] 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:
	[email-masked].
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="[email-masked]"

Content-Type: text/plain
Content-ID:	<[email-masked]>

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:	<[email-masked]>

--OtherAccess--

--NextPart--

Date: Tue, 20 Dec 2005 10:05:20 -0500
To: Tom Gindin <[email-masked]>
From: Stephen Kent <[email-masked]>
Subject: Re: Certificate Validity Problem
Cc: "Ersin Gulacti" <[email-masked]>, [email-masked]
Sender: [email-masked]

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

To: Stephen Kent <[email-masked]>
Cc: "Ersin Gulacti" <[email-masked]>, [email-masked]
Subject: Re: Certificate Validity Problem
From: Tom Gindin <[email-masked]>
Date: Tue, 20 Dec 2005 08:54:17 -0500
Sender: [email-masked]

        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 <[email-masked]>
Sent by: [email-masked]
12/19/2005 09:57 AM
 
        To:     "Ersin Gulacti" <[email-masked]>
        cc:     [email-masked]
        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

Date: Mon, 19 Dec 2005 09:35:20 -0800
To: "Ersin Gulacti" <[email-masked]>
From: "Kurt D. Zeilenga" <[email-masked]>
Subject: RE: Certificate Validity Problem
Cc: [email-masked]
Sender: [email-masked]

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 

Date: Mon, 19 Dec 2005 09:57:43 -0500
To: "Ersin Gulacti" <[email-masked]>
From: Stephen Kent <[email-masked]>
Subject: Re: Certificate Validity Problem
Cc: [email-masked]
Sender: [email-masked]

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

Importance: Normal
Subject: Re: Certificate Validity Problem
From: [email-masked]
To: Dino Esposito <[email-masked]>
Cc: [email-masked], [email-masked]
Date: Mon, 19 Dec 2005 12:21:48 +0100
Sender: [email-masked]

Importance: Normal
Subject: Re: Certificate Validity Problem
From: [email-masked]
To: sravan <[email-masked]>
Cc: [email-masked]
Date: Mon, 19 Dec 2005 12:14:57 +0100
Sender: [email-masked]

Date: Mon, 19 Dec 2005 10:49:59 +0100
From: Dino Esposito <[email-masked]>
To: [email-masked]
CC: Ersin Gulacti <[email-masked]>, [email-masked]
Subject: Re: Certificate Validity Problem
Sender: [email-masked]

[email-masked] 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.
> >
>
>
>

Date: Mon, 19 Dec 2005 14:55:32 +0530
From: sravan <[email-masked]>
To: [email-masked]
CC: [email-masked]
Subject: Re: Certificate Validity Problem
Sender: [email-masked]

[email-masked] 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.

Importance: Normal
Subject: Re: Certificate Validity Problem
From: [email-masked]
To: "Ersin Gulacti" <[email-masked]>
Cc: [email-masked]
Date: Mon, 19 Dec 2005 09:36:52 +0100
Sender: [email-masked]

Date: Sun, 18 Dec 2005 23:12:47 +0200 (EET)
Subject: RE: Certificate Validity Problem
From: "Ersin Gulacti" <[email-masked]>
To: [email-masked]
Importance: Normal
Sender: [email-masked]

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 ? :)

Content-class: urn:content-classes:message
Subject: RE: Certificate Validity Problem
Date: Sun, 18 Dec 2005 06:49:55 -0800
From: "Carl Wallace" <[email-masked]>
To: "Ersin Gulacti" <[email-masked]>, <[email-masked]>
Sender: [email-masked]

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: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Ersin Gulacti
> Sent: Sunday, December 18, 2005 4:40 AM
> To: [email-masked]
> 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.
> >
> 
> 
> 
> 

Date: Sun, 18 Dec 2005 11:39:57 +0200 (EET)
Subject: Re: Certificate Validity Problem
From: "Ersin Gulacti" <[email-masked]>
To: [email-masked]
Importance: Normal
Sender: [email-masked]

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

Date: Fri, 16 Dec 2005 17:31:56 -0500
To: [email-masked]
From: Stephen Kent <[email-masked]>
Subject: last call closed
Sender: [email-masked]

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

To: [email-masked]
Subject: RFC 4325 on Internet X.509 Public Key Infrastructure Authority Information Access Certificate Revocation List (CRL) Extension
Cc: [email-masked], [email-masked]
From: [email-masked]
Date: Thu, 15 Dec 2005 17:41:11 -0800
Sender: [email-masked]

--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:    [email-masked], [email-masked]
        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 [email-masked].  Requests to be
added to or deleted from the RFC-DIST distribution list should
be sent to [email-masked].

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

        To: [email-masked]
        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 [email-masked].  Unless
specifically noted otherwise on the RFC itself, all RFCs are for
unlimited distribution.

Submissions for Requests for Comments should be sent to
[email-masked].  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="[email-masked]"

Content-Type: text/plain
Content-ID: <[email-masked]>

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: <[email-masked]>

--OtherAccess--
--NextPart--

Content-class: urn:content-classes:message
Subject: RE: again: pmiUser ...
Date: Mon, 12 Dec 2005 07:38:39 -0500
From: "Weiser, Russ" <[email-masked]>
To: "Keutel, Jochen" <[email-masked]>, <[email-masked]>
Sender: [email-masked]

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 
[email-masked]
801-255-8078 Home Office
801-631-1685 Cell 
443-367-7011 Office Columbia MD
 
-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of Keutel, Jochen
Sent: Sunday, December 11, 2005 2:17 PM
To: [email-masked]
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"

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

Date: Sun, 11 Dec 2005 22:17:23 +0100
From: "Keutel, Jochen" <[email-masked]>
To: [email-masked]
Subject: again: pmiUser ...
Sender: [email-masked]

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.

From: "Anders Rundgren" <[email-masked]>
To: "Ersin Gulacti" <[email-masked]>, <[email-masked]>
Subject: Re: Certificate Validity Problem
Date: Sat, 10 Dec 2005 10:21:38 +0100
Sender: [email-masked]

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" <[email-masked]>
To: <[email-masked]>
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.

From: "Santosh Chokhani" <[email-masked]>
To: <[email-masked]>
Cc: <[email-masked]>
Subject: RE: Certificate Validity Problem
Date: Fri, 9 Dec 2005 12:53:24 -0500
Sender: [email-masked]

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: [email-masked] [mailto:[email-masked]] On
Behalf Of Russ Housley
Sent: Friday, December 09, 2005 11:04 AM
To: Stephen Kent; Ersin Gulacti
Cc: [email-masked]
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
>

Date: Fri, 9 Dec 2005 11:52:35 -0500
To: Russ Housley <[email-masked]>
From: Stephen Kent <[email-masked]>
Subject: Re: Certificate Validity Problem
Cc: "Ersin Gulacti" <[email-masked]>, [email-masked]
Sender: [email-masked]

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

Date: Fri, 09 Dec 2005 11:03:35 -0500
To: Stephen Kent <[email-masked]>, "Ersin Gulacti" <[email-masked]>
From: Russ Housley <[email-masked]>
Subject: Re: Certificate Validity Problem
Cc: [email-masked]
Sender: [email-masked]

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
>

Date: Thu, 8 Dec 2005 11:59:02 -0500
To: "Ersin Gulacti" <[email-masked]>
From: Stephen Kent <[email-masked]>
Subject: Re: Certificate Validity Problem
Cc: [email-masked]
Sender: [email-masked]

>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

Date: Wed, 7 Dec 2005 18:23:34 +0200 (EET)
Subject: Certificate Validity Problem
From: "Ersin Gulacti" <[email-masked]>
To: [email-masked]
Importance: Normal
Sender: [email-masked]

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.

Date: Tue, 06 Dec 2005 22:57:07 -0800
From: Ed Gerck <[email-masked]>
To: [email-masked]
Subject: feedback on X.509 / PKI secure email support
Sender: [email-masked]

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

Date: Mon, 05 Dec 2005 09:57:24 -0500
To: [email-masked]
From: Russ Housley <[email-masked]>
Subject: Does anyone use RFC 2875?
Sender: [email-masked]

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

Date: Sat, 3 Dec 2005 22:08:34 -0800
To: [email-masked]
From: Paul Hoffman <[email-masked]>
Subject: Preventing identity attacks in PKIX
Sender: [email-masked]

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

Date: Fri, 2 Dec 2005 10:22:33 -0500
To: [email-masked]
From: Stephen Kent <[email-masked]>
Subject: minutes
Sender: [email-masked]

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

Date: Thu, 01 Dec 2005 18:13:19 +0100
From: Jochen Keutel <[email-masked]>
To: ietf-pkix <[email-masked]>
Subject: pmiUser ?
Sender: [email-masked]

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.